All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Fabio Estevam <festevam@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
	Peter Chen <peter.chen@nxp.com>,
	linux-usb@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	Chris Healy <cphealy@gmail.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Subject: Re: [PATCH] usb: chipidea: Fix ULPI on imx51
Date: Thu, 21 Jun 2018 14:44:54 -0700	[thread overview]
Message-ID: <CAHQ1cqELs4LaQkmPiPjXQuF17+7PBsEtbmSt8iveLqRv+4bgfQ@mail.gmail.com> (raw)
In-Reply-To: <CAOMZO5B98O9XA8GhdWxJZ6DFgS=O+smHURm8v5jEirj31tuUhg@mail.gmail.com>

On Thu, Jun 21, 2018 at 7:08 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I never assumed it was a regression and that USB worked on RDU1 board
> > before, so I never tried to see if this was a regression. I can only
> > tell you that it hangs as soon as any PORTSC registers are accessed.
>
> I think we need to investigate this portsc register hang further.
>

I just finished experimenting with it on RDU1 and Babbage boards and I
can't reproduce the hang that you describe against 4.18-rc1. At this
point I wonder if it's the bootloader that is a variable that plays
into this. I was booting both boards with 2018.06.0 version of barebox
+ the custom patches that can be found here
https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
last patch in that branch/stack was added as a part of this
investigation, but even before it, I was able to boot Linux just fine,
albeit without working USB.

Any chance you can try it on your end and see if that makes a difference?

Thanks,
Andrey Smirnov

WARNING: multiple messages have this Message-ID (diff)
From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Fabio Estevam <festevam@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
	Peter Chen <peter.chen@nxp.com>,
	linux-usb@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	Chris Healy <cphealy@gmail.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Subject: usb: chipidea: Fix ULPI on imx51
Date: Thu, 21 Jun 2018 14:44:54 -0700	[thread overview]
Message-ID: <CAHQ1cqELs4LaQkmPiPjXQuF17+7PBsEtbmSt8iveLqRv+4bgfQ@mail.gmail.com> (raw)

On Thu, Jun 21, 2018 at 7:08 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I never assumed it was a regression and that USB worked on RDU1 board
> > before, so I never tried to see if this was a regression. I can only
> > tell you that it hangs as soon as any PORTSC registers are accessed.
>
> I think we need to investigate this portsc register hang further.
>

I just finished experimenting with it on RDU1 and Babbage boards and I
can't reproduce the hang that you describe against 4.18-rc1. At this
point I wonder if it's the bootloader that is a variable that plays
into this. I was booting both boards with 2018.06.0 version of barebox
+ the custom patches that can be found here
https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
last patch in that branch/stack was added as a part of this
investigation, but even before it, I was able to boot Linux just fine,
albeit without working USB.

Any chance you can try it on your end and see if that makes a difference?

Thanks,
Andrey Smirnov
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: andrew.smirnov@gmail.com (Andrey Smirnov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] usb: chipidea: Fix ULPI on imx51
Date: Thu, 21 Jun 2018 14:44:54 -0700	[thread overview]
Message-ID: <CAHQ1cqELs4LaQkmPiPjXQuF17+7PBsEtbmSt8iveLqRv+4bgfQ@mail.gmail.com> (raw)
In-Reply-To: <CAOMZO5B98O9XA8GhdWxJZ6DFgS=O+smHURm8v5jEirj31tuUhg@mail.gmail.com>

On Thu, Jun 21, 2018 at 7:08 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I never assumed it was a regression and that USB worked on RDU1 board
> > before, so I never tried to see if this was a regression. I can only
> > tell you that it hangs as soon as any PORTSC registers are accessed.
>
> I think we need to investigate this portsc register hang further.
>

