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@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxx> wrote: >>>>>>> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi >>>>>>> <michael@xxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
