[PATCH 1/2] ARM: imx_v6_v7_defconfig: add CONFIG_USB_PHY
Commit edc7cb2 (usb: phy: make it a menuconfig) makes USB_MXS_PHY be a sub-item of menuconfig symbol USB_PHY. This change gets the selection of CONFIG_USB_MXS_PHY in imx_v6_v7_defconfig lost. Hence the boot stops at the point below. ci_hdrc ci_hdrc.0: doesn't support gadget ci_hdrc ci_hdrc.0: EHCI Host Controller ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 Add CONFIG_USB_PHY to have the CONFIG_USB_MXS_PHY selection back to work. Signed-off-by: Shawn Guo --- arch/arm/configs/imx_v6_v7_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index e36b010..088d6c1 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -188,6 +188,7 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_MXC=y CONFIG_USB_CHIPIDEA=y CONFIG_USB_CHIPIDEA_HOST=y +CONFIG_USB_PHY=y CONFIG_USB_MXS_PHY=y CONFIG_USB_STORAGE=y CONFIG_MMC=y -- 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 2/2] ARM: mxs_defconfig: add CONFIG_USB_PHY
Commit edc7cb2 (usb: phy: make it a menuconfig) makes USB_MXS_PHY be a sub-item of menuconfig symbol USB_PHY. This change gets the selection of CONFIG_USB_MXS_PHY in mxs_defconfig lost. Hence the boot stops at the point below. [1.600867] ci_hdrc ci_hdrc.0: doesn't support gadget [1.606282] ci_hdrc ci_hdrc.0: EHCI Host Controller [1.613522] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 Add CONFIG_USB_PHY to have the CONFIG_USB_MXS_PHY selection back to work. Signed-off-by: Shawn Guo --- arch/arm/configs/mxs_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig index e9b1f6d..7ba48d2 100644 --- a/arch/arm/configs/mxs_defconfig +++ b/arch/arm/configs/mxs_defconfig @@ -122,6 +122,7 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_CHIPIDEA=y CONFIG_USB_CHIPIDEA_HOST=y CONFIG_USB_STORAGE=y +CONFIG_USB_PHY=y CONFIG_USB_MXS_PHY=y CONFIG_MMC=y CONFIG_MMC_UNSAFE_RESUME=y -- 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
[PATCHv3 0/3] usb: phy: remaining twl4030-usb/omap fixes
These are the last 3 patches of earlier twl4030-usb/omap fix series: http://marc.info/?l=linux-usb&m=136354462519052&w=2 Changed since v2: - simplified patch 5/7 (now 1/3) according to Felipe's suggestion - changed vbus_supplied to be always set to true when VBUS_PRES is set, even when ID is grounded at the same time (like it was before the patch). Grazvydas Ignotas (3): usb: phy: twl4030-usb: check if vbus is driven by twl itself usb: musb: omap2430: turn off vbus on cable disconnect usb: musb: gadget: use platform callback to enable vbus drivers/usb/musb/musb_gadget.c|5 ++--- drivers/usb/musb/omap2430.c |1 + drivers/usb/phy/phy-twl4030-usb.c | 31 --- 3 files changed, 31 insertions(+), 6 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
[PATCHv3 1/3] usb: phy: twl4030-usb: check if vbus is driven by twl itself
At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
itself. Reporting VBUS in this case confuses OMAP musb glue and charger
driver, so check if OTG VBUS charge pump is on before reporting VBUS
event to avoid this problem.
Signed-off-by: Grazvydas Ignotas
---
drivers/usb/phy/phy-twl4030-usb.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl4030-usb.c
index 61fe7e2..3f9858f 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -248,6 +248,25 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 reg, u8
bits)
/*-*/
+static bool twl4030_is_driving_vbus(struct twl4030_usb *twl)
+{
+ int ret;
+
+ ret = twl4030_usb_read(twl, PHY_CLK_CTRL_STS);
+ if (ret < 0 || !(ret & PHY_DPLL_CLK))
+ /*
+* if clocks are off, registers are not updated,
+* but we can assume we don't drive VBUS in this case
+*/
+ return false;
+
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret < 0)
+ return false;
+
+ return (ret & (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
+}
+
static enum omap_musb_vbus_id_status
twl4030_usb_linkstat(struct twl4030_usb *twl)
{
@@ -270,13 +289,19 @@ static enum omap_musb_vbus_id_status
if (status < 0)
dev_err(twl->dev, "USB link status err %d\n", status);
else if (status & (BIT(7) | BIT(2))) {
- if (status & (BIT(7)))
-twl->vbus_supplied = true;
+ if (status & BIT(7)) {
+ if (twl4030_is_driving_vbus(twl))
+ status &= ~BIT(7);
+ else
+ twl->vbus_supplied = true;
+ }
if (status & BIT(2))
linkstat = OMAP_MUSB_ID_GROUND;
- else
+ else if (status & BIT(7))
linkstat = OMAP_MUSB_VBUS_VALID;
+ else
+ linkstat = OMAP_MUSB_VBUS_OFF;
} else {
if (twl->linkstat != OMAP_MUSB_UNKNOWN)
linkstat = OMAP_MUSB_VBUS_OFF;
--
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
[PATCHv3 3/3] usb: musb: gadget: use platform callback to enable vbus
On some platform configurations (like OMAP3+twl4030) it's the platform code that enables VBUS, not OTG transceiver, so call vbus platform callback instead, it will then call the transceiver if needed. This fixes a use case where USB cable is plugged first and gadget driver is loaded later after that. Signed-off-by: Grazvydas Ignotas --- drivers/usb/musb/musb_gadget.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index ff6ba3a..4be4865 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1848,9 +1848,8 @@ static int musb_gadget_start(struct usb_gadget *g, goto err; } - if ((musb->xceiv->last_event == USB_EVENT_ID) - && otg->set_vbus) - otg_set_vbus(otg, 1); + if (musb->xceiv->last_event == USB_EVENT_ID) + musb_platform_set_vbus(musb, 1); hcd->self.uses_pio_for_control = 1; -- 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
[PATCHv3 2/3] usb: musb: omap2430: turn off vbus on cable disconnect
On USB_EVENT_ID event the musb glue enables VBUS by calling
omap2430_musb_set_vbus(musb, 1) that sets the session bit, but on
USB_EVENT_NONE reverse action is never made, and that breaks PM.
Disable VBUS on USB_EVENT_NONE to be sure musb session is ended
on cable unplug so that PM works.
Signed-off-by: Grazvydas Ignotas
---
drivers/usb/musb/omap2430.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 798e029..3551f1a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -291,6 +291,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb->xceiv->last_event = USB_EVENT_NONE;
if (musb->gadget_driver) {
+ omap2430_musb_set_vbus(musb, 0);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
}
--
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: PROBLEM: USB device registered on OHCI instead of EHCI at boot
On Thu, Mar 14, 2013 at 06:50:44PM +0800, Huang Rui wrote:
> On Tue, Mar 12, 2013 at 11:48:49PM +0800, Alan Stern wrote:
> > On Tue, 12 Mar 2013, Huang Rui wrote:
> >
> > > Hi Alan,
> > >
> > > The same problem is encountered in my side. Bruce's log doesn't
> > > demonstrate the break point. I attached a new one.
> > >
> > > [ 14.359603] hub 1-0:1.0: state 7 ports 4 chg 0004 evt
> > > [ 14.359613] hub 1-0:1.0: port 2, status 0101, change , 12 Mb/s
> > > [ 14.385538] ohci_hcd :00:12.0: port[1] reset timeout, stat 0111
> > > [ 14.431601] hub 3-0:1.0: port 2: status 0101 change 0001
> > > [ 14.435601] hub 4-0:1.0: port 2: status 0203 change 0001
> > > [ 14.439596] ohci_hcd :00:12.0: GetStatus roothub.portstatus [1] =
> > > 0x00100103 PRSC PPS PES CCS
> > > [ 14.495599] usb 1-2: new full-speed USB device number 2 using ohci_hcd
> > > [ 14.521546] ohci_hcd :00:12.0: port[1] reset timeout, stat 0113
> > > [ 14.575610] ohci_hcd :00:12.0: GetStatus roothub.portstatus [1] =
> > > 0x00100103 PRSC PPS PES CCS
> > > [ 14.656656] usb 1-2: Parent hub missing LPM exit latency info. Power
> > > management will be impacted.
> > > [ 14.658656] usb 1-2: not running at top speed; connect to a high speed
> > > hub
> > > [ 14.664658] usb 1-2: default language 0x0409
> > > [ 14.670658] usb 1-2: udev 2, busnum 1, minor = 1
> > > [ 14.670660] usb 1-2: New USB device found, idVendor=05e3,
> > > idProduct=0732
> > > [ 14.670662] usb 1-2: New USB device strings: Mfr=3, Product=4,
> > > SerialNumber=5
> > > [ 14.670664] usb 1-2: Product: USB Reader
> > > [ 14.670666] usb 1-2: Manufacturer: Genesys
> > > [ 14.670668] usb 1-2: SerialNumber: 0038
> >
> > That is not the relevant part of the log. Here's the important part:
> >
> > [ 28.924735] ehci-pci :00:12.2: GetStatus port:2 status 001803 0 ACK
> > POWER sig=j CSC CONNECT
> > [ 28.924739] hub 5-0:1.0: port 2: status 0501 change 0001
> > ...
> > [ 30.352837] ehci-pci :00:12.2: port 2 full speed --> companion
> >
>
> Thanks a lot to correct me and point that.
>
> > This shows that the card reader did attach to the EHCI controller, but
> > then failed to indicate that it was capable of high-speed operation.
> > I have no idea why not.
> >
> > Can you use git bisect to find the commit responsible for this?
>
> I used git bisect to locate the break commit between 3.0 and 3.9, but
> when the kernel is from 3.7 to 3.8, this issue does not reproduce
> stablely. During 3.8-rc3, I boot many times with the same kernel,
> sometimes are good and sometimes are bad(attached log). So I can not
> find break commit exactly... sorry :(
>
Hi Alan,
Thank you to take a look at this issue. Sorry to disturb you again.
The PORT ENABLE(PORT_PE) bit in PORTSC register is not set when the
port reset, in other words, host controller and device might not do
alternating sequence of Chirp Ks and Chirp Js or not be detected. Am I
right? I found why the boot issue is not alway reproduced. Because
sometimes ehci_hcd is not loaded before ohci_hcd.
[ 25.068090] Warning! ehci_hcd should always be loaded before uhci_hcd and
ohci_hcd, not after
If ehci_hcd is loaded firstly, the USB Reader(in my side) is always
detected as high speed device. Then I do below change and boot issue
isn't encountered again.
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 180a2b0..30fc91c 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1325,7 +1325,7 @@ static int __init ohci_hcd_mod_init(void)
clear_bit(USB_OHCI_LOADED, &usb_hcds_loaded);
return retval;
}
-module_init(ohci_hcd_mod_init);
+late_initcall(ohci_hcd_mod_init);
static void __exit ohci_hcd_mod_exit(void)
{
But I think it's not a good solution. Have you any idea to have an
appropriate way to make ehci_hcd loaded firstly?
Thanks & Best Regards,
Rui
--
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: PROBLEM: since linux kernel 3.8 Apple Cinema Display's usb hub spits errors randomly at boot.
On 03/18/2013 04:29 PM, Alan Stern wrote: On Sat, 16 Mar 2013, Alan Stern wrote: On Sat, 16 Mar 2013, Jenya Y wrote: Alan, looks like we are not quite there yet, just tried a fresh 3.8.3 build with both of your patches and here is what I have - [7.797975] usb 1-2.2: can't set config #1, error -19 [7.798332] usb 1-2.2: USB disconnect, device number 3 [7.799158] usb 2-1: USB disconnect, device number 2 [7.801304] usb 2-2: USB disconnect, device number 3 [7.813015] hub 2-2:1.0: hub_port_status failed (err = -19) [7.813364] hub 2-2:1.0: unable to enumerate USB device on port 2 [7.836270] usb 4-1: USB disconnect, device number 2 [7.881036] usb 4-1.3: new full-speed USB device number 3 using uhci_hcd [7.887063] hub 4-1:1.0: unable to enumerate USB device on port 3 So half of them is gone, just those remained. I downgraded to systemd 197 for the build just to make sure. Those -19 and "unable to enumerate" messages aren't necessary; I'll send you an updated version of the second patch that will get rid of them. However, the "USB disconnect" messages are unavoidable. Here's the updated version of the second patch. You know, these patches probably will apply okay (or with only minor changes) to 3.9. Then you should be able to use any config setup you want. Alan Stern Alan, thank you very much for your effort! The updated second patch did resolve all the remaining errors. In case you have any questions or need assistance or anything of this sort, feel free to contact me, I'll be happy to help. Remember I mentioned a friend of mine, that I sent your first patch to? Well, she tried it on an amd system with 3.8 and nvidia nforce chipset and though her usb hub error messages disappeared, her system was unable to auto-detect new devices after the patch. Meanwhile, I convinced her to go with 3.9 + the special build config we successfully tested and so far all seems to be almost perfect. I'm not sure if sending her the second patch will help. So this is where we stand... If you wish I can suggest her to contact you. -- 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: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tuesday, March 19, 2013 04:12:18 PM Daniel Vetter wrote:
> On Tue, Mar 19, 2013 at 10:03 AM, Chris Wilson
wrote:
> >> > How about just using:
> >> > if (!HAS_GMBUS_IRQ(dev_priv->dev)) gmbus4_irq_en = 0;
> >> >
> >> > and the existing wait loop?
> >>
> >> I explicitly wanted to avoid touching GMBUS4 register, as the real cause
> >> of the failure is not clear.
> >>
> >> But, as Yinghai Lu points out, the problem is most likely caused by
> >> interrupt disabling not working properly (see his very good point
> >> regarding DisINTx+ and INTx+ discrepancy), so zeroing the register out
> >> should work and it indeed does in my case, hence the (tested) patch
> >> below.
> >>
> >> I think it's a 3.9-rc material, and I am all open to debug this further
> >> for 3.10 so that the race is closed and gmbus irqs can be used on Gen4
> >> platform properly.
> >
> > Agreed. Using the IRQ for GMBUS is just a performance feature that can
> > be deferred until after we determine the root cause - and hope that the
> > failure is somehow peculiar to GMBUS.
>
> Ok, I've merged this patch. But some further investigation points at a
> much more severe dragon hiding here: The MSI interrupt for the intel
> gfx is commonly in the 40+ range, but the interrupt vector with the
> spurious interrupts is 16. Which is the irq of the intel gfx when MSI
> is disabled!
>
> So it looks like gmbus on the intel gfx is capable of generating
> non-MSI interrupts in parallel to the MSI interrupts (since apparently
> gmbus still works, so we get the interrupts we expect). I have no idea
> how that could happen. Hence adding a bunch of people with more clue
> than me.
>
Hello folks,
I am using Linus git master and built an rpm for 3.9.0-rc4 which has Jiri's
patch. I confirm this patch returns the GMA 4500 to working behavior as in
3.8.
Thanks everyone.
Shawn
> For reference below the updated commit message.
>
> Cheers, Daniel
>
> Author: Jiri Kosina
> Date: Tue Mar 19 09:56:57 2013 +0100
>
> drm/i915: stop using GMBUS IRQs on Gen4 chips
>
> Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
> using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
> and above.
>
> It turns out though that on many systems this leads to spurious
> interrupts being generated, long after the register write to disable the
> IRQs has been issued.
>
> Typically this results in the spurious interrupt source getting
> disabled:
>
> [9.636345] irq 16: nobody cared (try booting with the "irqpoll"
> option) [9.637915] Pid: 4157, comm: ifup Tainted: GF
> 3.9.0-rc2-00341-g0863702 #422
> [9.639484] Call Trace:
> [9.640731][] __report_bad_irq+0x1d/0xc7
> [9.640731] [] note_interrupt+0x15b/0x1e8
> [9.640731] [] handle_irq_event_percpu+0x1bf/0x214
> [9.640731] [] handle_irq_event+0x3c/0x5c [
> 9.640731] [] handle_fasteoi_irq+0x7a/0xb0 [9.640731]
> [] handle_irq+0x1a/0x24
> [9.640731] [] do_IRQ+0x48/0xaf
> [9.640731] [] common_interrupt+0x6a/0x6a
> [9.640731][] ?
> system_call_fastpath+0x16/0x1b [9.640731] handlers:
> [9.640731] [] usb_hcd_irq [usbcore]
> [9.640731] [] yenta_interrupt [yenta_socket]
> [9.640731] Disabling IRQ #16
>
> The really curious thing is now that irq 16 is _not_ the interrupt for
> the i915 driver when using MSI, but it _is_ the interrupt when not
> using MSI. So by all indications it seems like gmbus is able to
> generate a legacy (shared) interrupt in MSI mode on some
> configurations. I've tried to reproduce this and the differentiating
> thing seems to be that on unaffected systems no other device uses irq
> 16 (which seems to be the non-MSI intel gfx interrupt on all gm45).
>
> I have no idea how that even can happen.
>
> To avoid tempting this elephant into a rage, just disable gmbus
> interrupt support on gen 4.
>
> v2: Improve the commit message with exact details of what's going on.
> Also add a comment in the code to warn against this particular
> elephant in the room.
>
> Signed-off-by: Jiri Kosina (v1)
> Acked-by: Chris Wilson (v1)
> References: https://lkml.org/lkml/2013/3/8/325
> Signed-off-by: Daniel Vetter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] usb: gadget: mv_udc_core: fix sparse warnings
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: 2013年3月22日 23:15
> To: Linux USB Mailing List
> Cc: Alan Stern; Ido Shayevitz; Yu Xu; Yunfan Zhang; Virupax Sadashivpetimath;
> Vinod Koul; Sebastian Andrzej Siewior; Alexander Shishkin; Jingoo Han; Bill
> Pemberton; Neil Zhang; Chao Xie; Michal Nazarewicz; Linus Walleij; Felipe
> Balbi
> Subject: [PATCH 4/6] usb: gadget: mv_udc_core: fix sparse warnings
>
> fix the following sparse warnings:
>
> drivers/usb/gadget/mv_udc_core.c:1850:6: warning: symbol
> 'irq_process_reset' was not declared. Should it be static?
> drivers/usb/gadget/mv_udc_core.c:247:9: warning: context imbalance in
> 'done' - unexpected unlock
> drivers/usb/gadget/mv_udc_core.c:1692:25: warning: context imbalance in
> 'handle_setup_packet' - unexpected unlock
>
> Note that there are still other sparse warnings which aren't trivial to fix,
> so I
> left them out:
>
> drivers/usb/gadget/mv_udc_core.c:848:34: warning: incorrect type in
> argument 1 (different address spaces)
> drivers/usb/gadget/mv_udc_core.c:848:34:expected void const volatile
> [noderef] *addr
> drivers/usb/gadget/mv_udc_core.c:848:34:got unsigned int *
> drivers/usb/gadget/mv_udc_core.c:849:42: warning: incorrect type in
> argument 2 (different address spaces)
> drivers/usb/gadget/mv_udc_core.c:849:42:expected void volatile
> [noderef] *addr
> drivers/usb/gadget/mv_udc_core.c:849:42:got unsigned int *
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/mv_udc_core.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/mv_udc_core.c
> b/drivers/usb/gadget/mv_udc_core.c
> index 9a68c05..88be74e 100644
> --- a/drivers/usb/gadget/mv_udc_core.c
> +++ b/drivers/usb/gadget/mv_udc_core.c
> @@ -212,6 +212,8 @@ static int process_ep_req(struct mv_udc *udc, int
> index,
> * request is still in progress.
> */
> static void done(struct mv_ep *ep, struct mv_req *req, int status)
> + __releases(&ep->udc->lock)
> + __acquires(&ep->udc->lock)
> {
> struct mv_udc *udc = NULL;
> unsigned char stopped = ep->stopped;
> @@ -1651,6 +1653,8 @@ out:
>
> static void handle_setup_packet(struct mv_udc *udc, u8 ep_num,
> struct usb_ctrlrequest *setup)
> + __releases(&ep->udc->lock)
> + __acquires(&ep->udc->lock)
> {
> bool delegate = false;
>
> @@ -1847,7 +1851,7 @@ static void irq_process_tr_complete(struct
> mv_udc *udc)
> }
> }
>
> -void irq_process_reset(struct mv_udc *udc)
> +static void irq_process_reset(struct mv_udc *udc)
> {
> u32 tmp;
> unsigned int loops;
> --
> 1.8.2
Acked-by: Neil Zhang
Best Regards,
Neil Zhang
Re: Linux USB file storage gadget with new UDC
Hi, >> I have a serial console to access the platform. Today i use Linux as >> USB host. The log of the usb gadget is attached (gadget-log.txt). >> >> The Linux usbmon log file is also attached (usbmon-log.txt). Hopefully >> the log data will be useful. > > It looks like you cut out a lot of information from the gadget log. > Please don't do that. > > The logs show that your driver still has several bugs. For example, > the start of the gadget log shows that the driver thinks it received a > bunch of packets on the bulk-out endpoint, but the usbmon log shows > that the host never sent these packets. > > Your driver does not set the Halt feature for the bulk-in endpoint when > it is supposed to. It doesn't even respond with NAK when it receives > an invalid request on endpoint 0. > > When asked to transmit 4096 bytes of data, your driver sent a packet > containing more than 512 bytes. > I do not know when to set the Halt feature for the bulk-in endpoint. I see gadget code have this line printed out: g_file_storage gadget: bulk-in set halt In the log file, is there any invalid request received on endpoint 0? Regards, victor -- 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: Add EHCI and OHCI for Renesas R-Mobile SoC (r8a7740)
On Thu, Mar 21, 2013 at 10:02 AM, Kuninori Morimoto wrote: > > Hi Iwamatsu-san > >> >> >> +void rmobile_hc_start(struct usb_hcd *hcd, struct platform_device >> >> >> *pdev) >> >> > ... >> >> >> + data = SMODE_READY_CTR | MMODE_HBUSREQ | >> >> >> + MMODE_WR_INCR | MMODE_BYTE_BURST | MMODE_HTRANS; >> >> >> + >> >> >> + if (data == __raw_readl(hci->base + AHB_BUS_CTR)) >> >> >> + return; >> >> >> + >> >> >> + /* AHB-PCI Bridge Communication Registers */ >> >> >> + AHB_WRITE(hci, data, AHB_BUS_CTR); >> >> >> + AHB_WRITE(hci, (PHYS_OFFSET & 0xf000) | PREFETCH, >> >> >> + PCIAHB_WIN1_CTR); >> >> >> + AHB_WRITE(hci, 0xf000 | PREFETCH, PCIAHB_WIN2_CTR); >> >> >> + AHB_WRITE(hci, hci->phys_base | PCIWIN2_PCICMD, AHBPCI_WIN2_CTR); >> >> >> + data = __raw_readl(hci->base + PCI_ARBITER_CTR); >> >> >> + AHB_WRITE(hci, data | PCIBP_MODE | PCIREQ1 | PCIREQ0, >> >> >> + PCI_ARBITER_CTR); >> >> >> + >> >> >> + /* PCI Configuration Registers for AHBPCI */ >> >> >> + AHB_WRITE(hci, PCIWIN1_PCICMD | AHB_CFG_AHBPCI, AHBPCI_WIN1_CTR); >> >> >> + AHB_WRITE(hci, hci->phys_base + AHBPCI_OFFSET, >> >> >> + PCI_CONF_AHBPCI_BASEAD); >> >> >> + AHB_WRITE(hci, PHYS_OFFSET & 0xf000, >> >> >> PCI_CONF_AHBPCI_WIN1_BASEAD); >> >> >> + AHB_WRITE(hci, 0xf000, PCI_CONF_AHBPCI_WIN2_BASEAD); >> >> >> + AHB_WRITE(hci, SERREN | PERREN | MASTEREN | MEMEN, >> >> >> + PCI_CONF_AHBPCI_CMND_STS); >> >> >> + >> >> >> + /* PCI Configuration Registers for EHCI */ >> >> >> + AHB_WRITE(hci, PCIWIN1_PCICMD | AHB_CFG_HOST, AHBPCI_WIN1_CTR); >> >> >> + AHB_WRITE(hci, hci->phys_base + OHCI_OFFSET, OHCI_BASEAD); >> >> >> + AHB_WRITE(hci, hci->phys_base + EHCI_OFFSET, EHCI_BASEAD); >> >> >> + >> >> >> + data = SERREN | PERREN | MASTEREN | MEMEN; >> >> >> + AHB_WRITE(hci, data, OHCI_CMND_STS); >> >> >> + AHB_WRITE(hci, data, EHCI_CMND_STS); >> >> >> + >> >> >> + /* enable pci interrupt */ >> >> >> + data = __raw_readl(hci->base + PCI_INT_ENABLE); >> >> >> + data |= USBH_PMEEN | USBH_INTBEN | USBH_INTAEN; >> >> >> + AHB_WRITE(hci, data, PCI_INT_ENABLE); > (snip) >> > ohci-rmobile.c -> ohci->sh.c >> > ohci-common.c -> ohci-r8a7740.c >> > >> >> Thanks for your comment. >> OK, I will rename and update patches. > > Could you please teach me current status of this patch ? > > Best regards Sorry, reply was late. I am re-writing this code. I will send this week. Best regards, Nobuhirio -- Nobuhiro Iwamatsu -- 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