I just finished experimenting with it on RDU1 and Babbage boards and I
can't reproduce the hang that you describe against 4.18-rc1. At this
point I wonder if it's the bootloader that is a variable that plays
into this. I was booting both boards with 2018.06.0 version of barebox
+ the custom patches that can be found here
https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
last patch in that branch/stack was added as a part of this
investigation, but even before it, I was able to boot Linux just fine,
albeit without working USB.

Any chance you can try it on your end and see if that makes a difference?

Thanks,
Andrey Smirnov

  reply	other threads:[~2018-06-21 21:45 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-30 17:34 [PATCH] usb: chipidea: Fix ULPI on imx51 Andrey Smirnov
2018-05-30 17:34 ` Andrey Smirnov
2018-05-30 17:34 ` Andrey Smirnov
2018-05-30 18:10 ` [PATCH] " Fabio Estevam
2018-05-30 18:10   ` Fabio Estevam
2018-05-30 18:10   ` Fabio Estevam
2018-05-31  9:20 ` [PATCH] " Nikita Yushchenko
2018-05-31  9:20   ` Nikita Yushchenko
2018-05-31  9:20   ` Nikita Yushchenko
2018-06-20 22:07 ` [PATCH] " Fabio Estevam
2018-06-20 22:07   ` Fabio Estevam
2018-06-20 22:07   ` Fabio Estevam
2018-06-20 22:22   ` [PATCH] " Fabio Estevam
2018-06-20 22:22     ` Fabio Estevam
2018-06-20 22:22     ` Fabio Estevam
2018-06-21 12:47     ` [PATCH] " Andrey Smirnov
2018-06-21 12:47       ` Andrey Smirnov
2018-06-21 12:47       ` Andrey Smirnov
2018-06-21 14:08       ` [PATCH] " Fabio Estevam
2018-06-21 14:08         ` Fabio Estevam
2018-06-21 14:08         ` Fabio Estevam
2018-06-21 21:44         ` Andrey Smirnov [this message]
2018-06-21 21:44           ` [PATCH] " Andrey Smirnov
2018-06-21 21:44           ` Andrey Smirnov
2018-06-22 16:27           ` [PATCH] " Fabio Estevam
2018-06-22 16:27             ` Fabio Estevam
2018-06-22 16:27             ` Fabio Estevam
2018-06-24 22:40             ` [PATCH] " Andrey Smirnov
2018-06-24 22:40               ` Andrey Smirnov
2018-06-24 22:40               ` Andrey Smirnov
2018-06-24 23:51               ` [PATCH] " Fabio Estevam
2018-06-24 23:51                 ` Fabio Estevam
2018-06-24 23:51                 ` Fabio Estevam
2018-06-25 12:18                 ` [PATCH] " Sebastian Reichel
2018-06-25 12:18                   ` Sebastian Reichel
2018-06-25 12:18                   ` Sebastian Reichel
2018-06-25 12:26                   ` [PATCH] " Fabio Estevam
2018-06-25 12:26                     ` Fabio Estevam
2018-06-25 12:26                     ` Fabio Estevam
2018-06-21 14:12       ` [PATCH] " Nikita Yushchenko
2018-06-21 14:12         ` Nikita Yushchenko
2018-06-21 14:12         ` Nikita Yushchenko
2018-06-21 14:25         ` [PATCH] " Nikita Yushchenko
2018-06-21 14:25           ` Nikita Yushchenko
2018-06-21 14:25           ` Nikita Yushchenko
2018-06-22  0:49           ` [PATCH] " Peter Chen
2018-06-22  0:49             ` Peter Chen
2018-06-22  0:49             ` Peter Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHQ1cqELs4LaQkmPiPjXQuF17+7PBsEtbmSt8iveLqRv+4bgfQ@mail.gmail.com \
    --to=andrew.smirnov@gmail.com \
    --cc=cphealy@gmail.com \
    --cc=fabio.estevam@nxp.com \
    --cc=festevam@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=nikita.yoush@cogentembedded.com \
    --cc=peter.chen@nxp.com \
    --cc=sebastian.reichel@collabora.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.