| Message ID | 20181222201648.23449-1-aford173@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: OMAP: pdata-quirks: Remove pbias reference from Torpedo | expand |
* Adam Ford <aford173@gmail.com> [181222 20:17]: > This fixes an issue where the MMC errors our during boot which > requires the user to eject and re-insert the MMC. > > The bootloader has been updated for a while to correct set the > pbias for the GPIO pins. Kernels 4.20-RC1+ are getting hung up > on intializing the MMC. Removing the duplicative PBIAS setting > appears to eliminate the issue. Hmm I wonder if the root cause might be some PBIAS regulator regression between v4.19 and v4.20-rc series? Regards, Tony
On Sun, Dec 23, 2018 at 10:17 AM Tony Lindgren <tony@atomide.com> wrote: > > * Adam Ford <aford173@gmail.com> [181222 20:17]: > > This fixes an issue where the MMC errors our during boot which > > requires the user to eject and re-insert the MMC. > > > > The bootloader has been updated for a while to correct set the > > pbias for the GPIO pins. Kernels 4.20-RC1+ are getting hung up > > on intializing the MMC. Removing the duplicative PBIAS setting > > appears to eliminate the issue. > > Hmm I wonder if the root cause might be some PBIAS regulator > regression between v4.19 and v4.20-rc series? + balajitk@ti.com who's name appears in pbias driver. I noticed the pbias driver does not Disable extended drain IO before changing PBIAS as required on the OMAP36/DM37. I don't know if it's related to my problem. The original entry you made in pdata-quirks referenced the need to do this because the bootloader didn't. Since it's been addressed for a little while in U-Boot, I thought we could remove it now. If you have some ideas on where to disable the extended driain IO in the pbias driver, I can give that a try. adam > > Regards, > > Tony
On Sun, Dec 23, 2018 at 10:17 AM Tony Lindgren <tony@atomide.com> wrote: > > * Adam Ford <aford173@gmail.com> [181222 20:17]: > > This fixes an issue where the MMC errors our during boot which > > requires the user to eject and re-insert the MMC. > > > > The bootloader has been updated for a while to correct set the > > pbias for the GPIO pins. Kernels 4.20-RC1+ are getting hung up > > on intializing the MMC. Removing the duplicative PBIAS setting > > appears to eliminate the issue. > > Hmm I wonder if the root cause might be some PBIAS regulator > regression between v4.19 and v4.20-rc series? Possibly, but I haven't bisected it, but do you think this is even necessary if the bootloader correctly addresses this now? If anything, pdata quirks seems to me to be the wrong place, and we should add the IO disable/enable features into the pbias driver. I'd like to get this applied for 4.20.1 if possible, but I understand if you want more investigation. I am just not sure when I can get to it. As of right now, 4.20 doesn't properly boot the Torpedo board without ejecting and reinserting the card. adam > > Regards, > > Tony
* Adam Ford <aford173@gmail.com> [181227 15:53]: > On Sun, Dec 23, 2018 at 10:17 AM Tony Lindgren <tony@atomide.com> wrote: > > > > * Adam Ford <aford173@gmail.com> [181222 20:17]: > > > This fixes an issue where the MMC errors our during boot which > > > requires the user to eject and re-insert the MMC. > > > > > > The bootloader has been updated for a while to correct set the > > > pbias for the GPIO pins. Kernels 4.20-RC1+ are getting hung up > > > on intializing the MMC. Removing the duplicative PBIAS setting > > > appears to eliminate the issue. > > > > Hmm I wonder if the root cause might be some PBIAS regulator > > regression between v4.19 and v4.20-rc series? > > Possibly, but I haven't bisected it, but do you think this is even > necessary if the bootloader correctly addresses this now? If > anything, pdata quirks seems to me to be the wrong place, and we > should add the IO disable/enable features into the pbias driver. I'd > like to get this applied for 4.20.1 if possible, but I understand if > you want more investigation. I am just not sure when I can get to it. > As of right now, 4.20 doesn't properly boot the Torpedo board without > ejecting and reinserting the card. Yeah so there seems to be a MMC card detect GPIO regression caused by commit e63201f19438 ("mmc: omap_hsmmc: Delete platform data GPIO CD and WP") that I just sent an email about. Anyways, yeah if we can do the IO disable/enable into the pbias driver and get rid of more pdata-quirks.c handling that would be great. Care to check after reverting e63201f19438 and removing the pdata-quirks.c pieces if more changes are still needed? Regards, Tony
On Thu, Dec 27, 2018 at 12:53 PM Tony Lindgren <tony@atomide.com> wrote: > > * Adam Ford <aford173@gmail.com> [181227 15:53]: > > On Sun, Dec 23, 2018 at 10:17 AM Tony Lindgren <tony@atomide.com> wrote: > > > > > > * Adam Ford <aford173@gmail.com> [181222 20:17]: > > > > This fixes an issue where the MMC errors our during boot which > > > > requires the user to eject and re-insert the MMC. > > > > > > > > The bootloader has been updated for a while to correct set the > > > > pbias for the GPIO pins. Kernels 4.20-RC1+ are getting hung up > > > > on intializing the MMC. Removing the duplicative PBIAS setting > > > > appears to eliminate the issue. > > > > > > Hmm I wonder if the root cause might be some PBIAS regulator > > > regression between v4.19 and v4.20-rc series? > > > > Possibly, but I haven't bisected it, but do you think this is even > > necessary if the bootloader correctly addresses this now? If > > anything, pdata quirks seems to me to be the wrong place, and we > > should add the IO disable/enable features into the pbias driver. I'd > > like to get this applied for 4.20.1 if possible, but I understand if > > you want more investigation. I am just not sure when I can get to it. > > As of right now, 4.20 doesn't properly boot the Torpedo board without > > ejecting and reinserting the card. > > Yeah so there seems to be a MMC card detect GPIO regression > caused by commit e63201f19438 ("mmc: omap_hsmmc: Delete platform > data GPIO CD and WP") that I just sent an email about. > > Anyways, yeah if we can do the IO disable/enable into the pbias > driver and get rid of more pdata-quirks.c handling that would > be great. I'll try to work on that this weekend. > > Care to check after reverting e63201f19438 and removing the > pdata-quirks.c pieces if more changes are still needed? I can run some tests on reverting the code commit, but I probably won't get to it until tomorrow. Thanks for identifying that. adam > > Regards, > > Tony
On Thu, Dec 27, 2018 at 12:55 PM Adam Ford <aford173@gmail.com> wrote: > > On Thu, Dec 27, 2018 at 12:53 PM Tony Lindgren <tony@atomide.com> wrote: > > > > * Adam Ford <aford173@gmail.com> [181227 15:53]: > > > On Sun, Dec 23, 2018 at 10:17 AM Tony Lindgren <tony@atomide.com> wrote: > > > > > > > > * Adam Ford <aford173@gmail.com> [181222 20:17]: > > > > > This fixes an issue where the MMC errors our during boot which > > > > > requires the user to eject and re-insert the MMC. > > > > > > > > > > The bootloader has been updated for a while to correct set the > > > > > pbias for the GPIO pins. Kernels 4.20-RC1+ are getting hung up > > > > > on intializing the MMC. Removing the duplicative PBIAS setting > > > > > appears to eliminate the issue. > > > > > > > > Hmm I wonder if the root cause might be some PBIAS regulator > > > > regression between v4.19 and v4.20-rc series? > > > > > > Possibly, but I haven't bisected it, but do you think this is even > > > necessary if the bootloader correctly addresses this now? If > > > anything, pdata quirks seems to me to be the wrong place, and we > > > should add the IO disable/enable features into the pbias driver. I'd > > > like to get this applied for 4.20.1 if possible, but I understand if > > > you want more investigation. I am just not sure when I can get to it. > > > As of right now, 4.20 doesn't properly boot the Torpedo board without > > > ejecting and reinserting the card. > > > > Yeah so there seems to be a MMC card detect GPIO regression > > caused by commit e63201f19438 ("mmc: omap_hsmmc: Delete platform > > data GPIO CD and WP") that I just sent an email about. > > > > Anyways, yeah if we can do the IO disable/enable into the pbias > > driver and get rid of more pdata-quirks.c handling that would > > be great. > > I'll try to work on that this weekend. > > > > Care to check after reverting e63201f19438 and removing the > > pdata-quirks.c pieces if more changes are still needed? I cannot build master and just revert e63201f19438, I get build errors. I can go back to version e7fed63b59310 which is the commit just before e63201f19438 and apply my patch and it still boots. I can apply my patch against master without reverting, and it still boots, so I think it's safe to apply this patch. adam > > I can run some tests on reverting the code commit, but I probably > won't get to it until tomorrow. > > Thanks for identifying that. > > adam > > > > Regards, > > > > Tony
* Adam Ford <aford173@gmail.com> [190118 20:22]: > On Thu, Dec 27, 2018 at 12:55 PM Adam Ford <aford173@gmail.com> wrote: > > > > On Thu, Dec 27, 2018 at 12:53 PM Tony Lindgren <tony@atomide.com> wrote: > > > > > > * Adam Ford <aford173@gmail.com> [181227 15:53]: > > > > On Sun, Dec 23, 2018 at 10:17 AM Tony Lindgren <tony@atomide.com> wrote: > > > > > > > > > > * Adam Ford <aford173@gmail.com> [181222 20:17]: > > > > > > This fixes an issue where the MMC errors our during boot which > > > > > > requires the user to eject and re-insert the MMC. > > > > > > > > > > > > The bootloader has been updated for a while to correct set the > > > > > > pbias for the GPIO pins. Kernels 4.20-RC1+ are getting hung up > > > > > > on intializing the MMC. Removing the duplicative PBIAS setting > > > > > > appears to eliminate the issue. > > > > > > > > > > Hmm I wonder if the root cause might be some PBIAS regulator > > > > > regression between v4.19 and v4.20-rc series? > > > > > > > > Possibly, but I haven't bisected it, but do you think this is even > > > > necessary if the bootloader correctly addresses this now? If > > > > anything, pdata quirks seems to me to be the wrong place, and we > > > > should add the IO disable/enable features into the pbias driver. I'd > > > > like to get this applied for 4.20.1 if possible, but I understand if > > > > you want more investigation. I am just not sure when I can get to it. > > > > As of right now, 4.20 doesn't properly boot the Torpedo board without > > > > ejecting and reinserting the card. > > > > > > Yeah so there seems to be a MMC card detect GPIO regression > > > caused by commit e63201f19438 ("mmc: omap_hsmmc: Delete platform > > > data GPIO CD and WP") that I just sent an email about. > > > > > > Anyways, yeah if we can do the IO disable/enable into the pbias > > > driver and get rid of more pdata-quirks.c handling that would > > > be great. > > > > I'll try to work on that this weekend. > > > > > > Care to check after reverting e63201f19438 and removing the > > > pdata-quirks.c pieces if more changes are still needed? > > I cannot build master and just revert e63201f19438, I get build > errors. I can go back to version e7fed63b59310 which is the commit > just before e63201f19438 and apply my patch and it still boots. > > I can apply my patch against master without reverting, and it still > boots, so I think it's safe to apply this patch. OK thanks will apply this week once I'm done with fixes for the -rc cycle. Regards, Tony
On Mon, Jan 21, 2019 at 2:01 PM Tony Lindgren <tony@atomide.com> wrote: > > * Adam Ford <aford173@gmail.com> [190118 20:22]: > > On Thu, Dec 27, 2018 at 12:55 PM Adam Ford <aford173@gmail.com> wrote: > > > > > > On Thu, Dec 27, 2018 at 12:53 PM Tony Lindgren <tony@atomide.com> wrote: > > > > > > > > * Adam Ford <aford173@gmail.com> [181227 15:53]: > > > > > On Sun, Dec 23, 2018 at 10:17 AM Tony Lindgren <tony@atomide.com> wrote: > > > > > > > > > > > > * Adam Ford <aford173@gmail.com> [181222 20:17]: > > > > > > > This fixes an issue where the MMC errors our during boot which > > > > > > > requires the user to eject and re-insert the MMC. > > > > > > > > > > > > > > The bootloader has been updated for a while to correct set the > > > > > > > pbias for the GPIO pins. Kernels 4.20-RC1+ are getting hung up > > > > > > > on intializing the MMC. Removing the duplicative PBIAS setting > > > > > > > appears to eliminate the issue. > > > > > > > > > > > > Hmm I wonder if the root cause might be some PBIAS regulator > > > > > > regression between v4.19 and v4.20-rc series? > > > > > > > > > > Possibly, but I haven't bisected it, but do you think this is even > > > > > necessary if the bootloader correctly addresses this now? If > > > > > anything, pdata quirks seems to me to be the wrong place, and we > > > > > should add the IO disable/enable features into the pbias driver. I'd > > > > > like to get this applied for 4.20.1 if possible, but I understand if > > > > > you want more investigation. I am just not sure when I can get to it. > > > > > As of right now, 4.20 doesn't properly boot the Torpedo board without > > > > > ejecting and reinserting the card. > > > > > > > > Yeah so there seems to be a MMC card detect GPIO regression > > > > caused by commit e63201f19438 ("mmc: omap_hsmmc: Delete platform > > > > data GPIO CD and WP") that I just sent an email about. > > > > > > > > Anyways, yeah if we can do the IO disable/enable into the pbias > > > > driver and get rid of more pdata-quirks.c handling that would > > > > be great. > > > > > > I'll try to work on that this weekend. > > > > > > > > Care to check after reverting e63201f19438 and removing the > > > > pdata-quirks.c pieces if more changes are still needed? > > > > I cannot build master and just revert e63201f19438, I get build > > errors. I can go back to version e7fed63b59310 which is the commit > > just before e63201f19438 and apply my patch and it still boots. > > > > I can apply my patch against master without reverting, and it still > > boots, so I think it's safe to apply this patch. > > OK thanks will apply this week once I'm done with fixes > for the -rc cycle. Thanks. When you do, any chance it could get back ported to 4.19+ adam > > Regards, > > Tony
* Adam Ford <aford173@gmail.com> [190121 20:06]:
> Thanks. When you do, any chance it could get back ported to 4.19+
Hmm so what about older bootloaders? For a fix to be
applied to the stable kernels, shouldn't we fix the
core problem rather than remove code?
Regards,
Tony
On Mon, Jan 21, 2019 at 3:25 PM Tony Lindgren <tony@atomide.com> wrote: > > * Adam Ford <aford173@gmail.com> [190121 20:06]: > > Thanks. When you do, any chance it could get back ported to 4.19+ > > Hmm so what about older bootloaders? For a fix to be > applied to the stable kernels, shouldn't we fix the > core problem rather than remove code? I spent some time on it, but for some reason my system hangs when I tried to migrate the code to the pbias driver where it should be. I went back to see when the bootloader was fixed, and the pbias IO fix for omap36 was applied in Feb 2017, so it was out long before 4.19 was released. Although the fix it part of the mmc driver and not part of the pbias driver where it should be. I'll try to spend more cycles this afternoon. adam > > Regards, > > Tony
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c index 9fec5f84bf77..05cd546bf61c 100644 --- a/arch/arm/mach-omap2/pdata-quirks.c +++ b/arch/arm/mach-omap2/pdata-quirks.c @@ -57,26 +57,6 @@ static void __init omap2420_n8x0_legacy_init(void) #endif #ifdef CONFIG_ARCH_OMAP3 -/* - * Configures GPIOs 126, 127 and 129 to 1.8V mode instead of 3.0V - * mode for MMC1 in case bootloader did not configure things. - * Note that if the pins are used for MMC1, pbias-regulator - * manages the IO voltage. - */ -static void __init omap3_gpio126_127_129(void) -{ - u32 reg; - - reg = omap_ctrl_readl(OMAP343X_CONTROL_PBIAS_LITE); - reg &= ~OMAP343X_PBIASLITEVMODE1; - reg |= OMAP343X_PBIASLITEPWRDNZ1; - omap_ctrl_writel(reg, OMAP343X_CONTROL_PBIAS_LITE); - if (cpu_is_omap3630()) { - reg = omap_ctrl_readl(OMAP34XX_CONTROL_WKUP_CTRL); - reg |= OMAP36XX_GPIO_IO_PWRDNZ; - omap_ctrl_writel(reg, OMAP34XX_CONTROL_WKUP_CTRL); - } -} static void __init hsmmc2_internal_input_clk(void) { @@ -300,7 +280,6 @@ static void __init omap3_tao3530_legacy_init(void) static void __init omap3_logicpd_torpedo_init(void) { - omap3_gpio126_127_129(); platform_device_register(&wl128x_device); platform_device_register(&btwilink_device); }
This fixes an issue where the MMC errors our during boot which requires the user to eject and re-insert the MMC. The bootloader has been updated for a while to correct set the pbias for the GPIO pins. Kernels 4.20-RC1+ are getting hung up on intializing the MMC. Removing the duplicative PBIAS setting appears to eliminate the issue. Signed-off-by: Adam Ford <aford173@gmail.com>