> On Thu, Jan 10, 2013 at 04:35:51PM +0800, Peter Chen wrote:
> > For mxs-phy user i.mx6q, the PHY's clock is controlled by
> > hardware automatically, the software only needs to enable it
> > at probe, this clock should be used like below:
> >
> > - Enable at mxs-phy's probe, and disable at mxs-
> > >
> > > Some recent patch has caused fsl_mxc_udc.c driver to fail compilation
> > > because it can't find anymore.
> > >
> > > I would like this to be fixed still during this -rc cycle.
> >
> > Me too, who's sending a patch? :)
>
> Hi Peter,
>
> Who is currently working on the i.mx USB?
>
> > >
> >
> > I am working on it, but there are two versions, this one and chipidea's.
> >
> > Anyway, I will send a patch to fix this problem.
>
> if you're already using chipidea, then send me a patch removing this
> driver and focus your effort on chipidea.
>
Added Sascha
Now, not all of FS
>
> On Fri, Jan 18, 2013 at 10:50:28AM +0800, Peter Chen wrote:
> > +#ifdef CONFIG_PM
> > +static int ci13xxx_imx_suspend(struct device *dev)
> > +{
> > + struct ci13xxx_imx_data *data =
> > + platform_get_drvdata(to_platform_device(dev));
>
> Is there a reason not to use dev_get_dr
> Hi Ming, I also find this problem at my platform.
> (At chipidea controller, the resume signal will be ended about 21ms
> automatically)
>
My test is echo auto to keyboard (hub in int), then press key to wakeup it,
the system doesn't enter suspend.
> Neither delay 30ms at hub_events, nor
Add rpm trace log for log 1, the coming behavior is expected,
the usb subsystem will enters low power mode again.
root@freescale ~$ cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 156/156 #P:4
#
# _-=> irqs-off
#
>
> > I have post one patch which may remove the message, see link[2].
>
> I don't think sleeping is the right answer. For example, at the same
> time as the resume there could be a new device plugged in.
>
> What we really want to do is prevent the root hub from autosuspending
> while the re
Sorry, forget to cc the list
>
> Hi Greg,
>
> Alex has no response for chipidea driver review for long time
> (more than 1 month), below are some links about patchset.
> Does anyone else can help do it?
>
> http://marc.info/?t=13540330436&r=1&w=2
> http://marc.info/?l=linux-usb&m=13587375
> > > > } else {
> > > > + if (ci->driver)
> > > > + ci->driver->disconnect(&ci->gadget);
> > >
> > > This looks wrong. Why do you need to call ->disconnect() here ?
> >
> > When we disconnect usb cable from the host, we need to
> >
> > For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick
> (<500us)
> > once it accept the status of SET_ADDRESS
>
> The USB 2.0 spec says the recovery period after the status phase of
> SetAddress is 2ms. That should be enough to process the transfer
> completion interrupt, sh
> 2. If an internal USB port is suspended with remote wakeup disabled,
> power off the port. Add code to the USB core to ignore the device
> disconnect in this special case, so the driver thinks the device is
> still suspended. Issue a reset-resume when the driver wants to resume
> the device.
> >
> > <&usbmisc 0> would then mean port 0 of the usbmisc device.
> I didn't add the restriction that a usbmisc driver must have a usbmisc
> device. I'm not sure whether all SoC and future SoC can be look as
> a device.
>
> Peter, do you have any idea?
>
I have not followed this usbmisc design
>
> Which one? The MX28 p-o-s? Skimming through it's sources, I already used
> two
> puking bags, more to be filled tho.
>
mx23,mx28, maybe mx6x is the same.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More
>
> looks correct. Now that struct usb_otg should handle all otg details, it
> makes sense to put the state there. The problem is that a few of the
> states aren't really OTG specific. I think the only two otg-specific
> states are A_DEVICE and B_HOST...
>
According to USB_OTG_and_EH_2-0-final_
> > >
> > According to USB_OTG_and_EH_2-0-final_plus_errata_and_ecn_20110714 -
> final.pdf
> > Chapter7.1, 7,2. The states at enum usb_otg_state are all OTG state.
> >
> > If you think others (except for A_DEVICE and B_HOST) are not otg-
> specific states,
> > then what are they?
>
> granted, th
> > So, the others are usb_state not usb_otg_state. Then, when we
> generalize
> > otg driver, what kinds of **states** do you plan to use to stand for
> otg
> > state machine? Besides, if we name something different with spec, does
> it
> > will confuse the users?
>
> We could have just a singl
>
> > I am a little confused by using phy->state to stand for usb_state that
> I think
> > there is no relationship between usb_state with USB PHY.
>
> well, there's no relationship between usb_state and OTG. The state isn't
> OTG-specific, it's USB specific. This is a difficult detail to find
> >
> > In my mind, the system without OTG but using struct usb_phy can still
> > track their states.
> >
> > One thing I am always puzzled of current code is the OTG should be no
> > relationship with USB PHY.
> > The system without OTG but has USB device or host only function should
> > still o
> On 8/13/12, Felipe Balbi wrote:
>
> > Will there be another version for this or is this final ? Won't this
> > cause any regressions to other boards ?
>
> The proposed patch is not meant to be a final one.
>
> We still need to figure out the proper way to handle HOSTDISCONDETECT
> for all i
Add IC guy
Best regards,
Peter Chen
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Tuesday, August 14, 2012 10:01 AM
> To: Chen Peter-B29397
> Cc: ba...@ti.com; Sean Cross; linux-usb@vger.kernel.org; Estevam Fabio-
> R49496; Zhao Richard
>
> > According to IC guys, the logic of handling HOSTDISCONDETECT is the
> same
> > between i.mx28 and i.mx23.
>
> As pointed out by Sean, on mx23 reference manual we have the following
> text describing HOSTDISCONDETECT:
>
> "Due to a on chip issue (Errata #2791), software must
> pay attenti
> > >
> > It is the same with i.mx28.
> If they're same, imx23 should be ok. The mxs_phy driver pass test
> on mx28.
> > I think Richard's patch should not
> > violate point 2. Richard, can you confirm it?
> You mean I should not set the bit in mxs_phy_on_connect?
> or mxs_phy_on_connect is calle
>
> > Host controller's suspend should be executed later than root hub's,
> > or the hang may occur when root hub try to visit some registers
> > but host controller's suspend close the related clocks.
>
> Have you ever seen this happen? It should not be possible, because the
> PM core is care
Hi Alan,
One of my colleagues reports a problem that the enumeration will fail if
the storage has some problems. I can re-produce this problem if I add a
big delay (like 500ms) at handle_exception, at condition FSG_STATE_DISCONNECT,
please see below code:
3050 case FSG_STATE_DISCONNECT:
>
> that sounds like a plan :-) Tomorrow I can send a series of patches
> starting off the split, then people can just send in more patches for
> other controllers as we go. cheers
>
I agree with this change
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb"
> * In case we were forced against our will to halt a
>* bulk endpoint, clear the halt now. (The SuperH UDC
> @@ -2511,6 +2511,7 @@ static void handle_exception(struct fsg_
>
> case FSG_STATE_INTERFACE_CHANGE:
> case FSG_STATE_DISCONNECT:
> + case FSG_STATE_RESET:
> case FSG_STATE_COMMAND_PHASE:
> case FSG_STATE_DATA_PHASE:
> case FSG_STATE_STATUS_PHASE:
>
Reviewed-by: Chen Peter-B29397
--
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
t resets. The g_mass_storage driver
> > > shares a source file with g_file_storage; therefore it had to be
> > > modified accordingly.
> > >
> > > Signed-off-by: Alan Stern
> > > Reported-by: Chen Peter-B29397
> >
> > Looks good to me.
>
>
> On Wed, Aug 15, 2012 at 09:49:55AM +, Chen Peter-B29397 wrote:
> > Hi Alan,
> Hi Peter,
>
> > One of my colleagues reports a problem that the enumeration will fail
> if
> > the storage has some problems.
>
> A silghtly different question: do
>
> Because the fsl_udc_core driver shares one 'status_req' object for the
> complete ep0 control transfer, it is not possible to prime the final
> STATUS phase immediately after the IN transaction. E.g. ch9getstatus()
> executed:
>
> | req = udc->status_req;
> | ...
> | list_add_tail(&req->qu
> @@ -195,14 +195,13 @@ static void done(struct fsl_ep *ep, struct fsl_req
> *req, int status)
> dma_pool_free(udc->td_pool, curr_td, curr_td->td_dma);
> }
>
> - if (req->mapped) {
> + if (req->req.dma != DMA_ADDR_INVALID) {
> dma_unmap_single(ep->udc->g
> diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
> index c1a67cb..6a03e97 100644
> --- a/drivers/usb/otg/mxs-phy.c
> +++ b/drivers/usb/otg/mxs-phy.c
> @@ -97,12 +97,24 @@ static int mxs_phy_on_disconnect(struct usb_phy *phy,
> int port)
> return 0;
> }
>
> +static int
>
> The PHY framework provides a set of API's for the PHY drivers to
> create/remove a PHY and the PHY users to obtain a reference to the PHY
> using or without using phandle. If the PHY users has to obtain a
> reference to
> the PHY without using phandle, the platform specfic intialization code
>
> Peter, I dunno if you are already aware of it, but the USB peripheral
> mode hangs
> on MX233. It's easy to replicate for example if you try to run CDC
> ethernet over
> the USB peripheral mode, then telnet into the board and run "dmesg" .
> This will
> trigger a "larger" data transfer which
> Hi Peter,
>
> > > Peter, I dunno if you are already aware of it, but the USB peripheral
> > > mode hangs
> > > on MX233. It's easy to replicate for example if you try to run CDC
> > > ethernet over
> > > the USB peripheral mode, then telnet into the board and run "dmesg" .
> > > This will
> >
>
> No, I don't have this one available right now. I tried both MX23
> Olinuxino maxi
> (I just mutilated the board so that I cut traces to the USB devices on
> the board
> and routed out USB gadget connector) and a custom MX23 board.
>
> Note that both have working USB peripheral mode in U-Bo
> - I use the port in HOST mode by plugging in a USB pendrive over the OTG-
> capable
> reduction ; this works OK
> - I disconnect the reduction and connect it to the computer ; here I get
> "timeout waiting for 0800 in 11".
>
> This means the BSV bit in OTGSC register wasn't unset.
>
> Int
>
> Where can I measure this?
>
> > Two possible reasons:
> >
> > 1. You have not gpio control for vbus toggle when role switches.
>
> This works well.
>
> > 2. Your hardware has some problems that the vbus can't lower than 0.8v.
>
> How can I check that?
>
Just measure the voltage of your
> >
> > Just measure the voltage of your otg vbus pin.
>
> Ok, I see it's 2.25 volts after I disconnect the microB-A thing . I
> should see
> 0.8V constantly with nothing connected on the port?
>
You should see the voltage of vbus pin is less than 0.8v when
nothing is connected, we use B_SESS
> >
> > You should see the voltage of vbus pin is less than 0.8v when
> > nothing is connected, we use B_SESSION_VALID (0.8v) to judge
> > it is connected or not.
> >
> > You get 2.25 all the time or it is discharged very slowly?
>
> On my mx28evk it discharges very very slowly. Any hints about
> >
> > Have you opened the mouse by apps (like evtest)?, for USB mouse,
> > the usbhid->intf->needs_remote_wakeup is only set at .open/.close
> > API. That means if you have not opened mouse, the runtime pm status
> > for mouse will changed to RPM_ACTIVE (choose_wakeup ->
> pm_runtime_resume)
>
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Sunday, July 07, 2013 9:10 AM
> To: Chen Peter-B29397
> Cc: shawn@linaro.org; Michael Grzeschik; maxime.ripard@free-
> electrons.com; Hector Palacios; linux-usb@vger.kernel.org;
> s
>
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: Sunday, July 07, 2013 9:10 AM
> > > To: Chen Peter-B29397
> > > Cc: shawn@linaro.org; Michael Grzeschik; maxime.ripard@free-
> > >
>
> Yes, ID interrupt (IDIE) is set.
>
> I noticed this backtrace in the kernel bootlog, but this only happens if
> the
> dr_mode="otg" , it comes from the host-mode irq handler :
>
> [2.757563] irq 238: nobody cared (try booting with the "irqpoll"
> option)
> [2.764398] CPU: 0 PID: 1
>
> On Wed, Jul 17, 2013 at 10:36 AM, Peter Chen
> wrote:
> > On Mon, Jul 15, 2013 at 11:31:17PM -0700, Greg KH wrote:
> >> On Tue, Jul 16, 2013 at 11:49:07AM +0800, Rong Wang wrote:
> >> > Hi Greg,
> >> >
> >> > The USB on our platform can change roles between HOST and GADGET,
> but
> >> > it
My patches "usb: chipidea: fix the build error with randconfig" fixes chipidea
problem.
It has already at USB fixes for 3.11-rc4.
On Tue, 30 Jul 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.11-rc3 to v3.11-rc2[3], the summaries are:
> - build errors: +38/-14
+ arch/powerpc/kvm/b
Hi Alex, any comments, now it finished 3.11-rc4, I don't want this patchset
missed at 3.11.
Please tell me which one is OK, and which one needs to be refined, thanks.
Best regards,
Peter
From: linux-usb-ow...@vger.kernel.org [linux-usb-ow...@vger.kernel.
>
> Dear Peter Chen,
>
> > On Thu, Sep 12, 2013 at 12:55:54PM +0200, gianluca wrote:
> > > Hello,
> > > I just compiled the kernel from git repo of peter chen
> > > (git://github.com/hzpeterchen/linux-usb)
> >
> > Please use current linux-next tree, it has already supported
> > mx28 evk for vbu
> >> The reason was an mx28 errata: "ENGR119653 USB: ARM to USB register
> >> error issue"
>
> Peter, does this erratum only affect mx28?
Yes
> >>
> >> Freescale issued a patch for 2.6.35 to workaround this problem last
> >> year. I ported this patch. However, it is not totally "device tree
>
> > Since we introduce -EPROBE_DEFER for udc driver, it will be
> > probed at late_initcall if it is defered. When the gadget
> > is built in, it will return "couldn't find an available UDC"
> > at such case. That's the problem we met at below link:
> >
> > http://marc.info/?l=linux-usb&m=1377064
>
> > I think you should have a wrapper driver to EHCI/OHCI to handle this
> reset.
>
> Thank you Kishon and Peter for the quick replies. Is there any good
> example of such a wrapper driver in the kernel already?
>
chipidea, dwc3, etc.
--
To unsubscribe from this list: send the line "unsu
>
> On Mon, Sep 17, 2012 at 12:18 AM, Peter Chen
> wrote:
> > The operations in current otg.c are actually for USB PHY's
> > Move it from drivers/usb/otg/ to drivers/usb/phy/
> >
> > Signed-off-by: Peter Chen
> > ---
> > drivers/usb/otg/Makefile |3 -
> > drivers/usb/otg/otg.c| 239 -
>
> OTGSC_AVVIS cannot be set when vbus voltage goes valid or invalid on
> imx, so convert to use OTGSC_BSV.
>
Not just on imx, from the IC guys, it is chipidea's feature.
the AVVIS will not go to 1 when the vbus goes to high if ID = 1.
> OTGSC_BSVIE and OTGSC_BSVIS is not cleared when hw_
Hi Alex,
At current chipidea driver, we have not implemented struct usb_otg,
so when udc calls otg_set_peripheral, it will fail.
(udc_start at drivers/usb/chipidea/udc.c).
In fact, if both host and device use chipidea driver, we do not
need to call otg_set_peripheral at all at current chipidea f
The purpose for this patch is to have set_peripheral implementation,
but in current chipidea code, we don't need to know gadget at all,
as when id switch occurs, the core code know its role (device or host)
very well, and will call related stop/start function.
We have already many code bind struc
>
> > The purpose for this patch is to have set_peripheral implementation,
> > but in current chipidea code, we don't need to know gadget at all,
> > as when id switch occurs, the core code know its role (device or host)
> > very well, and will call related stop/start function.
> >
> > We have a
> -Original Message-
> From: Mike Thompson [mailto:mpthomp...@gmail.com]
> Sent: Thursday, September 20, 2012 3:58 AM
> To: Chen Peter-B29397
> Cc: st...@rowland.harvard.edu; ba...@ti.com;
> alexander.shish...@linux.intel.com; Zhao Richard-B20223; snijsure@grid-
> n
> Below are two patches to split some phy related things from
> otg.
>
> Changes for v2:
> - Use git mv / git format -M to create patch for rename otg.c to phy.c
>
Hi Felipe, how about these two patches?
> Peter Chen (2):
> usb: phy: rename enum usb_otg_state to usb_state
> usb: phy: rena
> > > hw_write(ci, OP_USBINTR, ~0,
> > >
> USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
> > > - hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > > } else {
> > > - hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > > hw_write(ci, OP_U
>
> Hmm, gadget gets zeroed out on every gadget->whatever switch, but it
> also gets reinitialized on every whatever->gadget transition. And it
> really shouldn't cause a null dereference.
>
When gadget->host, the call sequence like below:
udc_stop -> usb_del_gadget_udc -> usb_gadget_remove_dr
>
> Simply reading this patch shows that it contains at least two errors.
Thanks for review.
>
> > @@ -4187,6 +4190,10 @@ static void hub_port_connect_change(struct
> usb_hub *hub, int port1,
> > }
> > }
> >
> > + if (hcd->phy && !hdev->parent &&
> > + !(portstatus
>
> This if is a no-op, as OTG_ are defined as:
>
> #define OTGSC_AVVIS BIT(17)
> #define OTGSC_AVVIE BIT(25)
>
> Resulting in queue_work() never called from here.
>
> > +
> > spin_unlock(&ci->lock);
> >
>
> I'm not that deep into the OTG stuff to fix it properly.
>
>
> On Mon, Oct 22, 2012 at 03:13:09PM +0800, Peter Chen wrote:
> > The real reason causes mx23 fail are:
> >
> > - Calling mxs_phy_hw_init(mxs_phy) again at connection
> > - Error connect/disconnect nodity at hub.c
> >
> > The coming patch will fix above two problems, Mike Thompson
> > tested h
>
> On Mon, Oct 22, 2012 at 5:13 AM, Peter Chen
> wrote:
> > The real reason causes mx23 fail are:
> >
> > - Calling mxs_phy_hw_init(mxs_phy) again at connection
> > - Error connect/disconnect nodity at hub.c
> >
> > The coming patch will fix above two problems, Mike Thompson
>
> So shouldn't
> > @@ -89,14 +89,34 @@ static struct ci13xxx_platform_data
> > ci13xxx_imx_platdata __devinitdata = { .name =
> "ci13xxx_imx",
> > .flags = CI13XXX_REQUIRE_TRANSCEIVER |
> > CI13XXX_PULLUP_ON_VBUS |
> > -
>
> Just a nitpick really, but what about parametrizing this code so we won't
> have
> two copies of the same loop?
>
> Say:
>
> uint32_t bit = low ? OTGSC_BSV : OTGSC_AWW;
> const char *name = low ? "B_SESS_VALID" : "A_VBUS_VALID";
>
> while (!(otgsc & bit)) {
> if (time_after(jiffies,
>
> On Mon, Nov 05, 2012 at 08:27:40PM +0300, Dan Carpenter wrote:
> > Hello Richard Zhao,
> >
> > The patch 8c4fc031954b: "USB: chipidea: add vbus detect for udc" from
> > Sep 12, 2012, leads to the following Smatch warning:
> > drivers/usb/chipidea/udc.c:1683 udc_irq()
> > warn: odd binop
>
> This patchset adds fully tested otg id switch function and
> vbus connect/disconnect detection for chipidea driver.
> The mainly design of id/vbus handling follows msm otg driver.
> I hope the msm usb maintainer can have a look of this patchset,
> and give some comments, and move the whol
Peter-B29397
Cc: Uwe Kleine-König; Alexander Shishkin; gre...@linuxfoundation.org;
ker...@pengutronix.de; linux-usb@vger.kernel.org; Estevam Fabio-R49496;
m...@pengutronix.de; m.grzesc...@pengutronix.de; s.ha...@pengutronix.de
Subject: Re: [PATCH] usb: chipidea: ci13xxx_imx: Use dev_dbg for pinctrl
>
> This patch adds iso endpoint support to the device controller.
> It makes use of the multiplication bits in the maxpacket field
> of the endpoint and calculates the multiplier bits for each
> transfer description on every request.
>
> Signed-off-by: Michael Grzeschik
> ---
> drivers/usb/c
> Hello,
>
> Am I right in assuming that the MXS USB on-the-go port does not currently
> support the
> device (gadget) functionality?
> Anybody out there working on that?
>
As far as I know, Maxime Ripard may already let the chipidea durl-role function
work ok at mx28. It may need my chipidea
>
> Indeed, I've been using the patchset "Add tested id switch and vbus
> connect detect support for Chipidea" from Peter for quite some time on
> top of 3.9 and it works like a charm for the gadget mode on an MX28
> platform.
>
> BTW, Peter, I've seen that these patches are still not merged i
>
> I did actually have this one in my tree, but since that time this
>
> commit 7c8bfed7aaeba690de30835fe89882e1047a55fd
> Author: David Rientjes
> Date: Fri Apr 26 13:25:01 2013 -0700
>
> usb, chipidea: fix link error when USB_EHCI_HCD is a module
>
> has turned up in usb-next, and
72 matches
Mail list logo
