RE: [PATCH 2/3 v2] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
> > {
> > u32 portsc, lpm, sts = 0;
> >
> > switch (ci->platdata->phy_mode) {
> > case USBPHY_INTERFACE_MODE_UTMI:
> > portsc = PORTSC_PTS(PTS_UTMI);
> > @@ -273,10 +275,12 @@ static void hw_phymode_configure(struct ci_hdrc
> *ci)
> >
> > if (ci->hw_bank.lpm) {
> > hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
> > - hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
> > + if (sts)
> > + hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
> > } else {
> > hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
> > - hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
> > + if ( sts )
> > + hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
>
> The conditions coding style is broken.
>
> > }
> > }
>
> Still don't get why a system with ehci compliant PORTSC register
> should not want to have the sts bit _explicitly_ set to 0 if
> we don't use serial phy mode. So NACK!
>
At current code the PORTSC_STS is set to unknown value due to sts is
uninitialized, and it causes ARM internal error at Chris's imx27 platform.
This patch just gives sts an initialized value, and only set PORTSC_STS
for serial phy, it follows the code original logic mostly.
Until now, no one reports problem due to the wrong value of PORTSC_STS, it means
both 1 and 0 are working for most of platforms. So, just keep its current logic
until someone blames.
The chipidea datasheet said "This bit has no effect unless Parallel Transceiver
Select is set to UTMI+.",
my imx6 uses UTIM+, but the controller works fine whether PORTSC_STS is 0 or 1.
My original idea is just delete the code about PORTSC_STS, but chris
mentions it is used by serial phy at current logic, then, just keep current
logic.
Peter
> Michael
>
> --
> Pengutronix e.K. |
> |
> Industrial Linux Solutions | http://www.pengutronix.de/
> |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-
> |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3 v3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
>
> usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
>
> * init the sts flag to 0 (missed)
> * Set PORTCS_STS only if VUSB_HS_PHY_TYPE > 1
> otherwise the register is ReadOnly
> * Set/Reset correct BIT(28)/BIT(29) for STS
>
> Signed-off-by: Chris Ruehl
> ---
> drivers/usb/chipidea/core.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 5075407..2c634c1 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -243,7 +243,7 @@ static int hw_device_init(struct ci_hdrc *ci, void
> __iomem *base)
>
> static void hw_phymode_configure(struct ci_hdrc *ci)
> {
> - u32 portsc, lpm, sts;
> + u32 portsc, lpm, sts = 0;
>
> switch (ci->platdata->phy_mode) {
> case USBPHY_INTERFACE_MODE_UTMI:
> @@ -273,10 +273,24 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
>
> if (ci->hw_bank.lpm) {
> hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
> - hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
> + if ( sts )
> + hw_write(ci, OP_DEVLC, DEVLC_STS, BIT(28));
> + else
> + hw_write(ci, OP_DEVLC, DEVLC_STS, ~BIT(28));
> } else {
> hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
> - hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
> + if (((portsc >> 30) & 0x3) > 1) {
> + if (sts) {
> + hw_write(ci, OP_PORTSC, PORTSC_STS, BIT(29));
> + }
> + else {
> + portsc =
> (ioread32(ci->hw_bank.regmap[OP_PORTSC])
> + & PORTSC_STS);
> + if (portsc)
> + hw_write(ci, OP_PORTSC, PORTSC_STS,
> + ~BIT(29));
> + }
> + }
> }
> }
>
> --
At my chipidea datasheet, the VUSB_HS_PHY_SERIAL is at HWGENERAL (bit[10..11]),
We are still not sure the portsc_sts is needed to set or clear, and how to do
it. My suggestion is just use v2 patch (except fixing one code style problem)
Peter
--
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 0/3] usb: ehci+chipidea: fix imx28 "ENGR119653 USB: ARM to USB register error issue"
On 11/26/2013 01:11 PM, Peter Chen wrote: > Changes for v6: > - Add volatile for arm swp instruction, since we need io access > to fix this problem > - Add kernel style comment for imx28_write_fix > > Peter Chen (3): > usb: ehci: add freescale imx28 special write register method > usb: chipidea: add freescale imx28 special write register method > usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28 > > drivers/usb/chipidea/ci.h | 26 -- > drivers/usb/chipidea/ci_hdrc_imx.c | 32 ++-- > drivers/usb/chipidea/core.c|2 ++ > drivers/usb/chipidea/host.c|1 + > drivers/usb/host/ehci.h| 18 +- > include/linux/usb/chipidea.h |1 + > 6 files changed, 71 insertions(+), 9 deletions(-) Alexander, this is Peter Chens's and my final version of the patch. Can you please have a look at it? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/1] usb: chipidea: fix nobody cared IRQ when booting with host role
On 11/22/2013 09:14 AM, Peter Chen wrote: > If we connect Male-A-To-Male-A cable between otg-host and host pc, > the ci->vbus_active is set wrongly, and cause the controller run > at peripheral mode when we load gadget module (ci_udc_start will be run), > but the software runs at host mode due to id = 0. The ehci_irq > can't handle suspend (USBi_SLI) interrupt which is enabled for > peripheral mode, it causes no one will handle irq error. > > Cc: sta...@vger.kernel.org # 3.12 > Acked-by: Michael Grzeschik > Reported-by: Marc Kleine-Budde > Tested-by: Marc Kleine-Budde > Signed-off-by: Marc Kleine-Budde > Signed-off-by: Peter Chen Alexander, please have a look at this patch. Thanks, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: USB instabilities with Atheros AR9344
On Fri, 29 Nov 2013, Kristian Evensen wrote: > Hi, > > Thank you very much for the quick reply. > > On Fri, Nov 29, 2013 at 4:13 PM, Alan Stern wrote: > > The most common reason for -71 errors is that the device failed to send > > a reply or handshake packet back to the host. Generally this is caused > > by a bug in the device's firmware (it can also be caused by unplugging > > the USB cable, but obviously that didn't happen here). Ideally, if you > > knew what caused the device to go into this buggy state, you could > > avoid the situation. > > Thanks for the pointer. I have to admit I am a little bit unsure about > what you refer to by device, do you mean the modem or the SoC USB hub? > As it seems like most of the retransmitted packets are the big ones > (1514 bytes), I guess it is the hub that does not ACK? By "device", I mean the piece of hardware that is supposed to reply to the host. In your case that would be the modem (the hub does not make up replies to packets that were sent to the modem). On the other hand, it is true that in some circumstances, problems in the hub could mess up communications between the host and the modem. This could happen if the hub communicates at high speed (480 Mb/s) and the modem communicates at full speed (12 Mb/s). > > It would not help. Once the device stops replying to the host, it > > pretty much doesn't matter what you do on the host. The only way to > > address the problem is to do some sort of error recovery on the device. > > One interesting observations is that the modems seems to work fine > after this happens. They reattach to the network, switch between > UMTS/LTE and so forth. This may indicate the problem is in the hub. But if it is, there isn't much you can do about it. > > You could try doing a USB reset of the device. Of course, this is > > likely to cause the device to lose all its settings, so it may end up > > being worse than the original problem. > > Thanks, this is what we are currently experimenting with. Since it > seems to be a bug in the device, we made a quick hack where we monitor > the output from the kernel and reset USB as soon as -71 is seen. We > have also patched the qh_completions()-functions to drop packets where > qtd->length - QTD_LENGTH(token) == 0, to shorten the wait for the usb > reset to be detected. After a reset, the USB hub + modems work fine. > > One thing I have noticed is that when this error occurs with > option_serial, a usb reset (by using gpio) is detected immediately. > This is not the case with qmi-modems, which use cdc_wdm, they hang > until packets on the queue have been retransmitted (and we have > disconnected the devices). Is this expected behavior? I have no idea. I don't know how the various CDC drivers work. 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] add new pid for alcatel re-shape some alcatel pid list
On Sat, Nov 30, 2013 at 10:32:28PM +0800, shu.suo wrote: > From: "suo.suo" > > Signed-off-by: suo.suo > --- > drivers/usb/serial/option.c | 58 > - > 1 file changed, 47 insertions(+), 11 deletions(-) > > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c > index c3d9485..c6c4a3c 100644 > --- a/drivers/usb/serial/option.c > +++ b/drivers/usb/serial/option.c > @@ -283,7 +283,16 @@ static void option_instat_callback(struct urb *urb); > #define ALCATEL_VENDOR_ID0x1bbb > #define ALCATEL_PRODUCT_X060S_X200 0x > #define ALCATEL_PRODUCT_X220_X500D 0x0017 > -#define ALCATEL_PRODUCT_L100V0x011e > +#define ALCATEL_PRODUCT_0052 0x0052 > +#define ALCATEL_PRODUCT_L100V 0x011e > +#define ALCATEL_PRODUCT_00B6 0x00B6 > +#define ALCATEL_PRODUCT_X6000x00B7 > +#define ALCATEL_PRODUCT_Y800_X715 0x0191 > +#define ALCATEL_PRODUCT_01920x0192 > +#define ALCATEL_PROCUCT_01940x0194 > +#define ALCATEL_PRODUCT_01AA 0x01AA > +#define ALCATEL_PRODUCT_02030x0203 > +#define ALCATEL_PRODUCT_02040x0204 Why the very odd formatting of this list? Also, why did you drop the linux-usb@vger.kernel.org mailing list from the cc:? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some question about period scheduleing
On Fri, 29 Nov 2013, vichy wrote: > hi all: > My connection like below > ehci --> high speed hub -> full speed device > > I have some questions about period scheduling. > 1. when creating qh for full speed device, why we set EHCI_TUNE_RL_TT. Are you asking why EHCI_TUNE_RL_TT is equal to 0? I don't know -- it looks like a mistake. Do you find that changing it to 3 makes any difference? > isn't it possible the full speed device return NAK during transaction? Of course it is possible. > that mean once it react with NAK, the host will stop below transaction. The host stops the transaction temporarily. It will restart the transaction later. See section 4.9.1 in the EHCI spec. > How could we make sure device never react with NAK? There is no way to do that. > 2. I attach my mon log for your reference. > there is one thing I am curious > why below message 'E' mean in bulk/interrupt? > I have checked Document/usb/usbmon.txt but get nothing. E means the preceding submission failed. > d8c32600 190047566 E Bi:1:006:2 -19 0 > d8c32980 190062351 C Bi:1:006:2 -107 0 > d8c32980 190062363 S Bi:1:006:2 -115 1025 < > d8c32980 190072803 E Bi:1:006:2 -19 0 For example, this E means the submission on the line above was unsuccessful. The error code -19 is -ENODEV, which means the device has been disconnected. This is described in Documentation/usb/usbmon.txt: - Event Type. This type refers to the format of the event, not URB type. Available types are: S - submission, C - callback, E - submission error. 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 2/3 v3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
Hello.
On 30-11-2013 7:51, Chris Ruehl wrote:
usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
* init the sts flag to 0 (missed)
* Set PORTCS_STS only if VUSB_HS_PHY_TYPE > 1
otherwise the register is ReadOnly
* Set/Reset correct BIT(28)/BIT(29) for STS
Signed-off-by: Chris Ruehl
The coding style is still wrong at places...
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 5075407..2c634c1 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
[...]
@@ -273,10 +273,24 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
if (ci->hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
- hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+ if ( sts )
Remove spaces around 'sts', please.
+ hw_write(ci, OP_DEVLC, DEVLC_STS, BIT(28));
+ else
+ hw_write(ci, OP_DEVLC, DEVLC_STS, ~BIT(28));
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
- hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+ if (((portsc >> 30) & 0x3) > 1) {
+ if (sts) {
+ hw_write(ci, OP_PORTSC, PORTSC_STS, BIT(29));
+ }
+ else {
} else {
+ portsc =
(ioread32(ci->hw_bank.regmap[OP_PORTSC])
+ & PORTSC_STS);
No need for outer (). And it's preferred that an operator is left at the
end of a first line, not starts the continuation line.
WBR, Sergei
--
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] Staging: dwc2: hcd.c: Fixed a coding style issue
Fixed a coding style issue, specifically:
Line 1798: Removed parentheses since return is not a function.
Signed-off-by: Aldo Iljazi
---
drivers/staging/dwc2/hcd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index 3cfd2d5..173aa05 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
@@ -1795,7 +1795,7 @@ int dwc2_hcd_get_frame_number(struct dwc2_hsotg *hsotg)
int dwc2_hcd_is_b_host(struct dwc2_hsotg *hsotg)
{
- return (hsotg->op_state == OTG_STATE_B_HOST);
+ return hsotg->op_state == OTG_STATE_B_HOST;
}
static struct dwc2_hcd_urb *dwc2_hcd_urb_alloc(struct dwc2_hsotg *hsotg,
--
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] usb: phy: am335x: Prevent GPIO reset line request
On Thu, Nov 21, 2013 at 07:01:55AM -0600, Felipe Balbi wrote: > On Thu, Nov 21, 2013 at 08:55:20AM -0300, Ezequiel Garcia wrote: > > On Thu, Nov 21, 2013 at 12:44:51PM +0100, Sebastian Andrzej Siewior wrote: > > > On 11/21/2013 12:30 PM, Ezequiel Garcia wrote: > > > > Ah, good to know. That patch should be picked ASAP, without it the USB > > > > in AM335x is broken. Is it already too late to -rc1? > > > Yes. > > > > > > > Who is supposed to merge that? Greg? > > > > > > Felipe will start collecting fixes once -rc1 is out [0] so it should be > > > part of -rc2. > > > > > > > OK, fine by me. Please note that Felipe's commit is a much bigger (and > > nicer) rework of the code, and that it doesn't clearly state it fixes > > the current code. > > > > Felipe: Maybe you should add some message stating it fixes a regression? > > sure, makes sense. Sebastian had already mentioned it sounded too nice > of a commit log ;-) > I'm looking at -rc2 and it seems the fix was never pushed, so my board is probably still broken :-( Can anybody _please_please_ fix the issue by merging some fix so we can use USB with mainline? (FWIW, the fix from Felipe (pointed out by Sebastian) is sitting at linux-next). Thanks a lot! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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 v6 00/17] add COMMON_CLK support for PowerPC MPC512x
this series introduces support for the common clock framework (CCF,
COMMON_CLK Kconfig option) in the PowerPC based MPC512x platform,
which brings device tree based clock lookup as well
at subsystem maintainers:
this series was streamlined for conflict free application through the
subsystems' individual trees, and consists of the following phases
- PCI peripheral driver cleanup (1/17) (may get dropped if the
Layerscape series gets preferred)
- introduction of CCF support including migration workarounds and
backwards compatibility, device tree updates (2/17 - 7/17) --
nevertheless I suggest to take the .dts/.dtsi updates through the
PowerPC tree, the extensions are straight forward and strictly are
clock related, and complement the CCF platform support
- peripheral driver adjustment to the CCF approach (8/17 - 16/17)
- removal of migration workarounds (17/17)
at device tree maintainers:
- the series does not introduce new bindings, it implements the existing
clock binding (OF clock provider, DT based clock lookup) and so
adjusts and extends DTS files
- the code is backwards compatible, and keeps working with device trees
which don't contain clock related information
the series is based on v3.13-rc1
the series passes 'checkpatch.pl --strict' except for one warning which
cannot get resolved, since the API dictates the
data type, "fixing" the checkpatch warning would break compilation
WARNING: static const char * array should probably be static const char *
const
#421: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:343:
+static const char *parent_names_mux0[] = {
total: 0 errors, 1 warnings, 0 checks, 835 lines checked
the series has been build tested (each step on PowerPC 512x, 52xx, 5xxx
multi platform, 83xx, 85xx, 86xx, and on ARM v6/v7), run tested (each
step on 512x, the switch to CCF on 52xx), and tested for backwards
compatibility (each step on 512x with a v3.11 dtb file)
changes in v6 (2013-11-30)
- catch up with changes between v3.12 and v3.13-rc1 (conflict
resolution, explicit include for in 4/17)
- remove the no longer referenced file from
arch/powerpc/include/ in the s/PPC_CLOCK/COMMON_CLK/ switch (7/17)
changes in v5 (2013-11-18)
- extend comments in the PCI driver cleanup (probe() vs setup_arch()
discussion, no code change); all other peripheral driver cleanup from
v4 was taken into mainline
- concentrate migration support in a separate routine for improved
maintainability
- fix the oscillator frequency lookup ('osc' reference) in the CCF
platform support code which creates the clock tree
- add backwards compatibility with device trees that lack clock specs,
concentrate compat support in a separate routine for improved
maintainability, add it in a separate patch for easier review
- consistent use of the 'ipg' name in DTS files for the register access
clock item of peripherals
- switch from PPC_CLOCK to COMMON_CLK at the same time for 512x and 52xx
(keep multi-platform setups operational), in a separate patch
- move removal of migration support to the very end of the series, it's
no longer intertwined with peripheral driver adjustment
- SPI and UART: get 'mclk' and 'ipg' clock items in a more consistent
order (less obfuscation in the diff)
- add/adjust Cc: and Acked-By: entries, rework commit messages and
comments where appropriate
changes in v4 (2013-08-06)
- remove explicit devm_clk_put() calls as these will occur implicitly
upon device release (01/31, 02/31, 03/31, 04/31, 05/31, 06/31, 08/31,
09/31, 27/31)
- split the PSC (SPI, UART) and MSCAN (CAN) related MCLK subtrees into
separate 'ipg'/'bdlc' gated clock items for register access as well as
the 'mclk' clock subtrees that apply to bitrates -- this eliminates
the need for "shared gates" and further reduces clock pre-enable
workarounds (11/31, 15/31, 17/31, 18/31, 20/31, 21/31, 22/31, 27/31)
- further adjust the CAN clock driver, fix an incomplete error code path
in the network device open callback (11/31), only enable the bitrate
clock when the network device is open (27/31)
- remove debug output in the clock tree setup when introducing the
platform's clock driver, there already is CONFIG_COMMON_CLK_DEBUG to
retrieve more complete information (17/31)
- remove an "enums don't work here" comment in the dt-bindings header
file (15/31)
- reword and update commit messages (body and/or subject) where
appropriate (03/31, 04/31, 05/31, 06/31, 08/31, 09/31, 11/31, 12/31,
17/31, 20/31, 21/31, 22/31, 27/31, 28/31, 30/31, 31/31)
- add 'Reviewed-By' attributes which were received for v3
changes in v3 (2013-07-22)
- rebase the series against v3.11-rc2
- re-ordered the series to first address all general clock handling
concerns in existing drivers, before introducing common clock support
in the platform's clock driver
- slightly rework the SPI (01/31), UART (02/31), and PSC FIFO (23/31)
clock handling in comparison to v2 which introduced those fixes
[PATCH v6 11/17] USB: fsl-mph-dr-of: adjust for OF based clock lookup
after device tree based clock lookup became available, the peripheral
driver need no longer construct clock names which include the component
index -- remove the "usb%d_clk" template, always use "ipg" instead
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Signed-off-by: Gerhard Sittig
---
drivers/usb/host/fsl-mph-dr-of.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index abd5050a4899..9162d1b6c0a3 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -261,19 +261,8 @@ int fsl_usb2_mpc5121_init(struct platform_device *pdev)
struct fsl_usb2_platform_data *pdata = dev_get_platdata(&pdev->dev);
struct clk *clk;
int err;
- char clk_name[10];
- int base, clk_num;
-
- base = pdev->resource->start & 0xf000;
- if (base == 0x3000)
- clk_num = 1;
- else if (base == 0x4000)
- clk_num = 2;
- else
- return -ENODEV;
- snprintf(clk_name, sizeof(clk_name), "usb%d_clk", clk_num);
- clk = devm_clk_get(pdev->dev.parent, clk_name);
+ clk = devm_clk_get(pdev->dev.parent, "ipg");
if (IS_ERR(clk)) {
dev_err(&pdev->dev, "failed to get clk\n");
return PTR_ERR(clk);
--
1.7.10.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 v5 00/17] ARM: at91: move to common clk framework
Quoting Boris BREZILLON (2013-11-12 12:51:52) > Hello, > > This patch series is the 5th version of the at91 clk implementations > using the Common Clk Framework. Thanks for sending this latest version. A couple recurring themes to be addressed: 1) Some clocks implement .prepare and .disable but not .unprepre nor .enable. Please only use .prepare and .unprepare in this case. 2) Remove the file names & paths from the comment block at the top of the files. These are minor issues. Are you taking these through your platform tree or the clk tree? If you want to take them through your platform tree then feel free to add my acked-by to the next version. Regards, Mike > > Most of the clock provided by the PMC (Power Management Controller) are > implemented : > - main clock (main oscillator) > - pll clocks > - master clock > - programmable clocks > - utmi clock > - peripheral clocks > - system clocks > > Actually some clk drivers are missing (slow clk, main clk and processor > clk), and some drivers only implement a subset of the hardware capabilities > (master clk rate change is missing). > But this series implements all the already available clks, and I will > hopefully > add missing features in a near future. > > This implementation is only compatible with device tree definition. > The goal is to define the whole clock tree using the device tree. > > BTW, could a dt maintainer take a look at these dt bindinds ? > > Just a note to let you know these bindings are currently unstable and might > change in the future. > > > Mike, I know you already acked the previous version, but I slighty changed > the dt bindings, according to some feedbacks I got during ELCE. > Could you take a look at this new version (at least the new dt bindings), > and add your acked-by if you agree with these changes ? > > Best Regards, > Boris > > Changes since v4: > - rework dt bindings: >* replace "atmel,clk-id" property by the standard "reg" property >* reference system, peripheral and programmable clks using the direct > clk node instead of the parent node plus a clk id > - provide a new helper function (of_at91_get_clk_range) to retrieve a clk >range from the device tree > > Changes since v3: > - simplify master clk implementation (drop set_rate/parent support) > - fix bug in set_rate function of pll driver > - fix coding style issues > - define macros and constants where needed > - remove peripheral id macro references > - remove sam9g35 specific handling (sam9g35 = sam9x5) > - rework main clk prepare function to handle automatic rate calculation > > Changes since v2: > - fix several bugs in clk implementations > - drop non-dt boards support > - split the series to ease review and tests: >* 1 patch series for new clk implementations (this series) >* 1 patch series to move each at91 SoC to common clk framework (coming > soon) > - modify dt-bindings (add atmel,clk- prefix to atmel specific properties) > - add clk macros for dt-bindings > - add pmc framework (helper function to access pmc registers) > - add interrupt support to enable passive wait in clk_prepare functions > > Changes since v1: > - fix bugs in pll, programmable and system clock implementations >(wrong bit position). > - add usb clock configuration support (ohci and udc drivers + >clk_lookup for non dt boards) > - rework of the system clock interfaces (no need to define a parent clock, >system clock is a gate with no rate info) > - change system, peripheral and programmable clk dt bindings (1 master node >and multiple child nodes each defining a system/peripheral or prog clock) > - fix bugs in sama5 dt definition > > Boris BREZILLON (17): > ARM: at91: move at91_pmc.h to include/linux/clk/at91_pmc.h > ARM: at91: add Kconfig options for common clk support > clk: at91: add PMC base support > clk: at91: add PMC macro file for dt definitions > clk: at91: add PMC main clock > clk: at91: add PMC pll clocks > clk: at91: add PMC master clock > clk: at91: add PMC system clocks > clk: at91: add PMC peripheral clocks > clk: at91: add peripheral clk macros for peripheral clk dt bindings > clk: at91: add PMC programmable clocks > clk: at91: add PMC utmi clock > clk: at91: add PMC usb clock > clk: at91: add PMC smd clock > clk: at91: add PMC clk device tree binding doc. > ARM: at91: move pit timer to common clk framework > ARM: at91: add new compatible strings for pmc driver > > .../devicetree/bindings/clock/at91-clock.txt | 339 + > arch/arm/mach-at91/Kconfig | 44 ++ > arch/arm/mach-at91/Kconfig.non_dt |6 + > arch/arm/mach-at91/Makefile|2 +- > arch/arm/mach-at91/at91rm9200.c|2 +- > arch/arm/mach-at91/at91sam9260.c |2 +- > arch/arm/mach-at91/at91sam9261.c |2 +- > arch/arm/mach-at91/at91sam9263.c
Re: [PATCH v6 00/16] ARM: at91: move to common clk framework
Quoting Boris BREZILLON (2013-11-28 04:36:24) > Hello, > > This patch series is the 5th version of the at91 clk implementations > using the Common Clk Framework. Oops, I just replied to v5 of this series. Thanks for the fixes. Which tree do you want this to go through? Regards, Mike > > Most of the clock provided by the PMC (Power Management Controller) are > implemented : > - main clock (main oscillator) > - pll clocks > - master clock > - programmable clocks > - utmi clock > - peripheral clocks > - system clocks > > Actually some clk drivers are missing (slow clk, main clk and processor > clk), and some drivers only implement a subset of the hardware capabilities > (master clk rate change is missing). > But this series implements all the already available clks, and I will > hopefully > add missing features in a near future. > > This implementation is only compatible with device tree definition. > The goal is to define the whole clock tree using the device tree. > > Just a note to let you know these bindings are currently unstable and might > change in the future. > > > Best Regards, > Boris > > Changes since v5: > - remove peripheral divisors macros from dt binding include file > - remove file path from comment blocks > - replace pll and utmi disable function by unprepare function to >avoid issue when disabling and reenabling a clk > - fix programmable clk interrupt retrieval > - fix OF_CLK_DECLARE names (xxx_clk_main -> xxx_clk_pmc) > - add missing comma in at91rm9200 main clk dt declaration > - fix num_parents check in smd clk driver > > Changes since v4: > - rework dt bindings: >* replace "atmel,clk-id" property by the standard "reg" property >* reference system, peripheral and programmable clks using the direct > clk node instead of the parent node plus a clk id > - provide a new helper function (of_at91_get_clk_range) to retrieve a clk >range from the device tree > > Changes since v3: > - simplify master clk implementation (drop set_rate/parent support) > - fix bug in set_rate function of pll driver > - fix coding style issues > - define macros and constants where needed > - remove peripheral id macro references > - remove sam9g35 specific handling (sam9g35 = sam9x5) > - rework main clk prepare function to handle automatic rate calculation > > Changes since v2: > - fix several bugs in clk implementations > - drop non-dt boards support > - split the series to ease review and tests: >* 1 patch series for new clk implementations (this series) >* 1 patch series to move each at91 SoC to common clk framework (coming > soon) > - modify dt-bindings (add atmel,clk- prefix to atmel specific properties) > - add clk macros for dt-bindings > - add pmc framework (helper function to access pmc registers) > - add interrupt support to enable passive wait in clk_prepare functions > > Changes since v1: > - fix bugs in pll, programmable and system clock implementations >(wrong bit position). > - add usb clock configuration support (ohci and udc drivers + >clk_lookup for non dt boards) > - rework of the system clock interfaces (no need to define a parent clock, >system clock is a gate with no rate info) > - change system, peripheral and programmable clk dt bindings (1 master node >and multiple child nodes each defining a system/peripheral or prog clock) > - fix bugs in sama5 dt definition > > Boris BREZILLON (16): > ARM: at91: move at91_pmc.h to include/linux/clk/at91_pmc.h > ARM: at91: add Kconfig options for common clk support > clk: at91: add PMC base support > clk: at91: add PMC macro file for dt definitions > clk: at91: add PMC main clock > clk: at91: add PMC pll clocks > clk: at91: add PMC master clock > clk: at91: add PMC system clocks > clk: at91: add PMC peripheral clocks > clk: at91: add PMC programmable clocks > clk: at91: add PMC utmi clock > clk: at91: add PMC usb clock > clk: at91: add PMC smd clock > dt: binding: add at91 clks dt bindings documentation > ARM: at91: move pit timer to common clk framework > ARM: at91: add new compatible strings for pmc driver > > .../devicetree/bindings/clock/at91-clock.txt | 339 + > arch/arm/mach-at91/Kconfig | 44 ++ > arch/arm/mach-at91/Kconfig.non_dt |6 + > arch/arm/mach-at91/Makefile|2 +- > arch/arm/mach-at91/at91rm9200.c|2 +- > arch/arm/mach-at91/at91sam9260.c |2 +- > arch/arm/mach-at91/at91sam9261.c |2 +- > arch/arm/mach-at91/at91sam9263.c |2 +- > arch/arm/mach-at91/at91sam926x_time.c | 14 +- > arch/arm/mach-at91/at91sam9g45.c |2 +- > arch/arm/mach-at91/at91sam9n12.c |2 +- > arch/arm/mach-at91/at91sam9rl.c|2 +- > arch/arm/mach-at91/at91sam9x5.c|2 +
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
Hi
On Sat, Nov 30, 2013 at 6:10 AM, Michael Trimarchi
wrote:
> Hi
>
> On Sat, Nov 30, 2013 at 5:48 AM, Michael Trimarchi
> wrote:
>> Hi Roger
>>
>> On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros wrote:
>>> With u-boot 2013.10, USB devices are sometimes not detected
>>> on OMAP4 Panda. To make us independent of what bootloader does
>>> with the USB Host module, we must RESET it to get it to a known
>>> good state. This patch Soft RESETs the USB Host module.
>>>
>>> Reported-by: Tomi Valkeinen
>>> Cc: # 3.10+
>>> Signed-off-by: Roger Quadros
>>> ---
>>> drivers/mfd/omap-usb-host.c | 115
>>> +---
>>> 1 file changed, 109 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>>> index 142650f..d4bd464 100644
>>> --- a/drivers/mfd/omap-usb-host.c
>>> +++ b/drivers/mfd/omap-usb-host.c
>>> @@ -43,14 +43,18 @@
>>> /* UHH Register Set */
>>> #defineOMAP_UHH_REVISION (0x00)
>>> #defineOMAP_UHH_SYSCONFIG (0x10)
>>> -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1 << 12)
>>> +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3 << 12)
>>> +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT (12)
>>> #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1 << 8)
>>> -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1 << 3)
>>> +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3 << 3)
>>> +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT (3)
>>> #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1 << 2)
>>> #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1 << 1)
>>> #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1 << 0)
>>>
>>> #defineOMAP_UHH_SYSSTATUS (0x14)
>>> +#define OMAP_UHH_SYSSTATUS_RESETDONE (1 << 0)
>>> +
>>> #defineOMAP_UHH_HOSTCONFIG (0x40)
>>> #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1 << 0)
>>> #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS (1 << 0)
>>> @@ -66,10 +70,10 @@
>>> #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1 << 31)
>>>
>>> /* OMAP4-specific defines */
>>> -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3 << 2)
>>> -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1 << 2)
>>> -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3 << 4)
>>> -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1 << 4)
>>> +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK (3 << 2)
>>> +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
>>> +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK (3 << 4)
>>> +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
>>> #define OMAP4_UHH_SYSCONFIG_SOFTRESET (1 << 0)
>>>
>>> #define OMAP4_P1_MODE_CLEAR(3 << 16)
>>> @@ -81,6 +85,12 @@
>>>
>>> #defineOMAP_UHH_DEBUG_CSR (0x44)
>>>
>>> +/* MIDLE modes */
>>> +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
>>> +
>>> +/* SIDLE modes */
>>> +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
>>> +
>>> /* Values of UHH_REVISION - Note: these are not given in the TRM */
>>> #define OMAP_USBHS_REV10x0010 /* OMAP3 */
>>> #define OMAP_USBHS_REV20x50700100 /* OMAP4 */
>>> @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct
>>> usbhs_hcd_omap *omap,
>>> return reg;
>>> }
>>>
>>
>> I'm digging in the code but as I understand this should be done by
>> omap_hwmod and
>> i660 avoid reset of the ehci module. This is done by ocp_softreset?
>>
>>
>>> +static void omap_usbhs_rev1_reset(struct device *dev)
>>> +{
>>> + struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
>>> + u32 reg;
>>> + unsigned long timeout;
>>> +
>>> + reg = usbhs_read(omap->uhh_base, OMAP_UHH_SYSCONFIG);
>>> +
>>> + /* Soft Reset */
>>> + usbhs_write(omap->uhh_base, OMAP_UHH_SYSCONFIG,
>>> + reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
>>> +
>>> + timeout = jiffies + msecs_to_jiffies(100);
>>> + while (!(usbhs_read(omap->uhh_base, OMAP_UHH_SYSSTATUS)
>>> + & OMAP_UHH_SYSSTATUS_RESETDONE)) {
>>> + cpu_relax();
>>> +
>>> + if (time_after(jiffies, timeout)) {
>>> + dev_err(dev, "Soft RESET operation timed out\n");
>>> + break;
>>> + }
>>> + }
>>> +
>>> + /* Set No-Standby */
>>> + reg &= ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
>>> + reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
>>> + << OMAP_UHH_SYSCONFIG_MIDLESHIFT;
>>> +
>>> + /* Set No-Idle */
>>> + reg &= ~OMAP_UHH_SYSCONFIG_SIDL
Re: some question about period scheduleing
hi Alan: 2013/12/1 Alan Stern : > On Fri, 29 Nov 2013, vichy wrote: > >> hi all: >> My connection like below >> ehci --> high speed hub -> full speed device >> >> I have some questions about period scheduling. >> 1. when creating qh for full speed device, why we set EHCI_TUNE_RL_TT. > > Are you asking why EHCI_TUNE_RL_TT is equal to 0? I don't know -- it > looks like a mistake. Do you find that changing it to 3 makes any > difference? Yes, when I change EHCI_TUNE_RL_TT as not 0. The transaction can keep going. > >> isn't it possible the full speed device return NAK during transaction? > > Of course it is possible. If so, why we use EHCI_TUNE_RL_TT default as 0? > >> that mean once it react with NAK, the host will stop below transaction. > > The host stops the transaction temporarily. It will restart the > transaction later. See section 4.9.1 in the EHCI spec. I find what you mentioned. > >> How could we make sure device never react with NAK? > > There is no way to do that. > >> 2. I attach my mon log for your reference. >> there is one thing I am curious >> why below message 'E' mean in bulk/interrupt? >> I have checked Document/usb/usbmon.txt but get nothing. > > E means the preceding submission failed. > >> d8c32600 190047566 E Bi:1:006:2 -19 0 >> d8c32980 190062351 C Bi:1:006:2 -107 0 >> d8c32980 190062363 S Bi:1:006:2 -115 1025 < >> d8c32980 190072803 E Bi:1:006:2 -19 0 > > For example, this E means the submission on the line above was > unsuccessful. The error code -19 is -ENODEV, which means the device > has been disconnected. > > This is described in Documentation/usb/usbmon.txt: > > - Event Type. This type refers to the format of the event, not URB type. > Available types are: S - submission, C - callback, E - submission error. Thanks for your help -- 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
