Re: [PATCH 1/1] usb: Kconfig: using select for USB_COMMON dependency
On Wednesday, September 14, 2016 9:49:30 AM CEST Peter Chen wrote: > According to (badf6d47f8a9 "usb: common: rework CONFIG_USB_COMMON logic") > we should select USB_COMMON at Kconfig when usb common stuffs are needed, > but some of Kconfig enties have not followed it, update them. > > Cc: Arnd Bergmann > Cc: Felipe Balbi > Cc: Heikki Krogerus > Signed-off-by: Peter Chen > Acked-by: Arnd Bergmann I've also put this on top of my randconfig build tree and will let you know if anything breaks unexpectedly. If you don't hear from me by tomorrow, assume it's fine. Arnd -- 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: misc: Add a driver for TC7USB40MU
On Tue, Sep 13, 2016 at 10:58:26PM -0700, Stephen Boyd wrote: > Quoting Peter Chen (2016-09-13 20:32:00) > > On Tue, Sep 13, 2016 at 06:42:46PM -0700, Stephen Boyd wrote: > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the > > > board to mux the D+/D- lines from the SoC between a micro usb > > > "device" port and a USB hub for "host" roles. Upon a role switch, > > > we need to change this mux to forward the D+/D- lines to either > > > the port or the hub. Therefore, introduce a driver for this > > > device that intercepts extcon USB_HOST events and logically > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is > > > attached. When the cable goes away, it will logically deassert > > > the gpio and mux the "device" lines. > > > > Would you please draw the design? It can also help me review your > > chipidea patch well. > > > > 1. How many ports on the board? > > 2. How the lines are connected on the board? > > > > The schematic for the db410c is publically available here[2][3]. > > There's also the 96boards spec[4] which talks about this switch based > design a little bit. See the section titled "Single USB port Example". > > [2] > https://github.com/96boards/documentation/blob/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf > [3] > https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf > [4] > https://www.96boards.org/wp-content/uploads/2015/02/96BoardsCESpecificationv1.0-EA1.pdf Ok, I see several use cases for this role switch 1. Using the hardware switch (218-4LPST) In this case, you can set USB_SW_SEL as input gpio, and use extcon-usb-gpio.c like before, just set this gpio as active low at dts. 2. Using USB_HS_ID as vbus-gpio (input), and USB_SW_SEL as id-gpio (output) I can't find hardware relationship between each other, maybe I miss something. This use case (design) seems strange, usually, we use ID pin controls vbus, but seldom use vbus pin control ID. How you would like to implement it? When the USB cable is connected (between PC), it receives vbus-gpio interrupt, then you set USB_SW_SEL as low? If disconnected, you set USB_SW_SEL as high? When the USB controller works at Host mode, what will happen if the user connects USB cable at device port? 3. Using sysfs to switch the role Set USB_SW_SEL according to "role" at debugfs Which one you would like to implement? Or anything else I miss? -- 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/1] usb: Kconfig: using select for USB_COMMON dependency
On Wed, Sep 14, 2016 at 09:35:10AM +0200, Arnd Bergmann wrote: > On Wednesday, September 14, 2016 9:49:30 AM CEST Peter Chen wrote: > > According to (badf6d47f8a9 "usb: common: rework CONFIG_USB_COMMON logic") > > we should select USB_COMMON at Kconfig when usb common stuffs are needed, > > but some of Kconfig enties have not followed it, update them. > > > > Cc: Arnd Bergmann > > Cc: Felipe Balbi > > Cc: Heikki Krogerus > > Signed-off-by: Peter Chen > > > > Acked-by: Arnd Bergmann > > I've also put this on top of my randconfig build tree and will let you > know if anything breaks unexpectedly. If you don't hear from me by tomorrow, > assume it's fine. > > Arnd 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 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
Am Dienstag, den 13.09.2016, 17:59 -0700 schrieb Kevin Hilman: > Martin Blumenstingl writes: > > > On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel > > wrote: > > [...] > > >>> I added Philipp and Hans to this thread - maybe they can comment on this. > >>> To sum it up, our problem is: > >>> - there are two separate USB PHYs on Meson GXBB > >>> - both are sharing the same reset line (provided by the reset-meson > >>> driver) > >>> - during initialization of the PHYs we must only call > >>> reset_control_reset(rstc) once (if we do it for the first *and* second > >>> PHY then the first PHY gets confused once the second PHY uses the > >>> reset because the first PHY's state is reset as well) > >> > >> If you have an initially asserted reset line and you can enable the > >> first module by deasserting the reset via reset_control_deassert (and > >> reset_control_assert to signal when the module may be disabled again > >> after use), shared resets are for you. > >> > >> If you need a reset pulse or have no direct control over the reset line, > >> (device_reset), the reset framework currently has no solution for this. > >> The ugly thing about reset_control_once would be that it can't re-reset > >> modules when unloading and reloading driver modules. > > > > The corresponding reset driver in question is reset-meson, which only > > implements reset (assert/deassert are not implemented). However, I > > don't know if this is due to hardware design. > > I think the hardware implements the latter, but maybe Neil can give > > more information here (I currently don't have access to my board so I > > cannot test how the hardware actually behaves). > > It's implemented that way because the hardware only supports a reset > pulse. Would it be possible to bring down both PHYs drivers, pull the reset line once, and then bring the drivers back up again on this hardware? regards Philipp -- 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 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
Am Dienstag, den 13.09.2016, 17:59 -0700 schrieb Kevin Hilman: > Martin Blumenstingl writes: > > > On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel > > wrote: > > [...] > > >>> I added Philipp and Hans to this thread - maybe they can comment on this. > >>> To sum it up, our problem is: > >>> - there are two separate USB PHYs on Meson GXBB > >>> - both are sharing the same reset line (provided by the reset-meson > >>> driver) > >>> - during initialization of the PHYs we must only call > >>> reset_control_reset(rstc) once (if we do it for the first *and* second > >>> PHY then the first PHY gets confused once the second PHY uses the > >>> reset because the first PHY's state is reset as well) > >> > >> If you have an initially asserted reset line and you can enable the > >> first module by deasserting the reset via reset_control_deassert (and > >> reset_control_assert to signal when the module may be disabled again > >> after use), shared resets are for you. > >> > >> If you need a reset pulse or have no direct control over the reset line, > >> (device_reset), the reset framework currently has no solution for this. > >> The ugly thing about reset_control_once would be that it can't re-reset > >> modules when unloading and reloading driver modules. > > > > The corresponding reset driver in question is reset-meson, which only > > implements reset (assert/deassert are not implemented). However, I > > don't know if this is due to hardware design. > > I think the hardware implements the latter, but maybe Neil can give > > more information here (I currently don't have access to my board so I > > cannot test how the hardware actually behaves). > > It's implemented that way because the hardware only supports a reset > pulse. Would it be possible to bring down both PHYs drivers, pull the reset line once, and then bring the drivers back up again? regards Philipp -- 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 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
Am Dienstag, den 13.09.2016, 20:38 +0200 schrieb Martin Blumenstingl:
> Hi Philipp,
>
> On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel wrote:
> > Hi Martin,
> >
> > Am Freitag, den 09.09.2016, 22:36 +0200 schrieb Martin Blumenstingl:
> >> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman wrote:
> >> > Martin Blumenstingl writes:
> >> >
> >> >> On Thu, Sep 8, 2016 at 10:53 PM, Ben Dooks
> >> >> wrote:
> >> >>> On 08/09/16 21:42, Kevin Hilman wrote:
> >>
> >> Ben Dooks writes:
> >>
> >> > On 08/09/16 20:52, Martin Blumenstingl wrote:
> >> >>
> >> >> On Thu, Sep 8, 2016 at 9:35 PM, Kevin Hilman
> >> >> wrote:
> >>
> >> + phy = devm_phy_create(&pdev->dev, NULL,
> >> &phy_meson_usb2_ops);
> >> + if (IS_ERR(phy)) {
> >> + dev_err(&pdev->dev, "failed to create PHY\n");
> >> + return PTR_ERR(phy);
> >> + }
> >> +
> >> + if (usb_reset_refcnt++ == 0) {
> >> + ret = device_reset(&pdev->dev);
> >> + if (ret) {
> >> + dev_err(&phy->dev, "Failed to reset USB
> >> PHY\n");
> >> + return ret;
> >> + }
> >> + }
> >> >>>
> >> >>>
> >> >>> The ref count + reset here looks like something that could/should
> >> >>> be
> >> >>> handled in a runtime PM callback.
> >> >>
> >> >> Unfortunately that doesn't work (as Jerome found out) because both
> >> >> PHYs are sharing the same reset line.
> >> >> So if the second PHY would call device_reset then it would also
> >> >> reset
> >> >> the first PHY!
> >> >>
> >> >> There's a comment above the declaration of usb_reset_refcnt which
> >> >> tries to explain this:
> >> >> "The PHYs are sharing a common reset line -> we are only allowed to
> >> >> reset once for all PHYs."
> >> >> Maybe I should move this comment to the "if (usb_reset_refcnt++ ==
> >> >> 0)
> >> >> {" line to make it easier to see?
> >> >>
> >> >
> >> > pm-runtime has refcounting in it. When one of the nodes turns on,
> >> > the pm-runtime will call your driver to say there is a user when
> >> > this first use turns up.
> >> >
> >> > If all the sub-phys turn off and drop their refcount then the driver
> >> > is called to say there are no more users and you can go to sleep.
> >>
> >>
> >> After a chat w/Martin on IRC, It turns out runtime PM wont help here.
> >>
> >> The reason is because there are physically two PHY devices[1]. Those
> >> 2
> >> devices will be treated independely by runtime PM, and have separate
> >> use-counting, which means doing what I proposed would cause a reset to
> >> happen when either device was probed.
> >>
> >> So, I think it's OK as it is.
> >> >>>
> >> >>>
> >> >>> Surely you can do pm_runtime_get/put on the phy's parent platform
> >> >>> device and do it that way?
> >> >> could you please be more specific with that (do you mean
> >> >> pdev->dev.parent)?
> >> >> so we would use pm_runtime_{get_sync,put} with the parent, while we
> >> >> would still define the runtime_resume in our driver.
> >> >
> >> > You'd also need to do get/put on the children, but yes, that's what Ben
> >> > is suggesting.
> >> >
> >> > However, the problem with all of the solutions proposed (runtime PM ones
> >> > included) is that we're forcing a board-specific design issue (2 devices
> >> > sharing a reset line) into a driver that should not have any
> >> > board-specific assumptions in it.
> >> >
> >> > For example, if this driver is used on another platform where different
> >> > PHYs have different reset lines, then one of them (the unlucky one who
> >> > is not probed first) will never get reset. So any form of per-device
> >> > ref-counting is not a portable solution.
> >> indeed, so in simple words we would need something like
> >> reset_control_do_once(rstc, RESET/ASSERT/DEASSERT) which would
> >> remember internally if any action has already been executed: if not it
> >> does a _reset, _assert or _deassert and otherwise it does nothing.
> >>
> >> > I'm not sure yet how the reset framework is supposed to handle shared
> >> > reset lines, but that needs some investigation. I quick glance and it
> >> > seems that reset controllers can have shared lines, so that should be
> >> > investigated.
> >> I added Philipp and Hans to this thread - maybe they can comment on this.
> >> To sum it up, our problem is:
> >> - there are two separate USB PHYs on Meson GXBB
> >> - both are sharing the same reset line (provided by the reset-meson driver)
> >> - during initialization of the PHYs we must only call
> >> reset_control_reset(rstc) once (if we do it for the first *and* second
> >> PHY then the first PHY gets confused once the second PHY uses the
> >> reset
Re: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
Quoting Stephen Boyd (2016-09-13 18:42:46)
> On the db410c 96boards platform we have a TC7USB40MU[1] on the
> board to mux the D+/D- lines from the SoC between a micro usb
> "device" port and a USB hub for "host" roles. Upon a role switch,
> we need to change this mux to forward the D+/D- lines to either
> the port or the hub. Therefore, introduce a driver for this
> device that intercepts extcon USB_HOST events and logically
> asserts a gpio to mux the "host" D+/D- lines when a host cable is
> attached. When the cable goes away, it will logically deassert
> the gpio and mux the "device" lines.
>
> [1]
> https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
>
> Cc: MyungJoo Ham
> Cc: Chanwoo Choi
> Cc:
> Signed-off-by: Stephen Boyd
> ---
>
> Should I make the extcon part optional? I could see a case where there are two
> "OTG" ports connected to the mux (or two hubs), and for some reason the
> software may want to mux between them at runtime. If we mandate an extcon,
> that won't be possible to support. Perhaps it would be better to have
> the node, but connect it to the usb controller with a phandle (maybe of_graph
> endpoints would be useful too) so that when the controller wants to mux over
> a port it can do so.
Here's some dts mock-up on top of the db410c for the of_graph stuff. I
haven't written any code around it, but the idea is to allow the binding
to specify how the mux is connected to upstream and downstream D+/D-
lines. This way, we can do some dt parsing of the endpoints and their
parent nodes to figure out if the mux needs to be set high or low to use
a device connector or a usb hub based on if the id cable is present.
Maybe I'm over thinking things though and we could just have a DT
property for that.
soc {
usb@78d9000 {
extcon = <&usb_id>, <&usb_id>;
usb-controller; // needed?
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
usb_output: endpoint@0 { // USB D+/D-
reg = <0>;
remote-endpoint =
<&usb_switch_input>;
};
};
};
};
};
usb2513 {
compatible = "smsc,usb3503";
reset-gpios = <&pm8916_gpios 3 GPIO_ACTIVE_LOW>;
initial-mode = <1>;
usb-hub; // indicate this is a hub
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
usb_hub_input: endpoint@0 { // USB{DP,DM}_UP
reg = <0>;
remote-endpoint = <&usb_switch_hub_ep>;
};
usb_hub_output1: endpoint@1 { // USB{DP,DM}_DN1
reg = <1>;
remote-endpoint = <&usb_a2_connector>;
};
usb_hub_output2: endpoint@2 { // USB{DP,DM}_DN2
reg = <2>;
remote-endpoint = <&usb_a1_connector>;
};
usb_hub_output3: endpoint@3 { // USB{DP,DM}_DN3
reg = <3>;
// goes to expansion connector
};
};
};
};
usb_id: usb-id {
compatible = "linux,extcon-usb-gpio";
id-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&usb_id_default>;
};
usb-switch {
compatible = "toshiba,tc7usb40mu";
switch-gpios = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>;
extcon = <&usb_id>;
pinctrl-names = "default";
pinctrl-0 = <&usb_sw_sel_pm>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
On Tue, Sep 13, 2016 at 11:29:12PM -0700, Stephen Boyd wrote: > Quoting Peter Chen (2016-09-13 19:11:33) > > On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote: > > > Quoting Peter Chen (2016-09-13 00:03:58) > > > > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote: > > > > > The high-speed phy on qcom SoCs is controlled via the ULPI > > > > > viewport. > > > > > > > > > > > > > Hi Stephen, I am a little puzzled how this driver co-work with chipidea > > > > driver. According to nxp IC guys, the ULPI PHY's clock needs to be > > > > enabled > > > > before access portsc.pts (calling hw_phymode_configure), otherwise, > > > > the system will hang. But I find you call hw_phymode_configure before > > > > phy->power_on, doesn't your design have this requirement? > > > > > > Which clk needs to be enabled? The xcvr_clk? I believe that clk > > > corresponds to the "core" clk that we enable in the msm glue driver > > > layer. When that clk is enabled, the ULPI phy is able to respond to > > > register read/writes via the ULPI viewport. > > > > > > > The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, > > so in your platform, even PHY clock is gated, you can still access > > portsc.pts to configure PHY mode at controller register? > > There are a couple input clocks for this phy. I'm not sure which one the > nxp IC guys think needs to be enabled. Typically, the ref_clk is always > on so it's hard for me to test a scenario where it isn't enabled. But > I'm not sure that the ref_clk is what we're talking about anyway. Would > you know the frequency perhaps? I think this ref_clk is ULPI PHY vendor specific, at USB3317, it is 26Mhz. > The ref_clk is usually 19.2MHz on these > SoCs. That would match up with the "crystal input" pin in the ULPI > spec[1]. > > Do you know if this is documented anywhere in the chipidea manual? > I'll have to look again and see if there's something in there, but I > didn't see anything like this. > > I would guess that we're talking about the xcvr clock though, because > from what I see in the manual, this is used to clock the interface > between the ULPI phy and the controller. In the ULPI spec, this matches > up with the "clock" signal for the ULPI phy and that usually runs at > something >= 60MHz. I think you are right, since controller only concerns the output clock. So, if you have not enabled xcvr, you may meet hang when set portsc.pts too? At some designs, ULPI input clock (ref_clk) may from Soc internal, without enabling it, the controller will not get PHY clock (60Mhz). When visiting portsc.pts, may meet hang. > > > > > > > > > > > Besides, you read ulpi id before phy->power_on, how can read work before > > > > phy power on? > > > > > > > > > > I've found that even having the link clk enabled before phy->power_on > > > doesn't mean it's possible to read the id registers though. That's > > > because there can be other power supplies, like regulators, which need > > > to be on for the phy to operate properly. > > > > > > > Then I am puzzled the current initialization for your case, in my mind, > > it should like below: > > > > qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init > > > > Like other PHYs, it should get PHY first, then power on it, after that, > > you can access its register. > > > > Hmm.. maybe the confusion is in which registers we should be able to > access? Are we talking about the ULPI viewport MMIO register space or > the ULPI registers that we access through the viewport? I have a > hw_phymode_configure() inside of of ci_ulpi_init() so that the > identification registers through the ULPI viewport read properly > (assuming there aren't other power requirements like regulators). If we > don't set the portsc.pts before using the viewport, the viewport doesn't > work and reads timeout. So we really don't touch the ULPI registers > except for the scratch space and the id registers until after the phy is > properly powered on with clks and regulators, because the only place we > touch them after doing the id checking is in this phy driver in > qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where > we don't know which device driver to probe because the phy needs to be > powered on to read the id registers to know which device driver to use > by using DT to match up device drivers instead. > > [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf Ok, ulpi phy works like USB device on USB bus which create device at runtime. So, like some hard-wired USB devices, it may needs power sequence too, otherwise, how it knows which driver can loads. -- 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: ULPI phy issue with
On Tue, Sep 13, 2016 at 08:05:32PM +0200, Fabien Lahoudere wrote: > Hi Peter, > > >> > >>This is our device tree imx-ppd.dts: > > > >I may know the reason why you meet hang at current flow, you are using > >generic phy driver, and the PHY clock is enabled at phy_init which is > >called later than setting portsc.pts. The current flow to enable ULPI > >phy is like below: > > This explains why the patch works if USBPHY_INTERFACE_MODE_ULPI works as > USBPHY_INTERFACE_MODE_UTMI. because _ci_usb_phy_init(ci) initialise clock > and generator. Yes. > > > > >1. Enable ULPI and choose its clock select at usbmisc, which you have > >already done. > >2. Enable the input clock for ULPI > > This is done by _ci_usb_phy_init(ci); and this function only do this so I > think we should have in ci_usb_phy_init(ci);: > case USBPHY_INTERFACE_MODE_ULPI: > ret = _ci_usb_phy_init(ci); > if (!ret) > hw_wait_phy_stable(); > else > return ret; > >3. set portsc.pts > > > hw_phymode_configure(ci); > ci_ulpi_phy_init(ci); // to init ULPI specific config once > portsc.pts is > enabled > break; > > >You may need to have a ULPI PHY driver which do some power sequence > >(clock, regulator, etc) before setting portsc.pts and visit ULPI > >register. > This is already done by _ci_usb_phy_init(ci); > > In conclusion, I think USBPHY_INTERFACE_MODE_ULPI should work as > USBPHY_INTERFACE_MODE_UTMI but with an extra function to visit ULPI register > (ci_ulpi_phy_init(ci);). > Am I wrong? Currently, you are using generic PHY driver which does not intends for ULPI PHY uses, looks at usb/phy/phy-upi.c and usb/common/ulpi.c, both need to read id at its initialization. > > > > >I am also a little confused how Stephen Boyd's ULPI driver for qualcomm > >platform, I will cc on discussion. > > As you ask me earlier maybe he init clock from bootloader. Yes, his PHY input clock is always on. Stephen boyd's ulpi support at chipidea is the correct way. For your case, you can create a generic ULPI PHY driver, and registered it on ulpi bus, but you still need power sequence for your case. I am afraid you may use your hack temporarily at local, once Stephen's patch and power sequence patch set are queued, you can submit your changes. -- 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 v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On Tue, Sep 13, 2016 at 10:00:28AM +0200, NeilBrown wrote: > On Mon, Sep 12 2016, Mark Brown wrote: > > That's not actually 100% clear to me - for what the wm831x is doing it > > probably *does* want the higher limit. This is a system inflow limit > > (as it should be for this), at least the charger will adapt to voltage > > variations though other users in the system are much less likely to do > > so. > Not having very much electrical engineering background, I cannot say for > sure what will happen, but it seems likely that once the voltage drops > much below 4.75V, the charger won't be operating at peak efficiency, > which would be a waste. > I can easily imagine that the hardware would switch off at some voltage > level, rather than just making do with what is there. > So I'm skeptical of this approach, but I'm open to being corrected by > someone more knowledgeable than I. Yes, the idea is that the charger will back off charging and stop entirely if the rest of the system is consuming too much power to allow it to continue effectively. The same thing happens with wall power, if a wall supply isn't able to power the charger (eg, because the rest of the system is running flat out) it'll have to cope with that. > Looking at it from a different perspective, according to the patch set, > the limits that wm831x is able to impose are: > +0, > +2, > +100, > +500, > +900, > +1500, > +1800, > +550, > These are, from the battery charger spec, minimums rather than maximums. > e.g. a CDP provides at least 1500, and as much as 5000. So it seems > that the wm831x was designed to be told the minimum guaranteed available. > But that is circumstantial evidence and might be misleading. AIUI this is conservatisim in the system design - another way of reading a spec with a range like this is that the consumer should aim for the lower limit, the provider should aim for the upper limit and that way if either of them has issues with tolerances things will still work out. It predates wide availability of CDP so I wouldn't be surprised if that bit were just an oversight. Like I say this bit of hardware is totally separate to the battery charger. signature.asc Description: PGP signature
[GIT PULL] usb: patches for v4.9 merge window
Hi Greg, Here's my pull request for v4.9 merge window. Patches have been tested with plataforms I have around (where applicable) and have also been soaking in linux-next for a while. Let me know if you want anything to be changed. The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468: Linux 4.8-rc3 (2016-08-21 16:14:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v4.9 for you to fetch changes up to e6be244a83211f3a9daaf5e29ee97fe0bf1efe5a: usb: gadget: uvc: add V4L2 dependency (2016-09-13 09:29:08 +0300) usb: patches for v4.9 merge window This time around we have 92 non-merge commits. Most of the changes are in drivers/usb/gadget (40.3%) with drivers/usb/gadget/function being the most active directory (27.2%). As for UDC drivers, only dwc3 (26.5%) and dwc2 (12.7%) have really been active. The most important changes for dwc3 are better support for scatterlist and, again, throughput improvements. While on dwc2 got some minor stability fixes related to soft reset and FIFO usage. Felipe Tonello has done some good work fixing up our f_midi gadget and Tal Shorer has implemented a nice API change for our ULPI bus. Apart from these, we have our usual set of non-critical fixes, spelling fixes, build warning fixes, etc. Alexey Khoroshilov (1): usb: gadget: goku_udc: fix memory leak in goku_probe() Anurag Kumar Vulisha (1): usb: dwc3: of-simple: Fix warning during unbind Arnd Bergmann (2): usb: dwc3: avoid -Wmaybe-uninitialized warning usb: gadget: uvc: add V4L2 dependency Baolin Wang (1): usb: dwc3: core: Move the mode setting to the right place Bhaktipriya Shridhar (1): usb: dwc2: Remove deprecated create_singlethread_workqueue Brian Norris (1): Documentation: dt: dwc3: note the supported phy-names Colin Ian King (4): usb: gadget: remove redundant self assignment usb: phy: ab8500-usb: fix spelling mistake "regester" -> "register" usb: gadget: net2280: fix typo: "Inavlid" -> "Invalid" usb: gadget: remove variable ret and remove unnecessary if statement Felipe Balbi (15): usb: dwc3: gadget: retire LST bit completely usb: dwc3: gadget: increment dequeue pointer on completion usb: dwc3: gadget: simplify dwc3_ep_prev_trb() usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue() usb: dwc3: gadget: avoid while (1) loop on completion usb: dwc3: gadget: add sg and num_pending_sgs to dwc3_request usb: dwc3: gadget: interrupt on ring full too usb: dwc3: gadget: add remaining sg entries to ring usb: dwc3: gadget: remove condition that never happens usb: dwc3: gadget: improve increment request->actual usb: dwc3: gadget: abolish trbs_left usb: dwc3: gadget: stop kicking if we run out of space usb: gadget: don't couple configfs to legacy gadgets usb: dwc3: of-simple: allow glues without clocks usb: dwc3: of-simple: add compatible for Cavium Felipe F. Tonello (10): usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align usb: gadget: change len to size_t on alloc_ep_req() usb: gadget: align buffer size when allocating for OUT endpoint usb: gadget: f_midi: remove alignment code for OUT endpoint usb: gadget: f_midi: defaults buflen sizes to 512 usb: gadget: f_midi: refactor state machine usb: gadget: f_midi: drop substreams when disabling endpoint usb: gadget: remove useless parameter in alloc_ep_req() usb: gadget: f_hid: use free_ep_req() usb: gadget: f_hid: use alloc_ep_req() Felix Hädicke (3): usb: gadget: f_fs: handle control requests not directed to interface or endpoint usb: gadget: composite: let USB functions process ctrl reqs in cfg0 usb: gadget: f_fs: handle control requests in config 0 Harish Jenny K N (2): usb: gadget: u_ether: fix another dereference after null check usb: gadget: NCM: Protect dev->port_usb using dev->lock Jaret Cantu (1): usb: phy: mxs: Add DT bindings to configure TX settings Jim Baxter (1): usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference Johannes Berg (1): usb: gadget: f_hid: add dev to configfs John Youn (6): usb: dwc3: Add revision numbers for the USB 3.0 IP usb: dwc3: Add ENDXFER command polling Documentation: devicetree: dwc2: Deprecate g-tx-fifo-size usb: dwc2: gadget: Only initialize device if in device mode usb: dwc2: Add delay to core soft reset usb: dwc2: Properly account for the force mode delays Jussi Kivilinna (3): usb: gadget: f_ncm: add SuperSpeed descriptors for CDC NCM usb: gadget: net2280: fix infinite loop in irq handler usb: gadget: net2280: match interrupt endpoints to PIO endpoints and DMA
[PATCH] MAINTAINERS: add tree entry for USB Serial
Add tree entry for USB Serial. Signed-off-by: Johan Hovold --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6781a3febd59..c7131a91013a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12267,6 +12267,7 @@ F: drivers/net/usb/rtl8150.c USB SERIAL SUBSYSTEM M: Johan Hovold L: linux-usb@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git S: Maintained F: Documentation/usb/usb-serial.txt F: drivers/usb/serial/ -- 2.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VL805 USB 3.0 does not see connected devices (only on x86_64) (x86 is ok)
may be i can help to test something else? I am ready and have enough free time 2016-09-12 20:44 GMT+03:00 c400 : > [182047.000570] xhci_hcd :02:00.0: remove, state 4 > [182047.000577] usb usb4: USB disconnect, device number 1 > [182047.023980] xhci_hcd :02:00.0: Host not halted after 16000 > microseconds. > [182047.023982] xhci_hcd :02:00.0: Host controller not halted, > aborting reset. > [182047.023996] xhci_hcd :02:00.0: USB bus 4 deregistered > [182047.024103] xhci_hcd :02:00.0: remove, state 1 > [182047.024108] usb usb3: USB disconnect, device number 1 > [182047.024320] xhci_hcd :02:00.0: USB bus 3 deregistered > [182058.617466] xhci_hcd :02:00.0: xHCI Host Controller > [182058.617556] xhci_hcd :02:00.0: new USB bus registered, > assigned bus number 3 > [182058.640820] xhci_hcd :02:00.0: Host not halted after 16000 > microseconds. > [182058.640822] xhci_hcd :02:00.0: can't setup: -110 > [182058.640824] xhci_hcd :02:00.0: USB bus 3 deregistered > [182058.640944] xhci_hcd :02:00.0: init :02:00.0 fail, -110 > [182058.640947] xhci_hcd: probe of :02:00.0 failed with error -110 > > can not see my flash inserted into the USB > > echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control > Do not have such folder > (i`ve recompiled my kernel (make defconfig) with some small changes. > may be i need to enable something in kernelt? -- 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: VL805 USB 3.0 does not see connected devices (only on x86_64) (x86 is ok)
On Wed, 2016-09-14 at 15:22 +0300, c400 wrote: > may be i can help to test something else? I am ready and have enough free time You may need to mount debugfs at /sys/kernel/debug HTH Oliver -- 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] dmaengine: cppi41: Ignore EINPROGRESS for PM runtime
On Tue, Sep 13, 2016 at 10:22:43AM -0700, Tony Lindgren wrote: > We can occasionally get -EINPROGRESS for pm_runtime_get. In that case > we can just continue as we're queueing transfers anyways when > pm_runtime_active is not set. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: use of_usb_get_dr_mode_by_phy() inline helper without USB
We have had two new PHY drivers call of_usb_get_dr_mode_by_phy()
recently without having a dependency on CONFIG_USB_COMMON, resulting
in a link error:
ERROR: "of_usb_get_dr_mode_by_phy" [drivers/phy/phy-meson-usb2.ko] undefined!
I fixed up the first one (sun4i) by adding the dependency, but
if we get more of this, it's probably better to allow the PHY
drivers to build without the dependency.
This changes the guard around declarations so we only refer to
them when both CONFIG_OF and CONFIG_USB_COMMON are enabled,
which is the right thing for all of the first calls but not the
one that already has a correct check for USB_SUPPORT rather than
USB_COMMON.
Signed-off-by: Arnd Bergmann
Fixes: 5ed935458519 ("phy: meson: add USB2 PHY support for Meson8b and GXBB")
---
include/linux/usb/of.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index 5ff9032ee1b4..3ed539626840 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -11,7 +11,7 @@
#include
#include
-#if IS_ENABLED(CONFIG_OF)
+#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_COMMON)
enum usb_dr_mode of_usb_get_dr_mode_by_phy(struct device_node *np, int arg0);
bool of_usb_host_tpl_support(struct device_node *np);
int of_usb_update_otg_caps(struct device_node *np,
--
2.9.0
--
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: crash in usb_hc_died+0x16 when unplugging usb-c dock
On 08.09.2016 17:38, Alan Stern wrote: On Thu, 8 Sep 2016, Mathias Nyman wrote: ehci-hcd includes checks in several places for ehci->rh_state == RH_STATE_RUNNING. The removal pathway sets ehci->rh_state to RH_STATE_HALTED. As a result, the driver avoids waiting for things that will never happen. Yes, seems that there are two things that need to be done for xhci here. First part is doing the similar thing to xhci_urb_dequeue as ehci does, make sure host is alive before queuing any stop endpoint commands. It does check if PCI reads return 0x or host is XHCI_STATE_DYING, but we could detect a remove a lot earlier. There's a big difference between a removal and the host controller dying, because removal can be clean. So as long as the controller is still running okay, you shouldn't skip any steps -- just refuse to accept new URB submissions. But if the controller is gone or dead, then absolutely avoid queuing any new commands. I've been staring at the code for a while and I think xhci might need a bigger rework in this area. For example the XHCI_STATE_DYING flag was originally a flag meaning that a watchdog function for a timed out stop endpoint command is running and all URBs will be given back. Since then this flag has been used when host is no longer responding. The rework will take some time, I think I'll do a quick fix to just prevent the deadlock. That fix could go in quicker and to stable while polishing the rework -Mathias -- 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 v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On Wed, Sep 14 2016, Mark Brown wrote: > [ Unknown signature status ] > On Tue, Sep 13, 2016 at 10:00:28AM +0200, NeilBrown wrote: >> On Mon, Sep 12 2016, Mark Brown wrote: > >> > That's not actually 100% clear to me - for what the wm831x is doing it >> > probably *does* want the higher limit. This is a system inflow limit >> > (as it should be for this), at least the charger will adapt to voltage >> > variations though other users in the system are much less likely to do >> > so. > >> Not having very much electrical engineering background, I cannot say for >> sure what will happen, but it seems likely that once the voltage drops >> much below 4.75V, the charger won't be operating at peak efficiency, >> which would be a waste. >> I can easily imagine that the hardware would switch off at some voltage >> level, rather than just making do with what is there. >> So I'm skeptical of this approach, but I'm open to being corrected by >> someone more knowledgeable than I. > > Yes, the idea is that the charger will back off charging and stop > entirely if the rest of the system is consuming too much power to allow > it to continue effectively. The same thing happens with wall power, if > a wall supply isn't able to power the charger (eg, because the rest of > the system is running flat out) it'll have to cope with that. Maybe you are correct. I don't find your argument convincing, but maybe that is because I don't want to... Some facts though: 1/ I had a report once from someone whose device stopped charging because it was pulling more current than the charger could supply. The voltage dropped below the 3.5V (I think) that the battery charging hardware needed, so it switched off. It wouldn't switch back on again until explicitly told too. It would then overload the charger again and switch off. Changing the code to put a lower limit on the current allowed the battery to be charged. So empirical evidence suggests that the lower number should be used. 2/ I hoped that Battery Charging Specification Revision 1.2 December 7, 2010 would say something definite, but I cannot find it. However, "note 1" to "Table 5-2 Currents" says: 1) The maximum current is for safety reasons, as per USB 2.0 section 7.2.1.2.1. Which seems to say the maximum is just for safety, implying that the minimum is the important value. 3/ Felipe Balbi appears to agree with my perspective. http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1224904.html does argument-by-authority work? > >> Looking at it from a different perspective, according to the patch set, >> the limits that wm831x is able to impose are: > >> + 0, >> + 2, >> + 100, >> + 500, >> + 900, >> + 1500, >> + 1800, >> + 550, > >> These are, from the battery charger spec, minimums rather than maximums. >> e.g. a CDP provides at least 1500, and as much as 5000. So it seems >> that the wm831x was designed to be told the minimum guaranteed available. >> But that is circumstantial evidence and might be misleading. > > AIUI this is conservatisim in the system design - another way of reading > a spec with a range like this is that the consumer should aim for the > lower limit, the provider should aim for the upper limit and that way if > either of them has issues with tolerances things will still work out. > It predates wide availability of CDP so I wouldn't be surprised if that > bit were just an oversight. Like I say this bit of hardware is totally > separate to the battery charger. Your last sentence is interesting I would reply "of course". All the code we are talking about is only tangentially related to battery charging. It is about how much current can safely be pulled from a USB port. What that current is used for is a completely separate question. NeilBrown signature.asc Description: PGP signature
Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Ulf and Alan, On Fri, 2016-09-09 at 19:34 +0530, Ritesh Raj Sarraf wrote: > For #2, I'm building the 4.8-rc5 kernel with the following change. This build > does not include the previous change you had suggested (related to > POWER_CYCLE) > > Date: Fri Sep 9 19:28:03 2016 +0530 > > Disable pm runtime in mmc core > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c > index e55cde6..32388d5 100644 > --- a/drivers/mmc/core/core.c > +++ b/drivers/mmc/core/core.c > @@ -970,9 +970,6 @@ int __mmc_claim_host(struct mmc_host *host, atomic_t > *abort) > spin_unlock_irqrestore(&host->lock, flags); > remove_wait_queue(&host->wq, &wait); > > - if (pm) > - pm_runtime_get_sync(mmc_dev(host)); > - > return stop; > } > EXPORT_SYMBOL(__mmc_claim_host); > @@ -1000,7 +997,6 @@ void mmc_release_host(struct mmc_host *host) > spin_unlock_irqrestore(&host->lock, flags); > wake_up(&host->wq); > pm_runtime_mark_last_busy(mmc_dev(host)); > - pm_runtime_put_autosuspend(mmc_dev(host)); > } > } > EXPORT_SYMBOL(mmc_release_host); I tried with these changes on 4.8-rc6 and I only saw 2 resets so far. I captured the usb trace [1], just in case if you need it. [1] https://people.debian.org/~rrs/tmp/4.8-rc6-ulf.txt.gz - -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX2WO6AAoJEKY6WKPy4XVpfx4P/3VOWgHw87iZxuHlw+vHUVOR BB8cdQidh6nVba2UcDXb8uw/oYYYEJZ0FYvvdgKwt/14QNaL1L3jwrLpayUC7AAM wZA8bhESANx/KoJiZH4GuasnkXfmjXVz2XPOIz/b8qfp4jfreFZfZQHgkIY7cEtE gO9JArpM/e6FZY/5mEYy1bFnvuuyTfI4Wu5Cm6HmyidT1mfhTM7xvyMTLfM+QRUm VT7pRhS6oujWO7K2KDMTrcZqgs2AVmjCqZW13F4AnMU/owxvRYTpGyW3hDbi9oIg Z8ZJ5sHT7jpJ4I/FZJxwaSthIN5aF4wG8UjTFr2EIc+W5Xx/xzYpZP3Qm+HkFnej n8Uyo0ZMN9+CV6VI2Qgzr+pB5LAfYHjIMobGAzaCzN81MWCVmb/GfiLQhpcgOnoK TMHVqCqWlkF8W0V5ap+Tc4Ce4Wqj/V+RlQpE01GeOg15DUtgqWXCGbYKspnwwRD2 u2Ivso9G4xDd0VOp9x4zpIdfbAqaSP+DuZZ7EnGVfd30j4ENWsrRTDXdWf63uAx6 GMOpAephwUOZo7WFxwd/q19181YM/emSg+weOMcGxwHvpQ+vTEN+JELD0B0Z6PpI OvaPROIL8bb5SuPKzKJ55ZRLpv40sjWOglZC1oOhtSg2IMFJwjPcqzaO4frIxl4t 3OCttIZYgpp5kIiW8qV1 =KNnj -END PGP SIGNATURE- -- 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 v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On Wed, Sep 14, 2016 at 04:11:58PM +0200, NeilBrown wrote: > On Wed, Sep 14 2016, Mark Brown wrote: > > Yes, the idea is that the charger will back off charging and stop > > entirely if the rest of the system is consuming too much power to allow > > it to continue effectively. The same thing happens with wall power, if > > a wall supply isn't able to power the charger (eg, because the rest of > > the system is running flat out) it'll have to cope with that. > Maybe you are correct. I don't find your argument convincing, but maybe > that is because I don't want to... There's a *huge* variation in how chargers are designed, some are designed to be dumb and won't function without software while the wm831x is more at the opposite end of the spectrum and will quite happily run all the charging and power source selection logic with no software intervention at all - the parameters it uses can be changed at runtime but that's about it. Software implementations are obviously more flexible but hardware implementations can be more responsive to changes in system state like drooping supplies and aren't vulnerable to things like software lockups. > 1/ I had a report once from someone whose device stopped charging > because it was pulling more current than the charger could supply. > The voltage dropped below the 3.5V (I think) that the battery > charging hardware needed, so it switched off. It wouldn't switch > back on again until explicitly told too. It would then overload the > charger again and switch off. That's just one charger's algorithm though, other options are available. > Which seems to say the maximum is just for safety, implying that the > minimum is the important value. This is what I was saying about a sensible reading being for the supply and consumer side to directly target the maximum and minimum limits respectively (though for the battery charger spec it's a bit different as the range is so wide). > 3/ Felipe Balbi appears to agree with my >perspective. > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1224904.html >does argument-by-authority work? TI do a lot of the more software managed chargers (which I suspect are the main thing Felipe will have looked at) if that's what you're referring to here? The device is implementing pretty much the algorithm you're describing in that e-mail so I'm a bit confused as to what you're saying here. signature.asc Description: PGP signature
Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]
On Wed, 14 Sep 2016, Ritesh Raj Sarraf wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello Ulf and Alan, > > On Fri, 2016-09-09 at 19:34 +0530, Ritesh Raj Sarraf wrote: > > For #2, I'm building the 4.8-rc5 kernel with the following change. This > > build > > does not include the previous change you had suggested (related to > > POWER_CYCLE) > > > > Date: Fri Sep 9 19:28:03 2016 +0530 > > > > Disable pm runtime in mmc core > > > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c > > index e55cde6..32388d5 100644 > > --- a/drivers/mmc/core/core.c > > +++ b/drivers/mmc/core/core.c > > @@ -970,9 +970,6 @@ int __mmc_claim_host(struct mmc_host *host, atomic_t > > *abort) > > spin_unlock_irqrestore(&host->lock, flags); > > remove_wait_queue(&host->wq, &wait); > > > > - if (pm) > > - pm_runtime_get_sync(mmc_dev(host)); > > - > > return stop; > > } > > EXPORT_SYMBOL(__mmc_claim_host); > > @@ -1000,7 +997,6 @@ void mmc_release_host(struct mmc_host *host) > > spin_unlock_irqrestore(&host->lock, flags); > > wake_up(&host->wq); > > pm_runtime_mark_last_busy(mmc_dev(host)); > > - pm_runtime_put_autosuspend(mmc_dev(host)); > > } > > } > > EXPORT_SYMBOL(mmc_release_host); > > I tried with these changes on 4.8-rc6 and I only saw 2 resets so far. > I captured the usb trace [1], just in case if you need it. > > [1] https://people.debian.org/~rrs/tmp/4.8-rc6-ulf.txt.gz The situation isn't any better. At the start of the trace, the device is in runtime suspend but there are many attempts to communicate with it, all of which fail. Then a little less than an hour after the trace started, the device was resumed. At that point it started working okay. Until there was a spontaneous disconnect. The device reconnected, but after 3 seconds it was runtime suspended again -- and the I/O attempts continued. Some time later there was another runtime resume, and the device began working again. Until another spontaneous disconnect occurred. And so on... Ulf, we really need to figure out why the autosuspends are occurring and why the I/O doesn't stop while the device is suspended. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EHCI reset missing
Please use Reply-To-All so that your message gets sent to the mailing list as well as to me. On Tue, 13 Sep 2016, Arun Thiruvanantha wrote: > Thanks Alan for your Help > > I have tried dyndbg="module ehci_hcd =p" in boot command line param, But > No effect. > > Also enabled USB_DEBUG flag but issue is not able to reproduce. > This is strange. > Can You please help me if any other way to debug I can't help if you don't say what version of the kernel you are using. Alan Stern > On Sun, Sep 11, 2016 at 9:57 PM, Alan Stern > wrote: > > > On Sun, 11 Sep 2016, Arun Thiruvanantha wrote: > > > > > Thanks for your replay. > > > > > > Reload means reset the hardware. > > > > > > these are steps doing: > > > > > > 1 Booting > > > 2 reset > > > issue will occurring after doing above steps. for more than 5 times. > > > > What kernel version are you using? > > > > > Also some time EUSB chip detecting and no issue Booting well. > > > Some time EUSB chip is not detcting and Booting will hang and reset the > > > hardware.. > > > We cannot run those dynamic_debug command When issue occurring case. > > > > You can add this to the kernel's boot command line: > > > > dyndbg="module ehci_hcd =p" > > > > That will have the same effect. > > > > Alan Stern > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote: > > Hi, > > Robin Murphy writes: > > On 07/09/16 10:55, Peter Chen wrote: > > [...] > >>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(), > >>> I think we should replace > >>> > >>> pdev->dev.dma_mask = dev->dma_mask; > >>> pdev->dev.dma_parms = dev->dma_parms; > >>> dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask); > >>> > >>> with of_dma_configure(), which has the chance to configure more than > >>> just those three, as the dma API might look into different aspects: > >>> > >>> - iommu specific configuration > >>> - cache coherency information > >>> - bus type > >>> - dma offset > >>> - dma_map_ops pointer > >>> > >>> We try to handle everything in of_dma_configure() at configuration > >>> time, and that would be the place to add anything else that we might > >>> need in the future. > >>> > >> > >> Yes, I agree with you, but just like Felipe mentioned, we also need to > >> consider PCI device, can we do something like gpiod_get_index does? Are > >> there any similar APIs like of_dma_configure for ACPI? > > > > Not yet, but Lorenzo has one in progress[1], primarily for the sake of > > abstracting away the IOMMU configuration. > > > > Robin. > > > > [1]:http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1209911.html > > not exported for drivers to use. If Lorenzo is trying to making a > matching API for ACPI systems, then it needs to follow what > of_dma_configure() is doing, and add an EXPORT_SYMBOL_GPL() That's easy enough, not sure I understand though why of_dma_deconfigure() is not exported then. The second question mark is about the dma-ranges equivalent in ACPI world; the _DMA method seems to be the exact equivalent but to the best of my knowledge it is ignored by the kernel, to really have an of_dma_configure() equivalent that's really necessary, unless we want to resort to arch specific methods (is that what x86 is currently doing ?) to retrieve/build the dma masks. Lorenzo -- 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 v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On Wed, Sep 14 2016, Mark Brown wrote: > TI do a lot of the more software managed chargers (which I suspect are > the main thing Felipe will have looked at) if that's what you're > referring to here? The device is implementing pretty much the algorithm > you're describing in that e-mail so I'm a bit confused as to what you're > saying here. Ah my mistake, sorry. When earlier you said: > It's a > current limiter intended to sit in line with the USB power lines to > ensure the system doesn't go over the maximum current draw (and also > integrates with the power source selection logic the chip has to pick > the best available power source for the system). I assumed that all it did was limit the current to number given. If it also limits the current to ensure that voltage doesn't drop unduly, then I agree with your assertion that it just needs to be told the upper limit. I hope you'll agree that other drivers might need to know the lower limit, so reporting both to all drivers is sensible. Thanks, NeilBrown signature.asc Description: PGP signature
Re: EHCI reset missing
On Wed, 14 Sep 2016, Arun Thiruvanantha wrote: > Hi Alan , > We are using linux kernel 2.6.32 version That's a very old kernel release. A lot of bugs have been fixed since it came out. Can you try using a more recent version, like 4.7? It will make debugging a lot easier. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On Wed, Sep 14, 2016 at 07:50:00PM +0200, NeilBrown wrote: > On Wed, Sep 14 2016, Mark Brown wrote: > Ah my mistake, sorry. > When earlier you said: > > It's a > > current limiter intended to sit in line with the USB power lines to > I assumed that all it did was limit the current to number given. > If it also limits the current to ensure that voltage doesn't drop > unduly, then I agree with your assertion that it just needs to be told > the upper limit. Oh, I see the gap here - the USB specific bit is only a current limiter but it works in concert with other bits of the system that try to stop the voltage from whatever supply is in use from dropping and can't be used independently of them. That's why I wasn't clear in what I said! > I hope you'll agree that other drivers might need to know the lower > limit, so reporting both to all drivers is sensible. Yes, absolutely. signature.asc Description: PGP signature
Re: [PATCH v2 5/6] ARM64: meson-gxbb-p20x: Enable USB Nodes
Martin Blumenstingl writes:
> From: Jerome Brunet
>
> Enable both gxbb USB controller and add a 5V regulator for the OTG port
> VBUS
>
> Signed-off-by: Jerome Brunet
nit: subject should have "ARM64: dts:" prefix.
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 29
>
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index ce105fe..4493bce 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -93,6 +93,18 @@
> compatible = "mmc-pwrseq-emmc";
> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> };
> +
> + usb_vbus: regulator-usb0-vbus {
nit: I like to use the signal name from the schematics for the node name
(and for regulator-name below). In the schematics, that signal is named
USB_PWR.
> + compatible = "regulator-fixed";
> +
> + regulator-name = "USB0_VBUS";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> +
> + gpio = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>;
Please add a comment above this line with the schematic signal name: USB_PWR_EN.
> + enable-active-high;
> + };
> };
Kevin
--
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
[PATCHv3] usb: musb: Fix unbalanced platform_disable
Commit a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling
for 2430 glue layer") moved PHY enable/disable calls to happen from
omap2430_musb_enable/disable(). That broke enumeration for several
devices as PM runtime in the PHY will never enable it.
The root cause of the problem is unpaired calls from musb_core.c to
musb_platform_enable/disable in musb_core.c as reported by
Andreas Kemnade .
As musb_platform_enable/disable are being called from various functions,
let's not attempt to make them paiered immediately. This would require
fixing all the callers like musb_remove.
Instead, let's first fix the regression in a minimal way by removing
the initial call to musb_platform_disable. To do that in a safe way,
we need to call the glue specific *_musb_disable() directly in the
glue layer *_musb_init() as noted by Bin Liu .
AFAIK the initial musb_platform_disable call has always been just an
attempted workaround for the 2430 glue layer announcing itself too
early before the gadgets are configured. And that issue finally
got fixed with commit a118df07f5b1 ("usb: musb: Don't set d+ high
before enable for 2430 glue layer").
Further, most of the glue layers already do a reset of the musb
controller in the *_musb_init(), so later on we may want to
consider removing the calls to *__musb_disable() where a reset is
already done.
Note that we now also need to fix the twl4030-phy accordingly making
it's PM runtime call only needed in twl4030_phy_power_on and have it
autosuspend. The cable state will keep the phy active when connected.
Cc: Hans de Goede
Cc: Kishon Vijay Abraham I
Fixes: a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling
for 2430 glue layer")
Reported-by: Andreas Kemnade
Acked-by: Andreas Kemnade
Reported-by: Laurent Pinchart
Tested-by: Laurent Pinchart
Acked-by: Laurent Pinchart
Signed-off-by: Tony Lindgren
---
I've kept the 2430 glue layer related acks as those parts did
not change. For the glue layers doing things in *_musb_disable(),
I've tested da8xx, am35x and musb_dsps glue layers.
Changes since v2:
- Added glue layer calls to *_musb_disable() from *_musb_init()
where needed as suggested by Bin
---
drivers/phy/phy-twl4030-usb.c | 4 ++--
drivers/usb/musb/am35x.c | 1 +
drivers/usb/musb/da8xx.c | 1 +
drivers/usb/musb/davinci.c| 1 +
drivers/usb/musb/musb_core.c | 1 -
drivers/usb/musb/musb_dsps.c | 1 +
drivers/usb/musb/sunxi.c | 3 +++
drivers/usb/musb/tusb6010.c | 1 +
8 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -447,8 +447,6 @@ static int twl4030_phy_power_off(struct phy *phy)
struct twl4030_usb *twl = phy_get_drvdata(phy);
dev_dbg(twl->dev, "%s\n", __func__);
- pm_runtime_mark_last_busy(twl->dev);
- pm_runtime_put_autosuspend(twl->dev);
return 0;
}
@@ -465,6 +463,8 @@ static int twl4030_phy_power_on(struct phy *phy)
twl4030_i2c_access(twl, 0);
twl->linkstat = MUSB_UNKNOWN;
schedule_delayed_work(&twl->id_workaround_work, HZ);
+ pm_runtime_mark_last_busy(twl->dev);
+ pm_runtime_put_autosuspend(twl->dev);
return 0;
}
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -381,6 +381,7 @@ static int am35x_musb_init(struct musb *musb)
msleep(5);
+ am35x_musb_disable(musb);
musb->isr = am35x_musb_interrupt;
/* clear level interrupt */
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -440,6 +440,7 @@ static int da8xx_musb_init(struct musb *musb)
rev, __raw_readl(CFGCHIP2),
musb_readb(reg_base, DA8XX_USB_CTRL_REG));
+ da8xx_musb_disable(musb);
musb->isr = da8xx_musb_interrupt;
return 0;
fail:
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -432,6 +432,7 @@ static int davinci_musb_init(struct musb *musb)
revision, __raw_readl(USB_PHY_CTRL),
musb_readb(tibase, DAVINCI_USB_CTRL_REG));
+ davinci_musb_disable(musb);
musb->isr = davinci_musb_interrupt;
return 0;
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 74fc306..f7dc3df 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2142,7 +2142,6 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
}
/* be sure interrupts are disabled before connecting ISR */
- musb_platform_disable(musb);
musb_generic_disable(musb);
/* Init IRQ workqueue before request_irq */
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
--- a/
Re: [PATCH v2 1/6] usb: dwc2: add support for Meson8b and GXBB SoCs
On 9/14/2016 9:11 AM, Kevin Hilman wrote:
> Hi John,
>
> Martin Blumenstingl writes:
>
>> From: Jerome Brunet
>>
>> Add compatible strings for amlogic Meson8b and GXBB SoCs with the
>> corresponding configuration parameters.
>>
>> Signed-off-by: Jerome Brunet
>> Signed-off-by: Martin Blumenstingl
>
> Are you OK with adding this platform for v4.9? I know you mentioned
> you're working on new bindings to replace the current way, but since
> that hasn't been posted AFAICT, it would be nice to get this merged now
> and we can help test the new bindings when you're ready.
>
> If you're OK with that, and with your Ack, I can take merge the driver
> changes through the arm-soc tree along with the rest of the DT patches.
>
Sure. Unfortunately, I wasn't able to complete it for 4.9.
You can add my acked-by on this:
Acked-by: John Youn
Regards,
John
> Kevin
>
>> ---
>> Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++
>> drivers/usb/dwc2/platform.c| 34
>> ++
>> 2 files changed, 36 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt
>> b/Documentation/devicetree/bindings/usb/dwc2.txt
>> index 20a68bf..2c30a54 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>> @@ -10,6 +10,8 @@ Required properties:
>>- "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288
>> Soc;
>>- "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX
>> SoCs;
>>- "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX
>> SoCs;
>> + - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic
>> Meson8b SoCs;
>> + - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic
>> S905 SoCs;
>>- snps,dwc2: A generic DWC2 USB controller with default parameters.
>> - reg : Should contain 1 register range (address and length)
>> - interrupts : Should contain 1 interrupt
>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>> index fc6f525..8f7b34c 100644
>> --- a/drivers/usb/dwc2/platform.c
>> +++ b/drivers/usb/dwc2/platform.c
>> @@ -181,6 +181,38 @@ static const struct dwc2_core_params params_ltq = {
>> .hibernation= -1,
>> };
>>
>> +static const struct dwc2_core_params params_amlogic = {
>> +.otg_cap= DWC2_CAP_PARAM_NO_HNP_SRP_CAPABLE,
>> +.otg_ver= -1,
>> +.dma_enable = 1,
>> +.dma_desc_enable= 0,
>> +.dma_desc_fs_enable = 0,
>> +.speed = DWC2_SPEED_PARAM_HIGH,
>> +.enable_dynamic_fifo= 1,
>> +.en_multiple_tx_fifo= -1,
>> +.host_rx_fifo_size = 512,
>> +.host_nperio_tx_fifo_size = 500,
>> +.host_perio_tx_fifo_size= 500,
>> +.max_transfer_size = -1,
>> +.max_packet_count = -1,
>> +.host_channels = 16,
>> +.phy_type = DWC2_PHY_TYPE_PARAM_UTMI,
>> +.phy_utmi_width = -1,
>> +.phy_ulpi_ddr = -1,
>> +.phy_ulpi_ext_vbus = -1,
>> +.i2c_enable = -1,
>> +.ulpi_fs_ls = -1,
>> +.host_support_fs_ls_low_power = -1,
>> +.host_ls_low_power_phy_clk = -1,
>> +.ts_dline = -1,
>> +.reload_ctl = 1,
>> +.ahbcfg = GAHBCFG_HBSTLEN_INCR8 <<
>> + GAHBCFG_HBSTLEN_SHIFT,
>> +.uframe_sched = 0,
>> +.external_id_pin_ctl= -1,
>> +.hibernation= -1,
>> +};
>> +
>> /*
>> * Check the dr_mode against the module configuration and hardware
>> * capabilities.
>> @@ -464,6 +496,8 @@ static const struct of_device_id dwc2_of_match_table[] =
>> {
>> { .compatible = "lantiq,xrx200-usb", .data = ¶ms_ltq },
>> { .compatible = "snps,dwc2", .data = NULL },
>> { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
>> +{ .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
>> +{ .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] usb: dwc2: add support for Meson8b and GXBB SoCs
On Wed, Sep 14, 2016 at 11:12 AM, John Youn wrote: > On 9/14/2016 9:11 AM, Kevin Hilman wrote: >> Hi John, >> >> Martin Blumenstingl writes: >> >>> From: Jerome Brunet >>> >>> Add compatible strings for amlogic Meson8b and GXBB SoCs with the >>> corresponding configuration parameters. >>> >>> Signed-off-by: Jerome Brunet >>> Signed-off-by: Martin Blumenstingl >> >> Are you OK with adding this platform for v4.9? I know you mentioned >> you're working on new bindings to replace the current way, but since >> that hasn't been posted AFAICT, it would be nice to get this merged now >> and we can help test the new bindings when you're ready. >> >> If you're OK with that, and with your Ack, I can take merge the driver >> changes through the arm-soc tree along with the rest of the DT patches. >> > > Sure. Unfortunately, I wasn't able to complete it for 4.9. > > You can add my acked-by on this: > > Acked-by: John Youn Great, thanks! I assume you're OK with PATCH 2/2 for the bindings as well (at least for now until you rework them?) Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] usb: dwc2: add support for Meson8b and GXBB SoCs
On 9/14/2016 11:17 AM, Kevin Hilman wrote: > On Wed, Sep 14, 2016 at 11:12 AM, John Youn wrote: >> On 9/14/2016 9:11 AM, Kevin Hilman wrote: >>> Hi John, >>> >>> Martin Blumenstingl writes: >>> From: Jerome Brunet Add compatible strings for amlogic Meson8b and GXBB SoCs with the corresponding configuration parameters. Signed-off-by: Jerome Brunet Signed-off-by: Martin Blumenstingl >>> >>> Are you OK with adding this platform for v4.9? I know you mentioned >>> you're working on new bindings to replace the current way, but since >>> that hasn't been posted AFAICT, it would be nice to get this merged now >>> and we can help test the new bindings when you're ready. >>> >>> If you're OK with that, and with your Ack, I can take merge the driver >>> changes through the arm-soc tree along with the rest of the DT patches. >>> >> >> Sure. Unfortunately, I wasn't able to complete it for 4.9. >> >> You can add my acked-by on this: >> >> Acked-by: John Youn > > Great, thanks! I assume you're OK with PATCH 2/2 for the bindings as > well (at least for now until you rework them?) > > Kevin > Do you mean PATCH 2/6 from this series? It doesn't seem to add or remove any bindings in dwc2 so I'm fine with it. Regards, John -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] usb: dwc2: add support for Meson8b and GXBB SoCs
On Wed, Sep 14, 2016 at 11:26 AM, John Youn wrote: > On 9/14/2016 11:17 AM, Kevin Hilman wrote: >> On Wed, Sep 14, 2016 at 11:12 AM, John Youn wrote: >>> On 9/14/2016 9:11 AM, Kevin Hilman wrote: Hi John, Martin Blumenstingl writes: > From: Jerome Brunet > > Add compatible strings for amlogic Meson8b and GXBB SoCs with the > corresponding configuration parameters. > > Signed-off-by: Jerome Brunet > Signed-off-by: Martin Blumenstingl Are you OK with adding this platform for v4.9? I know you mentioned you're working on new bindings to replace the current way, but since that hasn't been posted AFAICT, it would be nice to get this merged now and we can help test the new bindings when you're ready. If you're OK with that, and with your Ack, I can take merge the driver changes through the arm-soc tree along with the rest of the DT patches. >>> >>> Sure. Unfortunately, I wasn't able to complete it for 4.9. >>> >>> You can add my acked-by on this: >>> >>> Acked-by: John Youn >> >> Great, thanks! I assume you're OK with PATCH 2/2 for the bindings as >> well (at least for now until you rework them?) >> >> Kevin >> > > Do you mean PATCH 2/6 from this series? Yes. > It doesn't seem to add or remove any bindings in dwc2 so I'm fine with > it. Thanks. Kevin -- 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: [GIT PULL] usb: patches for v4.9 merge window
On Wed, Sep 14, 2016 at 03:00:49PM +0300, Felipe Balbi wrote: > > Hi Greg, > > Here's my pull request for v4.9 merge window. Patches have been tested > with plataforms I have around (where applicable) and have also been > soaking in linux-next for a while. > > Let me know if you want anything to be changed. > > The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468: > > Linux 4.8-rc3 (2016-08-21 16:14:10 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/usb-for-v4.9 > > for you to fetch changes up to e6be244a83211f3a9daaf5e29ee97fe0bf1efe5a: > > usb: gadget: uvc: add V4L2 dependency (2016-09-13 09:29:08 +0300) Looks good, pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VL805 USB 3.0 does not see connected devices (only on x86_64) (x86 is ok)
2016-09-14 15:43 GMT+03:00 Oliver Neukum : > On Wed, 2016-09-14 at 15:22 +0300, c400 wrote: >> may be i can help to test something else? I am ready and have enough free >> time > > You may need to mount debugfs at /sys/kernel/debug > > HTH > Oliver > > mount -t debugfs none /sys/kernel/debug/ mount: none is already mounted or /sys/kernel/debug busy ls /sys/kernel/debug/ acpi extfrag mce sleep_time bcache fault_around_bytes nfsdsuspend_stats bdi hid pm_qos tracing boot_params hwpoisonpstate_snb usb dma_buf intel_powerclampras wakeup_sources dri kprobes regmap x86 2016-09-14 15:22 GMT+03:00 c400 : > may be i can help to test something else? I am ready and have enough free time > > 2016-09-12 20:44 GMT+03:00 c400 : >> [182047.000570] xhci_hcd :02:00.0: remove, state 4 >> [182047.000577] usb usb4: USB disconnect, device number 1 >> [182047.023980] xhci_hcd :02:00.0: Host not halted after 16000 >> microseconds. >> [182047.023982] xhci_hcd :02:00.0: Host controller not halted, >> aborting reset. >> [182047.023996] xhci_hcd :02:00.0: USB bus 4 deregistered >> [182047.024103] xhci_hcd :02:00.0: remove, state 1 >> [182047.024108] usb usb3: USB disconnect, device number 1 >> [182047.024320] xhci_hcd :02:00.0: USB bus 3 deregistered >> [182058.617466] xhci_hcd :02:00.0: xHCI Host Controller >> [182058.617556] xhci_hcd :02:00.0: new USB bus registered, >> assigned bus number 3 >> [182058.640820] xhci_hcd :02:00.0: Host not halted after 16000 >> microseconds. >> [182058.640822] xhci_hcd :02:00.0: can't setup: -110 >> [182058.640824] xhci_hcd :02:00.0: USB bus 3 deregistered >> [182058.640944] xhci_hcd :02:00.0: init :02:00.0 fail, -110 >> [182058.640947] xhci_hcd: probe of :02:00.0 failed with error -110 >> >> can not see my flash inserted into the USB >> >> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control >> Do not have such folder >> (i`ve recompiled my kernel (make defconfig) with some small changes. >> may be i need to enable something in kernelt? -- 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: VL805 USB 3.0 does not see connected devices (only on x86_64) (x86 is ok)
On Wed, 14 Sep 2016, c400 wrote: > 2016-09-14 15:43 GMT+03:00 Oliver Neukum : > > On Wed, 2016-09-14 at 15:22 +0300, c400 wrote: > >> may be i can help to test something else? I am ready and have enough free > >> time Did you try Mathias's suggestion of forcing DMA to use 32 bits? After unloading the xhci-pci and xhci-hcd modules: sudo modprobe xhci_hcd quirks=0x00800090 sudo modprobe xhci_pci > > You may need to mount debugfs at /sys/kernel/debug > > > > HTH > > Oliver > > > > > mount -t debugfs none /sys/kernel/debug/ > mount: none is already mounted or /sys/kernel/debug busy > > ls /sys/kernel/debug/ > > acpi extfrag mce sleep_time > bcache fault_around_bytes nfsdsuspend_stats > bdi hid pm_qos tracing > boot_params hwpoisonpstate_snb usb > dma_buf intel_powerclampras wakeup_sources > dri kprobes regmap x86 > > 2016-09-14 15:22 GMT+03:00 c400 : > > may be i can help to test something else? I am ready and have enough free > > time > > > > 2016-09-12 20:44 GMT+03:00 c400 : > >> [182047.000570] xhci_hcd :02:00.0: remove, state 4 > >> [182047.000577] usb usb4: USB disconnect, device number 1 > >> [182047.023980] xhci_hcd :02:00.0: Host not halted after 16000 > >> microseconds. > >> [182047.023982] xhci_hcd :02:00.0: Host controller not halted, > >> aborting reset. > >> [182047.023996] xhci_hcd :02:00.0: USB bus 4 deregistered > >> [182047.024103] xhci_hcd :02:00.0: remove, state 1 > >> [182047.024108] usb usb3: USB disconnect, device number 1 > >> [182047.024320] xhci_hcd :02:00.0: USB bus 3 deregistered > >> [182058.617466] xhci_hcd :02:00.0: xHCI Host Controller > >> [182058.617556] xhci_hcd :02:00.0: new USB bus registered, > >> assigned bus number 3 > >> [182058.640820] xhci_hcd :02:00.0: Host not halted after 16000 > >> microseconds. > >> [182058.640822] xhci_hcd :02:00.0: can't setup: -110 > >> [182058.640824] xhci_hcd :02:00.0: USB bus 3 deregistered > >> [182058.640944] xhci_hcd :02:00.0: init :02:00.0 fail, -110 > >> [182058.640947] xhci_hcd: probe of :02:00.0 failed with error -110 > >> > >> can not see my flash inserted into the USB > >> > >> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control > >> Do not have such folder > >> (i`ve recompiled my kernel (make defconfig) with some small changes. > >> may be i need to enable something in kernelt? You need to enable CONFIG_DYNAMIC_DEBUG. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
On Wed, Sep 14, 2016 at 10:37 AM, Philipp Zabel wrote: > Am Dienstag, den 13.09.2016, 17:59 -0700 schrieb Kevin Hilman: >> Martin Blumenstingl writes: >> >> > On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel >> > wrote: >> >> [...] >> >> >>> I added Philipp and Hans to this thread - maybe they can comment on this. >> >>> To sum it up, our problem is: >> >>> - there are two separate USB PHYs on Meson GXBB >> >>> - both are sharing the same reset line (provided by the reset-meson >> >>> driver) >> >>> - during initialization of the PHYs we must only call >> >>> reset_control_reset(rstc) once (if we do it for the first *and* second >> >>> PHY then the first PHY gets confused once the second PHY uses the >> >>> reset because the first PHY's state is reset as well) >> >> >> >> If you have an initially asserted reset line and you can enable the >> >> first module by deasserting the reset via reset_control_deassert (and >> >> reset_control_assert to signal when the module may be disabled again >> >> after use), shared resets are for you. >> >> >> >> If you need a reset pulse or have no direct control over the reset line, >> >> (device_reset), the reset framework currently has no solution for this. >> >> The ugly thing about reset_control_once would be that it can't re-reset >> >> modules when unloading and reloading driver modules. >> > >> > The corresponding reset driver in question is reset-meson, which only >> > implements reset (assert/deassert are not implemented). However, I >> > don't know if this is due to hardware design. >> > I think the hardware implements the latter, but maybe Neil can give >> > more information here (I currently don't have access to my board so I >> > cannot test how the hardware actually behaves). >> >> It's implemented that way because the hardware only supports a reset >> pulse. > > Would it be possible to bring down both PHYs drivers, pull the reset > line once, and then bring the drivers back up again? I guess that this is the rmmod case: I haven't tested it yet but that should work (even with the current code and .dts) -- 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: VL805 USB 3.0 does not see connected devices (only on x86_64) (x86 is ok)
On Wed, 14 Sep 2016, c400 wrote: > yep! enabling You need to enable CONFIG_DYNAMIC_DEBUG. did the trick! > here is my new dmesg output: Did you use the 32-bit DMA quirks option for xhci_hcd? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
On Wed, Sep 14, 2016 at 10:37 AM, Philipp Zabel wrote:
> Am Dienstag, den 13.09.2016, 20:38 +0200 schrieb Martin Blumenstingl:
>> Hi Philipp,
>>
>> On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel
>> wrote:
>> > Hi Martin,
>> >
>> > Am Freitag, den 09.09.2016, 22:36 +0200 schrieb Martin Blumenstingl:
>> >> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman wrote:
>> >> > Martin Blumenstingl writes:
>> >> >
>> >> >> On Thu, Sep 8, 2016 at 10:53 PM, Ben Dooks
>> >> >> wrote:
>> >> >>> On 08/09/16 21:42, Kevin Hilman wrote:
>> >>
>> >> Ben Dooks writes:
>> >>
>> >> > On 08/09/16 20:52, Martin Blumenstingl wrote:
>> >> >>
>> >> >> On Thu, Sep 8, 2016 at 9:35 PM, Kevin Hilman
>> >> >> wrote:
>> >>
>> >> + phy = devm_phy_create(&pdev->dev, NULL,
>> >> &phy_meson_usb2_ops);
>> >> + if (IS_ERR(phy)) {
>> >> + dev_err(&pdev->dev, "failed to create PHY\n");
>> >> + return PTR_ERR(phy);
>> >> + }
>> >> +
>> >> + if (usb_reset_refcnt++ == 0) {
>> >> + ret = device_reset(&pdev->dev);
>> >> + if (ret) {
>> >> + dev_err(&phy->dev, "Failed to reset USB
>> >> PHY\n");
>> >> + return ret;
>> >> + }
>> >> + }
>> >> >>>
>> >> >>>
>> >> >>> The ref count + reset here looks like something that could/should
>> >> >>> be
>> >> >>> handled in a runtime PM callback.
>> >> >>
>> >> >> Unfortunately that doesn't work (as Jerome found out) because both
>> >> >> PHYs are sharing the same reset line.
>> >> >> So if the second PHY would call device_reset then it would also
>> >> >> reset
>> >> >> the first PHY!
>> >> >>
>> >> >> There's a comment above the declaration of usb_reset_refcnt which
>> >> >> tries to explain this:
>> >> >> "The PHYs are sharing a common reset line -> we are only allowed to
>> >> >> reset once for all PHYs."
>> >> >> Maybe I should move this comment to the "if (usb_reset_refcnt++ ==
>> >> >> 0)
>> >> >> {" line to make it easier to see?
>> >> >>
>> >> >
>> >> > pm-runtime has refcounting in it. When one of the nodes turns on,
>> >> > the pm-runtime will call your driver to say there is a user when
>> >> > this first use turns up.
>> >> >
>> >> > If all the sub-phys turn off and drop their refcount then the driver
>> >> > is called to say there are no more users and you can go to sleep.
>> >>
>> >>
>> >> After a chat w/Martin on IRC, It turns out runtime PM wont help here.
>> >>
>> >> The reason is because there are physically two PHY devices[1].
>> >> Those 2
>> >> devices will be treated independely by runtime PM, and have separate
>> >> use-counting, which means doing what I proposed would cause a reset
>> >> to
>> >> happen when either device was probed.
>> >>
>> >> So, I think it's OK as it is.
>> >> >>>
>> >> >>>
>> >> >>> Surely you can do pm_runtime_get/put on the phy's parent platform
>> >> >>> device and do it that way?
>> >> >> could you please be more specific with that (do you mean
>> >> >> pdev->dev.parent)?
>> >> >> so we would use pm_runtime_{get_sync,put} with the parent, while we
>> >> >> would still define the runtime_resume in our driver.
>> >> >
>> >> > You'd also need to do get/put on the children, but yes, that's what Ben
>> >> > is suggesting.
>> >> >
>> >> > However, the problem with all of the solutions proposed (runtime PM ones
>> >> > included) is that we're forcing a board-specific design issue (2 devices
>> >> > sharing a reset line) into a driver that should not have any
>> >> > board-specific assumptions in it.
>> >> >
>> >> > For example, if this driver is used on another platform where different
>> >> > PHYs have different reset lines, then one of them (the unlucky one who
>> >> > is not probed first) will never get reset. So any form of per-device
>> >> > ref-counting is not a portable solution.
>> >> indeed, so in simple words we would need something like
>> >> reset_control_do_once(rstc, RESET/ASSERT/DEASSERT) which would
>> >> remember internally if any action has already been executed: if not it
>> >> does a _reset, _assert or _deassert and otherwise it does nothing.
>> >>
>> >> > I'm not sure yet how the reset framework is supposed to handle shared
>> >> > reset lines, but that needs some investigation. I quick glance and it
>> >> > seems that reset controllers can have shared lines, so that should be
>> >> > investigated.
>> >> I added Philipp and Hans to this thread - maybe they can comment on this.
>> >> To sum it up, our problem is:
>> >> - there are two separate USB PHYs on Meson GXBB
>> >> - both are sharing the same reset line (provided by the reset-meson
>> >> driver)
>> >> - during initialization
Re: [PATCH v2 3/6] phy: meson: add USB2 PHY support for Meson8b and GXBB
On Sun, Sep 11, 2016 at 3:41 PM, Martin Blumenstingl wrote: > This is a new driver for the USB PHY found in Meson8b and GXBB SoCs. > > Signed-off-by: Martin Blumenstingl > Signed-off-by: Jerome Brunet > Tested-by: Kevin Hilman > --- > drivers/phy/Kconfig | 11 ++ > drivers/phy/Makefile | 1 + > drivers/phy/phy-meson-usb2.c | 280 > +++ > 3 files changed, 292 insertions(+) > create mode 100644 drivers/phy/phy-meson-usb2.c > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 19bff3a..6ad87ec 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -453,4 +453,15 @@ config PHY_NS2_PCIE > help > Enable this to support the Broadcom Northstar2 PCIe PHY. > If unsure, say N. > + > +config PHY_MESON_USB2 > + tristate "Meson USB2 PHY driver" > + default ARCH_MESON > + depends on OF && (ARCH_MESON || COMPILE_TEST) > + select GENERIC_PHY as pointed out by Arnd Bergmann (see [0]) this is missing a "select USB_COMMON", just like the PHY_SUN4I_USB and PHY_SUN9I_USB drivers as we use of_usb_get_dr_mode_by_phy() to get the mode of the USB controller (as the PHY needs special configuration for host-mode). I will send an update on Sunday. Regards, Martin [0] http://marc.info/?l=linux-usb&m=147386117604824&w=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
Re: [PATCH 3/3] usb: gadget: default U1/U2 exit latencies to maximum
On 8/31/2016 1:37 PM, John Youn wrote:
> On 8/31/2016 12:47 PM, Felipe Balbi wrote:
>>
>> Hi John,
>>
>> John Youn writes:
>>> On 8/31/2016 2:38 AM, Felipe Balbi wrote:
If we don't know what are the actual U1/U2 exit
latencies from the UDC, we're better off using
maximum latencies as default. This should avoid
any problems with too frequent U1/U2 entry.
Signed-off-by: Felipe Balbi
---
include/linux/usb/gadget.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3667d667cab1..20cb590c658e 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -276,11 +276,19 @@ static inline void usb_ep_fifo_flush(struct usb_ep
*ep)
/*-*/
+/**
+ * struct usb_dcd_config_params - Default U1/U2 exit latencies
+ * @bU1DevExitLat: U1 Exit Latency in us
+ * @bU2DevExitLat: U2 Exit Latency in us
+ *
+ * Note that we will be setting U1/U2 exit latencies to their maximum
+ * by default if no value is passed by the UDC Driver.
+ */
struct usb_dcd_config_params {
__u8 bU1DevExitLat;/* U1 Device exit Latency */
-#define USB_DEFAULT_U1_DEV_EXIT_LAT 0x01/* Less then 1 microsec
*/
+#define USB_DEFAULT_U1_DEV_EXIT_LAT 10 /* us */
__le16 wU2DevExitLat; /* U2 Device exit Latency */
-#define USB_DEFAULT_U2_DEV_EXIT_LAT 0x1F4 /* Less then 500
microsec */
+#define USB_DEFAULT_U2_DEV_EXIT_LAT 2047 /* us */
};
>>>
>>> Hi Felipe,
>>>
>>> Speaking of this, how would you feel about adding module parameters in
>>> the dwc3-pci to set these? And we also have several more settings in
>>> our internal tree that we need for IP validation and debugging.
>>>
>>> As you know the IP is highly configurable, and we do much of the
>>> testing against these configurations via software settings. And our
>>> validation platform is not a typical platform. Basically we have a
>>> single platform, but the instantiated IP and PHY could be configured
>>> in any way so it could need different values passed in for
>>> testing. Like the U1/U2 exit latencies, LPM NYET threshold, HIRD,
>>> USB2/3 SUSPHY, LPM sleep mode, GFLADJ, etc.
>>>
>>> And some things that are automatically detected we need to restrict or
>>> disable to get full coverage. Such as disabling U1/U2 and LPM, maximum
>>> speed, dr_mode, NUMP, RX thresholding, RX thresholding packet count.
>>>
>>> I know module parameters are typically frowned upon so do you
>>> recommend another approach?
>>
>> I completely understand the situation. Module parameters are, well,
>> rather unsophisticated. FPGA validation is, however, a 'peculiar' use
>> case.
>>
>> I want to avoid module parameters as much as possible, but apart from
>> module parameters, the only thing I can think of is a specific
>> sub-directory on debugfs which only gets compile if EXPERT &&
>> DWC3_VALIDATION_MODE or whatever.
>>
>> Would debugfs work for you? The only problem is for things which get
>> discovered during probe()
>
> Yes that's the problem, otherwise I'd be fine with debugfs. Almost
> everything we need is initialized on probe. I thought of maybe
> refactoring the dwc3 code so that this doesn't have to happen on probe
> and we can trigger a "module reset" or something. But that is not
> exactly clean either.
>
> Regards,
> John
>
Does it seem reasonable to add module params to the PCI driver for
this use case? At least until/if there is some better solution. We can
guard it with a config option if necessary.
We want to do a similar thing with dwc2 as well.
Regards,
John
--
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: host: inherit dma configuration from parent dev
On Wednesday, September 14, 2016 5:31:36 PM CEST Lorenzo Pieralisi wrote: > On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote: > > > > Hi, > > > > Robin Murphy writes: > > > On 07/09/16 10:55, Peter Chen wrote: > > > [...] > > >>> Regarding the DMA configuration that you mention in > > >>> ci_hdrc_add_device(), > > >>> I think we should replace > > >>> > > >>> pdev->dev.dma_mask = dev->dma_mask; > > >>> pdev->dev.dma_parms = dev->dma_parms; > > >>> dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask); > > >>> > > >>> with of_dma_configure(), which has the chance to configure more than > > >>> just those three, as the dma API might look into different aspects: > > >>> > > >>> - iommu specific configuration > > >>> - cache coherency information > > >>> - bus type > > >>> - dma offset > > >>> - dma_map_ops pointer > > >>> > > >>> We try to handle everything in of_dma_configure() at configuration > > >>> time, and that would be the place to add anything else that we might > > >>> need in the future. > > >>> > > >> > > >> Yes, I agree with you, but just like Felipe mentioned, we also need to > > >> consider PCI device, can we do something like gpiod_get_index does? Are > > >> there any similar APIs like of_dma_configure for ACPI? > > > > > > Not yet, but Lorenzo has one in progress[1], primarily for the sake of > > > abstracting away the IOMMU configuration. > > > > > > Robin. > > > > > > [1]:http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1209911.html > > > > not exported for drivers to use. If Lorenzo is trying to making a > > matching API for ACPI systems, then it needs to follow what > > of_dma_configure() is doing, and add an EXPORT_SYMBOL_GPL() > > That's easy enough, not sure I understand though why > of_dma_deconfigure() is not exported then. The second question mark > is about the dma-ranges equivalent in ACPI world; the _DMA method > seems to be the exact equivalent but to the best of my knowledge > it is ignored by the kernel, to really have an of_dma_configure() > equivalent that's really necessary, unless we want to resort to > arch specific methods (is that what x86 is currently doing ?) to > retrieve/build the dma masks. Please see the follow-up emails after my proposed patch: if we add a pointer to the device that firmware knows about in the USB core layer, there is no longer a problem to be solved and the DMA operations will do the right thing. Arnd -- 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: VL805 USB 3.0 does not see connected devices (only on x86_64) (x86 is ok)
XHCI_NO_64BIT_SUPPORT can't find such flag in my kernel config. May be you can help me to find it in menuconfig tree? 2016-09-14 23:25 GMT+03:00 c400 : > yep! enabling You need to enable CONFIG_DYNAMIC_DEBUG. did the trick! > here is my new dmesg output: > > > 2016-09-14 22:39 GMT+03:00 c400 : >> 2016-09-14 15:43 GMT+03:00 Oliver Neukum : >>> On Wed, 2016-09-14 at 15:22 +0300, c400 wrote: may be i can help to test something else? I am ready and have enough free time >>> >>> You may need to mount debugfs at /sys/kernel/debug >>> >>> HTH >>> Oliver >>> >>> >> mount -t debugfs none /sys/kernel/debug/ >> mount: none is already mounted or /sys/kernel/debug busy >> >> ls /sys/kernel/debug/ >> >> acpi extfrag mce sleep_time >> bcache fault_around_bytes nfsdsuspend_stats >> bdi hid pm_qos tracing >> boot_params hwpoisonpstate_snb usb >> dma_buf intel_powerclampras wakeup_sources >> dri kprobes regmap x86 >> >> 2016-09-14 15:22 GMT+03:00 c400 : >>> may be i can help to test something else? I am ready and have enough free >>> time >>> >>> 2016-09-12 20:44 GMT+03:00 c400 : [182047.000570] xhci_hcd :02:00.0: remove, state 4 [182047.000577] usb usb4: USB disconnect, device number 1 [182047.023980] xhci_hcd :02:00.0: Host not halted after 16000 microseconds. [182047.023982] xhci_hcd :02:00.0: Host controller not halted, aborting reset. [182047.023996] xhci_hcd :02:00.0: USB bus 4 deregistered [182047.024103] xhci_hcd :02:00.0: remove, state 1 [182047.024108] usb usb3: USB disconnect, device number 1 [182047.024320] xhci_hcd :02:00.0: USB bus 3 deregistered [182058.617466] xhci_hcd :02:00.0: xHCI Host Controller [182058.617556] xhci_hcd :02:00.0: new USB bus registered, assigned bus number 3 [182058.640820] xhci_hcd :02:00.0: Host not halted after 16000 microseconds. [182058.640822] xhci_hcd :02:00.0: can't setup: -110 [182058.640824] xhci_hcd :02:00.0: USB bus 3 deregistered [182058.640944] xhci_hcd :02:00.0: init :02:00.0 fail, -110 [182058.640947] xhci_hcd: probe of :02:00.0 failed with error -110 can not see my flash inserted into the USB echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control Do not have such folder (i`ve recompiled my kernel (make defconfig) with some small changes. may be i need to enable something in kernelt? -- 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: use of_usb_get_dr_mode_by_phy() inline helper without USB
On Wednesday, September 14, 2016 3:51:01 PM CEST Arnd Bergmann wrote:
> We have had two new PHY drivers call of_usb_get_dr_mode_by_phy()
> recently without having a dependency on CONFIG_USB_COMMON, resulting
> in a link error:
>
> ERROR: "of_usb_get_dr_mode_by_phy" [drivers/phy/phy-meson-usb2.ko] undefined!
>
> I fixed up the first one (sun4i) by adding the dependency, but
> if we get more of this, it's probably better to allow the PHY
> drivers to build without the dependency.
>
> This changes the guard around declarations so we only refer to
> them when both CONFIG_OF and CONFIG_USB_COMMON are enabled,
> which is the right thing for all of the first calls but not the
> one that already has a correct check for USB_SUPPORT rather than
> USB_COMMON.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 5ed935458519 ("phy: meson: add USB2 PHY support for Meson8b and GXBB")
>
Please hold off applying for now, the randconfig builder came up with a
new build failure after this one, I have to investigate tomorrow.
Arnd
--
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 v4 22/22] phy: Add support for Qualcomm's USB HS phy
On Wed, Sep 14, 2016 at 10:42:50AM -0700, Stephen Boyd wrote: > > > > > > Hmm.. maybe the confusion is in which registers we should be able to > > > access? Are we talking about the ULPI viewport MMIO register space or > > > the ULPI registers that we access through the viewport? I have a > > > hw_phymode_configure() inside of of ci_ulpi_init() so that the > > > identification registers through the ULPI viewport read properly > > > (assuming there aren't other power requirements like regulators). If we > > > don't set the portsc.pts before using the viewport, the viewport doesn't > > > work and reads timeout. So we really don't touch the ULPI registers > > > except for the scratch space and the id registers until after the phy is > > > properly powered on with clks and regulators, because the only place we > > > touch them after doing the id checking is in this phy driver in > > > qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where > > > we don't know which device driver to probe because the phy needs to be > > > powered on to read the id registers to know which device driver to use > > > by using DT to match up device drivers instead. > > > > > > [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf > > > > Ok, ulpi phy works like USB device on USB bus which create device at > > runtime. So, like some hard-wired USB devices, it may needs power > > sequence too, otherwise, how it knows which driver can loads. > > > > Yes. We use the DT compatible string to ignore any issues with reading > the device ids when the device is powered off. Unlike USB though, we > have device drivers for the ULPI PHYs that do the power sequencing along > with other initializations, so using a common pwrseq layer seems like > overkill just so we can read the id registers. If the attempt to read id registers will not hang the system, it can work. Like the case [1], without PHY ref_clk, it will hang when configure PHY mode (visit portsc.pts), it has no chance to read id registers. So, I still think the ULPI bus driver needs to do power sequence for its children, unless you have some place to open the ref_clk. > > Are there any concerns with this patch? Or can they be reapplied? For this patch, it is ok for me. [1] http://www.spinics.net/lists/linux-usb/msg146336.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] usb: serial: update CH34x driver in drivers/usb/serial
On Thu, Sep 15, 2016 at 12:03:48AM +0100, Aidan Thornton wrote: > On 24 Jun 2016 16:10, "Greg KH" wrote: > > > > On Fri, Jun 24, 2016 at 01:42:24PM +0800, WCH Tech Group wrote: > > > There are several reasons why we decided to revoke the old one after > > > communicating with the author of > > > ch341.c (Frank A Kingswood ), first of > all > > > we want the driver to support both ch341 and > > > ch340 chips, so we changed the driver name from "ch341.c" to "ch34x.c", > > > > No need to rename the driver to support multiple chips. Keep it the > > same name, and just add the new device support. That's how we do it for > > lots and lots of Linux drivers, the name doesn't really matter that > > much (look at the option.c driver for one such example.) > > > > > secondly the new driver and old one are coded > > > by different authors, in fact there's no connection between them. > > > > Ok, but the functionality is the same, so please just fix up the > > existing driver to add support for the new device, and fix any existing > > bugs. > > > > In Linux you don't get to just delete a working driver, you have to > > evolve code over time, sending patches that do one logical thing at a > > time so that people can properly review them. Your patch is not how > > this is supposed to happen at all. > > > > So please just break up your changes into small logical ones, and send a > > series of patches adding the new device support and fix up any known > > bugs. > > > > After that is all done, if you _really_ want to rename the driver, then > > we can discuss that, but first do the work to evolve the driver, as that > > is much more difficult. > > > > thanks, > > > > greg k-h > > It looks like someone by the name of Grigori Goronzy (CCed) had a patch series > or four attempting to do this that just never went anywhere like all the other > attempts. Might be worth someone talking to him or looking at his patches. Do you have a pointer to those patches on the mailing list? Why were they rejected? > Seriously, this is... I was considering trying to get parity support merged so > I don't have to keep patching it in, but it feels like a total waste of effort > at this point after seeing all the other attempts. No reason you can't take those patches and fix them up and resend them, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] usb: gadget: default U1/U2 exit latencies to maximum
Hi,
John Youn writes:
>>> John Youn writes:
On 8/31/2016 2:38 AM, Felipe Balbi wrote:
> If we don't know what are the actual U1/U2 exit
> latencies from the UDC, we're better off using
> maximum latencies as default. This should avoid
> any problems with too frequent U1/U2 entry.
>
> Signed-off-by: Felipe Balbi
> ---
> include/linux/usb/gadget.h | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 3667d667cab1..20cb590c658e 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -276,11 +276,19 @@ static inline void usb_ep_fifo_flush(struct usb_ep
> *ep)
>
>
> /*-*/
>
> +/**
> + * struct usb_dcd_config_params - Default U1/U2 exit latencies
> + * @bU1DevExitLat: U1 Exit Latency in us
> + * @bU2DevExitLat: U2 Exit Latency in us
> + *
> + * Note that we will be setting U1/U2 exit latencies to their maximum
> + * by default if no value is passed by the UDC Driver.
> + */
> struct usb_dcd_config_params {
> __u8 bU1DevExitLat;/* U1 Device exit Latency */
> -#define USB_DEFAULT_U1_DEV_EXIT_LAT 0x01/* Less then 1 microsec
> */
> +#define USB_DEFAULT_U1_DEV_EXIT_LAT 10 /* us */
> __le16 wU2DevExitLat; /* U2 Device exit Latency */
> -#define USB_DEFAULT_U2_DEV_EXIT_LAT 0x1F4 /* Less then 500
> microsec */
> +#define USB_DEFAULT_U2_DEV_EXIT_LAT 2047 /* us */
> };
>
>
>
Hi Felipe,
Speaking of this, how would you feel about adding module parameters in
the dwc3-pci to set these? And we also have several more settings in
our internal tree that we need for IP validation and debugging.
As you know the IP is highly configurable, and we do much of the
testing against these configurations via software settings. And our
validation platform is not a typical platform. Basically we have a
single platform, but the instantiated IP and PHY could be configured
in any way so it could need different values passed in for
testing. Like the U1/U2 exit latencies, LPM NYET threshold, HIRD,
USB2/3 SUSPHY, LPM sleep mode, GFLADJ, etc.
And some things that are automatically detected we need to restrict or
disable to get full coverage. Such as disabling U1/U2 and LPM, maximum
speed, dr_mode, NUMP, RX thresholding, RX thresholding packet count.
I know module parameters are typically frowned upon so do you
recommend another approach?
>>>
>>> I completely understand the situation. Module parameters are, well,
>>> rather unsophisticated. FPGA validation is, however, a 'peculiar' use
>>> case.
>>>
>>> I want to avoid module parameters as much as possible, but apart from
>>> module parameters, the only thing I can think of is a specific
>>> sub-directory on debugfs which only gets compile if EXPERT &&
>>> DWC3_VALIDATION_MODE or whatever.
>>>
>>> Would debugfs work for you? The only problem is for things which get
>>> discovered during probe()
>>
>> Yes that's the problem, otherwise I'd be fine with debugfs. Almost
>> everything we need is initialized on probe. I thought of maybe
>> refactoring the dwc3 code so that this doesn't have to happen on probe
>> and we can trigger a "module reset" or something. But that is not
>> exactly clean either.
>>
>> Regards,
>> John
>>
>
> Does it seem reasonable to add module params to the PCI driver for
> this use case? At least until/if there is some better solution. We can
> guard it with a config option if necessary.
module parameters are user-space ABI. Once added, we can't easily
remove. I've been considering if kprobes could be used to change stuff
like this.
module parameters also feel like a big, big hammer to hit a tiny nail
head. I don't want to add any module parameters for stuff like this. And
since you've been pushing for them for a while, it only shows that
you're only concerned about your use case ;-)
Remember that module parameters are 'global', every instance of
dwc3-pci.ko/dwc3.ko will behave with the same set of module parameters.
Sorry, but I have to say 'no' again. module parameters are not an
option; and I'd strongly suggest you don't do it for dwc2 either because
it'll make maintaining the driver a lot more difficult.
--
balbi
signature.asc
Description: PGP signature
