Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
, will be fixed in gadget > >>> mode, but it will do gadget connect and disconnect in its diff states, > >>> so, to make the framework common, let's keep them separated. > >> > >> I'm sorry but I didn't understand your comment about "it will do gadget > >> connect and disconnect in its diff states" > > > > Gadget connect means loc_conn(1). > > > >> > >> I am reading the OTG v2.0 specification and loc_conn is always true when > >> b_peripheral or a_peripheral is true and false otherwise. > > > > If you only talk about these 2 states, yes, loc_conn is ture. > > > >> > >> loc_conn is just an internal state variable and it corresponds to our > >> gadget_start/stop() state. > > > > It's not an internal variable, there are OTG state machine > > parameters tables(table 7-x) in OTG spec which have clear lists > > which are "internal variable", which are "input", which are "output"... > > > > Those APIs are driven directly from OTG spec, easily understood so > > code reader can know what's those APIs for. For real OTG, I don't > > see the benefit if get rid of it. > > OK, no issues if we don't get rid of it. But I am still in favor of > doing a connect in usb_gadget_start(), because > > 1) If we split connect/disconnect() and usb_gadget_start/stop() then there is > additional overhead of keeping track whether connect was called or not during > usb_gadget_stop(). Plus we need to take care that users don't call > connect/disconnect > outside of start/stop. It is just complicating things. > > 2) for many controllers there is no difference between run/stop and > connect/disconnect. i.e. a single register bit controls both. > > 3) it fits well with the OTG specification. OTG specification says > that loc_conn *variable* must be true *after* the device has signalled a > connect. > So OTG state machine can safely set loc_conn variable to true after doing > otg_set_protocol(fsm, PROTO_GADGET); and set it to false otherwise. > > Note, OTG specification does not say to take any action based on loc_conn. > It is just a connect indicator variable. So we might have to fix this in the > OTG state machine. > > My suggestion is to keep it simple for now. Try the OTG implementation, > and later if we find issues then extend it as required. > I agree with you, roger. loc_conn action is only needed for peripheral, we can't do real !loc_conn at host mode. Besides, loc_conn is the output, we need to set/clear it after state has changed, and current gadget framework already takes well for connection and disconnection state, so it is better to delete loc_conn action at otg_fsm->ops, and only keeps it as indicator for OTG FSM reference. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
, will be fixed in gadget
> >>> mode, but it will do gadget connect and disconnect in its diff states,
> >>> so, to make the framework common, let's keep them separated.
> >>
> >> I'm sorry but I didn't understand your comment about "it will do gadget
> >> connect and disconnect in its diff states"
> >
> > Gadget connect means loc_conn(1).
> >
> >>
> >> I am reading the OTG v2.0 specification and loc_conn is always true when
> >> b_peripheral or a_peripheral is true and false otherwise.
> >
> > If you only talk about these 2 states, yes, loc_conn is ture.
> >
> >>
> >> loc_conn is just an internal state variable and it corresponds to our
> >> gadget_start/stop() state.
> >
> > It's not an internal variable, there are OTG state machine
> > parameters tables(table 7-x) in OTG spec which have clear lists
> > which are "internal variable", which are "input", which are "output"...
> >
> > Those APIs are driven directly from OTG spec, easily understood so
> > code reader can know what's those APIs for. For real OTG, I don't
> > see the benefit if get rid of it.
>
> OK, no issues if we don't get rid of it. But I am still in favor of
> doing a connect in usb_gadget_start(), because
>
> 1) If we split connect/disconnect() and usb_gadget_start/stop() then there is
> additional overhead of keeping track whether connect was called or not during
> usb_gadget_stop(). Plus we need to take care that users don't call
> connect/disconnect
> outside of start/stop. It is just complicating things.
>
> 2) for many controllers there is no difference between run/stop and
> connect/disconnect. i.e. a single register bit controls both.
>
> 3) it fits well with the OTG specification. OTG specification says
> that loc_conn *variable* must be true *after* the device has signalled a
> connect.
> So OTG state machine can safely set loc_conn variable to true after doing
> otg_set_protocol(fsm, PROTO_GADGET); and set it to false otherwise.
>
> Note, OTG specification does not say to take any action based on loc_conn.
> It is just a connect indicator variable. So we might have to fix this in the
> OTG state machine.
>
> My suggestion is to keep it simple for now. Try the OTG implementation,
> and later if we find issues then extend it as required.
>
Just talked with Jun, he is worried if loc_conn != pullup_dp at some
situations. So, how about only calling start gadget at usb_start_gadget,
and pullup_dp at drd_set_state (see below).
static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
{
struct usb_otg *otg = container_of(fsm, struct usb_otg, fsm);
if (otg->state == new_state)
return;
fsm->state_changed = 1;
dev_dbg(otg->dev, "otg: set state: %s\n",
usb_otg_state_string(new_state));
switch (new_state) {
case OTG_STATE_B_IDLE:
+ usb_udc_vbus_handler(gadget, false);
drd_set_protocol(fsm, PROTO_UNDEF);
otg_drv_vbus(otg, 0);
break;
case OTG_STATE_B_PERIPHERAL:
drd_set_protocol(fsm, PROTO_GADGET);
+ usb_udc_vbus_handler(gadget, true);
otg_drv_vbus(otg, 0);
break;
..
};
}
When the OTG FSM is added to this framework, it can keep usb_fsm->ops->loc_conn,
and using the current FSM.
--
Best Regards,
Peter Chen
--
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
[GIT PULL] usb: Chipidea and OTG FSM changes for v4.7-rc1
The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ tags/usb-ci-v4.7-rc1 for you to fetch changes up to 764763f0a0c81cbed4d2c7dc2b05e7173ff85b5b: doc: usb: chipidea: update the doc for OTG FSM (2016-05-04 13:40:31 +0800) Hi Greg, below are changes for chipidea and OTG FSM, no major changes. Some for documentation, some for tiny changes, thanks. Peter Chen (2): usb: chipidea: imx: delete the redundant setting default DMA mask code doc: usb: chipidea: update the doc for OTG FSM Roger Quadros (2): usb: otg-fsm: Add documentation for struct otg_fsm usb: otg-fsm: support multiple instances Documentation/usb/chipidea.txt | 13 +++--- drivers/usb/chipidea/ci_hdrc_imx.c | 4 -- drivers/usb/common/usb-otg-fsm.c | 10 ++--- include/linux/usb/otg-fsm.h| 91 +++--- 4 files changed, 96 insertions(+), 22 deletions(-) -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
On Wed, May 04, 2016 at 09:37:29AM +0300, Roger Quadros wrote:
> 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 explai
Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
On Wed, May 04, 2016 at 11:40:56AM +0300, Roger Quadros wrote:
> 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?
> >>>>>>>&g
Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup
On Thu, Apr 28, 2016 at 09:46:15AM +0300, Felipe Balbi wrote: > > Hi, > > (we don't top-post on this forum ;-) > > "Du, Changbin" writes: > > Hi, Balbi, > > > > The step to reproduce this issue is: > > 1) connect device to a host and wait its enumeration. > > 2) trigger software disconnect by calling function > > usb_gadget_disconnect(), which finally call > >dwc3_gadget_pullup(false). Do not reconnect device > > (I mean no enumeration go on, keep bit Run/Stop 0.). > > > > At here, gadget driver's disconnect callback should be > > Called, right? We has been disconnected. But no, as > > You said " not generating disconnect IRQ after you > > drop Run/Stop is expected". > > > > And I am testing on an Android device, Android only > > use dwc3_gadget_pullup(false) to issue a soft disconnection. > > This confused user that the UI still show usb as connected > > State, caused by missing a disconnect event. > > okay, so I know what this is. This is caused by Android gadget itself > not notifying the gadget that a disconnect has happened. Just look at > udc-core's soft_connect implementation for the sysfs interface, and > you'll see what I mean. > > This should be fixed at Android gadget itself. The only thing we could > do is introduce a new usb_gadget_soft_connect()/disconnect() to wrap the > logic so it's easier for Android gadget to use; but even that I'm a > little bit reluctant to do because Android should be using our > soft_connect interface instead of reimplementing it (wrongly) by its > own. > If it is a gadget driver, it can call its disconnect explicitly. Another thing is the gadget driver should not call usb_gadget_disconnect directly, it should call usb_gadget_deactivate or usb_function_deactivate. Since currently, calling usb_gadget_disconnect may not do real pull down dp, Felipe, will you consider adding gadget_driver->disconnect into usb_gadget_disconnect after pull down dp? -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Thu, May 05, 2016 at 05:42:40PM -0500, Rob Herring wrote: > On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: > > Hi, > > > > This is a different, second try to fix usb3503+lan on Odroid U3 board > > if it was initialized by bootloader (e.g. for TFTP boot). > > > > First version: > > http://www.spinics.net/lists/linux-usb/msg140042.html > > > > > > Problem > > === > > When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), > > the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset > > is required, e.g. by suspend to RAM. The actual TFTP boot does > > not have to happen. Just "usb start" from U-Boot is sufficient. > > > > From the schematics, the regulator is a supply only to LAN, however > > without toggling it off/on, the usb3503 hub won appear neither. > > > > > > Solution > > > > This is very similar to the MMC pwrseq behavior so the idea is to: > > 1. Move MMC pwrseq drivers to generic place, > > You can do that, but I'm going to NAK any use of pwrseq bindings outside > of MMC. I think it is the wrong way to do things. The DT should describe > the devices. If they happen to be "simple" then the core can walk the > tree and do any setup. For example, look for "reset-gpios" and toggle > that GPIO. There is no need for a special node. > Oh, I am doing the same thing like this patch set doing. Then, how can we let things be generic like you mention at [1] if without common pwrseq driver/library? The properties like "reset-gpios" under USB child node seems can only be handled by USB driver. > > 2. Extend the pwrseq-simple with regulator toggling, > > 3. Add support to USB hub and port core for pwrseq, > > We discussed this for USB already[1] and is why we defined how to add > USB child devices. The idea is not to add pwrseq to that. > > Rob > > [1] http://www.spinics.net/lists/linux-usb/msg134082.html [1] http://www.spinics.net/lists/linux-usb/msg137312.html -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Fri, May 06, 2016 at 08:12:24AM +0200, Krzysztof Kozlowski wrote: > On 05/06/2016 07:44 AM, Peter Chen wrote: > > On Thu, May 05, 2016 at 05:42:40PM -0500, Rob Herring wrote: > >> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: > >>> Hi, > >>> > >>> This is a different, second try to fix usb3503+lan on Odroid U3 board > >>> if it was initialized by bootloader (e.g. for TFTP boot). > >>> > >>> First version: > >>> http://www.spinics.net/lists/linux-usb/msg140042.html > >>> > >>> > >>> Problem > >>> === > >>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), > >>> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset > >>> is required, e.g. by suspend to RAM. The actual TFTP boot does > >>> not have to happen. Just "usb start" from U-Boot is sufficient. > >>> > >>> From the schematics, the regulator is a supply only to LAN, however > >>> without toggling it off/on, the usb3503 hub won appear neither. > >>> > >>> > >>> Solution > >>> > >>> This is very similar to the MMC pwrseq behavior so the idea is to: > >>> 1. Move MMC pwrseq drivers to generic place, > >> > >> You can do that, but I'm going to NAK any use of pwrseq bindings outside > >> of MMC. I think it is the wrong way to do things. The DT should describe > >> the devices. If they happen to be "simple" then the core can walk the > >> tree and do any setup. For example, look for "reset-gpios" and toggle > >> that GPIO. There is no need for a special node. > >> > > > > Oh, I am doing the same thing like this patch set doing. > > Shame on me that I did not use Google before starting the work. I could > just extend your patchset. I think we can combine our efforts. > Sure :) -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup
On Fri, May 06, 2016 at 10:01:20AM +0300, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > >> "Du, Changbin" writes: > >> > Hi, Balbi, > >> > > >> > The step to reproduce this issue is: > >> > 1) connect device to a host and wait its enumeration. > >> > 2) trigger software disconnect by calling function > >> > usb_gadget_disconnect(), which finally call > >> >dwc3_gadget_pullup(false). Do not reconnect device > >> > (I mean no enumeration go on, keep bit Run/Stop 0.). > >> > > >> > At here, gadget driver's disconnect callback should be > >> > Called, right? We has been disconnected. But no, as > >> > You said " not generating disconnect IRQ after you > >> > drop Run/Stop is expected". > >> > > >> > And I am testing on an Android device, Android only > >> > use dwc3_gadget_pullup(false) to issue a soft disconnection. > >> > This confused user that the UI still show usb as connected > >> > State, caused by missing a disconnect event. > >> > >> okay, so I know what this is. This is caused by Android gadget itself > >> not notifying the gadget that a disconnect has happened. Just look at > >> udc-core's soft_connect implementation for the sysfs interface, and > >> you'll see what I mean. > >> > >> This should be fixed at Android gadget itself. The only thing we could > >> do is introduce a new usb_gadget_soft_connect()/disconnect() to wrap the > >> logic so it's easier for Android gadget to use; but even that I'm a > >> little bit reluctant to do because Android should be using our > >> soft_connect interface instead of reimplementing it (wrongly) by its > >> own. > >> > > > > If it is a gadget driver, it can call its disconnect explicitly. > > Another thing is the gadget driver should not call usb_gadget_disconnect > > directly, it should call usb_gadget_deactivate or usb_function_deactivate. > > > > Since currently, calling usb_gadget_disconnect may not do real pull down > > dp, Felipe, will you consider adding gadget_driver->disconnect into > > usb_gadget_disconnect after pull down dp? > > this is the detail that I'm not yet entirely sure is always valid. Would > there ever be a situation where we want to drop pull-ups but not tell > the gadget about it ? Yes, we have. - We have enabled pullup dp default for most of platforms, and for gadget obex and uvc will pull down it since it wants app to control it - Some USB charger detection design may need it for the secondary detection. After checking again for usb_gadget_disconnect and usb_gadget_disconnect, I think there is no possible that the dp is still pulled after we call usb_gadget_disconnect, so we don't need to change anything:) -- Best Regards, Peter Chen -- 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 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?
--
Best Regards,
Peter Chen
--
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 01/14] usb: hcd: Initialize hcd->flags to 0
[ 91.758632] r10:0001 r9:ee5f8410 r8:ee731000 r7:ed429000 r6:0006 > r5:ee441dc0 > [ 91.758638] r4:ee731068 > [ 91.758651] [] (dev_printk_emit) from [] > (__dev_printk+0x50/0x70) > [ 91.758660] r3:bf2268cc r2:c07951e0 > [ 91.758673] [] (__dev_printk) from [] > (_dev_info+0x3c/0x48) > [ 91.758686] r6: r5:ee731068 r4:ee731000 > [ 91.758790] [] (_dev_info) from [] > (usb_new_device+0x11c/0x518 [usbcore]) > [ 91.758804] r3:0003 r2:1d6b r1:bf225bc4 > [ 91.758881] [] (usb_new_device [usbcore]) from [] > (usb_otg_add_hcd+0x514/0x7f8 [usbcore]) > [ 91.758903] 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 > --- > 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); Reviewed-by: Peter Chen -- Best Regards, Peter Chen -- 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 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?
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
--
Best Regards,
Peter Chen
--
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 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.
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
> >
--
Best Regards,
Peter Chen
--
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 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?
Peter
> 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,
> + .us
Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface
On Tue, May 10, 2016 at 12:20:28PM +0300, Roger Quadros wrote:
> 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.
>
Let's make OTG depends on gadget and hcd at Kconfig, and keep others
unchanging, if no one objects it.
Peter
> >
> >>
> >> 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 {
> >>>>>>
> >>>>>> };
&g
Re: [PATCH v7 02/14] usb: otg-fsm: Prevent build warning "VDBG" redefined
On Mon, May 02, 2016 at 03:18:45PM +0300, Roger Quadros wrote:
> 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
--
Best Regards,
Peter Chen
--
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 07/14] usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG
On Mon, May 02, 2016 at 03:18:50PM +0300, Roger Quadros wrote:
> 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 +-
I have updated this file, so you will meet a conflict if you
rebase with newest usb-next tree.
> 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 &&
Re: [PATCH v7 08/14] usb: otg: add OTG/dual-role core
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.
> + */
> +
> +#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.
>
> /* 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
--
Best Regards,
Peter Chen
--
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
| 1054
>
> .../usb/{chipidea/otg_fsm.h => common/usb-otg.h} | 61 +-
> drivers/usb/core/Kconfig | 10 +-
> drivers/usb/core/hcd.c | 56 ++
> drivers/usb/gadget/udc/udc-core.c | 161 ++-
> 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 | 20 +
> include/linux/usb/hcd.h| 29 +
> include/linux/usb/of.h |9 +
> include/linux/usb/otg-fsm.h| 154 +--
> include/linux/usb/otg.h| 264 -
> include/linux/usb/xhci_pdriver.h |3 +
> 27 files changed, 1989 insertions(+), 484 deletions(-)
> create mode 100644 drivers/usb/common/usb-otg.c
> copy drivers/usb/{chipidea/otg_fsm.h => common/usb-otg.h} (63%)
>
> --
> 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
--
Best Regards,
Peter Chen
--
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 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?
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
--
Best Regards,
Peter Chen
--
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 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
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 702bca8..77048aa 100644
> --- a/drivers/usb/common/usb-otg.c
> +++ b/drivers/usb/common/usb-otg.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -582,6 +583,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_singlethread_workqueue("usb_otg");
> if (!otg->wq) {
> dev_err(dev, "otg: %s: can't create workqueue\n",
> @@ -805,15 +810,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;
> }
>
> @@ -821,10 +829,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;
> }
> @@ -847,14 +857,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->pri
Re: [PATCH v7 11/14] usb: otg: use dev_dbg() instead of VDBG()
On Mon, May 09, 2016 at 12:48:28PM +0300, Roger Quadros wrote:
> 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.
>
Acked-by: Peter Chen
--
Best Regards,
Peter Chen
--
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 12/14] usb: hcd: Adapt to OTG core
On Mon, May 02, 2016 at 03:18:55PM +0300, Roger Quadros wrote:
> 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
--
Best Regards,
Peter Chen
--
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 14/14] usb: host: xhci-plat: Add otg device to platform data
On Mon, May 02, 2016 at 03:18:57PM +0300, Roger Quadros wrote:
> 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
> ---
> 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
>
Reviewed-by: Peter Chen
--
Best Regards,
Peter Chen
--
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 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?
Peter
> 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
Re: [RFC PATCH v2 4/4] ARM: dts: vf-colibri: USB device/host switch using extcon gpio
On Wed, May 11, 2016 at 06:11:36PM +0530, Sanchayan Maity wrote:
> Use USBC_DET feature of standard Colibri SODIMM pin 137 for USB
> device/host switching using the generic extcon USB gpio implementation.
>
> Signed-off-by: Sanchayan Maity
> ---
> arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 12
> arch/arm/boot/dts/vf-colibri.dtsi | 7 +++
> 2 files changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> index a8a8e43..a012f80 100644
> --- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> +++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> @@ -50,6 +50,14 @@
> clock-frequency = <1600>;
> };
>
> + extcon_usbc_det: usbc_det {
> + compatible = "linux,extcon-usb-gpio";
> + debounce = <25>;
> + id-gpio = <&gpio3 6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbc_det>;
> + };
> +
> panel: panel {
> compatible = "edt,et057090dhu";
> backlight = <&bl>;
> @@ -162,6 +170,10 @@
> status = "okay";
> };
>
> +&usbdev0 {
> + extcon = <&extcon_usbc_det>, <&extcon_usbc_det>;
> +};
> +
I still not understand why vbus needs id-extcon too? Per my understand,
this pin will not be changed between connects to pc and disconnects to
pc.
> &usbh1 {
> vbus-supply = <®_usbh_vbus>;
> };
> diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
> b/arch/arm/boot/dts/vf-colibri.dtsi
> index b741709..a7a3e88 100644
> --- a/arch/arm/boot/dts/vf-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf-colibri.dtsi
> @@ -174,6 +174,7 @@
>
> &usbdev0 {
> disable-over-current;
> + dr_mode = "otg";
> status = "okay";
> };
>
> @@ -362,6 +363,12 @@
> >;
> };
>
> + pinctrl_usbc_det: gpio_usbc_det {
> + fsl,pins = <
> + VF610_PAD_PTC29__GPIO_102 0x22ed
> + >;
> + };
> +
> pinctrl_usbh1_reg: gpio_usb_vbus {
> fsl,pins = <
> VF610_PAD_PTD4__GPIO_83 0x22ed
> --
> 2.8.2
>
> --
> 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
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 4/4] ARM: dts: vf-colibri: USB device/host switch using extcon gpio
On Thu, May 12, 2016 at 02:47:09PM +0530, maitysancha...@gmail.com wrote:
> Hello Peter,
>
> On 16-05-12 16:40:16, Peter Chen wrote:
> > On Wed, May 11, 2016 at 06:11:36PM +0530, Sanchayan Maity wrote:
> > > Use USBC_DET feature of standard Colibri SODIMM pin 137 for USB
> > > device/host switching using the generic extcon USB gpio implementation.
> > >
> > > Signed-off-by: Sanchayan Maity
> > > ---
> > > arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 12
> > > arch/arm/boot/dts/vf-colibri.dtsi | 7 +++
> > > 2 files changed, 19 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> > > b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> > > index a8a8e43..a012f80 100644
> > > --- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> > > +++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> > > @@ -50,6 +50,14 @@
> > > clock-frequency = <1600>;
> > > };
> > >
> > > + extcon_usbc_det: usbc_det {
> > > + compatible = "linux,extcon-usb-gpio";
> > > + debounce = <25>;
> > > + id-gpio = <&gpio3 6 GPIO_ACTIVE_HIGH>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&pinctrl_usbc_det>;
> > > + };
> > > +
> > > panel: panel {
> > > compatible = "edt,et057090dhu";
> > > backlight = <&bl>;
> > > @@ -162,6 +170,10 @@
> > > status = "okay";
> > > };
> > >
> > > +&usbdev0 {
> > > + extcon = <&extcon_usbc_det>, <&extcon_usbc_det>;
> > > +};
> > > +
> >
> > I still not understand why vbus needs id-extcon too? Per my understand,
> > this pin will not be changed between connects to pc and disconnects to
> > pc.
>
> While the ID extcon will take care of switching the role, without the
> vbus gadget connect/disconnect being called appropriately as per the
> current state, I have observed the client configuration to not work.
>
> From the descriptions of usb_gadget_vbus_connect/disconnect I understand
> this to be required. Do I understand wrong?
Your understand is right, but most of problem is your platform is lack
of vbus detect, so you don't know when to call usb_gadget_vbus_connect/
disconnect.
extcon_usbc_det is the external connector for ID, you can't use it for
both ID and VBUS. If you can add one gpio for vbus, then current framework
can support.
Roger is working on DRD/OTG framework [1], currently, it needs both ID
and VBUS input for state machine. Your case is the new case, it has only
one input (ID), but role switch is needed to support too.
[1] http://www.spinics.net/lists/linux-usb/msg140138.html
--
Best Regards,
Peter Chen
--
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
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. > Then, how you know this EHCI + companion controller special case during otg adds hcd, it needs special handling, right? Peter > 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 -- Best Regards, Peter Chen -- 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 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.
> 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.
> 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.
--
Best Regards,
Peter Chen
--
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 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 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. > >> [...] > > > > Then, how you know this EHCI + companion controller special case during otg > > adds > > hcd, it needs special handling, right? > > We know the special case by using the hcd_needs_companion flag. > You had said "we don't need this..", ok, yes, we do need it. -- Best Regards, Peter Chen -- 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 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.
> >
> >>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
--
Best Regards,
Peter Chen
--
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 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:
- Except for vbus interrupt, any chances this API will be used at
current logic?
- When this API is called but without a coming gadget->stop?
--
Best Regards,
Peter Chen
--
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 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:
drd_set_protocol(fsm, PROTO_GADGET);
otg_drv_vbus(otg, 0);
break;
OTG FSM:
case OTG_STATE_B_IDLE:
otg_drv_vbus(otg, 0);
otg_chrg_vbus(otg, 0);
otg_loc_conn(otg, 0);
otg_loc_sof(otg, 0);
/*
* Driver is responsible for starting ADP probing
* if ADP sensing times out.
*/
otg_start_adp_sns(otg);
otg_set_protocol(fsm, PROTO_UNDEF);
otg_add_timer(otg, B_SE0_SRP);
break;
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;
My original suggestion is to have an API to do pull dp and this API
will be used at both DRD and OTG FSM, and called at otg_loc_conn.
The (de)initialize is the same for both two FSMs, it both includes
init peripheral mode and pull up dp, and can be done by drd_set_protocol(fsm,
PROTO_GADGET)
otg_loc_conn(otg, 1);
What do you think?
--
Best Regards,
Peter Chen
--
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 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 > >>> @@ -59,5 +59,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS) += > >>> renesas_usbhs/ > >>> obj-$(CONFIG_USB_GADGET) += gadget/ > >>> > >>> obj-$(CONFIG_USB_COMMON) += common
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
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.
--
Best Regards,
Peter Chen
--
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 Fri, May 20, 2016 at 10:26:03AM +0300, Roger Quadros wrote:
> 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 user
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
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.
--
Best Regards,
Peter Chen
--
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 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, 'm' means module.
> >>>>>
> >>>>> 1) hcd 'y', gadget 'y'
> >>>>> otg has to be 'y' for proper build.
> >>>>>
> >>>>> 2) hcd &#x
Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
ince
usb_otg_descriptor_init is called at that. Besides, Gadget driver
may be probed before otg driver is registered
I am wonder if we can implement defer probe for gadget/udc/host driver
if otg driver is not probed, in that case, some designs can be simpler
like wait list in otg driver.
> 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
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] usb: chipidea: Add support for Tegra20 through Tegra124
On Thu, May 26, 2016 at 05:40:00PM +0200, Thierry Reding wrote: > From: Thierry Reding > > All Tegra SoC generations from Tegra20 through Tegra124 have a ChipIdea > USB device controller. This set of patches adds very rudimentary support > for it to the existing ChipIdea driver and enables them on the set of > boards that I could easily test on. > > I'm sending this out as RFC because I'm not sure yet how to merge this. > While the driver seems to work fine (tested by exporting a USB driver or > eMMC via the mass storage function) I don't yet understand how to make > the driver switch between host and device modes dynamically. It might be > useful to get this merged before, but I'd like to have some feedback on > this, because doing so would mean that we need to use device mode on the > devices where it's enabled and can't use the USBD port in host mode. > Chipidea driver supports many ways to switch between host and device mode. It can support switching with/without disconnecting cable. Most of cases need to disconnect cable (Micro-AB) to switch between host and device mode, I just take this as an example: Using ID pin which is at Micro-B receptacle on the board to determine host (ID = 0) or device (ID = 1 )mode. - ID pin connects to CPU, and ID interrupt and value can be get through register OTGSC. - ID pin does not connect to CPU, and there is a dedicated GPIO for ID. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/5] ARM: tegra: Enable UDC on Dalmore
On Thu, May 26, 2016 at 05:40:04PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Override the compatible string of the first USB controller to enable
> device mode.
>
> Signed-off-by: Thierry Reding
> ---
> arch/arm/boot/dts/tegra114-dalmore.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
> b/arch/arm/boot/dts/tegra114-dalmore.dts
> index c970bf65c74c..53d664f718ff 100644
> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
> @@ -1122,6 +1122,17 @@
> non-removable;
> };
>
> + usb@7d00 {
> + compatible = "nvidia,tegra114-udc";
> + status = "okay";
> + dr_mode = "otg";
> + };
> +
> + usb-phy@7d00 {
> + status = "okay";
> + dr_mode = "otg";
> + };
> +
It is a USB PHY node, you don't need to set dr_mode for it.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: select NOP_USB_XCEIV by drivers that require it
On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote: > Hello, > > I was updating my config by make oldconfig for a while and noticed that my USB > OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV > over time. > > Looking through defconfigs some have it included and some which seem in need > of > it don't. > > Since the dependency is not obvious I think it would be better to select it > where possible. >From Documentation/kbuild/kconfig-language.txt In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. But NOP_USB_XCEIV is a visible symbol and can be chosen, besides, NOP_USB_XCEIV has already selected USB_PHY. Using select may cause dependency problem in future, so unless it is necessary, use it as least as possible. If you are using new code, and it adds new dependency code, it is reasonable you may need to update your defconfig. Peter > > Attaching a patch. > > Thanks > > Michal > > 8<-- > NOP_USB_XCEIV is non-obvious dependency for MUSB and other drivers. > > This is a virtual driver in the sense that there is no actual piece of > hardware you can point at and say you did not include driver for this so > it won't work. > > So just change all depends on it to select. > > Signed-off-by: Michal Suchanek > --- > drivers/usb/chipidea/Kconfig | 3 ++- > drivers/usb/musb/Kconfig | 19 +-- > drivers/usb/phy/Kconfig | 2 ++ > 3 files changed, 17 insertions(+), 7 deletions(-) > > diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig > index 3644a35..8d08ebd 100644 > --- a/drivers/usb/chipidea/Kconfig > +++ b/drivers/usb/chipidea/Kconfig > @@ -19,7 +19,8 @@ config USB_CHIPIDEA_OF > config USB_CHIPIDEA_PCI > tristate > depends on PCI > - depends on NOP_USB_XCEIV > + select NOP_USB_XCEIV > + select USB_PHY > default USB_CHIPIDEA > > config USB_CHIPIDEA_UDC > diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > index 886526b..91717b9 100644 > --- a/drivers/usb/musb/Kconfig > +++ b/drivers/usb/musb/Kconfig > @@ -66,7 +66,8 @@ comment "Platform Glue Layer" > config USB_MUSB_SUNXI > tristate "Allwinner (sunxi)" > depends on ARCH_SUNXI > - depends on NOP_USB_XCEIV > + select NOP_USB_XCEIV > + select USB_PHY > depends on PHY_SUN4I_USB > depends on EXTCON > depends on GENERIC_PHY > @@ -75,13 +76,15 @@ config USB_MUSB_SUNXI > config USB_MUSB_DAVINCI > tristate "DaVinci" > depends on ARCH_DAVINCI_DMx > - depends on NOP_USB_XCEIV > + select NOP_USB_XCEIV > + select USB_PHY > depends on BROKEN > > config USB_MUSB_DA8XX > tristate "DA8xx/OMAP-L1x" > depends on ARCH_DAVINCI_DA8XX > - depends on NOP_USB_XCEIV > + select NOP_USB_XCEIV > + select USB_PHY > depends on BROKEN > > config USB_MUSB_TUSB6010 > @@ -89,6 +92,7 @@ config USB_MUSB_TUSB6010 > depends on HAS_IOMEM > depends on ARCH_OMAP2PLUS || COMPILE_TEST > depends on NOP_USB_XCEIV = USB_MUSB_HDRC # both built-in or both modules > + # cannot select NOP_USB_XCEIV because of the dependency above > > config USB_MUSB_OMAP2PLUS > tristate "OMAP2430 and onwards" > @@ -99,7 +103,8 @@ config USB_MUSB_OMAP2PLUS > config USB_MUSB_AM35X > tristate "AM35x" > depends on ARCH_OMAP > - depends on NOP_USB_XCEIV > + select NOP_USB_XCEIV > + select USB_PHY > > config USB_MUSB_DSPS > tristate "TI DSPS platforms" > @@ -110,7 +115,8 @@ config USB_MUSB_DSPS > config USB_MUSB_BLACKFIN > tristate "Blackfin" > depends on (BF54x && !BF544) || (BF52x && ! BF522 && !BF523) > - depends on NOP_USB_XCEIV > + select NOP_USB_XCEIV > + select USB_PHY > > config USB_MUSB_UX500 > tristate "Ux500 platforms" > @@ -118,7 +124,8 @@ config USB_MUSB_UX500 > > config USB_MUSB_JZ4740 > tristate "JZ4740" > - depends on NOP_USB_XCEIV > + select NOP_USB_XCEIV > + select USB_PHY > depends on MACH_JZ4740 || COMPILE_TEST > depends on USB_MUSB_GADGET > depends on USB_OTG_BLACKLIST_HUB > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig > index c690474..a0bdfd3 100644 > --- a/drivers/usb/phy/Kconfig > +++ b/drivers/usb/phy/Kconfig > @@ -57,6 +57,8 @@ config NOP_USB
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Tue, May 10, 2016 at 01:02:08PM +0200, Ulf Hansson wrote: > + Arnd > > [...] > > >> >> Solution > >> >> > >> >> This is very similar to the MMC pwrseq behavior so the idea is to: > >> >> 1. Move MMC pwrseq drivers to generic place, > >> > > >> > You can do that, but I'm going to NAK any use of pwrseq bindings outside > >> > of MMC. I think it is the wrong way to do things. The DT should describe > >> > >> Huh, I didn't know that was your view of the mmc pwrseq bindings. Why > >> didn't you NAK them before? > > > > Unfortunately, either I missed it or it was a time I couldn't spend much > > time on reviews. > > Okay, I guess it's common issue among maintainers. The problem with DT > is that it gets really hard to be fixed up later. :-) > > > > >> > the devices. If they happen to be "simple" then the core can walk the > >> > tree and do any setup. For example, look for "reset-gpios" and toggle > >> > that GPIO. There is no need for a special node. > >> > > >> >> 2. Extend the pwrseq-simple with regulator toggling, > >> >> 3. Add support to USB hub and port core for pwrseq, > >> > > >> > We discussed this for USB already[1] and is why we defined how to add > >> > USB child devices. The idea is not to add pwrseq to that. > >> > >> I am not familiar with the USB discussion. > >> > >> Still, let me give you some more background to the mmc pwrseq. The > >> idea from the mmc pwrseq bindings comes from the power-domain DT > >> bindings, as I thought these things were a bit related. > >> In both cases they are not directly a property of the device, but more > >> describing a HW dependency to allow the device to work. > > > > I could see this as a board level power domain. However the difference > > is we are not generally exposing internal SOC details the same way as > > board level components. Perhaps we could extend power domains to board > > level, but that is not what was done here. > > > >> One could probably use a child node instead of a phandle, but that > >> wasn't chosen back then. Of course you are the DT expert, but could > >> you perhaps tell me why a child node is better for cases like this? > > > > If there is a control path hierarchy, then we try to model that in DT > > with child nodes. In cases of SDIO and USB, there is a clear hierarchy. > > Ignoring the discovery ordering problem, we already have defined ways to > > describe GPIO connections, regulators, etc. to devices. Describing those > > things separately from the device to solve a particular issue that is > > really a kernel limitation is what I don't like. > > Okay, I see. > > To move forward in trying to make mmc pwrseq a generic pwrseq, could > we perhaps allow both cases? > > In the mmc case, there are already deployed bindings so we need to > cope with these by using the phandle option, but for USB etc we could > force the child node option. > As long as we agree that we keep using a compatible string for the > child node as well, both options should be able to co-exist and we > should probably be able to managed them both from a common pwrseq > driver framework. > > Although, I do remember from an older conversations around some of > mine submission for the mmc pwrseq code, that some people (maybe > Arnd?) wasn't keen on adding a new framework for this. Perhaps that > has changed? > All, how we move on for this? 1. Using a generic driver to manage both mmc and USB (and further subsystem), USB and further subsystem do not use pwrseq node in dts. 2. USB creates the similar driver under drivers/usb for its own use. Which one do you prefer, thanks. -- Best Regards, Peter Chen -- 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 00/14] USB OTG/dual-role framework
|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|9 + > include/linux/usb/otg-fsm.h | 154 +-- > include/linux/usb/otg.h | 264 +- > include/linux/usb/xhci_pdriver.h |3 + > 26 files changed, 2013 insertions(+), 438 deletions(-) > create mode 100644 drivers/usb/common/usb-otg.c > > -- > 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 -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Sat, May 28, 2016 at 11:36:13AM +0800, Peter Chen wrote: > On Tue, May 10, 2016 at 01:02:08PM +0200, Ulf Hansson wrote: > > + Arnd > > > > [...] > > > > >> >> Solution > > >> >> > > >> >> This is very similar to the MMC pwrseq behavior so the idea is to: > > >> >> 1. Move MMC pwrseq drivers to generic place, > > >> > > > >> > You can do that, but I'm going to NAK any use of pwrseq bindings > > >> > outside > > >> > of MMC. I think it is the wrong way to do things. The DT should > > >> > describe > > >> > > >> Huh, I didn't know that was your view of the mmc pwrseq bindings. Why > > >> didn't you NAK them before? > > > > > > Unfortunately, either I missed it or it was a time I couldn't spend much > > > time on reviews. > > > > Okay, I guess it's common issue among maintainers. The problem with DT > > is that it gets really hard to be fixed up later. :-) > > > > > > > >> > the devices. If they happen to be "simple" then the core can walk the > > >> > tree and do any setup. For example, look for "reset-gpios" and toggle > > >> > that GPIO. There is no need for a special node. > > >> > > > >> >> 2. Extend the pwrseq-simple with regulator toggling, > > >> >> 3. Add support to USB hub and port core for pwrseq, > > >> > > > >> > We discussed this for USB already[1] and is why we defined how to add > > >> > USB child devices. The idea is not to add pwrseq to that. > > >> > > >> I am not familiar with the USB discussion. > > >> > > >> Still, let me give you some more background to the mmc pwrseq. The > > >> idea from the mmc pwrseq bindings comes from the power-domain DT > > >> bindings, as I thought these things were a bit related. > > >> In both cases they are not directly a property of the device, but more > > >> describing a HW dependency to allow the device to work. > > > > > > I could see this as a board level power domain. However the difference > > > is we are not generally exposing internal SOC details the same way as > > > board level components. Perhaps we could extend power domains to board > > > level, but that is not what was done here. > > > > > >> One could probably use a child node instead of a phandle, but that > > >> wasn't chosen back then. Of course you are the DT expert, but could > > >> you perhaps tell me why a child node is better for cases like this? > > > > > > If there is a control path hierarchy, then we try to model that in DT > > > with child nodes. In cases of SDIO and USB, there is a clear hierarchy. > > > Ignoring the discovery ordering problem, we already have defined ways to > > > describe GPIO connections, regulators, etc. to devices. Describing those > > > things separately from the device to solve a particular issue that is > > > really a kernel limitation is what I don't like. > > > > Okay, I see. > > > > To move forward in trying to make mmc pwrseq a generic pwrseq, could > > we perhaps allow both cases? > > > > In the mmc case, there are already deployed bindings so we need to > > cope with these by using the phandle option, but for USB etc we could > > force the child node option. > > As long as we agree that we keep using a compatible string for the > > child node as well, both options should be able to co-exist and we > > should probably be able to managed them both from a common pwrseq > > driver framework. > > > > Although, I do remember from an older conversations around some of > > mine submission for the mmc pwrseq code, that some people (maybe > > Arnd?) wasn't keen on adding a new framework for this. Perhaps that > > has changed? > > > > All, how we move on for this? > > 1. Using a generic driver to manage both mmc and USB (and further > subsystem), USB and further subsystem do not use pwrseq node in dts. > 2. USB creates the similar driver under drivers/usb for its own use. > > Which one do you prefer, thanks. > Hi Krzysztof Kozlowski, I think option 1 may be better according to Rob and Ulf's comment. Would you like going on your patch set? You can work on generic pwrseq driver, I will do USB stuffs based on generic pwrseq driver? -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: gadget: move gadget API functions to udc-core
the configuration descriptor bMaxPower field.
> - *
> - * This call is used by gadget drivers during SET_CONFIGURATION calls,
> - * reporting how much power the device may consume. For example, this
> - * could affect how quickly batteries are recharged.
> - *
> - * Returns zero on success, else negative errno.
> - */
> -static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned
> mA)
> -{
> - if (!gadget->ops->vbus_draw)
> - return -EOPNOTSUPP;
> - return gadget->ops->vbus_draw(gadget, mA);
> -}
> -
> -/**
> - * usb_gadget_vbus_disconnect - notify controller about VBUS session end
> - * @gadget:the device whose VBUS supply is being described
> - * Context: can sleep
> - *
> - * This call is used by a driver for an external transceiver (or GPIO)
> - * that detects a VBUS power session ending. Common responses include
> - * reversing everything done in usb_gadget_vbus_connect().
> - *
> - * Returns zero on success, else negative errno.
> - */
> -static inline int usb_gadget_vbus_disconnect(struct usb_gadget *gadget)
> -{
> - if (!gadget->ops->vbus_session)
> - return -EOPNOTSUPP;
> - return gadget->ops->vbus_session(gadget, 0);
> -}
> -
> -/**
> - * usb_gadget_connect - software-controlled connect to USB host
> - * @gadget:the peripheral being connected
> - *
> - * Enables the D+ (or potentially D-) pullup. The host will start
> - * enumerating this gadget when the pullup is active and a VBUS session
> - * is active (the link is powered). This pullup is always enabled unless
> - * usb_gadget_disconnect() has been used to disable it.
> - *
> - * Returns zero on success, else negative errno.
> - */
> -static inline int usb_gadget_connect(struct usb_gadget *gadget)
> -{
> - int ret;
> -
> - if (!gadget->ops->pullup)
> - return -EOPNOTSUPP;
> -
> - if (gadget->deactivated) {
> - /*
> - * If gadget is deactivated we only save new state.
> - * Gadget will be connected automatically after activation.
> - */
> - gadget->connected = true;
> - return 0;
> - }
> -
> - ret = gadget->ops->pullup(gadget, 1);
> - if (!ret)
> - gadget->connected = 1;
> - return ret;
> -}
> -
> -/**
> - * usb_gadget_disconnect - software-controlled disconnect from USB host
> - * @gadget:the peripheral being disconnected
> - *
> - * Disables the D+ (or potentially D-) pullup, which the host may see
> - * as a disconnect (when a VBUS session is active). Not all systems
> - * support software pullup controls.
> - *
> - * Retur
Re: [PATCH 2/2] usb: gadget: add tracepoints to the gadget API
> + TP_STRUCT__entry(
> + __dynamic_array(char, name, UDC_TRACE_STR_MAX)
> + __field(unsigned, maxpacket)
> + __field(unsigned, maxpacket_limit)
> + __field(unsigned, max_streams)
> + __field(unsigned, mult)
> + __field(unsigned, maxburst)
> + __field(u8, address)
> + __field(bool, claimed)
> + __field(bool, enabled)
> + __field(int, ret)
> + ),
> + TP_fast_assign(
> + snprintf(__get_str(name), UDC_TRACE_STR_MAX, "%s", ep->name);
> + __entry->maxpacket = ep->maxpacket;
> + __entry->maxpacket_limit = ep->maxpacket_limit;
> + __entry->max_streams = ep->max_streams;
> + __entry->mult = ep->mult;
> + __entry->maxburst = ep->maxburst;
> + __entry->address = ep->address,
> + __entry->claimed = ep->claimed;
> + __entry->enabled = ep->enabled;
> + __entry->ret = ret;
> + ),
> + TP_printk("%s: mps %d/%d streams %d mult %d burst %d addr %02x %s%s -->
> %d",
> + __get_str(name), __entry->maxpacket, __entry->maxpacket_limit,
> + __entry->max_streams, __entry->mult, __entry->maxburst,
> + __entry->address, __entry->claimed ? "claimed:" : "released:",
> + __entry->enabled ? "enabled" : "disabled", ret)
> +);
> +
> +DEFINE_EVENT(udc_log_ep, usb_ep_set_maxpacket_limit,
> + TP_PROTO(struct usb_ep *ep, int ret),
> + TP_ARGS(ep, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_ep, usb_ep_enable,
> + TP_PROTO(struct usb_ep *ep, int ret),
> + TP_ARGS(ep, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_ep, usb_ep_disable,
> + TP_PROTO(struct usb_ep *ep, int ret),
> + TP_ARGS(ep, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_ep, usb_ep_set_halt,
> + TP_PROTO(struct usb_ep *ep, int ret),
> + TP_ARGS(ep, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_ep, usb_ep_clear_halt,
> + TP_PROTO(struct usb_ep *ep, int ret),
> + TP_ARGS(ep, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_ep, usb_ep_set_wedge,
> + TP_PROTO(struct usb_ep *ep, int ret),
> + TP_ARGS(ep, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_ep, usb_ep_fifo_status,
> + TP_PROTO(struct usb_ep *ep, int ret),
> + TP_ARGS(ep, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_ep, usb_ep_fifo_flush,
> + TP_PROTO(struct usb_ep *ep, int ret),
> + TP_ARGS(ep, ret)
> +);
> +
> +DECLARE_EVENT_CLASS(udc_log_req,
> + TP_PROTO(struct usb_ep *ep, struct usb_request *req, int ret),
> + TP_ARGS(ep, req, ret),
> + TP_STRUCT__entry(
> + __dynamic_array(char, name, UDC_TRACE_STR_MAX)
> + __field(unsigned, length)
> + __field(unsigned, actual)
> + __field(unsigned, num_sgs)
> + __field(unsigned, num_mapped_sgs)
> + __field(unsigned, stream_id)
> + __field(unsigned, no_interrupt)
> + __field(unsigned, zero)
> + __field(unsigned, short_not_ok)
> + __field(int, status)
> + __field(int, ret)
> + ),
> + TP_fast_assign(
> + snprintf(__get_str(name), UDC_TRACE_STR_MAX, "%s", ep->name);
> + __entry->length = req->length;
> + __entry->actual = req->actual;
> + __entry->num_sgs = req->num_sgs;
> + __entry->num_mapped_sgs = req->num_mapped_sgs;
> + __entry->stream_id = req->stream_id;
> + __entry->no_interrupt = req->no_interrupt;
> + __entry->zero = req->zero;
> + __entry->short_not_ok = req->short_not_ok;
> + __entry->status = req->status;
> + __entry->ret = ret;
> + ),
> + TP_printk("%s: length %d/%d sgs %d/%d stream %d %s%s%s status %d -->
> %d",
> + __get_str(name), __entry->actual, __entry->length,
> + __entry->num_mapped_sgs, __entry->num_sgs, __entry->stream_id,
> + __entry->zero ? "Z" : "z",
> + __entry->short_not_ok ? "S" : "s",
> + __entry->no_interrupt ? "i" : "I",
> + __entry->status, __entry->ret
> + )
> +);
> +
> +DEFINE_EVENT(udc_log_req, usb_ep_alloc_request,
> + TP_PROTO(struct usb_ep *ep, struct usb_request *req, int ret),
> + TP_ARGS(ep, req, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_req, usb_ep_free_request,
> + TP_PROTO(struct usb_ep *ep, struct usb_request *req, int ret),
> + TP_ARGS(ep, req, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_req, usb_ep_queue,
> + TP_PROTO(struct usb_ep *ep, struct usb_request *req, int ret),
> + TP_ARGS(ep, req, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_req, usb_ep_dequeue,
> + TP_PROTO(struct usb_ep *ep, struct usb_request *req, int ret),
> + TP_ARGS(ep, req, ret)
> +);
> +
> +DEFINE_EVENT(udc_log_req, usb_gadget_giveback_request,
> + TP_PROTO(struct usb_ep *ep, struct usb_request *req, int ret),
> + TP_ARGS(ep, req, ret)
> +);
> +
> +#endif /* __UDC_TRACE_H */
> +
> +/* this part has to be here */
> +
> +#undef TRACE_INCLUDE_PATH
> +#define TRACE_INCLUDE_PATH .
> +
> +#undef TRACE_INCLUDE_FILE
> +#define TRACE_INCLUDE_FILE trace
> +
> +#include
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 89e4a8de68e6..f327712cbef6 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -25,6 +25,8 @@
> #include
> #include
>
> +#define UDC_TRACE_STR_MAX512
> +
> struct usb_ep;
>
> /**
> @@ -293,6 +295,7 @@ struct usb_gadget_ops {
> * @dev: Driver model state for this abstract device.
> * @out_epnum: last used out ep number
> * @in_epnum: last used in ep number
> + * @mA: last set mA value
> * @otg_caps: OTG capabilities of this gadget.
> * @sg_supported: true if we can handle scatter-gather
> * @is_otg: True if the USB device port uses a Mini-AB jack, so that the
> @@ -349,6 +352,7 @@ struct usb_gadget {
> struct device dev;
> unsignedout_epnum;
> unsignedin_epnum;
> + unsignedmA;
> struct usb_otg_caps *otg_caps;
>
> unsignedsg_supported:1;
> --
> 2.8.3
Reviewed-by: Peter Chen
--
Best Regards,
Peter Chen
--
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 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.
Peter
> 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
>
> --
> 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
--
Best Regards,
Peter Chen
--
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 v3 12/12] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3
On Wed, Jun 01, 2016 at 10:02:21AM +0200, Krzysztof Kozlowski wrote:
> On Odroid U3 (Exynos4412-based) board if USB was initialized by
> bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
> and LAN (smsc95xx) after after successful probing were not visible in the
> system ("lsusb").
>
> In such case the devices had to be fully reset before configuring.
> Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
> in usb3503 HUB are not sufficient. Instead full reset has to be done by
> disabling and enabling regulator.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> index 31cdc036fda4..23e30e4609df 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> @@ -99,11 +99,15 @@
> clock-names = "refclk";
> clocks = <&pmu_system_controller 0>;
> refclk-frequency = <2400>;
> +
> + power-sequence;
> + ext-supply = <&buck8_reg>;
> };
>
> &ehci {
> port@1 {
> status = "okay";
> + usb-pwrseq = <&usb3503>;
> };
> port@2 {
> status = "okay";
> --
> 1.9.1
>
The hub is under the port1, you may need to describe it
under the port@1, see below:
Documentation/devicetree/bindings/usb/usb-device.txt
If I get Rob's comments correctly, you may need to consider
below MMC and USB device tree description together, it seems
hard for USB to use pwrseq driver, sorry for confusing you.
If rob can accept below USB device description, we have to
do it under USB. In future, if there is some suitable framework,
we can move it.
1. MMC device:
usdhc3_pwrseq: usdhc3_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>, /* WL_REG_ON */
<&gpio4 7 GPIO_ACTIVE_LOW>, /* WL_HOSTWAKE
*/
<&gpio3 25 GPIO_ACTIVE_LOW>, /* BT_REG_ON */
<&gpio3 27 GPIO_ACTIVE_LOW>, /* BT_HOSTWAKE
*/
<&gpio4 4 GPIO_ACTIVE_LOW>, /* BT_WAKE */
<&gpio4 6 GPIO_ACTIVE_LOW>; /* BT_RST_N */
};
&usdhc3 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc3>;
pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
bus-width = <4>;
non-removable;
keep-power-in-suspend;
wakeup-source;
mmc-pwrseq = <&usdhc3_pwrseq>;
status = "okay";
};
2. USB device
&usbotg1 {
vbus-supply = <®_usb_otg1_vbus>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usb_otg1_id>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
hub: genesys@1 {
compatible = "usb5e3,608";
reg = <1>;
reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
reset-duration-us = <10>;
clocks = <&clks IMX6SX_CLK_CKO>;
};
};
};
--
Best Regards,
Peter Chen
--
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 v3 09/12] EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree
On Wed, Jun 01, 2016 at 01:57:23AM -0700, Stephen Boyd wrote: > Quoting Krzysztof Kozlowski (2016-06-01 01:02:18) > > Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq > > device. The pwrseq device will be used by USB hub to cycle the power > > before activating ports. > > > > Signed-off-by: Krzysztof Kozlowski > > Drive by review comment. > > I was hoping this would help me with a problem I'm having where I have a > hub (smsc4604) that needs to be taken out of reset before my HSIC > controller sends a USB reset to it, but it seems this is more about > doing some sort of power on sequence after enumeration? > No, you may need to do reset before enumeration, the general purpose of reset is eliminate unstable hardware state, and let the controller find the device. Try to do it at bootloader to see if it works for you. -- Best Regards, Peter Chen -- 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 v3 09/12] EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree
On Wed, Jun 01, 2016 at 11:16:34AM -0700, Stephen Boyd wrote: > Quoting Peter Chen (2016-06-01 05:05:20) > > On Wed, Jun 01, 2016 at 01:57:23AM -0700, Stephen Boyd wrote: > > > Quoting Krzysztof Kozlowski (2016-06-01 01:02:18) > > > > Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq > > > > device. The pwrseq device will be used by USB hub to cycle the power > > > > before activating ports. > > > > > > > > Signed-off-by: Krzysztof Kozlowski > > > > > > Drive by review comment. > > > > > > I was hoping this would help me with a problem I'm having where I have a > > > hub (smsc4604) that needs to be taken out of reset before my HSIC > > > controller sends a USB reset to it, but it seems this is more about > > > doing some sort of power on sequence after enumeration? > > > > > > > No, you may need to do reset before enumeration, the general purpose of > > reset is eliminate unstable hardware state, and let the controller find > > the device. > > > > Try to do it at bootloader to see if it works for you. > > > > Sorry the bootloader doesn't do this so that doesn't work for me. I mean try to see if the HUB can work if you reset it at bootloader. If it works, it means you need to do reset before enumeration, and you don't need to do anything after enumeration. -- Best Regards, Peter Chen -- 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 v3 12/12] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3
On Thu, Jun 02, 2016 at 09:26:57AM +0200, Krzysztof Kozlowski wrote:
> On 06/01/2016 01:59 PM, Peter Chen wrote:
> > On Wed, Jun 01, 2016 at 10:02:21AM +0200, Krzysztof Kozlowski wrote:
> >> On Odroid U3 (Exynos4412-based) board if USB was initialized by
> >> bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
> >> and LAN (smsc95xx) after after successful probing were not visible in the
> >> system ("lsusb").
> >>
> >> In such case the devices had to be fully reset before configuring.
> >> Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
> >> in usb3503 HUB are not sufficient. Instead full reset has to be done by
> >> disabling and enabling regulator.
> >>
> >> Signed-off-by: Krzysztof Kozlowski
> >> ---
> >> arch/arm/boot/dts/exynos4412-odroidu3.dts | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> >> b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> >> index 31cdc036fda4..23e30e4609df 100644
> >> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> >> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> >> @@ -99,11 +99,15 @@
> >>clock-names = "refclk";
> >>clocks = <&pmu_system_controller 0>;
> >>refclk-frequency = <2400>;
> >> +
> >> + power-sequence;
> >> + ext-supply = <&buck8_reg>;
> >> };
> >>
> >> &ehci {
> >>port@1 {
> >>status = "okay";
> >> + usb-pwrseq = <&usb3503>;
> >>};
> >>port@2 {
> >>status = "okay";
> >> --
> >> 1.9.1
> >>
> >
> > The hub is under the port1, you may need to describe it
> > under the port@1, see below:
> > Documentation/devicetree/bindings/usb/usb-device.txt
>
> My configuration is a little bit different than yours.
>
> In my case I have a USB hub (usb3503) which is also a a i2c device
> because it has to be configured through I2C.
>
> I can add the power-sequence properties to the I2C node or as you
> pointed under port using the vendor-product-id compatible. In the first
> option: not many USB changes are needed. It works for me, at least as a
> proof of concept.
>
> The second solution: currently it does not work because the USB device
> does not get enumerated before the power sequence begins. It would be
> great if you could implement this on USB side.
Well, not matter which solution, the USB device can't be enumerated
without power sequence. For the #2 solution, it just handles all
gpios under dts before the enumeration at USB code.
>
> >
> > If I get Rob's comments correctly, you may need to consider
> > below MMC and USB device tree description together, it seems
> > hard for USB to use pwrseq driver, sorry for confusing you.
> >
> > If rob can accept below USB device description, we have to
> > do it under USB. In future, if there is some suitable framework,
> > we can move it.
> >
> > 1. MMC device:
> > usdhc3_pwrseq: usdhc3_pwrseq {
> > compatible = "mmc-pwrseq-simple";
> > reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>, /* WL_REG_ON */
> > <&gpio4 7 GPIO_ACTIVE_LOW>, /* WL_HOSTWAKE
> > */
> > <&gpio3 25 GPIO_ACTIVE_LOW>, /* BT_REG_ON */
> > <&gpio3 27 GPIO_ACTIVE_LOW>, /* BT_HOSTWAKE
> > */
> > <&gpio4 4 GPIO_ACTIVE_LOW>, /* BT_WAKE */
> > <&gpio4 6 GPIO_ACTIVE_LOW>; /* BT_RST_N */
> > };
> >
> > &usdhc3 {
> > pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > pinctrl-0 = <&pinctrl_usdhc3>;
> > pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
> > pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
> > bus-width = <4>;
> > non-removable;
> > keep-power-in-suspend;
> > wakeup-source;
> > mmc-pwrseq = <&usdhc3_pwrseq>;
> > status = "okay";
> > };
> >
> > 2. USB device
> >
> > &usbotg1 {
> > vbus-supply = <®_usb_otg1_vbus>;
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_usb_otg1_id>;
> > status = "okay";
> >
> > #address-cells = <1>;
> > #size-cells = <0>;
> > hub: genesys@1 {
> > compatible = "usb5e3,608";
> > reg = <1>;
> > reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> > reset-duration-us = <10>;
> > clocks = <&clks IMX6SX_CLK_CKO>;
> > };
>
> Yes, that looks like what Rob wanted... Do you plan to work on it? The
> power sequence is needed before device is enumerated.
>
Ok, I will work on it.
--
Best Regards,
Peter Chen
--
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
EL);
> + if (!pdev)
> + return ERR_PTR(-ENOMEM);
> +
> + mutex_init(&pdev->mux_mutex);
> + pdev->desc = desc;
> + pdev->dev.parent = desc->dev;
> + pdev->dev.release = portmux_dev_release;
> + dev_set_name(&pdev->dev, "portmux.%lu",
> + (unsigned long)atomic_inc_return(&portmux_no));
> + pdev->dev.groups = portmux_group;
> + ret = device_register(&pdev->dev);
> + if (ret) {
> + kfree(pdev);
> + return ERR_PTR(ret);
> + }
> +
> + dev_set_drvdata(&pdev->dev, pdev);
> +
> + return pdev;
> +}
> +EXPORT_SYMBOL_GPL(portmux_register);
> +
> +/**
> + * portmux_unregister - unregister a port mux
> + * @pdev: the port mux device
> + *
> + * Called by port mux drivers to release a mux.
> + */
> +void portmux_unregister(struct portmux_dev *pdev)
> +{
> + device_unregister(&pdev->dev);
> + kfree(pdev);
> +}
> +EXPORT_SYMBOL_GPL(portmux_unregister);
> +
> +/**
> + * portmux_switch - switch the port role
> + * @pdev: the port mux device
> + * @role: the target role
> + *
> + * Called by other components to switch the port role.
> + */
> +int portmux_switch(struct portmux_dev *pdev, enum portmux_role role)
> +{
> + int ret;
> +
> + mutex_lock(&pdev->mux_mutex);
> + ret = usb_mux_change_state(pdev, role);
> + mutex_unlock(&pdev->mux_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(portmux_switch);
> +
> +#ifdef CONFIG_PM_SLEEP
> +/**
> + * portmux_complete - refresh port state during system resumes back
> + * @pdev: the port mux device
> + *
> + * Called by port mux drivers to refresh port state during system
> + * resumes back.
> + */
> +void portmux_complete(struct portmux_dev *pdev)
> +{
> + mutex_lock(&pdev->mux_mutex);
> + usb_mux_change_state(pdev, pdev->mux_state);
> + mutex_unlock(&pdev->mux_mutex);
> +}
> +EXPORT_SYMBOL_GPL(portmux_complete);
> +#endif
> diff --git a/include/linux/usb/portmux.h b/include/linux/usb/portmux.h
> new file mode 100644
> index 000..093620a
> --- /dev/null
> +++ b/include/linux/usb/portmux.h
> @@ -0,0 +1,90 @@
> +/**
> + * portmux.h - USB Port Mux definitions
> + *
> + * Copyright (C) 2016 Intel Corporation
> + *
> + * Author: Lu Baolu
> + *
> + * 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.
> + */
> +
> +#ifndef __LINUX_USB_PORTMUX_H
> +#define __LINUX_USB_PORTMUX_H
> +
> +#include
> +
> +/**
> + * struct portmux_ops - ops two switch the port
> + *
> + * @set_host_cb: callback for switching port to host
> + * @set_device_cb: callback for switching port to device
> + */
> +struct portmux_ops {
> + int (*set_host_cb)(struct device *dev);
> + int (*set_device_cb)(struct device *dev);
> +};
> +
> +/**
> + * struct portmux_desc - port mux device descriptor
> + *
> + * @name: the name of the mux device
> + * @dev: the parent of the mux device
> + * @ops: ops to switch the port role
> + */
> +struct portmux_desc {
> + const char *name;
> + struct device *dev;
> + const struct portmux_ops *ops;
> +};
> +
> +/**
> + * enum portmux_role - role of the port
> + */
> +enum portmux_role {
> + PORTMUX_UNKNOWN,
> + PORTMUX_HOST,
> + PORTMUX_DEVICE,
> +};
> +
> +/**
> + * struct portmux_dev - A mux device
> + *
> + * @desc: the descriptor of the mux
> + * @dev: device of this mux
> + * @mux_mutex: lock to serialize port switch operation
> + * @mux_state: state of the mux
> + */
> +struct portmux_dev {
> + const struct portmux_desc *desc;
> + struct device dev;
> +
> + /* lock for mux_state */
> + struct mutex mux_mutex;
> + enum portmux_role mux_state;
> +};
> +
> +/*
> + * Functions for mux driver
> + */
> +struct portmux_dev *portmux_register(struct portmux_desc *desc);
> +void portmux_unregister(struct portmux_dev *pdev);
> +#ifdef CONFIG_PM_SLEEP
> +void portmux_complete(struct portmux_dev *pdev);
> +#endif
> +
> +/*
> + * Functions for mux consumer
> + */
> +#if defined(CONFIG_USB_PORTMUX)
> +int portmux_switch(struct portmux_dev *pdev, enum portmux_role role);
> +#else
> +static inline int portmux_switch(struct portmux_dev *pdev,
> + enum portmux_role role)
> +{
> + return 0;
> +}
> +#endif
> +
> +#endif /* __LINUX_USB_PORTMUX_H */
> --
> 2.1.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
--
Best Regards,
Peter Chen
--
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 Fri, Jun 03, 2016 at 11:16:32AM +0300, Heikki Krogerus wrote: > On Fri, Jun 03, 2016 at 03:41:13PM +0800, Peter Chen wrote: > > On Thu, Jun 02, 2016 at 09:37:24AM +0800, Lu Baolu wrote: > > > Several Intel platforms implement USB dual role by having completely > > > separate xHCI and dwc3 IPs in PCH or SOC silicons. These two IPs share > > > a single USB port. There is another external port mux which controls > > > where the data lines should go. While the USB controllers are part of > > > the silicon, the port mux design are platform specific. > > > > > > This patch adds the generic code to handle such multiple roles of a > > > usb port. It exports the necessary interfaces for other components to > > > register or unregister a usb mux device, and to control its role. > > > It registers the mux device with sysfs as well, so that users are able > > > to control the port role from user space. > > > > > > Some other archs (e.g. Renesas R-Car gen2 SoCs) need an external mux to > > > swap usb roles as well. This code could also be leveraged for those archs. > > > > > > > Sorry to review this so late, from my point, it is a dual-role switch > > driver too, we are reviewing USB OTG/dual-role framework [1], it is > > not necessary to create another framework to do it. And USB OTG framework > > has already tested at Renesas's platform [2]. > > > > [1] http://www.spinics.net/lists/linux-usb/msg140835.html > > [2] http://www.spinics.net/lists/linux-usb/msg140827.html > > We really can't marry dual-role capability with OTG. That OTG > framework can be used be when the hardware actually supports the > protocols defined in the OTG spec starting from SRP. In other cases it > must not be used. > > OTG relies heavily on existence of the ID pin, but with Type-C > connectors we do not have it. Therefore USB Type-C defines competing > support for example for the role swapping. With USB Type-C connectors > OTG will never be supported. > > So let's not mix USB dual-role capability with OTG. > Well, DRD/OTG framework is mainly used for dual-role switch, no matter what input is, you can use id pin, sysfs, or Type-C events. It is long term target, currently, it only supports id pin. In future, we can expend it to support more input events. Microsoft also has similar framework for it: https://msdn.microsoft.com/en-us/library/windows/hardware/dn957036(v=vs.85).aspx -- Best Regards, Peter Chen -- 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 Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote: > Hi Peter, > > On 06/03/2016 03:41 PM, Peter Chen wrote: > > On Thu, Jun 02, 2016 at 09:37:24AM +0800, Lu Baolu wrote: > >> > Several Intel platforms implement USB dual role by having completely > >> > separate xHCI and dwc3 IPs in PCH or SOC silicons. These two IPs share > >> > a single USB port. There is another external port mux which controls > >> > where the data lines should go. While the USB controllers are part of > >> > the silicon, the port mux design are platform specific. > >> > > >> > This patch adds the generic code to handle such multiple roles of a > >> > usb port. It exports the necessary interfaces for other components to > >> > register or unregister a usb mux device, and to control its role. > >> > It registers the mux device with sysfs as well, so that users are able > >> > to control the port role from user space. > >> > > >> > Some other archs (e.g. Renesas R-Car gen2 SoCs) need an external mux to > >> > swap usb roles as well. This code could also be leveraged for those > >> > archs. > >> > > > Sorry to review this so late, > > It doesn't matter. Thanks for review. Comments are always welcome.:-) > > > 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. Your case is just like Renesas case, which uses two different drivers between peripheral and host[1]. > Port multiplexing isn't equal to USB dual role. There are other cases in > today's > systems. In several Intel PCH chips, there equips two USB host controllers: > ehci > and xhci. The xhci USB2 ports are multiplexed with ehci. This guarantees all > USB ports work even running an old version of OS which lacks of USB3 support. > In theory, we can create a driver for the port mux and switch the ports > between > xhci and ehci, but that's silly, isn't it? Why not always USB3?:-) > > Another case is xHCI debug capability. The xHCI host controller might equip > a unit for system debugging (refer to 7.6 of xHCI spec). The debugging unit is > independent of xhci host controller. But it shares its port with xhci. > Software > could switch the port between xhci and the debugging unit through the > registers > defined in xHCI spec. > Yes, above two are different with dual role switch. But in your code and Kconfig, it seems this framework is dedicated for dual-role. Eg: +menuconfig USB_PORTMUX + bool "USB dual role port MUX support" + help + Generic USB dual role port mux support. I think a general dual role port mux is necessary, it can be used to manage different dual-role switch method, eg - ID pin - External connector through GPIO - SoC register - sysfs - type-C events 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. [1] https://lkml.org/lkml/2016/4/7/115 -- Best Regards, Peter Chen -- 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 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. > > > 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. > > >> Port multiplexing isn't equal to USB dual role. There are other cases in > >> today's > >> systems. In several Intel PCH chips, there equips two USB host > >> controllers: ehci > >> and xhci. The xhci USB2 ports are multiplexed with ehci. This guarantees > >> all > >> USB ports work even running an old version of OS which lacks of USB3 > >> support. > >> In theory, we can create a driver for the port mux and switch the ports > >> between > >> xhci and ehci, but that's silly, isn't it? Why not always USB3?:-) > >> > >> Another case is xHCI debug capability. The xHCI host controller might equip > >> a unit for system debugging (refer to 7.6 of xHCI spec). The debugging > >> unit is > >> independent of xhci host controller. But it shares its port with xhci. > >> Software > >> could switch the port between xhci and the debugging unit through the > >> registers > >> defined in xHCI spec. > >> > > Yes, above two are different with dual role switch. But in your code and > > Kconfig, it seems this framework is dedicated for dual-role. Eg: > > > > +menuconfig USB_PORTMUX > > + bool "USB dual role port MUX support" > > + help > > + Generic USB dual role port mux support. > > Above two cases are examples for port multiplexing, but I don't think we > need drivers for them. At this moment, this framework is only for dual > role port mux devices. > > > > > I think a general dual role port mux is necessary, it can be used to > > manage different dual-role switch method, eg > > Yes, I agree. > > > - ID pin > > - External connector through GPIO > > - SoC register > > - sysfs > > - type-C events > > ID pin and type-C events are the *reasons* which trigger the port > mux switch. Currently, on our platforms, gpio, registers and sysfs > are methods to control the mux. > > > > > 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? -- Best Regards, Peter Chen -- 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 Sun, Jun 05, 2016 at 04:46:55PM +0800, Lu Baolu wrote: > Hi, > > On 06/05/2016 04:33 PM, Jun Li wrote: > >> 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. > >> > > >>> > > 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. > >> > > > I also think current OTG/Dual role framework can support your case, if you > > find there is any limitation of it which can't meet your requirement, we > > should improve it, Roger also provide an example of dual role switch with > > USB3 based on his OTG core. > > Why do we need an OTG framework to support a device driver? Just like you said above, OTG framework can manage role switch, the role switch may need to start or stop host/gadget driver according to different hardware signals or user input. > Is it something like a bus or class driver? The DRD/OTG framework uses the same device structure with the caller, the caller can be a dual-role controller driver (like dwc3, chipidea, etc), or a separate switch driver which like your mux port driver. -- Best Regards, Peter Chen -- 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 v3 06/12] power: pwrseq: simple: Add support for regulator and generic property
On Fri, Jun 03, 2016 at 02:35:08PM +0200, Krzysztof Kozlowski wrote:
> On 06/03/2016 04:02 AM, Rob Herring wrote:
> > On Wed, Jun 01, 2016 at 10:02:15AM +0200, Krzysztof Kozlowski wrote:
> >> Some devices need real hard-reset by cutting the power. During power
> >> sequence turn off and on the regulator, if it is provided.
> >>
> >> Additionally add support for instantiating the pwrseq-simple device on a
> >> generic property 'power-sequence'. The device will attach itself to the
> >> node containing the property and parse the node's properties like
> >> reset-gpios, ext-supply etc.
> >>
> >> Signed-off-by: Krzysztof Kozlowski
> >> ---
> >> .../bindings/power/pwrseq/pwrseq-simple.txt| 29 +++-
> >> drivers/power/pwrseq/pwrseq_simple.c | 85
> >> +-
> >> 2 files changed, 107 insertions(+), 7 deletions(-)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> >> b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> >> index ce0e76749671..a8c3f13ee83f 100644
> >> --- a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> >> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> >> @@ -1,11 +1,17 @@
> >> -* The simple MMC power sequence provider
> >> +* The simple power sequence provider
> >>
> >> -The purpose of the simple MMC power sequence provider is to supports a
> >> set of
> >> +The purpose of the simple power sequence provider is to supports a set of
> >> common properties between various SOC designs. It thus enables us to use
> >> the
> >> same provider for several SOC designs.
> >>
> >> -Required properties:
> >> -- compatible : contains "mmc-pwrseq-simple".
> >> +The driver supports two types of bindings:
> >> +1. Separate node
> >> + Required properties:
> >> + - compatible : contains "mmc-pwrseq-simple".
> >
> > Please note that this is not recommended for new users.
>
> Sure.
>
> >
> >> +
> >> +2. Property for any node
> >> + Required properties:
> >> + - power-sequence
> >>
> >> Optional properties:
> >> - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are
> >> asserted
> >> @@ -16,6 +22,7 @@ Optional properties:
> >>See ../clocks/clock-bindings.txt for details.
> >> - clock-names : Must include the following entry:
> >>"ext_clock" (External clock provided to the card).
> >> +- ext-supply : External regulator supply
> >
> > What happens when there are 2 supplies?
> >
> > I'd prefer the name not be genericish and use the real supply names.
> > Then the power seq code should just turn on all supplies it finds. If
> > the order or timing to turn on matters, then sorry, no generic sequence.
>
> Understood. I'll change the code to use any supply.
>
> As for the genericness of this approach, Sylwester Nawrocki pointed an
> old thread:
> [PATCH v6 0/4] Runtime Interpreted Power Sequences
> https://lkml.org/lkml/2012/9/12/127
>
> How do you like that approach?
>
Rob, I am trying to implement the dts layout you suggested (see below),
but I find it is very hard to it due to the device is still not created,
without device, it is hard to manage the resources under this device (
Eg, de-initialization for probe deferral case). So, a common driver
is suitable for this power sequence case.
&usbotg1 {
vbus-supply = <®_usb_otg1_vbus>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usb_otg1_id>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
hub: genesys@1 {
compatible = "usb5e3,608";
reg = <1>;
reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
reset-duration-us = <10>;
clocks = <&clks IMX6SX_CLK_CKO>;
};
};
--
Best Regards,
Peter Chen
--
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 Mon, Jun 06, 2016 at 10:45:34AM +0800, Lu Baolu wrote: > Hi Peter, > > On 06/06/2016 10:05 AM, Peter Chen wrote: > > On Sun, Jun 05, 2016 at 04:46:55PM +0800, Lu Baolu wrote: > >> Hi, > >> > >> On 06/05/2016 04:33 PM, Jun Li wrote: > >>>> 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. > >>>>> > >>>>>>> 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. > >>>>> > >>> I also think current OTG/Dual role framework can support your case, if you > >>> find there is any limitation of it which can't meet your requirement, we > >>> should improve it, Roger also provide an example of dual role switch with > >>> USB3 based on his OTG core. > >> Why do we need an OTG framework to support a device driver? > > Just like you said above, OTG framework can manage role switch, the > > role switch may need to start or stop host/gadget driver according to > > different hardware signals or user input. > > We don't have any OTG or dual-role (reduced OTG) capable > controllers. So we don't need to aid OTG framework to > start/stop host/gadget drivers. > In your case, the related APIs are NULL. > > > >> Is it something like a bus or class driver? > > The DRD/OTG framework uses the same device structure with the caller, > > the caller can be a dual-role controller driver (like dwc3, chipidea, > > etc), or a separate switch driver which like your mux port driver. > > > > From my point of view, this isn't the right way to handle a port > mux device. > > We have many kinds of port mux devices across multiple archs, > we should have a generic framework for them, so that consumers, > (like OTG framework) can manipulate port mux devices through a > common interfaces. Just like we already have frameworks for PHY, > VBUS regulator and ... > But, in your framework, it will finish the role switch like OTG framework does. -- Best Regards, Peter Chen -- 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 Mon, Jun 06, 2016 at 11:04:48AM +0800, 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. > > > >> 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. > The user may not know the detail, they will do role switch according to sysfs documentation. Yes, in your role switch case, only port mux is enough, but for others, it needs other operations. I agree with Roger that the dual-role switch part in your code is better to use OTG framework to reduce redundancy. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and legacy gadgets
ct CRC32 > help > This driver implements USB CDC NCM subclass standard. NCM is > @@ -186,8 +185,8 @@ config USB_GADGETFS > > config USB_FUNCTIONFS > tristate "Function Filesystem" > - select USB_LIBCOMPOSITE > - select USB_F_FS > + depends on USB_LIBCOMPOSITE > + select USB_G_FUNCTIONFS_REQ_F_FS > select USB_FUNCTIONFS_GENERIC if !(USB_FUNCTIONFS_ETH || > USB_FUNCTIONFS_RNDIS) > help > The Function Filesystem (FunctionFS) lets one create USB > @@ -206,9 +205,8 @@ config USB_FUNCTIONFS > config USB_FUNCTIONFS_ETH > bool "Include configuration with CDC ECM (Ethernet)" > depends on USB_FUNCTIONFS && NET > - select USB_U_ETHER > - select USB_F_ECM > - select USB_F_SUBSET > + select USB_G_FUNCTIONFS_REQ_F_ECM > + select USB_G_FUNCTIONFS_REQ_F_SUBSET > help > Include a configuration with CDC ECM function (Ethernet) and the > Function Filesystem. > @@ -216,8 +214,7 @@ config USB_FUNCTIONFS_ETH > config USB_FUNCTIONFS_RNDIS > bool "Include configuration with RNDIS (Ethernet)" > depends on USB_FUNCTIONFS && NET > - select USB_U_ETHER > - select USB_F_RNDIS > + select USB_G_FUNCTIONFS_REQ_F_RNDIS > help > Include a configuration with RNDIS function (Ethernet) and the > Filesystem. > > @@ -231,8 +228,8 @@ config USB_FUNCTIONFS_GENERIC > config USB_MASS_STORAGE > tristate "Mass Storage Gadget" > depends on BLOCK > - select USB_LIBCOMPOSITE > - select USB_F_MASS_STORAGE > + depends on USB_LIBCOMPOSITE > + select USB_G_MASS_STORAGE_REQ_F_MASS_STORAGE > help > The Mass Storage Gadget acts as a USB Mass Storage disk drive. > As its storage repository it can use a regular file or a block > @@ -248,8 +245,8 @@ config USB_MASS_STORAGE > config USB_GADGET_TARGET > tristate "USB Gadget Target Fabric Module" > depends on TARGET_CORE > - select USB_LIBCOMPOSITE > - select USB_F_TCM > + depends on USB_LIBCOMPOSITE > + select USB_G_TCM_REQ_F_TCM > help > This fabric is an USB gadget. Two USB protocols are supported that is > BBB or BOT (Bulk Only Transport) and UAS (USB Attached SCSI). BOT is > @@ -260,11 +257,10 @@ config USB_GADGET_TARGET > config USB_G_SERIAL > tristate "Serial Gadget (with CDC ACM and CDC OBEX support)" > depends on TTY > - select USB_U_SERIAL > - select USB_F_ACM > - select USB_F_SERIAL > - select USB_F_OBEX > - select USB_LIBCOMPOSITE > + select USB_G_SERIAL_REQ_F_ACM > + select USB_G_SERIAL_REQ_F_SERIAL > + select USB_G_SERIAL_REQ_F_OBEX > + depends on USB_LIBCOMPOSITE > help > The Serial Gadget talks to the Linux-USB generic serial driver. > This driver supports a CDC-ACM module option, which can be used > @@ -285,9 +281,8 @@ config USB_G_SERIAL > config USB_MIDI_GADGET > tristate "MIDI Gadget" > depends on SND > - select USB_LIBCOMPOSITE > - select SND_RAWMIDI > - select USB_F_MIDI > + depends on USB_LIBCOMPOSITE > + select USB_G_MIDI_REQ_F_MIDI > help > The MIDI Gadget acts as a USB Audio device, with one MIDI > input and one MIDI output. These MIDI jacks appear as > @@ -300,8 +295,8 @@ config USB_MIDI_GADGET > > config USB_G_PRINTER > tristate "Printer Gadget" > - select USB_LIBCOMPOSITE > - select USB_F_PRINTER > + depends on USB_LIBCOMPOSITE > + select USB_G_PRINTER_REQ_F_PRINTER > help > The Printer Gadget channels data between the USB host and a > userspace program driving the print engine. The user space > @@ -320,11 +315,9 @@ if TTY > config USB_CDC_COMPOSITE > tristate "CDC Composite Device (Ethernet and ACM)" > depends on NET > - select USB_LIBCOMPOSITE > - select USB_U_SERIAL > - select USB_U_ETHER > - select USB_F_ACM > - select USB_F_ECM > + depends on USB_LIBCOMPOSITE > + select USB_G_CDC_COMPOSITE_REQ_F_ACM > + select USB_G_CDC_COMPOSITE_REQ_F_ECM > help > This driver provides two functions in one configuration: > a CDC Ethernet (ECM) link, and a CDC ACM (serial port) link. > @@ -340,14 +333,12 @@ config USB_G_NOKIA > tristate "Nokia composite gadget" > depends on PHONET > depends on BLOCK > - select USB_LIBCOMPOSITE > - select USB_U_SERIAL > - select USB_U_ETHER > - select USB_F_ACM > - select USB_F_OBEX > - select USB_F_PHONET > - select USB_F_ECM > - select USB_F_MASS_STORAGE > + depends on USB_LIBCOMPOSITE > + select USB_G_NOKIA_REQ_F_ACM > + select USB_G_NOKIA_REQ_F_OBEX > + select USB_G_NOKIA_REQ_F_PHONET > + select USB_G_NOKIA_REQ_F_ECM > + select USB_G_NOKIA_REQ_F_MASS_STORAGE > help > The Nokia composite gadget provides support for acm, obex > and phonet in only one composite gadget driver. > @@ -358,10 +349,9 @@ config USB_G_NOKIA > config USB_G_ACM_MS > tristate "CDC Composite Device (ACM and mass storage)" > depends on BLOCK > - select USB_LIBCOMPOSITE > - select USB_U_SERIAL > - select USB_F_ACM > - select USB_F_MASS_STORAGE > + depends on USB_LIBCOMPOSITE > + select USB_G_ACM_MS_REQ_F_ACM > + select USB_G_ACM_MS_F_MASS_STORAGE > help > This driver provides two functions in one configuration: > a mass storage, and a CDC ACM (serial port) link. > @@ -373,11 +363,9 @@ config USB_G_MULTI > tristate "Multifunction Composite Gadget" > depends on BLOCK && NET > select USB_G_MULTI_CDC if !USB_G_MULTI_RNDIS > - select USB_LIBCOMPOSITE > - select USB_U_SERIAL > - select USB_U_ETHER > - select USB_F_ACM > - select USB_F_MASS_STORAGE > + depends on USB_LIBCOMPOSITE > + select USB_G_MULTI_REQ_F_ACM > + select USB_G_MULTI_REQ_F_MASS_STORAGE > help > The Multifunction Composite Gadget provides Ethernet (RNDIS > and/or CDC Ethernet), mass storage and ACM serial link > @@ -396,7 +384,7 @@ config USB_G_MULTI > config USB_G_MULTI_RNDIS > bool "RNDIS + CDC Serial + Storage configuration" > depends on USB_G_MULTI > - select USB_F_RNDIS > + select USB_G_MULTI_REQ_F_RNDIS > default y > help > This option enables a configuration with RNDIS, CDC Serial and > @@ -410,7 +398,7 @@ config USB_G_MULTI_CDC > bool "CDC Ethernet + CDC Serial + Storage configuration" > depends on USB_G_MULTI > default n > - select USB_F_ECM > + select USB_G_MULTI_REQ_F_ECM > help > This option enables a configuration with CDC Ethernet (ECM), CDC > Serial and Mass Storage functions available in the Multifunction > @@ -422,8 +410,8 @@ endif # TTY > > config USB_G_HID > tristate "HID Gadget" > - select USB_LIBCOMPOSITE > - select USB_F_HID > + depends on USB_LIBCOMPOSITE > + select USB_G_HID_REQ_F_HID > help > The HID gadget driver provides generic emulation of USB > Human Interface Devices (HID). > @@ -438,7 +426,7 @@ config USB_G_HID > config USB_G_DBGP > tristate "EHCI Debug Device Gadget" > depends on TTY > - select USB_LIBCOMPOSITE > + depends on USB_LIBCOMPOSITE > help > This gadget emulates an EHCI Debug device. This is useful when you > want > to interact with an EHCI Debug Port. > @@ -459,7 +447,7 @@ config USB_G_DBGP_PRINTK > > config USB_G_DBGP_SERIAL > depends on USB_G_DBGP > - select USB_U_SERIAL > + select USB_G_DBG_REQ_U_SERIAL > bool "serial" > help > Userland can interact using /dev/ttyGSxxx. > @@ -471,9 +459,8 @@ endif > config USB_G_WEBCAM > tristate "USB Webcam Gadget" > depends on VIDEO_DEV > - select USB_LIBCOMPOSITE > - select VIDEOBUF2_VMALLOC > - select USB_F_UVC > + depends on USB_LIBCOMPOSITE > + select USB_G_WEBCAM_REQ_F_UVC > help > The Webcam Gadget acts as a composite USB Audio and Video Class > device. It provides a userspace API to process UVC control requests > @@ -481,3 +468,4 @@ config USB_G_WEBCAM > > Say "y" to link the driver statically, or "m" to build a > dynamically linked module called "g_webcam". > +endmenu > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards, Peter Chen -- 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: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'
ADGET=y || USB_GADGET=NOP_USB_XCEIV > depends on NOP_USB_XCEIV > > config USB_MUSB_DSPS > @@ -110,6 +115,7 @@ config USB_MUSB_DSPS > config USB_MUSB_BLACKFIN > tristate "Blackfin" > depends on (BF54x && !BF544) || (BF52x && ! BF522 && !BF523) > + depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV > depends on NOP_USB_XCEIV > > config USB_MUSB_UX500 > @@ -118,6 +124,7 @@ config USB_MUSB_UX500 > > config USB_MUSB_JZ4740 > tristate "JZ4740" > + depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV > depends on NOP_USB_XCEIV > depends on MACH_JZ4740 || COMPILE_TEST > depends on USB_MUSB_GADGET > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig > index c6904742e2aa..53c0f2220ce3 100644 > --- a/drivers/usb/phy/Kconfig > +++ b/drivers/usb/phy/Kconfig > @@ -43,7 +43,8 @@ config ISP1301_OMAP > config KEYSTONE_USB_PHY > tristate "Keystone USB PHY Driver" > depends on ARCH_KEYSTONE || COMPILE_TEST > - select NOP_USB_XCEIV > + depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV > + depends on NOP_USB_XCEIV > help > Enable this to support Keystone USB phy. This driver provides > interface to interact with USB 2.0 and USB 3.0 PHY that is part > @@ -63,9 +64,10 @@ config AM335X_CONTROL_USB > config AM335X_PHY_USB > tristate "AM335x USB PHY Driver" > depends on ARM || COMPILE_TEST > + depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV > + depends on NOP_USB_XCEIV > select USB_PHY > select AM335X_CONTROL_USB > - select NOP_USB_XCEIV > select USB_COMMON > help > This driver provides PHY support for that phy which part for the > > > Anybody has any problems with this being amended to original patch? Note > that NOP_USB_XCEIV should never have been selected with "select" to > start with. > > -- > balbi -- Best Regards, Peter Chen -- 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: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'
On Tue, Jun 07, 2016 at 12:36:13PM +0300, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > > On Mon, Jun 06, 2016 at 04:16:17PM +0300, Felipe Balbi wrote: > >> > >> Hi, > >> > >> Felipe Balbi writes: > >> > [ Unknown signature status ] > >> > > >> > Hi, > >> > > >> > kbuild test robot writes: > >> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > >> >> testing/next > >> >> head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060 > >> >> commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: > >> >> move gadget API functions to udc-core > >> >> config: x86_64-randconfig-s1-06061834 (attached as .config) > >> >> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 > >> >> reproduce: > >> >> git checkout 231b31ca34485552fe27e67dc6d30d06079c7648 > >> >> # save the attached .config to linux build tree > >> >> make ARCH=x86_64 > >> >> > >> >> All errors (new ones prefixed by >>): > >> >> > >> >>drivers/built-in.o: In function `nop_set_peripheral': > >> >>>> phy-generic.c:(.text+0x14423f): undefined reference to > >> >>>> `usb_gadget_vbus_connect' > >> >>drivers/built-in.o: In function `nop_gpio_vbus_thread': > >> >>>> phy-generic.c:(.text+0x144742): undefined reference to > >> >>>> `usb_gadget_vbus_disconnect' > >> > > >> > oh yeah, I have to fix this. I'll do it now. > >> > >> In order to fix this, I'll have to add something like below: > >> > >> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig > >> index 3644a3500b70..bd67e4ac4b61 100644 > >> --- a/drivers/usb/chipidea/Kconfig > >> +++ b/drivers/usb/chipidea/Kconfig > >> @@ -19,6 +19,7 @@ config USB_CHIPIDEA_OF > >> config USB_CHIPIDEA_PCI > >>tristate > >>depends on PCI > >> + depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV > >>depends on NOP_USB_XCEIV > >>default USB_CHIPIDEA > > > > Hi Felipe, > > > > It causes any drivers which use symbols from gadget.h needs to build > > USB_GADGET even it only wants to be host function. Any significant > > benefits after moving it to udc-core.c? > > why is a host-only function calling into the gadget API? > Well, Just like this case, the chipidea driver can be configured host mode only, but it still uses generic phy. Besides, we have some common code which handles vbus status, this code will be built even at host-only mode, but will not be called since the runtime condition is not satisfied, eg, dr_mode, device role at register. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] usb: gadget: Allow to build both USB functions and legacy gadgets
>-Original Message- >From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] >On Behalf Of Krzysztof Opasiak >Sent: Tuesday, June 07, 2016 3:46 PM >To: Peter Chen >Cc: Krzysztof Opasiak ; ba...@kernel.org; Greg Kroah- >Hartman ; Andrzej Pietrasiewicz >; Marek Szyprowski ; >linux-usb@vger.kernel.org >Subject: Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and >legacy gadgets > >Hi, > >On Tue, Jun 7, 2016 at 3:27 AM, Peter Chen wrote: >> On Mon, Jun 06, 2016 at 09:40:33PM +0200, Krzysztof Opasiak wrote: >>> Currently it is possible to build in some subset of usb functions >>> *OR* some gadget module. This is limited only by Kconfig not any >>> functionality. >>> >>> This patch removes this limitation. With this patch it is possible to >>> set up all build combinations: >>> 1) Multiple gadgets build in >> >> If that, what the user will expect if choosing multiple gadgets? >> Eg, if he chooses g_ncm and g_mass_storage, will he expect his udc has >> both mass_storage and ncm function, but it is not the fact, only the >> first gadget function will work. >> > >Not exactly one. You may build in multiple modules and use those multiple >modules if >you have multiple udcs. > My concern is: with your patch, the user may get unexpected results if he builds in multiple gadgets for this single udc. At current code, the user can't do that, then he will not get unexpected results. How do you consider that? Peter
Re: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'
On Tue, Jun 07, 2016 at 01:22:37PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> >> >> > kbuild test robot writes:
> >> >> >> tree:
> >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> >> >> >> testing/next
> >> >> >> head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060
> >> >> >> commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb:
> >> >> >> gadget: move gadget API functions to udc-core
> >> >> >> config: x86_64-randconfig-s1-06061834 (attached as .config)
> >> >> >> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> >> >> >> reproduce:
> >> >> >> git checkout 231b31ca34485552fe27e67dc6d30d06079c7648
> >> >> >> # save the attached .config to linux build tree
> >> >> >> make ARCH=x86_64
> >> >> >>
> >> >> >> All errors (new ones prefixed by >>):
> >> >> >>
> >> >> >>drivers/built-in.o: In function `nop_set_peripheral':
> >> >> >>>> phy-generic.c:(.text+0x14423f): undefined reference to
> >> >> >>>> `usb_gadget_vbus_connect'
> >> >> >>drivers/built-in.o: In function `nop_gpio_vbus_thread':
> >> >> >>>> phy-generic.c:(.text+0x144742): undefined reference to
> >> >> >>>> `usb_gadget_vbus_disconnect'
> >> >> >
> >> >> > oh yeah, I have to fix this. I'll do it now.
> >> >>
> >> >> In order to fix this, I'll have to add something like below:
> >> >>
> >> >> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> >> >> index 3644a3500b70..bd67e4ac4b61 100644
> >> >> --- a/drivers/usb/chipidea/Kconfig
> >> >> +++ b/drivers/usb/chipidea/Kconfig
> >> >> @@ -19,6 +19,7 @@ config USB_CHIPIDEA_OF
> >> >> config USB_CHIPIDEA_PCI
> >> >> tristate
> >> >> depends on PCI
> >> >> + depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV
> >> >> depends on NOP_USB_XCEIV
> >> >> default USB_CHIPIDEA
> >> >
> >> > Hi Felipe,
> >> >
> >> > It causes any drivers which use symbols from gadget.h needs to build
> >> > USB_GADGET even it only wants to be host function. Any significant
> >> > benefits after moving it to udc-core.c?
> >>
> >> why is a host-only function calling into the gadget API?
> >>
> >
> > Well, Just like this case, the chipidea driver can be configured host
> > mode only, but it still uses generic phy.
>
> then we should allow for PHYs to not depend on the Gadget API, right?
But you know it is not easy. The difficulty for gadget to do that is vbus and
pull dp, these two may be used by other subsystems, eg, vbus may be used
at PHY driver, dual-role switch driver, etc. The pull dp may be used at
USB charger driver, the secondary charger detection needs to pull up dp
for some charger designs.
See current kernel doc, it also says that.
/**
* usb_gadget_vbus_connect - Notify controller that VBUS is powered
* @gadget:The device which now has VBUS power.
* Context: can sleep
*
* This call is used by a driver for an external transceiver (or GPIO)
* that detects a VBUS power session starting. Common responses include
* resuming the controller, activating the D+ (or D-) pullup to let the
* host detect that a USB device is attached, and starting to draw power
* (8mA or possibly more, especially after SET_CONFIGURATION).
*
* Returns zero on success, else negative errno.
*/
static inline int usb_gadget_vbus_connect(struct usb_gadget *gadget)
{
if (!gadget->ops->vbus_session)
return -EOPNOTSUPP;
return gadget->ops->vbus_session(gadget, 1);
}
See current situations:
b29397@linux2:~/work/projects/usb$ find . -name *.c | xargs grep -rn
"usb_gadget_vbus_connect"
./drivers/phy/phy-twl4030-usb.c:559: * REVISIT
usb_gadget_vbus_connect(...) as needed, ditto
./drivers/usb/phy/phy-gpio-vbus-usb.c:126:
usb_gadget_vbus_connect(gpio_vbus->phy.otg->gadget);
./drivers/usb/phy/phy-tahvo.c:89:
usb_gadget_vbus_connect(tu->phy.otg-&g
Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
On Tue, Jun 07, 2016 at 06:05:25PM +0300, 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. > Indeed, some centralized IP drivers like MUSB, chipidea, dwc3 do not need this framework for role switch. But there are some common stuffs, like OTG FSM (fully/simplified), manage roles and sysfs for role switch, these things can be in a framework, the purpose of this framework is easy for dual-role switch function. Besides, when the host and device driver are in different folders for platform, eg host/ and gadget/udc/, a role switch driver is needed if we need dual role function. Recently, the dual-role function is more and more common for USB, a framework can avoid duplicated work and let switch be standardized. > > 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. Currently, there are some use cases which need to switch role on the fly (will be more for type-c in future), a sysfs for role switch is necessary. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and legacy gadgets
On Tue, Jun 07, 2016 at 11:59:57AM +0200, Krzysztof Opasiak wrote: > Hi, > > On Tue, Jun 7, 2016 at 11:06 AM, Peter Chen wrote: > > > > > >>-Original Message- > >>From: linux-usb-ow...@vger.kernel.org > >>[mailto:linux-usb-ow...@vger.kernel.org] > >>On Behalf Of Krzysztof Opasiak > >>Sent: Tuesday, June 07, 2016 3:46 PM > >>To: Peter Chen > >>Cc: Krzysztof Opasiak ; ba...@kernel.org; Greg Kroah- > >>Hartman ; Andrzej Pietrasiewicz > >>; Marek Szyprowski ; > >>linux-usb@vger.kernel.org > >>Subject: Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and > >>legacy gadgets > >> > >>Hi, > >> > >>On Tue, Jun 7, 2016 at 3:27 AM, Peter Chen wrote: > >>> On Mon, Jun 06, 2016 at 09:40:33PM +0200, Krzysztof Opasiak wrote: > >>>> Currently it is possible to build in some subset of usb functions > >>>> *OR* some gadget module. This is limited only by Kconfig not any > >>>> functionality. > >>>> > >>>> This patch removes this limitation. With this patch it is possible to > >>>> set up all build combinations: > >>>> 1) Multiple gadgets build in > >>> > >>> If that, what the user will expect if choosing multiple gadgets? > >>> Eg, if he chooses g_ncm and g_mass_storage, will he expect his udc has > >>> both mass_storage and ncm function, but it is not the fact, only the > >>> first gadget function will work. > >>> > >> > >>Not exactly one. You may build in multiple modules and use those multiple > >>modules if > >>you have multiple udcs. > >> > > > > My concern is: with your patch, the user may get unexpected results if he > > builds in > > multiple gadgets for this single udc. At current code, the user can't do > > that, then he will > > not get unexpected results. How do you consider that? > > > > That's true but even without this patch user may build multiple > gadgets as a modules. > > Even more, after commit (855ed04 "usb: gadget: udc-core: independent > registration of > gadgets and gadget drivers") it is possible to load multiple gadget > modules even if we have one UDC. > > So why would you like to disallow building in multiple gadgets if user > can build them as a modules and simply load? For module, the user can control which one to load, he or she can choose which function he needs. But if they are build-in, the user may make mistake and choose multiple gadgets, and get the unexpected results. This is only I concern. I just do not see the benefits that allow building in multiple gadgets, If you have some use cases, then that's reason for doing that:) > > If you concern about order of probing and binding to udc, I think that > we can add udc module param to all legacy gadgets so user can specify > in kernel cmd line where each gadget should be bound. > Yes, currently, we can't do that even the gadget is module, but the change may not be small. Now, we have configfs, it is not so necessary to add this future. -- Best Regards, Peter Chen -- 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 Wed, Jun 08, 2016 at 10:32:19AM +0300, Roger Quadros wrote:
> 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_fi
Re: [PATCH v9 08/14] usb: otg: add OTG/dual-role core
_otg_state state;
> + struct device *dev;
> + struct usb_otg_caps caps;
> struct otg_fsm fsm;
> struct otg_hcd_ops *hcd_ops;
>
> + /* internal use only */
> + struct otg_hcd primary_hcd;
> + struct otg_hcd shared_hcd;
> + struct otg_gadget_ops *gadget_ops;
> + bool gadget_ready;
> + struct list_head list;
> + struct work_struct work;
> + struct workqueue_struct *wq;
> + u32 flags;
> +#define OTG_FLAG_GADGET_RUNNING (1 << 0)
> +#define OTG_FLAG_HOST_RUNNING (1 << 1)
> + /* use otg->fsm.lock for serializing access */
> +
> +/*- deprecated interface -*/
> /* bind/unbind the host controller */
> int (*set_host)(struct usb_otg *otg, struct usb_bus *host);
>
> @@ -42,26 +118,101 @@ struct usb_otg {
>
> /* start or continue HNP role switch */
> int (*start_hnp)(struct usb_otg *otg);
> -
> +/*---*/
> };
>
> /**
> - * struct usb_otg_caps - describes the otg capabilities of the device
> - * @otg_rev: The OTG revision number the device is compliant with, it's
> - * in binary-coded decimal (i.e. 2.0 is 0200H).
> - * @hnp_support: Indicates if the device supports HNP.
> - * @srp_support: Indicates if the device supports SRP.
> - * @adp_support: Indicates if the device supports ADP.
> + * 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_caps {
> - u16 otg_rev;
> - bool hnp_support;
> - bool srp_support;
> - bool adp_support;
> +struct usb_otg_config {
> + struct usb_otg_caps *otg_caps;
> + struct otg_fsm_ops *fsm_ops;
> + void (*otg_work)(struct work_struct *work);
> };
>
> extern const char *usb_otg_state_string(enum usb_otg_state state);
>
> +#if IS_ENABLED(CONFIG_USB_OTG)
> +struct usb_otg *usb_otg_register(struct device *dev,
> + struct usb_otg_config *config);
> +int usb_otg_unregister(struct device *dev);
> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
> + unsigned long irqflags, struct otg_hcd_ops *ops);
> +int usb_otg_unregister_hcd(struct usb_hcd *hcd);
> +int usb_otg_register_gadget(struct usb_gadget *gadget,
> + struct otg_gadget_ops *ops);
> +int usb_otg_unregister_gadget(struct usb_gadget *gadget);
> +void usb_otg_sync_inputs(struct usb_otg *otg);
> +int usb_otg_kick_fsm(struct device *otg_dev);
> +int usb_otg_start_host(struct usb_otg *otg, int on);
> +int usb_otg_start_gadget(struct usb_otg *otg, int on);
> +int usb_otg_gadget_ready(struct usb_gadget *gadget, bool ready);
> +
> +#else /* CONFIG_USB_OTG */
> +
> +static inline struct usb_otg *usb_otg_register(struct device *dev,
> +struct usb_otg_config *config)
> +{
> + return ERR_PTR(-ENOTSUPP);
> +}
> +
> +static inline int usb_otg_unregister(struct device *dev)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int
> irqnum,
> +unsigned long irqflags,
> +struct otg_hcd_ops *ops)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_unregister_hcd(struct usb_hcd *hcd)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_register_gadget(struct usb_gadget *gadget,
> + struct otg_gadget_ops *ops)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_unregister_gadget(struct usb_gadget *gadget)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline void usb_otg_sync_inputs(struct usb_otg *otg)
> +{
> +}
> +
> +static inline int usb_otg_kick_fsm(struct device *otg_dev)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_start_host(struct usb_otg *otg, int on)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_start_gadget(struct usb_otg *otg, int on)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline int usb_otg_gadget_ready(struct usb_gadget *gadget, bool ready)
> +{
> + return -ENOTSUPP;
> +}
> +#endif /* CONFIG_USB_OTG */
> +
> +/*- deprecated interface -*/
> /* Context: can sleep */
> static inline int
> otg_start_hnp(struct usb_otg *otg)
> @@ -113,6 +264,8 @@ otg_start_srp(struct usb_otg *otg)
> return -ENOTSUPP;
> }
>
> +/*---*/
> +
> /* for OTG controller drivers (and maybe other stuff) */
> extern int usb_bus_start_enum(struct usb_bus *bus, unsigned port_num);
>
> @@ -237,4 +390,6 @@ static inline int otg_start_gadget(struct usb_otg *otg,
> int on)
> return otg->fsm.ops->start_gadget(otg, on);
> }
>
> +int drd_statemachine(struct usb_otg *otg);
> +
> #endif /* __LINUX_USB_OTG_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
--
Best Regards,
Peter Chen
--
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: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'
On Wed, Jun 08, 2016 at 12:50:57PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> >> >> > Hi Felipe,
> >> >> >
> >> >> > It causes any drivers which use symbols from gadget.h needs to build
> >> >> > USB_GADGET even it only wants to be host function. Any significant
> >> >> > benefits after moving it to udc-core.c?
> >> >>
> >> >> why is a host-only function calling into the gadget API?
> >> >>
> >> >
> >> > Well, Just like this case, the chipidea driver can be configured host
> >> > mode only, but it still uses generic phy.
> >>
> >> then we should allow for PHYs to not depend on the Gadget API, right?
> >
> > But you know it is not easy. The difficulty for gadget to do that is
> > vbus and pull dp, these two may be used by other subsystems, eg, vbus
> > may be used at PHY driver, dual-role switch driver, etc. The pull dp
> > may be used at USB charger driver, the secondary charger detection
> > needs to pull up dp for some charger designs.
>
> that's fine. And if they really need that, they depend on the Gadget
> API. That _is_ something the gadget API defines afterall.
>
> > See current kernel doc, it also says that.
> >
> > /**
> > * usb_gadget_vbus_connect - Notify controller that VBUS is powered
> > * @gadget:The device which now has VBUS power.
> > * Context: can sleep
> > *
> > * This call is used by a driver for an external transceiver (or GPIO)
> > * that detects a VBUS power session starting. Common responses include
> > * resuming the controller, activating the D+ (or D-) pullup to let the
> > * host detect that a USB device is attached, and starting to draw power
> > * (8mA or possibly more, especially after SET_CONFIGURATION).
> > *
> > * Returns zero on success, else negative errno.
> > */
> > static inline int usb_gadget_vbus_connect(struct usb_gadget *gadget)
> > {
> > if (!gadget->ops->vbus_session)
> > return -EOPNOTSUPP;
> > return gadget->ops->vbus_session(gadget, 1);
> > }
> >
> > See current situations:
> >
> > b29397@linux2:~/work/projects/usb$ find . -name *.c | xargs grep -rn
> > "usb_gadget_vbus_connect"
> > ./drivers/phy/phy-twl4030-usb.c:559: * REVISIT
> > usb_gadget_vbus_connect(...) as needed, ditto
> > ./drivers/usb/phy/phy-gpio-vbus-usb.c:126:
> > usb_gadget_vbus_connect(gpio_vbus->phy.otg->gadget);
> > ./drivers/usb/phy/phy-tahvo.c:89:
> > usb_gadget_vbus_connect(tu->phy.otg->gadget);
> > ./drivers/usb/phy/phy-isp1301-omap.c:929:
> > usb_gadget_vbus_connect(isp->phy.otg->gadget);
> > ./drivers/usb/phy/phy-isp1301-omap.c:1466:
> > usb_gadget_vbus_connect(otg->gadget);
> > ./drivers/usb/phy/phy-generic.c:122:
> > usb_gadget_vbus_connect(otg->gadget);
> > ./drivers/usb/phy/phy-generic.c:190:
> > usb_gadget_vbus_connect(gadget);
> > ./drivers/usb/phy/phy-msm-usb.c:783:
> > usb_gadget_vbus_connect(phy->otg->gadget);
> > ./drivers/usb/phy/phy-mv-usb.c:234:
> > usb_gadget_vbus_connect(otg->gadget);
> > ./drivers/usb/chipidea/otg.c:133:
> > usb_gadget_vbus_connect(&ci->gadget);
> > ./drivers/usb/chipidea/otg.c:138:
> > usb_gadget_vbus_connect(&ci->gadget);
> > ./drivers/usb/chipidea/udc.c:1964:
> > usb_gadget_vbus_connect(&ci->gadget);
> > ./drivers/usb/chipidea/otg_fsm.c:567:
> > usb_gadget_vbus_connect(&ci->gadget);
> > b29397@linux2:~/work/projects/usb$ find . -name *.c | xargs grep -rn
> > "usb_gadget_vbus_disconnect"
> > ./drivers/usb/phy/phy-gpio-vbus-usb.c:145:
> > usb_gadget_vbus_disconnect(gpio_vbus->phy.otg->gadget);
> > ./drivers/usb/phy/phy-gpio-vbus-usb.c:200:
> > usb_gadget_vbus_disconnect(otg->gadget);
> > ./drivers/usb/phy/phy-tahvo.c:108:
> > usb_gadget_vbus_disconnect(tu->phy.otg->gadget);
> > ./drivers/usb/phy/phy-tahvo.c:165:
> > usb_gadget_vbus_disconnect(tu->phy.otg->gadget);
> > ./drivers/usb/phy/phy-tahvo.c:175:
> > usb_gadget_vbus_disconnect(tu->phy.otg->gadget);
> > ./drivers/usb/phy/phy-isp1301-omap.c:312: return
> &
Re: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'
On Wed, Jun 08, 2016 at 01:32:29PM +0300, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > >> > Would you consider only keeps vbus and pull dp API at gadget.h, and move > >> > out others gadget APIs which is dedicated for gadget function? > >> > >> no, sorry :-) All these drivers depend on the gadget API to work. For > >> host-only builds, they'll still work because of the stub implemented in > >> gadget.h. > > > > Do you want these drivers to add dependency on GADGET at Kconfig > > or not? If you want, we don't need stub at gadget.h since the gadget > > just look at what the patch does: > > if USB_GADGET=m, then NOP must be m too. if USB_GADGET=y, then NOP can > be y or m. > > > will be built if these driver is built. I assume you don't want, then > > that's ok, we don't need to change anything on Kconfig to fix build > > issue. > > There was, anyway, a bug in my original patch in that it didn't provide > stubs for cases were USB_GADGET=n. That bug is now fixed, I'll still > wait a couple days for any 0-day build problems. > > >> Also, did you test the version I've apended to previous email? I noticed > >> that had one extra mistake which I correct in the version below: > >> > > > > Sorry, I did not try since I still have some questions for solution:) > > heh. You're not even willing to try a patch, rather than complaining > about pointless stuff all day. Thanks > The reason why I did not try your patch is: I don't think the PHY needs to depend on GADGET since your 1st patch like below: + depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV + depends on NOP_USB_XCEIV But look at your the newest patch, you have fixed it like below: + depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, NOP can't be built-in I agree with that since PHY can not depend on GADGET if it does not use gadget APIs. After trying your patch, you only fixed NOP PHY build issue (chipidea build issue is fixed too), but without for other code. You may need to fix all like my last grep: b29397@shlinux2:~/work/projects/usb$ find . -name *.c | xargs grep -rn "usb_gadget_vbus_connect" ./drivers/phy/phy-twl4030-usb.c:559: * REVISIT usb_gadget_vbus_connect(...) as needed, ditto ./drivers/usb/phy/phy-gpio-vbus-usb.c:126: usb_gadget_vbus_connect(gpio_vbus->phy.otg->gadget); ./drivers/usb/phy/phy-tahvo.c:89: usb_gadget_vbus_connect(tu->phy.otg->gadget); ./drivers/usb/phy/phy-isp1301-omap.c:929: usb_gadget_vbus_connect(isp->phy.otg->gadget); ./drivers/usb/phy/phy-isp1301-omap.c:1466: usb_gadget_vbus_connect(otg->gadget); ./drivers/usb/phy/phy-generic.c:122: usb_gadget_vbus_connect(otg->gadget); ./drivers/usb/phy/phy-generic.c:190:usb_gadget_vbus_connect(gadget); ./drivers/usb/phy/phy-msm-usb.c:783: usb_gadget_vbus_connect(phy->otg->gadget); ./drivers/usb/phy/phy-mv-usb.c:234: usb_gadget_vbus_connect(otg->gadget); ./drivers/usb/chipidea/otg.c:133: usb_gadget_vbus_connect(&ci->gadget); ./drivers/usb/chipidea/otg.c:138: usb_gadget_vbus_connect(&ci->gadget); ./drivers/usb/chipidea/udc.c:1964: usb_gadget_vbus_connect(&ci->gadget); ./drivers/usb/chipidea/otg_fsm.c:567: usb_gadget_vbus_connect(&ci->gadget); b29397@shlinux2:~/work/projects/usb$ find . -name *.c | xargs grep -rn "usb_gadget_vbus_disconnect" ./drivers/usb/phy/phy-gpio-vbus-usb.c:145: usb_gadget_vbus_disconnect(gpio_vbus->phy.otg->gadget); ./drivers/usb/phy/phy-gpio-vbus-usb.c:200: usb_gadget_vbus_disconnect(otg->gadget); ./drivers/usb/phy/phy-tahvo.c:108: usb_gadget_vbus_disconnect(tu->phy.otg->gadget); ./drivers/usb/phy/phy-tahvo.c:165: usb_gadget_vbus_disconnect(tu->phy.otg->gadget); ./drivers/usb/phy/phy-tahvo.c:175: usb_gadget_vbus_disconnect(tu->phy.otg->gadget); ./drivers/usb/phy/phy-isp1301-omap.c:312: return usb_gadget_vbus_disconnect(isp->phy.otg->gadget); ./drivers/usb/phy/phy-isp1301-omap.c:989: usb_gadget_vbus_disconnect(otg->gadget); ./drivers/usb/phy/phy-isp1301-omap.c:1342: usb_gadget_vbus_disconnect(otg->gadget); ./drivers/usb/phy/phy-generic.c:133: usb_gadget_vbus_disconnect(otg->gadget); ./drivers/usb/phy/phy-fsl-usb.c:622: usb_gadget_vbus_disconnect(otg->gadget); ./drivers/usb/phy/phy-msm-usb.c:786: usb_gadget_vbus_disconnect(phy->otg->gadget); ./drivers/usb/phy/phy
Re: [PATCH v9 08/14] usb: otg: add OTG/dual-role core
On Wed, Jun 08, 2016 at 01:12:10PM +0300, Roger Quadros wrote:
> Hi,
>
> On 08/06/16 12:53, Peter Chen wrote:
> > On Wed, Jun 08, 2016 at 12:03:40PM +0300, Roger Quadros wrote:
> >> +int usb_otg_unregister(struct device *dev)
> >> +{
> >> + struct usb_otg *otg;
> >> +
> >> + mutex_lock(&otg_list_mutex);
> >> + otg = usb_otg_get_data(dev);
> >> + if (!otg) {
> >> + dev_err(dev, "otg: %s: device not in otg list\n",
> >> + __func__);
> >> + mutex_unlock(&otg_list_mutex);
> >> + return -EINVAL;
> >> + }
> >> +
> >> + /* prevent unregister till both host & gadget have unregistered */
> >> + if (otg->host || otg->gadget) {
> >> + dev_err(dev, "otg: %s: host/gadget still registered\n",
> >> + __func__);
> >
> > You need to call mutex_unlock here
>
> Indeed. good catch.
> >
> >> +
> >> +int usb_otg_gadget_ready(struct usb_gadget *gadget, bool ready)
> >> +{
> >
> > What this API is for? Why need it in this version?
>
> we moved gadget to otg registration from udc_bind_to_driver() to
> usb_add_gadget_udc_release().
> This means there is a window when gadget function driver (e.g. g_zero) is not
> loaded.
> We don't want to start the gadget controller in that window.
>
> usb_otg_gadget_ready() is used by gadget core to notify the otg core when the
> function driver
> is ready or not-ready.
>
Why you need to move this from gadget's probe to udc's probe? Currently,
the sequence of gadget and udc's probe is random, but udc_bind_to_driver
is called when udc is ready.
--
Best Regards,
Peter Chen
--
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 v3] usb: phy: mxs: Add DT bindings to configure TX settings
On Thu, Jun 9, 2016 at 5:27 AM, Jaret Cantu wrote:
> On 03/23/2016 10:21 PM, Peter Chen wrote:
>>
>> On Wed, Mar 23, 2016 at 02:17:27PM -0400, Jaret Cantu wrote:
>>>
>>> On 03/23/2016 01:37 PM, Jaret Cantu wrote:
>>>>
>>>> On 03/23/2016 12:36 AM, Peter Chen wrote:
>>>>>
>>>>> On Mon, Mar 21, 2016 at 12:32:27PM -0400, Jaret Cantu wrote:
>>>>>>
>>>>>> The TX settings can be calibrated for particular hardware. The
>>>>>> phy is reset by Linux, so this cannot be handled by the bootloader.
>>>>>>
>>>>>> The TRM mentions that the maximum resistance should be used for the
>>>>>> DN/DP calibration in order to pass USB certification.
>>>>>>
>>>>>> The values for the TX registers are poorly described in the TRM.
>>>>>> The meanings of the register values were taken from another
>>>>>> Freescale-provided document:
>>>>>> https://community.freescale.com/message/566147#comment-566912
>>>>>>
>>>>>> Signed-off-by: Jaret Cantu
>>>>>> ---
>>>>>> v3. Added unit suffix (-ohms) to tx-cal-45-d*
>>>>>>
>>>>>> v2. Copying devicetree list
>>>>>> Removed prettifying extra whitespace
>>>>>> Removed unnecessary register rewrite on resume
>>>>>> Use min and max constants for clarity
>>>>>>
>>>>>> .../devicetree/bindings/phy/mxs-usb-phy.txt| 10
>>>>>> drivers/usb/phy/phy-mxs-usb.c | 58
>>>>>>
>>>>>> 2 files changed, 68 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
>>>>>> b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
>>>>>> index 379b84a..1d25b04 100644
>>>>>> --- a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
>>>>>> +++ b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
>>>>>> @@ -12,6 +12,16 @@ Required properties:
>>>>>> - interrupts: Should contain phy interrupt
>>>>>> - fsl,anatop: phandle for anatop register, it is only for imx6 SoC
>>>>>> series
>>>>>>
>>>>>> +
>>>>>> +if (!of_property_read_u32(np, "fsl,tx-d-cal", &val) &&
>>>>>> +val >= MXS_PHY_TX_D_CAL_MIN && val <= MXS_PHY_TX_D_CAL_MAX) {
>>>>>> +/* scale to 4-bit value */
>>>>>> +val = (MXS_PHY_TX_D_CAL_MAX - val) * 0xF
>>>>>> +/ (MXS_PHY_TX_D_CAL_MAX - MXS_PHY_TX_D_CAL_MIN);
>>>>>> +mxs_phy->tx_reg_mask |= GM_USBPHY_TX_D_CAL(~0);
>>>>>> +mxs_phy->tx_reg_set |= GM_USBPHY_TX_D_CAL(val);
>>>>>> +}
>>>>>> +
>>>>>
>>>>>
>>>>> I have tested "tx-d-cal", but it seems incorrect according to the xls
>>>>> you
>>>>> have provided, would you please check it again or am I wrong?
>>>>
>>>>
>>>> Gah! You're right. Some of the D_CAL values need to be rounded up to
>>>> match the xls. And even then, the value for 86 still doesn't play nice.
>>>> I was really hoping to avoid using a table for these values.
>>>>
>>>> The TXCALDP/DN values use a much simpler 1-to-1 scale across the 16
>>>> possible register values and so are unaffected by a similar issue. I
>>>> rechecked their numbers just to be sure.
>>>
>>>
>>> The solution looks to be to scale D_CAL starting from 80 instead of
>>> 79. If you look at the xls listing, the jump from 79 to 83 is the
>>> only time two adjacent register values result in a change greater
>>> than 2% or 3%.
>>>
>>> This will result in some code ugliness as the minimum allowed
>>> percentage (79), per the Freescale document, and the point at which
>>> we are scaling the percentage values to register values (80) are
>>> different.
>>>
>>> And, as mentioned before, the values will also have to be rounded up.
>>>
>>> This quick shell code confirms that these sorts of calculations
>>> match up with the values in the spreadsheet:
>>>
>>> for d in 1
Re: [PATCH v9 00/14] USB OTG/dual-role framework
On Wed, Jun 8, 2016 at 5:03 PM, 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 TI platform related patches will be sent separately.
>
> Series is based on v4.7-rc1.
>
Roger, I will wait your dwc3 and TI patch set since one framework needs
one user at least, thanks.
Peter
> 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 the OTG controller
> operations (fsm_ops) as necessary.
> void usb_otg_sync_inputs(struct usb_otg *otg);
>
> - The following 2 functions are provided as helpers for use by the
> OTG controller driver to start/stop the host/gadget controllers.
> int usb_otg_start_host(struct usb_otg *otg, int on);
> int usb_otg_start_gadget(struct usb_otg *otg, int on);
>
> - The following function is provided for use by the USB host stack
> to sync OTG related events to the OTG state machine.
> e.g. change in host_bus->b_hnp_enable, gadget->b_hnp_enable
> int usb_otg_kick_fsm(struct device *otg_device);
>
> - The following function is provided for use by the U
Re: [balbi-usb:testing/next 64/67] otg.c:undefined reference to `usb_gadget_vbus_disconnect'
On Wed, Jun 08, 2016 at 12:59:51PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> kbuild test robot writes:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> > testing/next
> > head: fc4d1f3f522648d92d0c046beedbc1469979499a
> > commit: 74e51eb7b5b4f7ab33c099c20def3dce0c699006 [64/67] usb: gadget: move
> > gadget API functions to udc-core
> > config: i386-randconfig-h1-06081244 (attached as .config)
> > compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> > reproduce:
> > git checkout 74e51eb7b5b4f7ab33c099c20def3dce0c699006
> > # save the attached .config to linux build tree
> > make ARCH=i386
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/built-in.o: In function `nop_set_peripheral':
> >phy-generic.c:(.text+0x59f7a6): undefined reference to
> > `usb_gadget_vbus_connect'
> >drivers/built-in.o: In function `nop_gpio_vbus_thread':
> >phy-generic.c:(.text+0x59f8a1): undefined reference to
> > `usb_gadget_vbus_connect'
> >phy-generic.c:(.text+0x59f925): undefined reference to
> > `usb_gadget_vbus_disconnect'
> >drivers/built-in.o: In function `gpio_vbus_set_peripheral':
> >phy-gpio-vbus-usb.c:(.text+0x59ff45): undefined reference to
> > `usb_gadget_vbus_disconnect'
> >drivers/built-in.o: In function `gpio_vbus_work':
> >phy-gpio-vbus-usb.c:(.text+0x5a02dd): undefined reference to
> > `usb_gadget_vbus_disconnect'
> >phy-gpio-vbus-usb.c:(.text+0x5a0333): undefined reference to
> > `usb_gadget_vbus_connect'
> >drivers/built-in.o: In function `ci_handle_vbus_change.part.6':
> >>> otg.c:(.text+0x605e3b): undefined reference to
> >>> `usb_gadget_vbus_disconnect'
> >>> otg.c:(.text+0x605e49): undefined reference to `usb_gadget_vbus_connect'
> >drivers/built-in.o: In function `isp1704_charger_work':
> >isp1704_charger.c:(.text+0x648335): undefined reference to
> > `usb_gadget_disconnect'
> >isp1704_charger.c:(.text+0x64839d): undefined reference to
> > `usb_gadget_connect'
> >drivers/built-in.o: In function `isp1704_charger_probe':
> >isp1704_charger.c:(.text+0x648760): undefined reference to
> > `usb_gadget_disconnect'
>
> thanks, fixed:
>
Hi Felipe,
Your patch does not fix above issue, I have tried. At least, I can
reproduce phy-gpio-vbus-usb build error if it is build in, and
USB_GADGET is module.
Peter
> From a22b539c7082b6a3046b3a9cebb356a047a2d81d Mon Sep 17 00:00:00 2001
> From: Felipe Balbi
> Date: Tue, 31 May 2016 13:07:47 +0300
> Subject: [PATCH] usb: gadget: move gadget API functions to udc-core
>
> instead of defining all functions as static inlines,
> let's move them to udc-core and export them with
> EXPORT_SYMBOL_GPL, that way we can make sure that
> only GPL drivers will use them.
>
> As a side effect, it'll be nicer to add tracepoints
> to the gadget API.
>
> While at that, also fix Kconfig dependencies to
> avoid randconfig build failures.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/udc-core.c | 573 +
> drivers/usb/host/Kconfig | 2 +-
> drivers/usb/phy/Kconfig | 5 +-
> include/linux/usb/gadget.h| 585
> --
> 4 files changed, 637 insertions(+), 528 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/udc-core.c
> b/drivers/usb/gadget/udc/udc-core.c
> index 6e8300d6a737..d2f28bb6dbda 100644
> --- a/drivers/usb/gadget/udc/udc-core.c
> +++ b/drivers/usb/gadget/udc/udc-core.c
> @@ -59,6 +59,579 @@ static int udc_bind_to_driver(struct usb_udc *udc,
>
> /* -
> */
>
> +/**
> + * usb_ep_set_maxpacket_limit - set maximum packet size limit for endpoint
> + * @ep:the endpoint being configured
> + * @maxpacket_limit:value of maximum packet size limit
> + *
> + * This function should be used only in UDC drivers to initialize endpoint
> + * (usually in probe function).
> + */
> +void usb_ep_set_maxpacket_limit(struct usb_ep *ep,
> + unsigned maxpacket_limit)
> +{
> + ep->maxpacket_limit = maxpacket_limit;
> + ep->maxpacket = maxpacket_limit;
> +}
> +EXPORT_SYMBOL_GPL(usb_ep_set_maxpacket_limit);
> +
> +/**
> + * usb_ep_enable - configure endpoint, making it usable
> + * @ep:the endpoint being configured. may not be the endpoint named "ep0".
> + * drivers discover endpoints through the ep_list of a usb_gadget.
> + *
> + * When configurations are set, or when interface settings change, the driver
> + * will enable or disable the relevant endpoints. while it is enabled, an
> + * endpoint may be used for i/o until the driver receives a disconnect() from
> + * the host or until the endpoint is disabled.
> + *
> + * the ep0 implementation (which calls this routine) must ensure that the
> + * hardware capabilities of each endpoint match the descriptor provided
> + * for it. for example, an endpoint named "ep2in-bulk" woul
Re: [PATCH v3] usb: phy: mxs: Add DT bindings to configure TX settings
On Thu, Jun 09, 2016 at 02:07:52PM -0400, Justin Waters wrote:
> Peter,
>
> On Wed, Jun 8, 2016 at 10:41 PM, Peter Chen wrote:
> > On Thu, Jun 9, 2016 at 5:27 AM, Jaret Cantu wrote:
> >> On 03/23/2016 10:21 PM, Peter Chen wrote:
> >>>
> >>> On Wed, Mar 23, 2016 at 02:17:27PM -0400, Jaret Cantu wrote:
> >>>>
> >>>> On 03/23/2016 01:37 PM, Jaret Cantu wrote:
> >>>>>
> >>>>> On 03/23/2016 12:36 AM, Peter Chen wrote:
> >>>>>>
> >>>>>> On Mon, Mar 21, 2016 at 12:32:27PM -0400, Jaret Cantu wrote:
> >>>>>>>
> >>>>>>> The TX settings can be calibrated for particular hardware. The
> >>>>>>> phy is reset by Linux, so this cannot be handled by the bootloader.
> >>>>>>>
> >>>>>>> The TRM mentions that the maximum resistance should be used for the
> >>>>>>> DN/DP calibration in order to pass USB certification.
> >>>>>>>
> >>>>>>> The values for the TX registers are poorly described in the TRM.
> >>>>>>> The meanings of the register values were taken from another
> >>>>>>> Freescale-provided document:
> >>>>>>> https://community.freescale.com/message/566147#comment-566912
> >>>>>>>
> >>>>>>> Signed-off-by: Jaret Cantu
> >>>>>>> ---
> >>>>>>> v3. Added unit suffix (-ohms) to tx-cal-45-d*
> >>>>>>>
> >>>>>>> v2. Copying devicetree list
> >>>>>>> Removed prettifying extra whitespace
> >>>>>>> Removed unnecessary register rewrite on resume
> >>>>>>> Use min and max constants for clarity
> >>>>>>>
> >>>>>>> .../devicetree/bindings/phy/mxs-usb-phy.txt| 10
> >>>>>>> drivers/usb/phy/phy-mxs-usb.c | 58
> >>>>>>>
> >>>>>>> 2 files changed, 68 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
> >>>>>>> b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
> >>>>>>> index 379b84a..1d25b04 100644
> >>>>>>> --- a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
> >>>>>>> +++ b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
> >>>>>>> @@ -12,6 +12,16 @@ Required properties:
> >>>>>>> - interrupts: Should contain phy interrupt
> >>>>>>> - fsl,anatop: phandle for anatop register, it is only for imx6 SoC
> >>>>>>> series
> >>>>>>>
> >>>>>>> +
> >>>>>>> +if (!of_property_read_u32(np, "fsl,tx-d-cal", &val) &&
> >>>>>>> +val >= MXS_PHY_TX_D_CAL_MIN && val <= MXS_PHY_TX_D_CAL_MAX) {
> >>>>>>> +/* scale to 4-bit value */
> >>>>>>> +val = (MXS_PHY_TX_D_CAL_MAX - val) * 0xF
> >>>>>>> +/ (MXS_PHY_TX_D_CAL_MAX - MXS_PHY_TX_D_CAL_MIN);
> >>>>>>> +mxs_phy->tx_reg_mask |= GM_USBPHY_TX_D_CAL(~0);
> >>>>>>> +mxs_phy->tx_reg_set |= GM_USBPHY_TX_D_CAL(val);
> >>>>>>> +}
> >>>>>>> +
> >>>>>>
> >>>>>>
> >>>>>> I have tested "tx-d-cal", but it seems incorrect according to the xls
> >>>>>> you
> >>>>>> have provided, would you please check it again or am I wrong?
> >>>>>
> >>>>>
> >>>>> Gah! You're right. Some of the D_CAL values need to be rounded up to
> >>>>> match the xls. And even then, the value for 86 still doesn't play nice.
> >>>>> I was really hoping to avoid using a table for these values.
> >>>>>
> >>>>> The TXCALDP/DN values use a much simpler 1-to-1 scale across the 16
> >>>>> possible register values and so are unaffected by a similar issue. I
> >>>>> rechecked their numbers just to be sure.
> >>>>
> >>>>
> >>>> The solution
Re: [PATCH v9 08/14] usb: otg: add OTG/dual-role core
On Thu, Jun 09, 2016 at 10:24:44AM +0300, Roger Quadros wrote:
> On 08/06/16 15:42, Peter Chen wrote:
> > On Wed, Jun 08, 2016 at 01:12:10PM +0300, Roger Quadros wrote:
> >> Hi,
> >>
> >> On 08/06/16 12:53, Peter Chen wrote:
> >>> On Wed, Jun 08, 2016 at 12:03:40PM +0300, Roger Quadros wrote:
> >>>> +int usb_otg_unregister(struct device *dev)
> >>>> +{
> >>>> +struct usb_otg *otg;
> >>>> +
> >>>> +mutex_lock(&otg_list_mutex);
> >>>> +otg = usb_otg_get_data(dev);
> >>>> +if (!otg) {
> >>>> +dev_err(dev, "otg: %s: device not in otg list\n",
> >>>> +__func__);
> >>>> +mutex_unlock(&otg_list_mutex);
> >>>> +return -EINVAL;
> >>>> +}
> >>>> +
> >>>> +/* prevent unregister till both host & gadget have unregistered
> >>>> */
> >>>> +if (otg->host || otg->gadget) {
> >>>> +dev_err(dev, "otg: %s: host/gadget still registered\n",
> >>>> +__func__);
> >>>
> >>> You need to call mutex_unlock here
> >>
> >> Indeed. good catch.
> >>>
> >>>> +
> >>>> +int usb_otg_gadget_ready(struct usb_gadget *gadget, bool ready)
> >>>> +{
> >>>
> >>> What this API is for? Why need it in this version?
> >>
> >> we moved gadget to otg registration from udc_bind_to_driver() to
> >> usb_add_gadget_udc_release().
> >> This means there is a window when gadget function driver (e.g. g_zero) is
> >> not loaded.
> >> We don't want to start the gadget controller in that window.
> >>
> >> usb_otg_gadget_ready() is used by gadget core to notify the otg core when
> >> the function driver
> >> is ready or not-ready.
> >>
> >
> > Why you need to move this from gadget's probe to udc's probe? Currently,
> > the sequence of gadget and udc's probe is random, but udc_bind_to_driver
> > is called when udc is ready.
> >
> Because we need to support -EPROBE_DEFER at udc probe.
> At udc_bind_to_driver there is no scope for -EPROBE_DEFER.
>
Why udc_bind_to_driver can't return -EPROBE_DEFER if register to OTG is
failed?
> Another issue is that we need to register with otg and have otg->caps
> available
> before driver->bind() is called in udc_bind_to_driver(). Else gadget function
> will not have the correct OTG descriptor.
>
You can do register before calling driver->bind.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v4 01/14] regulator: of: Add helper for getting all supplies
On Fri, Jun 10, 2016 at 12:30:56PM -0500, Rob Herring wrote:
> On Thu, Jun 09, 2016 at 01:42:02PM +0200, Krzysztof Kozlowski wrote:
> > On 06/09/2016 12:29 PM, Mark Brown wrote:
> > > On Thu, Jun 09, 2016 at 11:44:18AM +0200, Krzysztof Kozlowski wrote:
> > >> Few drivers have a need of getting regulator supplies without knowing
> > >> their names:
> > >> 1. The Simple Framebuffer driver works on setup provided by bootloader
> > >>(outside of scope of kernel);
> > >> 2. Generic power sequence driver may be attached to any device node.
> > >>
> > >> Add a Device Tree helper for parsing "-supply" properties and returning
> > >> allocated bulk regulator consumers.
> > >
> > > I'm still very concerned that this is just an invitation to people to
> > > write half baked regulator consumers and half baked DTs to go along with
> > > it, making it a standard API that doesn't have big red flags on it that
> > > will flag up when "normal" drivers use it is not good. Right now this
> > > just looks like a standard API and people are going to just start using
> > > it. If we are going to do this perhaps we need a separate header or
> > > something to help flag this up.
> >
> > No problem, I can move it to a special header. Actually, if you dislike
> > this as an API, it does not have to be in header at all. I can just
> > duplicate the simplefb code.
> >
> > > In the case of power sequences I'd expect the sequences to perform
> > > operations on named supplies - the core shouldn't know what the supplies
> > > are but the thing specifying the sequence should.
> >
> > Hm, so maybe passing names like:
> >
> > usb3503@08 {
> > reset-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
> > initial-mode = <1>;
> > vdd-supply = <&buck8_reg>;
> > foo-supply = <&buck9_reg>;
> >
> > power-sequence;
> > power-sequence-supplies = "vdd", "foo";
>
> This alone would be fine as it is just one property, but then what's
> next? power-sequence-delay, power-sequence-clocks, etc. What if you
> need to express ordering relationship of supplies, clocks, gpios? We end
> up with a scripting language in DT and we don't want to have that.
>
Can we do things like below:
- DT describes hardware elements (clock, gpios, etc) for power sequence, and we
need a node for power sequence.
- Power sequence framework handles getting hardware elements.
- Power sequence platform driver handles special sequence for devices,
and we can create some generic drivers for generic devices.
--
Best Regards,
Peter Chen
--
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 2/4] usb: dwc3: add dual-role support
dwc3_runtime_idle(struct device *dev)
> #endif /* CONFIG_PM */
>
> #ifdef CONFIG_PM_SLEEP
> +static int dwc3_prepare(struct device *dev)
> +{
> + struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dwc->lock, flags);
> + dwc->otg_prevent_sync = true;
> + spin_unlock_irqrestore(&dwc->lock, flags);
> +
> + return 0;
> +}
> +
> +static void dwc3_complete(struct device *dev)
> +{
> + struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dwc->lock, flags);
> + dwc->otg_prevent_sync = false;
> + spin_unlock_irqrestore(&dwc->lock, flags);
> + if (dwc->dr_mode == USB_DR_MODE_OTG)
> + dwc3_otg_fsm_sync(dwc);
> +}
> +
> static int dwc3_suspend(struct device *dev)
> {
> struct dwc3 *dwc = dev_get_drvdata(dev);
> @@ -1256,6 +1784,8 @@ static const struct dev_pm_ops dwc3_dev_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
> SET_RUNTIME_PM_OPS(dwc3_runtime_suspend, dwc3_runtime_resume,
> dwc3_runtime_idle)
> + .prepare = dwc3_prepare,
> + .complete = dwc3_complete,
> };
>
> #ifdef CONFIG_OF
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 32bb7531..e6b771a 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -817,13 +818,21 @@ struct dwc3_scratchpad_array {
> * @gadget_driver: pointer to the gadget driver
> * @regs: base address for our registers
> * @regs_size: address space size
> + * @dr_mode: requested mode of operation
> + * @otg: usb otg data structure
> + * @otg_caps: otg controller capabilities
> + * @otg_config: otg controller configuration
> + * @otg_prevent_sync: flag to block events to otg fsm
> + * @otg_protocol: saved copy of otg state during suspend
> + * @current_mode: current mode of operation written to PRTCAPDIR
> + * @oevt: cached OEVT register during OTG irq
> * @fladj: frame length adjustment
> * @irq_gadget: peripheral controller's IRQ number
> + * @otg_irq: IRQ number for OTG IRQs
> * @nr_scratch: number of scratch buffers
> * @u1u2: only used on revisions <1.83a for workaround
> * @maximum_speed: maximum speed requested (mainly for testing purposes)
> * @revision: revision register contents
> - * @dr_mode: requested mode of operation
> * @usb2_phy: pointer to USB2 PHY
> * @usb3_phy: pointer to USB3 PHY
> * @usb2_generic_phy: pointer to USB2 PHY
> @@ -831,6 +840,9 @@ struct dwc3_scratchpad_array {
> * @ulpi: pointer to ulpi interface
> * @dcfg: saved contents of DCFG register
> * @gctl: saved contents of GCTL register
> + * @ocfg: saved contents of OCFG register
> + * @octl: saved contents of OCTL register
> + * @oevten: saved contents of OEVTEN register
> * @isoch_delay: wValue from Set Isochronous Delay request;
> * @u2sel: parameter from Set SEL request.
> * @u2pel: parameter from Set SEL request.
> @@ -929,9 +941,25 @@ struct dwc3 {
> size_t regs_size;
>
> enum usb_dr_modedr_mode;
> + struct usb_otg *otg;
> + struct usb_otg_caps otg_caps;
> + struct usb_otg_config otg_config;
> + boolotg_prevent_sync;
> + int otg_protocol;
> + u32 current_mode;
> + u32 oevt;
>
> u32 fladj;
> u32 irq_gadget;
> + int otg_irq;
> +
> + /* used for suspend/resume */
> + u32 dcfg;
> + u32 gctl;
> + u32 ocfg;
> + u32 octl;
> + u32 oevten;
> +
> u32 nr_scratch;
> u32 u1u2;
> u32 maximum_speed;
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 1ade5e8..e409b1e 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -2974,7 +2974,11 @@ int dwc3_gadget_init(struct dwc3 *dwc)
> if (ret)
> goto err5;
>
> - ret = usb_add_gadget_udc(dwc->dev, &dwc->gadget);
> + if (dwc->dr_mode == USB_DR_MODE_OTG)
> + ret = usb_otg_add_gadget_udc(dwc->dev, &dwc->gadget, dwc->dev);
> + else
> + ret = usb_add_gadget_udc(dwc->dev, &dwc->gadget);
> +
> if (ret) {
> dev_err(dwc->dev, "failed to register udc\n");
> goto err5;
> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index 2e960ed..32096ec 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -91,6 +91,8 @@ int dwc3_host_init(struct dwc3 *dwc)
> memset(&pdata, 0, sizeof(pdata));
>
> pdata.usb3_lpm_capable = dwc->usb3_lpm_capable;
> + if (dwc->dr_mode == USB_DR_MODE_OTG)
> + pdata.otg_dev = dwc->dev;
>
> ret = platform_device_add_data(xhci, &pdata, sizeof(pdata));
> if (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
--
Best Regards,
Peter Chen
--
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 06/14] usb: gadget.h: Add OTG to gadget interface
On Fri, Jun 10, 2016 at 04:07:15PM +0300, Roger Quadros wrote:
> 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
Acked-by: Peter Chen
> ---
> 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 2dd9e6b..f4fc0aa 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -639,6 +639,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
--
Best Regards,
Peter Chen
--
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 v9 08/14] usb: otg: add OTG/dual-role core
On Sun, Jun 12, 2016 at 02:26:17PM +0800, Peter Chen wrote:
> On Thu, Jun 09, 2016 at 10:24:44AM +0300, Roger Quadros wrote:
> > On 08/06/16 15:42, Peter Chen wrote:
> > > On Wed, Jun 08, 2016 at 01:12:10PM +0300, Roger Quadros wrote:
> > >> Hi,
> > >>
> > >> On 08/06/16 12:53, Peter Chen wrote:
> > >>> On Wed, Jun 08, 2016 at 12:03:40PM +0300, Roger Quadros wrote:
> > >>>> +int usb_otg_unregister(struct device *dev)
> > >>>> +{
> > >>>> + struct usb_otg *otg;
> > >>>> +
> > >>>> + mutex_lock(&otg_list_mutex);
> > >>>> + otg = usb_otg_get_data(dev);
> > >>>> + if (!otg) {
> > >>>> + dev_err(dev, "otg: %s: device not in otg list\n",
> > >>>> + __func__);
> > >>>> + mutex_unlock(&otg_list_mutex);
> > >>>> + return -EINVAL;
> > >>>> + }
> > >>>> +
> > >>>> + /* prevent unregister till both host & gadget have unregistered
> > >>>> */
> > >>>> + if (otg->host || otg->gadget) {
> > >>>> + dev_err(dev, "otg: %s: host/gadget still registered\n",
> > >>>> + __func__);
> > >>>
> > >>> You need to call mutex_unlock here
> > >>
> > >> Indeed. good catch.
> > >>>
> > >>>> +
> > >>>> +int usb_otg_gadget_ready(struct usb_gadget *gadget, bool ready)
> > >>>> +{
> > >>>
> > >>> What this API is for? Why need it in this version?
> > >>
> > >> we moved gadget to otg registration from udc_bind_to_driver() to
> > >> usb_add_gadget_udc_release().
> > >> This means there is a window when gadget function driver (e.g. g_zero)
> > >> is not loaded.
> > >> We don't want to start the gadget controller in that window.
> > >>
> > >> usb_otg_gadget_ready() is used by gadget core to notify the otg core
> > >> when the function driver
> > >> is ready or not-ready.
> > >>
> > >
> > > Why you need to move this from gadget's probe to udc's probe? Currently,
> > > the sequence of gadget and udc's probe is random, but udc_bind_to_driver
> > > is called when udc is ready.
> > >
> > Because we need to support -EPROBE_DEFER at udc probe.
> > At udc_bind_to_driver there is no scope for -EPROBE_DEFER.
> >
>
> Why udc_bind_to_driver can't return -EPROBE_DEFER if register to OTG is
> failed?
>
> > Another issue is that we need to register with otg and have otg->caps
> > available
> > before driver->bind() is called in udc_bind_to_driver(). Else gadget
> > function
> > will not have the correct OTG descriptor.
> >
>
> You can do register before calling driver->bind.
>
Please skip my comments, I understand your changes now.
--
Best Regards,
Peter Chen
--
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 08/14] usb: otg: add OTG/dual-role core
On Fri, Jun 10, 2016 at 04:07:17PM +0300, Roger Quadros wrote:
> index dca7856..03f7204 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_CORE) += common/
I don't think you need to make above change, why you do it?
> +
> +/**
> + * usb_otg_get_data() - get usb_otg data structa
%s/structa/structure
> +
> +/**
> + * usb_otg_kick_fsm() - Kick the OTG state machine
> + * @otg_dev: OTG controller device
> + *
> + * Used by USB host/gadget stack to sync OTG related
> + * events to the OTG state machine.
> + * e.g. change in host_bus->b_hnp_enable, gadget->b_hnp_enable
> + *
> + * Return: 0 on success, error value otherwise.
> + */
> +int usb_otg_kick_fsm(struct device *otg_dev)
> +{
> + struct usb_otg *otg;
> +
> + mutex_lock(&otg_list_mutex);
> + otg = usb_otg_get_data(otg_dev);
> + mutex_unlock(&otg_list_mutex);
> + if (!otg) {
> + dev_dbg(otg_dev, "otg: %s: invalid otg device\n",
> + __func__);
> + return -ENODEV;
> + }
> +
> + usb_otg_sync_inputs(otg);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(usb_otg_kick_fsm);
Do you have any users for this API? If no, please delete it in this
version.
> +
> +/**
> + * usb_otg_register_hcd() - Register the host controller to OTG core
> + * @hcd: host controller
> + * @irqnum: interrupt number
> + * @irqflags:interrupt flags
> + * @ops: HCD ops to interface with the HCD
> + *
> + * This is used by the USB Host stack to register the host controller
> + * to the OTG core. Host controller must not be started by the
> + * caller as it is left upto the OTG state machine to do so.
%s/upto/up to
> +
> +/**
> + * usb_otg_register_gadget() - Register the gadget controller to OTG core
> + * @gadget: gadget controller instance
> + * @ops: gadget interface ops
> + *
> + * This is used by the USB gadget stack to register the gadget controller
> + * to the OTG core. Gadget controller must not be started by the
> + * caller as it is left upto the OTG state machine to do so.
> + *
%s/upto/up to
--
Best Regards,
Peter Chen
--
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 13/14] usb: gadget: udc: adapt to OTG core
On Fri, Jun 10, 2016 at 04:07:22PM +0300, Roger Quadros wrote:
>
> +/**
> + * usb_otg_add_gadget_udc - adds a new gadget to the udc class driver list
> + * @parent: the parent device to this udc. Usually the controller
> + * driver's device.
It seems it should be udc device
> +/* udc_lock must be held */
> static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver
> *driver)
> {
> int ret;
> @@ -1282,17 +1449,26 @@ 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/dual-role, the otg core manages UDC start/stop */
> + if (udc->gadget->otg_dev) {
> + mutex_unlock(&udc_lock);
> + usb_otg_gadget_ready(udc->gadget, true);
> + mutex_lock(&udc_lock);
> + } else {
> + ret = usb_gadget_udc_start(udc);
> + if (ret) {
> + mutex_unlock(&udc_lock);
> + 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;
> err1:
> - if (ret != -EISNAM)
> + if ((ret != -EISNAM) && (ret != -EPROBE_DEFER))
It seems it will not introduce -EPROBE_DEFER with your changes
in udc_bind_to_driver
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v4 01/14] regulator: of: Add helper for getting all supplies
On Sun, Jun 12, 2016 at 03:29:01PM +0800, Peter Chen wrote:
> On Fri, Jun 10, 2016 at 12:30:56PM -0500, Rob Herring wrote:
> > On Thu, Jun 09, 2016 at 01:42:02PM +0200, Krzysztof Kozlowski wrote:
> > > On 06/09/2016 12:29 PM, Mark Brown wrote:
> > > > On Thu, Jun 09, 2016 at 11:44:18AM +0200, Krzysztof Kozlowski wrote:
> > > >> Few drivers have a need of getting regulator supplies without knowing
> > > >> their names:
> > > >> 1. The Simple Framebuffer driver works on setup provided by bootloader
> > > >>(outside of scope of kernel);
> > > >> 2. Generic power sequence driver may be attached to any device node.
> > > >>
> > > >> Add a Device Tree helper for parsing "-supply" properties and returning
> > > >> allocated bulk regulator consumers.
> > > >
> > > > I'm still very concerned that this is just an invitation to people to
> > > > write half baked regulator consumers and half baked DTs to go along with
> > > > it, making it a standard API that doesn't have big red flags on it that
> > > > will flag up when "normal" drivers use it is not good. Right now this
> > > > just looks like a standard API and people are going to just start using
> > > > it. If we are going to do this perhaps we need a separate header or
> > > > something to help flag this up.
> > >
> > > No problem, I can move it to a special header. Actually, if you dislike
> > > this as an API, it does not have to be in header at all. I can just
> > > duplicate the simplefb code.
> > >
> > > > In the case of power sequences I'd expect the sequences to perform
> > > > operations on named supplies - the core shouldn't know what the supplies
> > > > are but the thing specifying the sequence should.
> > >
> > > Hm, so maybe passing names like:
> > >
> > > usb3503@08 {
> > > reset-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
> > > initial-mode = <1>;
> > > vdd-supply = <&buck8_reg>;
> > > foo-supply = <&buck9_reg>;
> > >
> > > power-sequence;
> > > power-sequence-supplies = "vdd", "foo";
> >
> > This alone would be fine as it is just one property, but then what's
> > next? power-sequence-delay, power-sequence-clocks, etc. What if you
> > need to express ordering relationship of supplies, clocks, gpios? We end
> > up with a scripting language in DT and we don't want to have that.
> >
>
> Can we do things like below:
>
> - DT describes hardware elements (clock, gpios, etc) for power sequence, and
> we
> need a node for power sequence.
> - Power sequence framework handles getting hardware elements.
Framework may do few things, since hardware elements are also different
for devices.
> - Power sequence platform driver handles special sequence for devices,
> and we can create some generic drivers for generic devices.
>
So, my suggestion is do like mmc does (like this patch set does). The
reasons like belows:
- This piece of power sequence code needs to work like device driver, not
library, it is easy to manage resources using device driver.
- The device on the bus has still not been found, so this piece of code
can't be in device driver on each subsystem.
- We need to have a place for these power sequences drivers
Ideally, I hope it can work like regulator class, but it seems hard to
compatible with current mmc-pwrseq DT node.
--
Best Regards,
Peter Chen
--
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: [balbi-usb:testing/next 64/67] otg.c:undefined reference to `usb_gadget_vbus_disconnect'
On Mon, Jun 13, 2016 at 09:01:55AM +0300, Felipe Balbi wrote:
> Felipe Balbi writes:
>
> Here's an updated version:
>
> From d45bdfafc3143dc7acc9d71131807d3e30ab7bcd Mon Sep 17 00:00:00 2001
> From: Felipe Balbi
> Date: Tue, 31 May 2016 13:07:47 +0300
> Subject: [PATCH] usb: gadget: move gadget API functions to udc-core
>
> instead of defining all functions as static inlines,
> let's move them to udc-core and export them with
> EXPORT_SYMBOL_GPL, that way we can make sure that
> only GPL drivers will use them.
>
> As a side effect, it'll be nicer to add tracepoints
> to the gadget API.
>
> While at that, also fix Kconfig dependencies to
> avoid randconfig build failures.
>
> Signed-off-by: Felipe Balbi
Acked-by: Peter Chen
> ---
> drivers/phy/Kconfig | 1 +
> drivers/power/Kconfig | 1 +
> drivers/usb/gadget/udc/udc-core.c | 573 +
> drivers/usb/host/Kconfig | 2 +-
> drivers/usb/phy/Kconfig | 11 +-
> include/linux/usb/gadget.h| 585
> --
> 6 files changed, 645 insertions(+), 528 deletions(-)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index b869b98835f4..8d1cfb7f3ea2 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -176,6 +176,7 @@ config TWL4030_USB
> tristate "TWL4030 USB Transceiver Driver"
> depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS
> depends on USB_SUPPORT
> + depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't 'y'
> select GENERIC_PHY
> select USB_PHY
> help
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 421770ddafa3..0f11a0f4c369 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -309,6 +309,7 @@ config BATTERY_RX51
> config CHARGER_ISP1704
> tristate "ISP1704 USB Charger Detection"
> depends on USB_PHY
> + depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be
> 'y'
> help
> Say Y to enable support for USB Charger Detection with
> ISP1707/ISP1704 USB transceivers.
> diff --git a/drivers/usb/gadget/udc/udc-core.c
> b/drivers/usb/gadget/udc/udc-core.c
> index 6e8300d6a737..d2f28bb6dbda 100644
> --- a/drivers/usb/gadget/udc/udc-core.c
> +++ b/drivers/usb/gadget/udc/udc-core.c
> @@ -59,6 +59,579 @@ static int udc_bind_to_driver(struct usb_udc *udc,
>
> /* -
> */
>
> +/**
> + * usb_ep_set_maxpacket_limit - set maximum packet size limit for endpoint
> + * @ep:the endpoint being configured
> + * @maxpacket_limit:value of maximum packet size limit
> + *
> + * This function should be used only in UDC drivers to initialize endpoint
> + * (usually in probe function).
> + */
> +void usb_ep_set_maxpacket_limit(struct usb_ep *ep,
> + unsigned maxpacket_limit)
> +{
> + ep->maxpacket_limit = maxpacket_limit;
> + ep->maxpacket = maxpacket_limit;
> +}
> +EXPORT_SYMBOL_GPL(usb_ep_set_maxpacket_limit);
> +
> +/**
> + * usb_ep_enable - configure endpoint, making it usable
> + * @ep:the endpoint being configured. may not be the endpoint named "ep0".
> + * drivers discover endpoints through the ep_list of a usb_gadget.
> + *
> + * When configurations are set, or when interface settings change, the driver
> + * will enable or disable the relevant endpoints. while it is enabled, an
> + * endpoint may be used for i/o until the driver receives a disconnect() from
> + * the host or until the endpoint is disabled.
> + *
> + * the ep0 implementation (which calls this routine) must ensure that the
> + * hardware capabilities of each endpoint match the descriptor provided
> + * for it. for example, an endpoint named "ep2in-bulk" would be usable
> + * for interrupt transfers as well as bulk, but it likely couldn't be used
> + * for iso transfers or for endpoint 14. some endpoints are fully
> + * configurable, with more generic names like "ep-a". (remember that for
> + * USB, "in" means "towards the USB master".)
> + *
> + * returns zero, or a negative error code.
> + */
> +int usb_ep_enable(struct usb_ep *ep)
> +{
> + int ret;
> +
> + if (ep->enabled)
> + return 0;
> +
> + ret = ep->ops->enable(ep, ep->desc);
> + if (ret)
> + return ret;
> +
> + ep->enabled = true;
> +
> + return 0;
> +}
>
Re: [PATCH v10 13/14] usb: gadget: udc: adapt to OTG core
On Mon, Jun 13, 2016 at 10:14:31AM +0300, Roger Quadros wrote:
> On 12/06/16 14:36, Peter Chen wrote:
> > On Fri, Jun 10, 2016 at 04:07:22PM +0300, Roger Quadros wrote:
> >>
> >> +/**
> >> + * usb_otg_add_gadget_udc - adds a new gadget to the udc class driver list
> >> + * @parent: the parent device to this udc. Usually the controller
> >> + * driver's device.
> >
> > It seems it should be udc device
>
> Parent and udc->dev are not the same right?
Sure, udc's parent is otg device.
>
> I guess i'll omit the second statement to avoid confusion. So.
>
> @parent: the parent device to this udc.
Where you call below APIs? It seems to be a udc driver, right?
So, when you try to get "otg-controller" from the node, this node
should be udc.
/**
* usb_otg_add_gadget_udc - adds a new gadget to the udc class driver list
* @parent: the parent device to this udc. Usually the controller
* driver's device.
* @gadget: the gadget to be added to the list
* @otg_dev: the OTG controller device
*
* If otg_dev is NULL then device tree node is checked
* for OTG controller via the otg-controller property.
* Returns zero on success, negative errno otherwise.
*/
int usb_otg_add_gadget_udc(struct device *parent, struct usb_gadget *gadget,
struct device *otg_dev)
{
if (!otg_dev) {
gadget->otg_dev = of_usb_get_otg(parent->of_node);
if (!gadget->otg_dev)
return -ENODEV;
} else {
gadget->otg_dev = otg_dev;
}
return usb_add_gadget_udc_release(parent, gadget, NULL);
}
EXPORT_SYMBOL_GPL(usb_otg_add_gadget_udc);
--
Best Regards,
Peter Chen
--
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 13/14] usb: gadget: udc: adapt to OTG core
On Mon, Jun 13, 2016 at 10:37:59AM +0300, Roger Quadros wrote:
> On 13/06/16 10:20, Peter Chen wrote:
> > On Mon, Jun 13, 2016 at 10:14:31AM +0300, Roger Quadros wrote:
> >> On 12/06/16 14:36, Peter Chen wrote:
> >>> On Fri, Jun 10, 2016 at 04:07:22PM +0300, Roger Quadros wrote:
> >>>>
> >>>> +/**
> >>>> + * usb_otg_add_gadget_udc - adds a new gadget to the udc class driver
> >>>> list
> >>>> + * @parent: the parent device to this udc. Usually the controller
> >>>> + * driver's device.
> >>>
> >>> It seems it should be udc device
> >>
> >> Parent and udc->dev are not the same right?
> >
> > Sure, udc's parent is otg device.
> >
> >>
> >> I guess i'll omit the second statement to avoid confusion. So.
> >>
> >> @parent: the parent device to this udc.
> >
> > Where you call below APIs? It seems to be a udc driver, right?
> > So, when you try to get "otg-controller" from the node, this node
> > should be udc.
>
> @parent is actually the device that represents the USB Device controller
> in the device tree. When you call usb_add_gadget_udc_release() a new
> udc->dev device is created as it's child.
>
> See explanation for the @parent argument in usb_add_gadget_udc_release().
> As we want to keep the parent argument identical to that I will not make
> any changes then.
Oh, yes. The parent should be glue layer udc device or the dual-role controller
device.
Peter
>
> >
> > /**
> > * usb_otg_add_gadget_udc - adds a new gadget to the udc class driver list
> > * @parent: the parent device to this udc. Usually the controller
> > * driver's device.
> > * @gadget: the gadget to be added to the list
> > * @otg_dev: the OTG controller device
> > *
> > * If otg_dev is NULL then device tree node is checked
> > * for OTG controller via the otg-controller property.
> > * Returns zero on success, negative errno otherwise.
> > */
> > int usb_otg_add_gadget_udc(struct device *parent, struct usb_gadget *gadget,
> >struct device *otg_dev)
> > {
> > if (!otg_dev) {
> > gadget->otg_dev = of_usb_get_otg(parent->of_node);
> > if (!gadget->otg_dev)
> > return -ENODEV;
> > } else {
> > gadget->otg_dev = otg_dev;
> > }
> >
> > return usb_add_gadget_udc_release(parent, gadget, NULL);
> > }
> > EXPORT_SYMBOL_GPL(usb_otg_add_gadget_udc);
> >
>
> --
> cheers,
> -roger
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: common: otg-fsm: add license to usb-otg-fsm
On Sun, Jun 12, 2016 at 01:06:45PM +0200, Oscar wrote:
> usb: common: otg-fsm: add license to usb-otg-fsm.
>
> Fix warning about tainted kernel because usb-otg-fsm has no license.
> WARNING: with this patch usb-otg-fsm module can be loaded
> but then the kernel hangs. Tested with a udoo quad board.
>
> Signed-off-by: Oscar Curero
> ---
>
> --- a/drivers/usb/common/usb-otg-fsm.c.orig 2016-06-12
> 12:02:09.269814317 +0200
> +++ b/drivers/usb/common/usb-otg-fsm.c 2016-06-12
> 12:01:54.473000410 +0200
> @@ -21,6 +21,7 @@
> * 675 Mass Ave, Cambridge, MA 02139, USA.
> */
>
> +#include
> #include
> #include
> #include
> @@ -452,3 +453,4 @@ int otg_statemachine(struct otg_fsm *fsm
> return state_changed;
> }
> EXPORT_SYMBOL_GPL(otg_statemachine);
> +MODULE_LICENSE("GPL");
> --
> 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
Good catch, but would you please create the patch using "git
format-patch", I can't apply it directly.
--
Best Regards,
Peter Chen
--
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 v11 13/14] usb: gadget: udc: adapt to OTG core
On Mon, Jun 13, 2016 at 10:55:12AM +0300, Roger Quadros wrote:
> err1:
> - if (ret != -EISNAM)
> + if ((ret != -EISNAM))
Since you do not need above change.
Expect above, I am ok with this patch.
Acked-by: Peter Chen
> dev_err(&udc->dev, "failed to start %s: %d\n",
> udc->driver->function, ret);
> udc->driver = NULL;
> @@ -1389,6 +1565,12 @@ static ssize_t usb_udc_softconn_store(struct device
> *dev,
> return -EOPNOTSUPP;
> }
>
> + /* In OTG/dual-role mode, soft-connect should be handled by OTG core */
> + 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);
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 1d74fb8..8c6880d 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -701,6 +701,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
>
>
> --
> 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
--
Best Regards,
Peter Chen
--
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 v11 08/14] usb: otg: add OTG/dual-role core
On Mon, Jun 13, 2016 at 10:56:30AM +0300, 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
> ---
> v11:
> - remove usb_otg_kick_fsm().
> - typo fixes: structa/structure, upto/up to.
> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.
Acked-by: Peter Chen
>
> drivers/usb/Kconfig | 18 +
> drivers/usb/common/Makefile | 6 +-
> drivers/usb/common/usb-otg.c | 877
> +++
> drivers/usb/core/Kconfig | 14 -
> drivers/usb/gadget/Kconfig | 1 +
> include/linux/usb/gadget.h | 2 +
> include/linux/usb/hcd.h | 1 +
> include/linux/usb/otg-fsm.h | 7 +
> include/linux/usb/otg.h | 174 -
> 9 files changed, 1070 insertions(+), 30 deletions(-)
> create mode 100644 drivers/usb/common/usb-otg.c
>
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8689dcb..ed596ec 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -32,6 +32,23 @@ if USB_SUPPORT
> config USB_COMMON
> tristate
>
> +config USB_OTG_CORE
> + tristate
> +
> +config USB_OTG
> + bool "OTG/Dual-role support"
> + depends on PM && USB && USB_GADGET
> + default n
> + ---help---
> + The most notable feature of USB OTG is support for a
> + "Dual-Role" device, which can act as either a device
> + or a host. The initial role is decided by the type of
> + plug inserted and can be changed later when two dual
> + role devices talk to each other.
> +
> + Select this only if your board has Mini-AB/Micro-AB
> + connector.
> +
> config USB_ARCH_HAS_HCD
> def_bool y
>
> @@ -40,6 +57,7 @@ config USB
> tristate "Support for Host-side USB"
> depends on USB_ARCH_HAS_HCD
> select USB_COMMON
> + select USB_OTG_CORE
> select NLS # for UTF-8 strings
> ---help---
> Universal Serial Bus (USB) is a specification for a serial bus
> diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
> index f8f2c88..5122b3f 100644
> --- a/drivers/usb/common/Makefile
> +++ b/drivers/usb/common/Makefile
> @@ -7,5 +7,7 @@ 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
> -obj-$(CONFIG_USB_OTG)+= usbotg.o
> +ifeq ($(CONFIG_USB_OTG),y)
> +usbotg-y := usb-otg.o usb-otg-fsm.o
> +obj-$(CONFIG_USB_OTG_CORE) += usbotg.o
> +endif
> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> new file mode 100644
> index 000..a23ab1e
> --- /dev/null
> +++ b/drivers/usb/common/usb-otg.c
> @@ -0,0 +1,877 @@
> +/**
> + * 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
> +#include
> +#include
> +
> +/* OTG device list */
> +LIST_HEAD(otg_list);
> +static DEFINE_MUTEX(otg_list_mutex);
> +
> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
> +{
> + if (!hcd->primary_
Re: uac2: diagnosing uac2 audio gadget problems
On Wed, Jun 08, 2016 at 04:11:11PM -0700, Caleb Crome wrote: > > Here is the script I use for starting the gadget interface: > > cd /sys/kernel/config/usb_gadget > mkdir g1 > cd g1 > echo "0x1d6b" > idVendor > echo "0x0104" > idProduct > mkdir strings/0x409 > echo "0123456789" > strings/0x409/serialnumber > echo "Foo Inc." > strings/0x409/manufacturer > echo "Bar Gadget" > strings/0x409/product > mkdir functions/uac2.aud0 > mkdir functions/ecm.usb0 > #echo 64000 > functions/uac2.aud0/c_srate > #echo 64000 > functions/uac2.aud0/p_srate > mkdir configs/c.1 > mkdir configs/c.1/strings/0x409 > echo "CDC ECM + audio" > configs/c.1/strings/0x409/configuration > ln -s functions/uac2.aud0 configs/c.1 > ln -s functions/ecm.usb0 configs/c.1 > echo `ls /sys/class/udc/` > /sys/kernel/config/usb_gadget/g1/UDC > Try to use below command to see if it works, it works at my i.mx6 board. 1. List of PLAYBACK Hardware Devices root@imx6sxsabresd:~# aplay -l List of PLAYBACK Hardware Devices card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM Playback dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM] Subdevices: 1/1 Subdevice #0: subdevice #0 2. List of CAPTURE Hardware Devices root@imx6sxsabresd:~# arecord -l List of CAPTURE Hardware Devices card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM] Subdevices: 1/1 Subdevice #0: subdevice #0 3. Using below command to play (it is playback, the audio file is from PC) root@imx6sxsabresd:~# arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 & NOTE: arecord uses uac2_gadget to record, aplay uses real codec to play > > When I run the script above I get the following dumped into /var/log/syslog: > Jun 8 23:08:14 wandboard kernel: [ 139.994081] using random self > ethernet address > Jun 8 23:08:14 wandboard kernel: [ 139.994107] using random host > ethernet address > Jun 8 23:08:14 wandboard NetworkManager[359]: > nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed > Jun 8 23:08:14 wandboard NetworkManager[359]: (usb0): new > Generic device (carrier: OFF, driver: 'g_ether', ifindex: 4) > Jun 8 23:08:14 wandboard kernel: [ 140.125255] usb0: HOST MAC > 3e:52:2d:0d:98:fe > Jun 8 23:08:14 wandboard kernel: [ 140.153803] usb0: MAC 0e:cf:aa:06:aa:8a > Jun 8 23:08:14 wandboard systemd-udevd[773]: Failed to apply ACL on > /dev/snd/controlC3: Operation not supported > Jun 8 23:08:14 wandboard systemd-udevd[776]: Failed to apply ACL on > /dev/snd/pcmC3D0c: Operation not supported > Jun 8 23:08:14 wandboard systemd-udevd[775]: Failed to apply ACL on > /dev/snd/pcmC3D0p: Operation not supported > Jun 8 23:08:14 wandboard systemd-udevd[773]: Process > '/usr/sbin/alsactl -E HOME=/var/run/alsa restore 3' failed with exit > code 99. > Jun 8 23:08:14 wandboard NetworkManager[359]: devices added > (path: > /sys/devices/soc0/soc/210.aips-bus/2184000.usb/ci_hdrc.0/gadget/net/usb0, > iface: usb0) > Jun 8 23:08:14 wandboard NetworkManager[359]: device added > (path: > /sys/devices/soc0/soc/210.aips-bus/2184000.usb/ci_hdrc.0/gadget/net/usb0, > iface: usb0): no ifupdown configuration found. > > > Any idea what could be wrong?Is the 'Failed to apply ACL' relavent? Sorry, I don't know what that mean, do that mean there is something wrong with your local codec? -- Best Regards, Peter Chen -- 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 v3] usb: phy: mxs: Add DT bindings to configure TX settings
On Mon, Jun 13, 2016 at 04:40:55PM -0400, Jaret Cantu wrote: > > > >According to your previous information, the single formula can't be used > >to get D_CAL value, do you have any good ways except for using a table? > > That is not exactly what I said: > > "I can't find any formula which would hit all of those same > percentages **without rounding up.**" > Sorry, my careless. > I did find a formula that hits all of the percentages with rounding > up, and I listed this formula (in shell form) previously. The > rounding (+ (119-80)/2) just makes it look a little more awkward > than I would like: > > $ for d in 119 116 114 112 109 106 103 100 97 95 93 90 88 86 83 79; > do echo "$d="$(( ( (119-$d) * 0xf + (119-80)/2 ) / (119-80) )); > d=$((d+1)); done > 119=0 > 116=1 > 114=2 > 112=3 > 109=4 > 106=5 > 103=6 > 100=7 > 97=8 > 95=9 > 93=10 > 90=11 > 88=12 > 86=13 > 83=14 > 79=15 > > These current percentage/register value pairs match the D_CAL table. > > > > Sending the patch for new algorithm to speed up this issue please. > > > There were also some Documentation changes from between when I > created this patch and the current HOL for which I had to modify the > patch. I will review and test your v4 patch, thanks. -- Best Regards, Peter Chen -- 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 00/14] USB OTG/dual-role framework
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_vdbg() 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/Kconfig | 18 + > drivers/usb/Makefile | 1 + > 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 | 5 +- > drivers/usb/common/common.c | 27 + > drivers/usb/common/usb-otg-fsm.c | 203 ++--- > drivers/usb/common/usb-otg.c | 919 > ++ > drivers/usb/core/Kconfig | 22 - > drivers/usb/core/hcd.c| 56 ++ > drivers/usb/gadget/Kconfig| 1 + > drivers/usb/gadget/udc/core.c | 202 - > 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| 9 + > include/linux/usb/otg-fsm.h | 154 +--- > include/linux/usb/otg.h | 290 ++- > include/linux/usb/xhci_pdriver.h | 3 + > 29 files changed, 1918 insertions(+), 462 deletions(-) > create mode 100644 drivers/usb/common/usb-otg.c > > -- > 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 -- Best Regards, Peter Chen -- 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: uac2: diagnosing uac2 audio gadget problems
On Mon, Jun 13, 2016 at 04:49:50PM -0700, Caleb Crome wrote: > On Mon, Jun 13, 2016 at 4:04 PM, Caleb Crome wrote: > > On Mon, Jun 13, 2016 at 2:53 AM, Peter Chen wrote: > >> On Wed, Jun 08, 2016 at 04:11:11PM -0700, Caleb Crome wrote: > >>> > >>> Here is the script I use for starting the gadget interface: > >>> > >>> cd /sys/kernel/config/usb_gadget > >>> mkdir g1 > >>> cd g1 > >>> echo "0x1d6b" > idVendor > >>> echo "0x0104" > idProduct > >>> mkdir strings/0x409 > >>> echo "0123456789" > strings/0x409/serialnumber > >>> echo "Foo Inc." > strings/0x409/manufacturer > >>> echo "Bar Gadget" > strings/0x409/product > >>> mkdir functions/uac2.aud0 > >>> mkdir functions/ecm.usb0 > >>> #echo 64000 > functions/uac2.aud0/c_srate > >>> #echo 64000 > functions/uac2.aud0/p_srate > >>> mkdir configs/c.1 > >>> mkdir configs/c.1/strings/0x409 > >>> echo "CDC ECM + audio" > configs/c.1/strings/0x409/configuration > >>> ln -s functions/uac2.aud0 configs/c.1 > >>> ln -s functions/ecm.usb0 configs/c.1 > >>> echo `ls /sys/class/udc/` > /sys/kernel/config/usb_gadget/g1/UDC > >>> > >> > >> Try to use below command to see if it works, it works at my i.mx6 board. > >> > >> 1. List of PLAYBACK Hardware Devices > >> root@imx6sxsabresd:~# aplay -l > >> List of PLAYBACK Hardware Devices > >> card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] > >> Subdevices: 1/1 > >> Subdevice #0: subdevice #0 > >> card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM Playback dit-hifi-0 [] > >> Subdevices: 1/1 > >> Subdevice #0: subdevice #0 > >> card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM] > >> Subdevices: 1/1 > >> Subdevice #0: subdevice #0 > >> 2. List of CAPTURE Hardware Devices > >> root@imx6sxsabresd:~# arecord -l > >> List of CAPTURE Hardware Devices > >> card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] > >> Subdevices: 1/1 > >> Subdevice #0: subdevice #0 > >> card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM] > >> Subdevices: 1/1 > >> Subdevice #0: subdevice #0 > >> 3. Using below command to play (it is playback, the audio file is from > >> PC) > >> root@imx6sxsabresd:~# arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 & > >> > >> NOTE: arecord uses uac2_gadget to record, aplay uses real codec to play > >> > > > > Great to hear that it works on your board, that gives me hope :-) > > > > 2 questions: > > 1) What kernel version do you use? > > 2) What are the commands you send to configfs to get it working? Does > > it look like mine? > > I tried your commands, it can't work indeed. It seems the two interfaces can't be work together, the host side can't find the USB audio device. My test branch: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git branch: testing/next Works command: modprobe libcomposite mount none /sys/kernel/config/ -t configfs cd /sys/kernel/config/usb_gadget mkdir g1 cd g1 echo "0x1d6b" > idVendor echo "0x0104" > idProduct mkdir strings/0x409 echo "0123456789" > strings/0x409/serialnumber echo "Foo Inc." > strings/0x409/manufacturer echo "Bar Gadget" > strings/0x409/product mkdir functions/uac2.aud0 # mkdir functions/ecm.usb0 mkdir configs/c.1 mkdir configs/c.1/strings/0x409 # echo "CDC ECM + audio" > configs/c.1/strings/0x409/configuration echo 2 > functions/uac2.aud0/p_ssize echo 48000 > functions/uac2.aud0/p_srate echo 3 > functions/uac2.aud0/p_chmask echo 2 > functions/uac2.aud0/c_ssize echo 48000 > functions/uac2.aud0/c_srate echo 3 > functions/uac2.aud0/c_chmask ln -s functions/uac2.aud0 configs/c.1 # ln -s functions/ecm.usb0 configs/c.1 echo `ls /sys/class/udc/` > /sys/kernel/config/usb_gadget/g1/UDC At host side: aplay -Dhw:1 sine48k16s-5min.wav card 1: Gadget [Bar Gadget], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 At device side: arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 & I can hear the wav from my codec -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: common: otg-fsm: add license to usb-otg-fsm
On Mon, Jun 13, 2016 at 06:56:30PM +0200, Oscar wrote:
> Fix warning about tainted kernel because usb-otg-fsm has no license.
> WARNING: with this patch usb-otg-fsm module can be loaded
> but then the kernel will hang. Tested with a udoo quad board.
>
> Signed-off-by: Oscar Curero
> ---
> drivers/usb/common/usb-otg-fsm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/common/usb-otg-fsm.c
> b/drivers/usb/common/usb-otg-fsm.c
> index 9059b7d..2f537bb 100644
> --- a/drivers/usb/common/usb-otg-fsm.c
> +++ b/drivers/usb/common/usb-otg-fsm.c
> @@ -21,6 +21,7 @@
> * 675 Mass Ave, Cambridge, MA 02139, USA.
> */
>
> +#include
> #include
> #include
> #include
> @@ -450,3 +451,4 @@ int otg_statemachine(struct otg_fsm *fsm)
> return fsm->state_changed;
> }
> EXPORT_SYMBOL_GPL(otg_statemachine);
> +MODULE_LICENSE("GPL");
> --
I don't know why I can't apply your patch, does it make on
an very old version?
I apply it manually, thanks.
--
Best Regards,
Peter Chen
--
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: uac2: diagnosing uac2 audio gadget problems
On Tue, Jun 14, 2016 at 02:00:23PM +0800, Peter Chen wrote: > On Mon, Jun 13, 2016 at 04:49:50PM -0700, Caleb Crome wrote: > > On Mon, Jun 13, 2016 at 4:04 PM, Caleb Crome wrote: > > > On Mon, Jun 13, 2016 at 2:53 AM, Peter Chen wrote: > > >> On Wed, Jun 08, 2016 at 04:11:11PM -0700, Caleb Crome wrote: > > >>> > > >>> Here is the script I use for starting the gadget interface: > > >>> > > >>> cd /sys/kernel/config/usb_gadget > > >>> mkdir g1 > > >>> cd g1 > > >>> echo "0x1d6b" > idVendor > > >>> echo "0x0104" > idProduct > > >>> mkdir strings/0x409 > > >>> echo "0123456789" > strings/0x409/serialnumber > > >>> echo "Foo Inc." > strings/0x409/manufacturer > > >>> echo "Bar Gadget" > strings/0x409/product > > >>> mkdir functions/uac2.aud0 > > >>> mkdir functions/ecm.usb0 > > >>> #echo 64000 > functions/uac2.aud0/c_srate > > >>> #echo 64000 > functions/uac2.aud0/p_srate > > >>> mkdir configs/c.1 > > >>> mkdir configs/c.1/strings/0x409 > > >>> echo "CDC ECM + audio" > configs/c.1/strings/0x409/configuration > > >>> ln -s functions/uac2.aud0 configs/c.1 > > >>> ln -s functions/ecm.usb0 configs/c.1 > > >>> echo `ls /sys/class/udc/` > /sys/kernel/config/usb_gadget/g1/UDC > > >>> > > >> > > >> Try to use below command to see if it works, it works at my i.mx6 board. > > >> > > >> 1. List of PLAYBACK Hardware Devices > > >> root@imx6sxsabresd:~# aplay -l > > >> List of PLAYBACK Hardware Devices > > >> card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] > > >> Subdevices: 1/1 > > >> Subdevice #0: subdevice #0 > > >> card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM Playback dit-hifi-0 [] > > >> Subdevices: 1/1 > > >> Subdevice #0: subdevice #0 > > >> card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM] > > >> Subdevices: 1/1 > > >> Subdevice #0: subdevice #0 > > >> 2. List of CAPTURE Hardware Devices > > >> root@imx6sxsabresd:~# arecord -l > > >> List of CAPTURE Hardware Devices > > >> card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] > > >> Subdevices: 1/1 > > >> Subdevice #0: subdevice #0 > > >> card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM] > > >> Subdevices: 1/1 > > >> Subdevice #0: subdevice #0 > > >> 3. Using below command to play (it is playback, the audio file is from > > >> PC) > > >> root@imx6sxsabresd:~# arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 & > > >> > > >> NOTE: arecord uses uac2_gadget to record, aplay uses real codec to play > > >> > > > > > > Great to hear that it works on your board, that gives me hope :-) > > > > > > 2 questions: > > > 1) What kernel version do you use? > > > 2) What are the commands you send to configfs to get it working? Does > > > it look like mine? > > > > > I tried your commands, it can't work indeed. It seems the two interfaces > can't be work together, the host side can't find the USB audio device. > My test branch: > https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > branch: testing/next > > Works command: > modprobe libcomposite > mount none /sys/kernel/config/ -t configfs > cd /sys/kernel/config/usb_gadget > mkdir g1 > cd g1 > echo "0x1d6b" > idVendor > echo "0x0104" > idProduct > mkdir strings/0x409 > echo "0123456789" > strings/0x409/serialnumber > echo "Foo Inc." > strings/0x409/manufacturer > echo "Bar Gadget" > strings/0x409/product > mkdir functions/uac2.aud0 > # mkdir functions/ecm.usb0 > > mkdir configs/c.1 > mkdir configs/c.1/strings/0x409 > # echo "CDC ECM + audio" > configs/c.1/strings/0x409/configuration > > > echo 2 > functions/uac2.aud0/p_ssize > echo 48000 > functions/uac2.aud0/p_srate > echo 3 > functions/uac2.aud0/p_chmask > > echo 2 > functions/uac2.aud0/c_ssize > echo 48000 > functions/uac2.aud0/c_srate > echo 3 > functions/uac2.aud0/c_chmask > > ln -s functions/uac2.aud0 configs/c.1 > # ln -s functions/ecm.usb
Re: [PATCH] usb: common: otg-fsm: add license to usb-otg-fsm
On Tue, Jun 14, 2016 at 01:26:59PM +0200, Oscar wrote:
> El 2016-06-14 08:26, Peter Chen escribió:
> >On Mon, Jun 13, 2016 at 06:56:30PM +0200, Oscar wrote:
> >>Fix warning about tainted kernel because usb-otg-fsm has no license.
> >>WARNING: with this patch usb-otg-fsm module can be loaded
> >>but then the kernel will hang. Tested with a udoo quad board.
> >>
> >>Signed-off-by: Oscar Curero
> >>---
> >> drivers/usb/common/usb-otg-fsm.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >>diff --git a/drivers/usb/common/usb-otg-fsm.c
> >>b/drivers/usb/common/usb-otg-fsm.c
> >>index 9059b7d..2f537bb 100644
> >>--- a/drivers/usb/common/usb-otg-fsm.c
> >>+++ b/drivers/usb/common/usb-otg-fsm.c
> >>@@ -21,6 +21,7 @@
> >> * 675 Mass Ave, Cambridge, MA 02139, USA.
> >> */
> >>
> >>+#include
> >> #include
> >> #include
> >> #include
> >>@@ -450,3 +451,4 @@ int otg_statemachine(struct otg_fsm *fsm)
> >>return fsm->state_changed;
> >> }
> >> EXPORT_SYMBOL_GPL(otg_statemachine);
> >>+MODULE_LICENSE("GPL");
> >>--
> >
> >I don't know why I can't apply your patch, does it make on
> >an very old version?
> >
> >I apply it manually, thanks.
>
> Hi Peter,
>
> Thanks for applying my first patch to linux! :)
>
> As I said on the commit message, although I can load ci_hdrc_imx
> just fine, it doesn't work because as soon as it's loaded, the
> kernel hangs without any error or message at all.
>
> This happens on my udoo quad board (imx6q). Of course, if I
> blacklist the ci_hdrc_imx module (appending
> modprobe.blacklist=ci_hdrc_imx as boot parm) I can login the system,
> but no usb devices are found. Alexander Graf from Suse said that
> this sounds like a clock problem.
>
> Let me know how can I help you to resolve the problem.
>
I know your problem, below patch set should fix your problem:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/413331.html
But this patch set is objected due to the DT description. I am working
on it using generic power sequence driver, I will add you to cc list,
it will be great if you can help me test it
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: core: fix missing include
On Tue, Jun 14, 2016 at 01:08:08PM +0200, Arnd Bergmann wrote:
> On Wednesday, June 8, 2016 3:04:27 AM CEST kbuild test robot wrote:
> > >> drivers/usb/core/of.c:32:21: error: redefinition of
> > >> 'usb_of_get_child_node'
> > struct device_node *usb_of_get_child_node(struct device_node *parent,
> > ^
> >In file included from drivers/usb/core/of.c:21:0:
> >include/linux/usb/of.h:36:35: note: previous definition of
> > 'usb_of_get_child_node' was here
> > static inline struct device_node *usb_of_get_child_node
> > ^~~~~
> >
> > vim +/usb_of_get_child_node +32 drivers/usb/core/of.c
> >
> > 69bec725 Peter Chen 2016-02-19 26 * @portnum: the port number which
> > device is connecting
> > 69bec725 Peter Chen 2016-02-19 27 *
> > 69bec725 Peter Chen 2016-02-19 28 * Find the node from device tree
> > according to its port number.
> > 69bec725 Peter Chen 2016-02-19 29 *
> > 69bec725 Peter Chen 2016-02-19 30 * Return: On success, a pointer to the
> > device node, %NULL on failure.
> > 69bec725 Peter Chen 2016-02-19 31 */
> > 69bec725 Peter Chen 2016-02-19 @32 struct device_node
> > *usb_of_get_child_node(struct device_node *parent,
> > 69bec725 Peter Chen 2016-02-19 33 int
> > portnum)
> > 69bec725 Peter Chen 2016-02-19 34 {
> > 69bec725 Peter Chen 2016-02-19 35 struct device_node *node;
> >
> >
>
> I think what we want here is to make the compilation of of.o conditional on
> CONFIG_OF, so we get only one of the two definitions.
>
> Arnd
Thanks, Arnd. It is the correct solution, I will send patch soon.
--
Best Regards,
Peter Chen
--
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 1/1] usb: core: of.c: fix defined but not declare warning
The helper usb_of_get_child_node is defined at of.c, but missing its declare as a global function. Fix it by adding related header file as well as compile it on conditional of CONFIG_OF. Cc: Greg Kroah-Hartman Cc: Arnd Bergmann Cc: Alan Stern Cc: linux-usb@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Ben Dooks Cc: linux-ker...@lists.codethink.co.uk Signed-off-by: Peter Chen Reported-by: Ben Dooks --- drivers/usb/core/Makefile | 3 ++- drivers/usb/core/of.c | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile index 9780877..da36b78 100644 --- a/drivers/usb/core/Makefile +++ b/drivers/usb/core/Makefile @@ -5,8 +5,9 @@ usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o usbcore-y += devio.o notify.o generic.o quirks.o devices.o -usbcore-y += port.o of.o +usbcore-y += port.o +usbcore-$(CONFIG_OF) += of.o usbcore-$(CONFIG_PCI) += hcd-pci.o usbcore-$(CONFIG_ACPI) += usb-acpi.o diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c index 2289700..3de4f88 100644 --- a/drivers/usb/core/of.c +++ b/drivers/usb/core/of.c @@ -18,6 +18,7 @@ */ #include +#include /** * usb_of_get_child_node - Find the device node match port number -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: core: fix missing include
On Thu, Jun 16, 2016 at 02:02:37PM +0100, Ben Dooks wrote:
> On 14/06/16 12:08, Arnd Bergmann wrote:
> > On Wednesday, June 8, 2016 3:04:27 AM CEST kbuild test robot wrote:
> >>>> drivers/usb/core/of.c:32:21: error: redefinition of
> >>>> 'usb_of_get_child_node'
> >> struct device_node *usb_of_get_child_node(struct device_node *parent,
> >> ^
> >>In file included from drivers/usb/core/of.c:21:0:
> >>include/linux/usb/of.h:36:35: note: previous definition of
> >> 'usb_of_get_child_node' was here
> >> static inline struct device_node *usb_of_get_child_node
> >> ^
> >>
> >> vim +/usb_of_get_child_node +32 drivers/usb/core/of.c
> >>
> >> 69bec725 Peter Chen 2016-02-19 26 * @portnum: the port number which
> >> device is connecting
> >> 69bec725 Peter Chen 2016-02-19 27 *
> >> 69bec725 Peter Chen 2016-02-19 28 * Find the node from device tree
> >> according to its port number.
> >> 69bec725 Peter Chen 2016-02-19 29 *
> >> 69bec725 Peter Chen 2016-02-19 30 * Return: On success, a pointer to
> >> the device node, %NULL on failure.
> >> 69bec725 Peter Chen 2016-02-19 31 */
> >> 69bec725 Peter Chen 2016-02-19 @32 struct device_node
> >> *usb_of_get_child_node(struct device_node *parent,
> >> 69bec725 Peter Chen 2016-02-19 33
> >> int portnum)
> >> 69bec725 Peter Chen 2016-02-19 34 {
> >> 69bec725 Peter Chen 2016-02-19 35 struct device_node *node;
> >>
> >>
> >
> > I think what we want here is to make the compilation of of.o conditional on
> > CONFIG_OF, so we get only one of the two definitions.
>
> Ah, so make the of.o conditional, and also apply my patch for when
> it is compiled.
>
> Should I submit one for that, or is someone else on the case?
>
Yes, Ben. I have already done it.
http://www.spinics.net/lists/linux-usb/msg142676.html
--
Best Regards,
Peter Chen
--
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
