[U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

[Benoît Thébaudeau]

Hi,

On 24/01/2018 at 17:17, Michael Nazzareno Trimarchi wrote:
> On Wed, Jan 24, 2018 at 5:03 PM, Benoît Thébaudeau <benoit at wsystem.com> wrote:
>> On 24/01/2018 at 16:43, Michael Nazzareno Trimarchi wrote:
>>> On Wed, Jan 24, 2018 at 4:39 PM, Benoît Thébaudeau <benoit at wsystem.com> wrote:
>>>> On 24/01/2018 at 16:34, Benoît Thébaudeau wrote:
>>>>> On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote:
>>>>>> On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam <festevam at gmail.com> wrote:
>>>>>>> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi
>>>>>>> <michael at amarulasolutions.com> wrote:
>>>>>>>> SION bit should be used in the situation that we need
>>>>>>>> to read back the value of a pin and should be set by
>>>>>>>> default.
>>>>>
>>>>> You remove this bit because it should be set by default? This sentence is
>>>>> confusing.
>>>
>>> English is wrong ;)
>>>
>>> SION bit as a specific purpose to read back value that is set in
>>> output. You don't need
>>> and it's not set in any freescale board. If you need to set you need
>>> to add to your peripheral.
>>
>> Unless there is a NEW_PAD_CTRL()-like mechanism for SION, all these definitions
>> should be kept in iomux-mx25.h in order not to redefine the register offsets
>> everywhere. AFAIK, all the Freescale boards use the definitions from
>> iomux-mx25.h too.
>>
>>> The only case you need maybe is the data[0] of sdcard.
>>
>> And eSDHC CMD, and I²C probably too. Yet, you are also removing SION in these
>> cases. I have 3 i.M25-based boards working fine with SION. ;) Can you explain
>> the precise issue that you are trying to fix (which pin)?
>>
> 
> Let me summarize for you:
> - was having a board with linux 2.6.x and uboot from 2009 working fine
> on a usb pen driver (look on thread in linux-usb)
> - was having the same board with any version of linux from 3.18 to
> 4.15 and fail with this pen drive
> - check back all the changes from linux 2.6.x  to linux 4.15.x and
> compare every single register and all the usb code and was just
> confirm a better implementation of new kernel.
>   but with a result of a usb stuck on the host port
> - swap the boot-loader and having a working board
> - go in deep in boot-loader and compare everything
> - Understand the difference was the SION bit that was enable on all the mux
> 
> In general when a board start from reset it has default pin muxing.
> Each peripheral need to setup the pin muxing according to the real
> usage.
> SION by default is not the right way to do it. What is the concept of
> working board in your side? Just pass your testcase? Ok even this
> board
> was passing all test cases apart this usb pen drive. We was having in
> the field some customer with usb issue time to time and only this
> proof that somenthing was not real ok.

Thanks for these details. All the test cases should of course work. I'm just
trying to figure out the root cause of your issue, and maybe it's not SION
itself but a power issue triggered by SION, or maybe it's SION only for some
specific pads and not for all the pads, or something else. So what I'm saying is
that this change might be too large, and care should be taken.

Some Freescale boards actually do use SION. E.g., see
MX25_PAD_FEC_MDIO__FEC_MDIO in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx25-pdk.dts?h=v4.15-rc9 . SION is required to read back the actual state of a GPIO
in output mode. It is also required for some bidirectional alternate functions
(such as I²C SDA/SCL, SD CMD/DATn, etc.) on some i.MXs (not all i.MXs behave in
the same way for the same peripheral), but which ones are affected is not always
documented, so please double check and test all these cases.

Best regards,
Benoît