Re: [PATCH v6] usb: common: add API to set usb otg capabilities by device tree
On Mon, 22 Jun 2015 22:36:40 +0800
Li Jun wrote:
> On Mon, Jun 22, 2015 at 04:32:56PM +0300, Roger Quadros wrote:
> > On Mon, 22 Jun 2015 18:45:37 +0800
> > Li Jun wrote:
> >
> > > On Mon, Jun 22, 2015 at 12:41:22PM +0300, Roger Quadros wrote:
> > > > On Thu, 18 Jun 2015 21:37:04 +0800
> > > > Li Jun wrote:
> > > >
> > > > > On Thu, Jun 18, 2015 at 03:07:48PM +0300, Roger Quadros wrote:
> > > > > > On Thu, 18 Jun 2015 16:47:48 +0800
> > > > > > Li Jun wrote:
> > > > > >
> > > > > > > On Thu, Jun 18, 2015 at 10:36:50AM +0300, Roger Quadros wrote:
> > > > > > > > Lin,
> > > > > > > >
> > > > > > > > You can use --in-reply-to "message id of v5 of this path" so
> > > > > > > > that it appears together
> > > > > > > > with the other patches in peoples mailboxes.
> > > > > > > >
> > > > > > > > > + * the passed properties in DT.
> > > > > > > > > + * @np: Pointer to the given device_node
> > > > > > > > > + * @otg_caps: Pointer to the target usb_otg_caps to be set
> > > > > > > > > + *
> > > > > > > > > + * The function gets and sets the otg capabilities
> > > > > > > > > + */
> > > > > > > > > +void of_usb_set_otg_caps(struct device_node *np, struct
> > > > > > > > > usb_otg_caps *otg_caps)
> > > > > > > > > +{
> > > > > > > > > + u32 otg_rev;
> > > > > > > > > +
> > > > > > > > > + if (!otg_caps)
> > > > > > > > > + return;
> > > > > > > > > +
> > > > > > > > > + if (!of_property_read_u32(np, "otg-rev", &otg_rev))
> > > > > > > > > + otg_caps->otg_rev = otg_rev;
> > > > > > > >
> > > > > > > > should we check if otg_rev is in correct format?
> > > > > > > > anything non BCD and greater than 0x is invalid.
> > > > > > > >
> > > > > > > > Also if otg-rev is not passed then we need to treat it as legacy
> > > > > > > > platform right? How is this taken care of?
> > > > > > > >
> > > > > > > Missed this comment
> > > > > > > This handling rely on controller driver, cannot decided here.
> > > > > > > There are several cases we need take care:
> > > > > > > 1) otg-rev is not passed, but all 3 disable flags passed, this is
> > > > > > > valid, means user want to disable whole OTG, so only "otg-rev"
> > > > > > > not passed, cannot treat as legacy platform.
> > > > > > > 2) Legacy platform means: none of 4 properties is present.
> > > > > >
> > > > > > Right. Plus controller drivers that are not updated to use these
> > > > > > otg_caps
> > > > > > are also legacy.
> > > > > >
> > > > > Did not understand the "Plus" case.
> > > > > Some of 4 properties is present, but its driver dose not use otg_caps?
> > > >
> > > > yes that is what I meant.
> > > >
> > > > >
> > > > > > > 3) Some controller drivers already support OTG HNP/SRP, then
> > > > > > > change
> > > > > > > to utilize those new flags, still should support OTG HNP/SRP w/o
> > > > > > > any dt change, so OTG caps should be enabled for legacy
> > > > > > > platforms.
> > > > > >
> > > > > > I didn't understand this point. If a controller driver is not
> > > > > > updated
> > > > > > to use otg_caps it is legacy and gadget->otg_caps will be NULL.
> > > > > >
> > > > > Some of existing chipdea platforms work fine on HNP and SRP , which
> > > > > did
> > > > > not use any new flags and properties, after my patch, those platform
> > > > > should
> > > > > still enable HNP and SRP without any DT change.
> > > >
> > > > Agreed.
> > > > >
> > > > > > > 4) Some controller drivers does not support any OTG, after add OTG
> > > > > > > functions and utilize those new flags, should keep OTG disabled
> > > > > > > for legacy platforms.
> > > > > >
> > > > > > If controller drivers don't support OTG. gadget->is_otg and
> > > > > > gadget->otg_caps will not be set by them and they don't have to use
> > > > > > of_usb_set_otg_caps().
> > > > > >
> > > > > But after my patch, some time later, this driver adds OTG functions on
> > > > > it new platform, it should disable any OTG feature for its legacy
> > > > > platforms (none of properties is passed).
> > > >
> > > > That can be decided in of_usb_update_otg_caps().
> > > > Controller sets whatever it supports in otg_caps.
> > > > of_usb_updade_otg_caps() checks if it is legacy DT (i.e. no otg-rev)
> > > > and then
> > > > overrides to legacy otg_caps.
> > > >
> > > > >
> > > > > > So I didn't understand why the decision can't be taken here
> > > > > > for non-legacy controller drivers with legacy DT.
> > > > > > They will set gadget->otg_caps and gadget->is_otg.
> > > > > >
> > > > > > If none of the 4 DT flags are passed then we know it is legacy DT
> > > > > > and we can limit to legacy behaviour.
> > > > > >
> > > > > legacy behaviour number is 2, not only one legacy behaviour.
> > > > > That's why I leave the otg caps decided by controller drivers.
> > > >
> > > > I'm only suggesting that it be decided at one place i.e. in
> > > > of_usb_updade_otg_caps() instead of every controller.
> > > >
> > > > Do you see any problems with tha
Re: [PATCH v6] usb: common: add API to set usb otg capabilities by device tree
On Tue, Jun 23, 2015 at 10:43:28AM +0300, Roger Quadros wrote: > > > > > > If the dr_mode was "otg" for such case and we want OTG disabled then it > > > is really the DT fault. > > > > It's ID pin detect for dual role switch as many current OTG controllers > > have. > > not DT fault, its dt only has a dr_mode = "otg". > > > > > We don't need to tackle this case. Just fix up the DT to dr_mode = > > > "peripheral" if > > > OTG behaviour is not needed. > > > > > OTG behaviour is not needed, so we need disable HNP/SRP/ADP. but dr_mode = > > "otg" as it already works fine with ID pin detect. > > Do you know which platform has plain non-otg dual-role working as of today > with dr_mode set to "otg"? I don't know. The dt property dr_mode is already there, and currently there are some platforms as its user, so I assume those platforms either are non-otg dual-role, or real OTG with HNP supported, I guess most are the former cases; chipidea is the later case. > For TI platforms none of them have it working currently. > So for Ti platforms, some enables non-otg dual-role function but do not use dr_mode = "otg"? For those only have non-otg dual-role platforms, no matter using dr_mode or not, we need keep it's real OTG disabled for legacy users after it's controller driver adds real OTG later. > > > > > > > > > > How I make one decision in of_usb_updade_otg_caps() > > > > for above 2 cases?(the otg-rev is 0 for both). > > > > > > > > > > For case 3. otg-rev passed by controller is not 0. otg-rev is just not > > > present in DT. > > > > > > > Current OTG situation is not so simple, so that we can not use one simple > > rule to handle legacy cases in a common place, but for a particular > > controller > > driver, make decision on this is a simple work, I think. > > OK. Let's continue with your apporach. Maybe USB maintainers can give their > opinion > as well. > If some simple handling for all legacy platforms can be accepted, I am happy to follow it in of_usb_update_otg_caps(). Felipe, Peter, any comments on this? Li Jun > Later if more controllers are trying to do the same thing then we can > introduce a helper > function for those controllers. > Agree. > cheers, > -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] FTDI CBUS GPIO support
On Mon, Jun 22, 2015 at 10:11:35PM +0200, Stefan Agner wrote: > On 2015-06-22 19:26, Johan Hovold wrote: > > Instead, hang the gpio chip directly off the usb interface (not the > > port), add a new config option, and keep the gpio implementation under > > drivers/usb/serial (possibly in its own file ftdi_sio-gpio.c). > > Agreed sounds like a good plan. Will try this approach in v2. > > Except I don't think hanging it directly to the USB interface is the > right thing to do. > > Looking at the block diagram of FT232R or FT232H, the CBUS pins seem to > be part of the UART/FIFO controller. And I think the dual UART FT2232D > actually supports controlling the CBUS pins of the two UART controllers > individually, at least the block diagram thereof suggests so. The port is a Linux abstraction, and for FTDI we happen to have exactly one port child device per USB interface. As I see it, the gpio controller for the CBUS pins should be a sibling rather than a child device to the port. Note that we'd still have two gpio-controllers on FT2232D (one per USB interface). I'm aware that this requires some restructuring of the ftdi_sio-driver (e.g. the device type and ftdi-interface number should be a feature of the usb-serial rather than usb-serial-port device). Thanks, Johan -- 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: pci: make better use of gpiod API
On Fri, Jun 12, 2015 at 09:10:19AM +0200, Uwe Kleine-König wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter that allows to specify direction and initial value for output.
>
> Furthermore there is devm_gpiod_get_optional which is designed to get
> optional gpios. Also use devm_gpiod_get* because otherwise the gpio
> might be grabbed by a different driver.
These gpios are later given to the phy driver. We handle them in this
quirk separately because otherwise the phy can not be probed as it
may still be in reset.
So we are just turning the phy "on" here, and then releasing the gpios
so the phy driver can take over.
> diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> index 27e4fc896e9d..7e308730f955 100644
> --- a/drivers/usb/dwc3/dwc3-pci.c
> +++ b/drivers/usb/dwc3/dwc3-pci.c
> @@ -84,18 +84,19 @@ static int dwc3_pci_quirks(struct pci_dev *pdev)
> acpi_dwc3_byt_gpios);
>
> /* These GPIOs will turn on the USB2 PHY */
> - gpio = gpiod_get(&pdev->dev, "cs");
> - if (!IS_ERR(gpio)) {
> - gpiod_direction_output(gpio, 0);
> - gpiod_set_value_cansleep(gpio, 1);
> - gpiod_put(gpio);
> - }
> + gpio = devm_gpiod_get_optional(&pdev->dev, "cs", GPIOD_OUT_LOW);
> + if (IS_ERR(gpio))
> + return PTR_ERR(gpio);
> +
> + gpiod_set_value_cansleep(gpio, 1);
> +
> + gpio = devm_gpiod_get_optional(&pdev->dev, "reset",
> +GPIOD_OUT_LOW);
> + if (IS_ERR(gpio))
> + return PTR_ERR(gpio);
>
> - gpio = gpiod_get(&pdev->dev, "reset");
> - if (!IS_ERR(gpio)) {
> - gpiod_direction_output(gpio, 0);
> + if (gpio) {
> gpiod_set_value_cansleep(gpio, 1);
> - gpiod_put(gpio);
So we still need to release the gpio here, or we break the platforms
where we have these gpios.
Thanks,
--
heikki
--
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 4/7] USB: mos7720: rename DCR
On Thu, Jun 18, 2015 at 05:47:50PM +0530, Sudip Mukherjee wrote:
> While building with mn10300 it failed with:
> error: expected identifier before '(' token
> #define __SYSREG(ADDR, TYPE) (*(volatile TYPE *)(ADDR))
> note: in expansion of macro '__SYSREG'
> #define DCR __SYSREG(0xc030, u16) /* Debug control register */
>
> mn10300 has a register named as DCR, so when this driver used an enum
> named as DCR, build failed.
> Just rename the DCR in the driver to parport_DCR.
>
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/usb/serial/mos7720.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
> index 4f70df3..3263125 100644
> --- a/drivers/usb/serial/mos7720.c
> +++ b/drivers/usb/serial/mos7720.c
> @@ -135,7 +135,7 @@ enum mos_regs {
> DLM,
> DPR, /* parallel port regs */
> DSR,
> - DCR,
> + parport_DCR,
> ECR,
> SP1_REG, /* device control regs */
> SP2_REG, /* serial port 2 (7720 only) */
Please use a MOS_ (or MOS7720_) prefix instead and add it to all the
registers.
Thanks,
Johan
--
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: ulpi: call put_device if device_register fails
On Fri, Jun 19, 2015 at 01:12:36AM +0800, ChengYi He wrote:
> put_device is required to release the last reference to the device.
>
> Signed-off-by: ChengYi He
> ---
> drivers/usb/common/ulpi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index 0e6f968..bd25bdb 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -184,8 +184,10 @@ static int ulpi_register(struct device *dev, struct ulpi
> *ulpi)
> request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product);
>
> ret = device_register(&ulpi->dev);
> - if (ret)
> + if (ret) {
> + put_device(&ulpi->dev);
If device_register returns failure, put_device has already been
called. Check device_add in drivers/base/core.c.
Thanks,
--
heikki
--
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 v5 00/22] usb: third series of updates for dwc2 driver
Hi Doug, Am Montag, 22. Juni 2015, 16:00:42 schrieb Doug Anderson: > On Thu, Jun 4, 2015 at 6:12 AM, Kaukab, Yousaf wrote: > >> > Tested-by: Heiko Stuebner > >> > > >> > -- 8< -- > >> > [ 19.799200] BUG: sleeping function called from invalid context > >> > at > >> > >>> > >> > >>> mm/slab.c:2863 > >> > >>> > >> > >>> Will I see a patch for fixing this ? > >> > >> > >> > >> I am currently on a business trip and can't look into this for at > >> > >> least a couple of weeks. > >> > > > >> > > John, since this is your driver, could you fix it up ? > >> > > >> > Hi Felipe, > >> > > >> > I've been out of the office for the past 2 weeks and am catching up on > >> > stuff now. > >> > > >> > I'll take a look at it later this week if I don't hear anything from > >> > Yousaf. > > > > I have patches to fix this issue (and another one). I will send them out > > hopefully tomorrow. > I noticed that (33ad261 usb: dwc2: host: spinlock urb_enqueue) is now > in linuxnext, so I pulled it (and many other) changes into the > chromeos-3.14 kernel for testing. I still see the problem that Heiko > reported. Note that aside from the warning, this causes all sorts of > "spinlock recursion" issues and an eventual freeze on my system. > > Until Yousaf's patch has landed it seems as if we should do a revert > of (33ad261 usb: dwc2: host: spinlock urb_enqueue) to avoid regressing > existing systems. I'm not exactly sure which patches have already landed, but did you try with "usb: dwc2: fix sleep while atomic bugs" [0] from 2015-06-12 by chance? This did seem to fix the issue for me. Heiko [0] http://www.spinics.net/lists/linux-usb/msg125921.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] usb: common: add API to set usb otg capabilities by device tree
+ Kukjin, Stephen, for board specific USB question. On Tue, 23 Jun 2015 16:35:49 +0800 Li Jun wrote: > On Tue, Jun 23, 2015 at 10:43:28AM +0300, Roger Quadros wrote: > > > > > > > > If the dr_mode was "otg" for such case and we want OTG disabled then it > > > > is really the DT fault. > > > > > > It's ID pin detect for dual role switch as many current OTG controllers > > > have. > > > not DT fault, its dt only has a dr_mode = "otg". > > > > > > > We don't need to tackle this case. Just fix up the DT to dr_mode = > > > > "peripheral" if > > > > OTG behaviour is not needed. > > > > > > > OTG behaviour is not needed, so we need disable HNP/SRP/ADP. but dr_mode = > > > "otg" as it already works fine with ID pin detect. > > > > Do you know which platform has plain non-otg dual-role working as of today > > with dr_mode set to "otg"? > > I don't know. > The dt property dr_mode is already there, and currently there are some > platforms > as its user, so I assume those platforms either are non-otg dual-role, or > real OTG > with HNP supported, I guess most are the former cases; chipidea is the later > case. > > > For TI platforms none of them have it working currently. > > > So for Ti platforms, some enables non-otg dual-role function but do not use > dr_mode = "otg"? for TI we have only musb based and dwc3 based platforms. MUSB based are OTG. dwc3 doesn't support dual-role or OTG yet so we use either "peripheral" or "Host" > > For those only have non-otg dual-role platforms, no matter using dr_mode or > not, > we need keep it's real OTG disabled for legacy users after it's controller > driver adds real OTG later. I wouldn't even bother about platforms expecting dual-role behaviour with dr_mode not set to "otg". That is just plain wrong and can't be supported. These are the dts files having dr_mode == "otg". I've sorted them as per Soc vendor and USB controller Freescale: -- powerpc/boot/dts/mpc5121.dtsi: dr_mode = "otg"; compatible = "fsl,mpc5121-usb2-dr"; powerpc/boot/dts/asp834x-redboot.dts: dr_mode = "otg"; compatible = "fsl-usb2-dr" powerpc/boot/dts/mpc834x_mds.dts: dr_mode = "otg"; compatible = "fsl-usb2-dr"; powerpc/boot/dts/mpc8349emitxgp.dts:dr_mode = "otg"; compatible = "fsl-usb2-dr"; arm/boot/dts/imx25-pdk.dts: dr_mode = "otg"; compatible = "fsl,imx25-usb", "fsl,imx27-usb"; arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts: dr_mode = "otg"; compatible = "fsl,imx25-usb", "fsl,imx27-usb"; arm/boot/dts/imx27-eukrea-cpuimx27.dtsi:dr_mode = "otg"; compatible = "fsl,imx27-usb"; arm/boot/dts/imx27-phytec-phycore-som.dtsi: dr_mode = "otg"; compatible = "fsl,imx27-usb"; arm/boot/dts/imx27-pdk.dts: dr_mode = "otg"; compatible = "fsl,imx27-usb"; arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts: dr_mode = "otg"; compatible = "fsl,imx35-usb", "fsl,imx27-usb"; arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts: dr_mode = "otg"; compatible = "fsl,imx51-usb", "fsl,imx27-usb"; arm/boot/dts/imx51-babbage.dts: dr_mode = "otg"; compatible = "fsl,imx51-usb", "fsl,imx27-usb"; arm/boot/dts/imx51-digi-connectcore-jsk.dts:dr_mode = "otg"; compatible = "fsl,imx51-usb", "fsl,imx27-usb"; arm/boot/dts/imx6dl-riotboard.dts: dr_mode = "otg"; compatible = "fsl,imx6q-usb", "fsl,imx27-usb"; Li, can you please comment on all the above Freesacle platforms? STE: --- arm/boot/dts/ste-dbx5x0.dtsi: dr_mode = "otg"; compatible = "stericsson,db8500-musb"; MUSB so legacy OTG. TI: --- arm/boot/dts/am33xx.dtsi: dr_mode = "otg"; compatible = "ti,musb-am33xx"; MUSB so legacy OTG. arm/boot/dts/dra7.dtsi: dr_mode = "otg"; compatible = "snps,dwc3"; /* board dts overrides to dr_mode = "peripheral" or "host" */ arm/boot/dts/dra74x.dtsi: dr_mode = "otg"; compatible = "snps,dwc3"; /* board dts overrides to dr_mode = "peripheral" or "host" */ arm/boot/dts/am4372.dtsi: dr_mode = "otg"; compatible = "snps,dwc3"; /* board dts overrides to dr_mode = "peripheral" or "host" */ arm/boot/dts/am4372.dtsi: dr_mode = "otg"; compatible = "snps,dwc3"; /* board dts overrides to dr_mode = "peripheral" or "host" */ All these will eventually use dr_mode = "otg" with all 3 disable flags for simple dual-role operation. Samsung --- arm/boot/dts/exynos5422-odroidxu3.dts: dr_mode = "otg"; compatible = "snps,dwc3"; I think that this board expects dual-role only behaviour. But that is not functional for DWC3. Kukjin/Felipe, any comment? Nvidia -- arm/boot/dts/tegra20-seaboard.dts: dr_mode = "otg"; compatible = "nvidia,tegra20-ehci", "us
[PATCH 14/17] ARM: dts: OMAP5: Use "syscon-phy-power" instead of "ctrl-module" in USB PHY node
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from USB PHY devicetree node.
Since "omap_control_usb2phy" and "omap_control_usb3phy" devicetree nodes
are no longer used, remove it.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7d24ae0..9b50314 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -846,18 +846,6 @@
hw-caps-temp-alert;
};
- omap_control_usb2phy: control-phy@4a002300 {
- compatible = "ti,control-phy-usb2";
- reg = <0x4a002300 0x4>;
- reg-names = "power";
- };
-
- omap_control_usb3phy: control-phy@4a002370 {
- compatible = "ti,control-phy-pipe3";
- reg = <0x4a002370 0x4>;
- reg-names = "power";
- };
-
usb3: omap_dwc3@4a02 {
compatible = "ti,dwc3";
ti,hwmods = "usb_otg_ss";
@@ -888,7 +876,7 @@
usb2_phy: usb2phy@4a084000 {
compatible = "ti,omap-usb2";
reg = <0x4a084000 0x7c>;
- ctrl-module = <&omap_control_usb2phy>;
+ syscon-phy-power = <&scm_conf 0x300>;
clocks = <&usb_phy_cm_clk32k>,
<&usb_otg_ss_refclk960m>;
clock-names = "wkupclk", "refclk";
#phy-cells = <0>;
@@ -900,7 +888,7 @@
<0x4a084800 0x64>,
<0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_usb3phy>;
+ syscon-phy-power = <&scm_conf 0x370>;
clocks = <&usb_phy_cm_clk32k>,
<&sys_clkin>,
<&usb_otg_ss_refclk960m>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/17] ARM: dts: dra7: Use "syscon-phy-power" instead of "ctrl-module" in SATA PHY node
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from SATA PHY node. Since "omap_control_sata" note is no longer
used, remove it.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 3f434f7..92e0741 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1115,14 +1115,6 @@
status = "disabled";
};
- omap_control_sata: control-phy@4a002374 {
- compatible = "ti,control-phy-pipe3";
- reg = <0x4a002374 0x4>;
- reg-names = "power";
- clocks = <&sys_clkin1>;
- clock-names = "sysclk";
- };
-
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp";
@@ -1137,7 +1129,7 @@
<0x4A096400 0x64>, /* phy_tx */
<0x4A096800 0x40>; /* pll_ctrl */
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_sata>;
+ syscon-phy-power = <&dra7_ctrl_core 0x374>;
clocks = <&sys_clkin1>, <&sata_ref_clk>;
clock-names = "sysclk", "refclk";
syscon-pllreset = <&dra7_ctrl_core 0x3fc>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/17] ARM: dts: omap4: Use "syscon-otghs" instead of "ctrl-module" in USB node
Add "syscon-otghs" property and remove the deprecated "ctrl-module"
property from MUSB devicetree node.
Since "omap_control_usbotg" devicetree node is no longer used, remove
it.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap4.dtsi |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d0e0960..3bc77b1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -852,12 +852,6 @@
};
};
- omap_control_usbotg: control-phy@4a00233c {
- compatible = "ti,control-phy-otghs";
- reg = <0x4a00233c 0x4>;
- reg-names = "otghs_control";
- };
-
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = "ti,omap4-musb";
reg = <0x4a0ab000 0x7ff>;
@@ -870,7 +864,7 @@
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
- ctrl-module = <&omap_control_usbotg>;
+ syscon-otghs = <&scm_conf 0x33c>;
};
aes: aes@4b501000 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/17] ARM: dts: dra7: Add dt node for the sycon pcie
Add new device tree node for the control module register space where
PCIe registers are present.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 260f300..3f434f7 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -291,6 +291,11 @@
reg = <0x4a002e00 0x7c>;
};
+ dra7_ctrl_pcie: tisyscon@4a003c00 {
+ compatible = "syscon";
+ reg = <0x4a003c00 0x48>;
+ };
+
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/17] ARM: dts: dra7: Use "syscon-phy-power" instead of "ctrl-module" in USB PHY node
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from USB PHY devicetree nodes.
Since "omap_control_usb2phy1", "omap_control_usb3phy1" and
"omap_control_usb2phy2" devicetree nodes are no longer used, remove it.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a8ee829..e82ac00 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1196,24 +1196,6 @@
clocks = <&sys_32k_ck>;
};
- omap_control_usb2phy1: control-phy@4a002300 {
- compatible = "ti,control-phy-usb2";
- reg = <0x4a002300 0x4>;
- reg-names = "power";
- };
-
- omap_control_usb3phy1: control-phy@4a002370 {
- compatible = "ti,control-phy-pipe3";
- reg = <0x4a002370 0x4>;
- reg-names = "power";
- };
-
- omap_control_usb2phy2: control-phy@0x4a002e74 {
- compatible = "ti,control-phy-usb2-dra7";
- reg = <0x4a002e74 0x4>;
- reg-names = "power";
- };
-
/* OCP2SCP1 */
ocp2scp@4a08 {
compatible = "ti,omap-ocp2scp";
@@ -1226,7 +1208,7 @@
usb2_phy1: phy@4a084000 {
compatible = "ti,omap-usb2";
reg = <0x4a084000 0x400>;
- ctrl-module = <&omap_control_usb2phy1>;
+ syscon-phy-power = <&dra7_ctrl_core 0x300>;
clocks = <&usb_phy1_always_on_clk32k>,
<&usb_otg_ss1_refclk960m>;
clock-names = "wkupclk",
@@ -1237,7 +1219,7 @@
usb2_phy2: phy@4a085000 {
compatible = "ti,dra7x-usb2-phy2",
"ti,omap-usb2";
reg = <0x4a085000 0x400>;
- ctrl-module = <&omap_control_usb2phy2>;
+ syscon-phy-power = <&dra7_ctrl_general 0x74>;
clocks = <&usb_phy2_always_on_clk32k>,
<&usb_otg_ss2_refclk960m>;
clock-names = "wkupclk",
@@ -1251,7 +1233,7 @@
<0x4a084800 0x64>,
<0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_usb3phy1>;
+ syscon-phy-power = <&dra7_ctrl_core 0x370>;
clocks = <&usb_phy3_always_on_clk32k>,
<&sys_clkin1>,
<&usb_otg_ss1_refclk960m>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/17] ARM: dts: omap4: Use "syscon-phy-power" instead of "ctrl-module" in USB PHY node
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from USB PHY dt node.
Since "omap_control_usb2phy" devicetree node is no longer used,
remove it.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap4.dtsi |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index f884d6a..d0e0960 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -701,7 +701,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
- ctrl-module = <&omap_control_usb2phy>;
+ syscon-phy-power = <&scm_conf 0x300>;
clocks = <&usb_phy_cm_clk32k>;
clock-names = "wkupclk";
#phy-cells = <0>;
@@ -852,12 +852,6 @@
};
};
- omap_control_usb2phy: control-phy@4a002300 {
- compatible = "ti,control-phy-usb2";
- reg = <0x4a002300 0x4>;
- reg-names = "power";
- };
-
omap_control_usbotg: control-phy@4a00233c {
compatible = "ti,control-phy-otghs";
reg = <0x4a00233c 0x4>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/17] ARM: dts: am4372: Use "syscon-phy-power" instead of "ctrl-module" in USB PHY node
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from USB PHY device tree node.
Since "am43xx_control_usb2phy1" and "am43xx_control_usb2phy2"
devicetree nodes are no longer used, remove it.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/am4372.dtsi | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c80a3e2..0754e0da 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -796,18 +796,6 @@
status = "disabled";
};
- am43xx_control_usb2phy1: control-phy@44e10620 {
- compatible = "ti,control-phy-usb2-am437";
- reg = <0x44e10620 0x4>;
- reg-names = "power";
- };
-
- am43xx_control_usb2phy2: control-phy@0x44e10628 {
- compatible = "ti,control-phy-usb2-am437";
- reg = <0x44e10628 0x4>;
- reg-names = "power";
- };
-
ocp2scp0: ocp2scp@483a8000 {
compatible = "ti,am437x-ocp2scp", "ti,omap-ocp2scp";
#address-cells = <1>;
@@ -818,7 +806,7 @@
usb2_phy1: phy@483a8000 {
compatible = "ti,am437x-usb2";
reg = <0x483a8000 0x8000>;
- ctrl-module = <&am43xx_control_usb2phy1>;
+ syscon-phy-power = <&scm_conf 0x620>;
clocks = <&usb_phy0_always_on_clk32k>,
<&usb_otg_ss0_refclk960m>;
clock-names = "wkupclk", "refclk";
@@ -837,7 +825,7 @@
usb2_phy2: phy@483e8000 {
compatible = "ti,am437x-usb2";
reg = <0x483e8000 0x8000>;
- ctrl-module = <&am43xx_control_usb2phy2>;
+ syscon-phy-power = <&scm_conf 0x628>;
clocks = <&usb_phy1_always_on_clk32k>,
<&usb_otg_ss1_refclk960m>;
clock-names = "wkupclk", "refclk";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/17] ARM: dts: OMAP5: Use "syscon-phy-power" instead of "ctrl-module" in SATA PHY node
Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from SATA PHY node.
Since "omap_control_sata" devicetree node is no longer used, remove it.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 9b50314..ca0a77f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -944,14 +944,6 @@
#thermal-sensor-cells = <1>;
};
- omap_control_sata: control-phy@4a002374 {
- compatible = "ti,control-phy-pipe3";
- reg = <0x4a002374 0x4>;
- reg-names = "power";
- clocks = <&sys_clkin>;
- clock-names = "sysclk";
- };
-
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp";
@@ -966,7 +958,7 @@
<0x4A096400 0x64>, /* phy_tx */
<0x4A096800 0x40>; /* pll_ctrl */
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_sata>;
+ syscon-phy-power = <&scm_conf 0x374>;
clocks = <&sys_clkin>, <&sata_ref_clk>;
clock-names = "sysclk", "refclk";
#phy-cells = <0>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/17] usb: musb: omap2430: use *syscon* framework to write to mailbox register
Deprecate using phy-omap-control driver to write to the mailbox register
and start using *syscon* framework to do the same.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/omap-usb.txt |7 +-
drivers/usb/musb/omap2430.c| 118
2 files changed, 102 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 38d9bb8..c001306 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -20,10 +20,15 @@ OMAP MUSB GLUE
- phy-names : the names of the PHY corresponding to the PHYs present in the
*phy* phandle.
-Optional properties:
+Optional Properties:
+Deprecated properties:
- ctrl-module : phandle of the control module this glue uses to write to
mailbox
+Recommended properies:
+ - syscon-otghs : phandle/offset pair. Phandle to the system control module
and the
+ register offset of the mailbox.
+
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = "ti,omap4-musb";
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index cc752d8..bcd6d1e 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -39,16 +39,27 @@
#include
#include
#include
+#include
+#include
#include "musb_core.h"
#include "omap2430.h"
+#define OMAP2430_MUSB_MODE_MASK0x1f
+#define OMAP2430_MUSB_AVALID (0x1 << 0)
+#define OMAP2430_MUSB_BVALID (0x1 << 1)
+#define OMAP2430_MUSB_VBUSVALID(0x1 << 2)
+#define OMAP2430_MUSB_SESSEND (0x1 << 3)
+#define OMAP2430_MUSB_IDDIG(0x1 << 4)
+
struct omap2430_glue {
struct device *dev;
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
struct device *control_otghs;
+ struct regmap *syscon_otghs; /* ctrl. reg. acces */
+ unsigned intotghs_reg; /* otghs reg. index within syscon */
};
#define glue_to_musb(g)platform_get_drvdata(g->musb)
@@ -253,6 +264,47 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status
status)
}
EXPORT_SYMBOL_GPL(omap_musb_mailbox);
+static void omap2430_musb_set_usbmode(struct omap2430_glue *glue,
+ enum omap_control_usb_mode mode)
+{
+ u32 val;
+ int ret;
+
+ if (glue->syscon_otghs) {
+ switch (mode) {
+ case USB_MODE_HOST:
+ val = OMAP2430_MUSB_AVALID | OMAP2430_MUSB_VBUSVALID;
+ break;
+
+ case USB_MODE_DEVICE:
+ val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_AVALID |
+ OMAP2430_MUSB_VBUSVALID;
+ break;
+
+ case USB_MODE_DISCONNECT:
+ val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_SESSEND;
+ break;
+
+ default:
+ dev_dbg(glue->dev, "Invalid mode\n");
+ goto err_regmap_update;
+ }
+
+ ret = regmap_update_bits(glue->syscon_otghs,
+glue->otghs_reg,
+OMAP2430_MUSB_MODE_MASK, val);
+ if (ret < 0)
+ goto err_regmap_update;
+ } else {
+ omap_control_usb_set_mode(glue->control_otghs, mode);
+ }
+
+ return;
+
+err_regmap_update:
+ dev_err(glue->dev, "Failed to set mode to %d\n", mode);
+}
+
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
struct musb *musb = glue_to_musb(glue);
@@ -270,8 +322,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb->xceiv->last_event = USB_EVENT_ID;
if (musb->gadget_driver) {
pm_runtime_get_sync(dev);
- omap_control_usb_set_mode(glue->control_otghs,
- USB_MODE_HOST);
+ omap2430_musb_set_usbmode(glue, USB_MODE_HOST);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -284,7 +335,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb->xceiv->last_event = USB_EVENT_VBUS;
if (musb->gadget_driver)
pm_runtime_get_sync(dev);
- omap_control_usb_set_mode(glue->control_otghs, USB_MODE_DEVICE);
+ omap2430_musb_set_usbmode(glue, USB_MODE_DEVICE);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -301,8 +352,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (data->interface_type == MUSB_INTERFACE_UTMI)
otg_set_vbus(musb->xceiv->otg, 0);
-
[PATCH 02/17] phy: ti-pipe3: use *syscon* framework to power on/off the PHY
Deprecate using phy-omap-control driver to power on/off the PHY and
use *syscon* framework to do the same.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/phy/ti-phy.txt | 10 ++-
drivers/phy/phy-ti-pipe3.c | 91 ++
2 files changed, 86 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index f0f5537..d3ad3bf 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -77,8 +77,6 @@ Required properties:
* "div-clk" - apll clock
Optional properties:
- - ctrl-module : phandle of the control module used by PHY driver to power on
- the PHY.
- id: If there are multiple instance of the same type, in order to
differentiate between each instance "id" can be used (e.g., multi-lane PCIe
PHY). If "id" is not provided, it is set to default value of '1'.
@@ -86,6 +84,14 @@ Optional properties:
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
+Deprecated properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+ the PHY.
+
+Recommended properies:
+ - syscon-phy-power : phandle/offset pair. Phandle to the system control
+ module and the register offset to power on/off the PHY.
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index d784426..78bac00 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -56,6 +56,15 @@
#define SATA_PLL_SOFT_RESETBIT(18)
+#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK 0x003FC000
+#define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
+
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_MASK 0xFFC0
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT22
+
+#define PIPE3_PHY_TX_RX_POWERON0x3
+#define PIPE3_PHY_TX_RX_POWEROFF 0x0
+
/*
* This is an Empirical value that works, need to confirm the actual
* value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -86,8 +95,10 @@ struct ti_pipe3 {
struct clk *refclk;
struct clk *div_clk;
struct pipe3_dpll_map *dpll_map;
+ struct regmap *phy_power_syscon; /* ctrl. reg. acces */
struct regmap *dpll_reset_syscon; /* ctrl. reg. acces */
unsigned intdpll_reset_reg; /* reg. index within syscon */
+ unsigned intpower_reg; /* power reg. index within syscon */
boolsata_refclk_enabled;
};
@@ -144,18 +155,49 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3 *phy);
static int ti_pipe3_power_off(struct phy *x)
{
+ u32 val;
+ int ret;
struct ti_pipe3 *phy = phy_get_drvdata(x);
- omap_control_phy_power(phy->control_dev, 0);
+ if (phy->phy_power_syscon) {
+ val = PIPE3_PHY_TX_RX_POWEROFF <<
+ PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+
+ ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
+ if (ret < 0)
+ return ret;
+ } else {
+ omap_control_phy_power(phy->control_dev, 0);
+ }
return 0;
}
static int ti_pipe3_power_on(struct phy *x)
{
+ u32 val;
+ u32 mask;
+ int ret;
+ unsigned long rate;
struct ti_pipe3 *phy = phy_get_drvdata(x);
- omap_control_phy_power(phy->control_dev, 1);
+ if (phy->phy_power_syscon) {
+ rate = clk_get_rate(phy->sys_clk);
+ rate = rate / 100;
+ mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
+ OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK;
+ val = PIPE3_PHY_TX_RX_POWERON <<
+ PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+ val |= rate << OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
+
+ ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+mask, val);
+ if (ret < 0)
+ return ret;
+ } else {
+ omap_control_phy_power(phy->control_dev, 1);
+ }
return 0;
}
@@ -417,19 +459,42 @@ static int ti_pipe3_probe(struct platform_device *pdev)
phy->div_clk = ERR_PTR(-ENODEV);
}
- control_node = of_parse_phandle(node, "ctrl-module", 0);
- if (!control_node) {
- dev_err(&pdev->dev, "Failed to get control device phandle\n");
- return -EINVAL;
- }
+ phy->phy_power_syscon = syscon_regmap_lookup_by_phandle(node,
+ "syscon-phy-po
[PATCH 05/17] phy: omap-usb2: Add a new compatible string for USB2 PHY2
The USB2 PHY2 has a different register map compared to USB2 PHY1
to power on/off the PHY. In order to handle it, add a new
"compatible" string.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
drivers/phy/phy-omap-usb2.c |9 +
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 52c7a92..b9101b9 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -31,6 +31,8 @@ OMAP USB2 PHY
Required properties:
- compatible: Should be "ti,omap-usb2"
+ Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
+ in DRA7x
- reg : Address and length of the register set for the device.
- #phy-cells: determine the number of cells that should be given in the
phandle while referencing this phy.
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index b5c266a..2f7220f 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -159,6 +159,11 @@ static const struct usb_phy_data dra7x_usb2_data = {
.flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
};
+static const struct usb_phy_data dra7x_usb2_phy2_data = {
+ .label = "dra7x_usb2_phy2",
+ .flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+};
+
static const struct usb_phy_data am437x_usb2_data = {
.label = "am437x_usb2",
.flags = 0,
@@ -178,6 +183,10 @@ static const struct of_device_id omap_usb2_id_table[] = {
.data = &dra7x_usb2_data,
},
{
+ .compatible = "ti,dra7x-usb2-phy2",
+ .data = &dra7x_usb2_phy2_data,
+ },
+ {
.compatible = "ti,am437x-usb2",
.data = &am437x_usb2_data,
},
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/17] Deprecate phy-omap-control and use SYSCON
phy-omap-control driver was added when there was no proper infrastructure for doing control module initializations. Now with SYSCON framework being added to the kernel, phy-omap-control shouldn't be needed. This series is about adapting phy-omap-usb2, phy-ti-pipe3 and omap2430 to use SYSCON framework instead of phy-omap-control. However we can't remove the phy-omap-control driver altogether since that will break older dtbs. Performed USB enumeration testing in DRA72-EVM, AM43XX-EVM, OMAP5-uEVM and OMAP4 PANDA. Performed SATA enumeration testing in DRA72-EVM and OMAP5-uEVM Performed PCIe enumeration testing in DRA72-EVM. This patch series is developed on top of Linux 4.1-rc8 + http://lkml.iu.edu/hypermail/linux/kernel/1505.1/03099.html Kishon Vijay Abraham I (17): phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during probe phy: ti-pipe3: use *syscon* framework to power on/off the PHY phy: ti-pipe3: use *syscon* framework to set PCS value of the PHY phy: omap-usb2: use omap_usb_power_off to power off the PHY during probe phy: omap-usb2: Add a new compatible string for USB2 PHY2 phy: omap-usb2: use *syscon* framework to power on/off the PHY usb: musb: omap2430: use *syscon* framework to write to mailbox register ARM: dts: dra7: Add dt node for the sycon pcie ARM: dts: dra7: Use "syscon-phy-power" instead of "ctrl-module" in SATA PHY node ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY node ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2 PHY2 ARM: dts: dra7: Use "syscon-phy-power" instead of "ctrl-module" in USB PHY node ARM: dts: am4372: Use "syscon-phy-power" instead of "ctrl-module" in USB PHY node ARM: dts: OMAP5: Use "syscon-phy-power" instead of "ctrl-module" in USB PHY node ARM: dts: OMAP5: Use "syscon-phy-power" instead of "ctrl-module" in SATA PHY node ARM: dts: omap4: Use "syscon-phy-power" instead of "ctrl-module" in USB PHY node ARM: dts: omap4: Use "syscon-otghs" instead of "ctrl-module" in USB node Documentation/devicetree/bindings/phy/ti-phy.txt | 20 +++- Documentation/devicetree/bindings/usb/omap-usb.txt |7 +- arch/arm/boot/dts/am4372.dtsi | 16 +-- arch/arm/boot/dts/dra7.dtsi| 69 +++ arch/arm/boot/dts/omap4.dtsi | 16 +-- arch/arm/boot/dts/omap5.dtsi | 26 +--- drivers/phy/phy-omap-usb2.c| 112 +++--- drivers/phy/phy-ti-pipe3.c | 125 +--- drivers/usb/musb/omap2430.c| 118 ++ include/linux/phy/omap_usb.h | 18 +++ 10 files changed, 365 insertions(+), 162 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/17] phy: ti-pipe3: use *syscon* framework to set PCS value of the PHY
Deprecate using phy-omap-control driver to set PCS value of the PHY
and start using *syscon* framework to do the same.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
drivers/phy/phy-ti-pipe3.c | 32 +-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index d3ad3bf..52c7a92 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -83,6 +83,8 @@ Optional properties:
- syscon-pllreset: Handle to system control region that contains the
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
+ - syscon-pcs : phandle/offset pair. Phandle to the system control module and
the
+ register offset to write the PCS delay value.
Deprecated properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 78bac00..e2f9ad7 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -65,6 +65,9 @@
#define PIPE3_PHY_TX_RX_POWERON0x3
#define PIPE3_PHY_TX_RX_POWEROFF 0x0
+#define PCIE_PCS_MASK 0xFF
+#define PCIE_PCS_DELAY_COUNT_SHIFT 0x10
+
/*
* This is an Empirical value that works, need to confirm the actual
* value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -96,9 +99,11 @@ struct ti_pipe3 {
struct clk *div_clk;
struct pipe3_dpll_map *dpll_map;
struct regmap *phy_power_syscon; /* ctrl. reg. acces */
+ struct regmap *pcs_syscon; /* ctrl. reg. acces */
struct regmap *dpll_reset_syscon; /* ctrl. reg. acces */
unsigned intdpll_reset_reg; /* reg. index within syscon */
unsigned intpower_reg; /* power reg. index within syscon */
+ unsigned intpcie_pcs_reg; /* pcs reg. index in syscon */
boolsata_refclk_enabled;
};
@@ -271,7 +276,16 @@ static int ti_pipe3_init(struct phy *x)
* 18-1804.
*/
if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
- omap_control_pcie_pcs(phy->control_dev, 0x96);
+ if (phy->pcs_syscon) {
+ val = 0x96 << OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT;
+ ret = regmap_update_bits(phy->pcs_syscon,
+phy->pcie_pcs_reg,
+PCIE_PCS_MASK, val);
+ if (ret < 0)
+ return ret;
+ } else {
+ omap_control_pcie_pcs(phy->control_dev, 0x96);
+ }
return 0;
}
@@ -455,6 +469,22 @@ static int ti_pipe3_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "unable to get div-clk\n");
return PTR_ERR(phy->div_clk);
}
+
+ phy->pcs_syscon = syscon_regmap_lookup_by_phandle(node,
+ "syscon-pcs");
+ if (IS_ERR(phy->pcs_syscon)) {
+ dev_dbg(&pdev->dev,
+"can't get syscon-pcs, using omap control\n");
+ phy->pcs_syscon = NULL;
+ } else {
+ if (of_property_read_u32_index(node,
+ "syscon-pcs", 1,
+ &phy->pcie_pcs_reg)) {
+ dev_err(&pdev->dev,
+ "couldn't get pcie pcs reg. offset\n");
+ return -EINVAL;
+ }
+ }
} else {
phy->div_clk = ERR_PTR(-ENODEV);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/17] phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during probe
No functional change. Previously omap_control_phy_power() was used to power off the PHY during probe. But once PIPE3 driver is adapted to use syscon, omap_control_phy_power() cannot be used. Hence used ti_pipe3_power_off to power off the PHY. Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/phy-ti-pipe3.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c index 08020dc..d784426 100644 --- a/drivers/phy/phy-ti-pipe3.c +++ b/drivers/phy/phy-ti-pipe3.c @@ -431,8 +431,6 @@ static int ti_pipe3_probe(struct platform_device *pdev) phy->control_dev = &control_pdev->dev; - omap_control_phy_power(phy->control_dev, 0); - platform_set_drvdata(pdev, phy); pm_runtime_enable(phy->dev); @@ -451,6 +449,8 @@ static int ti_pipe3_probe(struct platform_device *pdev) return PTR_ERR(generic_phy); phy_set_drvdata(generic_phy, phy); + ti_pipe3_power_off(generic_phy); + phy_provider = devm_of_phy_provider_register(phy->dev, of_phy_simple_xlate); if (IS_ERR(phy_provider)) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/17] ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY node
Add "syscon-phy-power" property and "syscon-pcs" property which can
be used to perform the control module initializations and remove
the deprecated "ctrl-module" property from PCIe PHY dt nodes.
Phandle to "sysclk" clock node is also added to the PCIe PHY node
since some of the syscon initializations is based on system clock
frequency.
Since "omap_control_pcie1phy" and "omap_control_pcie2phy" devicetree
nodes are no longer used, remove it.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 92e0741..f69db70 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1141,16 +1141,18 @@
reg = <0x4a094000 0x80>, /* phy_rx */
<0x4a094400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
- ctrl-module = <&omap_control_pcie1phy>;
+ syscon-phy-power = <&dra7_ctrl_pcie 0x40>;
+ syscon-pcs = <&dra7_ctrl_pcie 0x34>;
clocks = <&dpll_pcie_ref_ck>,
<&dpll_pcie_ref_m2ldo_ck>,
<&optfclk_pciephy1_32khz>,
<&optfclk_pciephy1_clk>,
<&optfclk_pciephy1_div_clk>,
-<&optfclk_pciephy_div>;
+<&optfclk_pciephy_div>,
+<&sys_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
"wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
};
@@ -1159,7 +1161,8 @@
reg = <0x4a095000 0x80>, /* phy_rx */
<0x4a095400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
- ctrl-module = <&omap_control_pcie2phy>;
+ syscon-phy-power = <&dra7_ctrl_pcie 0x44>;
+ syscon-pcs = <&dra7_ctrl_pcie 0x34>;
clocks = <&dpll_pcie_ref_ck>,
<&dpll_pcie_ref_m2ldo_ck>,
<&optfclk_pciephy2_32khz>,
@@ -1184,23 +1187,6 @@
ti,hwmods = "sata";
};
- omap_control_pcie1phy: control-phy@0x4a003c40 {
- compatible = "ti,control-phy-pcie";
- reg = <0x4a003c40 0x4>, <0x4a003c14 0x4>, <0x4a003c34
0x4>;
- reg-names = "power", "control_sma", "pcie_pcs";
- clocks = <&sys_clkin1>;
- clock-names = "sysclk";
- };
-
- omap_control_pcie2phy: control-pcie@0x4a003c44 {
- compatible = "ti,control-phy-pcie";
- reg = <0x4a003c44 0x4>, <0x4a003c14 0x4>, <0x4a003c34
0x4>;
- reg-names = "power", "control_sma", "pcie_pcs";
- clocks = <&sys_clkin1>;
- clock-names = "sysclk";
- status = "disabled";
- };
-
rtc: rtc@48838000 {
compatible = "ti,am3352-rtc";
reg = <0x48838000 0x100>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/17] phy: omap-usb2: use *syscon* framework to power on/off the PHY
Deprecate using phy-omap-control driver to power on/off the PHY,
and use *syscon* framework to do the same. This handles
powering on/off the PHY for the USB2 PHYs used in various TI SoCs.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/phy/ti-phy.txt |6 +-
drivers/phy/phy-omap-usb2.c | 101 ++
include/linux/phy/omap_usb.h | 18
3 files changed, 107 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index b9101b9..5bfe461 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -42,10 +42,14 @@ Required properties:
* "wkupclk" - wakeup clock.
* "refclk" - reference clock (optional).
-Optional properties:
+Deprecated properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
the PHY.
+Recommended properies:
+- syscon-phy-power : phandle/offset pair. Phandle to the system control
+ module and the register offset to power on/off the PHY.
+
This is usually a subnode of ocp2scp to which it is connected.
usb2phy@4a0ad080 {
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 2f7220f..180b066 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+#include
#include
#define USB2PHY_DISCON_BYP_LATCH (1 << 31)
@@ -97,22 +99,65 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
}
-static int omap_usb_power_off(struct phy *x)
+static int omap_usb_phy_power(struct omap_usb *phy, int on)
{
- struct omap_usb *phy = phy_get_drvdata(x);
+ u32 val = 0;
+ u32 mask;
+ int ret;
- omap_control_phy_power(phy->control_dev, 0);
+ if (phy->syscon_phy_power) {
+ switch (phy->type) {
+ case TYPE_USB2:
+ mask = OMAP_DEV_PHY_PD;
+ if (!on)
+ val = OMAP_DEV_PHY_PD;
+ break;
+ case TYPE_DRA7USB2:
+ mask = OMAP_USB2_PHY_PD;
+ if (!on)
+ val = OMAP_USB2_PHY_PD;
+ break;
+ case TYPE_AM437USB2:
+ mask = AM437X_USB2_PHY_PD |
+ AM437X_USB2_OTG_PD |
+ AM437X_USB2_OTGVDET_EN |
+ AM437X_USB2_OTGSESSEND_EN;
+ if (on) {
+ val = AM437X_USB2_OTGVDET_EN |
+ AM437X_USB2_OTGSESSEND_EN;
+ } else {
+ val = AM437X_USB2_PHY_PD | AM437X_USB2_OTG_PD;
+ }
+ break;
+ default:
+ dev_err(phy->dev, "%s: type %d not recognized\n",
+ __func__, phy->type);
+ return -EINVAL;
+ }
+
+ ret = regmap_update_bits(phy->syscon_phy_power, phy->power_reg,
+mask, val);
+ if (ret < 0)
+ return ret;
+ } else {
+ omap_control_phy_power(phy->control_dev, on);
+ }
return 0;
}
-static int omap_usb_power_on(struct phy *x)
+static int omap_usb_power_off(struct phy *x)
{
struct omap_usb *phy = phy_get_drvdata(x);
- omap_control_phy_power(phy->control_dev, 1);
+ return omap_usb_phy_power(phy, false);
+}
- return 0;
+static int omap_usb_power_on(struct phy *x)
+{
+ struct omap_usb *phy = phy_get_drvdata(x);
+
+ return omap_usb_phy_power(phy, true);
}
static int omap_usb_init(struct phy *x)
@@ -147,26 +192,31 @@ static struct phy_ops ops = {
static const struct usb_phy_data omap_usb2_data = {
.label = "omap_usb2",
.flags = OMAP_USB2_HAS_START_SRP | OMAP_USB2_HAS_SET_VBUS,
+ .type = TYPE_USB2,
};
static const struct usb_phy_data omap5_usb2_data = {
.label = "omap5_usb2",
.flags = 0,
+ .type = TYPE_USB2,
};
static const struct usb_phy_data dra7x_usb2_data = {
.label = "dra7x_usb2",
.flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+ .type = TYPE_USB2,
};
static const struct usb_phy_data dra7x_usb2_phy2_data = {
.label = "dra7x_usb2_phy2",
.flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+ .type = TYPE_DRA7USB2,
};
static const struct usb_phy_data am437x_usb2_data = {
.label = "am437x_usb2",
.flags = 0,
+ .type = TYPE_AM437USB2,
};
static const struct of_device_id omap_usb2_id_table[] = {
@@ -223,6 +273,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
[PATCH 11/17] ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2 PHY2
The USB2 PHY2 has a different register map compared to USB2 PHY1
to power on/off the PHY. In order to handle it, use the new compatible
string "ti,dra7x-usb2-phy2" for the second instance of USB2 PHY.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index f69db70..a8ee829 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1235,7 +1235,7 @@
};
usb2_phy2: phy@4a085000 {
- compatible = "ti,omap-usb2";
+ compatible = "ti,dra7x-usb2-phy2",
"ti,omap-usb2";
reg = <0x4a085000 0x400>;
ctrl-module = <&omap_control_usb2phy2>;
clocks = <&usb_phy2_always_on_clk32k>,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/17] phy: omap-usb2: use omap_usb_power_off to power off the PHY during probe
No functional change. Previously omap_control_phy_power() was used to power off the PHY during probe. But once phy-omap-usb2 driver is adapted to use syscon, omap_control_phy_power() cannot be used. Hence used omap_usb_power_off to power off the PHY. Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/phy-omap-usb2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c index c1a4686..b5c266a 100644 --- a/drivers/phy/phy-omap-usb2.c +++ b/drivers/phy/phy-omap-usb2.c @@ -241,7 +241,6 @@ static int omap_usb2_probe(struct platform_device *pdev) } phy->control_dev = &control_pdev->dev; - omap_control_phy_power(phy->control_dev, 0); otg->set_host = omap_usb_set_host; otg->set_peripheral = omap_usb_set_peripheral; @@ -261,6 +260,7 @@ static int omap_usb2_probe(struct platform_device *pdev) } phy_set_drvdata(generic_phy, phy); + omap_usb_power_off(generic_phy); phy_provider = devm_of_phy_provider_register(phy->dev, of_phy_simple_xlate); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: dwc3: pci: make better use of gpiod API
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Use this additional parameter and the _optional variant to simplify the
driver and improve error handling. Also expand the comment to explain
why it's not sensible to switch to devm_gpiod_get and why the gpiod_put
is also necessary.
Furthermore this is one caller less that stops us making the flags
argument to gpiod_get*() mandatory.
Signed-off-by: Uwe Kleine-König
---
Changes since (implicit) v1, sent with Message-Id:
1434093019-14009-1-git-send-email-u.kleine-koe...@pengutronix.de:
- don't use devm_ and keep the gpiod_put
As with v1: This usage without flags was introduced by commit a89d977cc04c
(usb: dwc3: pci: add quirk for Baytrails) that is currently in next.
Note I plan to make the flags parameter mandatory for 4.3. So unless
this change gets into 4.2, would it be ok to let it go in via the gpio
tree?
Best regards
Uwe
drivers/usb/dwc3/dwc3-pci.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 27e4fc896e9d..f62617999f3c 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -83,17 +83,23 @@ static int dwc3_pci_quirks(struct pci_dev *pdev)
acpi_dev_add_driver_gpios(ACPI_COMPANION(&pdev->dev),
acpi_dwc3_byt_gpios);
- /* These GPIOs will turn on the USB2 PHY */
- gpio = gpiod_get(&pdev->dev, "cs");
- if (!IS_ERR(gpio)) {
- gpiod_direction_output(gpio, 0);
- gpiod_set_value_cansleep(gpio, 1);
- gpiod_put(gpio);
- }
+ /*
+* These GPIOs will turn on the USB2 PHY. Note that we have to
+* put the gpio descriptors again here because the phy driver
+* might want to grab them, too.
+*/
+ gpio = gpiod_get_optional(&pdev->dev, "cs", GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
+
+ gpiod_set_value_cansleep(gpio, 1);
+ gpiod_put(gpio);
+
+ gpio = gpiod_get_optional(&pdev->dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
- gpio = gpiod_get(&pdev->dev, "reset");
- if (!IS_ERR(gpio)) {
- gpiod_direction_output(gpio, 0);
+ if (gpio) {
gpiod_set_value_cansleep(gpio, 1);
gpiod_put(gpio);
usleep_range(1, 11000);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] usb: common: add API to set usb otg capabilities by device tree
On Tue, Jun 23, 2015 at 02:56:06PM +0300, Roger Quadros wrote: > + Kukjin, Stephen, > > for board specific USB question. > > On Tue, 23 Jun 2015 16:35:49 +0800 > Li Jun wrote: > > > On Tue, Jun 23, 2015 at 10:43:28AM +0300, Roger Quadros wrote: > > > > > > > > > > If the dr_mode was "otg" for such case and we want OTG disabled then > > > > > it is really the DT fault. > > > > > > > > It's ID pin detect for dual role switch as many current OTG controllers > > > > have. > > > > not DT fault, its dt only has a dr_mode = "otg". > > > > > > > > > We don't need to tackle this case. Just fix up the DT to dr_mode = > > > > > "peripheral" if > > > > > OTG behaviour is not needed. > > > > > > > > > OTG behaviour is not needed, so we need disable HNP/SRP/ADP. but > > > > dr_mode = > > > > "otg" as it already works fine with ID pin detect. > > > > > > Do you know which platform has plain non-otg dual-role working as of today > > > with dr_mode set to "otg"? > > > > I don't know. > > The dt property dr_mode is already there, and currently there are some > > platforms > > as its user, so I assume those platforms either are non-otg dual-role, or > > real OTG > > with HNP supported, I guess most are the former cases; chipidea is the > > later case. > > > > > For TI platforms none of them have it working currently. > > > > > So for Ti platforms, some enables non-otg dual-role function but do not use > > dr_mode = "otg"? > > for TI we have only musb based and dwc3 based platforms. MUSB based are OTG. > dwc3 doesn't support dual-role or OTG yet so we use either "peripheral" or > "Host" > > > > > For those only have non-otg dual-role platforms, no matter using dr_mode or > > not, > > we need keep it's real OTG disabled for legacy users after it's controller > > driver adds real OTG later. > > I wouldn't even bother about platforms expecting dual-role behaviour > with dr_mode not set to "otg". That is just plain wrong and can't be > supported. > Some platforms may not pass dr_mode in it DT, and treat that means otg controller will work at otg mode by default, at least I know current chipidea platforms do so. Therefore we may not list all otg controller drivers just by grep "dr_mode = "otg"" in its dts files. > These are the dts files having dr_mode == "otg". > I've sorted them as per Soc vendor and USB controller > > Freescale: > -- > powerpc/boot/dts/mpc5121.dtsi:dr_mode = "otg"; > compatible = "fsl,mpc5121-usb2-dr"; > powerpc/boot/dts/asp834x-redboot.dts: dr_mode = "otg"; > compatible = "fsl-usb2-dr" > powerpc/boot/dts/mpc834x_mds.dts: dr_mode = "otg"; > compatible = "fsl-usb2-dr"; > powerpc/boot/dts/mpc8349emitxgp.dts: dr_mode = "otg"; > compatible = "fsl-usb2-dr"; > > arm/boot/dts/imx25-pdk.dts: dr_mode = "otg"; > compatible = "fsl,imx25-usb", "fsl,imx27-usb"; > arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts:dr_mode = "otg"; > compatible = "fsl,imx25-usb", "fsl,imx27-usb"; > arm/boot/dts/imx27-eukrea-cpuimx27.dtsi: dr_mode = "otg"; > compatible = "fsl,imx27-usb"; > arm/boot/dts/imx27-phytec-phycore-som.dtsi: dr_mode = "otg"; > compatible = "fsl,imx27-usb"; > arm/boot/dts/imx27-pdk.dts: dr_mode = "otg"; > compatible = "fsl,imx27-usb"; > arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts:dr_mode = "otg"; > compatible = "fsl,imx35-usb", "fsl,imx27-usb"; > arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts:dr_mode = "otg"; > compatible = "fsl,imx51-usb", "fsl,imx27-usb"; > arm/boot/dts/imx51-babbage.dts: dr_mode = "otg"; > compatible = "fsl,imx51-usb", "fsl,imx27-usb"; > arm/boot/dts/imx51-digi-connectcore-jsk.dts: dr_mode = "otg"; > compatible = "fsl,imx51-usb", "fsl,imx27-usb"; > arm/boot/dts/imx6dl-riotboard.dts:dr_mode = "otg"; > compatible = "fsl,imx6q-usb", "fsl,imx27-usb"; > > Li, can you please comment on all the above Freesacle platforms? > AFAIK, those FSL platforms are legacy OTG. Li Jun > STE: > --- > arm/boot/dts/ste-dbx5x0.dtsi: dr_mode = "otg"; > compatible = "stericsson,db8500-musb"; > > MUSB so legacy OTG. > > TI: > --- > arm/boot/dts/am33xx.dtsi: dr_mode = "otg"; > compatible = "ti,musb-am33xx"; > > MUSB so legacy OTG. > > arm/boot/dts/dra7.dtsi: dr_mode = "otg"; > compatible = "snps,dwc3"; /* board dts overrides to dr_mode = > "peripheral" or "host" */ > arm/boot/dts/dra74x.dtsi: dr_mode = "otg"; > compatible = "snps,dwc3"; /* board dts overrides to dr_mode = > "peripheral" or "host" */ > arm/boot/dts/am4372.dtsi: dr_mode = "otg"; > compatible = "snps,dwc3"; /* board dts overrides to dr_mode = > "peripheral" or "host" */ > arm/boot/dts/am4372.dtsi: dr_mode = "otg"
re: usb: dwc2: add controller hibernation support
Hello Gregory Herrero,
The patch d17ee77b3044: "usb: dwc2: add controller hibernation
support" from Apr 29, 2015, leads to the following static checker
warning:
drivers/usb/dwc2/core.c:77 dwc2_backup_host_registers()
error: scheduling with locks held: 'spin_lock:lock'
drivers/usb/dwc2/core.c
67 static int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
68 {
69 struct dwc2_hregs_backup *hr;
70 int i;
71
72 dev_dbg(hsotg->dev, "%s\n", __func__);
73
74 /* Backup Host regs */
75 hr = hsotg->hr_backup;
76 if (!hr) {
77 hr = devm_kzalloc(hsotg->dev, sizeof(*hr), GFP_KERNEL);
^^
We can't sleep here because we are called under spin_lock. The call
tree is:
dwc2_handle_common_intr() <- takes a lock.
dwc2_handle_usb_suspend_intr()
dwc2_enter_hibernation()
dwc2_backup_host_registers()
78 if (!hr) {
79 dev_err(hsotg->dev, "%s: can't allocate host
regs\n",
80 __func__);
81 return -ENOMEM;
82 }
83
regards,
dan carpenter
--
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 v3] USB: mos7720: rename registers
Some of the register names defined here are matching with registers
defined in other places. Like DCR is defined here and DCR is also
a register in mn10300 architecture. So when we are building this with
mn10300, build fails.
To avoid we rename all the registers.
Signed-off-by: Sudip Mukherjee
---
v3: renamed all registers with MOS7220_
v2: renamed only DCR
drivers/usb/serial/mos7720.c | 253 +++
1 file changed, 138 insertions(+), 115 deletions(-)
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index 4f70df3..78b4f64 100644
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -121,26 +121,26 @@ static DEFINE_SPINLOCK(release_lock);
static const unsigned int dummy; /* for clarity in register access fns */
enum mos_regs {
- THR, /* serial port regs */
- RHR,
- IER,
- FCR,
- ISR,
- LCR,
- MCR,
- LSR,
- MSR,
- SPR,
- DLL,
- DLM,
- DPR, /* parallel port regs */
- DSR,
- DCR,
- ECR,
- SP1_REG, /* device control regs */
- SP2_REG, /* serial port 2 (7720 only) */
- PP_REG,
- SP_CONTROL_REG,
+ MOS7720_THR, /* serial port regs */
+ MOS7720_RHR,
+ MOS7720_IER,
+ MOS7720_FCR,
+ MOS7720_ISR,
+ MOS7720_LCR,
+ MOS7720_MCR,
+ MOS7720_LSR,
+ MOS7720_MSR,
+ MOS7720_SPR,
+ MOS7720_DLL,
+ MOS7720_DLM,
+ MOS7720_DPR, /* parallel port regs */
+ MOS7720_DSR,
+ MOS7720_DCR,
+ MOS7720_ECR,
+ MOS7720_SP1_REG, /* device control regs */
+ MOS7720_SP2_REG, /* serial port 2 (7720 only) */
+ MOS7720_PP_REG,
+ MOS7720_SP_CONTROL_REG,
};
/*
@@ -150,26 +150,26 @@ enum mos_regs {
static inline __u16 get_reg_index(enum mos_regs reg)
{
static const __u16 mos7715_index_lookup_table[] = {
- 0x00, /* THR */
- 0x00, /* RHR */
- 0x01, /* IER */
- 0x02, /* FCR */
- 0x02, /* ISR */
- 0x03, /* LCR */
- 0x04, /* MCR */
- 0x05, /* LSR */
- 0x06, /* MSR */
- 0x07, /* SPR */
- 0x00, /* DLL */
- 0x01, /* DLM */
- 0x00, /* DPR */
- 0x01, /* DSR */
- 0x02, /* DCR */
- 0x0a, /* ECR */
- 0x01, /* SP1_REG */
- 0x02, /* SP2_REG (7720 only) */
- 0x04, /* PP_REG (7715 only) */
- 0x08, /* SP_CONTROL_REG */
+ 0x00, /* MOS7720_THR */
+ 0x00, /* MOS7720_RHR */
+ 0x01, /* MOS7720_IER */
+ 0x02, /* MOS7720_FCR */
+ 0x02, /* MOS7720_ISR */
+ 0x03, /* MOS7720_LCR */
+ 0x04, /* MOS7720_MCR */
+ 0x05, /* MOS7720_LSR */
+ 0x06, /* MOS7720_MSR */
+ 0x07, /* MOS7720_SPR */
+ 0x00, /* MOS7720_DLL */
+ 0x01, /* MOS7720_DLM */
+ 0x00, /* MOS7720_DPR */
+ 0x01, /* MOS7720_DSR */
+ 0x02, /* MOS7720_DCR */
+ 0x0a, /* MOS7720_ECR */
+ 0x01, /* MOS7720_SP1_REG */
+ 0x02, /* MOS7720_SP2_REG (7720 only) */
+ 0x04, /* MOS7720_PP_REG (7715 only) */
+ 0x08, /* MOS7720_SP_CONTROL_REG */
};
return mos7715_index_lookup_table[reg];
}
@@ -181,10 +181,10 @@ static inline __u16 get_reg_index(enum mos_regs reg)
static inline __u16 get_reg_value(enum mos_regs reg,
unsigned int serial_portnum)
{
- if (reg >= SP1_REG) /* control reg */
+ if (reg >= MOS7720_SP1_REG) /* control reg */
return 0x;
- else if (reg >= DPR) /* parallel port reg (7715 only) */
+ else if (reg >= MOS7720_DPR)/* parallel port reg (7715 only) */
return 0x0100;
else /* serial port reg */
@@ -252,7 +252,8 @@ static inline int mos7715_change_mode(struct
mos7715_parport *mos_parport,
enum mos7715_pp_modes mode)
{
mos_parport->shadowECR = mode;
- write_mos_reg(mos_parport->serial, dummy, ECR, mos_parport->shadowECR);
+ write_mos_reg(mos_parport->serial, dummy, MOS7720_ECR,
+ mos_parport->shadowECR);
retu
Re: [Patch v1] ax88179_178a: add reset functionality in reset_resume
From: Vivek Bhagat Date: Sun, 21 Jun 2015 11:41:43 +0530 > From d178065c9e3cfa8a45ef537fae7412775339beb0 Mon Sep 17 00:00:00 2001 > From: Vivek Kumar Bhagat > Date: Thu, 11 Jun 2015 07:23:46 -0700 > Subject: [PATCH] ax88179_178a: add reset functionality in reset_resume > > Without reset functionality in reset_resume, iperf connection does not > establish after suspend/resume however ping works at the same time. > iperf connection fails with wrong checksum error shown by tcpdump. > > reset function inside reset_resume solves above bug. We have verified > this issue on ASIX based ST Lab, Cadyce dongle. > > Signed-off-by: Vivek Kumar Bhagat > Signed-off-by: Praveen Kumar Your email client has corrupted the patch, turning TAB characters into spaces etc. Please fix this up and resubmit. -- 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 v5 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
On Tue, 23 Jun 2015, Ruslan Bilovol wrote:
> Change behavior during registration of gadgets and
> gadget drivers in udc-core. Instead of previous
> approach when for successful probe of usb gadget driver
> at least one usb gadget should be already registered
> use another one where gadget drivers and gadgets
> can be registered in udc-core independently.
>
> Independent registration of gadgets and gadget drivers
> is useful for built-in into kernel gadget and gadget
> driver case - because it's possible that gadget is
> really probed only on late_init stage (due to deferred
> probe) whereas gadget driver's probe is silently failed
> on module_init stage due to no any UDC added.
>
> Also it is useful for modules case - now there is no
> difference what module to insert first: gadget module
> or gadget driver one.
>
> Tested-by: Maxime Ripard
> Signed-off-by: Ruslan Bilovol
> @@ -484,6 +507,16 @@ int usb_gadget_unregister_driver(struct
> usb_gadget_driver *driver)
> break;
> }
>
> + if (ret) {
> + struct usb_gadget_driver *tmp;
> +
> + list_for_each_entry(tmp, &gadget_driver_pending_list, pending)
> + if (tmp == driver) {
> + list_del(&driver->pending);
> + ret = 0;
> + break;
> + }
> + }
Weren't you going to replace this loop with a simple list_del()? IIRC,
this is the third time I have asked you to make this change.
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: storage: add "no SYNCHRONIZE CACHE" quirk
From: Of James Bottomley
> Sent: 22 June 2015 18:36
> To: Alan Stern
...
> > > Obviously, for a disk with a writeback cache that can't do flush, that
> > > window is much wider and the real solution should be to try to switch
> > > the cache to write through.
> >
> > I agree. Doing the switch manually (by writing to the "cache_type"
> > attribute file) works, but it's a nuisance to do this when you have a
> > portable USB drive that gets moved among a bunch of machines.
>
> Perhaps it might be wise to do this to every USB device ... for external
> devices, the small performance gain doesn't really make up for the
> potential data loss.
What about systems running from USB memory/disk directly plugged into the
motherboard and shut inside the case?
Since they shouldn't be removed you don't want to bypass any write cache.
(Any more than you'd want to on a real disk.)
There is an additional problem caused by very temporary USB disconnects
(easily caused by electrical noise causing (probably) Vbus to bounce).
In these conditions you don't want to signal a USB remove at all - at
least not to the filesystem - until the device has remained disconnected
for a short time.
David
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [PATCH 01/17] phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during probe
On Tue, 23 Jun 2015 17:28:46 +0530 Kishon Vijay Abraham I wrote: > No functional change. Previously omap_control_phy_power() was used to power > off the PHY during probe. But once PIPE3 driver is adapted to use syscon, > omap_control_phy_power() cannot be used. Hence used ti_pipe3_power_off > to power off the PHY. > > Signed-off-by: Kishon Vijay Abraham I Acked-by: Roger Quadros cheers, -roger > --- > drivers/phy/phy-ti-pipe3.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c > index 08020dc..d784426 100644 > --- a/drivers/phy/phy-ti-pipe3.c > +++ b/drivers/phy/phy-ti-pipe3.c > @@ -431,8 +431,6 @@ static int ti_pipe3_probe(struct platform_device *pdev) > > phy->control_dev = &control_pdev->dev; > > - omap_control_phy_power(phy->control_dev, 0); > - > platform_set_drvdata(pdev, phy); > pm_runtime_enable(phy->dev); > > @@ -451,6 +449,8 @@ static int ti_pipe3_probe(struct platform_device *pdev) > return PTR_ERR(generic_phy); > > phy_set_drvdata(generic_phy, phy); > + ti_pipe3_power_off(generic_phy); > + > phy_provider = devm_of_phy_provider_register(phy->dev, > of_phy_simple_xlate); > if (IS_ERR(phy_provider)) > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/17] phy: ti-pipe3: use *syscon* framework to power on/off the PHY
Hi Kishon,
On Tue, 23 Jun 2015 17:28:47 +0530
Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to power on/off the PHY and
> use *syscon* framework to do the same.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Documentation/devicetree/bindings/phy/ti-phy.txt | 10 ++-
> drivers/phy/phy-ti-pipe3.c | 91
> ++
> 2 files changed, 86 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
> b/Documentation/devicetree/bindings/phy/ti-phy.txt
> index f0f5537..d3ad3bf 100644
> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
> @@ -77,8 +77,6 @@ Required properties:
> * "div-clk" - apll clock
>
> Optional properties:
> - - ctrl-module : phandle of the control module used by PHY driver to power on
> - the PHY.
> - id: If there are multiple instance of the same type, in order to
> differentiate between each instance "id" can be used (e.g., multi-lane
> PCIe
> PHY). If "id" is not provided, it is set to default value of '1'.
> @@ -86,6 +84,14 @@ Optional properties:
> CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
> register that contains the SATA_PLL_SOFT_RESET bit. Only valid for
> sata_phy.
>
> +Deprecated properties:
> + - ctrl-module : phandle of the control module used by PHY driver to power on
> + the PHY.
> +
> +Recommended properies:
> + - syscon-phy-power : phandle/offset pair. Phandle to the system control
> + module and the register offset to power on/off the PHY.
> +
> This is usually a subnode of ocp2scp to which it is connected.
>
> usb3phy@4a084400 {
> diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
> index d784426..78bac00 100644
> --- a/drivers/phy/phy-ti-pipe3.c
> +++ b/drivers/phy/phy-ti-pipe3.c
> @@ -56,6 +56,15 @@
>
> #define SATA_PLL_SOFT_RESET BIT(18)
>
> +#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK0x003FC000
> +#define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
> +
> +#define PIPE3_PHY_PWRCTL_CLK_FREQ_MASK 0xFFC0
> +#define PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT 22
> +
> +#define PIPE3_PHY_TX_RX_POWERON 0x3
> +#define PIPE3_PHY_TX_RX_POWEROFF 0x0
> +
> /*
> * This is an Empirical value that works, need to confirm the actual
> * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
> @@ -86,8 +95,10 @@ struct ti_pipe3 {
> struct clk *refclk;
> struct clk *div_clk;
> struct pipe3_dpll_map *dpll_map;
> + struct regmap *phy_power_syscon; /* ctrl. reg. acces */
> struct regmap *dpll_reset_syscon; /* ctrl. reg. acces */
> unsigned intdpll_reset_reg; /* reg. index within syscon */
> + unsigned intpower_reg; /* power reg. index within syscon */
> boolsata_refclk_enabled;
> };
>
> @@ -144,18 +155,49 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3
> *phy);
>
> static int ti_pipe3_power_off(struct phy *x)
> {
> + u32 val;
> + int ret;
> struct ti_pipe3 *phy = phy_get_drvdata(x);
>
> - omap_control_phy_power(phy->control_dev, 0);
> + if (phy->phy_power_syscon) {
> + val = PIPE3_PHY_TX_RX_POWEROFF <<
> + PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
> +
> + ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
> + PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
> + if (ret < 0)
> + return ret;
> + } else {
> + omap_control_phy_power(phy->control_dev, 0);
> + }
>
> return 0;
> }
>
> static int ti_pipe3_power_on(struct phy *x)
> {
> + u32 val;
> + u32 mask;
> + int ret;
> + unsigned long rate;
> struct ti_pipe3 *phy = phy_get_drvdata(x);
>
> - omap_control_phy_power(phy->control_dev, 1);
> + if (phy->phy_power_syscon) {
> + rate = clk_get_rate(phy->sys_clk);
what if clk_get_rate() returns 0?
> + rate = rate / 100;
> + mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
> + OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK;
> + val = PIPE3_PHY_TX_RX_POWERON <<
> + PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
> + val |= rate << OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
> +
> + ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
> + mask, val);
> + if (ret < 0)
> + return ret;
> + } else {
> + omap_control_phy_power(phy->control_dev, 1);
> + }
>
> return 0;
> }
> @@ -417,19 +459,42 @@ static int ti_pipe3_probe(struct platform_device *pdev)
> phy->div_clk = ERR_PTR(-ENODEV);
> }
>
> - control_node = of_parse_phandle(node, "ctrl-module", 0
ISO interval in the xhci driver
Hi all,
is that right that setting urb->interval does not work for the xhci
driver? Seems so that the driver (in my case the usbduxsigma.c) needs to
request the xhci_interval and then has to live with that frame rate so
essentially 125us? Is that right?
/Bernd
xhci-ring.c: (I've added a couple of debug messages to it)
if (xhci_interval != ep_interval) {
dev_err(&urb->dev->dev,
"Driver uses different interval (%d microframe%s) than xHCI (%d
microframe%s)\n",
ep_interval, ep_interval == 1 ? "" : "s",
xhci_interval, xhci_interval == 1 ? "" : "s");
urb->interval = xhci_interval;
/* Convert back to frames for LS/FS devices */
if (urb->dev->speed == USB_SPEED_LOW ||
urb->dev->speed == USB_SPEED_FULL)
urb->interval /= 8;
}
return xhci_queue_bulk_tx(xhci, mem_flags, urb, slot_id, ep_index);
--
http://www.berndporr.me.uk
http://www.imdb.com/name/nm3293421/
http://www.facebook.com/bernd.porr
+44 (0)7840 340069
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: usb: dwc2: add controller hibernation support
Hello Dan Carpenter,
Yousaf Kaukab did a patch to embed those backup registers in struct dwc2_hsotg.
This way, there is no more allocation needed in dwc2_backup_host_registers().
Here is the patch title: "usb: dwc2: embed storage for reg backup in struct
dwc2_hsotg"
It has been submitted to linux-usb mailing list few weeks ago.
Regards,
Gregory Herrero
-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
Sent: Tuesday, June 23, 2015 3:12 PM
To: Herrero, Gregory
Cc: linux-usb@vger.kernel.org
Subject: re: usb: dwc2: add controller hibernation support
Hello Gregory Herrero,
The patch d17ee77b3044: "usb: dwc2: add controller hibernation support" from
Apr 29, 2015, leads to the following static checker
warning:
drivers/usb/dwc2/core.c:77 dwc2_backup_host_registers()
error: scheduling with locks held: 'spin_lock:lock'
drivers/usb/dwc2/core.c
67 static int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
68 {
69 struct dwc2_hregs_backup *hr;
70 int i;
71
72 dev_dbg(hsotg->dev, "%s\n", __func__);
73
74 /* Backup Host regs */
75 hr = hsotg->hr_backup;
76 if (!hr) {
77 hr = devm_kzalloc(hsotg->dev, sizeof(*hr), GFP_KERNEL);
^^
We can't sleep here because we are called under spin_lock. The call tree is:
dwc2_handle_common_intr() <- takes a lock.
dwc2_handle_usb_suspend_intr()
dwc2_enter_hibernation()
dwc2_backup_host_registers()
78 if (!hr) {
79 dev_err(hsotg->dev, "%s: can't allocate host
regs\n",
80 __func__);
81 return -ENOMEM;
82 }
83
regards,
dan carpenter
--
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
urb->interval ignored in xhci?
Hi all,
is that right that setting urb->interval does not work for the xhci
driver? Seems so that the driver (in my case the usbduxsigma.c) needs to
request the xhci_interval and then has to live with that frame rate so
essentially 125us? Is that right?
/Bernd
xhci-ring.c: (I've added a couple of debug messages to it)
if (xhci_interval != ep_interval) {
dev_err(&urb->dev->dev,
"Driver uses different interval (%d microframe%s) than xHCI
(%d microframe%s)\n",
ep_interval, ep_interval == 1 ? "" : "s",
xhci_interval, xhci_interval == 1 ? "" : "s");
urb->interval = xhci_interval;
/* Convert back to frames for LS/FS devices */
if (urb->dev->speed == USB_SPEED_LOW ||
urb->dev->speed == USB_SPEED_FULL)
urb->interval /= 8;
}
return xhci_queue_bulk_tx(xhci, mem_flags, urb, slot_id, ep_index);
--
http://www.berndporr.me.uk
http://www.imdb.com/name/nm3293421/
http://www.facebook.com/bernd.porr
+44 (0)7840 340069
--
http://www.berndporr.me.uk
http://www.imdb.com/name/nm3293421/
http://www.facebook.com/bernd.porr
+44 (0)7840 340069
--
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 v5 00/22] usb: third series of updates for dwc2 driver
On 6/22/2015 4:00 PM, Doug Anderson wrote: > Hi, > > On Thu, Jun 4, 2015 at 6:12 AM, Kaukab, Yousaf > wrote: Tested-by: Heiko Stuebner -- 8< -- [ 19.799200] BUG: sleeping function called from invalid context at >>> mm/slab.c:2863 >>> >>> Will I see a patch for fixing this ? >> >> I am currently on a business trip and can't look into this for at >> least a couple of weeks. > > John, since this is your driver, could you fix it up ? > Hi Felipe, I've been out of the office for the past 2 weeks and am catching up on stuff now. I'll take a look at it later this week if I don't hear anything from Yousaf. >> >> I have patches to fix this issue (and another one). I will send them out >> hopefully tomorrow. > > I noticed that (33ad261 usb: dwc2: host: spinlock urb_enqueue) is now > in linuxnext, so I pulled it (and many other) changes into the > chromeos-3.14 kernel for testing. I still see the problem that Heiko > reported. Note that aside from the warning, this causes all sorts of > "spinlock recursion" issues and an eventual freeze on my system. > > Until Yousaf's patch has landed it seems as if we should do a revert > of (33ad261 usb: dwc2: host: spinlock urb_enqueue) to avoid regressing > existing systems. > > -Doug > Hi Doug, Hopefully the fixes will go into the next rc. Hi Felipe, If you haven't already, could you queue these patches for the next rc? They fix issues for patches applied for 4.2. http://marc.info/?l=linux-usb&m=143409924626643&w=2 http://marc.info/?l=linux-usb&m=143409925026644&w=2 http://marc.info/?l=linux-usb&m=143409925026645&w=2 Thanks, 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 v5 00/22] usb: third series of updates for dwc2 driver
John and Felipe, On Tue, Jun 23, 2015 at 10:56 AM, John Youn wrote: > On 6/22/2015 4:00 PM, Doug Anderson wrote: >> Hi, >> >> On Thu, Jun 4, 2015 at 6:12 AM, Kaukab, Yousaf >> wrote: > Tested-by: Heiko Stuebner > > -- 8< -- > [ 19.799200] BUG: sleeping function called from invalid context at mm/slab.c:2863 Will I see a patch for fixing this ? >>> >>> I am currently on a business trip and can't look into this for at >>> least a couple of weeks. >> >> John, since this is your driver, could you fix it up ? >> > > Hi Felipe, > > I've been out of the office for the past 2 weeks and am catching up on > stuff now. > > I'll take a look at it later this week if I don't hear anything from > Yousaf. >>> >>> I have patches to fix this issue (and another one). I will send them out >>> hopefully tomorrow. >> >> I noticed that (33ad261 usb: dwc2: host: spinlock urb_enqueue) is now >> in linuxnext, so I pulled it (and many other) changes into the >> chromeos-3.14 kernel for testing. I still see the problem that Heiko >> reported. Note that aside from the warning, this causes all sorts of >> "spinlock recursion" issues and an eventual freeze on my system. >> >> Until Yousaf's patch has landed it seems as if we should do a revert >> of (33ad261 usb: dwc2: host: spinlock urb_enqueue) to avoid regressing >> existing systems. >> >> -Doug >> > > Hi Doug, > > Hopefully the fixes will go into the next rc. > > > Hi Felipe, > > If you haven't already, could you queue these patches for the next rc? They > fix issues for patches applied for 4.2. > > http://marc.info/?l=linux-usb&m=143409924626643&w=2 > http://marc.info/?l=linux-usb&m=143409925026644&w=2 > http://marc.info/?l=linux-usb&m=143409925026645&w=2 OK, I tried those changes and they fix my problems too (which is not a terrible surprise). You can add my Tested-by if it helps. We need either these fixes or a revert of the patch. As it stands right now ToT linuxnext is pretty broken for me. -Doug -- 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 v5 00/22] usb: third series of updates for dwc2 driver
On Tue, Jun 23, 2015 at 02:56:23PM -0700, Doug Anderson wrote: > John and Felipe, > > On Tue, Jun 23, 2015 at 10:56 AM, John Youn wrote: > > On 6/22/2015 4:00 PM, Doug Anderson wrote: > >> Hi, > >> > >> On Thu, Jun 4, 2015 at 6:12 AM, Kaukab, Yousaf > >> wrote: > > Tested-by: Heiko Stuebner > > > > -- 8< -- > > [ 19.799200] BUG: sleeping function called from invalid context at > mm/slab.c:2863 > > Will I see a patch for fixing this ? > >>> > >>> I am currently on a business trip and can't look into this for at > >>> least a couple of weeks. > >> > >> John, since this is your driver, could you fix it up ? > >> > > > > Hi Felipe, > > > > I've been out of the office for the past 2 weeks and am catching up on > > stuff now. > > > > I'll take a look at it later this week if I don't hear anything from > > Yousaf. > >>> > >>> I have patches to fix this issue (and another one). I will send them out > >>> hopefully tomorrow. > >> > >> I noticed that (33ad261 usb: dwc2: host: spinlock urb_enqueue) is now > >> in linuxnext, so I pulled it (and many other) changes into the > >> chromeos-3.14 kernel for testing. I still see the problem that Heiko > >> reported. Note that aside from the warning, this causes all sorts of > >> "spinlock recursion" issues and an eventual freeze on my system. > >> > >> Until Yousaf's patch has landed it seems as if we should do a revert > >> of (33ad261 usb: dwc2: host: spinlock urb_enqueue) to avoid regressing > >> existing systems. > >> > >> -Doug > >> > > > > Hi Doug, > > > > Hopefully the fixes will go into the next rc. > > > > > > Hi Felipe, > > > > If you haven't already, could you queue these patches for the next rc? They > > fix issues for patches applied for 4.2. > > > > http://marc.info/?l=linux-usb&m=143409924626643&w=2 > > http://marc.info/?l=linux-usb&m=143409925026644&w=2 > > http://marc.info/?l=linux-usb&m=143409925026645&w=2 > > OK, I tried those changes and they fix my problems too (which is not a > terrible surprise). You can add my Tested-by if it helps. > > We need either these fixes or a revert of the patch. As it stands > right now ToT linuxnext is pretty broken for me. Can someone resend patches which need to be applied with proper Acks and Tested-bys in place ? This would go a long way. Keep in mind I won't apply patches before -rc1 is tagged though. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/2] FTDI CBUS GPIO support
On 2015-06-23 11:22, Johan Hovold wrote: > On Mon, Jun 22, 2015 at 10:11:35PM +0200, Stefan Agner wrote: >> On 2015-06-22 19:26, Johan Hovold wrote: > >> > Instead, hang the gpio chip directly off the usb interface (not the >> > port), add a new config option, and keep the gpio implementation under >> > drivers/usb/serial (possibly in its own file ftdi_sio-gpio.c). >> >> Agreed sounds like a good plan. Will try this approach in v2. >> >> Except I don't think hanging it directly to the USB interface is the >> right thing to do. >> >> Looking at the block diagram of FT232R or FT232H, the CBUS pins seem to >> be part of the UART/FIFO controller. And I think the dual UART FT2232D >> actually supports controlling the CBUS pins of the two UART controllers >> individually, at least the block diagram thereof suggests so. > > The port is a Linux abstraction, and for FTDI we happen to have exactly > one port child device per USB interface. As I see it, the gpio > controller for the CBUS pins should be a sibling rather than a child > device to the port. > > Note that we'd still have two gpio-controllers on FT2232D (one per USB > interface). I did some research. I think the FT2232D or FT2232H devices do not support the CBUS Bit Bang mode. For instance the D2XX Programmer's Guide indicates that on page 69 (CBUS Bit Bang Mode (FT232R and FT232H devices only)) as well as the AN_184 "FTDI Device Input Output Pin States", does not mention that the CBUS pins as EEPROM selectable (the same document does so for FT232R/FT232H devices)... I don't have such a device, hence I can't try it out... > I'm aware that this requires some restructuring of the ftdi_sio-driver > (e.g. the device type and ftdi-interface number should be a feature of > the usb-serial rather than usb-serial-port device). The findings above probably do not change the fact that we should not use the Linux port abstraction to attach the GPIO controller... I looked into that a bit more in depth. Do I see things right that the multi-port devices have multiple USB interfaces, which leads to usb_serial_probe and in turn ftdi_sio_probe getting called multiple times by the USB stack? If yes, I think I have the bigger picture to go ahead and try to implement it accordingly. -- Stefan -- 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 v5 08/23] usb: chipidea: set usb gadeget's otg capabilities
On Wed, Jun 17, 2015 at 07:40:15PM +0800, Li Jun wrote:
> Set gadget's otg capabilities according to controller's capability and otg
> properties in device tree.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/chipidea/core.c | 8
> drivers/usb/chipidea/udc.c | 7 ++-
> include/linux/usb/chipidea.h | 1 +
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 74fea4f..2abecbc 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -588,6 +588,14 @@ static int ci_get_platdata(struct device *dev,
> of_usb_host_tpl_support(dev->of_node);
> }
>
> + if (platdata->dr_mode == USB_DR_MODE_OTG) {
> + /* We can support HNP and SRP */
> + platdata->ci_otg_caps.hnp_support = true;
> + platdata->ci_otg_caps.srp_support = true;
> + /* Update otg capabilities by DT properties */
> + of_usb_set_otg_caps(dev->of_node, &platdata->ci_otg_caps);
> + }
> +
For current dual-role supported platforms (through ID pin), their dts has
nothing
with otg capabilities, what will happen if we set .hnp_support as true?
For non-dt platform (eg i686), how it changes otg capabilities through
their platform data?
Peter
> if (of_usb_get_maximum_speed(dev->of_node) == USB_SPEED_FULL)
> platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 764f668..858bd21 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1827,6 +1827,7 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci)
> static int udc_start(struct ci_hdrc *ci)
> {
> struct device *dev = ci->dev;
> + struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps;
> int retval = 0;
>
> spin_lock_init(&ci->lock);
> @@ -1834,8 +1835,12 @@ static int udc_start(struct ci_hdrc *ci)
> ci->gadget.ops = &usb_gadget_ops;
> ci->gadget.speed= USB_SPEED_UNKNOWN;
> ci->gadget.max_speed= USB_SPEED_HIGH;
> - ci->gadget.is_otg = ci->is_otg ? 1 : 0;
> ci->gadget.name = ci->platdata->name;
> + ci->gadget.otg_caps = otg_caps;
> +
> + if (otg_caps->otg_rev && (otg_caps->hnp_support ||
> + otg_caps->srp_support || otg_caps->adp_support))
> + ci->gadget.is_otg = 1;
>
> INIT_LIST_HEAD(&ci->gadget.ep_list);
>
> diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> index ab94f78..e10cefc 100644
> --- a/include/linux/usb/chipidea.h
> +++ b/include/linux/usb/chipidea.h
> @@ -34,6 +34,7 @@ struct ci_hdrc_platform_data {
> #define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
> void(*notify_event) (struct ci_hdrc *ci, unsigned event);
> struct regulator*reg_vbus;
> + struct usb_otg_caps ci_otg_caps;
> booltpl_support;
> };
>
> --
> 1.9.1
>
--
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 v5 08/23] usb: chipidea: set usb gadeget's otg capabilities
On Wed, Jun 24, 2015 at 11:04:43AM +0800, Peter Chen wrote:
> On Wed, Jun 17, 2015 at 07:40:15PM +0800, Li Jun wrote:
> > Set gadget's otg capabilities according to controller's capability and otg
> > properties in device tree.
> >
> > Signed-off-by: Li Jun
> > ---
> > drivers/usb/chipidea/core.c | 8
> > drivers/usb/chipidea/udc.c | 7 ++-
> > include/linux/usb/chipidea.h | 1 +
> > 3 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 74fea4f..2abecbc 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -588,6 +588,14 @@ static int ci_get_platdata(struct device *dev,
> > of_usb_host_tpl_support(dev->of_node);
> > }
> >
> > + if (platdata->dr_mode == USB_DR_MODE_OTG) {
> > + /* We can support HNP and SRP */
> > + platdata->ci_otg_caps.hnp_support = true;
> > + platdata->ci_otg_caps.srp_support = true;
> > + /* Update otg capabilities by DT properties */
> > + of_usb_set_otg_caps(dev->of_node, &platdata->ci_otg_caps);
> > + }
> > +
>
> For current dual-role supported platforms (through ID pin), their dts has
> nothing
> with otg capabilities, what will happen if we set .hnp_support as true?
>
No impact for them, those platforms will continue work as before(i.e.
otg descriptor with HNP&SRP enabled if CONFIG_USB_OTG is selected,
no otg fsm if CONFIG_USB_OTG_FSM is not selected).
> For non-dt platform (eg i686), how it changes otg capabilities through
> their platform data?
>
Directly override platdata->ci_otg_caps in its platform driver after
ci_hdrc_add_device().
> Peter
> > if (of_usb_get_maximum_speed(dev->of_node) == USB_SPEED_FULL)
> > platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 764f668..858bd21 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1827,6 +1827,7 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci)
> > static int udc_start(struct ci_hdrc *ci)
> > {
> > struct device *dev = ci->dev;
> > + struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps;
> > int retval = 0;
> >
> > spin_lock_init(&ci->lock);
> > @@ -1834,8 +1835,12 @@ static int udc_start(struct ci_hdrc *ci)
> > ci->gadget.ops = &usb_gadget_ops;
> > ci->gadget.speed= USB_SPEED_UNKNOWN;
> > ci->gadget.max_speed= USB_SPEED_HIGH;
> > - ci->gadget.is_otg = ci->is_otg ? 1 : 0;
> > ci->gadget.name = ci->platdata->name;
> > + ci->gadget.otg_caps = otg_caps;
> > +
> > + if (otg_caps->otg_rev && (otg_caps->hnp_support ||
> > + otg_caps->srp_support || otg_caps->adp_support))
> > + ci->gadget.is_otg = 1;
> >
> > INIT_LIST_HEAD(&ci->gadget.ep_list);
> >
> > diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> > index ab94f78..e10cefc 100644
> > --- a/include/linux/usb/chipidea.h
> > +++ b/include/linux/usb/chipidea.h
> > @@ -34,6 +34,7 @@ struct ci_hdrc_platform_data {
> > #define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
> > void(*notify_event) (struct ci_hdrc *ci, unsigned event);
> > struct regulator*reg_vbus;
> > + struct usb_otg_caps ci_otg_caps;
> > booltpl_support;
> > };
> >
> > --
> > 1.9.1
> >
>
> --
>
> 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 v5 08/23] usb: chipidea: set usb gadeget's otg capabilities
On Wed, Jun 24, 2015 at 11:34:23AM +0800, Li Jun wrote:
> On Wed, Jun 24, 2015 at 11:04:43AM +0800, Peter Chen wrote:
> > On Wed, Jun 17, 2015 at 07:40:15PM +0800, Li Jun wrote:
> > > Set gadget's otg capabilities according to controller's capability and otg
> > > properties in device tree.
> > >
> > > Signed-off-by: Li Jun
> > > ---
> > > drivers/usb/chipidea/core.c | 8
> > > drivers/usb/chipidea/udc.c | 7 ++-
> > > include/linux/usb/chipidea.h | 1 +
> > > 3 files changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > > index 74fea4f..2abecbc 100644
> > > --- a/drivers/usb/chipidea/core.c
> > > +++ b/drivers/usb/chipidea/core.c
> > > @@ -588,6 +588,14 @@ static int ci_get_platdata(struct device *dev,
> > > of_usb_host_tpl_support(dev->of_node);
> > > }
> > >
> > > + if (platdata->dr_mode == USB_DR_MODE_OTG) {
> > > + /* We can support HNP and SRP */
> > > + platdata->ci_otg_caps.hnp_support = true;
> > > + platdata->ci_otg_caps.srp_support = true;
> > > + /* Update otg capabilities by DT properties */
> > > + of_usb_set_otg_caps(dev->of_node, &platdata->ci_otg_caps);
> > > + }
> > > +
> >
> > For current dual-role supported platforms (through ID pin), their dts has
> > nothing
> > with otg capabilities, what will happen if we set .hnp_support as true?
> >
> No impact for them, those platforms will continue work as before(i.e.
> otg descriptor with HNP&SRP enabled if CONFIG_USB_OTG is selected,
> no otg fsm if CONFIG_USB_OTG_FSM is not selected).
So if CONFIG_USB_OTG is not chosen, even platdata->ci_otg_caps.hnp_support
is true, it will be act as pure host or peripheral, right?
>
> > For non-dt platform (eg i686), how it changes otg capabilities through
> > their platform data?
> >
> Directly override platdata->ci_otg_caps in its platform driver after
> ci_hdrc_add_device().
After ci_hdrc_add_device, the device may begin to enumerate, we need to
make sure otg capabilities before the device goes to work.
Peter
>
> > Peter
> > > if (of_usb_get_maximum_speed(dev->of_node) == USB_SPEED_FULL)
> > > platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
> > >
> > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > index 764f668..858bd21 100644
> > > --- a/drivers/usb/chipidea/udc.c
> > > +++ b/drivers/usb/chipidea/udc.c
> > > @@ -1827,6 +1827,7 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci)
> > > static int udc_start(struct ci_hdrc *ci)
> > > {
> > > struct device *dev = ci->dev;
> > > + struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps;
> > > int retval = 0;
> > >
> > > spin_lock_init(&ci->lock);
> > > @@ -1834,8 +1835,12 @@ static int udc_start(struct ci_hdrc *ci)
> > > ci->gadget.ops = &usb_gadget_ops;
> > > ci->gadget.speed= USB_SPEED_UNKNOWN;
> > > ci->gadget.max_speed= USB_SPEED_HIGH;
> > > - ci->gadget.is_otg = ci->is_otg ? 1 : 0;
> > > ci->gadget.name = ci->platdata->name;
> > > + ci->gadget.otg_caps = otg_caps;
> > > +
> > > + if (otg_caps->otg_rev && (otg_caps->hnp_support ||
> > > + otg_caps->srp_support || otg_caps->adp_support))
> > > + ci->gadget.is_otg = 1;
> > >
> > > INIT_LIST_HEAD(&ci->gadget.ep_list);
> > >
> > > diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> > > index ab94f78..e10cefc 100644
> > > --- a/include/linux/usb/chipidea.h
> > > +++ b/include/linux/usb/chipidea.h
> > > @@ -34,6 +34,7 @@ struct ci_hdrc_platform_data {
> > > #define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
> > > void(*notify_event) (struct ci_hdrc *ci, unsigned event);
> > > struct regulator*reg_vbus;
> > > + struct usb_otg_caps ci_otg_caps;
> > > booltpl_support;
> > > };
> > >
> > > --
> > > 1.9.1
> > >
> >
> > --
> >
> > Best Regards,
> > Peter Chen
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/3] USB: io_ti: Move request_firmware() calls out of download_fw()
On Mon, 2015-06-22 at 11:43 +0200, Johan Hovold wrote:
> On Thu, Jun 18, 2015 at 06:43:35AM -0500, Peter E. Berger wrote:
> > From: "Peter E. Berger"
> >
> > The io_ti driver fails to download firmware to Edgeport
> > devices such as the EP/416, even when the on-disk firmware image
> > (/lib/firmware/edgeport/down3.bin) is more current than the version
> > on the EP/416. The current download code is broken in a few ways.
> > Notably it mis-uses global variables OperationalMajorVersion and
> > OperationalMinorVersion (reading their values before they've been
> > properly initialized and subsequently initializing them multiple times
> > without synchronization). This patch drops the global variables and
> > replaces the redundant calls to request_firmware()/release_firmware()
> > in download_fw() with a single call pair in edge_startup(); the firmware
> > image pointer is then passed to download_fw() and build_i2c_fw_hdr().
> >
> > Also, the firmware has a "build_number" field, though it apparently is
> > unused (according to observations of the three firmware images I have
> > seen and confirmed by Digi Tech Support). This comment describes its
> > structure, in case it is populated in a future release.
> >
> > Signed-off-by: Peter E. Berger
> > ---
> > drivers/usb/serial/io_ti.c | 100
> > +++--
> > 1 file changed, 51 insertions(+), 49 deletions(-)
> >
> > diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
> > index 69378a7..c76820b 100644
> > --- a/drivers/usb/serial/io_ti.c
> > +++ b/drivers/usb/serial/io_ti.c
> > @@ -101,6 +101,7 @@ struct edgeport_serial {
> > struct mutex es_lock;
> > int num_ports_open;
> > struct usb_serial *serial;
> > + int fw_version;
> > };
> >
> >
> > @@ -187,10 +188,6 @@ static const struct usb_device_id id_table_combined[]
> > = {
> >
> > MODULE_DEVICE_TABLE(usb, id_table_combined);
> >
> > -static unsigned char OperationalMajorVersion;
> > -static unsigned char OperationalMinorVersion;
> > -static unsigned short OperationalBuildNumber;
> > -
> > static int closing_wait = EDGE_CLOSING_WAIT;
> > static bool ignore_cpu_rev;
> > static int default_uart_mode; /* RS232 */
> > @@ -751,18 +748,18 @@ exit:
> > }
> >
> > /* Build firmware header used for firmware update */
> > -static int build_i2c_fw_hdr(__u8 *header, struct device *dev)
> > +static int build_i2c_fw_hdr(u8 *header, struct device *dev,
> > + const struct firmware *fw)
> > {
> > __u8 *buffer;
> > int buffer_size;
> > int i;
> > - int err;
> > __u8 cs = 0;
> > struct ti_i2c_desc *i2c_header;
> > struct ti_i2c_image_header *img_header;
> > struct ti_i2c_firmware_rec *firmware_rec;
> > - const struct firmware *fw;
> > - const char *fw_name = "edgeport/down3.bin";
> > + u8 fw_major_version = fw->data[0];
> > + u8 fw_minor_version = fw->data[1];
> >
> > /* In order to update the I2C firmware we must change the type 2 record
> > * to type 0xF2. This will force the UMP to come up in Boot Mode.
> > @@ -785,24 +782,11 @@ static int build_i2c_fw_hdr(__u8 *header, struct
> > device *dev)
> > // Set entire image of 0xffs
> > memset(buffer, 0xff, buffer_size);
> >
> > - err = request_firmware(&fw, fw_name, dev);
> > - if (err) {
> > - dev_err(dev, "Failed to load image \"%s\" err %d\n",
> > - fw_name, err);
> > - kfree(buffer);
> > - return err;
> > - }
> > -
> > - /* Save Download Version Number */
> > - OperationalMajorVersion = fw->data[0];
> > - OperationalMinorVersion = fw->data[1];
> > - OperationalBuildNumber = fw->data[2] | (fw->data[3] << 8);
> > -
> > /* Copy version number into firmware record */
> > firmware_rec = (struct ti_i2c_firmware_rec *)buffer;
> >
> > - firmware_rec->Ver_Major = OperationalMajorVersion;
> > - firmware_rec->Ver_Minor = OperationalMinorVersion;
> > + firmware_rec->Ver_Major = fw_major_version;
> > + firmware_rec->Ver_Minor = fw_minor_version;
> >
> > /* Pointer to fw_down memory image */
> > img_header = (struct ti_i2c_image_header *)&fw->data[4];
>
> Note that sanity checks on the firmware size are missing here; you could
> fix that as a follow up.
I did some digging and it looks like we can actually do several sanity
checks on the firmware image. It seems that the Edgeport firmware
images have a 7-byte header:
u8 major_version;
u8 minor_version;
le16 build_number;
le16 length;
u8 checksum;
"length" appears to be the number of bytes of actual data following the
header.
"checksum" is apparently (from the images I have seen) the low order
byte resulting from adding the values of all the data bytes.
So, I'm testing a new ck_fw_sanity() function that checks for these
error conditions:
1. NULL (missing) firmware image
2. Incomplete firmware header:
#define FW_HEADER_SIZE 7
fw->size
Re: [PATCH v6 1/3] USB: io_ti: Increase insufficient timeout for firmware downloads
On Mon, 2015-06-22 at 10:45 +0200, Johan Hovold wrote: > On Thu, Jun 18, 2015 at 06:43:34AM -0500, Peter E. Berger wrote: > > From: "Peter E. Berger" > > > > The io_ti driver fails to download firmware to Edgeport devices such as > > the EP/416. One of the problems is that the default 1 second timeout > > in ti_vsend_sync() is insufficient for download operations. This patch > > increases the download timeout to 10 seconds. > > Patch looks good now. > > What happens when download fails? Does the device still work (e.g. this > is only needed to support newer on-disk firmware)? Perhaps you can > mention that in the commit log as well. It looks like some Edgeports (models like the EP/416 with on-board E2PROM) may be able to function even if the on-disk firmware image is bad or missing, iff their local E2PROM versions are valid. But most Edgeport models (I've tried EP/1 and EP/4) do not appear to have this capability and they always rely on the on-disk firmware image. I'm testing an implementation that calls the new check_fw_sanity() function at the top of download_fw() and, rather than simply returning an error if the firmware image is bad or missing, it saves the result and defers the decision until later when it may find that it is running on a E2PROM-equipped device with a valid image. But I think this is messier than it is worth (adding still more messiness to the already very messy download_fw()) for such a marginal possible benefit. I'm leaning towards the simpler approach of returning an error whenever check_fw_sanity() indicates a bad on-disk firmware image. Do you agree? Thanks. --Peter > > Thanks, > Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/3] USB: io_ti: Add heartbeat to keep idle Edgeport ports from disconnecting
On Mon, 2015-06-22 at 12:01 +0200, Johan Hovold wrote:
> On Thu, Jun 18, 2015 at 06:43:36AM -0500, Peter E. Berger wrote:
> > From: "Peter E. Berger"
> >
> > When using newer Edgeport devices such as the EP/416, idle ports are
> > automatically bounced (disconnected and then reconnected) approximately
> > every 60 seconds. This breaks programs (e.g: minicom) where idle periods
> > are common, normal and expected.
> >
> > I confirmed with the manufacturer (Digi International) that some Edgeports
> > now ship from the factory with firmware that expects periodic "heartbeat"
> > queries from the driver to keep idle ports alive. This patch implements
> > heartbeat support using the mechanism Digi suggested (periodically
> > requesting an I2C descriptor address) that appears effective on Edgeports
> > running the newer firmware (that require it) and benign on Edgeport
> > devices running older firmware. Since we know that Edgeport firmware
> > version 4.80 (the version distributed in /lib/firmware/down3.bin and used
> > for Edgeports that are either running still older versions or have no
> > onboard non-volatile firmware image) does not require heartbeat support,
> > this patch schedules heartbeats only on devices running firmware versions
> > newer than 4.80.
> >
> > Signed-off-by: Peter E. Berger
> > ---
> > drivers/usb/serial/io_ti.c | 78
> > +-
> > 1 file changed, 77 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
> > index c76820b..b7c1ea1 100644
> > --- a/drivers/usb/serial/io_ti.c
> > +++ b/drivers/usb/serial/io_ti.c
> > @@ -101,6 +101,7 @@ struct edgeport_serial {
> > struct mutex es_lock;
> > int num_ports_open;
> > struct usb_serial *serial;
> > + struct delayed_work heartbeat_work;
> > int fw_version;
> > };
> >
> > @@ -206,6 +207,18 @@ static void edge_send(struct usb_serial_port *port,
> > struct tty_struct *tty);
> > static int edge_create_sysfs_attrs(struct usb_serial_port *port);
> > static int edge_remove_sysfs_attrs(struct usb_serial_port *port);
> >
> > +/*
> > + * Some release of Edgeport firmware "down3.bin" after version 4.80
> > + * introduced code to automatically disconnect idle devices after periods
> > + * of inactivity, typically ~60 seconds. This occurs without regard to
> > + * whether ports on the device are open or not. Digi International Tech
> > + * Support suggested adding driver "heartbeat" code to reset the firmware
> > + * timer by requesting a descriptor record every 15 seconds, which should
> > be
> > + * effective with newer firmware versions that require it, and benign with
> > + * older versions that do not. In practice 40 seconds seems often enough.
> > + */
> > +#define FW_HEARTBEAT_VERSION_CUTOFF ((4 << 8) + 80)
> > +#define FW_HEARTBEAT_SECS 40
> >
> > /* Timeouts in msecs: firmware downloads take longer */
> > #define TI_VSEND_TIMEOUT_DEFAULT 1000
> > @@ -2354,6 +2367,36 @@ static void edge_break(struct tty_struct *tty, int
> > break_state)
> > __func__, status);
> > }
> >
> > +static void edge_heartbeat_work(struct work_struct *work)
> > +{
> > + struct edgeport_serial *serial;
> > + struct ti_i2c_desc *rom_desc;
> > +
> > + serial = container_of(work, struct edgeport_serial,
> > + heartbeat_work.work);
> > +
> > + rom_desc = kmalloc(sizeof(*rom_desc), GFP_KERNEL);
> > +
> > + /* Descriptor address request is enough to reset the firmware timer */
> > + if (!rom_desc || !get_descriptor_addr(serial, I2C_DESC_TYPE_ION,
> > + rom_desc)) {
> > + dev_err(&serial->serial->interface->dev,
> > + "%s - Incomplete heartbeat\n", __func__);
> > + }
> > + kfree(rom_desc);
> > +
> > + schedule_delayed_work(&serial->heartbeat_work, FW_HEARTBEAT_SECS * HZ);
>
> Use the helper here as well.
Done.
>
> > +}
> > +
> > +static inline void edge_heartbeat_reschedule(struct edgeport_serial
> > + *edge_serial)
>
> Odd line break, rename edge_serial or break after void instead if needed.
Done.
>
> Perhaps just edge_heartbeat_schedule would have been a better name.
Done.
>
> > +{
> > + if (edge_serial->fw_version > FW_HEARTBEAT_VERSION_CUTOFF) {
>
> Return if <= cutoff instead.
Done.
I'm zeroing in on a v7 patchset, which I hope to have ready tomorrow or
so.
Thanks.
--Peter
>
> > + schedule_delayed_work(&edge_serial->heartbeat_work,
> > + FW_HEARTBEAT_SECS * HZ);
> > + }
> > +}
>
> Looks good otherwise.
>
> Thanks,
> Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: usleep_range is preferred over udelay where wakeup is flexible
According to Documentation/timers/timers-howto.txt"
udelay() is only called once from a place where sleeping is allowed.
We can replace it with a call to usleep_range()
with a reasonable upper limit.
Signed-off-by: Sunny Kumar
---
drivers/usb/storage/transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index 540add2..7cd45ac 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -,7 +,7 @@ int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct
us_data *us)
* command phase and the data phase. Some devices need a little
* more than that, probably because of clock rate inaccuracies. */
if (unlikely(us->fflags & US_FL_GO_SLOW))
- udelay(125);
+ usleep_range(100, 125);
if (transfer_length) {
unsigned int pipe = srb->sc_data_direction == DMA_FROM_DEVICE ?
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
