ARM: OMAP: pdata-quirks: Remove pbias reference from Torpedo
diff mbox series

Message ID 20181222201648.23449-1-aford173@gmail.com
State New
Headers show
Series
  • ARM: OMAP: pdata-quirks: Remove pbias reference from Torpedo
Related show

Commit Message

Adam Ford Dec. 22, 2018, 8:16 p.m. UTC
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>

Comments

Tony Lindgren Dec. 23, 2018, 4:17 p.m. UTC | #1
* 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
Adam Ford Dec. 23, 2018, 4:24 p.m. UTC | #2
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
Adam Ford Dec. 27, 2018, 3:52 p.m. UTC | #3
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
Tony Lindgren Dec. 27, 2018, 6:53 p.m. UTC | #4
* 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
Adam Ford Dec. 27, 2018, 6:55 p.m. UTC | #5
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
Adam Ford Jan. 18, 2019, 8:22 p.m. UTC | #6
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
Tony Lindgren Jan. 21, 2019, 8:01 p.m. UTC | #7
* 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
Adam Ford Jan. 21, 2019, 8:06 p.m. UTC | #8
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
Tony Lindgren Jan. 21, 2019, 9:24 p.m. UTC | #9
* 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
Adam Ford Jan. 24, 2019, 3:52 p.m. UTC | #10
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

Patch
diff mbox series

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);
 }