fsl_udc status?

fsl_udc status?

[Joakim Tjernlund]

We are trying to get fsl_udc up and running on a T1042 with without success.
Seems like this driver is lagging behind the corresponding host driver(mph).
The mph driver has a number of USB errata workarounds while udc has none.
At least erratas A007792 seems applicable for udc too.

Is the fsl_udc driver functional on 4.14.x(which we use)? What is missing ?

 Jocke  

Re: fsl_udc status?

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]


Hi,

Joakim Tjernlund <Joakim.Tjernlund@infinera.com> writes:
> We are trying to get fsl_udc up and running on a T1042 with without success.
> Seems like this driver is lagging behind the corresponding host driver(mph).
> The mph driver has a number of USB errata workarounds while udc has none.
> At least erratas A007792 seems applicable for udc too.
>
> Is the fsl_udc driver functional on 4.14.x(which we use)? What is missing ?

If you're on v4.14, then you need to ask for support from whoever gave
you that kernel. In this forum we treat mainline only, which currently
is at v5.2-rc4. Unless you can try that version of the kernel, we can't
really help you here.

Good luck

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: fsl_udc status?

[Joakim Tjernlund]

On Mon, 2019-06-10 at 10:56 +0300, Felipe Balbi wrote:
> Hi,
> 
> Joakim Tjernlund <Joakim.Tjernlund@infinera.com> writes:
> > We are trying to get fsl_udc up and running on a T1042 with without success.
> > Seems like this driver is lagging behind the corresponding host driver(mph).
> > The mph driver has a number of USB errata workarounds while udc has none.
> > At least erratas A007792 seems applicable for udc too.
> >
> > Is the fsl_udc driver functional on 4.14.x(which we use)? What is missing ?
> 
> If you're on v4.14, then you need to ask for support from whoever gave
> you that kernel. In this forum we treat mainline only, which currently
> is at v5.2-rc4. Unless you can try that version of the kernel, we can't
> really help you here.

None gave me that kernel, it is the stable 4.14.x tree that Greg maintains, I would
assume that this forum has some support for stable kernels too?

Looking at upstream, there has not been any significant change in this area for a long time.

 Jocke

Re: fsl_udc status?

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]


Hi,

Joakim Tjernlund <Joakim.Tjernlund@infinera.com> writes:

> On Mon, 2019-06-10 at 10:56 +0300, Felipe Balbi wrote:
>> Hi,
>> 
>> Joakim Tjernlund <Joakim.Tjernlund@infinera.com> writes:
>> > We are trying to get fsl_udc up and running on a T1042 with without success.
>> > Seems like this driver is lagging behind the corresponding host driver(mph).
>> > The mph driver has a number of USB errata workarounds while udc has none.
>> > At least erratas A007792 seems applicable for udc too.
>> >
>> > Is the fsl_udc driver functional on 4.14.x(which we use)? What is missing ?
>> 
>> If you're on v4.14, then you need to ask for support from whoever gave
>> you that kernel. In this forum we treat mainline only, which currently
>> is at v5.2-rc4. Unless you can try that version of the kernel, we can't
>> really help you here.
>
> None gave me that kernel, it is the stable 4.14.x tree that Greg maintains, I would
> assume that this forum has some support for stable kernels too?
>
> Looking at upstream, there has not been any significant change in this
> area for a long time.

In that case, I'll let Li Yang reply.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: fsl_udc status?

[Greg KH]

On Mon, Jun 10, 2019 at 08:33:17AM +0000, Joakim Tjernlund wrote:
> On Mon, 2019-06-10 at 10:56 +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > Joakim Tjernlund <Joakim.Tjernlund@infinera.com> writes:
> > > We are trying to get fsl_udc up and running on a T1042 with without success.
> > > Seems like this driver is lagging behind the corresponding host driver(mph).
> > > The mph driver has a number of USB errata workarounds while udc has none.
> > > At least erratas A007792 seems applicable for udc too.
> > >
> > > Is the fsl_udc driver functional on 4.14.x(which we use)? What is missing ?
> > 
> > If you're on v4.14, then you need to ask for support from whoever gave
> > you that kernel. In this forum we treat mainline only, which currently
> > is at v5.2-rc4. Unless you can try that version of the kernel, we can't
> > really help you here.
> 
> None gave me that kernel, it is the stable 4.14.x tree that Greg maintains, I would
> assume that this forum has some support for stable kernels too?

ONLY use a older LTS kernel if you already have a device up and working
properly and you need "long term" support for it.  Do NOT use it for
bringing up a new device and expecting everything to work properly on it
at all.  That should only be done on the latest stable release, and
sometimes, if you are using an older system, on the latest LTS release.

4.14.y is neither the latest LTS release, nor the latest stable release.
Please try either 4.19.y or 5.1 to see if Linux even works on this
device.  If so, then worry about running an older kernel (but you really
do not want to do that anyway.)

> Looking at upstream, there has not been any significant change in this
> area for a long time.

There are lots and lots of changes that have happened all over the
kernel tree since 4.14.0 was released.  Don't assume things are not
connected at all, they are not.

So please, try 5.1, and if that doesn't work, we will be glad to help
you out.

If you insist on using 4.14 for a device you do not even know if it
works or not, you really are on your own.

thanks,

greg k-h

Re: fsl_udc status?

[Fabio Estevam]

On Mon, Jun 10, 2019 at 4:53 AM Joakim Tjernlund
<Joakim.Tjernlund@infinera.com> wrote:
>
> We are trying to get fsl_udc up and running on a T1042 with without success.

I am not familiar with T1042, but fsl_udc is from the time i.MX
devices didn't have devicetree support.

i.MX has been converted for devicetree for quite some time and the USB
driver we have been using is drivers/usb/chipidea

Maybe you could consider using the chipidea driver instead.


> Seems like this driver is lagging behind the corresponding host driver(mph).
> The mph driver has a number of USB errata workarounds while udc has none.
> At least erratas A007792 seems applicable for udc too.
>
> Is the fsl_udc driver functional on 4.14.x(which we use)? What is missing ?
>
>  Jocke

RE: fsl_udc status?

[Leo Li]

> -----Original Message-----
> From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> Sent: Monday, June 10, 2019 2:52 AM
> To: Leo Li <leoyang.li@nxp.com>; linux-usb@vger.kernel.org
> Subject: fsl_udc status?
> 
> We are trying to get fsl_udc up and running on a T1042 with without success.
> Seems like this driver is lagging behind the corresponding host driver(mph).
> The mph driver has a number of USB errata workarounds while udc has none.
> At least erratas A007792 seems applicable for udc too.
> 
> Is the fsl_udc driver functional on 4.14.x(which we use)? What is missing ?

We are currently providing 4.14 support with our QorIQ SDK.  You can try the kernel tree at https://source.codeaurora.org/external/qoriq/qoriq-components/linux/log/?h=linux-4.14.  I think it is tested on T1042.

I see that there are a few udc related patches that only exist on our SDK code base.  Adding Ran Wang who is maintaining these USB patches internally.  We should definitely try to upstream them instead of maintaining them internally forever.

Regards,
Leo

Re: fsl_udc status?

[Joakim Tjernlund]

On Mon, 2019-06-10 at 17:12 +0000, Leo Li wrote:
> > -----Original Message-----
> > From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > Sent: Monday, June 10, 2019 2:52 AM
> > To: Leo Li <leoyang.li@nxp.com>; linux-usb@vger.kernel.org
> > Subject: fsl_udc status?
> > 
> > We are trying to get fsl_udc up and running on a T1042 with without success.
> > Seems like this driver is lagging behind the corresponding host driver(mph).
> > The mph driver has a number of USB errata workarounds while udc has none.
> > At least erratas A007792 seems applicable for udc too.
> > 
> > Is the fsl_udc driver functional on 4.14.x(which we use)? What is missing ?
> 
> We are currently providing 4.14 support with our QorIQ SDK.  You can try the kernel tree at https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fqoriq%2Fqoriq-components%2Flinux%2Flog%2F%3Fh%3Dlinux-4.14&amp;data=02%7C01%7CJoakim.Tjernlund%40infinera.com%7C1127e5ff228943c6863f08d6edc6e4cd%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C636957835832383776&amp;sdata=FIr8bnUVWFws5RZJvASdN8DANStRoO29Ffwg8GCJ580%3D&amp;reserved=0.  I think it is tested on T1042.
> 
> I see that there are a few udc related patches that only exist on our SDK code base.  Adding Ran Wang who is maintaining these USB patches internally.  We should definitely try to upstream them instead of maintaining them internally forever.

Hi Leo

I checked and cherry-picked the few changes there were in your repo into my 4.14.x stable and no joy :(
Anyhow, I suspect udc gadget was never tested on T1042 as this driver has no support for errata A007792,
without that simple workaround the USB I/F is completely dead.

Could you check if udc/gadget works on T1042RDB(or any T10xy)?
Is there a better driver nowadays than fsl_udc ?

 Jocke
PS.

With some extra debug in IRQ handling and the A007792 we only get this far:
   12.999592] udc:[fsl_udc_irq]  irq_src [0x      40]
[   12.999598] udc:[fsl_udc_irq]  reset int
[   12.999601] udc:[reset_irq]  Bus reset
[   13.001860] udc:[fsl_udc_irq]  irq_src [0x       4]
[   13.001863] udc:[fsl_udc_irq]  port change
[   13.215395] udc:[fsl_udc_irq]  irq_src [0x      40]
[   13.215398] udc:[fsl_udc_irq]  reset int
[   13.215401] udc:[reset_irq]  Bus reset
[   13.217667] udc:[fsl_udc_irq]  irq_src [0x       4]
[   13.217670] udc:[fsl_udc_irq]  port change
[   13.326035] udc:[fsl_udc_irq]  irq_src [0x      10]
[   13.326038] udc:[fsl_udc_irq]  Error IRQ 10
[   18.631463] udc:[fsl_udc_irq]  irq_src [0x      40]
[   18.631469] udc:[fsl_udc_irq]  reset int
[   18.631473] udc:[reset_irq]  Bus reset
[   18.633732] udc:[fsl_udc_irq]  irq_src [0x       4]
[   18.633735] udc:[fsl_udc_irq]  port change
[   18.843936] udc:[fsl_udc_irq]  irq_src [0x      10]
[   18.843939] udc:[fsl_udc_irq]  Error IRQ 10
[   24.263656] udc:[fsl_udc_irq]  irq_src [0x      40]
[   24.263661] udc:[fsl_udc_irq]  reset int
[   24.263665] udc:[reset_irq]  Bus reset
[   24.265926] udc:[fsl_udc_irq]  irq_src [0x       4]
[   24.265929] udc:[fsl_udc_irq]  port change
[   24.479144] udc:[fsl_udc_irq]  irq_src [0x     100]
[   24.479147] udc:[fsl_udc_irq]  suspend int
....
"Error IRQ 10" is USB_STS_SYS_ERR and that is were we are stuck.

   Jocke

RE: fsl_udc status?

[Leo Li]

