Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
Peter,
On 04/05/16 06:35, Peter Chen wrote:
> On Tue, May 03, 2016 at 06:44:46PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> On 03/05/16 10:06, Jun Li wrote:
>>> Hi
>>>
>>>>>>>>>>> /**
>>>>>>>>>>> + * usb_gadget_start - start the usb gadget controller and
>>>>>>>>>>> +connect to bus
>>>>>>>>>>> + * @gadget: the gadget device to start
>>>>>>>>>>> + *
>>>>>>>>>>> + * This is external API for use by OTG core.
>>>>>>>>>>> + *
>>>>>>>>>>> + * Start the usb device controller and connect to bus (enable
>>>> pull).
>>>>>>>>>>> + */
>>>>>>>>>>> +static int usb_gadget_start(struct usb_gadget *gadget) {
>>>>>>>>>>> + int ret;
>>>>>>>>>>> + struct usb_udc *udc = NULL;
>>>>>>>>>>> +
>>>>>>>>>>> + dev_dbg(&gadget->dev, "%s\n", __func__);
>>>>>>>>>>> + mutex_lock(&udc_lock);
>>>>>>>>>>> + list_for_each_entry(udc, &udc_list, list)
>>>>>>>>>>> + if (udc->gadget == gadget)
>>>>>>>>>>> + goto found;
>>>>>>>>>>> +
>>>>>>>>>>> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
>>>>>>>>>>> + __func__);
>>>>>>>>>>> + mutex_unlock(&udc_lock);
>>>>>>>>>>> + return -EINVAL;
>>>>>>>>>>> +
>>>>>>>>>>> +found:
>>>>>>>>>>> + ret = usb_gadget_udc_start(udc);
>>>>>>>>>>> + if (ret)
>>>>>>>>>>> + dev_err(&udc->dev, "USB Device Controller didn't
>>>>>> start: %d\n",
>>>>>>>>>>> + ret);
>>>>>>>>>>> + else
>>>>>>>>>>> + usb_udc_connect_control(udc);
>>>>>>>>>>
>>>>>>>>>> For drd, it's fine, but for real otg, gadget connect should be
>>>>>>>>>> done by
>>>>>>>>>> loc_conn() instead of gadget start.
>>>>>>>>>
>>>>>>>>> It is upto the OTG state machine to call gadget_start() when it
>>>>>>>>> needs to connect to the bus (i.e. loc_conn()). I see no point in
>>>>>>>>> calling gadget start before.
>>>>>>>>>
>>>>>>>>> Do you see any issue in doing so?
>>>>>>>>
>>>>>>>> This is what OTG state machine does:
>>>>>>>> case OTG_STATE_B_PERIPHERAL:
>>>>>>>> otg_chrg_vbus(otg, 0);
>>>>>>>> otg_loc_sof(otg, 0);
>>>>>>>> otg_set_protocol(fsm, PROTO_GADGET);
>>>>>>>> otg_loc_conn(otg, 1);
>>>>>>>> break;
>>>>>>
>>>>>> On second thoughts, after seen the OTG state machine.
>>>>>> otg_set_protocol(fsm, PROTO_GADGET); is always followed by
>>>>>> otg_loc_conn(otg, 1); And whenever protocol changes to anything other
>>>>>> the PROTO_GADGET, we use otg_loc_conn(otg, 0);
>>>>>>
>>>>>> So otg_loc_conn seems redundant. Can we just get rid of it?
>>>>>>
>>>>>> usb_gadget_start() implies that gadget controller starts up and
>>>>>> enables pull.
>>>>>> usb_gadget_stop() implies that gadget controller disables pull and
>>>> stops.
>>>>>>
>>>>>>
>>>>>> Can you please explain why just these 2 APIs are not sufficient for
>>>>>> full OTG?
>>>>>>
>>>>>> Do we want anything to happen between gadget controller start/stop
>>>>>> and pull on/off?
>>>>>
>>>>> "loc_conn" is a standard output parameter in OTG spec, it deserves a
>>>>> separate api, yes, current
Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
On 04/05/16 11:03, Jun Li wrote:
> Hi
>
>> -Original Message-----
>> From: Roger Quadros [mailto:rog...@ti.com]
>> Sent: Wednesday, May 04, 2016 2:37 PM
>> To: Peter Chen
>> Cc: Jun Li ; st...@rowland.harvard.edu; ba...@kernel.org;
>> gre...@linuxfoundation.org; peter.c...@freescale.com;
>> dan.j.willi...@intel.com; jun...@freescale.com;
>> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
>> abres...@chromium.org; r.bald...@samsung.com; linux-usb@vger.kernel.org;
>> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
>> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
>>
>> Peter,
>>
>> On 04/05/16 06:35, Peter Chen wrote:
>>> On Tue, May 03, 2016 at 06:44:46PM +0300, Roger Quadros wrote:
>>>> Hi,
>>>>
>>>> On 03/05/16 10:06, Jun Li wrote:
>>>>> Hi
>>>>>
>>>>>>>>>>>>> /**
>>>>>>>>>>>>> + * usb_gadget_start - start the usb gadget controller and
>>>>>>>>>>>>> +connect to bus
>>>>>>>>>>>>> + * @gadget: the gadget device to start
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * This is external API for use by OTG core.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * Start the usb device controller and connect to bus
>>>>>>>>>>>>> +(enable
>>>>>> pull).
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +static int usb_gadget_start(struct usb_gadget *gadget) {
>>>>>>>>>>>>> + int ret;
>>>>>>>>>>>>> + struct usb_udc *udc = NULL;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + dev_dbg(&gadget->dev, "%s\n", __func__);
>>>>>>>>>>>>> + mutex_lock(&udc_lock);
>>>>>>>>>>>>> + list_for_each_entry(udc, &udc_list, list)
>>>>>>>>>>>>> + if (udc->gadget == gadget)
>>>>>>>>>>>>> + goto found;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + dev_err(gadget->dev.parent, "%s: gadget not
>> registered.\n",
>>>>>>>>>>>>> + __func__);
>>>>>>>>>>>>> + mutex_unlock(&udc_lock);
>>>>>>>>>>>>> + return -EINVAL;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +found:
>>>>>>>>>>>>> + ret = usb_gadget_udc_start(udc);
>>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>>> + dev_err(&udc->dev, "USB Device Controller didn't
>>>>>>>> start: %d\n",
>>>>>>>>>>>>> + ret);
>>>>>>>>>>>>> + else
>>>>>>>>>>>>> + usb_udc_connect_control(udc);
>>>>>>>>>>>>
>>>>>>>>>>>> For drd, it's fine, but for real otg, gadget connect should
>>>>>>>>>>>> be done by
>>>>>>>>>>>> loc_conn() instead of gadget start.
>>>>>>>>>>>
>>>>>>>>>>> It is upto the OTG state machine to call gadget_start() when
>>>>>>>>>>> it needs to connect to the bus (i.e. loc_conn()). I see no
>>>>>>>>>>> point in calling gadget start before.
>>>>>>>>>>>
>>>>>>>>>>> Do you see any issue in doing so?
>>>>>>>>>>
>>>>>>>>>> This is what OTG state machine does:
>>>>>>>>>> case OTG_STATE_B_PERIPHERAL:
>>>>>>>>>> otg_chrg_vbus(otg, 0);
>>>>>>>>>> otg_loc_sof(otg, 0);
>>>>>>>>>> otg_set_protocol(fsm, PROTO_GADGET);
>>>>>>>>>> otg_loc_conn(otg, 1);
>>>>>>>>>> break;
>>>>>
Re: [PATCH v7 10/14] usb: otg: add hcd companion support
On 04/05/16 16:17, Rob Herring wrote: > On Mon, May 02, 2016 at 03:18:53PM +0300, Roger Quadros wrote: >> From: Yoshihiro Shimoda >> >> Since some host controller (e.g. EHCI) needs a companion host controller >> (e.g. OHCI), this patch adds such a configuration to use it in the OTG >> core. >> >> Signed-off-by: Yoshihiro Shimoda >> Signed-off-by: Roger Quadros >> --- >> Documentation/devicetree/bindings/usb/generic.txt | 3 +++ >> drivers/usb/common/usb-otg.c | 32 >> --- >> include/linux/usb/otg.h | 7 - >> 3 files changed, 32 insertions(+), 10 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/generic.txt >> b/Documentation/devicetree/bindings/usb/generic.txt >> index f6866c1..1db1c33 100644 >> --- a/Documentation/devicetree/bindings/usb/generic.txt >> +++ b/Documentation/devicetree/bindings/usb/generic.txt >> @@ -27,6 +27,9 @@ Optional properties: >> - otg-controller: phandle to otg controller. Host or gadget controllers can >> contain this property to link it to a particular OTG >> controller. >> + - hcd-needs-companion: must be present if otg controller is dealing with >> +EHCI host controller that needs a companion OHCI host >> +controller. > > Don't you need to have a link to the companion controller node? primary and companion controllers are totally independent of each other e.g. EHCI and OHCI. They are enabled by separate Kconfig options and the system can operate with either or both of them enabled. At the OTG layer we don't have information as to whether we should be waiting for both of them to register or not and hence need this "hcd-needs-companion" flag. > >> >> This is an attribute to a USB controller such as: >> -- cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface
On 06/05/16 12:41, Peter Chen wrote:
> On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote:
>> The OTG core will use struct otg_hcd_ops to interface
>> with the HCD controller.
>>
>> The main purpose of this interface is to avoid directly
>> calling HCD APIs from the OTG core as they
>> wouldn't be defined in the built-in symbol table if
>> CONFIG_USB is m.
>>
>> Signed-off-by: Roger Quadros
>> Acked-by: Peter Chen
>
> Roger, after thinking more, I still think current dependency between
> OTG, HCD and gadget are too complicated. Since the OTG can't work
> if it is built as module, I suggest letting OTG depends on HCD &&
> USB_GADGET, and it is a boolean, in that case, we don't need to
> export any HCD and gadget ops, things will be much simpler.
> What's your opinion?
How will it work if HCD and USB_GADGET are modules and OTG is built-in?
cheers,
-roger
>
> Peter
>
>> ---
>> include/linux/usb/hcd.h | 24
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
>> index b98f831..861ccaa 100644
>> --- a/include/linux/usb/hcd.h
>> +++ b/include/linux/usb/hcd.h
>> @@ -399,6 +399,30 @@ struct hc_driver {
>>
>> };
>>
>> +/**
>> + * struct otg_hcd_ops - Interface between OTG core and HCD
>> + *
>> + * Provided by the HCD core to allow the OTG core to interface with the HCD
>> + *
>> + * @add: function to add the HCD
>> + * @remove: function to remove the HCD
>> + * @usb_bus_start_enum: function to immediately start bus enumeration
>> + * @usb_control_msg: function to build and send of a control urb
>> + * @usb_hub_find_child: function to get pointer to the child device
>> + */
>> +struct otg_hcd_ops {
>> +int (*add)(struct usb_hcd *hcd,
>> + unsigned int irqnum, unsigned long irqflags);
>> +void (*remove)(struct usb_hcd *hcd);
>> +int (*usb_bus_start_enum)(struct usb_bus *bus, unsigned int port_num);
>> +int (*usb_control_msg)(struct usb_device *dev, unsigned int pipe,
>> + __u8 request, __u8 requesttype, __u16 value,
>> + __u16 index, void *data, __u16 size,
>> + int timeout);
>> +struct usb_device * (*usb_hub_find_child)(struct usb_device *hdev,
>> + int port1);
>> +};
>> +
>> static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)
>> {
>> return hcd->driver->flags & HCD_BH;
>> --
>> 2.7.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 11/14] usb: otg: use dev_dbg() instead of VDBG()
On 06/05/16 12:04, Peter Chen wrote:
> On Mon, May 02, 2016 at 03:18:54PM +0300, Roger Quadros wrote:
>> Now that we have a device reference in struct usb_otg
>> let's use dev_dbg() for debug messages.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/usb/common/usb-otg-fsm.c | 19 +++
>> 1 file changed, 7 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/usb/common/usb-otg-fsm.c
>> b/drivers/usb/common/usb-otg-fsm.c
>> index 2986b66..e6e58c2 100644
>> --- a/drivers/usb/common/usb-otg-fsm.c
>> +++ b/drivers/usb/common/usb-otg-fsm.c
>> @@ -30,13 +30,6 @@
>> #include
>> #include
>>
>> -#ifdef VERBOSE
>> -#define VDBG(fmt, args...) pr_debug("[%s] " fmt , \
>> - __func__, ## args)
>> -#else
>> -#define VDBG(stuff...) do {} while (0)
>> -#endif
>> -
>> /* Change USB protocol when there is a protocol change */
>> static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
>> {
>> @@ -44,8 +37,9 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
>> protocol)
>> int ret = 0;
>>
>> if (fsm->protocol != protocol) {
>> -VDBG("Changing role fsm->protocol= %d; new protocol= %d\n",
>> -fsm->protocol, protocol);
>> +dev_vdbg(otg->dev,
>> + "Changing role fsm->protocol= %d; new protocol= %d\n",
>> + fsm->protocol, protocol);
>> /* stop old protocol */
>> if (fsm->protocol == PROTO_HOST)
>> ret = otg_start_host(otg, 0);
>> @@ -226,7 +220,7 @@ static int otg_set_state(struct otg_fsm *fsm, enum
>> usb_otg_state new_state)
>>
>> if (otg->state == new_state)
>> return 0;
>> -VDBG("Set state: %s\n", usb_otg_state_string(new_state));
>> +dev_vdbg(otg->dev, "Set state: %s\n", usb_otg_state_string(new_state));
>> otg_leave_state(fsm, otg->state);
>> switch (new_state) {
>> case OTG_STATE_B_IDLE:
>> @@ -358,7 +352,7 @@ int otg_statemachine(struct usb_otg *otg)
>>
>> switch (state) {
>> case OTG_STATE_UNDEFINED:
>> -VDBG("fsm->id = %d\n", fsm->id);
>> +dev_vdbg(otg->dev, "fsm->id = %d\n", fsm->id);
>> if (fsm->id)
>> otg_set_state(fsm, OTG_STATE_B_IDLE);
>> else
>> @@ -466,7 +460,8 @@ int otg_statemachine(struct usb_otg *otg)
>> }
>> mutex_unlock(&fsm->lock);
>>
>> -VDBG("quit statemachine, changed = %d\n", fsm->state_changed);
>> +dev_vdbg(otg->dev, "quit statemachine, changed = %d\n",
>> + fsm->state_changed);
>> return fsm->state_changed;
>> }
>> EXPORT_SYMBOL_GPL(otg_statemachine);
>> --
>
> Could you squash patch 2 with this one?
>
We can't because at patch 2, otg->dev is not defined and we need patch 2
before patch 8 to prevent the build warning. This patch can come only
after patch 8 where we add otg->dev.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface
On 10/05/16 06:14, Peter Chen wrote:
> On Mon, May 09, 2016 at 12:45:38PM +0300, Roger Quadros wrote:
>> On 06/05/16 12:41, Peter Chen wrote:
>>> On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote:
>>>> The OTG core will use struct otg_hcd_ops to interface
>>>> with the HCD controller.
>>>>
>>>> The main purpose of this interface is to avoid directly
>>>> calling HCD APIs from the OTG core as they
>>>> wouldn't be defined in the built-in symbol table if
>>>> CONFIG_USB is m.
>>>>
>>>> Signed-off-by: Roger Quadros
>>>> Acked-by: Peter Chen
>>>
>>> Roger, after thinking more, I still think current dependency between
>>> OTG, HCD and gadget are too complicated. Since the OTG can't work
>>> if it is built as module, I suggest letting OTG depends on HCD &&
>>> USB_GADGET, and it is a boolean, in that case, we don't need to
>>> export any HCD and gadget ops, things will be much simpler.
>>> What's your opinion?
>>
>> How will it work if HCD and USB_GADGET are modules and OTG is built-in?
>>
>
> The OTG will not be compiled at this situation, since it is boolean.
> In fact, like I mentioned at above, OTG or USB function can't work if
> it is built as module.
Isn't this a limitation?
As per the current implementation dual role works fine even with both
USB_GADGET and HCD as module.
In the real world it is unlikely that GADGET and HCD will be built-in.
cheers,
-roger
>
> Peter
>> cheers,
>> -roger
>>
>>>
>>> Peter
>>>
>>>> ---
>>>> include/linux/usb/hcd.h | 24
>>>> 1 file changed, 24 insertions(+)
>>>>
>>>> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
>>>> index b98f831..861ccaa 100644
>>>> --- a/include/linux/usb/hcd.h
>>>> +++ b/include/linux/usb/hcd.h
>>>> @@ -399,6 +399,30 @@ struct hc_driver {
>>>>
>>>> };
>>>>
>>>> +/**
>>>> + * struct otg_hcd_ops - Interface between OTG core and HCD
>>>> + *
>>>> + * Provided by the HCD core to allow the OTG core to interface with the
>>>> HCD
>>>> + *
>>>> + * @add: function to add the HCD
>>>> + * @remove: function to remove the HCD
>>>> + * @usb_bus_start_enum: function to immediately start bus enumeration
>>>> + * @usb_control_msg: function to build and send of a control urb
>>>> + * @usb_hub_find_child: function to get pointer to the child device
>>>> + */
>>>> +struct otg_hcd_ops {
>>>> + int (*add)(struct usb_hcd *hcd,
>>>> + unsigned int irqnum, unsigned long irqflags);
>>>> + void (*remove)(struct usb_hcd *hcd);
>>>> + int (*usb_bus_start_enum)(struct usb_bus *bus, unsigned int port_num);
>>>> + int (*usb_control_msg)(struct usb_device *dev, unsigned int pipe,
>>>> + __u8 request, __u8 requesttype, __u16 value,
>>>> + __u16 index, void *data, __u16 size,
>>>> + int timeout);
>>>> + struct usb_device * (*usb_hub_find_child)(struct usb_device *hdev,
>>>> +int port1);
>>>> +};
>>>> +
>>>> static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)
>>>> {
>>>>return hcd->driver->flags & HCD_BH;
>>>> --
>>>> 2.7.4
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>>> the body of a message to majord...@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface
On 10/05/16 11:12, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> On 10/05/16 06:14, Peter Chen wrote: >>> On Mon, May 09, 2016 at 12:45:38PM +0300, Roger Quadros wrote: >>>> On 06/05/16 12:41, Peter Chen wrote: >>>>> On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote: >>>>>> The OTG core will use struct otg_hcd_ops to interface >>>>>> with the HCD controller. >>>>>> >>>>>> The main purpose of this interface is to avoid directly >>>>>> calling HCD APIs from the OTG core as they >>>>>> wouldn't be defined in the built-in symbol table if >>>>>> CONFIG_USB is m. >>>>>> >>>>>> Signed-off-by: Roger Quadros >>>>>> Acked-by: Peter Chen >>>>> >>>>> Roger, after thinking more, I still think current dependency between >>>>> OTG, HCD and gadget are too complicated. Since the OTG can't work >>>>> if it is built as module, I suggest letting OTG depends on HCD && >>>>> USB_GADGET, and it is a boolean, in that case, we don't need to >>>>> export any HCD and gadget ops, things will be much simpler. >>>>> What's your opinion? >>>> >>>> How will it work if HCD and USB_GADGET are modules and OTG is built-in? >>>> >>> >>> The OTG will not be compiled at this situation, since it is boolean. >>> In fact, like I mentioned at above, OTG or USB function can't work if >>> it is built as module. >> >> Isn't this a limitation? > > I agree, it should work built-in or module. > >> As per the current implementation dual role works fine even with both >> USB_GADGET and HCD as module. >> >> In the real world it is unlikely that GADGET and HCD will be built-in. > > we can't make this assumption, however :-) > Agreed, we need to make sure it works with all combinations. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface
On 10/05/16 11:03, Jun Li wrote:
> Hi
>
>> -Original Message-----
>> From: Roger Quadros [mailto:rog...@ti.com]
>> Sent: Tuesday, May 10, 2016 3:35 PM
>> To: Peter Chen
>> Cc: peter.c...@freescale.com; st...@rowland.harvard.edu; ba...@kernel.org;
>> gre...@linuxfoundation.org; dan.j.willi...@intel.com; jun...@freescale.com;
>> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
>> abres...@chromium.org; yoshihiro.shimoda...@renesas.com; linux-
>> u...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
>> o...@vger.kernel.org; devicet...@vger.kernel.org
>> Subject: Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface
>>
>> On 10/05/16 06:14, Peter Chen wrote:
>>> On Mon, May 09, 2016 at 12:45:38PM +0300, Roger Quadros wrote:
>>>> On 06/05/16 12:41, Peter Chen wrote:
>>>>> On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote:
>>>>>> The OTG core will use struct otg_hcd_ops to interface with the HCD
>>>>>> controller.
>>>>>>
>>>>>> The main purpose of this interface is to avoid directly calling HCD
>>>>>> APIs from the OTG core as they wouldn't be defined in the built-in
>>>>>> symbol table if CONFIG_USB is m.
>>>>>>
>>>>>> Signed-off-by: Roger Quadros
>>>>>> Acked-by: Peter Chen
>>>>>
>>>>> Roger, after thinking more, I still think current dependency between
>>>>> OTG, HCD and gadget are too complicated. Since the OTG can't work if
>>>>> it is built as module, I suggest letting OTG depends on HCD &&
>>>>> USB_GADGET, and it is a boolean, in that case, we don't need to
>>>>> export any HCD and gadget ops, things will be much simpler.
>>>>> What's your opinion?
>>>>
>>>> How will it work if HCD and USB_GADGET are modules and OTG is built-in?
>>>>
>>>
>>> The OTG will not be compiled at this situation, since it is boolean.
>>> In fact, like I mentioned at above, OTG or USB function can't work if
>>> it is built as module.
>>
>> Isn't this a limitation?
>> As per the current implementation dual role works fine even with both
>> USB_GADGET and HCD as module.
>
> My understand: only make sense for pass build, host can't work before
> gadget modules loaded; gadget can't work before hcd loaded, nothing
> can work before all drivers are loaded.
I can make OTG depend on GADGET and HCD, no issue with that.
But we can't get rid of the OTG to HCD/Gadged interfaces as we want things
to work with GADGET and HCD as modules.
>
>>
>> In the real world it is unlikely that GADGET and HCD will be built-in.
>
> Why? User enable USB_OTG means both drivers should be enabled anyway.
Enabled, but not necessarily built-in. Most distributions don't have them
as built-in.
But let's not argue in that direction. Let's say that they can be either
built-in or modules.
> Even in non-OTG case, both may be built-in for machine with 2 ports
> (one port is host only, the other one is peripheral only).
Sure. Every system designer is free to select the configuration.
>
> A general question, 2 drivers depends on each other, allowable?
I don't thing that's possible. Kconfig will complain.
http://lxr.free-electrons.com/source/Documentation/kbuild/kconfig-language.txt#L397
cheers,
-roger
>>>>>
>>>>>> ---
>>>>>> include/linux/usb/hcd.h | 24
>>>>>> 1 file changed, 24 insertions(+)
>>>>>>
>>>>>> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
>>>>>> index b98f831..861ccaa 100644
>>>>>> --- a/include/linux/usb/hcd.h
>>>>>> +++ b/include/linux/usb/hcd.h
>>>>>> @@ -399,6 +399,30 @@ struct hc_driver {
>>>>>>
>>>>>> };
>>>>>>
>>>>>> +/**
>>>>>> + * struct otg_hcd_ops - Interface between OTG core and HCD
>>>>>> + *
>>>>>> + * Provided by the HCD core to allow the OTG core to interface
>>>>>> +with the HCD
>>>>>> + *
>>>>>> + * @add: function to add the HCD
>>>>>> + * @remove: function to remove the HCD
>>>>>> + * @usb_bus_start_enum: function to immediately start bus
>>>>>> +enumeration
>>>>>> + * @usb_control_msg: function to
[PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT
TRM [1] recommends that POWERPRESENT bit must not be set and left at it's default value of 0. [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 Section 23.11.4.5.1 Mailbox VBUS/ID Management "Because PIPE powerpresent has a different meaning in host and in device mode, and because of the redundancy with the UTMI signals, the controller ORes together the appropriate PIPE and UTMI inputs to create its internal VBUS status. For that reason, it is recommended to leave field USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only to fill in the USB2 VBUS status fields in the same register." Signed-off-by: Roger Quadros --- drivers/usb/dwc3/dwc3-omap.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c index a30944d..1f7259d 100644 --- a/drivers/usb/dwc3/dwc3-omap.c +++ b/drivers/usb/dwc3/dwc3-omap.c @@ -234,8 +234,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *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_SESSVALID; dwc3_omap_write_utmi_ctrl(omap, val); break; @@ -244,8 +243,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap, val &= ~USBOTGSS_UTMI_OTG_CTRL_SESSEND; val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID - | USBOTGSS_UTMI_OTG_CTRL_SESSVALID - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT; + | USBOTGSS_UTMI_OTG_CTRL_SESSVALID; dwc3_omap_write_utmi_ctrl(omap, val); break; @@ -256,8 +254,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap, case OMAP_DWC3_VBUS_OFF: val = dwc3_omap_read_utmi_ctrl(omap); val &= ~(USBOTGSS_UTMI_OTG_CTRL_SESSVALID - | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT); + | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID); val |= USBOTGSS_UTMI_OTG_CTRL_SESSEND | USBOTGSS_UTMI_OTG_CTRL_IDDIG; dwc3_omap_write_utmi_ctrl(omap, val); -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 4/5] 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 | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c index 1f7259d..c40d301 100644 --- a/drivers/usb/dwc3/dwc3-omap.c +++ b/drivers/usb/dwc3/dwc3-omap.c @@ -231,18 +231,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; + 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; dwc3_omap_write_utmi_ctrl(omap, val); break; @@ -250,13 +246,15 @@ 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 = dwc3_omap_read_utmi_ctrl(omap); val &= ~(USBOTGSS_UTMI_OTG_CTRL_SESSVALID | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID); - val |= USBOTGSS_UTMI_OTG_CTRL_SESSEND - | USBOTGSS_UTMI_OTG_CTRL_IDDIG; + val |= USBOTGSS_UTMI_OTG_CTRL_SESSEND; dwc3_omap_write_utmi_ctrl(omap, val); break; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/5] dwc3: omap: fixes and dual-role preparation
Hi Felipe, I've removed the patches that add dual role support. These are just some fixes can go in before any actual dual role support. About the OTG software mailbox, I tried checking internally in TI but nobody was aware of any constraints. The events can be set as they are obtained from the PMIC OTG comparators. My gut feeling is that we didn't have VBUS and ID events working properly back then and so resulting in a hackish software OTG mailbox implementation. I tested this on OMAP5, DRA7 and didn't observe any regressions. Based on balbi/next commit 2a58f9c12bb360f38fb39e470bb5ff94014356e6. v7: - remove patches adding dual-role support. - split out shared irq conversion from threaded irq conversion patch. - added a new patch about not touching POWERPRESENT bit. v6: - use just otg irq to get otg events and don't depend on extcon at all. - follow OTG flow in TRM strictly. - use tracepoints instead of dev_dbg(). - match IRQ flags in dwc3_omap and core.c for shared otg interrupt. v5: Internal revision. Not sent to mailing list. v4: first version that was reviewed. cheers, -roger Roger Quadros (5): usb: dwc3: omap: use request_threaded_irq() usb: dwc3: omap: Mark the interrupt handler as shared usb: dwc3: omap: Don't set POWERPRESENT usb: dwc3: omap: Pass VBUS and ID events transparently usb: dwc3: core: cleanup IRQ resources drivers/usb/dwc3/core.c | 26 -- drivers/usb/dwc3/core.h | 5 + drivers/usb/dwc3/dwc3-omap.c | 33 + drivers/usb/dwc3/gadget.c| 19 ++- drivers/usb/dwc3/host.c | 19 +++ 5 files changed, 75 insertions(+), 27 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 5/5] usb: dwc3: core: cleanup IRQ resources
Implementations might use different IRQs for
host, gadget and OTG so use named interrupt resources
to allow Device tree to specify the 3 interrupts.
Following are the interrupt names
Peripheral Interrupt - peripheral
HOST Interrupt - host
OTG Interrupt - otg
We still maintain backward compatibility for a single named
interrupt for all 3 interrupts (e.g. for dwc3-pci) and
single unnamed interrupt for all 3 interrupts (e.g. old DT).
Signed-off-by: Roger Quadros
---
drivers/usb/dwc3/core.c | 26 --
drivers/usb/dwc3/core.h | 5 +
drivers/usb/dwc3/gadget.c | 19 ++-
drivers/usb/dwc3/host.c | 19 +++
4 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c050a88..5139003 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -729,6 +729,8 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
{
struct device *dev = dwc->dev;
int ret;
+ struct resource *res;
+ struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
@@ -748,6 +750,20 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
}
break;
case USB_DR_MODE_OTG:
+ dwc->otg_irq = platform_get_irq_byname(dwc3_pdev, "otg");
+ if (dwc->otg_irq <= 0) {
+ dwc->otg_irq = platform_get_irq_byname(dwc3_pdev,
+ "dwc_usb3");
+ if (dwc->otg_irq <= 0) {
+ res = platform_get_resource(dwc3_pdev,
+ IORESOURCE_IRQ, 0);
+ if (!res) {
+ dev_err(dwc->dev, "missing otg IRQ\n");
+ return -ENODEV;
+ }
+ dwc->otg_irq = res->start;
+ }
+ }
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
ret = dwc3_host_init(dwc);
if (ret) {
@@ -814,16 +830,6 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->mem = mem;
dwc->dev = dev;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(dev, "missing IRQ\n");
- return -ENODEV;
- }
- dwc->xhci_resources[1].start = res->start;
- dwc->xhci_resources[1].end = res->end;
- dwc->xhci_resources[1].flags = res->flags;
- dwc->xhci_resources[1].name = res->name;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "missing memory resource\n");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 186a886..2e20892 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -716,6 +716,8 @@ struct dwc3_scratchpad_array {
* @maximum_speed: maximum speed requested (mainly for testing purposes)
* @revision: revision register contents
* @dr_mode: requested mode of operation
+ * @gadget_irq: IRQ number for Peripheral IRQs
+ * @otg_irq: IRQ number for OTG IRQs
* @usb2_phy: pointer to USB2 PHY
* @usb3_phy: pointer to USB3 PHY
* @usb2_generic_phy: pointer to USB2 PHY
@@ -817,6 +819,9 @@ struct dwc3 {
enum usb_dr_modedr_mode;
+ int gadget_irq;
+ int otg_irq;
+
/* used for suspend/resume */
u32 dcfg;
u32 gctl;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c3b0d01..8db8d13 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1605,7 +1605,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
int irq;
u32 reg;
- irq = platform_get_irq(to_platform_device(dwc->dev), 0);
+ irq = dwc->gadget_irq;
ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
IRQF_SHARED, "dwc3", dwc->ev_buf);
if (ret) {
@@ -2781,6 +2781,23 @@ static irqreturn_t dwc3_interrupt(int irq, void *_evt)
int dwc3_gadget_init(struct dwc3 *dwc)
{
int ret;
+ struct resource *res;
+ struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
+
+ dwc->gadget_irq = platform_get_irq_byname(dwc3_pdev, "peripheral");
+ if (dwc->gadget_irq <= 0) {
+ dwc->gadget_irq = platform_get_irq_byname(dwc3_pdev,
+ "dwc_usb3");
+
[PATCH v7 1/5] usb: dwc3: omap: use request_threaded_irq()
We intend to share this interrupt with the OTG driver an to ensure
that irqflags match for the shared interrupt handlers we use
request_threaded_irq()
If we don't use request_treaded_irq() then forced threaded irq will
set IRQF_ONESHOT and this won't match with the OTG IRQ handler's
IRQ flags.
NOTE: OTG IRQ handler is yet to be added. This is a preparatory step.
Signed-off-by: Roger Quadros
---
drivers/usb/dwc3/dwc3-omap.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 59ea35f..6504e94 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -272,16 +272,22 @@ static irqreturn_t dwc3_omap_interrupt(int irq, void
*_omap)
{
struct dwc3_omap*omap = _omap;
u32 reg;
+ int ret = IRQ_NONE;
reg = dwc3_omap_read_irqmisc_status(omap);
+ if (reg)
+ ret = IRQ_HANDLED;
+
dwc3_omap_write_irqmisc_status(omap, reg);
reg = dwc3_omap_read_irq0_status(omap);
+ if (reg)
+ ret = IRQ_HANDLED;
dwc3_omap_write_irq0_status(omap, reg);
- return IRQ_HANDLED;
+ return ret;
}
static void dwc3_omap_enable_irqs(struct dwc3_omap *omap)
@@ -497,8 +503,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
/* check the DMA Status */
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
- ret = devm_request_irq(dev, omap->irq, dwc3_omap_interrupt, 0,
- "dwc3-omap", omap);
+ ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
+ NULL, 0, "dwc3-omap", omap);
if (ret) {
dev_err(dev, "failed to request IRQ #%d --> %d\n",
omap->irq, ret);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/5] usb: dwc3: omap: Mark the interrupt handler as shared
On OMAPs, OTG events come on the same IRQ so we need to share
this IRQ with the OTG device driver.
Signed-off-by: Roger Quadros
---
drivers/usb/dwc3/dwc3-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 6504e94..a30944d 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -504,7 +504,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
- NULL, 0, "dwc3-omap", omap);
+ NULL, IRQF_SHARED, "dwc3-omap", omap);
if (ret) {
dev_err(dev, "failed to request IRQ #%d --> %d\n",
omap->irq, ret);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT
On 10/05/16 12:54, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> TRM [1] recommends that POWERPRESENT bit must not be >> set and left at it's default value of 0. >> >> [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 >> Section 23.11.4.5.1 Mailbox VBUS/ID Management >> >> "Because PIPE powerpresent has a different meaning in host and in device >> mode, >> and because of the redundancy with the UTMI signals, the controller ORes >> together the appropriate PIPE and UTMI inputs to create its internal >> VBUS status. For that reason, it is recommended to leave field >> USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only >> to >> fill in the USB2 VBUS status fields in the same register." >> >> Signed-off-by: Roger Quadros > > to make sure we avoid regressions, do you mind sharing on which > platforms you tested this patch ? > I tested this on omap5-uevm and dra7-evm. My am437x board stopped working so couldn't test on that one. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/5] usb: dwc3: omap: Pass VBUS and ID events transparently
On 10/05/16 12:55, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> 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 > > I have a feeling this will regress OMAP5432 uEVM. Did you test with that > board ? > Yes. Any specific test case you would like me to test? For now I'm just doing enumeration with g_zero. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/5] usb: dwc3: omap: use request_threaded_irq()
On 10/05/16 12:58, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
>> We intend to share this interrupt with the OTG driver an to ensure
>> that irqflags match for the shared interrupt handlers we use
>> request_threaded_irq()
>>
>> If we don't use request_treaded_irq() then forced threaded irq will
>> set IRQF_ONESHOT and this won't match with the OTG IRQ handler's
>> IRQ flags.
>>
>> NOTE: OTG IRQ handler is yet to be added. This is a preparatory step.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/usb/dwc3/dwc3-omap.c | 12 +---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
>> index 59ea35f..6504e94 100644
>> --- a/drivers/usb/dwc3/dwc3-omap.c
>> +++ b/drivers/usb/dwc3/dwc3-omap.c
>> @@ -272,16 +272,22 @@ static irqreturn_t dwc3_omap_interrupt(int irq, void
>> *_omap)
>> {
>> struct dwc3_omap*omap = _omap;
>> u32 reg;
>> +int ret = IRQ_NONE;
>>
>> reg = dwc3_omap_read_irqmisc_status(omap);
>>
>> +if (reg)
>> +ret = IRQ_HANDLED;
>> +
>> dwc3_omap_write_irqmisc_status(omap, reg);
>>
>> reg = dwc3_omap_read_irq0_status(omap);
>> +if (reg)
>> +ret = IRQ_HANDLED;
>>
>> dwc3_omap_write_irq0_status(omap, reg);
>>
>> -return IRQ_HANDLED;
>> +return ret;
>> }
>>
>> static void dwc3_omap_enable_irqs(struct dwc3_omap *omap)
>> @@ -497,8 +503,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>> /* check the DMA Status */
>> reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
>>
>> -ret = devm_request_irq(dev, omap->irq, dwc3_omap_interrupt, 0,
>> -"dwc3-omap", omap);
>> +ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
>> +NULL, 0, "dwc3-omap", omap);
>
> if you're using threaded_irq, it's better to have a NULL top half and
> valid bottom half.
But in this case we don't need a bottom half as there is nothing to do :).
>
> In fact, since this will be shared, you could do a proper preparation
> and on top half check if $this device generated the IRQ and
> conditionally schedule the bottom half. Don't forget to mask device's
> interrupts from top half so you can run without IRQF_ONESHOT.
>
Why do this at all if there is nothing to do in the bottom half?
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/5] usb: dwc3: core: cleanup IRQ resources
On 10/05/16 13:03, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
>> Implementations might use different IRQs for
>> host, gadget and OTG so use named interrupt resources
>> to allow Device tree to specify the 3 interrupts.
>>
>> Following are the interrupt names
>>
>> Peripheral Interrupt - peripheral
>> HOST Interrupt - host
>> OTG Interrupt - otg
>>
>> We still maintain backward compatibility for a single named
>> interrupt for all 3 interrupts (e.g. for dwc3-pci) and
>> single unnamed interrupt for all 3 interrupts (e.g. old DT).
>
> cool :-)
>
>> @@ -748,6 +750,20 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>> }
>> break;
>> case USB_DR_MODE_OTG:
>> +dwc->otg_irq = platform_get_irq_byname(dwc3_pdev, "otg");
>> +if (dwc->otg_irq <= 0) {
>> +dwc->otg_irq = platform_get_irq_byname(dwc3_pdev,
>> + "dwc_usb3");
>> +if (dwc->otg_irq <= 0) {
>> +res = platform_get_resource(dwc3_pdev,
>> +IORESOURCE_IRQ, 0);
>> +if (!res) {
>> +dev_err(dwc->dev, "missing otg IRQ\n");
>> +return -ENODEV;
>> +}
>> +dwc->otg_irq = res->start;
>> +}
>> +}
>
> I suppose this part can be removed and added only when OTG is
> supported. Then dwc3_otg_init() (or whatever) can do this.
Sure.
>
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 186a886..2e20892 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -716,6 +716,8 @@ struct dwc3_scratchpad_array {
>> * @maximum_speed: maximum speed requested (mainly for testing purposes)
>> * @revision: revision register contents
>> * @dr_mode: requested mode of operation
>> + * @gadget_irq: IRQ number for Peripheral IRQs
>> + * @otg_irq: IRQ number for OTG IRQs
>> * @usb2_phy: pointer to USB2 PHY
>> * @usb3_phy: pointer to USB3 PHY
>> * @usb2_generic_phy: pointer to USB2 PHY
>> @@ -817,6 +819,9 @@ struct dwc3 {
>>
>> enum usb_dr_modedr_mode;
>>
>> +int gadget_irq;
>> +int otg_irq;
>
> while at that, let's add host_irq too and do proper changes to dwc3/host.c
Sure. So we add host_irq here, and manually create an irq resource
in dwc3_host_init?
>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index c3b0d01..8db8d13 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1605,7 +1605,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>> int irq;
>> u32 reg;
>>
>> -irq = platform_get_irq(to_platform_device(dwc->dev), 0);
>> +irq = dwc->gadget_irq;
>> ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
>> IRQF_SHARED, "dwc3", dwc->ev_buf);
>> if (ret) {
>> @@ -2781,6 +2781,23 @@ static irqreturn_t dwc3_interrupt(int irq, void *_evt)
>> int dwc3_gadget_init(struct dwc3 *dwc)
>> {
>> int ret;
>> +struct resource *res;
>> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>> +
>> +dwc->gadget_irq = platform_get_irq_byname(dwc3_pdev, "peripheral");
>> +if (dwc->gadget_irq <= 0) {
>> +dwc->gadget_irq = platform_get_irq_byname(dwc3_pdev,
>> + "dwc_usb3");
>> +if (dwc->gadget_irq <= 0) {
>> +res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
>> +0);
>> +if (!res) {
>> +dev_err(dwc->dev, "missing peripheral IRQ\n");
>> +return -ENODEV;
>> +}
>> +dwc->gadget_irq = res->start;
>> +}
>> +}
>>
>> dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
>> &dwc->ctrl_req_addr, GFP_KERNEL);
>
> you're regressing dwc3_gadget_stop().
>
ah, good catch.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/5] usb: dwc3: omap: Pass VBUS and ID events transparently
On 10/05/16 13:05, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> On 10/05/16 12:55, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Roger Quadros writes: >>>> 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 >>> >>> I have a feeling this will regress OMAP5432 uEVM. Did you test with that >>> board ? >>> >> >> Yes. Any specific test case you would like me to test? >> For now I'm just doing enumeration with g_zero. > > IIRC OMAP5 uEVM didn't have separate VBUS and ID GPIOs. How are you > handling that case ? > It comes from the PMIC, extcon-palmas.c. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/5] usb: dwc3: omap: use request_threaded_irq()
On 10/05/16 13:12, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
>>>> @@ -497,8 +503,8 @@ static int dwc3_omap_probe(struct platform_device
>>>> *pdev)
>>>>/* check the DMA Status */
>>>>reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
>>>>
>>>> - ret = devm_request_irq(dev, omap->irq, dwc3_omap_interrupt, 0,
>>>> - "dwc3-omap", omap);
>>>> + ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
>>>> + NULL, 0, "dwc3-omap", omap);
>>>
>>> if you're using threaded_irq, it's better to have a NULL top half and
>>> valid bottom half.
>>
>> But in this case we don't need a bottom half as there is nothing to do :).
>>
>>>
>>> In fact, since this will be shared, you could do a proper preparation
>>> and on top half check if $this device generated the IRQ and
>>> conditionally schedule the bottom half. Don't forget to mask device's
>>> interrupts from top half so you can run without IRQF_ONESHOT.
>>>
>>
>> Why do this at all if there is nothing to do in the bottom half?
>
> oh, but there is :-)
>
> The whole idea of threaded IRQs is that you spend as little time as
> possible on top half and the (strong) recommendation is that you *only*
> check if $this device generated the interrupt. Note that "checking if
> $this device generated the interrupt" will be mandatory as soon as you
> mark the IRQ line as shared ;-)
>
> So here's how this should look like:
>
> static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
> {
> struct dwc3_omap *omap = _omap;
> u32 reg;
>
> reg = readl(IRQSTATUS)
> if (reg) {
> mask_interrupts(omap);
> return IRQ_WAKE_THREAD;
> }
>
> return IRQ_HANDLED;
> }
>
> static irqreturn_t dwc3_omap_threaded_interrupt(int irq, void *_omap)
> {
> struct dwc3_omap *omap = _omap;
> u32 reg;
>
> spin_lock(&omap->lock);
> reg = readl(IRQSTATUS);
>
> if (reg & BIT0)
> handle_bit_0(omap);
>
> if (reg & BIT1)
> handle_bit_1(omap);
>
> unmask_interrupts(omap);
> spin_unlock(&omap->lock);
>
> return IRQ_HANDLED;
> }
>
> this will *always* behave well with RT and non-RT kernels. It also
> allows for the user to change priorities on these interrupt handlers if
> necessary.
>
No problem, I can implement a bottom half. We are not handling anything
there at the moment so it is a bit of an overkill :)
It might help in the future if someone wants to handle something.
cheers,
-roge
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT
On 10/05/16 13:04, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> On 10/05/16 12:54, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Roger Quadros writes: >>>> TRM [1] recommends that POWERPRESENT bit must not be >>>> set and left at it's default value of 0. >>>> >>>> [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 >>>> Section 23.11.4.5.1 Mailbox VBUS/ID Management >>>> >>>> "Because PIPE powerpresent has a different meaning in host and in device >>>> mode, >>>> and because of the redundancy with the UTMI signals, the controller ORes >>>> together the appropriate PIPE and UTMI inputs to create its internal >>>> VBUS status. For that reason, it is recommended to leave field >>>> USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and >>>> only to >>>> fill in the USB2 VBUS status fields in the same register." >>>> >>>> Signed-off-by: Roger Quadros >>> >>> to make sure we avoid regressions, do you mind sharing on which >>> platforms you tested this patch ? >>> >> I tested this on omap5-uevm and dra7-evm. >> My am437x board stopped working so couldn't test on that one. > > would you have a colleague or perhaps an automated test-farm which could > run the test for you ? :-) > > I can take the patch, no problem, but if there are any regressions don't > blame me :-) > Don't worry, blame is on the TRM then :). cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT
On 10/05/16 13:04, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> On 10/05/16 12:54, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Roger Quadros writes: >>>> TRM [1] recommends that POWERPRESENT bit must not be >>>> set and left at it's default value of 0. >>>> >>>> [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 >>>> Section 23.11.4.5.1 Mailbox VBUS/ID Management >>>> >>>> "Because PIPE powerpresent has a different meaning in host and in device >>>> mode, >>>> and because of the redundancy with the UTMI signals, the controller ORes >>>> together the appropriate PIPE and UTMI inputs to create its internal >>>> VBUS status. For that reason, it is recommended to leave field >>>> USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and >>>> only to >>>> fill in the USB2 VBUS status fields in the same register." >>>> >>>> Signed-off-by: Roger Quadros >>> >>> to make sure we avoid regressions, do you mind sharing on which >>> platforms you tested this patch ? >>> >> I tested this on omap5-uevm and dra7-evm. >> My am437x board stopped working so couldn't test on that one. > > would you have a colleague or perhaps an automated test-farm which could > run the test for you ? :-) Bin, do you mind testing this and giving your blessings please? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/5] usb: dwc3: core: cleanup IRQ resources
On 10/05/16 13:14, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
>>>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>>>> index 186a886..2e20892 100644
>>>> --- a/drivers/usb/dwc3/core.h
>>>> +++ b/drivers/usb/dwc3/core.h
>>>> @@ -716,6 +716,8 @@ struct dwc3_scratchpad_array {
>>>> * @maximum_speed: maximum speed requested (mainly for testing purposes)
>>>> * @revision: revision register contents
>>>> * @dr_mode: requested mode of operation
>>>> + * @gadget_irq: IRQ number for Peripheral IRQs
>>>> + * @otg_irq: IRQ number for OTG IRQs
>>>> * @usb2_phy: pointer to USB2 PHY
>>>> * @usb3_phy: pointer to USB3 PHY
>>>> * @usb2_generic_phy: pointer to USB2 PHY
>>>> @@ -817,6 +819,9 @@ struct dwc3 {
>>>>
>>>>enum usb_dr_modedr_mode;
>>>>
>>>> + int gadget_irq;
>>>> + int otg_irq;
>>>
>>> while at that, let's add host_irq too and do proper changes to dwc3/host.c
>>
>> Sure. So we add host_irq here, and manually create an irq resource
>> in dwc3_host_init?
>
> right :-) Then the code looks similar for otg, peripheral and host parts ;-)
>
Just saw that host_irq is not used anywhere other than creating the XHCI
platform
device. So I don't see why we need host_irq in struct dwc3.
It is obtained in dwc3_host_init() and consumed there itself.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/5] usb: dwc3: omap: use request_threaded_irq()
Felipe,
On 10/05/16 13:12, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
>>>> @@ -497,8 +503,8 @@ static int dwc3_omap_probe(struct platform_device
>>>> *pdev)
>>>>/* check the DMA Status */
>>>>reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
>>>>
>>>> - ret = devm_request_irq(dev, omap->irq, dwc3_omap_interrupt, 0,
>>>> - "dwc3-omap", omap);
>>>> + ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
>>>> + NULL, 0, "dwc3-omap", omap);
>>>
>>> if you're using threaded_irq, it's better to have a NULL top half and
>>> valid bottom half.
>>
>> But in this case we don't need a bottom half as there is nothing to do :).
>>
>>>
>>> In fact, since this will be shared, you could do a proper preparation
>>> and on top half check if $this device generated the IRQ and
>>> conditionally schedule the bottom half. Don't forget to mask device's
>>> interrupts from top half so you can run without IRQF_ONESHOT.
>>>
>>
>> Why do this at all if there is nothing to do in the bottom half?
>
> oh, but there is :-)
>
> The whole idea of threaded IRQs is that you spend as little time as
> possible on top half and the (strong) recommendation is that you *only*
> check if $this device generated the interrupt. Note that "checking if
> $this device generated the interrupt" will be mandatory as soon as you
> mark the IRQ line as shared ;-)
>
> So here's how this should look like:
>
> static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
> {
> struct dwc3_omap *omap = _omap;
> u32 reg;
>
> reg = readl(IRQSTATUS)
> if (reg) {
> mask_interrupts(omap);
> return IRQ_WAKE_THREAD;
> }
>
> return IRQ_HANDLED;
This should be IRQ_NONE right?
> }
>
> static irqreturn_t dwc3_omap_threaded_interrupt(int irq, void *_omap)
> {
> struct dwc3_omap *omap = _omap;
> u32 reg;
>
> spin_lock(&omap->lock);
Do we really need a spin_lock for the dwc3-omap driver?
Currently we won't be doing anything other than just
clearing the irqstatus and re-enabling the interrupts.
> reg = readl(IRQSTATUS);
>
> if (reg & BIT0)
> handle_bit_0(omap);
>
> if (reg & BIT1)
> handle_bit_1(omap);
>
> unmask_interrupts(omap);
> spin_unlock(&omap->lock);
>
> return IRQ_HANDLED;
> }
>
> this will *always* behave well with RT and non-RT kernels. It also
> allows for the user to change priorities on these interrupt handlers if
> necessary.
>
--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/14] usb: otg-fsm: move host controller operations into usb_otg->hcd_ops
On 11/05/16 09:10, Peter Chen wrote:
> On Mon, May 02, 2016 at 03:18:48PM +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/chipidea/otg_fsm.c | 7 +++
>> drivers/usb/common/usb-otg-fsm.c | 15 +++
>> drivers/usb/phy/phy-fsl-usb.c| 7 +++
>> include/linux/usb/otg.h | 2 ++
>> 4 files changed, 27 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
>> index 1c0c750..2d8d659 100644
>> --- a/drivers/usb/chipidea/otg_fsm.c
>> +++ b/drivers/usb/chipidea/otg_fsm.c
>> @@ -582,6 +582,12 @@ static struct otg_fsm_ops ci_otg_ops = {
>> .start_gadget = ci_otg_start_gadget,
>> };
>>
>> +static struct otg_hcd_ops ci_hcd_ops = {
>> +.usb_bus_start_enum = usb_bus_start_enum,
>> +.usb_control_msg = usb_control_msg,
>> +.usb_hub_find_child = usb_hub_find_child,
>> +};
>> +
>
> Is it possible have default otg_hcd_ops during OTG register to
> avoid define it at every dual-role driver?
Yes, I'll do that.
cheers,
-roger
>> int ci_otg_fsm_work(struct ci_hdrc *ci)
>> {
>> /*
>> @@ -804,6 +810,7 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
>> ci->otg.fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
>> ci->otg.state = OTG_STATE_UNDEFINED;
>> ci->otg.fsm.ops = &ci_otg_ops;
>> +ci->otg.hcd_ops = &ci_hcd_ops;
>> ci->gadget.hnp_polling_support = 1;
>> ci->otg.fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
>> if (!ci->otg.fsm.host_req_flag)
>> diff --git a/drivers/usb/common/usb-otg-fsm.c
>> b/drivers/usb/common/usb-otg-fsm.c
>> index 4bfc6a5..2986b66 100644
>> --- a/drivers/usb/common/usb-otg-fsm.c
>> +++ b/drivers/usb/common/usb-otg-fsm.c
>> @@ -141,11 +141,16 @@ static void otg_hnp_polling_work(struct work_struct
>> *work)
>> enum usb_otg_state state = otg->state;
>> u8 flag;
>> int retval;
>> +struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
>>
>> if (state != OTG_STATE_A_HOST && state != OTG_STATE_B_HOST)
>> return;
>>
>> -udev = usb_hub_find_child(otg->host->root_hub, 1);
>> +if (!hcd_ops || !hcd_ops->usb_control_msg ||
>> +!hcd_ops->usb_hub_find_child)
>> +return;
>> +
>> +udev = hcd_ops->usb_hub_find_child(otg->host->root_hub, 1);
>> if (!udev) {
>> dev_err(otg->host->controller,
>> "no usb dev connected, can't start HNP polling\n");
>> @@ -154,7 +159,7 @@ static void otg_hnp_polling_work(struct work_struct
>> *work)
>>
>> *fsm->host_req_flag = 0;
>> /* Get host request flag from connected USB device */
>> -retval = usb_control_msg(udev,
>> +retval = hcd_ops->usb_control_msg(udev,
>> usb_rcvctrlpipe(udev, 0),
>> USB_REQ_GET_STATUS,
>> USB_DIR_IN | USB_RECIP_DEVICE,
>> @@ -183,7 +188,7 @@ static void otg_hnp_polling_work(struct work_struct
>> *work)
>> if (state == OTG_STATE_A_HOST) {
>> /* Set b_hnp_enable */
>> if (!otg->host->b_hnp_enable) {
>> -retval = usb_control_msg(udev,
>> +retval = hcd_ops->usb_control_msg(udev,
>> usb_sndctrlpipe(udev, 0),
>> USB_REQ_SET_FEATURE, 0,
>> USB_DEVICE_B_HNP_ENABLE,
>> @@ -262,7 +267,9 @@ static int otg_set_state(struct otg_fsm *fsm, enum
>> usb_otg_state new_state)
>> otg_loc_conn(otg, 0);
>> otg_loc_sof(otg, 1);
>> otg_set_protocol(fsm, PROTO_HOST);
>> -usb_bus_start_enum(otg->host, otg->host->otg_port);
>> +if (otg->hcd_ops && otg->hcd_ops->usb_bus_start_enum)
>> +otg->hcd_ops->usb_bus_start_enum(otg->host,
>> + otg->host->otg_port);
>> otg_start_hnp_polling(fsm);
>> break;
>> case OTG_STATE_A_IDLE:
>> diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/
Re: [PATCH v7 08/14] usb: otg: add OTG/dual-role core
On 11/05/16 11:34, Peter Chen wrote:
> On Mon, May 02, 2016 at 03:18:51PM +0300, Roger Quadros wrote:
>> +
>> +if (config->otg_work) /* custom otg_work ? */
>> +INIT_WORK(&otg->work, config->otg_work);
>> +else
>> +INIT_WORK(&otg->work, usb_drd_work);
>> +
>> +otg->wq = create_singlethread_workqueue("usb_otg");
>
> Using create_freezable_workqueue like I suggested before.
Sorry that I missed this part. I'll fix it in v8.
>
>> + */
>> +
>> +#ifndef __DRIVERS_USB_COMMON_USB_OTG_H
>> +#define __DRIVERS_USB_COMMON_USB_OTG_H
>> +
>> +/*
>> + * A-DEVICE timing constants
>> + */
>> +
>> +/* Wait for VBUS Rise */
>> +#define TA_WAIT_VRISE(100) /* a_wait_vrise: section 7.1.2
>> + * a_wait_vrise_tmr: section 7.4.5.1
>> + * TA_VBUS_RISE <= 100ms, section 4.4
>> + * Table 4-1: Electrical Characteristics
>> + * ->DC Electrical Timing
>> + */
>> +/* Wait for VBUS Fall */
>> +#define TA_WAIT_VFALL(1000) /* a_wait_vfall: section 7.1.7
>> + * a_wait_vfall_tmr: section: 7.4.5.2
>> + */
>> +/* Wait for B-Connect */
>> +#define TA_WAIT_BCON (1)/* a_wait_bcon: section 7.1.3
>> + * TA_WAIT_BCON: should be between 1100
>> + * and 3 ms, section 5.5, Table 5-1
>> + */
>> +/* A-Idle to B-Disconnect */
>> +#define TA_AIDL_BDIS (5000) /* a_suspend min 200 ms, section 5.2.1
>> + * TA_AIDL_BDIS: section 5.5, Table 5-1
>> + */
>> +/* B-Idle to A-Disconnect */
>> +#define TA_BIDL_ADIS (500) /* TA_BIDL_ADIS: section 5.2.1
>> + * 500ms is used for B switch to host
>> + * for safe
>> + */
>> +
>> +/*
>> + * B-device timing constants
>> + */
>> +
>> +/* Data-Line Pulse Time*/
>> +#define TB_DATA_PLS (10) /* b_srp_init,continue 5~10ms
>> + * section:5.1.3
>> + */
>> +/* SRP Fail Time */
>> +#define TB_SRP_FAIL (6000) /* b_srp_init,fail time 5~6s
>> + * section:5.1.6
>> + */
>> +/* A-SE0 to B-Reset */
>> +#define TB_ASE0_BRST (155) /* minimum 155 ms, section:5.3.1 */
>> +/* SE0 Time Before SRP */
>> +#define TB_SE0_SRP (1000) /* b_idle,minimum 1s, section:5.1.2 */
>> +/* SSEND time before SRP */
>> +#define TB_SSEND_SRP (1500) /* minimum 1.5 sec, section:5.1.2 */
>> +
>> +#define TB_SESS_VLD (1000)
>
> Seems you agree to remove above definitions.
My bad, sorry.
>
>>
>> /* Current usb protocol used: 0:undefine; 1:host; 2:client */
>> diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
>> index 85b8fb5..b094352 100644
>> --- a/include/linux/usb/otg.h
>> +++ b/include/linux/usb/otg.h
>> @@ -10,10 +10,55 @@
>> #define __LINUX_USB_OTG_H
>>
>> #include
>> -#include
>> -#include
>> +#include
>> +#include
>> +#include
>
> Above two headers are not needed
>
OK.
--
cheers
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 09/14] usb: of: add an API to get OTG device from USB controller node
On 11/05/16 11:40, Peter Chen wrote:
> On Mon, May 02, 2016 at 03:18:52PM +0300, Roger Quadros wrote:
>> The OTG controller and the USB controller an be linked via the
>
> Typo?
Will fix.
cheers,
-roger
>
> Others are ok for me.
>
> Acked-by: Peter Chen
>
>> 'otg-controller' property in the USB controller's device node.
>>
>> of_usb_get_otg() can be used to get the OTG controller device
>> from the USB controller's device node.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> Documentation/devicetree/bindings/usb/generic.txt | 3 +++
>> drivers/usb/common/common.c | 27
>> +++
>> include/linux/usb/of.h| 9
>> 3 files changed, 39 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/generic.txt
>> b/Documentation/devicetree/bindings/usb/generic.txt
>> index bba8257..f6866c1 100644
>> --- a/Documentation/devicetree/bindings/usb/generic.txt
>> +++ b/Documentation/devicetree/bindings/usb/generic.txt
>> @@ -24,6 +24,9 @@ Optional properties:
>> optional for OTG device.
>> - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
>> optional for OTG device.
>> + - otg-controller: phandle to otg controller. Host or gadget controllers can
>> +contain this property to link it to a particular OTG
>> +controller.
>>
>> This is an attribute to a USB controller such as:
>>
>> diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
>> index e3d0161..d7ec471 100644
>> --- a/drivers/usb/common/common.c
>> +++ b/drivers/usb/common/common.c
>> @@ -238,6 +238,33 @@ int of_usb_update_otg_caps(struct device_node *np,
>> }
>> EXPORT_SYMBOL_GPL(of_usb_update_otg_caps);
>>
>> +#ifdef CONFIG_USB_OTG
>> +/**
>> + * of_usb_get_otg - get the OTG controller linked to the USB controller
>> + * @np: Pointer to the device_node of the USB controller
>> + * @otg_caps: Pointer to the target usb_otg_caps to be set
>> + *
>> + * Returns the OTG controller device or NULL on error.
>> + */
>> +struct device *of_usb_get_otg(struct device_node *np)
>> +{
>> +struct device_node *otg_np;
>> +struct platform_device *pdev;
>> +
>> +otg_np = of_parse_phandle(np, "otg-controller", 0);
>> +if (!otg_np)
>> +return NULL;
>> +
>> +pdev = of_find_device_by_node(otg_np);
>> +of_node_put(otg_np);
>> +if (!pdev)
>> +return NULL;
>> +
>> +return &pdev->dev;
>> +}
>> +EXPORT_SYMBOL_GPL(of_usb_get_otg);
>> +#endif
>> +
>> #endif
>>
>> MODULE_LICENSE("GPL");
>> diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
>> index de3237f..499a4e8 100644
>> --- a/include/linux/usb/of.h
>> +++ b/include/linux/usb/of.h
>> @@ -40,6 +40,15 @@ static inline struct device_node *usb_of_get_child_node
>> }
>> #endif
>>
>> +#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_OTG)
>> +struct device *of_usb_get_otg(struct device_node *np);
>> +#else
>> +static inline struct device *of_usb_get_otg(struct device_node *np)
>> +{
>> +return NULL;
>> +}
>> +#endif
>> +
>> #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
>> enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
>> #else
>> --
>> 2.7.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/14] USB OTG/dual-role framework
On 11/05/16 11:36, Peter Chen wrote:
> On Mon, May 02, 2016 at 03:18:43PM +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 v4.6-rc1 and depends on first 2 patches of [1]
>> [1] - OTG fsm cleanup - https://lkml.org/lkml/2016/3/30/186
>>
>> Why?:
>>
>>
>> Currently there is no central location where OTG/dual-role functionality is
>> implemented in the Linux USB stack and every USB controller driver is
>> doing their own thing for OTG/dual-role. We can benefit from code-reuse
>> and simplicity by adding the OTG/dual-role core driver.
>>
>> 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 controllers in dual-role mode. i.e. to stop and start them
>> from a central location. This central location should be the
>> USB OTG/dual-role 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 couldn't be done till now but can be done from the OTG core.
>>
>> What?:
>> -
>>
>> The OTG/dual-role core consists of a set of APIs that allow
>> registration of OTG controller device and OTG capable host and gadget
>> controllers.
>>
>> - The OTG controller driver can provide the OTG capabilities and the
>> Finite State Machine work function via 'struct usb_otg_config'
>> at the time of registration i.e. usb_otg_register();
>>
>> struct usb_otg *usb_otg_register(struct device *dev,
>> struct usb_otg_config *config);
>> int usb_otg_unregister(struct device *dev);
>> /**
>> * struct usb_otg_config - otg controller configuration
>> * @caps: otg capabilities of the controller
>> * @ops: otg fsm operations
>> * @otg_work: optional custom otg state machine work function
>> */
>> struct usb_otg_config {
>> struct usb_otg_caps *otg_caps;
>> struct otg_fsm_ops *fsm_ops;
>> void (*otg_work)(struct work_struct *work);
>> };
>>
>> The dual-role state machine is built-into the OTG core so nothing
>> special needs to be provided if only dual-role functionality is desired.
>> The low level OTG controller driver ops are povided via
>> 'struct otg_fsm_ops *fsm_ops' in the 'struct usb_otg_config'.
>>
>> After registration, the OTG core waits for host, gadget controller
>> and the gadget function driver to be registered. Once all resources are
>> available it instantiates the Finite State Machine (FSM).
>> The host/gadget controllers are started/stopped according to the FSM.
>>
>> - Host and gadget controllers that are a part of OTG/dual-role port must
>> use the OTG core provided APIs to add/remove the host/gadget.
>> i.e. hosts must use usb_otg_add_hcd() usb_otg_remove_hcd(),,
>> gadgets must use usb_otg_add_gadget_udc() usb_del_gadget_udc().
>> This ensures that the host and gadget controllers are not started till
>> the state machine is ready and the right bus conditions are met.
>> It also allows the host and gadget controllers to provide the OTG
>> controller device to link them together. For Device tree boots
>> the related OTG controller is automatically picked up via the
>> 'otg-controller' property in the Host/Gadget controller nodes.
>>
>> int usb_otg_add_hcd(struct usb_hcd *hcd,
>> unsigned int irqnum, unsigned long irqflags,
>> struct device *otg_dev);
>> void usb_otg_remove_hcd(struct usb_hcd *hcd);
>>
>> int usb_otg_add_gadget_udc(struct device *parent,
>> struct usb_gadget *gadget,
>> struct device *otg_dev);
>> usb_del_gadget_udc() must be used for removal.
>>
>>
>> - During the lifetime of the FSM, the OTG controller driver can provide
>> inputs event changes using usb_otg_sync_inputs(). The OTG core will
>> then schedule the FSM work function (or internal dual-role state machine)
>> to update the FSM state. The FSM then calls t
Re: [PATCH v7 1/5] usb: dwc3: omap: use request_threaded_irq()
On 11/05/16 12:47, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
>>> Roger Quadros writes:
>>>>>> @@ -497,8 +503,8 @@ static int dwc3_omap_probe(struct platform_device
>>>>>> *pdev)
>>>>>> /* check the DMA Status */
>>>>>> reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
>>>>>>
>>>>>> -ret = devm_request_irq(dev, omap->irq, dwc3_omap_interrupt, 0,
>>>>>> -"dwc3-omap", omap);
>>>>>> +ret = devm_request_threaded_irq(dev, omap->irq,
>>>>>> dwc3_omap_interrupt,
>>>>>> +NULL, 0, "dwc3-omap", omap);
>>>>>
>>>>> if you're using threaded_irq, it's better to have a NULL top half and
>>>>> valid bottom half.
>>>>
>>>> But in this case we don't need a bottom half as there is nothing to do :).
>>>>
>>>>>
>>>>> In fact, since this will be shared, you could do a proper preparation
>>>>> and on top half check if $this device generated the IRQ and
>>>>> conditionally schedule the bottom half. Don't forget to mask device's
>>>>> interrupts from top half so you can run without IRQF_ONESHOT.
>>>>>
>>>>
>>>> Why do this at all if there is nothing to do in the bottom half?
>>>
>>> oh, but there is :-)
>>>
>>> The whole idea of threaded IRQs is that you spend as little time as
>>> possible on top half and the (strong) recommendation is that you *only*
>>> check if $this device generated the interrupt. Note that "checking if
>>> $this device generated the interrupt" will be mandatory as soon as you
>>> mark the IRQ line as shared ;-)
>>>
>>> So here's how this should look like:
>>>
>>> static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
>>> {
>>> struct dwc3_omap *omap = _omap;
>>> u32 reg;
>>>
>>> reg = readl(IRQSTATUS)
>>> if (reg) {
>>> mask_interrupts(omap);
>>> return IRQ_WAKE_THREAD;
>>> }
>>>
>>> return IRQ_HANDLED;
>>
>> This should be IRQ_NONE right?
>
> possibly, testing will say ;-)
>
>>> static irqreturn_t dwc3_omap_threaded_interrupt(int irq, void *_omap)
>>> {
>>> struct dwc3_omap *omap = _omap;
>>> u32 reg;
>>>
>>> spin_lock(&omap->lock);
>>
>> Do we really need a spin_lock for the dwc3-omap driver?
>> Currently we won't be doing anything other than just
>> clearing the irqstatus and re-enabling the interrupts.
>
> well, if there's no possibility of races, then no. But only testing will
> say for sure, I guess. I didn't really go through the entire thing just
> to a write a quick little template :-p
>
OK. Another hurdle I have is that how do I mask/unmask the interrupts?
I do not see any masking bits, only enable/disable bits.
I don't think we can use the enable/disable bits to mask as we'd loose
events while the event is disabled.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/14] usb: otg-fsm: move host controller operations into usb_otg->hcd_ops
Peter,
On 11/05/16 14:02, Roger Quadros wrote:
> On 11/05/16 09:10, Peter Chen wrote:
>> On Mon, May 02, 2016 at 03:18:48PM +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/chipidea/otg_fsm.c | 7 +++
>>> drivers/usb/common/usb-otg-fsm.c | 15 +++
>>> drivers/usb/phy/phy-fsl-usb.c| 7 +++
>>> include/linux/usb/otg.h | 2 ++
>>> 4 files changed, 27 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
>>> index 1c0c750..2d8d659 100644
>>> --- a/drivers/usb/chipidea/otg_fsm.c
>>> +++ b/drivers/usb/chipidea/otg_fsm.c
>>> @@ -582,6 +582,12 @@ static struct otg_fsm_ops ci_otg_ops = {
>>> .start_gadget = ci_otg_start_gadget,
>>> };
>>>
>>> +static struct otg_hcd_ops ci_hcd_ops = {
>>> + .usb_bus_start_enum = usb_bus_start_enum,
>>> + .usb_control_msg = usb_control_msg,
>>> + .usb_hub_find_child = usb_hub_find_child,
>>> +};
>>> +
>>
>> Is it possible have default otg_hcd_ops during OTG register to
>> avoid define it at every dual-role driver?
>
> Yes, I'll do that.
Every OTG driver doesn't need to do this as this is provided by
hcd.c during usb_otg_add_hcd().
So proper fix is that chipidea driver must use usb_otg_add_hcd().
cheers,
-roger
>
>>> int ci_otg_fsm_work(struct ci_hdrc *ci)
>>> {
>>> /*
>>> @@ -804,6 +810,7 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
>>> ci->otg.fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
>>> ci->otg.state = OTG_STATE_UNDEFINED;
>>> ci->otg.fsm.ops = &ci_otg_ops;
>>> + ci->otg.hcd_ops = &ci_hcd_ops;
>>> ci->gadget.hnp_polling_support = 1;
>>> ci->otg.fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
>>> if (!ci->otg.fsm.host_req_flag)
>>> diff --git a/drivers/usb/common/usb-otg-fsm.c
>>> b/drivers/usb/common/usb-otg-fsm.c
>>> index 4bfc6a5..2986b66 100644
>>> --- a/drivers/usb/common/usb-otg-fsm.c
>>> +++ b/drivers/usb/common/usb-otg-fsm.c
>>> @@ -141,11 +141,16 @@ static void otg_hnp_polling_work(struct work_struct
>>> *work)
>>> enum usb_otg_state state = otg->state;
>>> u8 flag;
>>> int retval;
>>> + struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
>>>
>>> if (state != OTG_STATE_A_HOST && state != OTG_STATE_B_HOST)
>>> return;
>>>
>>> - udev = usb_hub_find_child(otg->host->root_hub, 1);
>>> + if (!hcd_ops || !hcd_ops->usb_control_msg ||
>>> + !hcd_ops->usb_hub_find_child)
>>> + return;
>>> +
>>> + udev = hcd_ops->usb_hub_find_child(otg->host->root_hub, 1);
>>> if (!udev) {
>>> dev_err(otg->host->controller,
>>> "no usb dev connected, can't start HNP polling\n");
>>> @@ -154,7 +159,7 @@ static void otg_hnp_polling_work(struct work_struct
>>> *work)
>>>
>>> *fsm->host_req_flag = 0;
>>> /* Get host request flag from connected USB device */
>>> - retval = usb_control_msg(udev,
>>> + retval = hcd_ops->usb_control_msg(udev,
>>> usb_rcvctrlpipe(udev, 0),
>>> USB_REQ_GET_STATUS,
>>> USB_DIR_IN | USB_RECIP_DEVICE,
>>> @@ -183,7 +188,7 @@ static void otg_hnp_polling_work(struct work_struct
>>> *work)
>>> if (state == OTG_STATE_A_HOST) {
>>> /* Set b_hnp_enable */
>>> if (!otg->host->b_hnp_enable) {
>>> - retval = usb_control_msg(udev,
>>> + retval = hcd_ops->usb_control_msg(udev,
>>> usb_sndctrlpipe(udev, 0),
>>> USB_REQ_SET_FEATURE, 0,
>>> USB_DEVICE_B_HNP_ENABLE,
>>> @@ -262,7 +267,9 @@ static int otg_set_state(struct otg_fsm *fsm, enum
>>> usb_otg_state new_state)
>>> otg_loc_conn(otg, 0);
>>> otg_loc_sof(otg, 1);
>>> otg_
Re: [PATCH v7 1/5] usb: dwc3: omap: use request_threaded_irq()
On 11/05/16 15:39, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
>>>>> static irqreturn_t dwc3_omap_threaded_interrupt(int irq, void *_omap)
>>>>> {
>>>>> struct dwc3_omap *omap = _omap;
>>>>> u32 reg;
>>>>>
>>>>> spin_lock(&omap->lock);
>>>>
>>>> Do we really need a spin_lock for the dwc3-omap driver?
>>>> Currently we won't be doing anything other than just
>>>> clearing the irqstatus and re-enabling the interrupts.
>>>
>>> well, if there's no possibility of races, then no. But only testing will
>>> say for sure, I guess. I didn't really go through the entire thing just
>>> to a write a quick little template :-p
>>>
>> OK. Another hurdle I have is that how do I mask/unmask the interrupts?
>> I do not see any masking bits, only enable/disable bits.
>>
>> I don't think we can use the enable/disable bits to mask as we'd loose
>> events while the event is disabled.
>
> I'm pretty sure your TRM discusses the usage of IRQSTATUS_RAW*
> registers, doesn't it ? :-)
It does and also says that it is mostly for debug. But I don't mind using it
if it solves our problem :).
>
> Those registers should be modified by HW even when interrupts are
> disabled/masked. Note that, the IRQSTATUS_SET* and IRQSTATUS_CLR*
> registers act more like mask/unmask than enable/disable considering we
> can still read IRQ status using *RAW* registers.
>
> See if below works fine for OMAP5, AM4 and AM5 SoCs:
>
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index af264493bbae..ece2f25ad2c3 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -165,20 +165,20 @@ static void dwc3_omap_write_utmi_ctrl(struct dwc3_omap
> *omap, u32 value)
>
> static u32 dwc3_omap_read_irq0_status(struct dwc3_omap *omap)
> {
> - return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_0 -
> + return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_RAW_0 -
> omap->irq0_offset);
> }
>
> static void dwc3_omap_write_irq0_status(struct dwc3_omap *omap, u32 value)
> {
> - dwc3_omap_writel(omap->base, USBOTGSS_IRQSTATUS_0 -
> + dwc3_omap_writel(omap->base, USBOTGSS_IRQSTATUS_RAW_0 -
> omap->irq0_offset, value);
We shouldn't write to RAW here as it will trigger a software IRQ instead of
clearing the event.
>
> }
>
> static u32 dwc3_omap_read_irqmisc_status(struct dwc3_omap *omap)
> {
> - return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_MISC +
> + return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_RAW_MISC +
> omap->irqmisc_offset);
> }
>
>
The rest is fine. It seemed to work on omap5. I'll do more tests though.
Thanks for the hint :)
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 10/14] usb: otg: add hcd companion support
On 11/05/16 16:54, Rob Herring wrote: > On Wed, May 04, 2016 at 04:47:18PM +0300, Roger Quadros wrote: >> On 04/05/16 16:17, Rob Herring wrote: >>> On Mon, May 02, 2016 at 03:18:53PM +0300, Roger Quadros wrote: >>>> From: Yoshihiro Shimoda >>>> >>>> Since some host controller (e.g. EHCI) needs a companion host controller >>>> (e.g. OHCI), this patch adds such a configuration to use it in the OTG >>>> core. >>>> >>>> Signed-off-by: Yoshihiro Shimoda >>>> Signed-off-by: Roger Quadros >>>> --- >>>> Documentation/devicetree/bindings/usb/generic.txt | 3 +++ >>>> drivers/usb/common/usb-otg.c | 32 >>>> --- >>>> include/linux/usb/otg.h | 7 - >>>> 3 files changed, 32 insertions(+), 10 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/usb/generic.txt >>>> b/Documentation/devicetree/bindings/usb/generic.txt >>>> index f6866c1..1db1c33 100644 >>>> --- a/Documentation/devicetree/bindings/usb/generic.txt >>>> +++ b/Documentation/devicetree/bindings/usb/generic.txt >>>> @@ -27,6 +27,9 @@ Optional properties: >>>> - otg-controller: phandle to otg controller. Host or gadget controllers >>>> can >>>>contain this property to link it to a particular OTG >>>>controller. >>>> + - hcd-needs-companion: must be present if otg controller is dealing with >>>> + EHCI host controller that needs a companion OHCI host >>>> + controller. >>> >>> Don't you need to have a link to the companion controller node? >> >> primary and companion controllers are totally independent of each other >> e.g. EHCI and OHCI. They are enabled by separate Kconfig options and >> the system can operate with either or both of them enabled. >> >> At the OTG layer we don't have information as to whether we should be waiting >> for both of them to register or not and hence need this >> "hcd-needs-companion" flag. > > What I mean is if you have 2 EHCI controllers with 2 companion > controllers, don't you need to know which companion goes with which EHCI > controller? Just like you do for the otg-controller property. > That is a very good point. I'm not very sure and it seems that current code won't work with multiple EHCI + companion instances. Alan, does USB core even know which EHCI and OHCI are linked to the same port or the handoff is software transparent? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 4/5] 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 | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c index dd55e08..3cebf9b 100644 --- a/drivers/usb/dwc3/dwc3-omap.c +++ b/drivers/usb/dwc3/dwc3-omap.c @@ -231,18 +231,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; + 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; dwc3_omap_write_utmi_ctrl(omap, val); break; @@ -250,13 +246,15 @@ 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 = dwc3_omap_read_utmi_ctrl(omap); val &= ~(USBOTGSS_UTMI_OTG_CTRL_SESSVALID | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID); - val |= USBOTGSS_UTMI_OTG_CTRL_SESSEND - | USBOTGSS_UTMI_OTG_CTRL_IDDIG; + val |= USBOTGSS_UTMI_OTG_CTRL_SESSEND; dwc3_omap_write_utmi_ctrl(omap, val); break; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/5] usb: dwc3: omap: Mark the interrupt handler as shared
On OMAPs, OTG events come on the same IRQ so we need to share
this IRQ with the OTG device driver.
Signed-off-by: Roger Quadros
---
drivers/usb/dwc3/dwc3-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 7d49da1..b58546c 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -517,7 +517,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
- dwc3_omap_interrupt_thread, 0,
+ dwc3_omap_interrupt_thread, IRQF_SHARED,
"dwc3-omap", omap);
if (ret) {
dev_err(dev, "failed to request IRQ #%d --> %d\n",
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 5/5] usb: dwc3: core: cleanup IRQ resources
Implementations might use different IRQs for
host, gadget and OTG so use named interrupt resources
to allow Device tree to specify the 3 interrupts.
Following are the interrupt names
Peripheral Interrupt - peripheral
HOST Interrupt - host
OTG Interrupt - otg
We still maintain backward compatibility for a single named
interrupt for all 3 interrupts (e.g. for dwc3-pci) and
single unnamed interrupt for all 3 interrupts (e.g. old DT).
Signed-off-by: Roger Quadros
---
drivers/usb/dwc3/core.c | 10 --
drivers/usb/dwc3/core.h | 3 +++
drivers/usb/dwc3/gadget.c | 23 +++
drivers/usb/dwc3/host.c | 19 +++
4 files changed, 41 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c050a88..4e8b154 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -814,16 +814,6 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->mem = mem;
dwc->dev = dev;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(dev, "missing IRQ\n");
- return -ENODEV;
- }
- dwc->xhci_resources[1].start = res->start;
- dwc->xhci_resources[1].end = res->end;
- dwc->xhci_resources[1].flags = res->flags;
- dwc->xhci_resources[1].name = res->name;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "missing memory resource\n");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 186a886..ab0d615 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -716,6 +716,7 @@ struct dwc3_scratchpad_array {
* @maximum_speed: maximum speed requested (mainly for testing purposes)
* @revision: revision register contents
* @dr_mode: requested mode of operation
+ * @gadget_irq: IRQ number for Peripheral IRQs
* @usb2_phy: pointer to USB2 PHY
* @usb3_phy: pointer to USB3 PHY
* @usb2_generic_phy: pointer to USB2 PHY
@@ -817,6 +818,8 @@ struct dwc3 {
enum usb_dr_modedr_mode;
+ int gadget_irq;
+
/* used for suspend/resume */
u32 dcfg;
u32 gctl;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c3b0d01..f493c32 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1605,7 +1605,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
int irq;
u32 reg;
- irq = platform_get_irq(to_platform_device(dwc->dev), 0);
+ irq = dwc->gadget_irq;
ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
IRQF_SHARED, "dwc3", dwc->ev_buf);
if (ret) {
@@ -1728,7 +1728,6 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
{
struct dwc3 *dwc = gadget_to_dwc(g);
unsigned long flags;
- int irq;
spin_lock_irqsave(&dwc->lock, flags);
@@ -1740,8 +1739,7 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
spin_unlock_irqrestore(&dwc->lock, flags);
- irq = platform_get_irq(to_platform_device(dwc->dev), 0);
- free_irq(irq, dwc->ev_buf);
+ free_irq(dwc->gadget_irq, dwc->ev_buf);
return 0;
}
@@ -2781,6 +2779,23 @@ static irqreturn_t dwc3_interrupt(int irq, void *_evt)
int dwc3_gadget_init(struct dwc3 *dwc)
{
int ret;
+ struct resource *res;
+ struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
+
+ dwc->gadget_irq = platform_get_irq_byname(dwc3_pdev, "peripheral");
+ if (dwc->gadget_irq <= 0) {
+ dwc->gadget_irq = platform_get_irq_byname(dwc3_pdev,
+ "dwc_usb3");
+ if (dwc->gadget_irq <= 0) {
+ res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
+ 0);
+ if (!res) {
+ dev_err(dwc->dev, "missing peripheral IRQ\n");
+ return -ENODEV;
+ }
+ dwc->gadget_irq = res->start;
+ }
+ }
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
&dwc->ctrl_req_addr, GFP_KERNEL);
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index c679f63..f2b60a4 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -25,6 +25,25 @@ int dwc3_host_init(struct dwc3 *dwc)
struct platform_device *xhci;
struct usb_xhci_pdata pdata;
int r
[PATCH v8 3/5] usb: dwc3: omap: Don't set POWERPRESENT
TRM [1] recommends that POWERPRESENT bit must not be set and left at it's default value of 0. [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 Section 23.11.4.5.1 Mailbox VBUS/ID Management "Because PIPE powerpresent has a different meaning in host and in device mode, and because of the redundancy with the UTMI signals, the controller ORes together the appropriate PIPE and UTMI inputs to create its internal VBUS status. For that reason, it is recommended to leave field USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only to fill in the USB2 VBUS status fields in the same register." Signed-off-by: Roger Quadros --- drivers/usb/dwc3/dwc3-omap.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c index b58546c..dd55e08 100644 --- a/drivers/usb/dwc3/dwc3-omap.c +++ b/drivers/usb/dwc3/dwc3-omap.c @@ -234,8 +234,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *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_SESSVALID; dwc3_omap_write_utmi_ctrl(omap, val); break; @@ -244,8 +243,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap, val &= ~USBOTGSS_UTMI_OTG_CTRL_SESSEND; val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID - | USBOTGSS_UTMI_OTG_CTRL_SESSVALID - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT; + | USBOTGSS_UTMI_OTG_CTRL_SESSVALID; dwc3_omap_write_utmi_ctrl(omap, val); break; @@ -256,8 +254,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap, case OMAP_DWC3_VBUS_OFF: val = dwc3_omap_read_utmi_ctrl(omap); val &= ~(USBOTGSS_UTMI_OTG_CTRL_SESSVALID - | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT); + | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID); val |= USBOTGSS_UTMI_OTG_CTRL_SESSEND | USBOTGSS_UTMI_OTG_CTRL_IDDIG; dwc3_omap_write_utmi_ctrl(omap, val); -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/5] dwc3: omap: fixes and dual-role preparation
Hi Felipe, I've removed the patches that add dual role support. These are just some fixes can go in before any actual dual role support. About the OTG software mailbox, I tried checking internally in TI but nobody was aware of any constraints. The events can be set as they are obtained from the PMIC OTG comparators. My gut feeling is that we didn't have VBUS and ID events working properly back then and so resulting in a hackish software OTG mailbox implementation. I tested this on omap5-uevm, dra7-evm and am572x-evm and didn't observe any regressions. Based on balbi/next commit 2a58f9c12bb360f38fb39e470bb5ff94014356e6. v8: - implement proper top and bottom half irq handler for dwc3-omap. - remove otg_irq code, this can come later with dual-role support. - use dwc3->gadget_irq while free_irq() in dwc3_gadget_stop(). v7: - remove patches adding dual-role support. - split out shared irq conversion from threaded irq conversion patch. - added a new patch about not touching POWERPRESENT bit. v6: - use just otg irq to get otg events and don't depend on extcon at all. - follow OTG flow in TRM strictly. - use tracepoints instead of dev_dbg(). - match IRQ flags in dwc3_omap and core.c for shared otg interrupt. v5: Internal revision. Not sent to mailing list. v4: first version that was reviewed. cheers, -roger Roger Quadros (5): usb: dwc3: omap: use request_threaded_irq() usb: dwc3: omap: Mark the interrupt handler as shared usb: dwc3: omap: Don't set POWERPRESENT usb: dwc3: omap: Pass VBUS and ID events transparently usb: dwc3: core: cleanup IRQ resources drivers/usb/dwc3/core.c | 10 - drivers/usb/dwc3/core.h | 3 +++ drivers/usb/dwc3/dwc3-omap.c | 53 drivers/usb/dwc3/gadget.c| 23 +++ drivers/usb/dwc3/host.c | 19 5 files changed, 75 insertions(+), 33 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/5] usb: dwc3: omap: use request_threaded_irq()
We intend to share this interrupt with the OTG driver an to ensure
that irqflags match for the shared interrupt handlers we use
request_threaded_irq()
If we don't use request_treaded_irq() then forced threaded irq will
set IRQF_ONESHOT and this won't match with the OTG IRQ handler's
IRQ flags.
NOTE: OTG IRQ handler is yet to be added. This is a preparatory step.
Signed-off-by: Roger Quadros
---
drivers/usb/dwc3/dwc3-omap.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 59ea35f..7d49da1 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -165,7 +165,7 @@ static void dwc3_omap_write_utmi_ctrl(struct dwc3_omap
*omap, u32 value)
static u32 dwc3_omap_read_irq0_status(struct dwc3_omap *omap)
{
- return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_0 -
+ return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_RAW_0 -
omap->irq0_offset);
}
@@ -178,7 +178,7 @@ static void dwc3_omap_write_irq0_status(struct dwc3_omap
*omap, u32 value)
static u32 dwc3_omap_read_irqmisc_status(struct dwc3_omap *omap)
{
- return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_MISC +
+ return dwc3_omap_readl(omap->base, USBOTGSS_IRQSTATUS_RAW_MISC +
omap->irqmisc_offset);
}
@@ -268,19 +268,38 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
}
}
+static void dwc3_omap_enable_irqs(struct dwc3_omap *omap);
+static void dwc3_omap_disable_irqs(struct dwc3_omap *omap);
+
static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
{
struct dwc3_omap*omap = _omap;
+
+ if (dwc3_omap_read_irqmisc_status(omap) ||
+ dwc3_omap_read_irq0_status(omap)) {
+ /* mask irqs */
+ dwc3_omap_disable_irqs(omap);
+ return IRQ_WAKE_THREAD;
+ }
+
+ return IRQ_NONE;
+}
+
+static irqreturn_t dwc3_omap_interrupt_thread(int irq, void *_omap)
+{
+ struct dwc3_omap*omap = _omap;
u32 reg;
+ /* clear irq status flags */
reg = dwc3_omap_read_irqmisc_status(omap);
-
dwc3_omap_write_irqmisc_status(omap, reg);
reg = dwc3_omap_read_irq0_status(omap);
-
dwc3_omap_write_irq0_status(omap, reg);
+ /* unmask irqs */
+ dwc3_omap_enable_irqs(omap);
+
return IRQ_HANDLED;
}
@@ -497,8 +516,9 @@ static int dwc3_omap_probe(struct platform_device *pdev)
/* check the DMA Status */
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
- ret = devm_request_irq(dev, omap->irq, dwc3_omap_interrupt, 0,
- "dwc3-omap", omap);
+ ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
+ dwc3_omap_interrupt_thread, 0,
+ "dwc3-omap", omap);
if (ret) {
dev_err(dev, "failed to request IRQ #%d --> %d\n",
omap->irq, ret);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/14] usb: otg-fsm: move host controller operations into usb_otg->hcd_ops
On 12/05/16 11:18, Peter Chen wrote:
> On Wed, May 11, 2016 at 03:32:30PM +0300, Roger Quadros wrote:
>> Peter,
>>
>> On 11/05/16 14:02, Roger Quadros wrote:
>>> On 11/05/16 09:10, Peter Chen wrote:
>>>> On Mon, May 02, 2016 at 03:18:48PM +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/chipidea/otg_fsm.c | 7 +++
>>>>> drivers/usb/common/usb-otg-fsm.c | 15 +++
>>>>> drivers/usb/phy/phy-fsl-usb.c| 7 +++
>>>>> include/linux/usb/otg.h | 2 ++
>>>>> 4 files changed, 27 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/usb/chipidea/otg_fsm.c
>>>>> b/drivers/usb/chipidea/otg_fsm.c
>>>>> index 1c0c750..2d8d659 100644
>>>>> --- a/drivers/usb/chipidea/otg_fsm.c
>>>>> +++ b/drivers/usb/chipidea/otg_fsm.c
>>>>> @@ -582,6 +582,12 @@ static struct otg_fsm_ops ci_otg_ops = {
>>>>> .start_gadget = ci_otg_start_gadget,
>>>>> };
>>>>>
>>>>> +static struct otg_hcd_ops ci_hcd_ops = {
>>>>> + .usb_bus_start_enum = usb_bus_start_enum,
>>>>> + .usb_control_msg = usb_control_msg,
>>>>> + .usb_hub_find_child = usb_hub_find_child,
>>>>> +};
>>>>> +
>>>>
>>>> Is it possible have default otg_hcd_ops during OTG register to
>>>> avoid define it at every dual-role driver?
>>>
>>> Yes, I'll do that.
>>
>> Every OTG driver doesn't need to do this as this is provided by
>> hcd.c during usb_otg_add_hcd().
>>
>> So proper fix is that chipidea driver must use usb_otg_add_hcd().
>>
>
> But the chipidea is not ready to merge with framework that this patch
> set introduces. So, as a solution, we need this patch, and can remove
> the redundant information after the OTG driver uses this framework?
That is fine, but I don't want to create a default otg_hcd_ops as we
don't want to encourage its use. Do you agree?
cheers,
-roger
>>
>>>
>>>>> int ci_otg_fsm_work(struct ci_hdrc *ci)
>>>>> {
>>>>> /*
>>>>> @@ -804,6 +810,7 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
>>>>> ci->otg.fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
>>>>> ci->otg.state = OTG_STATE_UNDEFINED;
>>>>> ci->otg.fsm.ops = &ci_otg_ops;
>>>>> + ci->otg.hcd_ops = &ci_hcd_ops;
>>>>> ci->gadget.hnp_polling_support = 1;
>>>>> ci->otg.fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
>>>>> if (!ci->otg.fsm.host_req_flag)
>>>>> diff --git a/drivers/usb/common/usb-otg-fsm.c
>>>>> b/drivers/usb/common/usb-otg-fsm.c
>>>>> index 4bfc6a5..2986b66 100644
>>>>> --- a/drivers/usb/common/usb-otg-fsm.c
>>>>> +++ b/drivers/usb/common/usb-otg-fsm.c
>>>>> @@ -141,11 +141,16 @@ static void otg_hnp_polling_work(struct work_struct
>>>>> *work)
>>>>> enum usb_otg_state state = otg->state;
>>>>> u8 flag;
>>>>> int retval;
>>>>> + struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
>>>>>
>>>>> if (state != OTG_STATE_A_HOST && state != OTG_STATE_B_HOST)
>>>>> return;
>>>>>
>>>>> - udev = usb_hub_find_child(otg->host->root_hub, 1);
>>>>> + if (!hcd_ops || !hcd_ops->usb_control_msg ||
>>>>> + !hcd_ops->usb_hub_find_child)
>>>>> + return;
>>>>> +
>>>>> + udev = hcd_ops->usb_hub_find_child(otg->host->root_hub, 1);
>>>>> if (!udev) {
>>>>> dev_err(otg->host->controller,
>>>>> "no usb dev connected, can't start HNP polling\n");
>>>>> @@ -154,7 +159,7 @@ static void otg_hnp_polling_work(struct work_struct
>>>>> *work)
>>>>>
>>>>> *fsm->host_req_flag = 0;
>>>>> /* Get host request flag from connected USB device */
>>>>> - retval = usb_control_msg(udev,
>>>>> + ret
Re: [PATCH v7 10/14] usb: otg: add hcd companion support
On 12/05/16 07:00, Yoshihiro Shimoda wrote: > Hi, > >> From: Alan Stern >> Sent: Wednesday, May 11, 2016 11:47 PM >> >> On Wed, 11 May 2016, Roger Quadros wrote: >> >>>> What I mean is if you have 2 EHCI controllers with 2 companion >>>> controllers, don't you need to know which companion goes with which EHCI >>>> controller? Just like you do for the otg-controller property. >>>> >>> >>> That is a very good point. I'm not very sure and it seems that current code >>> won't work >>> with multiple EHCI + companion instances. > > I may misunderstand this topic, but if I use the following environment, it > works correctly. > > < My environment > > - an otg controller: Sets hcd-needs-companion. > - ehci0 and ohci0 and a function: They connect to the otg controller using > "otg-controller" property. > - ehci1 and ohci1: No "otg-controller" property. > - ehci2 and ohci2: No "otg-controller" property. > > In this environment, all hosts works correctly. > Also I think if we have 2 otg controlelrs, it should be work because otg_dev > instance differs. The topic is about more than one otg controllers and how to tie the right ehci and ohci to the correct otg_dev instance especially in cases where we can't depend on probe order. > Or, does this topic assume an otg controller handles 2 EHCI controllers? > I'm not sure such environment actually exists. No it is not about that. > >>> Alan, does USB core even know which EHCI and OHCI are linked to the same >>> port >>> or the handoff is software transparent? >> >> The core knows. It doesn't use the information for a whole lot of >> things, but it does use it in a couple of places. Search for >> "companion" in core/hcd-pci.c and you'll see. > > Thank you for the information. I didn't know this code. > If my understanding is correct, the core/hcd-pci.c code will not be used by > non-PCI devices. That is correct. > In other words, nobody sets "hcd->self.hs_companion" if we use such a device. > So, I will try to add such a code if needed. I think OTG core would have to rely on USB core in providing the right companion device, just like we rely on it for the primary vs shared HCD case. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 10/14] usb: otg: add hcd companion support
Hi, On 12/05/16 11:34, Roger Quadros wrote: > On 12/05/16 07:00, Yoshihiro Shimoda wrote: >> Hi, >> >>> From: Alan Stern >>> Sent: Wednesday, May 11, 2016 11:47 PM >>> >>> On Wed, 11 May 2016, Roger Quadros wrote: >>> >>>>> What I mean is if you have 2 EHCI controllers with 2 companion >>>>> controllers, don't you need to know which companion goes with which EHCI >>>>> controller? Just like you do for the otg-controller property. >>>>> >>>> >>>> That is a very good point. I'm not very sure and it seems that current >>>> code won't work >>>> with multiple EHCI + companion instances. >> >> I may misunderstand this topic, but if I use the following environment, it >> works correctly. >> >> < My environment > >> - an otg controller: Sets hcd-needs-companion. >> - ehci0 and ohci0 and a function: They connect to the otg controller using >> "otg-controller" property. >> - ehci1 and ohci1: No "otg-controller" property. >> - ehci2 and ohci2: No "otg-controller" property. >> >> In this environment, all hosts works correctly. >> Also I think if we have 2 otg controlelrs, it should be work because otg_dev >> instance differs. > > The topic is about more than one otg controllers and how to tie the right > ehci and ohci > to the correct otg_dev instance especially in cases where we can't depend on > probe order. > >> Or, does this topic assume an otg controller handles 2 EHCI controllers? >> I'm not sure such environment actually exists. > > No it is not about that. > >> >>>> Alan, does USB core even know which EHCI and OHCI are linked to the same >>>> port >>>> or the handoff is software transparent? >>> >>> The core knows. It doesn't use the information for a whole lot of >>> things, but it does use it in a couple of places. Search for >>> "companion" in core/hcd-pci.c and you'll see. >> >> Thank you for the information. I didn't know this code. >> If my understanding is correct, the core/hcd-pci.c code will not be used by >> non-PCI devices. > > That is correct. > >> In other words, nobody sets "hcd->self.hs_companion" if we use such a device. >> So, I will try to add such a code if needed. > > I think OTG core would have to rely on USB core in providing the right > companion device, > just like we rely on it for the primary vs shared HCD case. > OK, it is not so simple. EHCI and companion port handoff is really meant to be software transparent. non-PCI devices really don't have knowledge of which OHCI instance is companion to the EHCI. With device tree we could provide this mapping but for non-device tree case we can't do anything. So my suggestion would be to keep dual role implementation limited to one instance for EHCI + companion case for non-DT. For PCI case I don't see how dual role can be implemented. I don't think we have any dual-role PCI cards. For DT case we could have a DT binding to tie the EHCI and companion and use that in the OTG framework. Any objections? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 10/14] usb: otg: add hcd companion support
Hi, On 12/05/16 13:31, Yoshihiro Shimoda wrote: > Hi, > >> From: Roger Quadros >> Sent: Thursday, May 12, 2016 6:32 PM >> >> Hi, >> >> On 12/05/16 11:34, Roger Quadros wrote: >>> On 12/05/16 07:00, Yoshihiro Shimoda wrote: >>>> Hi, >>>> >>>>> From: Alan Stern >>>>> Sent: Wednesday, May 11, 2016 11:47 PM >>>>> >>>>> On Wed, 11 May 2016, Roger Quadros wrote: >>>>> >>>>>>> What I mean is if you have 2 EHCI controllers with 2 companion >>>>>>> controllers, don't you need to know which companion goes with which EHCI >>>>>>> controller? Just like you do for the otg-controller property. >>>>>>> >>>>>> >>>>>> That is a very good point. I'm not very sure and it seems that current >>>>>> code won't work >>>>>> with multiple EHCI + companion instances. >>>> >>>> I may misunderstand this topic, but if I use the following environment, it >>>> works correctly. >>>> >>>> < My environment > >>>> - an otg controller: Sets hcd-needs-companion. >>>> - ehci0 and ohci0 and a function: They connect to the otg controller using >>>> "otg-controller" property. >>>> - ehci1 and ohci1: No "otg-controller" property. >>>> - ehci2 and ohci2: No "otg-controller" property. >>>> >>>> In this environment, all hosts works correctly. >>>> Also I think if we have 2 otg controlelrs, it should be work because >>>> otg_dev instance differs. >>> >>> The topic is about more than one otg controllers and how to tie the right >>> ehci and ohci >>> to the correct otg_dev instance especially in cases where we can't depend >>> on probe order. >>> >>>> Or, does this topic assume an otg controller handles 2 EHCI controllers? >>>> I'm not sure such environment actually exists. >>> >>> No it is not about that. > > Thank you for the reply. I understood it. > >>>>>> Alan, does USB core even know which EHCI and OHCI are linked to the same >>>>>> port >>>>>> or the handoff is software transparent? >>>>> >>>>> The core knows. It doesn't use the information for a whole lot of >>>>> things, but it does use it in a couple of places. Search for >>>>> "companion" in core/hcd-pci.c and you'll see. >>>> >>>> Thank you for the information. I didn't know this code. >>>> If my understanding is correct, the core/hcd-pci.c code will not be used >>>> by non-PCI devices. >>> >>> That is correct. >>> >>>> In other words, nobody sets "hcd->self.hs_companion" if we use such a >>>> device. >>>> So, I will try to add such a code if needed. >>> >>> I think OTG core would have to rely on USB core in providing the right >>> companion device, >>> just like we rely on it for the primary vs shared HCD case. >>> >> >> OK, it is not so simple. >> >> EHCI and companion port handoff is really meant to be software transparent. >> >> non-PCI devices really don't have knowledge of which OHCI instance is >> companion to the EHCI. >> With device tree we could provide this mapping but for non-device tree case >> we can't do >> anything. >> >> So my suggestion would be to keep dual role implementation limited to one >> instance for >> EHCI + companion case for non-DT. >> For PCI case I don't see how dual role can be implemented. I don't think we >> have any >> dual-role PCI cards. > > R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via PCI > bus and > one high speed function controller via AXI bus. > One of channel can be used as host or function. > >> For DT case we could have a DT binding to tie the EHCI and companion and use >> that >> in the OTG framework. After looking at the code it seems we don't need this special binding as we are already linking the EHCI controller and companion controller to the single otg controller instance using the otg-controller property. So all is good as of now. For non DT case, it is the responsibility of platform support code to ensure that it calls usb_otg_add_hcd() with the correct otg controller instance for both EHCI and companion controller and things should work fine there as well. -- cheers, -roger > > R-Car Gen3 SoC (r8a7795 / arm64) will be this type. > (Both USB 2.0 host/function controllers connect to AXI bus.) > >> Any objections? > > I don't have any objections because I'm just focus on R-Car Gen3 SoC for now. > If someone needs for PCI case, I think it is possible to add such a code > somehow later. > > Best regards, > Yoshihiro Shimoda > >> cheers, >> -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 14/14] usb: host: xhci-plat: Add otg device to platform data
Host controllers that are part of an OTG/dual-role instance
need to somehow pass the OTG controller device information
to the HCD core.
We use platform data to pass the OTG controller device.
Signed-off-by: Roger Quadros
Reviewed-by: Peter Chen
---
drivers/usb/host/xhci-plat.c | 35 ---
include/linux/usb/xhci_pdriver.h | 3 +++
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5c15e9b..84ebe18 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -230,11 +230,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_usb3_hcd;
}
- ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+ if (pdata && pdata->otg_dev)
+ ret = usb_otg_add_hcd(hcd, irq, IRQF_SHARED, pdata->otg_dev);
+ else
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+
if (ret)
goto disable_usb_phy;
- ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+ if (pdata && pdata->otg_dev)
+ ret = usb_otg_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED,
+ pdata->otg_dev);
+ else
+ ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+
if (ret)
goto dealloc_usb2_hcd;
@@ -242,7 +251,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
dealloc_usb2_hcd:
- usb_remove_hcd(hcd);
+ if (pdata && pdata->otg_dev)
+ usb_otg_remove_hcd(hcd);
+ else
+ usb_remove_hcd(hcd);
disable_usb_phy:
usb_phy_shutdown(hcd->usb_phy);
@@ -260,16 +272,25 @@ put_hcd:
return ret;
}
-static int xhci_plat_remove(struct platform_device *dev)
+static int xhci_plat_remove(struct platform_device *pdev)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
+ struct usb_xhci_pdata *pdata = dev_get_platdata(&pdev->dev);
+
+ if (pdata && pdata->otg_dev)
+ usb_otg_remove_hcd(xhci->shared_hcd);
+ else
+ usb_remove_hcd(xhci->shared_hcd);
- usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
- usb_remove_hcd(hcd);
+ if (pdata && pdata->otg_dev)
+ usb_otg_remove_hcd(hcd);
+ else
+ usb_remove_hcd(hcd);
+
usb_put_hcd(xhci->shared_hcd);
if (!IS_ERR(clk))
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..5c68b83 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,13 @@
*
* @usb3_lpm_capable: determines if this xhci platform supports USB3
* LPM capability
+ * @otg_dev: OTG controller device. Only requied if part of
+ * OTG/dual-role.
*
*/
struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+ struct device *otg_dev;
};
#endif /* __USB_CORE_XHCI_PDRIVER_H */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 11/14] usb: otg: use dev_dbg() instead of VDBG()
Now that we have a device reference in struct usb_otg
let's use dev_dbg() for debug messages.
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
drivers/usb/common/usb-otg-fsm.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 2986b66..e6e58c2 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -30,13 +30,6 @@
#include
#include
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug("[%s] " fmt , \
-__func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
/* Change USB protocol when there is a protocol change */
static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
{
@@ -44,8 +37,9 @@ static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
int ret = 0;
if (fsm->protocol != protocol) {
- VDBG("Changing role fsm->protocol= %d; new protocol= %d\n",
- fsm->protocol, protocol);
+ dev_vdbg(otg->dev,
+"Changing role fsm->protocol= %d; new protocol= %d\n",
+fsm->protocol, protocol);
/* stop old protocol */
if (fsm->protocol == PROTO_HOST)
ret = otg_start_host(otg, 0);
@@ -226,7 +220,7 @@ static int otg_set_state(struct otg_fsm *fsm, enum
usb_otg_state new_state)
if (otg->state == new_state)
return 0;
- VDBG("Set state: %s\n", usb_otg_state_string(new_state));
+ dev_vdbg(otg->dev, "Set state: %s\n", usb_otg_state_string(new_state));
otg_leave_state(fsm, otg->state);
switch (new_state) {
case OTG_STATE_B_IDLE:
@@ -358,7 +352,7 @@ int otg_statemachine(struct usb_otg *otg)
switch (state) {
case OTG_STATE_UNDEFINED:
- VDBG("fsm->id = %d\n", fsm->id);
+ dev_vdbg(otg->dev, "fsm->id = %d\n", fsm->id);
if (fsm->id)
otg_set_state(fsm, OTG_STATE_B_IDLE);
else
@@ -466,7 +460,8 @@ int otg_statemachine(struct usb_otg *otg)
}
mutex_unlock(&fsm->lock);
- VDBG("quit statemachine, changed = %d\n", fsm->state_changed);
+ dev_vdbg(otg->dev, "quit statemachine, changed = %d\n",
+fsm->state_changed);
return fsm->state_changed;
}
EXPORT_SYMBOL_GPL(otg_statemachine);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 09/14] usb: of: add an API to get OTG device from USB controller node
The OTG controller and the USB controller can be linked via the
'otg-controller' property in the USB controller's device node.
of_usb_get_otg() can be used to get the OTG controller device
from the USB controller's device node.
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
Documentation/devicetree/bindings/usb/generic.txt | 3 +++
drivers/usb/common/common.c | 27 +++
include/linux/usb/of.h| 9
3 files changed, 39 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/generic.txt
b/Documentation/devicetree/bindings/usb/generic.txt
index bba8257..f6866c1 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -24,6 +24,9 @@ Optional properties:
optional for OTG device.
- adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
optional for OTG device.
+ - otg-controller: phandle to otg controller. Host or gadget controllers can
+ contain this property to link it to a particular OTG
+ controller.
This is an attribute to a USB controller such as:
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index e3d0161..d7ec471 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -238,6 +238,33 @@ int of_usb_update_otg_caps(struct device_node *np,
}
EXPORT_SYMBOL_GPL(of_usb_update_otg_caps);
+#ifdef CONFIG_USB_OTG
+/**
+ * of_usb_get_otg - get the OTG controller linked to the USB controller
+ * @np: Pointer to the device_node of the USB controller
+ * @otg_caps: Pointer to the target usb_otg_caps to be set
+ *
+ * Returns the OTG controller device or NULL on error.
+ */
+struct device *of_usb_get_otg(struct device_node *np)
+{
+ struct device_node *otg_np;
+ struct platform_device *pdev;
+
+ otg_np = of_parse_phandle(np, "otg-controller", 0);
+ if (!otg_np)
+ return NULL;
+
+ pdev = of_find_device_by_node(otg_np);
+ of_node_put(otg_np);
+ if (!pdev)
+ return NULL;
+
+ return &pdev->dev;
+}
+EXPORT_SYMBOL_GPL(of_usb_get_otg);
+#endif
+
#endif
MODULE_LICENSE("GPL");
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index de3237f..499a4e8 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -40,6 +40,15 @@ static inline struct device_node *usb_of_get_child_node
}
#endif
+#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_OTG)
+struct device *of_usb_get_otg(struct device_node *np);
+#else
+static inline struct device *of_usb_get_otg(struct device_node *np)
+{
+ return NULL;
+}
+#endif
+
#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
#else
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 12/14] usb: hcd: Adapt to OTG core
Introduce usb_otg_add/remove_hcd() for use by host
controllers that are part of OTG/dual-role port.
Non Device tree platforms can use the otg_dev argument
to specify the OTG controller device. If otg_dev is NULL
then the device tree node's otg-controller property is used to
get the otg_dev device.
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
drivers/usb/core/hcd.c | 55 +
include/linux/usb/hcd.h | 4
2 files changed, 59 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 9484539..cfc8232 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -46,6 +46,11 @@
#include
#include
#include
+#include
+#include
+
+#include
+#include
#include "usb.h"
@@ -3013,6 +3018,56 @@ void usb_remove_hcd(struct usb_hcd *hcd)
}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
+static struct otg_hcd_ops otg_hcd_intf = {
+ .add = usb_add_hcd,
+ .remove = usb_remove_hcd,
+ .usb_bus_start_enum = usb_bus_start_enum,
+ .usb_control_msg = usb_control_msg,
+ .usb_hub_find_child = usb_hub_find_child,
+};
+
+/**
+ * usb_otg_add_hcd - Register the HCD with OTG core.
+ * @hcd: the usb_hcd structure to initialize
+ * @irqnum: Interrupt line to allocate
+ * @irqflags: Interrupt type flags
+ * @otg_dev: OTG controller device managing this HCD
+ *
+ * Registers the HCD with OTG core. OTG core will call usb_add_hcd()
+ * or usb_remove_hcd() as necessary.
+ * If otg_dev is NULL then device tree node is checked for OTG
+ * controller device via the otg-controller property.
+ */
+int usb_otg_add_hcd(struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags,
+ struct device *otg_dev)
+{
+ struct device *dev = hcd->self.controller;
+
+ if (!otg_dev) {
+ hcd->otg_dev = of_usb_get_otg(dev->of_node);
+ if (!hcd->otg_dev)
+ return -ENODEV;
+ } else {
+ hcd->otg_dev = otg_dev;
+ }
+
+ return usb_otg_register_hcd(hcd, irqnum, irqflags, &otg_hcd_intf);
+}
+EXPORT_SYMBOL_GPL(usb_otg_add_hcd);
+
+/**
+ * usb_otg_remove_hcd - Unregister the HCD with OTG core.
+ * @hcd: the usb_hcd structure to remove
+ *
+ * Unregisters the HCD from the OTG core.
+ */
+void usb_otg_remove_hcd(struct usb_hcd *hcd)
+{
+ usb_otg_unregister_hcd(hcd);
+}
+EXPORT_SYMBOL_GPL(usb_otg_remove_hcd);
+
void
usb_hcd_platform_shutdown(struct platform_device *dev)
{
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 2017cd4..adcf2e7 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -472,6 +472,10 @@ extern int usb_hcd_is_primary_hcd(struct usb_hcd *hcd);
extern int usb_add_hcd(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags);
extern void usb_remove_hcd(struct usb_hcd *hcd);
+extern int usb_otg_add_hcd(struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags,
+ struct device *otg_dev);
+extern void usb_otg_remove_hcd(struct usb_hcd *hcd);
extern int usb_hcd_find_raw_port_number(struct usb_hcd *hcd, int port1);
struct platform_device;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
The OTG state machine needs a mechanism to start and
stop the gadget controller as well as connect/disconnect
from the bus. Add usb_gadget_start(), usb_gadget_stop()
and usb_gadget_connect_control().
Introduce usb_otg_add_gadget_udc() to allow controller drivers
to register a gadget controller that is part of an OTG instance.
Register with OTG core when gadget function driver
is available and unregister when function driver is unbound.
We need to unlock the usb_lock mutex before calling
usb_otg_register_gadget() in udc_bind_to_driver() and
usb_gadget_remove_driver() else it will cause a circular
locking dependency.
Ignore softconnect sysfs control when we're in OTG
mode as OTG FSM takes care of gadget softconnect using
the b_bus_req mechanism.
Signed-off-by: Roger Quadros
---
drivers/usb/gadget/udc/udc-core.c | 194 --
include/linux/usb/gadget.h| 4 +
2 files changed, 189 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 4151597..21c85ef 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,11 @@
#include
#include
#include
+#include
+#include
+
+#include
+#include
/**
* struct usb_udc - describes one usb device controller
@@ -325,6 +330,119 @@ static inline void usb_gadget_udc_stop(struct usb_udc
*udc)
}
/**
+ * usb_gadget_to_udc - get the UDC owning the gadget
+ *
+ * udc_lock must be held.
+ * Returs NULL if UDC is not found.
+ */
+static struct usb_udc *usb_gadget_to_udc(struct usb_gadget *gadget)
+{
+ struct usb_udc *udc;
+
+ list_for_each_entry(udc, &udc_list, list)
+ if (udc->gadget == gadget)
+ return udc;
+
+ return NULL;
+}
+
+/**
+ * usb_gadget_start - start the usb gadget controller
+ * @gadget: the gadget device to start
+ *
+ * This is external API for use by OTG core.
+ *
+ * Start the usb device controller. Does not connect to the bus.
+ */
+static int usb_gadget_start(struct usb_gadget *gadget)
+{
+ int ret;
+ struct usb_udc *udc;
+
+ mutex_lock(&udc_lock);
+ udc = usb_gadget_to_udc(gadget);
+ if (!udc) {
+ dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
+ __func__);
+ mutex_unlock(&udc_lock);
+ return -EINVAL;
+ }
+
+ ret = usb_gadget_udc_start(udc);
+ if (ret)
+ dev_err(&udc->dev, "USB Device Controller didn't start: %d\n",
+ ret);
+
+ mutex_unlock(&udc_lock);
+
+ return ret;
+}
+
+/**
+ * usb_gadget_stop - stop the usb gadget controller
+ * @gadget: the gadget device we want to stop
+ *
+ * This is external API for use by OTG core.
+ *
+ * Stop the gadget controller. Does not disconnect from the bus.
+ * Caller must ensure that gadget has disconnected from the bus
+ * before calling usb_gadget_stop().
+ */
+static int usb_gadget_stop(struct usb_gadget *gadget)
+{
+ struct usb_udc *udc;
+
+ mutex_lock(&udc_lock);
+ udc = usb_gadget_to_udc(gadget);
+ if (!udc) {
+ dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
+ __func__);
+ mutex_unlock(&udc_lock);
+ return -EINVAL;
+ }
+
+ if (gadget->connected) {
+ dev_err(gadget->dev.parent,
+ "%s: called while still connected\n", __func__);
+ mutex_unlock(&udc_lock);
+ return -EINVAL;
+ }
+
+ usb_gadget_udc_stop(udc);
+ mutex_unlock(&udc_lock);
+
+ return 0;
+}
+
+static int usb_gadget_connect_control(struct usb_gadget *gadget, bool connect)
+{
+ struct usb_udc *udc;
+
+ mutex_lock(&udc_lock);
+ udc = usb_gadget_to_udc(gadget);
+ if (!udc) {
+ dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
+ __func__);
+ mutex_unlock(&udc_lock);
+ return -EINVAL;
+ }
+
+ if (connect) {
+ if (!gadget->connected)
+ usb_gadget_connect(udc->gadget);
+ } else {
+ if (gadget->connected) {
+ usb_gadget_disconnect(udc->gadget);
+ udc->driver->disconnect(udc->gadget);
+ }
+ }
+
+ mutex_unlock(&udc_lock);
+
+ return 0;
+}
+
+/**
* usb_udc_release - release the usb_udc struct
* @dev: the dev member within usb_udc
*
@@ -486,6 +604,33 @@ int usb_add_gadget_udc(struct device *parent, struct
usb_gadget *gadget)
}
EXPORT_SYMBOL_GPL(usb_add_gadget_udc);
+/**
+ * usb_otg_add_gadget_udc - adds a new gadget to the udc class driver list
+ * @parent: the parent device to this udc. Usu
[PATCH v8 07/14] usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG
Let's use CONFIG_USB_OTG as a single config option to enable
USB OTG and the OTG FSM. This makes things a lot less confusing.
Update all users of CONFIG_USB_OTG_FSM to CONFIG_USB_OTG.
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
Documentation/usb/chipidea.txt | 2 +-
drivers/usb/chipidea/Makefile | 2 +-
drivers/usb/chipidea/ci.h | 2 +-
drivers/usb/chipidea/otg_fsm.h | 2 +-
drivers/usb/common/Makefile| 3 ++-
drivers/usb/core/Kconfig | 8
drivers/usb/phy/Kconfig| 2 +-
7 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt
index 678741b..3b1f263 100644
--- a/Documentation/usb/chipidea.txt
+++ b/Documentation/usb/chipidea.txt
@@ -5,7 +5,7 @@ with 2 Freescale i.MX6Q sabre SD boards.
1.1 How to enable OTG FSM in menuconfig
---
-Select CONFIG_USB_OTG_FSM, rebuild kernel Image and modules.
+Select CONFIG_USB_OTG, rebuild kernel Image and modules.
If you want to check some internal variables for otg fsm,
mount debugfs, there are 2 files which can show otg fsm
variables and some controller registers value:
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 518e445..45aa24d 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc.o
ci_hdrc-y := core.o otg.o debug.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)+= host.o
-ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
+ci_hdrc-$(CONFIG_USB_OTG) += otg_fsm.o
# Glue/Bridge layers go here
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index c523975..1a32b8c 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -406,7 +406,7 @@ static inline u32 hw_test_and_write(struct ci_hdrc *ci,
enum ci_hw_regs reg,
*/
static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
{
-#ifdef CONFIG_USB_OTG_FSM
+#ifdef CONFIG_USB_OTG
struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps;
return ci->is_otg && ci->roles[CI_ROLE_HOST] &&
diff --git a/drivers/usb/chipidea/otg_fsm.h b/drivers/usb/chipidea/otg_fsm.h
index 6366fe3..2d451bb 100644
--- a/drivers/usb/chipidea/otg_fsm.h
+++ b/drivers/usb/chipidea/otg_fsm.h
@@ -64,7 +64,7 @@
#define TB_AIDL_BDIS (20) /* 4ms ~ 150ms, section 5.2.1 */
-#if IS_ENABLED(CONFIG_USB_OTG_FSM)
+#if IS_ENABLED(CONFIG_USB_OTG)
int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci);
int ci_otg_fsm_work(struct ci_hdrc *ci);
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 6bbb3ec..f8f2c88 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -6,5 +6,6 @@ obj-$(CONFIG_USB_COMMON) += usb-common.o
usb-common-y += common.o
usb-common-$(CONFIG_USB_LED_TRIG) += led.o
-obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
+usbotg-y := usb-otg-fsm.o
+obj-$(CONFIG_USB_OTG) += usbotg.o
diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index dd28010..ae228d0 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -75,14 +75,6 @@ config USB_OTG_BLACKLIST_HUB
and software costs by not supporting external hubs. So
are "Embedded Hosts" that don't offer OTG support.
-config USB_OTG_FSM
- tristate "USB 2.0 OTG FSM implementation"
- depends on USB && USB_OTG
- select USB_PHY
- help
- Implements OTG Finite State Machine as specified in On-The-Go
- and Embedded Host Supplement to the USB Revision 2.0 Specification.
-
config USB_ULPI_BUS
tristate "USB ULPI PHY interface support"
depends on USB_SUPPORT
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index c690474..06794e2 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -20,7 +20,7 @@ config AB8500_USB
config FSL_USB2_OTG
bool "Freescale USB OTG Transceiver Driver"
- depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM
+ depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG && PM
select USB_PHY
help
Enable this to support Freescale USB OTG transceiver.
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 06/14] usb: gadget.h: Add OTG to gadget interface
The OTG core will use struct otg_gadget_ops to
start/stop the gadget controller.
The main purpose of this interface is to avoid directly
calling usb_gadget_start/stop() from the OTG core as they
wouldn't be defined in the built-in symbol table if
CONFIG_USB_GADGET is m.
Signed-off-by: Roger Quadros
---
include/linux/usb/gadget.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 5d4e151..20a2f8a 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1100,6 +1100,22 @@ struct usb_gadget_driver {
};
+/*-*/
+
+/**
+ * struct otg_gadget_ops - Interface between OTG core and gadget
+ *
+ * Provided by the gadget core to allow the OTG core to start/stop the gadget
+ *
+ * @start: function to start the gadget
+ * @stop: function to stop the gadget
+ * @connect_control: function to connect/disconnect from the bus
+ */
+struct otg_gadget_ops {
+ int (*start)(struct usb_gadget *gadget);
+ int (*stop)(struct usb_gadget *gadget);
+ int (*connect_control)(struct usb_gadget *gadget, bool connect);
+};
/*-*/
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 05/14] usb: otg-fsm: move host controller operations into usb_otg->hcd_ops
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/chipidea/otg_fsm.c | 7 +++
drivers/usb/common/usb-otg-fsm.c | 15 +++
drivers/usb/phy/phy-fsl-usb.c| 7 +++
include/linux/usb/otg.h | 2 ++
4 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 1c0c750..2d8d659 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -582,6 +582,12 @@ static struct otg_fsm_ops ci_otg_ops = {
.start_gadget = ci_otg_start_gadget,
};
+static struct otg_hcd_ops ci_hcd_ops = {
+ .usb_bus_start_enum = usb_bus_start_enum,
+ .usb_control_msg = usb_control_msg,
+ .usb_hub_find_child = usb_hub_find_child,
+};
+
int ci_otg_fsm_work(struct ci_hdrc *ci)
{
/*
@@ -804,6 +810,7 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
ci->otg.fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
ci->otg.state = OTG_STATE_UNDEFINED;
ci->otg.fsm.ops = &ci_otg_ops;
+ ci->otg.hcd_ops = &ci_hcd_ops;
ci->gadget.hnp_polling_support = 1;
ci->otg.fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
if (!ci->otg.fsm.host_req_flag)
diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 4bfc6a5..2986b66 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -141,11 +141,16 @@ static void otg_hnp_polling_work(struct work_struct *work)
enum usb_otg_state state = otg->state;
u8 flag;
int retval;
+ struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
if (state != OTG_STATE_A_HOST && state != OTG_STATE_B_HOST)
return;
- udev = usb_hub_find_child(otg->host->root_hub, 1);
+ if (!hcd_ops || !hcd_ops->usb_control_msg ||
+ !hcd_ops->usb_hub_find_child)
+ return;
+
+ udev = hcd_ops->usb_hub_find_child(otg->host->root_hub, 1);
if (!udev) {
dev_err(otg->host->controller,
"no usb dev connected, can't start HNP polling\n");
@@ -154,7 +159,7 @@ static void otg_hnp_polling_work(struct work_struct *work)
*fsm->host_req_flag = 0;
/* Get host request flag from connected USB device */
- retval = usb_control_msg(udev,
+ retval = hcd_ops->usb_control_msg(udev,
usb_rcvctrlpipe(udev, 0),
USB_REQ_GET_STATUS,
USB_DIR_IN | USB_RECIP_DEVICE,
@@ -183,7 +188,7 @@ static void otg_hnp_polling_work(struct work_struct *work)
if (state == OTG_STATE_A_HOST) {
/* Set b_hnp_enable */
if (!otg->host->b_hnp_enable) {
- retval = usb_control_msg(udev,
+ retval = hcd_ops->usb_control_msg(udev,
usb_sndctrlpipe(udev, 0),
USB_REQ_SET_FEATURE, 0,
USB_DEVICE_B_HNP_ENABLE,
@@ -262,7 +267,9 @@ static int otg_set_state(struct otg_fsm *fsm, enum
usb_otg_state new_state)
otg_loc_conn(otg, 0);
otg_loc_sof(otg, 1);
otg_set_protocol(fsm, PROTO_HOST);
- usb_bus_start_enum(otg->host, otg->host->otg_port);
+ if (otg->hcd_ops && otg->hcd_ops->usb_bus_start_enum)
+ otg->hcd_ops->usb_bus_start_enum(otg->host,
+otg->host->otg_port);
otg_start_hnp_polling(fsm);
break;
case OTG_STATE_A_IDLE:
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 587a187..9dbd9f0 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -792,6 +792,12 @@ static struct otg_fsm_ops fsl_otg_ops = {
.start_gadget = fsl_otg_start_gadget,
};
+static struct otg_hcd_ops fsl_hcd_ops = {
+ .usb_bus_start_enum = usb_bus_start_enum,
+ .usb_control_msg = usb_control_msg,
+ .usb_hub_find_child = usb_hub_find_child,
+};
+
/* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
static int fsl_otg_conf(struct platform_device *pdev)
{
@@ -820,6 +826,7 @@ static int fsl_otg_conf(struct platform_device *pdev)
/* Set OTG state machine operations */
fsl_otg_tc->otg.fsm.ops = &fsl_otg_ops;
+ fsl_otg_tc->otg.hcd_ops = &fsl_hcd_ops;
/* initialize the otg structure */
fsl_otg_tc->phy.label = DRIVER_DESC;
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index e8a14dc..85b8fb
[PATCH v8 04/14] usb: otg-fsm: use usb_otg wherever possible
Move otg_fsm into usb_otg and use usb_otg wherever possible
in the usb_otg APIs.
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
drivers/usb/chipidea/ci.h| 1 -
drivers/usb/chipidea/core.c | 14 +--
drivers/usb/chipidea/debug.c | 2 +-
drivers/usb/chipidea/otg_fsm.c | 169 ++--
drivers/usb/chipidea/udc.c | 17 ++--
drivers/usb/common/usb-otg-fsm.c | 180 ---
drivers/usb/phy/phy-fsl-usb.c| 141 +++---
drivers/usb/phy/phy-fsl-usb.h| 3 +-
include/linux/usb/otg-fsm.h | 132 +++-
include/linux/usb/otg.h | 107 +++
10 files changed, 383 insertions(+), 383 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index cd41455..c523975 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -209,7 +209,6 @@ struct ci_hdrc {
enum ci_rolerole;
boolis_otg;
struct usb_otg otg;
- struct otg_fsm fsm;
struct hrtimer otg_fsm_hrtimer;
ktime_t hr_timeouts[NUM_OTG_FSM_TIMERS];
unsignedenabled_otg_timer_bits;
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..56b6ac6 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -1085,8 +1085,8 @@ static int ci_hdrc_remove(struct platform_device *pdev)
/* Prepare wakeup by SRP before suspend */
static void ci_otg_fsm_suspend_for_srp(struct ci_hdrc *ci)
{
- if ((ci->fsm.otg->state == OTG_STATE_A_IDLE) &&
- !hw_read_otgsc(ci, OTGSC_ID)) {
+ if ((ci->otg.state == OTG_STATE_A_IDLE) &&
+ !hw_read_otgsc(ci, OTGSC_ID)) {
hw_write(ci, OP_PORTSC, PORTSC_W1C_BITS | PORTSC_PP,
PORTSC_PP);
hw_write(ci, OP_PORTSC, PORTSC_W1C_BITS | PORTSC_WKCN,
@@ -1097,13 +1097,13 @@ static void ci_otg_fsm_suspend_for_srp(struct ci_hdrc
*ci)
/* Handle SRP when wakeup by data pulse */
static void ci_otg_fsm_wakeup_by_srp(struct ci_hdrc *ci)
{
- if ((ci->fsm.otg->state == OTG_STATE_A_IDLE) &&
- (ci->fsm.a_bus_drop == 1) && (ci->fsm.a_bus_req == 0)) {
+ if ((ci->otg.state == OTG_STATE_A_IDLE) &&
+ (ci->otg.fsm.a_bus_drop == 1) && (ci->otg.fsm.a_bus_req == 0)) {
if (!hw_read_otgsc(ci, OTGSC_ID)) {
- ci->fsm.a_srp_det = 1;
- ci->fsm.a_bus_drop = 0;
+ ci->otg.fsm.a_srp_det = 1;
+ ci->otg.fsm.a_bus_drop = 0;
} else {
- ci->fsm.id = 1;
+ ci->otg.fsm.id = 1;
}
ci_otg_queue_work(ci);
}
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 6d23eed..374cdaa 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -224,7 +224,7 @@ static int ci_otg_show(struct seq_file *s, void *unused)
if (!ci || !ci_otg_is_fsm_mode(ci))
return 0;
- fsm = &ci->fsm;
+ fsm = &ci->otg.fsm;
/* -- State - */
seq_printf(s, "OTG state: %s\n\n",
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index de8e22e..1c0c750 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -40,7 +40,7 @@ get_a_bus_req(struct device *dev, struct device_attribute
*attr, char *buf)
next = buf;
size = PAGE_SIZE;
- t = scnprintf(next, size, "%d\n", ci->fsm.a_bus_req);
+ t = scnprintf(next, size, "%d\n", ci->otg.fsm.a_bus_req);
size -= t;
next += t;
@@ -56,25 +56,25 @@ set_a_bus_req(struct device *dev, struct device_attribute
*attr,
if (count > 2)
return -1;
- mutex_lock(&ci->fsm.lock);
+ mutex_lock(&ci->otg.fsm.lock);
if (buf[0] == '0') {
- ci->fsm.a_bus_req = 0;
+ ci->otg.fsm.a_bus_req = 0;
} else if (buf[0] == '1') {
/* If a_bus_drop is TRUE, a_bus_req can't be set */
- if (ci->fsm.a_bus_drop) {
- mutex_unlock(&ci->fsm.lock);
+ if (ci->otg.fsm.a_bus_drop) {
+ mutex_unlock(&ci->otg.fsm.lock);
return count;
}
- ci->fsm.a_bus_req = 1;
- if (ci->fsm.otg->state == OTG_STATE_A_PERIPHERAL) {
+ ci->otg.fsm.a_b
[PATCH v8 08/14] usb: otg: add OTG/dual-role core
It provides APIs for the following tasks
- Registering an OTG/dual-role capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine
Provide a dual-role device (DRD) state machine.
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/Makefile |2 +-
drivers/usb/common/usb-otg.c | 1042 ++
drivers/usb/core/Kconfig |4 +-
include/linux/usb/gadget.h |2 +
include/linux/usb/hcd.h |1 +
include/linux/usb/otg-fsm.h |7 +
include/linux/usb/otg.h | 154 ++-
7 files changed, 1206 insertions(+), 6 deletions(-)
create mode 100644 drivers/usb/common/usb-otg.c
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index f8f2c88..730d928 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,5 +7,5 @@ usb-common-y += common.o
usb-common-$(CONFIG_USB_LED_TRIG) += led.o
obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
-usbotg-y := usb-otg-fsm.o
+usbotg-y := usb-otg.o usb-otg-fsm.o
obj-$(CONFIG_USB_OTG) += usbotg.o
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
new file mode 100644
index 000..64be6df
--- /dev/null
+++ b/drivers/usb/common/usb-otg.c
@@ -0,0 +1,1042 @@
+/**
+ * drivers/usb/common/usb-otg.c - USB OTG core
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct otg_gcd {
+ struct usb_gadget *gadget;
+ struct otg_gadget_ops *ops;
+};
+
+/* OTG device list */
+LIST_HEAD(otg_list);
+static DEFINE_MUTEX(otg_list_mutex);
+
+/* Hosts and Gadgets waiting for OTG controller */
+struct otg_wait_data {
+ struct device *dev; /* OTG controller device */
+
+ struct otg_hcd primary_hcd;
+ struct otg_hcd shared_hcd;
+ struct otg_gcd gcd;
+ struct list_head list;
+};
+
+LIST_HEAD(wait_list);
+static DEFINE_MUTEX(wait_list_mutex);
+
+static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
+{
+ if (!hcd->primary_hcd)
+ return 1;
+ return hcd == hcd->primary_hcd;
+}
+
+/**
+ * Check if the OTG device is in our wait list and return
+ * otg_wait_data, else NULL.
+ *
+ * wait_list_mutex must be held.
+ */
+static struct otg_wait_data *usb_otg_get_wait(struct device *otg_dev)
+{
+ struct otg_wait_data *wait;
+
+ if (!otg_dev)
+ return NULL;
+
+ /* is there an entry for this otg_dev ?*/
+ list_for_each_entry(wait, &wait_list, list) {
+ if (wait->dev == otg_dev)
+ return wait;
+ }
+
+ return NULL;
+}
+
+/**
+ * Add the hcd to our wait list
+ */
+static int usb_otg_hcd_wait_add(struct device *otg_dev, struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags,
+ struct otg_hcd_ops *ops)
+{
+ struct otg_wait_data *wait;
+ int ret = -EINVAL;
+
+ mutex_lock(&wait_list_mutex);
+
+ wait = usb_otg_get_wait(otg_dev);
+ if (!wait) {
+ /* Not yet in wait list? allocate and add */
+ wait = kzalloc(sizeof(*wait), GFP_KERNEL);
+ if (!wait) {
+ ret = -ENOMEM;
+ goto fail;
+ }
+
+ wait->dev = otg_dev;
+ list_add_tail(&wait->list, &wait_list);
+ }
+
+ if (usb_otg_hcd_is_primary_hcd(hcd)) {
+ if (wait->primary_hcd.hcd) /* already assigned? */
+ goto fail;
+
+ wait->primary_hcd.hcd = hcd;
+ wait->primary_hcd.irqnum = irqnum;
+ wait->primary_hcd.irqflags = irqflags;
+
[PATCH v8 10/14] usb: otg: add hcd companion support
From: Yoshihiro Shimoda
Since some host controller (e.g. EHCI) needs a companion host controller
(e.g. OHCI), this patch adds such a configuration to use it in the OTG
core.
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
Documentation/devicetree/bindings/usb/generic.txt | 3 +++
drivers/usb/common/usb-otg.c | 32 ---
include/linux/usb/otg.h | 7 -
3 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/generic.txt
b/Documentation/devicetree/bindings/usb/generic.txt
index f6866c1..1db1c33 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -27,6 +27,9 @@ Optional properties:
- otg-controller: phandle to otg controller. Host or gadget controllers can
contain this property to link it to a particular OTG
controller.
+ - hcd-needs-companion: must be present if otg controller is dealing with
+ EHCI host controller that needs a companion OHCI host
+ controller.
This is an attribute to a USB controller such as:
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index 64be6df..8a2a0d4 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -584,6 +585,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
else
INIT_WORK(&otg->work, usb_drd_work);
+ if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
+ config->hcd_needs_companion)/* needs companion ? */
+ otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
+
otg->wq = create_freezable_workqueue("usb_otg");
if (!otg->wq) {
dev_err(dev, "otg: %s: can't create workqueue\n",
@@ -807,15 +812,18 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned
int irqnum,
/* HCD will be started by OTG fsm when needed */
mutex_lock(&otg->fsm.lock);
if (otg->primary_hcd.hcd) {
- /* probably a shared HCD ? */
- if (usb_otg_hcd_is_primary_hcd(hcd)) {
+ /* probably a shared HCD or a companion OHCI HCD ? */
+ if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
+ usb_otg_hcd_is_primary_hcd(hcd)) {
dev_err(otg_dev, "otg: primary host already
registered\n");
goto err;
}
- if (hcd->shared_hcd == otg->primary_hcd.hcd) {
+ if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
+ (hcd->shared_hcd == otg->primary_hcd.hcd)) {
if (otg->shared_hcd.hcd) {
- dev_err(otg_dev, "otg: shared host already
registered\n");
+ dev_err(otg_dev,
+ "otg: shared/companion host already
registered\n");
goto err;
}
@@ -823,10 +831,12 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned
int irqnum,
otg->shared_hcd.irqnum = irqnum;
otg->shared_hcd.irqflags = irqflags;
otg->shared_hcd.ops = ops;
- dev_info(otg_dev, "otg: shared host %s registered\n",
+ dev_info(otg_dev,
+"otg: shared/companion host %s registered\n",
dev_name(hcd->self.controller));
} else {
- dev_err(otg_dev, "otg: invalid shared host %s\n",
+ dev_err(otg_dev,
+ "otg: invalid shared/companion host %s\n",
dev_name(hcd->self.controller));
goto err;
}
@@ -849,14 +859,17 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned
int irqnum,
* we're ready only if we have shared HCD
* or we don't need shared HCD.
*/
- if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
+ if (otg->shared_hcd.hcd ||
+ (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
+!otg->primary_hcd.hcd->shared_hcd)) {
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(otg);
} else {
- dev_dbg(otg_dev, &quo
[PATCH v8 02/14] usb: otg-fsm: Prevent build warning "VDBG" redefined
If usb/otg-fsm.h and usb/composite.h are included together
then it results in the build warning [1].
Prevent that by defining VDBG locally.
Also get rid of MPC_LOC which doesn't seem to be used
by anyone.
[1] - warning fixed by this patch:
In file included from drivers/usb/dwc3/core.h:33,
from drivers/usb/dwc3/ep0.c:33:
include/linux/usb/otg-fsm.h:30:1: warning: "VDBG" redefined
In file included from drivers/usb/dwc3/ep0.c:31:
include/linux/usb/composite.h:615:1: warning: this is the location
of the previous definition
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
drivers/usb/common/usb-otg-fsm.c | 7 +++
drivers/usb/phy/phy-fsl-usb.c| 7 +++
include/linux/usb/otg-fsm.h | 15 ---
3 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 9059b7d..015cf41 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -30,6 +30,13 @@
#include
#include
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug("[%s] " fmt , \
+__func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
/* Change USB protocol when there is a protocol change */
static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
{
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 94eb292..dd8a1ad 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -44,6 +44,13 @@
#include "phy-fsl-usb.h"
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug("[%s] " fmt , \
+__func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
#define DRIVER_VERSION "Rev. 1.55"
#define DRIVER_AUTHOR "Jerry Huang/Li Yang"
#define DRIVER_DESC "Freescale USB OTG Transceiver Driver"
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 7a03505..a0a8f87 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -21,21 +21,6 @@
#include
#include
-#undef VERBOSE
-
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug("[%s] " fmt , \
-__func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
-#ifdef VERBOSE
-#define MPC_LOC printk("Current Location [%s]:[%d]\n", __FILE__, __LINE__)
-#else
-#define MPC_LOC do {} while (0)
-#endif
-
#define PROTO_UNDEF(0)
#define PROTO_HOST (1)
#define PROTO_GADGET (2)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 03/14] usb: hcd.h: Add OTG to HCD interface
The OTG core will use struct otg_hcd_ops to interface
with the HCD controller.
The main purpose of this interface is to avoid directly
calling HCD APIs from the OTG core as they
wouldn't be defined in the built-in symbol table if
CONFIG_USB is m.
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
include/linux/usb/hcd.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index b98f831..861ccaa 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -399,6 +399,30 @@ struct hc_driver {
};
+/**
+ * struct otg_hcd_ops - Interface between OTG core and HCD
+ *
+ * Provided by the HCD core to allow the OTG core to interface with the HCD
+ *
+ * @add: function to add the HCD
+ * @remove: function to remove the HCD
+ * @usb_bus_start_enum: function to immediately start bus enumeration
+ * @usb_control_msg: function to build and send of a control urb
+ * @usb_hub_find_child: function to get pointer to the child device
+ */
+struct otg_hcd_ops {
+ int (*add)(struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags);
+ void (*remove)(struct usb_hcd *hcd);
+ int (*usb_bus_start_enum)(struct usb_bus *bus, unsigned int port_num);
+ int (*usb_control_msg)(struct usb_device *dev, unsigned int pipe,
+ __u8 request, __u8 requesttype, __u16 value,
+ __u16 index, void *data, __u16 size,
+ int timeout);
+ struct usb_device * (*usb_hub_find_child)(struct usb_device *hdev,
+ int port1);
+};
+
static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)
{
return hcd->driver->flags & HCD_BH;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 01/14] usb: hcd: Initialize hcd->flags to 0
903] r10:0001 r9:ee5f8410 r8:ee731000 r7:00fe r6:ed4290c8 r5: [ 91.758909] r4:ed429000 [ 91.758957] [] (usb_otg_add_hcd [usbcore]) from [] (usb_otg_start_host+0xb8/0xf8) [ 91.758978] r10: r9:0002 r8: r7:ee02b000 r6:ee452808 r5:ee452808 [ 91.758985] r4:ee452808 [ 91.758997] [] (usb_otg_start_host) from [] (drd_set_protocol+0xac/0xd8) [ 91.759007] r4:0001 r3:c047a180 [ 91.759018] [] (drd_set_protocol) from [] (drd_set_state+0x74/0x98) [ 91.759027] r5:ee452808 r4:0009 [ 91.759039] [] (drd_set_state) from [] (usb_otg_work+0xcc/0x154) [ 91.759054] r6:ee452808 r5:ee4528b8 r4:ee452968 r3: [ 91.759072] [] (usb_otg_work) from [] (process_one_work+0x128/0x340) [ 91.759087] r6:ee02ac00 r5:ee452968 r4:ee42b900 r3:c047a310 [ 91.759100] [] (process_one_work) from [] (worker_thread+0x158/0x49c) [ 91.759120] r10:ee42b900 r9:0002 r8:ee02ac00 r7:0088 r6:ee42b918 r5:ee02ac00 [ 91.759127] r4:ee02ac14 [ 91.759145] [] (worker_thread) from [] (kthread+0xdc/0xf8) [ 91.759165] r10: r9: r8: r7:c00577a0 r6:ee42b900 r5:ee429940 [ 91.759174] r4: r3: [ 91.759190] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 91.759206] r7: r6: r5:c005cb64 r4:ee429940 [ 91.759209] handlers: [ 91.759255] [] usb_hcd_irq [usbcore] [ 91.759260] Disabling IRQ #254 Signed-off-by: Roger Quadros Reviewed-by: Peter Chen --- drivers/usb/core/hcd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 2ca2cef..9484539 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -3009,6 +3009,7 @@ void usb_remove_hcd(struct usb_hcd *hcd) } usb_put_invalidate_rhdev(hcd); + hcd->flags = 0; } EXPORT_SYMBOL_GPL(usb_remove_hcd); -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 00/14] USB OTG/dual-role framework
NFIG_OTG dpend on CONFIG_USB_GADGET as well apart from CONFIG_USB - use create_freezable_workqueue() for OTG work as per Peter's suggestion. - remove usb-otg.h as we're not initializing any OTG timers. - don't include unnecessary headers in usb-otg.c (i.e. hrtimer.h & ktime.h) v7: - added dual-role support for host controllers requiring a companion controller. e.g. EHCI + OHCI. - added of_usb_get_otg() to get the OTG controller device from the USB controller's device node. - addressed review comments. v6: - added otg specific APIs for host/gadget registration. behaviour of original host/gadget API remains unchanged. Platform devices can now pass the otg device explicitly while registering host/gadget. - moved hcd specific operations from struct otg_fsm to struct hcd_ops. - made struct usb_otg mandatory for all otg related APIs. - allow otg controller to provide it's own otg_work function so that it can implement it's own state machine. - removed otg fsm and timers from usb-otg.c. Only dual-role state machine is implemented. - vbus is controlled in the dual-role state machine. - PM runtime is used around drd_statemachine(). - added otg_dev to xhci platform data to allow platform code to specify the otg controller tied to the xhci host controller. v5: Internal version. Not sent to mailing list 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 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. -- cheers, -roger Roger Quadros (13): usb: hcd: Initialize hcd->flags to 0 usb: otg-fsm: Prevent build warning "VDBG" redefined usb: hcd.h: Add OTG to HCD interface usb: otg-fsm: use usb_otg wherever possible usb: otg-fsm: move host controller operations into usb_otg->hcd_ops usb: gadget.h: Add OTG to gadget interface usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG usb: otg: add OTG/dual-role core usb: of: add an API to get OTG device from USB controller node usb: otg: use dev_dbg() instead of VDBG() usb: hcd: Adapt to OTG core usb: gadget: udc: adapt to OTG core usb: host: xhci-plat: Add otg device to platform data Yoshihiro Shimoda (1): usb: otg: add hcd companion support Documentation/devicetree/bindings/usb/generic.txt |6 + Documentation/usb/chipidea.txt|2 +- drivers/usb/chipidea/Makefile |2 +- drivers/usb/chipidea/ci.h |3 +- drivers/usb/chipidea/core.c | 14 +- drivers/usb/chipidea/debug.c |2 +- drivers/usb/chipidea/otg_fsm.c| 176 ++-- drivers/usb/chipidea/otg_fsm.h|2 +- drivers/usb/chipidea/udc.c| 17 +- drivers/usb/common/Makefile |3 +- drivers/usb/common/common.c | 27 + drivers/usb/common/usb-otg-fsm.c | 203 ++-- drivers/usb/common/usb-otg.c | 1056 + drivers/usb/core/Kconfig | 12 +- drivers/usb/core/hcd.c| 56 ++ drivers/usb/gadget/udc/udc-core.c | 194 +++- drivers/usb/host/xhci-plat.c | 35 +- drivers/usb/phy/Kconfig |2 +- drivers/usb/phy/phy-fsl-usb.c | 155 +-- drivers/usb/phy/phy-fsl-usb.h |3 +- include/linux/usb/gadget.h| 22 + include/linux/usb/hcd.h | 29 + include/linux/usb/of.h|
Re: [PATCH v7 10/14] usb: otg: add hcd companion support
On 16/05/16 05:13, Peter Chen wrote: > On Thu, May 12, 2016 at 03:13:48PM +0300, Roger Quadros wrote: >> Hi, >> >> On 12/05/16 13:31, Yoshihiro Shimoda wrote: >>> Hi, >>> >>>> From: Roger Quadros >>>> Sent: Thursday, May 12, 2016 6:32 PM >>>> >>>> Hi, >>>> >>>> On 12/05/16 11:34, Roger Quadros wrote: >>>>> On 12/05/16 07:00, Yoshihiro Shimoda wrote: >>>>>> Hi, >>>>>> >>>>>>> From: Alan Stern >>>>>>> Sent: Wednesday, May 11, 2016 11:47 PM >>>>>>> >>>>>>> On Wed, 11 May 2016, Roger Quadros wrote: >>>>>>> >>>>>>>>> What I mean is if you have 2 EHCI controllers with 2 companion >>>>>>>>> controllers, don't you need to know which companion goes with which >>>>>>>>> EHCI >>>>>>>>> controller? Just like you do for the otg-controller property. >>>>>>>>> >>>>>>>> >>>>>>>> That is a very good point. I'm not very sure and it seems that current >>>>>>>> code won't work >>>>>>>> with multiple EHCI + companion instances. >>>>>> >>>>>> I may misunderstand this topic, but if I use the following environment, >>>>>> it works correctly. >>>>>> >>>>>> < My environment > >>>>>> - an otg controller: Sets hcd-needs-companion. >>>>>> - ehci0 and ohci0 and a function: They connect to the otg controller >>>>>> using "otg-controller" property. >>>>>> - ehci1 and ohci1: No "otg-controller" property. >>>>>> - ehci2 and ohci2: No "otg-controller" property. >>>>>> >>>>>> In this environment, all hosts works correctly. >>>>>> Also I think if we have 2 otg controlelrs, it should be work because >>>>>> otg_dev instance differs. >>>>> >>>>> The topic is about more than one otg controllers and how to tie the right >>>>> ehci and ohci >>>>> to the correct otg_dev instance especially in cases where we can't depend >>>>> on probe order. >>>>> >>>>>> Or, does this topic assume an otg controller handles 2 EHCI controllers? >>>>>> I'm not sure such environment actually exists. >>>>> >>>>> No it is not about that. >>> >>> Thank you for the reply. I understood it. >>> >>>>>>>> Alan, does USB core even know which EHCI and OHCI are linked to the >>>>>>>> same port >>>>>>>> or the handoff is software transparent? >>>>>>> >>>>>>> The core knows. It doesn't use the information for a whole lot of >>>>>>> things, but it does use it in a couple of places. Search for >>>>>>> "companion" in core/hcd-pci.c and you'll see. >>>>>> >>>>>> Thank you for the information. I didn't know this code. >>>>>> If my understanding is correct, the core/hcd-pci.c code will not be used >>>>>> by non-PCI devices. >>>>> >>>>> That is correct. >>>>> >>>>>> In other words, nobody sets "hcd->self.hs_companion" if we use such a >>>>>> device. >>>>>> So, I will try to add such a code if needed. >>>>> >>>>> I think OTG core would have to rely on USB core in providing the right >>>>> companion device, >>>>> just like we rely on it for the primary vs shared HCD case. >>>>> >>>> >>>> OK, it is not so simple. >>>> >>>> EHCI and companion port handoff is really meant to be software transparent. >>>> >>>> non-PCI devices really don't have knowledge of which OHCI instance is >>>> companion to the EHCI. >>>> With device tree we could provide this mapping but for non-device tree >>>> case we can't do >>>> anything. >>>> >>>> So my suggestion would be to keep dual role implementation limited to one >>>> instance for >>>> EHCI + companion case for non-DT. >>>> For PCI case I do
Re: [PATCH v8 10/14] usb: otg: add hcd companion support
On 13/05/16 21:13, Rob Herring wrote: > On Fri, May 13, 2016 at 5:03 AM, Roger Quadros wrote: >> From: Yoshihiro Shimoda >> >> Since some host controller (e.g. EHCI) needs a companion host controller >> (e.g. OHCI), this patch adds such a configuration to use it in the OTG >> core. >> >> Signed-off-by: Yoshihiro Shimoda >> Signed-off-by: Roger Quadros >> Acked-by: Peter Chen >> --- >> Documentation/devicetree/bindings/usb/generic.txt | 3 +++ >> drivers/usb/common/usb-otg.c | 32 >> --- >> include/linux/usb/otg.h | 7 - >> 3 files changed, 32 insertions(+), 10 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/generic.txt >> b/Documentation/devicetree/bindings/usb/generic.txt >> index f6866c1..1db1c33 100644 >> --- a/Documentation/devicetree/bindings/usb/generic.txt >> +++ b/Documentation/devicetree/bindings/usb/generic.txt >> @@ -27,6 +27,9 @@ Optional properties: >> - otg-controller: phandle to otg controller. Host or gadget controllers can >> contain this property to link it to a particular OTG >> controller. >> + - hcd-needs-companion: must be present if otg controller is dealing with >> + EHCI host controller that needs a companion OHCI host >> + controller. > > I thought the conclusion was this is not needed? This is still needed to differentiate between primary+shared HCD case vs primary + primary-companion HCD case. > > One thing that is not clear here is otg-controller is a host or device > property while hcd-needs-companion is an OTG controller property. > These lists should be separated. Agreed. I'll fix that up. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
Hi,
On 16/05/16 10:02, Peter Chen wrote:
> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>> +
>> +static int usb_gadget_connect_control(struct usb_gadget *gadget, bool
>> connect)
>> +{
>> +struct usb_udc *udc;
>> +
>> +mutex_lock(&udc_lock);
>> +udc = usb_gadget_to_udc(gadget);
>> +if (!udc) {
>> +dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
>> +__func__);
>> +mutex_unlock(&udc_lock);
>> +return -EINVAL;
>> +}
>> +
>> +if (connect) {
>> +if (!gadget->connected)
>> +usb_gadget_connect(udc->gadget);
>> +} else {
>> +if (gadget->connected) {
>> +usb_gadget_disconnect(udc->gadget);
>> +udc->driver->disconnect(udc->gadget);
>> +}
>> +}
>> +
>> +mutex_unlock(&udc_lock);
>> +
>> +return 0;
>> +}
>> +
>
> Since this is called for vbus interrupt, why not using
> usb_udc_vbus_handler directly, and call udc->driver->disconnect
> at usb_gadget_stop.
We can't assume that this is always called for vbus interrupt so
I decided not to call usb_udc_vbus_handler.
udc->vbus is really pointless for us. We keep vbus states in our
state machine and leave udc->vbus as ture always.
Why do you want to move udc->driver->disconnect() to stop?
If USB controller disconnected from bus then the gadget driver
must be notified about the disconnect immediately. The controller
may or may not be stopped by the core.
>
>> return 0;
>> @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct device
>> *dev,
>> return -EOPNOTSUPP;
>> }
>>
>> +/* In OTG mode we don't support softconnect, but b_bus_req */
>> +if (udc->gadget->otg_dev) {
>> +dev_err(dev, "soft-connect not supported in OTG mode\n");
>> +return -EOPNOTSUPP;
>> +}
>> +
>
> The soft-connect can be supported at dual-role mode currently, we can
> use b_bus_req entry once it is implemented later.
Soft-connect should be done via sysfs handling within the OTG core.
This can be added later. I don't want anything outside the OTG core
to handle soft-connect behaviour as it will be hard to keep things
in sync.
I can update the comment to something like this.
/* In OTG/dual-role mode, soft-connect should be handled by OTG core */
>
>> if (sysfs_streq(buf, "connect")) {
>> usb_gadget_udc_start(udc);
>> -usb_gadget_connect(udc->gadget);
>> +usb_udc_connect_control(udc);
>
> This line seems to be not related with this patch.
>
Right. I'll remove it.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 10/14] usb: otg: add hcd companion support
On 16/05/16 11:13, Peter Chen wrote: > On Mon, May 16, 2016 at 11:01:27AM +0300, Roger Quadros wrote: >> On 16/05/16 05:13, Peter Chen wrote: >>> On Thu, May 12, 2016 at 03:13:48PM +0300, Roger Quadros wrote: >>>> Hi, >>>> >>>> On 12/05/16 13:31, Yoshihiro Shimoda wrote: >>>>> Hi, >>>>> >>>>>> From: Roger Quadros >>>>>> Sent: Thursday, May 12, 2016 6:32 PM >>>>>> >>>>>> Hi, >>>>>> >>>>>> On 12/05/16 11:34, Roger Quadros wrote: >>>>>>> On 12/05/16 07:00, Yoshihiro Shimoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>>> From: Alan Stern >>>>>>>>> Sent: Wednesday, May 11, 2016 11:47 PM >>>>>>>>> >>>>>>>>> On Wed, 11 May 2016, Roger Quadros wrote: >>>>>>>>> >>>>>>>>>>> What I mean is if you have 2 EHCI controllers with 2 companion >>>>>>>>>>> controllers, don't you need to know which companion goes with which >>>>>>>>>>> EHCI >>>>>>>>>>> controller? Just like you do for the otg-controller property. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That is a very good point. I'm not very sure and it seems that >>>>>>>>>> current code won't work >>>>>>>>>> with multiple EHCI + companion instances. >>>>>>>> >>>>>>>> I may misunderstand this topic, but if I use the following >>>>>>>> environment, it works correctly. >>>>>>>> >>>>>>>> < My environment > >>>>>>>> - an otg controller: Sets hcd-needs-companion. >>>>>>>> - ehci0 and ohci0 and a function: They connect to the otg controller >>>>>>>> using "otg-controller" property. >>>>>>>> - ehci1 and ohci1: No "otg-controller" property. >>>>>>>> - ehci2 and ohci2: No "otg-controller" property. >>>>>>>> >>>>>>>> In this environment, all hosts works correctly. >>>>>>>> Also I think if we have 2 otg controlelrs, it should be work because >>>>>>>> otg_dev instance differs. >>>>>>> >>>>>>> The topic is about more than one otg controllers and how to tie the >>>>>>> right ehci and ohci >>>>>>> to the correct otg_dev instance especially in cases where we can't >>>>>>> depend on probe order. >>>>>>> >>>>>>>> Or, does this topic assume an otg controller handles 2 EHCI >>>>>>>> controllers? >>>>>>>> I'm not sure such environment actually exists. >>>>>>> >>>>>>> No it is not about that. >>>>> >>>>> Thank you for the reply. I understood it. >>>>> >>>>>>>>>> Alan, does USB core even know which EHCI and OHCI are linked to the >>>>>>>>>> same port >>>>>>>>>> or the handoff is software transparent? >>>>>>>>> >>>>>>>>> The core knows. It doesn't use the information for a whole lot of >>>>>>>>> things, but it does use it in a couple of places. Search for >>>>>>>>> "companion" in core/hcd-pci.c and you'll see. >>>>>>>> >>>>>>>> Thank you for the information. I didn't know this code. >>>>>>>> If my understanding is correct, the core/hcd-pci.c code will not be >>>>>>>> used by non-PCI devices. >>>>>>> >>>>>>> That is correct. >>>>>>> >>>>>>>> In other words, nobody sets "hcd->self.hs_companion" if we use such a >>>>>>>> device. >>>>>>>> So, I will try to add such a code if needed. >>>>>>> >>>>>>> I think OTG core would have to rely on USB core in providing the right >>>>>>> companion device, >>>>>>> just like we rely
Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
On 13/05/16 13:03, Roger Quadros wrote:
> It provides APIs for the following tasks
>
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine
>
> Provide a dual-role device (DRD) state machine.
> 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/Makefile |2 +-
> drivers/usb/common/usb-otg.c | 1042
> ++
> drivers/usb/core/Kconfig |4 +-
> include/linux/usb/gadget.h |2 +
> include/linux/usb/hcd.h |1 +
> include/linux/usb/otg-fsm.h |7 +
> include/linux/usb/otg.h | 154 ++-
> 7 files changed, 1206 insertions(+), 6 deletions(-)
> create mode 100644 drivers/usb/common/usb-otg.c
This patch causes the following build issues when CONFIG_USB_GADGET=m,
CONFIG_USB=m,
CONFIG_USB_COMMON=m and CONFIG_USB_OTG=y
ERROR: "usb_otg_register_gadget" [drivers/usb/gadget/udc/udc-core.ko] undefined!
ERROR: "usb_otg_unregister_gadget" [drivers/usb/gadget/udc/udc-core.ko]
undefined!
ERROR: "usb_otg_register_hcd" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "usb_otg_unregister_hcd" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "otg_statemachine" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1141: recipe for target 'modules' failed
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs
drivers/built-in.o: In function `drd_set_state':
usb-otg.c:(.text+0x2b4242): undefined reference to `usb_otg_state_string'
drivers/built-in.o: In function `drd_statemachine':
(.text+0x2b4b4c): undefined reference to `usb_otg_state_string'
Makefile:937: recipe for target 'vmlinux' failed
I'll fix it up with the following diff.
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..16a5b55 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -59,5 +59,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS) += renesas_usbhs/
obj-$(CONFIG_USB_GADGET) += gadget/
obj-$(CONFIG_USB_COMMON) += common/
+obj-$(CONFIG_USB_OTG) += common/
obj-$(CONFIG_USBIP_CORE) += usbip/
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index 77048aa..17e449e 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -56,6 +56,30 @@ static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
return hcd == hcd->primary_hcd;
}
+static const char *otg_state_string(enum usb_otg_state state)
+{
+ static const char *const names[] = {
+ [OTG_STATE_A_IDLE] = "a_idle",
+ [OTG_STATE_A_WAIT_VRISE] = "a_wait_vrise",
+ [OTG_STATE_A_WAIT_BCON] = "a_wait_bcon",
+ [OTG_STATE_A_HOST] = "a_host",
+ [OTG_STATE_A_SUSPEND] = "a_suspend",
+ [OTG_STATE_A_PERIPHERAL] = "a_peripheral",
+ [OTG_STATE_A_WAIT_VFALL] = "a_wait_vfall",
+ [OTG_STATE_A_VBUS_ERR] = "a_vbus_err",
+ [OTG_STATE_B_IDLE] = "b_idle",
+ [OTG_STATE_B_SRP_INIT] = "b_srp_init",
+ [OTG_STATE_B_PERIPHERAL] = "b_peripheral",
+ [OTG_STATE_B_WAIT_ACON] = "b_wait_acon",
+ [OTG_STATE_B_HOST] = "b_host",
+ };
+
+ if (state < 0 || state >= ARRAY_SIZE(names))
+ return "UNDEFINED";
+
+ return names[state];
+}
+
/**
* Check if the OTG device is in our wait list and return
* otg_wait_data, else NULL.
@@ -433,7 +457,7 @@ static void drd_set_state(struct otg_fsm *fsm, enum
usb_otg_state new_state)
fsm->state_changed = 1;
dev_dbg(otg->dev, "otg: set state: %s\n",
- usb_otg_state_string(new_state));
+ otg_state_string(new_state));
switch (new_state) {
case OTG_STATE_B_IDLE:
drd_set_protocol(fsm, PROTO_UNDEF);
@@ -449,7 +473,7
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On 16/05/16 12:23, Peter Chen wrote:
> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
>> Hi,
>>
>> On 16/05/16 10:02, Peter Chen wrote:
>>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>>>> +
>>>> +static int usb_gadget_connect_control(struct usb_gadget *gadget, bool
>>>> connect)
>>>> +{
>>>> + struct usb_udc *udc;
>>>> +
>>>> + mutex_lock(&udc_lock);
>>>> + udc = usb_gadget_to_udc(gadget);
>>>> + if (!udc) {
>>>> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
>>>> + __func__);
>>>> + mutex_unlock(&udc_lock);
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + if (connect) {
>>>> + if (!gadget->connected)
>>>> + usb_gadget_connect(udc->gadget);
>>>> + } else {
>>>> + if (gadget->connected) {
>>>> + usb_gadget_disconnect(udc->gadget);
>>>> + udc->driver->disconnect(udc->gadget);
>>>> + }
>>>> + }
>>>> +
>>>> + mutex_unlock(&udc_lock);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>
>>> Since this is called for vbus interrupt, why not using
>>> usb_udc_vbus_handler directly, and call udc->driver->disconnect
>>> at usb_gadget_stop.
>>
>> We can't assume that this is always called for vbus interrupt so
>> I decided not to call usb_udc_vbus_handler.
>>
>> udc->vbus is really pointless for us. We keep vbus states in our
>> state machine and leave udc->vbus as ture always.
>>
>> Why do you want to move udc->driver->disconnect() to stop?
>> If USB controller disconnected from bus then the gadget driver
>> must be notified about the disconnect immediately. The controller
>> may or may not be stopped by the core.
>>
>
> Then, would you give some comments when this API will be used?
> I was assumed it is only used for drd state machine.
drd_state machine didn't even need this API in the first place :).
You guys wanted me to separate out start/stop and connect/disconnect for full
OTG case.
Won't full OTG state machine want to use this API? If not what would it use?
cheers,
-roger
>
>>>
>>>>return 0;
>>>> @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct device
>>>> *dev,
>>>>return -EOPNOTSUPP;
>>>>}
>>>>
>>>> + /* In OTG mode we don't support softconnect, but b_bus_req */
>>>> + if (udc->gadget->otg_dev) {
>>>> + dev_err(dev, "soft-connect not supported in OTG mode\n");
>>>> + return -EOPNOTSUPP;
>>>> + }
>>>> +
>>>
>>> The soft-connect can be supported at dual-role mode currently, we can
>>> use b_bus_req entry once it is implemented later.
>>
>> Soft-connect should be done via sysfs handling within the OTG core.
>> This can be added later. I don't want anything outside the OTG core
>> to handle soft-connect behaviour as it will be hard to keep things
>> in sync.
>>
>> I can update the comment to something like this.
>>
>> /* In OTG/dual-role mode, soft-connect should be handled by OTG core */
>
> Ok, let's Felipe decide it.
>
>>
>>>
>>>>if (sysfs_streq(buf, "connect")) {
>>>>usb_gadget_udc_start(udc);
>>>> - usb_gadget_connect(udc->gadget);
>>>> + usb_udc_connect_control(udc);
>>>
>>> This line seems to be not related with this patch.
>>>
>> Right. I'll remove it.
>>
>> cheers,
>> -roger
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On 17/05/16 10:38, Jun Li wrote:
> Hi
>
>> -Original Message-----
>> From: Roger Quadros [mailto:rog...@ti.com]
>> Sent: Monday, May 16, 2016 5:52 PM
>> To: Peter Chen
>> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
>> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
>> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-usb@vger.kernel.org;
>> linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
>> devicet...@vger.kernel.org
>> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
>>
>> On 16/05/16 12:23, Peter Chen wrote:
>>> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
>>>> Hi,
>>>>
>>>> On 16/05/16 10:02, Peter Chen wrote:
>>>>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>>>>>> +
>>>>>> +static int usb_gadget_connect_control(struct usb_gadget *gadget,
>>>>>> +bool connect) {
>>>>>> +struct usb_udc *udc;
>>>>>> +
>>>>>> +mutex_lock(&udc_lock);
>>>>>> +udc = usb_gadget_to_udc(gadget);
>>>>>> +if (!udc) {
>>>>>> +dev_err(gadget->dev.parent, "%s: gadget not
>> registered.\n",
>>>>>> +__func__);
>>>>>> +mutex_unlock(&udc_lock);
>>>>>> +return -EINVAL;
>>>>>> +}
>>>>>> +
>>>>>> +if (connect) {
>>>>>> +if (!gadget->connected)
>>>>>> +usb_gadget_connect(udc->gadget);
>>>>>> +} else {
>>>>>> +if (gadget->connected) {
>>>>>> +usb_gadget_disconnect(udc->gadget);
>>>>>> +udc->driver->disconnect(udc->gadget);
>>>>>> +}
>>>>>> +}
>>>>>> +
>>>>>> +mutex_unlock(&udc_lock);
>>>>>> +
>>>>>> +return 0;
>>>>>> +}
>>>>>> +
>>>>>
>>>>> Since this is called for vbus interrupt, why not using
>>>>> usb_udc_vbus_handler directly, and call udc->driver->disconnect at
>>>>> usb_gadget_stop.
>>>>
>>>> We can't assume that this is always called for vbus interrupt so I
>>>> decided not to call usb_udc_vbus_handler.
>>>>
>>>> udc->vbus is really pointless for us. We keep vbus states in our
>>>> state machine and leave udc->vbus as ture always.
>>>>
>>>> Why do you want to move udc->driver->disconnect() to stop?
>>>> If USB controller disconnected from bus then the gadget driver must
>>>> be notified about the disconnect immediately. The controller may or
>>>> may not be stopped by the core.
>>>>
>>>
>>> Then, would you give some comments when this API will be used?
>>> I was assumed it is only used for drd state machine.
>>
>> drd_state machine didn't even need this API in the first place :).
>> You guys wanted me to separate out start/stop and connect/disconnect for
>> full OTG case.
>> Won't full OTG state machine want to use this API? If not what would it
>> use?
>
> Instead create those new interfaces/symbol here and there just aim to
> address build problems in diff configures, Could we only allow meaningful
> combination of those 3 drivers configures?
>
> Hcd=y, gadget=y, otg=y or
> Hcd=m, gadget=m, otg=m
This is still a limitation.
It is perfectly fine to have
hcd=m, gadget=y
or
hcd=y, gadget=m
cheers,
-roger
>
> Li Jun
>
>>
>> cheers,
>> -roger
>>
>>>
>>>>>
>>>>>> return 0;
>>>>>> @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct
>> device *dev,
>>>>>> return -EOPNOTSUPP;
>>>>>> }
>>>>>>
>>>>>> +/* In OTG mode we don't support softconnect, but b_bus_req */
>>>>>> +if (udc->gadget->otg_dev)
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On 17/05/16 11:28, Jun Li wrote:
> Hi Roger,
>
>> -Original Message-----
>> From: Roger Quadros [mailto:rog...@ti.com]
>> Sent: Tuesday, May 17, 2016 4:09 PM
>> To: Jun Li ; Peter Chen
>> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
>> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
>> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-usb@vger.kernel.org;
>> linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
>> devicet...@vger.kernel.org
>> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
>>
>> On 17/05/16 10:38, Jun Li wrote:
>>> Hi
>>>
>>>> -Original Message-
>>>> From: Roger Quadros [mailto:rog...@ti.com]
>>>> Sent: Monday, May 16, 2016 5:52 PM
>>>> To: Peter Chen
>>>> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
>>>> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
>>>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
>>>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
>>>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
>>>> r...@kernel.org; nsek...@ti.com; b-...@ti.com;
>>>> linux-usb@vger.kernel.org; linux-o...@vger.kernel.org;
>>>> linux-ker...@vger.kernel.org; devicet...@vger.kernel.org
>>>> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
>>>>
>>>> On 16/05/16 12:23, Peter Chen wrote:
>>>>> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 16/05/16 10:02, Peter Chen wrote:
>>>>>>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>>>>>>>> +
>>>>>>>> +static int usb_gadget_connect_control(struct usb_gadget *gadget,
>>>>>>>> +bool connect) {
>>>>>>>> + struct usb_udc *udc;
>>>>>>>> +
>>>>>>>> + mutex_lock(&udc_lock);
>>>>>>>> + udc = usb_gadget_to_udc(gadget);
>>>>>>>> + if (!udc) {
>>>>>>>> + dev_err(gadget->dev.parent, "%s: gadget not
>>>> registered.\n",
>>>>>>>> + __func__);
>>>>>>>> + mutex_unlock(&udc_lock);
>>>>>>>> + return -EINVAL;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + if (connect) {
>>>>>>>> + if (!gadget->connected)
>>>>>>>> + usb_gadget_connect(udc->gadget);
>>>>>>>> + } else {
>>>>>>>> + if (gadget->connected) {
>>>>>>>> + usb_gadget_disconnect(udc->gadget);
>>>>>>>> + udc->driver->disconnect(udc->gadget);
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + mutex_unlock(&udc_lock);
>>>>>>>> +
>>>>>>>> + return 0;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>
>>>>>>> Since this is called for vbus interrupt, why not using
>>>>>>> usb_udc_vbus_handler directly, and call udc->driver->disconnect at
>>>>>>> usb_gadget_stop.
>>>>>>
>>>>>> We can't assume that this is always called for vbus interrupt so I
>>>>>> decided not to call usb_udc_vbus_handler.
>>>>>>
>>>>>> udc->vbus is really pointless for us. We keep vbus states in our
>>>>>> state machine and leave udc->vbus as ture always.
>>>>>>
>>>>>> Why do you want to move udc->driver->disconnect() to stop?
>>>>>> If USB controller disconnected from bus then the gadget driver must
>>>>>> be notified about the disconnect immediately. The controller may or
>>>>>> may not be stopped by the core.
>>>>>>
>>>>>
>>>>> Then
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On 18/05/16 06:18, Peter Chen wrote:
> On Mon, May 16, 2016 at 12:51:53PM +0300, Roger Quadros wrote:
>> On 16/05/16 12:23, Peter Chen wrote:
>>> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
>>>> Hi,
>>>>
>>>> On 16/05/16 10:02, Peter Chen wrote:
>>>>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>>>>>> +
>>>>>> +static int usb_gadget_connect_control(struct usb_gadget *gadget, bool
>>>>>> connect)
>>>>>> +{
>>>>>> +struct usb_udc *udc;
>>>>>> +
>>>>>> +mutex_lock(&udc_lock);
>>>>>> +udc = usb_gadget_to_udc(gadget);
>>>>>> +if (!udc) {
>>>>>> +dev_err(gadget->dev.parent, "%s: gadget not
>>>>>> registered.\n",
>>>>>> +__func__);
>>>>>> +mutex_unlock(&udc_lock);
>>>>>> +return -EINVAL;
>>>>>> +}
>>>>>> +
>>>>>> +if (connect) {
>>>>>> +if (!gadget->connected)
>>>>>> +usb_gadget_connect(udc->gadget);
>>>>>> +} else {
>>>>>> +if (gadget->connected) {
>>>>>> +usb_gadget_disconnect(udc->gadget);
>>>>>> +udc->driver->disconnect(udc->gadget);
>>>>>> +}
>>>>>> +}
>>>>>> +
>>>>>> +mutex_unlock(&udc_lock);
>>>>>> +
>>>>>> +return 0;
>>>>>> +}
>>>>>> +
>>>>>
>>>>> Since this is called for vbus interrupt, why not using
>>>>> usb_udc_vbus_handler directly, and call udc->driver->disconnect
>>>>> at usb_gadget_stop.
>>>>
>>>> We can't assume that this is always called for vbus interrupt so
>>>> I decided not to call usb_udc_vbus_handler.
>>>>
>>>> udc->vbus is really pointless for us. We keep vbus states in our
>>>> state machine and leave udc->vbus as ture always.
>>>>
>>>> Why do you want to move udc->driver->disconnect() to stop?
>>>> If USB controller disconnected from bus then the gadget driver
>>>> must be notified about the disconnect immediately. The controller
>>>> may or may not be stopped by the core.
>>>>
>>>
>>> Then, would you give some comments when this API will be used?
>>> I was assumed it is only used for drd state machine.
>>
>> drd_state machine didn't even need this API in the first place :).
>> You guys wanted me to separate out start/stop and connect/disconnect for
>> full OTG case.
>> Won't full OTG state machine want to use this API? If not what would it use?
>>
>
> Oh, I meant only drd and fully otg state machine needs it. I am
> wondering if we need have a new API to do it. Two questions:
OK.
>
> - Except for vbus interrupt, any chances this API will be used at
> current logic?
I don't think so. But we can't assume caller behaviour for any API.
> - When this API is called but without a coming gadget->stop?
>
Never for DRD case. But we want to catch wrong users.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
Hi Peter,
On 18/05/16 10:45, Peter Chen wrote:
>
>
> On Mon, May 16, 2016 at 5:00 PM, Roger Quadros <mailto:rog...@ti.com>> wrote:
>
> On 13/05/16 13:03, Roger Quadros wrote:
> > It provides APIs for the following tasks
> >
> > - Registering an OTG/dual-role capable controller
> > - Registering Host and Gadget controllers to OTG core
> > - Providing inputs to and kicking the OTG state machine
> >
> > Provide a dual-role device (DRD) state machine.
> > 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 mailto:rog...@ti.com>>
> > ---
> > drivers/usb/common/Makefile |2 +-
> > drivers/usb/common/usb-otg.c | 1042
> ++
> > drivers/usb/core/Kconfig |4 +-
> > include/linux/usb/gadget.h |2 +
> > include/linux/usb/hcd.h |1 +
> > include/linux/usb/otg-fsm.h |7 +
> > include/linux/usb/otg.h | 154 ++-
> > 7 files changed, 1206 insertions(+), 6 deletions(-)
> > create mode 100644 drivers/usb/common/usb-otg.c
>
>
> This patch causes the following build issues when CONFIG_USB_GADGET=m,
> CONFIG_USB=m,
> CONFIG_USB_COMMON=m and CONFIG_USB_OTG=y
>
> ERROR: "usb_otg_register_gadget" [drivers/usb/gadget/udc/udc-core.ko]
> undefined!
> ERROR: "usb_otg_unregister_gadget" [drivers/usb/gadget/udc/udc-core.ko]
> undefined!
> ERROR: "usb_otg_register_hcd" [drivers/usb/core/usbcore.ko] undefined!
> ERROR: "usb_otg_unregister_hcd" [drivers/usb/core/usbcore.ko] undefined!
> ERROR: "otg_statemachine" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> make[1]: *** [__modpost] Error 1
> Makefile:1141: recipe for target 'modules' failed
> make: *** [modules] Error 2
> make: *** Waiting for unfinished jobs
>
> drivers/built-in.o: In function `drd_set_state':
> usb-otg.c:(.text+0x2b4242): undefined reference to `usb_otg_state_string'
> drivers/built-in.o: In function `drd_statemachine':
> (.text+0x2b4b4c): undefined reference to `usb_otg_state_string'
> Makefile:937: recipe for target 'vmlinux' failed
>
> I'll fix it up with the following diff.
>
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index dca7856..16a5b55 100644
> --- a/drivers/usb/Makefile
> +++ b/drivers/usb/Makefile
> @@ -59,5 +59,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS) += renesas_usbhs/
> obj-$(CONFIG_USB_GADGET) += gadget/
>
> obj-$(CONFIG_USB_COMMON) += common/
> +obj-$(CONFIG_USB_OTG) += common/
>
> obj-$(CONFIG_USBIP_CORE) += usbip/
> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> index 77048aa..17e449e 100644
> --- a/drivers/usb/common/usb-otg.c
> +++ b/drivers/usb/common/usb-otg.c
> @@ -56,6 +56,30 @@ static int usb_otg_hcd_is_primary_hcd(struct usb_hcd
> *hcd)
> return hcd == hcd->primary_hcd;
> }
>
> +static const char *otg_state_string(enum usb_otg_state state)
> +{
> + static const char *const names[] = {
> + [OTG_STATE_A_IDLE] = "a_idle",
> + [OTG_STATE_A_WAIT_VRISE] = "a_wait_vrise",
> + [OTG_STATE_A_WAIT_BCON] = "a_wait_bcon",
> + [OTG_STATE_A_HOST] = "a_host",
> + [OTG_STATE_A_SUSPEND] = "a_suspend",
> + [OTG_STATE_A_PERIPHERAL] = "a_peripheral",
> + [OTG_STATE_A_WAIT_VFALL] = "a_wait_vfall",
> + [OTG_STATE_A_VBUS_ERR] = "a_vbus_err",
> + [OTG_STATE_B_
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On 18/05/16 16:12, Jun Li wrote:
> Hi
>
>> -Original Message-----
>> From: Roger Quadros [mailto:rog...@ti.com]
>> Sent: Wednesday, May 18, 2016 8:43 PM
>> To: Jun Li ; Peter Chen
>> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
>> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
>> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-usb@vger.kernel.org;
>> linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
>> devicet...@vger.kernel.org
>> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
>>
>> On 17/05/16 11:28, Jun Li wrote:
>>> Hi Roger,
>>>
>>>> -Original Message-
>>>> From: Roger Quadros [mailto:rog...@ti.com]
>>>> Sent: Tuesday, May 17, 2016 4:09 PM
>>>> To: Jun Li ; Peter Chen
>>>> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
>>>> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
>>>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
>>>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
>>>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
>>>> r...@kernel.org; nsek...@ti.com; b-...@ti.com;
>>>> linux-usb@vger.kernel.org; linux-o...@vger.kernel.org;
>>>> linux-ker...@vger.kernel.org; devicet...@vger.kernel.org
>>>> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
>>>>
>>>> On 17/05/16 10:38, Jun Li wrote:
>>>>> Hi
>>>>>
>>>>>> -Original Message-
>>>>>> From: Roger Quadros [mailto:rog...@ti.com]
>>>>>> Sent: Monday, May 16, 2016 5:52 PM
>>>>>> To: Peter Chen
>>>>>> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
>>>>>> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
>>>>>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
>>>>>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
>>>>>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
>>>>>> r...@kernel.org; nsek...@ti.com; b-...@ti.com;
>>>>>> linux-usb@vger.kernel.org; linux-o...@vger.kernel.org;
>>>>>> linux-ker...@vger.kernel.org; devicet...@vger.kernel.org
>>>>>> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
>>>>>>
>>>>>> On 16/05/16 12:23, Peter Chen wrote:
>>>>>>> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 16/05/16 10:02, Peter Chen wrote:
>>>>>>>>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>>>>>>>>>> +
>>>>>>>>>> +static int usb_gadget_connect_control(struct usb_gadget
>>>>>>>>>> +*gadget, bool connect) {
>>>>>>>>>> +struct usb_udc *udc;
>>>>>>>>>> +
>>>>>>>>>> +mutex_lock(&udc_lock);
>>>>>>>>>> +udc = usb_gadget_to_udc(gadget);
>>>>>>>>>> +if (!udc) {
>>>>>>>>>> +dev_err(gadget->dev.parent, "%s: gadget not
>>>>>> registered.\n",
>>>>>>>>>> +__func__);
>>>>>>>>>> +mutex_unlock(&udc_lock);
>>>>>>>>>> +return -EINVAL;
>>>>>>>>>> +}
>>>>>>>>>> +
>>>>>>>>>> +if (connect) {
>>>>>>>>>> +if (!gadget->connected)
>>>>>>>>>> +usb_gadget_connect(udc->gadget);
>>>>>>>>>> +} else {
>>>>>>>>>> +if (gadget->connected) {
>>>>>>>>>> +usb_gadget_disconnect(udc->gadget);
>>>>>>>>>> +udc->driver->disconnect(udc->gadget);
>>>>>>>>>> +}
>>>>>>>>>> +}
>>>>>>>>>
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On 18/05/16 17:46, Jun Li wrote:
>
>
I didn't want to have complex Kconfig so decided to have otg as
built-in only.
What do you want me to change in existing code? and why?
>>>
>>> Remove those stuff which only for pass diff driver config Like every
>>> controller driver need a duplicated
>>>
>>> static struct otg_hcd_ops ci_hcd_ops = {
>>> ...
>>> }
>>
>> This is an exception only. Every controller driver doesn't need to
>> implement hcd_ops. It is implemented in the hcd core.
>>
>>>
>>> And here is another example, for gadget connect, otg driver can
>>> directly call to usb_udc_vbus_handler() in drd state machine, but you
>>> create another interface:
>>>
>>> .connect_control = usb_gadget_connect_control,
>>>
>>> If the symbol is defined in one driver which is 'm', another driver
>>> reference it should be 'm' as well, then there is no this kind of
>>> problem as my understanding.
>>
>> That is fine as long as all are 'm'. but how do you solve the case when
>> Gadget is built in and host is 'm'? OTG has to be built-in and you will
>> need an hcd to gadget interface.
>
> Hcd to gadget interface? Or you want to say otg to host interface?
Sorry, I meant to say host to otg interface.
>
> I think hcd and gadget are independent each other, now
>
> Hcd --> otg; and gadget --> otg, (hcd and gadget use otg's symbol)
It is actually a circular dependency for both.
hcd <--> otg and gadget <--> otg
hcd -> otg for usb_otg_register/unregister_hcd
otg -> hcd for usb_add/remove_hcd, usb_bus_start_enum, usb_control_msg,
usb_hub_find_child
gadget -> otg for usb_otg_register/unregister_gadget
otg -> gadget for usb_gadget_start/stop, usb_udc_vbus_handler
Now consider what will happen if I get rid of the otg_hcd and otg_gadget
interfaces.
'y' means built-in, 'm' means module.
1) hcd 'y', gadget 'y'
otg has to be 'y' for proper build.
2) hcd 'm', gadget 'm'
otg has to be 'm' for proper build.
3) hcd 'y', gadget 'm'
Build will fail always.
If otg is 'y', otg build will fail due to dependency on gadget.
If otg is 'm', hcd build will fail due to dependency on otg.
4) hcd 'm', gadget 'y'
Build will fail always.
If otg is 'y', otg build will fail due to dependency on hcd.
If otg is 'm', gadget build will fails due to dependency on otg.
So I solve this problem by adding the otg_hcd_ops and otg_gadget_ops
to remove otg->hcd and otg->gadget dependency.
Now we can address 3) and 4) like so
3) hcd 'y', gadget 'm'
otg has to be 'y' for proper build.
4) hcd 'm', gadget 'y'
otg has to be 'y' for proper build.
>
> If you directly call to usb_udc_vbus_handler() in drd state machine
>
> Then:
>
> Hcd --> otg; and gadget <--> otg, (gadget and otg will refer to symbol of
> each other)
It's not so easy. We are again creating a circular dependency and all
build configurations don't work like I pointed above.
The only optimization I could do is make CONFIG_OTG tristate and
allow it to be built as 'm' if both hcd and gadget are 'm'.
i.e. case (2).
cheers,
-roger
>>
>> Do you have any ideas to solve that case?
>>
>> cheers,
>> -roger
>>
>
>>>
return 0;
@@ -660,9 +830,15 @@ static ssize_t
usb_udc_softconn_store(struct
device *dev,
return -EOPNOTSUPP;
}
+ /* In OTG mode we don't support softconnect, but
>> b_bus_req */
+ if (udc->gadget->otg_dev) {
+ dev_err(dev, "soft-connect not supported in OTG
>> mode\n");
+ return -EOPNOTSUPP;
+ }
+
>>>
>>> The soft-connect can be supported at dual-role mode currently,
>>> we can use b_bus_req entry once it is implemented later.
>>
>> Soft-connect should be done via sysfs handling within the OTG
>> core.
>> This can be added later. I don't want anything outside the OTG
>> core to handle soft-connect behaviour as it will be hard to
>> keep things in sync.
>>
>> I can update the comment to something like this.
>>
>> /* In OTG/dual-role mode, soft-connect should be handled by OTG
>> core */
>
> Ok, let's Felipe decide it.
>
>>
>>>
if (sysfs_streq(buf, "connect")) {
usb_gadget_udc_start(udc);
- usb_gadget_connect(udc->gadget);
+ usb_udc_connect_control(udc);
>>>
>>> This line seems to be not related with this patch.
>>>
>> Right. I'll remove it.
>>
>> cheers,
>> -roger
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
Peter,
On 20/05/16 04:39, Peter Chen wrote:
> On Wed, May 18, 2016 at 03:45:11PM +0300, Roger Quadros wrote:
>> On 18/05/16 06:18, Peter Chen wrote:
>>> On Mon, May 16, 2016 at 12:51:53PM +0300, Roger Quadros wrote:
>>>> On 16/05/16 12:23, Peter Chen wrote:
>>>>> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 16/05/16 10:02, Peter Chen wrote:
>>>>>>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>>>>>>>> +
>>>>>>>> +static int usb_gadget_connect_control(struct usb_gadget *gadget, bool
>>>>>>>> connect)
>>>>>>>> +{
>>>>>>>> + struct usb_udc *udc;
>>>>>>>> +
>>>>>>>> + mutex_lock(&udc_lock);
>>>>>>>> + udc = usb_gadget_to_udc(gadget);
>>>>>>>> + if (!udc) {
>>>>>>>> + dev_err(gadget->dev.parent, "%s: gadget not
>>>>>>>> registered.\n",
>>>>>>>> + __func__);
>>>>>>>> + mutex_unlock(&udc_lock);
>>>>>>>> + return -EINVAL;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + if (connect) {
>>>>>>>> + if (!gadget->connected)
>>>>>>>> + usb_gadget_connect(udc->gadget);
>>>>>>>> + } else {
>>>>>>>> + if (gadget->connected) {
>>>>>>>> + usb_gadget_disconnect(udc->gadget);
>>>>>>>> + udc->driver->disconnect(udc->gadget);
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + mutex_unlock(&udc_lock);
>>>>>>>> +
>>>>>>>> + return 0;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>
>>>>>>> Since this is called for vbus interrupt, why not using
>>>>>>> usb_udc_vbus_handler directly, and call udc->driver->disconnect
>>>>>>> at usb_gadget_stop.
>>>>>>
>>>>>> We can't assume that this is always called for vbus interrupt so
>>>>>> I decided not to call usb_udc_vbus_handler.
>>>>>>
>>>>>> udc->vbus is really pointless for us. We keep vbus states in our
>>>>>> state machine and leave udc->vbus as ture always.
>>>>>>
>>>>>> Why do you want to move udc->driver->disconnect() to stop?
>>>>>> If USB controller disconnected from bus then the gadget driver
>>>>>> must be notified about the disconnect immediately. The controller
>>>>>> may or may not be stopped by the core.
>>>>>>
>>>>>
>>>>> Then, would you give some comments when this API will be used?
>>>>> I was assumed it is only used for drd state machine.
>>>>
>>>> drd_state machine didn't even need this API in the first place :).
>>>> You guys wanted me to separate out start/stop and connect/disconnect for
>>>> full OTG case.
>>>> Won't full OTG state machine want to use this API? If not what would it
>>>> use?
>>>>
>>>
>>> Oh, I meant only drd and fully otg state machine needs it. I am
>>> wondering if we need have a new API to do it. Two questions:
>>
>> OK.
>>>
>>> - Except for vbus interrupt, any chances this API will be used at
>>> current logic?
>>
>> I don't think so. But we can't assume caller behaviour for any API.
>>
>>> - When this API is called but without a coming gadget->stop?
>>>
>> Never for DRD case. But we want to catch wrong users.
>>
>
> In future, otg_start_gadget will be used for both DRD and fully OTG FSM.
> There is no otg_loc_conn at current DRD FSM, but there is
> otg_loc_conn at current OTG FSM, see below.
>
> DRD FSM:
> case OTG_STATE_B_IDLE:
> drd_set_protocol(fsm, PROTO_UNDEF);
> otg_drv_vbus(otg, 0);
> break;
> case OTG_STATE_B_PERIPHERAL:
>
Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
On 18/05/16 15:59, Roger Quadros wrote:
> Hi Peter,
>
> On 18/05/16 10:45, Peter Chen wrote:
>>
>>
>> On Mon, May 16, 2016 at 5:00 PM, Roger Quadros > <mailto:rog...@ti.com>> wrote:
>>
>> On 13/05/16 13:03, Roger Quadros wrote:
>> > It provides APIs for the following tasks
>> >
>> > - Registering an OTG/dual-role capable controller
>> > - Registering Host and Gadget controllers to OTG core
>> > - Providing inputs to and kicking the OTG state machine
>> >
>> > Provide a dual-role device (DRD) state machine.
>> > 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 mailto:rog...@ti.com>>
>> > ---
>> > drivers/usb/common/Makefile |2 +-
>> > drivers/usb/common/usb-otg.c | 1042
>> ++
>> > drivers/usb/core/Kconfig |4 +-
>> > include/linux/usb/gadget.h |2 +
>> > include/linux/usb/hcd.h |1 +
>> > include/linux/usb/otg-fsm.h |7 +
>> > include/linux/usb/otg.h | 154 ++-
>> > 7 files changed, 1206 insertions(+), 6 deletions(-)
>> > create mode 100644 drivers/usb/common/usb-otg.c
>>
>>
>> This patch causes the following build issues when CONFIG_USB_GADGET=m,
>> CONFIG_USB=m,
>> CONFIG_USB_COMMON=m and CONFIG_USB_OTG=y
>>
>> ERROR: "usb_otg_register_gadget" [drivers/usb/gadget/udc/udc-core.ko]
>> undefined!
>> ERROR: "usb_otg_unregister_gadget" [drivers/usb/gadget/udc/udc-core.ko]
>> undefined!
>> ERROR: "usb_otg_register_hcd" [drivers/usb/core/usbcore.ko] undefined!
>> ERROR: "usb_otg_unregister_hcd" [drivers/usb/core/usbcore.ko] undefined!
>> ERROR: "otg_statemachine" [drivers/usb/chipidea/ci_hdrc.ko] undefined!
>> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>> make[1]: *** [__modpost] Error 1
>> Makefile:1141: recipe for target 'modules' failed
>> make: *** [modules] Error 2
>> make: *** Waiting for unfinished jobs
>>
>> drivers/built-in.o: In function `drd_set_state':
>> usb-otg.c:(.text+0x2b4242): undefined reference to `usb_otg_state_string'
>> drivers/built-in.o: In function `drd_statemachine':
>> (.text+0x2b4b4c): undefined reference to `usb_otg_state_string'
>> Makefile:937: recipe for target 'vmlinux' failed
>>
>> I'll fix it up with the following diff.
>>
>> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
>> index dca7856..16a5b55 100644
>> --- a/drivers/usb/Makefile
>> +++ b/drivers/usb/Makefile
>> @@ -59,5 +59,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS) += renesas_usbhs/
>> obj-$(CONFIG_USB_GADGET) += gadget/
>>
>> obj-$(CONFIG_USB_COMMON) += common/
>> +obj-$(CONFIG_USB_OTG) += common/
>>
>> obj-$(CONFIG_USBIP_CORE) += usbip/
>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
>> index 77048aa..17e449e 100644
>> --- a/drivers/usb/common/usb-otg.c
>> +++ b/drivers/usb/common/usb-otg.c
>> @@ -56,6 +56,30 @@ static int usb_otg_hcd_is_primary_hcd(struct usb_hcd
>> *hcd)
>> return hcd == hcd->primary_hcd;
>> }
>>
>> +static const char *otg_state_string(enum usb_otg_state state)
>> +{
>> + static const char *const names[] = {
>> + [OTG_STATE_A_IDLE] = "a_idle",
>> + [OTG_STATE_A_WAIT_VRISE] = "a_wait_vrise",
>> + [OTG_STATE_A_WAIT_BCON] = "a_wait_bco
Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
On 20/05/16 11:31, Roger Quadros wrote: > On 18/05/16 15:59, Roger Quadros wrote: >> Hi Peter, >> >> On 18/05/16 10:45, Peter Chen wrote: >>> >>> >>> On Mon, May 16, 2016 at 5:00 PM, Roger Quadros >> <mailto:rog...@ti.com>> wrote: >>> >>> On 13/05/16 13:03, Roger Quadros wrote: >>> > It provides APIs for the following tasks >>> > >>> > - Registering an OTG/dual-role capable controller >>> > - Registering Host and Gadget controllers to OTG core >>> > - Providing inputs to and kicking the OTG state machine >>> > >>> > Provide a dual-role device (DRD) state machine. >>> > 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 mailto:rog...@ti.com>> >>> > --- >>> > drivers/usb/common/Makefile |2 +- >>> > drivers/usb/common/usb-otg.c | 1042 >>> ++ >>> > drivers/usb/core/Kconfig |4 +- >>> > include/linux/usb/gadget.h |2 + >>> > include/linux/usb/hcd.h |1 + >>> > include/linux/usb/otg-fsm.h |7 + >>> > include/linux/usb/otg.h | 154 ++- >>> > 7 files changed, 1206 insertions(+), 6 deletions(-) >>> > create mode 100644 drivers/usb/common/usb-otg.c >>> >>> >>> This patch causes the following build issues when CONFIG_USB_GADGET=m, >>> CONFIG_USB=m, >>> CONFIG_USB_COMMON=m and CONFIG_USB_OTG=y >>> >>> ERROR: "usb_otg_register_gadget" [drivers/usb/gadget/udc/udc-core.ko] >>> undefined! >>> ERROR: "usb_otg_unregister_gadget" [drivers/usb/gadget/udc/udc-core.ko] >>> undefined! >>> ERROR: "usb_otg_register_hcd" [drivers/usb/core/usbcore.ko] undefined! >>> ERROR: "usb_otg_unregister_hcd" [drivers/usb/core/usbcore.ko] undefined! >>> ERROR: "otg_statemachine" [drivers/usb/chipidea/ci_hdrc.ko] undefined! >>> scripts/Makefile.modpost:91: recipe for target '__modpost' failed >>> make[1]: *** [__modpost] Error 1 >>> Makefile:1141: recipe for target 'modules' failed >>> make: *** [modules] Error 2 >>> make: *** Waiting for unfinished jobs >>> >>> drivers/built-in.o: In function `drd_set_state': >>> usb-otg.c:(.text+0x2b4242): undefined reference to >>> `usb_otg_state_string' >>> drivers/built-in.o: In function `drd_statemachine': >>> (.text+0x2b4b4c): undefined reference to `usb_otg_state_string' >>> Makefile:937: recipe for target 'vmlinux' failed >>> >>> I'll fix it up with the following diff. >>> >>> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile >>> index dca7856..16a5b55 100644 >>> --- a/drivers/usb/Makefile >>> +++ b/drivers/usb/Makefile >>> @@ -59,5 +59,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS) += >>> renesas_usbhs/ >>> obj-$(CONFIG_USB_GADGET) += gadget/ >>> >>> obj-$(CONFIG_USB_COMMON) += common/ >>> +obj-$(CONFIG_USB_OTG) += common/ >>> >>> obj-$(CONFIG_USBIP_CORE) += usbip/ >>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c >>> index 77048aa..17e449e 100644 >>> --- a/drivers/usb/common/usb-otg.c >>> +++ b/drivers/usb/common/usb-otg.c >>> @@ -56,6 +56,30 @@ static int usb_otg_hcd_is_primary_hcd(struct usb_hcd >>> *hcd) >>> return hcd
[PATCH v9 09/14] usb: of: add an API to get OTG device from USB controller node
The OTG controller and the USB controller can be linked via the
'otg-controller' property in the USB controller's device node.
of_usb_get_otg() can be used to get the OTG controller device
from the USB controller's device node.
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
v9:
Clearly indicate which properties are for OTG controller and which ones
are for host/device controllers
Documentation/devicetree/bindings/usb/generic.txt | 7 ++
drivers/usb/common/common.c | 27 +++
include/linux/usb/of.h| 9
3 files changed, 43 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/generic.txt
b/Documentation/devicetree/bindings/usb/generic.txt
index bba8257..0887d6e 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -11,6 +11,8 @@ Optional properties:
"peripheral" and "otg". In case this attribute isn't
passed via DT, USB DRD controllers should default to
OTG.
+
+Optional properties for OTG controllers:
- otg-rev: tells usb driver the release number of the OTG and EH supplement
with which the device and its descriptors are compliant,
in binary-coded decimal (i.e. 2.0 is 0200H). This
@@ -25,6 +27,11 @@ Optional properties:
- adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
optional for OTG device.
+Optional properties for host/device controllers:
+ - otg-controller: phandle to otg controller. Host or gadget controllers can
+ contain this property to link it to a particular OTG
+ controller.
+
This is an attribute to a USB controller such as:
dwc3@4a03 {
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index e3d0161..d7ec471 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -238,6 +238,33 @@ int of_usb_update_otg_caps(struct device_node *np,
}
EXPORT_SYMBOL_GPL(of_usb_update_otg_caps);
+#ifdef CONFIG_USB_OTG
+/**
+ * of_usb_get_otg - get the OTG controller linked to the USB controller
+ * @np: Pointer to the device_node of the USB controller
+ * @otg_caps: Pointer to the target usb_otg_caps to be set
+ *
+ * Returns the OTG controller device or NULL on error.
+ */
+struct device *of_usb_get_otg(struct device_node *np)
+{
+ struct device_node *otg_np;
+ struct platform_device *pdev;
+
+ otg_np = of_parse_phandle(np, "otg-controller", 0);
+ if (!otg_np)
+ return NULL;
+
+ pdev = of_find_device_by_node(otg_np);
+ of_node_put(otg_np);
+ if (!pdev)
+ return NULL;
+
+ return &pdev->dev;
+}
+EXPORT_SYMBOL_GPL(of_usb_get_otg);
+#endif
+
#endif
MODULE_LICENSE("GPL");
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index de3237f..499a4e8 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -40,6 +40,15 @@ static inline struct device_node *usb_of_get_child_node
}
#endif
+#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_OTG)
+struct device *of_usb_get_otg(struct device_node *np);
+#else
+static inline struct device *of_usb_get_otg(struct device_node *np)
+{
+ return NULL;
+}
+#endif
+
#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
#else
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 10/14] usb: otg: add hcd companion support
Since some host controller (e.g. EHCI) needs a companion host controller
(e.g. OHCI), this patch adds such a configuration to use it in the OTG
core.
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
v9:
- add DT property documentation under OTG controllers.
Documentation/devicetree/bindings/usb/generic.txt | 3 +++
drivers/usb/common/usb-otg.c | 32 ---
include/linux/usb/otg.h | 7 -
3 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/generic.txt
b/Documentation/devicetree/bindings/usb/generic.txt
index 0887d6e..6013296 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -26,6 +26,9 @@ Optional properties for OTG controllers:
optional for OTG device.
- adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
optional for OTG device.
+ - hcd-needs-companion: must be present if otg controller is dealing with
+ EHCI host controller that needs a companion OHCI host
+ controller.
Optional properties for host/device controllers:
- otg-controller: phandle to otg controller. Host or gadget controllers can
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index 64be6df..8a2a0d4 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -584,6 +585,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
else
INIT_WORK(&otg->work, usb_drd_work);
+ if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
+ config->hcd_needs_companion)/* needs companion ? */
+ otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
+
otg->wq = create_freezable_workqueue("usb_otg");
if (!otg->wq) {
dev_err(dev, "otg: %s: can't create workqueue\n",
@@ -807,15 +812,18 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned
int irqnum,
/* HCD will be started by OTG fsm when needed */
mutex_lock(&otg->fsm.lock);
if (otg->primary_hcd.hcd) {
- /* probably a shared HCD ? */
- if (usb_otg_hcd_is_primary_hcd(hcd)) {
+ /* probably a shared HCD or a companion OHCI HCD ? */
+ if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
+ usb_otg_hcd_is_primary_hcd(hcd)) {
dev_err(otg_dev, "otg: primary host already
registered\n");
goto err;
}
- if (hcd->shared_hcd == otg->primary_hcd.hcd) {
+ if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
+ (hcd->shared_hcd == otg->primary_hcd.hcd)) {
if (otg->shared_hcd.hcd) {
- dev_err(otg_dev, "otg: shared host already
registered\n");
+ dev_err(otg_dev,
+ "otg: shared/companion host already
registered\n");
goto err;
}
@@ -823,10 +831,12 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned
int irqnum,
otg->shared_hcd.irqnum = irqnum;
otg->shared_hcd.irqflags = irqflags;
otg->shared_hcd.ops = ops;
- dev_info(otg_dev, "otg: shared host %s registered\n",
+ dev_info(otg_dev,
+"otg: shared/companion host %s registered\n",
dev_name(hcd->self.controller));
} else {
- dev_err(otg_dev, "otg: invalid shared host %s\n",
+ dev_err(otg_dev,
+ "otg: invalid shared/companion host %s\n",
dev_name(hcd->self.controller));
goto err;
}
@@ -849,14 +859,17 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned
int irqnum,
* we're ready only if we have shared HCD
* or we don't need shared HCD.
*/
- if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
+ if (otg->shared_hcd.hcd ||
+ (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
+!otg->primary_hcd.hcd->shared_hcd)) {
otg->host = hcd_to_bus(hcd);
/* FIXME: set bus->otg_port if this is true OTG port with HNP */
/* start FSM */
Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
On 20/05/16 12:53, Peter Chen wrote: > On Fri, May 20, 2016 at 12:19:07PM +0300, Roger Quadros wrote: >> On 20/05/16 11:31, Roger Quadros wrote: >>> On 18/05/16 15:59, Roger Quadros wrote: >>>> Hi Peter, >>>> >>>> On 18/05/16 10:45, Peter Chen wrote: >>>>> >>>>> >>>>> On Mon, May 16, 2016 at 5:00 PM, Roger Quadros >>>> <mailto:rog...@ti.com>> wrote: >>>>> >>>>> On 13/05/16 13:03, Roger Quadros wrote: >>>>> > It provides APIs for the following tasks >>>>> > >>>>> > - Registering an OTG/dual-role capable controller >>>>> > - Registering Host and Gadget controllers to OTG core >>>>> > - Providing inputs to and kicking the OTG state machine >>>>> > >>>>> > Provide a dual-role device (DRD) state machine. >>>>> > 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 mailto:rog...@ti.com>> >>>>> > --- >>>>> > drivers/usb/common/Makefile |2 +- >>>>> > drivers/usb/common/usb-otg.c | 1042 >>>>> ++ >>>>> > drivers/usb/core/Kconfig |4 +- >>>>> > include/linux/usb/gadget.h |2 + >>>>> > include/linux/usb/hcd.h |1 + >>>>> > include/linux/usb/otg-fsm.h |7 + >>>>> > include/linux/usb/otg.h | 154 ++- >>>>> > 7 files changed, 1206 insertions(+), 6 deletions(-) >>>>> > create mode 100644 drivers/usb/common/usb-otg.c >>>>> >>>>> >>>>> This patch causes the following build issues when >>>>> CONFIG_USB_GADGET=m, CONFIG_USB=m, >>>>> CONFIG_USB_COMMON=m and CONFIG_USB_OTG=y >>>>> >>>>> ERROR: "usb_otg_register_gadget" [drivers/usb/gadget/udc/udc-core.ko] >>>>> undefined! >>>>> ERROR: "usb_otg_unregister_gadget" >>>>> [drivers/usb/gadget/udc/udc-core.ko] undefined! >>>>> ERROR: "usb_otg_register_hcd" [drivers/usb/core/usbcore.ko] undefined! >>>>> ERROR: "usb_otg_unregister_hcd" [drivers/usb/core/usbcore.ko] >>>>> undefined! >>>>> ERROR: "otg_statemachine" [drivers/usb/chipidea/ci_hdrc.ko] undefined! >>>>> scripts/Makefile.modpost:91: recipe for target '__modpost' failed >>>>> make[1]: *** [__modpost] Error 1 >>>>> Makefile:1141: recipe for target 'modules' failed >>>>> make: *** [modules] Error 2 >>>>> make: *** Waiting for unfinished jobs >>>>> >>>>> drivers/built-in.o: In function `drd_set_state': >>>>> usb-otg.c:(.text+0x2b4242): undefined reference to >>>>> `usb_otg_state_string' >>>>> drivers/built-in.o: In function `drd_statemachine': >>>>> (.text+0x2b4b4c): undefined reference to `usb_otg_state_string' >>>>> Makefile:937: recipe for target 'vmlinux' failed >>>>> >>>>> I'll fix it up with the following diff. >>>>> >>>>> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile >>>>> index dca7856..16a5b55 100644 >>>>> --- a/drivers/usb/Makefile >>>>> +++ b/drivers/usb/Makefile >>>>> @@
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On 23/05/16 06:21, Peter Chen wrote:
> On Sat, May 21, 2016 at 10:29:40AM +0800, Peter Chen wrote:
>> On Thu, May 19, 2016 at 10:32:44AM +0300, Roger Quadros wrote:
>>> On 18/05/16 17:46, Jun Li wrote:
>>>>
>>>>
>>>>>>>
>>>>>>> I didn't want to have complex Kconfig so decided to have otg as
>>>>>>> built-in only.
>>>>>>> What do you want me to change in existing code? and why?
>>>>>>
>>>>>> Remove those stuff which only for pass diff driver config Like every
>>>>>> controller driver need a duplicated
>>>>>>
>>>>>> static struct otg_hcd_ops ci_hcd_ops = {
>>>>>> ...
>>>>>> }
>>>>>
>>>>> This is an exception only. Every controller driver doesn't need to
>>>>> implement hcd_ops. It is implemented in the hcd core.
>>>>>
>>>>>>
>>>>>> And here is another example, for gadget connect, otg driver can
>>>>>> directly call to usb_udc_vbus_handler() in drd state machine, but you
>>>>>> create another interface:
>>>>>>
>>>>>> .connect_control = usb_gadget_connect_control,
>>>>>>
>>>>>> If the symbol is defined in one driver which is 'm', another driver
>>>>>> reference it should be 'm' as well, then there is no this kind of
>>>>>> problem as my understanding.
>>>>>
>>>>> That is fine as long as all are 'm'. but how do you solve the case when
>>>>> Gadget is built in and host is 'm'? OTG has to be built-in and you will
>>>>> need an hcd to gadget interface.
>>>>
>>>> Hcd to gadget interface? Or you want to say otg to host interface?
>>>
>>> Sorry, I meant to say host to otg interface.
>>>
>>>>
>>>> I think hcd and gadget are independent each other, now
>>>>
>>>> Hcd --> otg; and gadget --> otg, (hcd and gadget use otg's symbol)
>>>
>>> It is actually a circular dependency for both.
>>> hcd <--> otg and gadget <--> otg
>>>
>>> hcd -> otg for usb_otg_register/unregister_hcd
>>> otg -> hcd for usb_add/remove_hcd, usb_bus_start_enum, usb_control_msg,
>>> usb_hub_find_child
>>>
>>> gadget -> otg for usb_otg_register/unregister_gadget
>>> otg -> gadget for usb_gadget_start/stop, usb_udc_vbus_handler
>>>
>>> Now consider what will happen if I get rid of the otg_hcd and otg_gadget
>>> interfaces.
>>> 'y' means built-in, 'm' means module.
>>>
>>> 1) hcd 'y', gadget 'y'
>>> otg has to be 'y' for proper build.
>>>
>>> 2) hcd 'm', gadget 'm'
>>> otg has to be 'm' for proper build.
>>>
>>> 3) hcd 'y', gadget 'm'
>>> Build will fail always.
>>> If otg is 'y', otg build will fail due to dependency on gadget.
>>> If otg is 'm', hcd build will fail due to dependency on otg.
>>>
>>> 4) hcd 'm', gadget 'y'
>>> Build will fail always.
>>> If otg is 'y', otg build will fail due to dependency on hcd.
>>> If otg is 'm', gadget build will fails due to dependency on otg.
>>>
>>> So I solve this problem by adding the otg_hcd_ops and otg_gadget_ops
>>> to remove otg->hcd and otg->gadget dependency.
>>>
>>> Now we can address 3) and 4) like so
>>>
>>> 3) hcd 'y', gadget 'm'
>>> otg has to be 'y' for proper build.
>>>
>>> 4) hcd 'm', gadget 'y'
>>> otg has to be 'y' for proper build.
>>>
>>
>> How about this:
>> Moving usb_otg_register/unregister_hcd to host driver to remove
>> dependency hcd->otg. And moving usb_otg_get_data to common.c.
>>
>> Delete the wait queue at usb-otg.c, and if calling usb_otg_get_data
>> returns NULL, the host/device driver's probe return -EPROBE_DEFER.
>> When the otg driver is probed successfully, the host/device will be
>> re-probed again, and usb_otg_register_hcd will be called again.
>>
>> And let OTG depends on HCD && GADGET, and delete otg_hcd_ops and
>> otg_gadget_ops. Below build dependency issues can be fixed.
>> What do you think?
>>
>>> 1) hcd 'y', gadget 'y'
>>> otg has to be 'y' for proper build.
>>>
>>> 2) hcd 'm', gadget 'm'
>>> otg has to be 'm' for proper build.
>>>
>>> 3) hcd 'y', gadget 'm'
>>> Build will fail always.
>>> If otg is 'y', otg build will fail due to dependency on gadget.
>>> If otg is 'm', hcd build will fail due to dependency on otg.
>>>
>>> 4) hcd 'm', gadget 'y'
>>> Build will fail always.
>>> If otg is 'y', otg build will fail due to dependency on hcd.
>>> If otg is 'm', gadget build will fails due to dependency on otg.
>> --
>>
>
> After thinking more, my suggestion can't work. How about moving
> CONFIG_USB_OTG out of CONFIG_USB, in that case, CONFIG_USB_OTG
> can only be built in.
>
I tried this but it still doesn't resolve 3 and 4. I.e.
it can't be automatically set to 'y' when either of hcd/gadget is 'y'
and the other is 'm'.
I think some kconfig trickery can be done to get what we want.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On 23/05/16 13:34, Jun Li wrote:
> Hi
>
>> -Original Message-----
>> From: Roger Quadros [mailto:rog...@ti.com]
>> Sent: Monday, May 23, 2016 6:12 PM
>> To: Peter Chen
>> Cc: Jun Li ; peter.c...@freescale.com; ba...@kernel.org;
>> t...@atomide.com; gre...@linuxfoundation.org; dan.j.willi...@intel.com;
>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
>> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-usb@vger.kernel.org;
>> linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
>> devicet...@vger.kernel.org
>> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
>>
>> On 23/05/16 06:21, Peter Chen wrote:
>>> On Sat, May 21, 2016 at 10:29:40AM +0800, Peter Chen wrote:
>>>> On Thu, May 19, 2016 at 10:32:44AM +0300, Roger Quadros wrote:
>>>>> On 18/05/16 17:46, Jun Li wrote:
>>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>> I didn't want to have complex Kconfig so decided to have otg as
>>>>>>>>> built-in only.
>>>>>>>>> What do you want me to change in existing code? and why?
>>>>>>>>
>>>>>>>> Remove those stuff which only for pass diff driver config Like
>>>>>>>> every controller driver need a duplicated
>>>>>>>>
>>>>>>>> static struct otg_hcd_ops ci_hcd_ops = {
>>>>>>>> ...
>>>>>>>> }
>>>>>>>
>>>>>>> This is an exception only. Every controller driver doesn't need to
>>>>>>> implement hcd_ops. It is implemented in the hcd core.
>>>>>>>
>>>>>>>>
>>>>>>>> And here is another example, for gadget connect, otg driver can
>>>>>>>> directly call to usb_udc_vbus_handler() in drd state machine, but
>>>>>>>> you create another interface:
>>>>>>>>
>>>>>>>> .connect_control = usb_gadget_connect_control,
>>>>>>>>
>>>>>>>> If the symbol is defined in one driver which is 'm', another
>>>>>>>> driver reference it should be 'm' as well, then there is no this
>>>>>>>> kind of problem as my understanding.
>>>>>>>
>>>>>>> That is fine as long as all are 'm'. but how do you solve the case
>>>>>>> when Gadget is built in and host is 'm'? OTG has to be built-in
>>>>>>> and you will need an hcd to gadget interface.
>>>>>>
>>>>>> Hcd to gadget interface? Or you want to say otg to host interface?
>>>>>
>>>>> Sorry, I meant to say host to otg interface.
>>>>>
>>>>>>
>>>>>> I think hcd and gadget are independent each other, now
>>>>>>
>>>>>> Hcd --> otg; and gadget --> otg, (hcd and gadget use otg's symbol)
>>>>>
>>>>> It is actually a circular dependency for both.
>>>>> hcd <--> otg and gadget <--> otg
>>>>>
>>>>> hcd -> otg for usb_otg_register/unregister_hcd otg -> hcd for
>>>>> usb_add/remove_hcd, usb_bus_start_enum, usb_control_msg,
>>>>> usb_hub_find_child
>>>>>
>>>>> gadget -> otg for usb_otg_register/unregister_gadget
>>>>> otg -> gadget for usb_gadget_start/stop, usb_udc_vbus_handler
>>>>>
>>>>> Now consider what will happen if I get rid of the otg_hcd and
>> otg_gadget interfaces.
>>>>> 'y' means built-in, 'm' means module.
>>>>>
>>>>> 1) hcd 'y', gadget 'y'
>>>>> otg has to be 'y' for proper build.
>>>>>
>>>>> 2) hcd 'm', gadget 'm'
>>>>> otg has to be 'm' for proper build.
>>>>>
>>>>> 3) hcd 'y', gadget 'm'
>>>>> Build will fail always.
>>>>> If otg is 'y', otg build will fail due to dependency on gadget.
>>>>> If otg is 'm', hcd build will fail due to dependency on otg.
>>>>>
>>>>> 4) hcd '
Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
Hi Peter,
I have one question here. Please see below.
On 13/05/16 13:03, Roger Quadros wrote:
> It provides APIs for the following tasks
>
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine
>
> Provide a dual-role device (DRD) state machine.
> 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/Makefile |2 +-
> drivers/usb/common/usb-otg.c | 1042
> ++
> drivers/usb/core/Kconfig |4 +-
> include/linux/usb/gadget.h |2 +
> include/linux/usb/hcd.h |1 +
> include/linux/usb/otg-fsm.h |7 +
> include/linux/usb/otg.h | 154 ++-
> 7 files changed, 1206 insertions(+), 6 deletions(-)
> create mode 100644 drivers/usb/common/usb-otg.c
>
> +
> +/**
> + * usb_otg_register() - Register the OTG/dual-role device to OTG core
> + * @dev: OTG/dual-role controller device.
> + * @config: OTG configuration.
> + *
> + * Registers the OTG/dual-role controller device with the USB OTG core.
> + *
> + * Return: struct usb_otg * if success, ERR_PTR() if error.
> + */
> +struct usb_otg *usb_otg_register(struct device *dev,
> + struct usb_otg_config *config)
> +{
> + struct usb_otg *otg;
> + struct otg_wait_data *wait;
> + int ret = 0;
> +
> + if (!dev || !config || !config->fsm_ops)
> + return ERR_PTR(-EINVAL);
> +
> + /* already in list? */
> + mutex_lock(&otg_list_mutex);
> + if (usb_otg_get_data(dev)) {
> + dev_err(dev, "otg: %s: device already in otg list\n",
> + __func__);
> + ret = -EINVAL;
> + goto unlock;
> + }
> +
> + /* allocate and add to list */
> + otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> + if (!otg) {
> + ret = -ENOMEM;
> + goto unlock;
> + }
> +
> + otg->dev = dev;
> + otg->caps = config->otg_caps;
Here, we should be checking if user needs to disable any OTG features. So,
if (dev->of_node)
of_usb_update_otg_caps(dev->of_node, &otg->caps);
Do you agree?
This means we need to change otg->caps from 'struct usb_otg_caps *caps;'
to 'struct usb_otg_caps caps;' so that we can modify the local copy instead
of the one passed by the OTG controller.
We can also move of_usb_update_otg_caps() to otg.h.
We will also need to modify the udc-core code so that it sets gadget->otg_caps
to the modified otg_caps from the OTG core. This will ensure that the right
OTG descriptors are sent.
So we will have to introduce an API.
struct usb_otg_caps *usb_otg_get_otg_caps(struct device *otg_dev)
And in udc-core.c,
static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver
*driver)
{
..
ret = driver->bind(udc->gadget, driver);
if (ret)
goto err1;
/* If OTG, the otg core starts the UDC when needed */
if (udc->gadget->otg_dev) {
+ udc->gadget->is_otg = true;
+ udc->gadget->otg_caps =
usb_otg_get_otg_caps(udc->gadget->otg_dev);
mutex_unlock(&udc_lock);
usb_otg_register_gadget(udc->gadget, &otg_gadget_intf);
mutex_lock(&udc_lock);
} else {
ret = usb_gadget_udc_start(udc);
if (ret) {
driver->unbind(udc->gadget);
goto err1;
}
usb_udc_connect_control(udc);
}
..
}
What do you say?
regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 5/5] usb: dwc3: core: cleanup IRQ resources
On 24/05/16 12:35, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> Implementations might use different IRQs for >> host, gadget and OTG so use named interrupt resources >> to allow Device tree to specify the 3 interrupts. >> >> Following are the interrupt names >> >> Peripheral Interrupt - peripheral >> HOST Interrupt - host >> OTG Interrupt - otg >> >> We still maintain backward compatibility for a single named >> interrupt for all 3 interrupts (e.g. for dwc3-pci) and >> single unnamed interrupt for all 3 interrupts (e.g. old DT). >> >> Signed-off-by: Roger Quadros > > fails to apply, unfortunately: > > checking file drivers/usb/dwc3/core.c > Hunk #1 succeeded at 845 (offset 31 lines). > checking file drivers/usb/dwc3/core.h > Hunk #1 succeeded at 738 (offset 22 lines). > Hunk #2 FAILED at 818. > 1 out of 2 hunks FAILED > checking file drivers/usb/dwc3/gadget.c > Hunk #1 succeeded at 1710 with fuzz 2 (offset 105 lines). > Hunk #2 FAILED at 1728. > Hunk #3 FAILED at 1740. > Hunk #4 succeeded at 2835 (offset 54 lines). > 2 out of 4 hunks FAILED > checking file drivers/usb/dwc3/host.c > > I'll update my testing/next shortly, if you could rebase the remaining > of these patches on that, I'd be glad. No Problem Felipe. I'll rebase and re-send this series. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
On 25/05/16 05:44, Peter Chen wrote:
> On Tue, May 24, 2016 at 12:45:46PM +0300, Roger Quadros wrote:
>> Hi Peter,
>>
>> I have one question here. Please see below.
>>
>> On 13/05/16 13:03, Roger Quadros wrote:
>>> It provides APIs for the following tasks
>>>
>>> - Registering an OTG/dual-role capable controller
>>> - Registering Host and Gadget controllers to OTG core
>>> - Providing inputs to and kicking the OTG state machine
>>>
>>> Provide a dual-role device (DRD) state machine.
>>> 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/Makefile |2 +-
>>> drivers/usb/common/usb-otg.c | 1042
>>> ++
>>> drivers/usb/core/Kconfig |4 +-
>>> include/linux/usb/gadget.h |2 +
>>> include/linux/usb/hcd.h |1 +
>>> include/linux/usb/otg-fsm.h |7 +
>>> include/linux/usb/otg.h | 154 ++-
>>> 7 files changed, 1206 insertions(+), 6 deletions(-)
>>> create mode 100644 drivers/usb/common/usb-otg.c
>>>
>>
>>
>>
>>> +
>>> +/**
>>> + * usb_otg_register() - Register the OTG/dual-role device to OTG core
>>> + * @dev: OTG/dual-role controller device.
>>> + * @config: OTG configuration.
>>> + *
>>> + * Registers the OTG/dual-role controller device with the USB OTG core.
>>> + *
>>> + * Return: struct usb_otg * if success, ERR_PTR() if error.
>>> + */
>>> +struct usb_otg *usb_otg_register(struct device *dev,
>>> +struct usb_otg_config *config)
>>> +{
>>> + struct usb_otg *otg;
>>> + struct otg_wait_data *wait;
>>> + int ret = 0;
>>> +
>>> + if (!dev || !config || !config->fsm_ops)
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + /* already in list? */
>>> + mutex_lock(&otg_list_mutex);
>>> + if (usb_otg_get_data(dev)) {
>>> + dev_err(dev, "otg: %s: device already in otg list\n",
>>> + __func__);
>>> + ret = -EINVAL;
>>> + goto unlock;
>>> + }
>>> +
>>> + /* allocate and add to list */
>>> + otg = kzalloc(sizeof(*otg), GFP_KERNEL);
>>> + if (!otg) {
>>> + ret = -ENOMEM;
>>> + goto unlock;
>>> + }
>>> +
>>> + otg->dev = dev;
>>> + otg->caps = config->otg_caps;
>>
>> Here, we should be checking if user needs to disable any OTG features. So,
>>
>> if (dev->of_node)
>> of_usb_update_otg_caps(dev->of_node, &otg->caps);
>>
>> Do you agree?
>> This means we need to change otg->caps from 'struct usb_otg_caps *caps;'
>> to 'struct usb_otg_caps caps;' so that we can modify the local copy instead
>> of the one passed by the OTG controller.
>
> Why can't modify the one from OTG controller directly?
>
There are 2 things.
1) OTG features supported by hardware. This is the controller's config->otg_caps
2) OTG features needed by system designer. This can be a subset of (1).
This needs to be maintained in the OTG core, based on config->otg_caps and
device tree disable flags.
So we can't use OTG controller config->otg_caps directly.
>>
>> We can also move of_usb_update_otg_caps() to otg.h.
>>
>> We will also need to modify the udc-core code so that it sets
>> gadget->otg_caps
>> to the modified otg_caps from the OTG core. This will ensure that the right
>> OTG descriptors are sent.
>>
>> So we will have to introduce an API.
>>
>> struct usb_otg_caps *usb_otg_get_otg_caps(struct device *otg_dev)
>>
>> And in udc-core.c,
>>
&
Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
On 25/05/16 06:19, Jun Li wrote:
>
>
>> -Original Message-
>> From: Peter Chen [mailto:hzpeterc...@gmail.com]
>> Sent: Wednesday, May 25, 2016 10:44 AM
>> To: Roger Quadros
>> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
>> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
>> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-usb@vger.kernel.org;
>> linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
>> devicet...@vger.kernel.org
>> Subject: Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
>>
>> On Tue, May 24, 2016 at 12:45:46PM +0300, Roger Quadros wrote:
>>> Hi Peter,
>>>
>>> I have one question here. Please see below.
>>>
>>> On 13/05/16 13:03, Roger Quadros wrote:
>>>> It provides APIs for the following tasks
>>>>
>>>> - Registering an OTG/dual-role capable controller
>>>> - Registering Host and Gadget controllers to OTG core
>>>> - Providing inputs to and kicking the OTG state machine
>>>>
>>>> Provide a dual-role device (DRD) state machine.
>>>> 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/Makefile |2 +-
>>>> drivers/usb/common/usb-otg.c | 1042
>> ++
>>>> drivers/usb/core/Kconfig |4 +-
>>>> include/linux/usb/gadget.h |2 +
>>>> include/linux/usb/hcd.h |1 +
>>>> include/linux/usb/otg-fsm.h |7 +
>>>> include/linux/usb/otg.h | 154 ++-
>>>> 7 files changed, 1206 insertions(+), 6 deletions(-) create mode
>>>> 100644 drivers/usb/common/usb-otg.c
>>>>
>>>
>>>
>>>
>>>> +
>>>> +/**
>>>> + * usb_otg_register() - Register the OTG/dual-role device to OTG
>>>> +core
>>>> + * @dev: OTG/dual-role controller device.
>>>> + * @config: OTG configuration.
>>>> + *
>>>> + * Registers the OTG/dual-role controller device with the USB OTG
>> core.
>>>> + *
>>>> + * Return: struct usb_otg * if success, ERR_PTR() if error.
>>>> + */
>>>> +struct usb_otg *usb_otg_register(struct device *dev,
>>>> + struct usb_otg_config *config) {
>>>> + struct usb_otg *otg;
>>>> + struct otg_wait_data *wait;
>>>> + int ret = 0;
>>>> +
>>>> + if (!dev || !config || !config->fsm_ops)
>>>> + return ERR_PTR(-EINVAL);
>>>> +
>>>> + /* already in list? */
>>>> + mutex_lock(&otg_list_mutex);
>>>> + if (usb_otg_get_data(dev)) {
>>>> + dev_err(dev, "otg: %s: device already in otg list\n",
>>>> + __func__);
>>>> + ret = -EINVAL;
>>>> + goto unlock;
>>>> + }
>>>> +
>>>> + /* allocate and add to list */
>>>> + otg = kzalloc(sizeof(*otg), GFP_KERNEL);
>>>> + if (!otg) {
>>>> + ret = -ENOMEM;
>>>> + goto unlock;
>>>> + }
>>>> +
>>>> + otg->dev = dev;
>>>> + otg->caps = config->otg_caps;
>>>
>>> Here, we should be checking if user needs to disable any OTG features.
>>> So,
>>>
>>> if (dev->of_node)
>>> of_usb_update_otg_caps(dev->of_node, &otg->caps);
>>>
>>> Do you agree?
>>> This means we need t
Re: [PATCH 23/62] usb: dwc3: implement runtime PM
Hi Felipe,
On 30/05/16 14:35, Felipe Balbi wrote:
> this patch implements the most basic pm_runtime
> support for dwc3. Whenever USB cable is dettached,
> then we will allow core to runtime_suspend.
>
> Runtime suspending will involve completely tearing
> down event buffers and require a full soft-reset of
> the IP.
>
> Note that a further optimization could be
> implemented once we decide to support hibernation,
> which is to allow runtime_suspend with cable
> connected when bus is in U3. That's subject to a
> separate patch, however.
>
> Tested-by: Baolin Wang
> Signed-off-by: Felipe Balbi
We've discussed this offline but for the record, this patch
breaks DWC3 on OMAP platforms. At least on dra7-evm I could see
both USB host and gadget breaking.
I will try to implement the runtime resume hooks for dwc3-omap
and let you know if we can make it work.
cheers,
-roger
> ---
> drivers/usb/dwc3/core.c | 146
> +-
> drivers/usb/dwc3/core.h | 9 +++
> drivers/usb/dwc3/gadget.c | 32 +-
> 3 files changed, 171 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 80e9affd3d77..167d44375640 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -48,7 +48,7 @@
>
> #include "debug.h"
>
> -/*
> -- */
> +#define DWC3_DEFAULT_AUTOSUSPEND_DELAY 5000 /* ms */
>
> void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
> {
> @@ -996,9 +996,11 @@ static int dwc3_probe(struct platform_device *pdev)
> dma_set_coherent_mask(dev, dev->parent->coherent_dma_mask);
> }
>
> + pm_runtime_set_active(dev);
> + pm_runtime_use_autosuspend(dev);
> + pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
> pm_runtime_enable(dev);
> pm_runtime_get_sync(dev);
> - pm_runtime_forbid(dev);
>
> ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
> if (ret) {
> @@ -1057,7 +1059,7 @@ static int dwc3_probe(struct platform_device *pdev)
> goto err3;
>
> dwc3_debugfs_init(dwc);
> - pm_runtime_allow(dev);
> + pm_runtime_put(dev);
>
> return 0;
>
> @@ -1087,6 +1089,7 @@ static int dwc3_remove(struct platform_device *pdev)
> struct dwc3 *dwc = platform_get_drvdata(pdev);
> struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> + pm_runtime_get_sync(&pdev->dev);
> /*
>* restore res->start back to its original value so that, in case the
>* probe is deferred, we don't end up getting error in request the
> @@ -1100,24 +1103,26 @@ static int dwc3_remove(struct platform_device *pdev)
> dwc3_core_exit(dwc);
> dwc3_ulpi_exit(dwc);
>
> - dwc3_free_event_buffers(dwc);
> - dwc3_free_scratch_buffers(dwc);
> -
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> + dwc3_free_event_buffers(dwc);
> + dwc3_free_scratch_buffers(dwc);
> +
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int dwc3_suspend(struct device *dev)
> +#ifdef CONFIG_PM
> +static int dwc3_suspend_common(struct dwc3 *dwc)
> {
> - struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long flags;
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> case USB_DR_MODE_OTG:
> + spin_lock_irqsave(&dwc->lock, flags);
> dwc3_gadget_suspend(dwc);
> + spin_unlock_irqrestore(&dwc->lock, flags);
> break;
> case USB_DR_MODE_HOST:
> default:
> @@ -1127,18 +1132,14 @@ static int dwc3_suspend(struct device *dev)
>
> dwc3_core_exit(dwc);
>
> - pinctrl_pm_select_sleep_state(dev);
> -
> return 0;
> }
>
> -static int dwc3_resume(struct device *dev)
> +static int dwc3_resume_common(struct dwc3 *dwc)
> {
> - struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long flags;
> int ret;
>
> - pinctrl_pm_select_default_state(dev);
> -
> ret = dwc3_core_init(dwc);
> if (ret)
> return ret;
> @@ -1146,7 +1147,9 @@ static int dwc3_resume(struct device *dev)
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> case USB_DR_MODE_OTG:
> + spin_lock_irqsave(&dwc->lock, flags);
> dwc3_gadget_resume(dwc);
> + spin_unlock_irqrestore(&dwc->lock, flags);
> /* FALLTHROUGH */
> case USB_DR_MODE_HOST:
> default:
> @@ -1154,6 +1157,117 @@ static int dwc3_resume(struct device *dev)
> break;
> }
>
> + return 0;
> +}
> +
> +static int dwc3_runtime_checks(struct dwc3 *dwc)
> +{
> + switch (dwc->dr_mode) {
> + case USB_DR_MODE_PERIPHERAL:
> + case USB_DR_MODE_OTG:
> + if (dwc->connected)
> + return -EBUSY;
> +
Re: [PATCH v8 00/14] USB OTG/dual-role framework
On 30/05/16 12:29, Peter Chen wrote:
> On Fri, May 13, 2016 at 01:03:14PM +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.
>> NOTE: my am437x-gp-evm broke so I couldn't test v8 on it.
>> But the changes since v7 are trivial and shouldn't impact am437x-gp-evm.
>>
>> DWC3 controller and platform related patches will be sent separately.
>>
>> Series is based on v4.6-rc1 and depends on first 2 patches of [1]
>> [1] - OTG fsm cleanup - https://lkml.org/lkml/2016/3/30/186
>>
>> Why?:
>>
>>
>> Currently there is no central location where OTG/dual-role functionality is
>> implemented in the Linux USB stack and every USB controller driver is
>> doing their own thing for OTG/dual-role. We can benefit from code-reuse
>> and simplicity by adding the OTG/dual-role core driver.
>>
>> 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 controllers in dual-role mode. i.e. to stop and start them
>> from a central location. This central location should be the
>> USB OTG/dual-role 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 couldn't be done till now but can be done from the OTG core.
>>
>> What?:
>> -
>>
>> The OTG/dual-role core consists of a set of APIs that allow
>> registration of OTG controller device and OTG capable host and gadget
>> controllers.
>>
>> - The OTG controller driver can provide the OTG capabilities and the
>> Finite State Machine work function via 'struct usb_otg_config'
>> at the time of registration i.e. usb_otg_register();
>>
>> struct usb_otg *usb_otg_register(struct device *dev,
>> struct usb_otg_config *config);
>> int usb_otg_unregister(struct device *dev);
>> /**
>> * struct usb_otg_config - otg controller configuration
>> * @caps: otg capabilities of the controller
>> * @ops: otg fsm operations
>> * @otg_work: optional custom otg state machine work function
>> */
>> struct usb_otg_config {
>> struct usb_otg_caps *otg_caps;
>> struct otg_fsm_ops *fsm_ops;
>> void (*otg_work)(struct work_struct *work);
>> };
>>
>> The dual-role state machine is built-into the OTG core so nothing
>> special needs to be provided if only dual-role functionality is desired.
>> The low level OTG controller driver ops are povided via
>> 'struct otg_fsm_ops *fsm_ops' in the 'struct usb_otg_config'.
>>
>> After registration, the OTG core waits for host, gadget controller
>> and the gadget function driver to be registered. Once all resources are
>> available it instantiates the Finite State Machine (FSM).
>> The host/gadget controllers are started/stopped according to the FSM.
>>
>> - Host and gadget controllers that are a part of OTG/dual-role port must
>> use the OTG core provided APIs to add/remove the host/gadget.
>> i.e. hosts must use usb_otg_add_hcd() usb_otg_remove_hcd(),,
>> gadgets must use usb_otg_add_gadget_udc() usb_del_gadget_udc().
>> This ensures that the host and gadget controllers are not started till
>> the state machine is ready and the right bus conditions are met.
>> It also allows the host and gadget controllers to provide the OTG
>> controller device to link them together. For Device tree boots
>> the related OTG controller is automatically picked up via the
>> 'otg-controller' property in the Host/Gadget controller nodes.
>>
>> int usb_otg_add_hcd(struct usb_hcd *hcd,
>> unsigned int irqnum, unsigned long irqflags,
>> struct device *otg_dev);
>> void usb_otg_remove_hcd(struct usb_hcd *hcd);
>>
>> int usb_otg_add_gadget_udc(struct device *parent,
>> struct usb_gadget *gadget,
>> struct device *otg_dev);
>> usb_del_gadget_udc() must be used for removal.
>>
>>
>> - During the lifetime of the FSM, the OTG controller driver can provide
>> inputs event changes using usb_otg_sync_inputs(). The
[PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources
Implementations might use different IRQs for
host, gadget and OTG so use named interrupt resources
to allow Device tree to specify the 3 interrupts.
Following are the interrupt names
Peripheral Interrupt - peripheral
HOST Interrupt - host
OTG Interrupt - otg
We still maintain backward compatibility for a single named
interrupt for all 3 interrupts (e.g. for dwc3-pci) and
single unnamed interrupt for all 3 interrupts (e.g. old DT).
Signed-off-by: Roger Quadros
---
v9: rebased on top of balbi/testing/next
drivers/usb/dwc3/core.c | 10 --
drivers/usb/dwc3/gadget.c | 20 ++--
drivers/usb/dwc3/host.c | 19 +++
3 files changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9c4e1d8d..5cedf3d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->mem = mem;
dwc->dev = dev;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(dev, "missing IRQ\n");
- return -ENODEV;
- }
- dwc->xhci_resources[1].start = res->start;
- dwc->xhci_resources[1].end = res->end;
- dwc->xhci_resources[1].flags = res->flags;
- dwc->xhci_resources[1].name = res->name;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "missing memory resource\n");
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c37168d..c18c72f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
int ret = 0;
int irq;
- irq = platform_get_irq(to_platform_device(dwc->dev), 0);
+ irq = dwc->irq_gadget;
ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
IRQF_SHARED, "dwc3", dwc->ev_buf);
if (ret) {
@@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
irq, ret);
goto err0;
}
- dwc->irq_gadget = irq;
spin_lock_irqsave(&dwc->lock, flags);
if (dwc->gadget_driver) {
@@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void *_evt)
int dwc3_gadget_init(struct dwc3 *dwc)
{
int ret;
+ struct resource *res;
+ struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
+
+ dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
+ if (dwc->irq_gadget <= 0) {
+ dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev,
+ "dwc_usb3");
+ if (dwc->irq_gadget <= 0) {
+ res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
+ 0);
+ if (!res) {
+ dev_err(dwc->dev, "missing peripheral IRQ\n");
+ return -ENODEV;
+ }
+ dwc->irq_gadget = res->start;
+ }
+ }
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
&dwc->ctrl_req_addr, GFP_KERNEL);
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index c679f63..f2b60a4 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -25,6 +25,25 @@ int dwc3_host_init(struct dwc3 *dwc)
struct platform_device *xhci;
struct usb_xhci_pdata pdata;
int ret;
+ struct resource *res;
+ struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
+
+ res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ, "host");
+ if (!res) {
+ res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ,
+ "dwc_usb3");
+ if (!res) {
+ res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
+ 0);
+ if (!res)
+ return -ENOMEM;
+ }
+ }
+
+ dwc->xhci_resources[1].start = res->start;
+ dwc->xhci_resources[1].end = res->end;
+ dwc->xhci_resources[1].flags = res->flags;
+ dwc->xhci_resources[1].name = res->name;
xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
if (!xhci) {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On 01/06/16 10:38, Peter Chen wrote:
> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>> @@ -530,6 +683,8 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
>> }
>> mutex_unlock(&udc_lock);
>>
>> +mutex_unlock(&udc_lock);
>> +
>
> Here, you have one more mutex_unlock.
Will fix it. Thanks.
>> kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
>> flush_work(&gadget->work);
>> device_unregister(&udc->dev);
>> @@ -539,6 +694,13 @@ EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
>>
>> /*
>> - */
>>
>> +struct otg_gadget_ops otg_gadget_intf = {
>> +.start = usb_gadget_start,
>> +.stop = usb_gadget_stop,
>> +.connect_control = usb_gadget_connect_control,
>> +};
>> +
>> +/* udc_lock must be held */
>> static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver
>> *driver)
>> {
>> int ret;
>> @@ -553,12 +715,20 @@ static int udc_bind_to_driver(struct usb_udc *udc,
>> struct usb_gadget_driver *dri
>> ret = driver->bind(udc->gadget, driver);
>> if (ret)
>> goto err1;
>> -ret = usb_gadget_udc_start(udc);
>> -if (ret) {
>> -driver->unbind(udc->gadget);
>> -goto err1;
>> +
>> +/* If OTG, the otg core starts the UDC when needed */
>> +if (udc->gadget->otg_dev) {
>> +mutex_unlock(&udc_lock);
>> +usb_otg_register_gadget(udc->gadget, &otg_gadget_intf);
>> +mutex_lock(&udc_lock);
>> +} else {
>> +ret = usb_gadget_udc_start(udc);
>> +if (ret) {
>> +driver->unbind(udc->gadget);
>> +goto err1;
>> +}
>> +usb_udc_connect_control(udc);
>> }
>> -usb_udc_connect_control(udc);
>>
>> kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
>> return 0;
>> @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct device
>> *dev,
>> return -EOPNOTSUPP;
>> }
>>
>> +/* In OTG mode we don't support softconnect, but b_bus_req */
>> +if (udc->gadget->otg_dev) {
>> +dev_err(dev, "soft-connect not supported in OTG mode\n");
>> +return -EOPNOTSUPP;
>> +}
>> +
>> if (sysfs_streq(buf, "connect")) {
>> usb_gadget_udc_start(udc);
>> -usb_gadget_connect(udc->gadget);
>> +usb_udc_connect_control(udc);
>> } else if (sysfs_streq(buf, "disconnect")) {
>> usb_gadget_disconnect(udc->gadget);
>> udc->driver->disconnect(udc->gadget);
>> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> index 3ecfddd..79d654f 100644
>> --- a/include/linux/usb/gadget.h
>> +++ b/include/linux/usb/gadget.h
>> @@ -1162,6 +1162,10 @@ extern int usb_add_gadget_udc(struct device *parent,
>> struct usb_gadget *gadget);
>> extern void usb_del_gadget_udc(struct usb_gadget *gadget);
>> extern char *usb_get_gadget_udc_name(void);
>>
>> +extern int usb_otg_add_gadget_udc(struct device *parent,
>> + struct usb_gadget *gadget,
>> + struct device *otg_dev);
>> +
>>
>> /*-*/
>>
>> /* utility to simplify dealing with string descriptors */
>> --
>> 2.7.4
>>
--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
Hi, On 06/06/16 06:04, Lu Baolu wrote: > Hi Peter, > > On 06/06/2016 09:25 AM, Peter Chen wrote: >> On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote: >>> Hi Peter, >>> >>> On 06/04/2016 10:28 AM, Peter Chen wrote: On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote: >> from my point,it is a dual-role switch >> driver too, > No, it's not a dual-role switch driver, but a driver for USB port > multiplexing. > > One example of port multiplexing can be found in several Intel SOC and PCH > chips, inside of which, there are two independent USB controllers: host > and > device. They might share a single port and this port could be configured > to > route the line to one of these two controllers. This patch introduced a > generic > framework for port mux drivers. It aids the drivers to handle port mux by > providing interfaces to 1) register/unregister a mux device; 2) lookup the > mux device; and 3) switch the port. > For this case, I can't see it is different with dual-role switch. >>> Port mux is part of dual role switch, but not the whole thing. >>> >>> Dual role switch includes at least below things: >>> - ID or type-C event detection >>> - port mux >>> - VBUS management >>> - start/stop host/device controllers >>> >>> An OTG/Dual-role framework can be used to keep all these >>> things run together with an internal state machine. But it's >>> not duplicated with a generic framework for port mux and >>> the port mux drivers. >> You have admitted port mux is one of the ports of dual-role switch, >> Then, how they can co-work with each other? If can't, the dual-role >> switch framework needs another input events management for switching. > > My point is we need a generic framework for the port mux devices, > just like we have that for PHY and regulator. OTG framework > manages the port mux devices through the common interfaces > provided by the port mux framework. > > If we integrate the port mux device support into OTG itself, this will > force every use case of port mux to rely on the big OTG framework, > although what it needs is only a single driver. That causes unnecessary > software complexity. I agree with Lu here. Intel platforms seem to actually have a Mux device and we need a device driver for that. OTG/dual-role core cannot directly handle the Mux device. The Mux device can be used not only for dual-role but for other things so we can't force it to use just OTG/dual-role. For Mux devices implementing dual-role, the mux device driver _must_ use OTG/dual-role core API so that a common ABI is presented to user space for OTG/dual-role. I haven't yet looked at the mux framework but if we take care of the above point then we are not introducing any redundancy. > >> Your case is just like Renesas case, which uses two different drivers between peripheral and host[1]. >>> In my case, the port mux devices are physical devices and they >>> can be controlled through GPIO pins or device registers. They >>> are independent of both peripheral and host controllers. >>> >> Yes, it is the same. GPIO pin or device registers is like ID pin >> event. >> > > > >>> But this code is better co-work with OTG/Dual-role framework, we'd >>> better have only interface that the user can know which role for the >>> current port. >>> OTG/Dual-role framework and portmux framework are not overlapped. >>> The sysfs interface shouldn't be overlapped as well. Say, I have a port >>> mux device and I have a driver for it. I am able to read the status of my >>> port mux device through sysfs. This is not part of OTG/Dual-role as far >>> as I can see. >>> >> Then how the user wants to switch the role through the mux driver's >> sysfs or dual-role switch sysfs? >> > > It depends. If you have an OTG/DRD capable controllers, you need to > do this through OTG sysfs; otherwise you only need to switch the port. > -- cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 23/62] usb: dwc3: implement runtime PM
Felipe, On 30/05/16 15:42, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> On 30/05/16 14:35, Felipe Balbi wrote: >>> this patch implements the most basic pm_runtime >>> support for dwc3. Whenever USB cable is dettached, >>> then we will allow core to runtime_suspend. >>> >>> Runtime suspending will involve completely tearing >>> down event buffers and require a full soft-reset of >>> the IP. >>> >>> Note that a further optimization could be >>> implemented once we decide to support hibernation, >>> which is to allow runtime_suspend with cable >>> connected when bus is in U3. That's subject to a >>> separate patch, however. >>> >>> Tested-by: Baolin Wang >>> Signed-off-by: Felipe Balbi >> >> We've discussed this offline but for the record, this patch >> breaks DWC3 on OMAP platforms. At least on dra7-evm I could see >> both USB host and gadget breaking. >> >> I will try to implement the runtime resume hooks for dwc3-omap >> and let you know if we can make it work. > > cool, thanks :-) > On testing branch commit [1], dwc3 breaks after system suspend/resume on dra7-evm. [1] - cd45299a0f3a41f25729a523aecc0f3e6ad14d43 cheers, -roger signature.asc Description: OpenPGP digital signature
Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources
Felipe, On 01/06/16 11:06, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> Implementations might use different IRQs for >> host, gadget and OTG so use named interrupt resources >> to allow Device tree to specify the 3 interrupts. >> >> Following are the interrupt names >> >> Peripheral Interrupt - peripheral >> HOST Interrupt - host >> OTG Interrupt - otg >> >> We still maintain backward compatibility for a single named >> interrupt for all 3 interrupts (e.g. for dwc3-pci) and >> single unnamed interrupt for all 3 interrupts (e.g. old DT). >> >> Signed-off-by: Roger Quadros >> --- >> v9: rebased on top of balbi/testing/next > > breaks dwc3: > > [ 222.776504] dwc3 dwc3.0.auto: failed to request irq #-6 --> -22 > > please test > I couldn't reproduce the failure at my end. Could it be specific to your setup? cheers, -roger signature.asc Description: OpenPGP digital signature
Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources
On 02/06/16 14:52, Grygorii Strashko wrote:
> On 06/01/2016 10:46 AM, Roger Quadros wrote:
>> Implementations might use different IRQs for
>> host, gadget and OTG so use named interrupt resources
>> to allow Device tree to specify the 3 interrupts.
>>
>> Following are the interrupt names
>>
>> Peripheral Interrupt - peripheral
>> HOST Interrupt - host
>> OTG Interrupt - otg
>
> or "dwc_usb3"??
That is for backward compatibility only. I could explicitly
mention it in the next line.
>
>>
>> We still maintain backward compatibility for a single named
>> interrupt for all 3 interrupts (e.g. for dwc3-pci) and
>> single unnamed interrupt for all 3 interrupts (e.g. old DT).
>
> bindings
OK.
>
>>
>> Signed-off-by: Roger Quadros
>> ---
>> v9: rebased on top of balbi/testing/next
>>
>> drivers/usb/dwc3/core.c | 10 --
>> drivers/usb/dwc3/gadget.c | 20 ++--
>> drivers/usb/dwc3/host.c | 19 +++
>> 3 files changed, 37 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 9c4e1d8d..5cedf3d 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
>> dwc->mem = mem;
>> dwc->dev = dev;
>>
>> -res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> -if (!res) {
>> -dev_err(dev, "missing IRQ\n");
>> -return -ENODEV;
>> -}
>> -dwc->xhci_resources[1].start = res->start;
>> -dwc->xhci_resources[1].end = res->end;
>> -dwc->xhci_resources[1].flags = res->flags;
>> -dwc->xhci_resources[1].name = res->name;
>> -
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> if (!res) {
>> dev_err(dev, "missing memory resource\n");
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index c37168d..c18c72f 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>> intret = 0;
>> intirq;
>>
>> -irq = platform_get_irq(to_platform_device(dwc->dev), 0);
>> +irq = dwc->irq_gadget;
>> ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
>> IRQF_SHARED, "dwc3", dwc->ev_buf);
>> if (ret) {
>> @@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>> irq, ret);
>> goto err0;
>> }
>> -dwc->irq_gadget = irq;
>>
>> spin_lock_irqsave(&dwc->lock, flags);
>> if (dwc->gadget_driver) {
>> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void *_evt)
>> int dwc3_gadget_init(struct dwc3 *dwc)
>> {
>> intret;
>> +struct resource *res;
>> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>> +
>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
>> +if (dwc->irq_gadget <= 0) {
>
> Is it expected to get -EPROBE_DEFER here?
Probably not as we don't have any chance of deferring probe here. We've already
probed successfully and are just turning on the gadget mode here.
>
>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev,
>> + "dwc_usb3");
>> +if (dwc->irq_gadget <= 0) {
>> +res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
>> +0);
>
> It's better to use platform_get_irq().
OK.
>
>> +if (!res) {
>> +dev_err(dwc->dev, "missing peripheral IRQ\n");
>> +return -ENODEV;
>> +}
>> +dwc->irq_gadget = res->start;
>> +}
>> +}
>>
>> dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
>> &dwc->ctrl_req_addr, GFP_KERNEL);
>> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
>> index c679f63..f2b60a4 100644
>> --- a/drivers/usb/dwc3/host.c
>> +++ b/drivers/usb/dwc3/host.c
>> @@ -25,6 +25,25 @@ int dwc3_host_init(struct dwc3 *dwc)
>> struct platform_device*xhci;
>> struct usb_xhci_pdatapdata;
>>
Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources
On 07/06/16 14:49, Grygorii Strashko wrote:
> On 06/07/2016 12:34 PM, Roger Quadros wrote:
>> On 02/06/16 14:52, Grygorii Strashko wrote:
>>> On 06/01/2016 10:46 AM, Roger Quadros wrote:
>>>> Implementations might use different IRQs for
>>>> host, gadget and OTG so use named interrupt resources
>>>> to allow Device tree to specify the 3 interrupts.
>>>>
>>>> Following are the interrupt names
>>>>
>>>> Peripheral Interrupt - peripheral
>>>> HOST Interrupt - host
>>>> OTG Interrupt - otg
>>>
>>> or "dwc_usb3"??
>>
>> That is for backward compatibility only. I could explicitly
>> mention it in the next line.
>
> yes pls, this confuses.
> Also I don't see how "otg" irq name is used in code.
>
OK. I'll remove it from the commit message.
>>
>>>
>>>>
>>>> We still maintain backward compatibility for a single named
>>>> interrupt for all 3 interrupts (e.g. for dwc3-pci) and
>>>> single unnamed interrupt for all 3 interrupts (e.g. old DT).
>>>
>>> bindings
>>
>> OK.
>>>
>>>>
>>>> Signed-off-by: Roger Quadros
>>>> ---
>>>> v9: rebased on top of balbi/testing/next
>>>>
>>>>drivers/usb/dwc3/core.c | 10 --
>>>>drivers/usb/dwc3/gadget.c | 20 ++--
>>>>drivers/usb/dwc3/host.c | 19 +++
>>>>3 files changed, 37 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>> index 9c4e1d8d..5cedf3d 100644
>>>> --- a/drivers/usb/dwc3/core.c
>>>> +++ b/drivers/usb/dwc3/core.c
>>>> @@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
>>>>dwc->mem = mem;
>>>>dwc->dev = dev;
>>>>
>>>> -res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>>>> -if (!res) {
>>>> -dev_err(dev, "missing IRQ\n");
>>>> -return -ENODEV;
>>>> -}
>>>> -dwc->xhci_resources[1].start = res->start;
>>>> -dwc->xhci_resources[1].end = res->end;
>>>> -dwc->xhci_resources[1].flags = res->flags;
>>>> -dwc->xhci_resources[1].name = res->name;
>>>> -
>>>>res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>if (!res) {
>>>>dev_err(dev, "missing memory resource\n");
>>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>>> index c37168d..c18c72f 100644
>>>> --- a/drivers/usb/dwc3/gadget.c
>>>> +++ b/drivers/usb/dwc3/gadget.c
>>>> @@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>>>intret = 0;
>>>>intirq;
>>>>
>>>> -irq = platform_get_irq(to_platform_device(dwc->dev), 0);
>>>> +irq = dwc->irq_gadget;
>>>>ret = request_threaded_irq(irq, dwc3_interrupt,
>>>> dwc3_thread_interrupt,
>>>>IRQF_SHARED, "dwc3", dwc->ev_buf);
>>>>if (ret) {
>>>> @@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>>>irq, ret);
>>>>goto err0;
>>>>}
>>>> -dwc->irq_gadget = irq;
>>>>
>>>>spin_lock_irqsave(&dwc->lock, flags);
>>>>if (dwc->gadget_driver) {
>>>> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void
>>>> *_evt)
>>>>int dwc3_gadget_init(struct dwc3 *dwc)
>>>>{
>>>>intret;
>>>> +struct resource *res;
>>>> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>>>> +
>>>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
>>>> +if (dwc->irq_gadget <= 0) {
>>>
>>> Is it expected to get -EPROBE_DEFER here?
>>
>> Probably not as we don't have any chance of deferring probe here. We've
>> already
>> probed successfully and are just turning on the gadget mode here.
>
> In general, you can't say that you've been probed successfully if not all
> resources are ready,
> and irq is a resource :)
> It's expected that all resources will be requested in probe, but here you are
> trying to get
> resource outside of probe. As result, it will be perfectly possible to get
> -EPROBE_DEFER here
> if on some HW GPIO IRQ will be used as peripheral, or host or otg irq (for
> example), because
> GPIO IRQ controller might not be ready at the moment when IRQ resource is
> requested.
I agree with you.
Felipe, are you ok with moving the IRQ resource obtaining code to probe?
--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
On 07/06/16 12:27, Lu Baolu wrote: > Hi, > > On 06/07/2016 02:34 PM, Jun Li wrote: On 06/07/2016 11:03 AM, Jun Li wrote: >> Hi Roger >> For Mux devices implementing dual-role, the mux device driver _must_ use OTG/dual-role core API so that a common ABI is presented to user space for OTG/dual-role. >> That's the only point we have concern, do dual role switch through >> OTG/dual-role core, not do it by itself. That really depends on how do you define "dual role". Can you please provide an unambiguous definition of "dual role" used in OTG/dual-role framework? >> Host and peripheral. >> > > This is definitely ambiguous. > > By reading OTG/dual-role code, my understanding is that "dual-role" is a > "reduced OTG" which is for DRD devices lacking of some OTG negotiation > protocols. DRD means dual role with zero OTG features, which is similar to just host and peripheral mode. > > We really can't say "it's the scope of OTG/dual-role" whenever it comes to > "host and peripheral". What other combination you foresee? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
On 07/06/16 12:53, Lu Baolu wrote: > Hi, > > On 06/07/2016 11:03 AM, Jun Li wrote: >> Hi Roger >> >>> >>> For Mux devices implementing dual-role, the mux device driver _must_ use >>> OTG/dual-role core API so that a common ABI is presented to user space for >>> OTG/dual-role. >> That's the only point we have concern, do dual role switch through >> OTG/dual-role core, not do it by itself. >> >>> I haven't yet looked at the mux framework but if we take care of the above >>> point then we are not introducing any redundancy. >>> >> Roger, actually this is my worry on OTG core: those dual role switch >> users just tends to do it simply by itself(straightforward and easy), >> not through the OTG core(some complicated in first look), > > I'm sorry, but I'm really confused. > > Why do we need to drop "straightforward and easy", but have to run > an *unnecessary* OTG state machine? Don't you think that will (1) add > *unnecessary* software complexity; (2) increase *unnecessary* memory > footprint; and (3) increase the debugging efforts? > >> this is just an example for us to convince people to select a better >> way:) > > Sure. Let's take my case for an example. > > My system has a third-party port mux, which is not part any USB controllers. > Also, my system doesn't have any DRD capable devices. I need a > "straightforward and easy" driver for it. Otherwise, the system could not be > waken up from system suspend. > > But you said I must run an unnecessary OTG state machine, even thought it > has nothing to do with my system, only because the two sides of my port > mux device is a host and peripheral controller. We have a minimal dual-role state machine that just looks at ID pin and toggles the port role. How are you switching the port mux between host and peripheral? Only by sysfs or do you have a GPIO for ID pin as well? What happens to the gadget controller when the port is muxed to the host controller? Is it stopped or it continues to run? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
On 07/06/16 16:04, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >>> But you said I must run an unnecessary OTG state machine, even thought it >>> has nothing to do with my system, only because the two sides of my port >>> mux device is a host and peripheral controller. >> >> We have a minimal dual-role state machine that just looks at ID pin >> and toggles the port role. > > I don't know if we want to bring all that extra baggage just to write a > few bits in a single register. Even for DWC3-only dual-role (what > Synopsys licenses as part of some DWC3 instantiations), the OTG/DRD > layer is a bit overkill. > > If you take my testing/next, for example, we have everything we need for > dual-role; except for OTG/DRD IRQ handler. Just look at how we implement > ->suspend()/->resume() and it's be clear that we're just missing one > step. > > I might be able to find some time to implement a proof of concept which > would allow your platforms to get dual-role with code we already have, > but I need DWC3's OTG support which, I'm assuming, you already have :-) > > If you wanna try something offline, just ping me ;-) I'll be happy to > help. What you are proposing is a dwc3 only solution. With the otg/dual-role series we are trying to be generic as much as possible. Whether controller drivers want to use it or not is upto the driver maintainers but we should at least ensure that user space ABI if any, is consistent across different implementations. > >> How are you switching the port mux between host and peripheral? Only >> by sysfs or do you have a GPIO for ID pin as well? > > depends. Some SoCs have GPIO-controller muxes while some just have mux's > select signals (one for ID, one for VBUS) mapped on xHCI's address > space. > >> What happens to the gadget controller when the port is muxed to the >> host controller? Is it stopped or it continues to run? > > it continues running, but that's pretty irrelevant for Intel's dual-role Isn't that unnecessary waste of power? Or you have firmware assisted low power mode? > setup. We have an actual physical (inside the die, though) mux which > muxes USB signals to XHCI (not DWC3's XHCI) or to a peripheral-only > DWC3. > Probably irrelevant for Intel's dual-role but many platforms that share the port can't have device controller running when port is in host mode and vice versa. So there has to be a central point of control where the respective controllers are started/stopped. That is the other point we are trying to address with the common otg/dual-role code. Even in the TI dwc3 implementation we use dwc3's XHCI so I guess we need to stop the host controller for device mode, right? If so then who will deal with start/stop of the controllers then? So for Intel port-mux case it seems that OTG/dual-role is overcomplicated and I wouldn't force you to use it. It is upto Peter to decide how he wants dual-role users to behave. cheers, -roger signature.asc Description: OpenPGP digital signature
Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources
On 07/06/16 16:09, Felipe Balbi wrote:
>
> Hi,
>
> (guys, please make sure to break lines at 80-columns)
>
> Roger Quadros writes:
>>>>>> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void
>>>>>> *_evt)
>>>>>>int dwc3_gadget_init(struct dwc3 *dwc)
>>>>>>{
>>>>>>intret;
>>>>>> +struct resource *res;
>>>>>> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>>>>>> +
>>>>>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
>>>>>> +if (dwc->irq_gadget <= 0) {
>>>>>
>>>>> Is it expected to get -EPROBE_DEFER here?
>>>>
>>>> Probably not as we don't have any chance of deferring probe here. We've
>>>> already
>>>> probed successfully and are just turning on the gadget mode here.
>>>
>>> In general, you can't say that you've been probed successfully if not
>>> all resources are ready, and irq is a resource :) It's expected that
>>> all resources will be requested in probe, but here you are trying to
>>> get resource outside of probe. As result, it will be perfectly
>>> possible to get -EPROBE_DEFER here if on some HW GPIO IRQ will be
>>> used as peripheral, or host or otg irq (for example), because GPIO
>>> IRQ controller might not be ready at the moment when IRQ resource is
>>> requested.
>>
>> I agree with you.
>>
>> Felipe, are you ok with moving the IRQ resource obtaining code to probe?
>
> You mean that probe() would setup all gadget_irq, otg_irq and host_irq
> while the other pieces (otg.c, gadget.c and host.c) only use it?
>
> yeah, that should be fine. No problems.
>
OK great. I'll fix this up then. Thanks.
cheers,
-roger
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
Hi,
On 24/05/16 05:53, Peter Chen wrote:
> On Mon, May 23, 2016 at 01:36:51PM +0300, Roger Quadros wrote:
>> On 23/05/16 13:34, Jun Li wrote:
>>> Hi
>>>
>>>> -Original Message-
>>>> From: Roger Quadros [mailto:rog...@ti.com]
>>>> Sent: Monday, May 23, 2016 6:12 PM
>>>> To: Peter Chen
>>>> Cc: Jun Li ; peter.c...@freescale.com; ba...@kernel.org;
>>>> t...@atomide.com; gre...@linuxfoundation.org; dan.j.willi...@intel.com;
>>>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
>>>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
>>>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
>>>> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-usb@vger.kernel.org;
>>>> linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
>>>> devicet...@vger.kernel.org
>>>> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
>>>>
>>>> On 23/05/16 06:21, Peter Chen wrote:
>>>>> On Sat, May 21, 2016 at 10:29:40AM +0800, Peter Chen wrote:
>>>>>> On Thu, May 19, 2016 at 10:32:44AM +0300, Roger Quadros wrote:
>>>>>>> On 18/05/16 17:46, Jun Li wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I didn't want to have complex Kconfig so decided to have otg as
>>>>>>>>>>> built-in only.
>>>>>>>>>>> What do you want me to change in existing code? and why?
>>>>>>>>>>
>>>>>>>>>> Remove those stuff which only for pass diff driver config Like
>>>>>>>>>> every controller driver need a duplicated
>>>>>>>>>>
>>>>>>>>>> static struct otg_hcd_ops ci_hcd_ops = {
>>>>>>>>>> ...
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> This is an exception only. Every controller driver doesn't need to
>>>>>>>>> implement hcd_ops. It is implemented in the hcd core.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And here is another example, for gadget connect, otg driver can
>>>>>>>>>> directly call to usb_udc_vbus_handler() in drd state machine, but
>>>>>>>>>> you create another interface:
>>>>>>>>>>
>>>>>>>>>> .connect_control = usb_gadget_connect_control,
>>>>>>>>>>
>>>>>>>>>> If the symbol is defined in one driver which is 'm', another
>>>>>>>>>> driver reference it should be 'm' as well, then there is no this
>>>>>>>>>> kind of problem as my understanding.
>>>>>>>>>
>>>>>>>>> That is fine as long as all are 'm'. but how do you solve the case
>>>>>>>>> when Gadget is built in and host is 'm'? OTG has to be built-in
>>>>>>>>> and you will need an hcd to gadget interface.
>>>>>>>>
>>>>>>>> Hcd to gadget interface? Or you want to say otg to host interface?
>>>>>>>
>>>>>>> Sorry, I meant to say host to otg interface.
>>>>>>>
>>>>>>>>
>>>>>>>> I think hcd and gadget are independent each other, now
>>>>>>>>
>>>>>>>> Hcd --> otg; and gadget --> otg, (hcd and gadget use otg's symbol)
>>>>>>>
>>>>>>> It is actually a circular dependency for both.
>>>>>>> hcd <--> otg and gadget <--> otg
>>>>>>>
>>>>>>> hcd -> otg for usb_otg_register/unregister_hcd otg -> hcd for
>>>>>>> usb_add/remove_hcd, usb_bus_start_enum, usb_control_msg,
>>>>>>> usb_hub_find_child
>>>>>>>
>>>>>>> gadget -> otg for usb_otg_register/unregister_gadget
>>>>>>> otg -> gadget for usb_gadget_start/stop, usb_udc_vbus_handler
>>>>>>>
>>>>>>> Now consider what will happen if I get rid of the otg_hcd and
>>>> otg_gadget interfaces.
>>>>>>> 'y' means built-in
Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
On 07/06/16 18:05, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >>> I might be able to find some time to implement a proof of concept which >>> would allow your platforms to get dual-role with code we already have, >>> but I need DWC3's OTG support which, I'm assuming, you already have :-) >>> >>> If you wanna try something offline, just ping me ;-) I'll be happy to >>> help. >> >> What you are proposing is a dwc3 only solution. With the otg/dual-role >> series we are trying to be generic as much as possible. > > Well, if there is a need for that, sure. Take MUSB for instance. It > makes use of nothing of the sorts, because it doesn't have to. > >> Whether controller drivers want to use it or not is upto the driver >> maintainers but we should at least ensure that user space ABI if any, >> is consistent across different implementations. > > Role decisions should not be exposed to userspace unless as debug > feature (using e.g. DebugFS). That should be done either by the HW or > within the kernel. > > If we're discussing userspace ABI here, there's something very wrong > with OTG/DRD layer design. Not really. There can be a need for user space application to control the port role. Consider Apple carplay for instance or even full OTG support which has user selectable role. > >>>> How are you switching the port mux between host and peripheral? Only >>>> by sysfs or do you have a GPIO for ID pin as well? >>> >>> depends. Some SoCs have GPIO-controller muxes while some just have mux's >>> select signals (one for ID, one for VBUS) mapped on xHCI's address >>> space. >>> >>>> What happens to the gadget controller when the port is muxed to the >>>> host controller? Is it stopped or it continues to run? >>> >>> it continues running, but that's pretty irrelevant for Intel's dual-role >> >> Isn't that unnecessary waste of power? Or you have firmware assisted >> low power mode? > > that's an implementation detail which brings nothing to this discussion, > right? :-) > > We can, certainly, put the other side to D3. > >>> setup. We have an actual physical (inside the die, though) mux which >>> muxes USB signals to XHCI (not DWC3's XHCI) or to a peripheral-only >>> DWC3. >>> >> >> Probably irrelevant for Intel's dual-role but many platforms that >> share the port can't have device controller running when port is in >> host mode and vice versa. > > but that doesn't mean we need an entire new layer added to the kernel > ;-) > > DWC3 already gives us all the information necessary to make a decision > on which role we should assume. Just consider your options. Here's how > things would look like without any OTG/DRD layer: > > -> DWC3 OTG IRQ > -> readl(OSTS); > -> if (OSTS & BIT(4)) >-> dwc3_host_exit(); __dwc3_gadget_start(); > -> else >-> __dwc3_gadget_stop(); dwc3_host_init(); > > Can you draw something similar for your proposed OTG/DRD layer? What about B_IDLE state? We don't want either peripheral or host to run when no cable is inserted. Have you tested if it works? I'd be happy to test if you can prepare a patch to get dual-role working on dwc3 without the OTG/DRD layer :). > > I remember there were at least two schedule_work(). IIRC it looked > something like below: > > -> DWC3 OTG IRQ > -> readl(OSTS); > -> if (OSTS & BIT(4)) >-> otg_set_mode(PERIPHERAL); > -> schedule_work(); > -> otg_ops->stop_host(); > -> usb_del_hcd(); > -> otg_ops->start_peripheral(); > -> usb_gadget_add_udc(); > -> else >-> otg_set_mode(HOST); > -> schedule_work(); > -> otg_ops->stop_peripheral(); > -> usb_gadget_del_udc(); > -> otg_ops->start_host(); > -> usb_add_hcd(); > > I'm probably missing some steps there. As a user you just need to do this reg = read(OSTS); dwc->otg->fsm.id = !!(reg & STS_ID); dwc->otg->fsm.b_sess_vld = !!(reg &STS_BSESVLD); usb_otg_sync_inputs(dwc->otg); And the layer does the rest. But as I said earlier. I have absolutely no issues if dwc3 doesn't use that layer as long as dual-role works on our platforms. > >> So there has to be a central point of control where the respective >> controllers are started/stopped. > > some implementations might need this, yes. DWC3 and MUSB don't seem to > be this type of system. OK. > >> That is the other point we are trying to address with the common >> otg/dual-role code. >> >> Even in the TI dwc3 implementation we use dwc3's XHCI so I guess we need >> to stop the host controller for device mode, right? > > yes, see above. We already have that code. Just code is not enough. We need to know if it works :). > >> If so then who will deal with start/stop of the controllers then? > > dwc3 itself. > OK. cheers, -roger signature.asc Description: OpenPGP digital signature
[PATCH v9 02/14] usb: otg-fsm: Prevent build warning "VDBG" redefined
If usb/otg-fsm.h and usb/composite.h are included together
then it results in the build warning [1].
Prevent that by defining VDBG locally.
Also get rid of MPC_LOC which doesn't seem to be used
by anyone.
[1] - warning fixed by this patch:
In file included from drivers/usb/dwc3/core.h:33,
from drivers/usb/dwc3/ep0.c:33:
include/linux/usb/otg-fsm.h:30:1: warning: "VDBG" redefined
In file included from drivers/usb/dwc3/ep0.c:31:
include/linux/usb/composite.h:615:1: warning: this is the location
of the previous definition
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
drivers/usb/common/usb-otg-fsm.c | 7 +++
drivers/usb/phy/phy-fsl-usb.c| 7 +++
include/linux/usb/otg-fsm.h | 15 ---
3 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 9059b7d..199dee0 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -30,6 +30,13 @@
#include
#include
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug("[%s] " fmt, \
+__func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
/* Change USB protocol when there is a protocol change */
static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
{
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 94eb292..a8784ec 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -44,6 +44,13 @@
#include "phy-fsl-usb.h"
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug("[%s] " fmt, \
+__func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
#define DRIVER_VERSION "Rev. 1.55"
#define DRIVER_AUTHOR "Jerry Huang/Li Yang"
#define DRIVER_DESC "Freescale USB OTG Transceiver Driver"
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 7a03505..a0a8f87 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -21,21 +21,6 @@
#include
#include
-#undef VERBOSE
-
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug("[%s] " fmt , \
-__func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
-#ifdef VERBOSE
-#define MPC_LOC printk("Current Location [%s]:[%d]\n", __FILE__, __LINE__)
-#else
-#define MPC_LOC do {} while (0)
-#endif
-
#define PROTO_UNDEF(0)
#define PROTO_HOST (1)
#define PROTO_GADGET (2)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 14/14] usb: host: xhci-plat: Add otg device to platform data
Host controllers that are part of an OTG/dual-role instance
need to somehow pass the OTG controller device information
to the HCD core.
We use platform data to pass the OTG controller device.
Signed-off-by: Roger Quadros
Reviewed-by: Peter Chen
---
drivers/usb/host/xhci-plat.c | 35 ---
include/linux/usb/xhci_pdriver.h | 3 +++
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 676ea45..24d030a 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -239,11 +239,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_usb3_hcd;
}
- ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+ if (pdata && pdata->otg_dev)
+ ret = usb_otg_add_hcd(hcd, irq, IRQF_SHARED, pdata->otg_dev);
+ else
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+
if (ret)
goto disable_usb_phy;
- ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+ if (pdata && pdata->otg_dev)
+ ret = usb_otg_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED,
+ pdata->otg_dev);
+ else
+ ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+
if (ret)
goto dealloc_usb2_hcd;
@@ -251,7 +260,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
dealloc_usb2_hcd:
- usb_remove_hcd(hcd);
+ if (pdata && pdata->otg_dev)
+ usb_otg_remove_hcd(hcd);
+ else
+ usb_remove_hcd(hcd);
disable_usb_phy:
usb_phy_shutdown(hcd->usb_phy);
@@ -269,16 +281,25 @@ put_hcd:
return ret;
}
-static int xhci_plat_remove(struct platform_device *dev)
+static int xhci_plat_remove(struct platform_device *pdev)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
+ struct usb_xhci_pdata *pdata = dev_get_platdata(&pdev->dev);
+
+ if (pdata && pdata->otg_dev)
+ usb_otg_remove_hcd(xhci->shared_hcd);
+ else
+ usb_remove_hcd(xhci->shared_hcd);
- usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
- usb_remove_hcd(hcd);
+ if (pdata && pdata->otg_dev)
+ usb_otg_remove_hcd(hcd);
+ else
+ usb_remove_hcd(hcd);
+
usb_put_hcd(xhci->shared_hcd);
if (!IS_ERR(clk))
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..5c68b83 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,13 @@
*
* @usb3_lpm_capable: determines if this xhci platform supports USB3
* LPM capability
+ * @otg_dev: OTG controller device. Only requied if part of
+ * OTG/dual-role.
*
*/
struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+ struct device *otg_dev;
};
#endif /* __USB_CORE_XHCI_PDRIVER_H */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 13/14] usb: gadget: udc: adapt to OTG core
The OTG state machine needs a mechanism to start and
stop the gadget controller as well as connect/disconnect
from the bus. Add usb_gadget_start(), usb_gadget_stop()
and usb_gadget_connect_control().
Introduce usb_otg_add_gadget_udc() to allow controller drivers
to register a gadget controller that is part of an OTG instance.
Register with OTG core when UDC is added in usb_add_gadget_udc_release()
and unregister on usb_del_gadget_udc().
Notify the OTG core when gadget function driver is available on
udc_bind_to_driver() and when it is removed in usb_gadget_remove_driver().
We need to unlock the usb_lock mutex before calling
usb_otg_register_gadget() else it will cause a circular
locking dependency.
Ignore softconnect sysfs control when we're in OTG
mode as OTG FSM should care of gadget softconnect using
the b_bus_req mechanism.
Signed-off-by: Roger Quadros
---
drivers/usb/gadget/udc/udc-core.c | 202 --
include/linux/usb/gadget.h| 4 +
2 files changed, 196 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 6e8300d..a80a6c9 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,11 @@
#include
#include
#include
+#include
+#include
+
+#include
+#include
/**
* struct usb_udc - describes one usb device controller
@@ -337,6 +342,113 @@ static inline void usb_gadget_udc_stop(struct usb_udc
*udc)
}
/**
+ * usb_gadget_to_udc - get the UDC owning the gadget
+ *
+ * udc_lock must be held.
+ * Returs NULL if UDC is not found.
+ */
+static struct usb_udc *usb_gadget_to_udc(struct usb_gadget *gadget)
+{
+ struct usb_udc *udc;
+
+ list_for_each_entry(udc, &udc_list, list)
+ if (udc->gadget == gadget)
+ return udc;
+
+ return NULL;
+}
+
+/**
+ * usb_gadget_start - start the usb gadget controller
+ * @gadget: the gadget device to start
+ *
+ * This is external API for use by OTG core.
+ *
+ * Start the usb device controller. Does not connect to the bus.
+ */
+static int usb_gadget_start(struct usb_gadget *gadget)
+{
+ int ret;
+ struct usb_udc *udc;
+
+ mutex_lock(&udc_lock);
+ udc = usb_gadget_to_udc(gadget);
+ if (!udc) {
+ dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
+ __func__);
+ mutex_unlock(&udc_lock);
+ return -EINVAL;
+ }
+
+ ret = usb_gadget_udc_start(udc);
+ if (ret)
+ dev_err(&udc->dev, "USB Device Controller didn't start: %d\n",
+ ret);
+
+ mutex_unlock(&udc_lock);
+
+ return ret;
+}
+
+/**
+ * usb_gadget_stop - stop the usb gadget controller
+ * @gadget: the gadget device we want to stop
+ *
+ * This is external API for use by OTG core.
+ *
+ * Stop the gadget controller. Does not disconnect from the bus.
+ * Caller must ensure that gadget has disconnected from the bus
+ * before calling usb_gadget_stop().
+ */
+static int usb_gadget_stop(struct usb_gadget *gadget)
+{
+ struct usb_udc *udc;
+
+ mutex_lock(&udc_lock);
+ udc = usb_gadget_to_udc(gadget);
+ if (!udc) {
+ dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
+ __func__);
+ mutex_unlock(&udc_lock);
+ return -EINVAL;
+ }
+
+ if (gadget->connected)
+ dev_dbg(gadget->dev.parent,
+ "%s: called while still connected\n", __func__);
+
+ usb_gadget_udc_stop(udc);
+ mutex_unlock(&udc_lock);
+
+ return 0;
+}
+
+static int usb_gadget_connect_control(struct usb_gadget *gadget, bool connect)
+{
+ struct usb_udc *udc;
+
+ mutex_lock(&udc_lock);
+ udc = usb_gadget_to_udc(gadget);
+ if (!udc) {
+ dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
+ __func__);
+ mutex_unlock(&udc_lock);
+ return -EINVAL;
+ }
+
+ if (connect) {
+ usb_gadget_connect(udc->gadget);
+ } else {
+ usb_gadget_disconnect(udc->gadget);
+ udc->driver->disconnect(udc->gadget);
+ }
+
+ mutex_unlock(&udc_lock);
+
+ return 0;
+}
+
+/**
* usb_udc_release - release the usb_udc struct
* @dev: the dev member within usb_udc
*
@@ -359,6 +471,12 @@ static void usb_udc_nop_release(struct device *dev)
dev_vdbg(dev, "%s\n", __func__);
}
+struct otg_gadget_ops otg_gadget_intf = {
+ .start = usb_gadget_start,
+ .stop = usb_gadget_stop,
+ .connect_control = usb_gadget_connect_control,
+};
+
/**
* usb_add_gadget_udc_release - adds a new gadget to the udc class driver list
* @par
[PATCH v9 12/14] usb: hcd: Adapt to OTG core
Introduce usb_otg_add/remove_hcd() for use by host
controllers that are part of OTG/dual-role port.
Non Device tree platforms can use the otg_dev argument
to specify the OTG controller device. If otg_dev is NULL
then the device tree node's otg-controller property is used to
get the otg_dev device.
Signed-off-by: Roger Quadros
Acked-by: Peter Chen
---
drivers/usb/core/hcd.c | 55 +
include/linux/usb/hcd.h | 4
2 files changed, 59 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index ae6c76d..c6f4155 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -46,6 +46,11 @@
#include
#include
#include
+#include
+#include
+
+#include
+#include
#include "usb.h"
@@ -3025,6 +3030,56 @@ void usb_remove_hcd(struct usb_hcd *hcd)
}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
+static struct otg_hcd_ops otg_hcd_intf = {
+ .add = usb_add_hcd,
+ .remove = usb_remove_hcd,
+ .usb_bus_start_enum = usb_bus_start_enum,
+ .usb_control_msg = usb_control_msg,
+ .usb_hub_find_child = usb_hub_find_child,
+};
+
+/**
+ * usb_otg_add_hcd - Register the HCD with OTG core.
+ * @hcd: the usb_hcd structure to initialize
+ * @irqnum: Interrupt line to allocate
+ * @irqflags: Interrupt type flags
+ * @otg_dev: OTG controller device managing this HCD
+ *
+ * Registers the HCD with OTG core. OTG core will call usb_add_hcd()
+ * or usb_remove_hcd() as necessary.
+ * If otg_dev is NULL then device tree node is checked for OTG
+ * controller device via the otg-controller property.
+ */
+int usb_otg_add_hcd(struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags,
+ struct device *otg_dev)
+{
+ struct device *dev = hcd->self.controller;
+
+ if (!otg_dev) {
+ hcd->otg_dev = of_usb_get_otg(dev->of_node);
+ if (!hcd->otg_dev)
+ return -ENODEV;
+ } else {
+ hcd->otg_dev = otg_dev;
+ }
+
+ return usb_otg_register_hcd(hcd, irqnum, irqflags, &otg_hcd_intf);
+}
+EXPORT_SYMBOL_GPL(usb_otg_add_hcd);
+
+/**
+ * usb_otg_remove_hcd - Unregister the HCD with OTG core.
+ * @hcd: the usb_hcd structure to remove
+ *
+ * Unregisters the HCD from the OTG core.
+ */
+void usb_otg_remove_hcd(struct usb_hcd *hcd)
+{
+ usb_otg_unregister_hcd(hcd);
+}
+EXPORT_SYMBOL_GPL(usb_otg_remove_hcd);
+
void
usb_hcd_platform_shutdown(struct platform_device *dev)
{
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 845c761..2331b48 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -473,6 +473,10 @@ extern int usb_hcd_is_primary_hcd(struct usb_hcd *hcd);
extern int usb_add_hcd(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags);
extern void usb_remove_hcd(struct usb_hcd *hcd);
+extern int usb_otg_add_hcd(struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags,
+ struct device *otg_dev);
+extern void usb_otg_remove_hcd(struct usb_hcd *hcd);
extern int usb_hcd_find_raw_port_number(struct usb_hcd *hcd, int port1);
struct platform_device;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
