On Mon, Sep 05, 2016 at 11:10:22AM +0800, Peter Chen wrote:
> How about below, it will set halt for device, and host will get stall
> from the device.
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 0f692fc..3c46ccb 100644
> --- a/drivers/usb/chipidea/udc.c
> +++
On Mon, Sep 05, 2016 at 11:10:22AM +0800, Peter Chen wrote:
> How about below, it will set halt for device, and host will get stall
> from the device.
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 0f692fc..3c46ccb 100644
> --- a/drivers/usb/chipidea/udc.c
> +++
On Fri, Sep 02, 2016 at 06:42:43PM +0200, Clemens Gruber wrote:
> On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> > Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> > as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> > the lower vbus
On Fri, Sep 02, 2016 at 06:42:43PM +0200, Clemens Gruber wrote:
> On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> > Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> > as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> > the lower vbus
On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> the lower vbus voltage causes the USB LDO voltage less than 3.0v, then
> cause the unstable
On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> the lower vbus voltage causes the USB LDO voltage less than 3.0v, then
> cause the unstable
On Tue, Aug 30, 2016 at 07:20:45PM +0200, Clemens Gruber wrote:
> On Mon, Aug 29, 2016 at 06:24:03PM +0800, Peter Chen wrote:
> > Would you please measure the voltage of vbus within 1s at below two
> > conditions:
> >
> > - Just connect cable
> > - Just disconnect cable
>
> We found out that
On Tue, Aug 30, 2016 at 07:20:45PM +0200, Clemens Gruber wrote:
> On Mon, Aug 29, 2016 at 06:24:03PM +0800, Peter Chen wrote:
> > Would you please measure the voltage of vbus within 1s at below two
> > conditions:
> >
> > - Just connect cable
> > - Just disconnect cable
>
> We found out that
On Mon, Aug 29, 2016 at 06:24:03PM +0800, Peter Chen wrote:
> Would you please measure the voltage of vbus within 1s at below two
> conditions:
>
> - Just connect cable
> - Just disconnect cable
We found out that there was a problem with our hardware design!
But first, here is the VBUS
On Mon, Aug 29, 2016 at 06:24:03PM +0800, Peter Chen wrote:
> Would you please measure the voltage of vbus within 1s at below two
> conditions:
>
> - Just connect cable
> - Just disconnect cable
We found out that there was a problem with our hardware design!
But first, here is the VBUS
On Sun, Aug 28, 2016 at 08:15:02PM +0200, Clemens Gruber wrote:
> On Sat, Aug 27, 2016 at 01:21:52AM +0800, Peter Chen wrote:
> > The gadget triggers UI interrupt due to host sends packet.
> >
> > I really can't understand that, why host does not send bus reset
> > before sending packet (eg,
On Sun, Aug 28, 2016 at 08:15:02PM +0200, Clemens Gruber wrote:
> On Sat, Aug 27, 2016 at 01:21:52AM +0800, Peter Chen wrote:
> > The gadget triggers UI interrupt due to host sends packet.
> >
> > I really can't understand that, why host does not send bus reset
> > before sending packet (eg,
On Sat, Aug 27, 2016 at 01:21:52AM +0800, Peter Chen wrote:
> The gadget triggers UI interrupt due to host sends packet.
>
> I really can't understand that, why host does not send bus reset
> before sending packet (eg, GET_DESCRIPTOR)? It violates USB spec.
>
> Are you sure the first interrupt
On Sat, Aug 27, 2016 at 01:21:52AM +0800, Peter Chen wrote:
> The gadget triggers UI interrupt due to host sends packet.
>
> I really can't understand that, why host does not send bus reset
> before sending packet (eg, GET_DESCRIPTOR)? It violates USB spec.
>
> Are you sure the first interrupt
On Fri, Aug 26, 2016 at 01:47:40AM +0200, Clemens Gruber wrote:
> On Wed, Aug 24, 2016 at 04:11:02PM +0800, Peter Chen wrote:
> > UEI is an error interrupt, and software have not handled it, so it will
> > not affect ci->status.
> >
> > > Should we only call isr_tr_complete_handler if UI && !UEI
On Fri, Aug 26, 2016 at 01:47:40AM +0200, Clemens Gruber wrote:
> On Wed, Aug 24, 2016 at 04:11:02PM +0800, Peter Chen wrote:
> > UEI is an error interrupt, and software have not handled it, so it will
> > not affect ci->status.
> >
> > > Should we only call isr_tr_complete_handler if UI && !UEI
On Fri, Aug 26, 2016 at 01:47:40AM +0200, Clemens Gruber wrote:
> On Wed, Aug 24, 2016 at 04:11:02PM +0800, Peter Chen wrote:
> > UEI is an error interrupt, and software have not handled it, so it will
> > not affect ci->status.
> >
> > > Should we only call isr_tr_complete_handler if UI && !UEI
On Fri, Aug 26, 2016 at 01:47:40AM +0200, Clemens Gruber wrote:
> On Wed, Aug 24, 2016 at 04:11:02PM +0800, Peter Chen wrote:
> > UEI is an error interrupt, and software have not handled it, so it will
> > not affect ci->status.
> >
> > > Should we only call isr_tr_complete_handler if UI && !UEI
On Wed, Aug 24, 2016 at 04:11:02PM +0800, Peter Chen wrote:
> UEI is an error interrupt, and software have not handled it, so it will
> not affect ci->status.
>
> > Should we only call isr_tr_complete_handler if UI && !UEI ?
> >
> > Or would adding a check for ci->status == NULL in
On Wed, Aug 24, 2016 at 04:11:02PM +0800, Peter Chen wrote:
> UEI is an error interrupt, and software have not handled it, so it will
> not affect ci->status.
>
> > Should we only call isr_tr_complete_handler if UI && !UEI ?
> >
> > Or would adding a check for ci->status == NULL in
On Tue, Aug 23, 2016 at 02:36:30AM +0200, Clemens Gruber wrote:
> Hi,
>
> I am using an i.MX6Q embedded board, acting as a (ethernet) gadget with
> RNDIS function, connected over an USB OTG cable to a PC.
> Most of the time it works fine, but in some mysterious circumstances,
> a kernel panic
On Tue, Aug 23, 2016 at 02:36:30AM +0200, Clemens Gruber wrote:
> Hi,
>
> I am using an i.MX6Q embedded board, acting as a (ethernet) gadget with
> RNDIS function, connected over an USB OTG cable to a PC.
> Most of the time it works fine, but in some mysterious circumstances,
> a kernel panic
Hi,
I am using an i.MX6Q embedded board, acting as a (ethernet) gadget with
RNDIS function, connected over an USB OTG cable to a PC.
Most of the time it works fine, but in some mysterious circumstances,
a kernel panic occurs, just after attaching the OTG cable, connecting it
to the other machine:
Hi,
I am using an i.MX6Q embedded board, acting as a (ethernet) gadget with
RNDIS function, connected over an USB OTG cable to a PC.
Most of the time it works fine, but in some mysterious circumstances,
a kernel panic occurs, just after attaching the OTG cable, connecting it
to the other machine:
24 matches
Mail list logo