> -----Original Message-----
> From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> Sent: Monday, June 10, 2019 12:52 PM
> To: Leo Li <leoyang.li@nxp.com>; Ran Wang <ran.wang_1@nxp.com>; linux-
> usb@vger.kernel.org
> Subject: Re: fsl_udc status?
> 
> On Mon, 2019-06-10 at 17:12 +0000, Leo Li wrote:
> > > -----Original Message-----
> > > From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > Sent: Monday, June 10, 2019 2:52 AM
> > > To: Leo Li <leoyang.li@nxp.com>; linux-usb@vger.kernel.org
> > > Subject: fsl_udc status?
> > >
> > > We are trying to get fsl_udc up and running on a T1042 with without
> success.
> > > Seems like this driver is lagging behind the corresponding host
> driver(mph).
> > > The mph driver has a number of USB errata workarounds while udc has
> none.
> > > At least erratas A007792 seems applicable for udc too.
> > >
> > > Is the fsl_udc driver functional on 4.14.x(which we use)? What is missing ?
> >
> > We are currently providing 4.14 support with our QorIQ SDK.  You can try
> the kernel tree at
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourc
> e.codeaurora.org%2Fexternal%2Fqoriq%2Fqoriq-
> components%2Flinux%2Flog%2F%3Fh%3Dlinux-
> 4.14&amp;data=02%7C01%7Cleoyang.li%40nxp.com%7C70fbfaa92c8e4e8a92
> 7008d6edcc48a0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369
> 57858984804209&amp;sdata=YivmkgjDhJ1kMLK3V5o3XFXqOZQaJu4ghnqjQ8
> SZUTU%3D&amp;reserved=0.  I think it is tested on T1042.
> >
> > I see that there are a few udc related patches that only exist on our SDK
> code base.  Adding Ran Wang who is maintaining these USB patches
> internally.  We should definitely try to upstream them instead of maintaining
> them internally forever.
> 
> Hi Leo
> 
> I checked and cherry-picked the few changes there were in your repo into
> my 4.14.x stable and no joy :( Anyhow, I suspect udc gadget was never
> tested on T1042 as this driver has no support for errata A007792, without that
> simple workaround the USB I/F is completely dead.

I will double check the testing result with the testing team.  But I doubt that the A007792 is causing this total failure otherwise the problem should have been there for a long time and unlikely to be left unnoticed.

> 
> Could you check if udc/gadget works on T1042RDB(or any T10xy)?
> Is there a better driver nowadays than fsl_udc ?

There was some effort to make use of the chipidea driver(drivers/usb/chipidea) for the QorIQ platforms.  But I guess the effort stopped when the guy working on it left.  You can try it out, but I don't think the erratum workaround get into that driver either.

> 
>  Jocke
> PS.
> 
> With some extra debug in IRQ handling and the A007792 we only get this far:
>    12.999592] udc:[fsl_udc_irq]  irq_src [0x      40]
> [   12.999598] udc:[fsl_udc_irq]  reset int
> [   12.999601] udc:[reset_irq]  Bus reset
> [   13.001860] udc:[fsl_udc_irq]  irq_src [0x       4]
> [   13.001863] udc:[fsl_udc_irq]  port change
> [   13.215395] udc:[fsl_udc_irq]  irq_src [0x      40]
> [   13.215398] udc:[fsl_udc_irq]  reset int
> [   13.215401] udc:[reset_irq]  Bus reset
> [   13.217667] udc:[fsl_udc_irq]  irq_src [0x       4]
> [   13.217670] udc:[fsl_udc_irq]  port change
> [   13.326035] udc:[fsl_udc_irq]  irq_src [0x      10]
> [   13.326038] udc:[fsl_udc_irq]  Error IRQ 10
> [   18.631463] udc:[fsl_udc_irq]  irq_src [0x      40]
> [   18.631469] udc:[fsl_udc_irq]  reset int
> [   18.631473] udc:[reset_irq]  Bus reset
> [   18.633732] udc:[fsl_udc_irq]  irq_src [0x       4]
> [   18.633735] udc:[fsl_udc_irq]  port change
> [   18.843936] udc:[fsl_udc_irq]  irq_src [0x      10]
> [   18.843939] udc:[fsl_udc_irq]  Error IRQ 10
> [   24.263656] udc:[fsl_udc_irq]  irq_src [0x      40]
> [   24.263661] udc:[fsl_udc_irq]  reset int
> [   24.263665] udc:[reset_irq]  Bus reset
> [   24.265926] udc:[fsl_udc_irq]  irq_src [0x       4]
> [   24.265929] udc:[fsl_udc_irq]  port change
> [   24.479144] udc:[fsl_udc_irq]  irq_src [0x     100]
> [   24.479147] udc:[fsl_udc_irq]  suspend int
> ....
> "Error IRQ 10" is USB_STS_SYS_ERR and that is were we are stuck.
> 
>    Jocke