From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Date: Thu, 25 Jan 2018 11:17:27 +0100
Subject: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
In-Reply-To: <36da5c7c-beb5-2a9c-90de-a03980631918@wsystem.com>
References: <1516805770-6712-1-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5CXtuKnZHSCBSVs20J7QUpckfHiy0-HYRKeEhWwtncZRQ@mail.gmail.com>
 <CAOf5uwkigLkNc_B4X2Kz=6WLypdU9LveCs7rw7ZGCTMR2AiqSw@mail.gmail.com>
 <CAOf5uw=1mgNsatRsR-C-shLEefERG42NKp7L4kmLjNtwb5mHGw@mail.gmail.com>
 <CAOMZO5CSyj875upLJVv9YpaOn-1FjBqHwX-uRtv++exmV++1NA@mail.gmail.com>
 <CAOf5uwn739N3tMP0hKiFaaSMojS1bZANCjJ1QWMgwCboVex-_w@mail.gmail.com>
 <42c042a8-169e-1843-a7f4-a46d4ef60d2a@wsystem.com>
 <CAOf5uwmwET_rfh=Fr5Dg_BukQ7brWr6cUVc4uFooRbX4QeSDxw@mail.gmail.com>
 <CAOMZO5Cm=GQw4d32RE5JdFrRiCedrfxgveUcDpTGZysv3cmZJA@mail.gmail.com>
 <6ab6f607-1736-2123-6387-636c8e452046@wsystem.com>
 <CAOMZO5D658629PACPSx7PX98QRfY50yHjjq+SPEW7gp2Akb18g@mail.gmail.com>
 <CAOf5uwn1y+bge0bAjYduboH7wLmbuJaS1oLgWt9Xn4LZ9Ud90Q@mail.gmail.com>
 <CAOMZO5CARLSyk1oNA2t3bT_ZzGvaUjyOnaeJYsiP2o2Z6PbBaw@mail.gmail.com>
 <CAOf5uwkqadc1dtmi=zsTLO5rSFXv=kk8sU5kU_FWFLNGUKmAPw@mail.gmail.com>
 <36da5c7c-beb5-2a9c-90de-a03980631918@wsystem.com>
Message-ID: <CAOf5uwnzBo0xDfo9O=H9LMx+=CO+7aL5g+NM=rZrnVv-HzqgQQ@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
To: u-boot@lists.denx.de

Hi

On Thu, Jan 25, 2018 at 11:02 AM, Benoît Thébaudeau <benoit@wsystem.com> wrote:
> Hi Michael,
>
> On 25/01/2018 at 06:47, Michael Nazzareno Trimarchi wrote:
>> On 25 Jan. 2018 12:07 am, "Fabio Estevam" <festevam at gmail.com <mailto:festevam@gmail.com>> wrote:
>>
>>     Hi Michael,
>>
>>     On Wed, Jan 24, 2018 at 3:46 PM, Michael Nazzareno Trimarchi
>>     <michael at amarulasolutions.com <mailto:michael@amarulasolutions.com>> wrote:
>>
>>     > This is exactly my initial propose. Can we give a try and manage on board level?
>>
>>     The kernel should not rely on the IOMUX setting done by the bootloader.
>>
>>     Do you use 0x80000000 in your dts IOMUX configuration by any chance?
>>
>>     0x80000000 means that the kernel will not do IOMUX configuration and
>>     will use the IOMUX value that comes from the bootloader.
>>
>>
>> Yes but those should not be even wrong. We can not be sure if the state machine of any logic as already corrupted. Remember that we have already this problem with the clock in general that most of the time are already enabled and so logic can be up.
>>
>>
>>     It seems you can fix your USB problem by not using the IOMUX value
>>     from the bootloader and just use the good IOMUX (without SION)
>>     explicitly in your dts.
>>
>>     Does it fix the problem?
>>
>>
>> I think that the way to fix in a specific case could be more then one. I will do the best on my side but I will include to not touch iomux without any reason. I already point out that just with few pins configured like console I get the problem . I can check two extra gpio too.
>>
>> To be clear, my board was "working". We are talking about a product in the field since years with one minimal USB mulfuction . Other boards can have the same problem but just not rise in the field. If the host port is direct connected to the pen drive without an hub the USB reset can most of the time recover the connection.
>
> I agree with Fabio: Linux should not rely on the pad configurations performed by

This is not the linux mailing list

> U-Boot. But as you say, U-Boot should work fine itself too. Have you tested the
> problematic USB pen drive with U-Boot?
>

ehci phy of imx25 is not supported in uboot I think and it's not in
the scope of this change


> Besides your USB issue, in order to optimize power consumption, iomux-mx25.h
> should not set SION by default, except for the pad functions that can in no way
> work without it (still to be identified/tested). For the other use cases, the
> board files can set SION themselves, thanks to a NEW_PAD_CTRL()-like mechanism
> (apparently yet to be introduced into U-Boot). The changes introduced here
> should not break anything for the current in-tree boards.

yes I know.

>
> You said that setting SION only for a UART is enough to trigger your USB issue.
> Of course, there is no reason to set SION by default for a UART, but I was
> thinking about a possible link between UART and USB, as this behavior is very
> strange. Which USB host port are use using with the problematic pen drive, and
> with which PHY (SoC-internal/external, bus)? Have you checked that this port is
> properly configured for this PHY and PWR/OC (on/off + polarity) in both U-Boot
> and Linux? For instance, if this port is configured to use OC but no OC signal

Nothing of above is connected. Pen drive is in the linux thread
described in the commit
message. All the usb stack is fully functional with a lot of pen
drive. OC, PWR are not
managed on USB/serial ehci port so they are not involved and I can
check. I have posted
some patches on linux mailing list to fix minor stuff. Let's say any
permutation bit on phy
configuration does not solve the problem. It's not a problem of usb
suspend etc. I think that
approch should be:

- align the pin mux mx25 file to the other architecture. So drop all
the sion bit expect for the one
where we know that silicon is buggy
- apply SION when is needed in the board that are already in uboot
- send patches on pin mux for board that are in mainline and we can test

On my side. I will restrict the change on my board to full isolate the
configuration. Force the reset of SION
bit anyway in linux if this solve.

Agree?

Michael

> is actually wired, this can probably do weird things.
>
> Best regards,
> Benoît



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |