All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Nishanth Menon <nm@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>,
	linux-omap@vger.kernel.org, bcousson@baylibre.com,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	nsekhar@ti.com, rnayak@ti.com, mark.rutland@arm.com,
	Dave Gerlach <d-gerlach@ti.com>
Subject: Re: [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5
Date: Fri, 25 Apr 2014 09:46:14 -0700	[thread overview]
Message-ID: <20140425164614.GE20807@atomide.com> (raw)
In-Reply-To: <20140417163407.GB23385@atomide.com>

* Tony Lindgren <tony@atomide.com> [140417 09:34]:
> * Nishanth Menon <nm@ti.com> [140325 08:05]:
> > On 03/21/2014 12:20 AM, Lokesh Vutla wrote:
> > > From: Dave Gerlach <d-gerlach@ti.com>
> > > 
> > > Do not reset GPIO5 at boot-up because GPIO5_7 is used
> > > on AM437x GP-EVM to control VTT regulators on DDR3.
> > > Without this some GP-EVM boards will fail to boot because
> > > of DDR3 corruption.
> 
> How funny :)
> 
> Ideally we would be able to specify which GPIO pins should
> maintain their state during the boot.
> 
> AFAIK, this patch currently means that the kernel has no idea
> what state the whole GPIO bank is in. At minimum we should
> parse the GPIO bank state so the kernel knows it and then it
> should be safe to set the no reset flag.
> 
> So for the workaround, can you guys please try to see test
> if the old mux trick in the bootloader works to mux the pin
> into something PIN_INPUT_PULLUP | MUX_MODE7? Or a PULLDOWN
> depending on the direction naturally. That would allow
> leaving out the GPIO completely from this.

OK so no safe mode as MUX_MODE7 on am335x. So based on the
tests done by Dave on various GPIO banks without the reset,
this seems OK to do. So applying into omap-for-v3.15/fixes-v2
to get the board booting properly.

Naturally this is not a reason to stop further work on making
sure the GPIO driver actually knows what state the bank is
as suggested by Felipe.

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5
Date: Fri, 25 Apr 2014 09:46:14 -0700	[thread overview]
Message-ID: <20140425164614.GE20807@atomide.com> (raw)
In-Reply-To: <20140417163407.GB23385@atomide.com>

* Tony Lindgren <tony@atomide.com> [140417 09:34]:
> * Nishanth Menon <nm@ti.com> [140325 08:05]:
> > On 03/21/2014 12:20 AM, Lokesh Vutla wrote:
> > > From: Dave Gerlach <d-gerlach@ti.com>
> > > 
> > > Do not reset GPIO5 at boot-up because GPIO5_7 is used
> > > on AM437x GP-EVM to control VTT regulators on DDR3.
> > > Without this some GP-EVM boards will fail to boot because
> > > of DDR3 corruption.
> 
> How funny :)
> 
> Ideally we would be able to specify which GPIO pins should
> maintain their state during the boot.
> 
> AFAIK, this patch currently means that the kernel has no idea
> what state the whole GPIO bank is in. At minimum we should
> parse the GPIO bank state so the kernel knows it and then it
> should be safe to set the no reset flag.
> 
> So for the workaround, can you guys please try to see test
> if the old mux trick in the bootloader works to mux the pin
> into something PIN_INPUT_PULLUP | MUX_MODE7? Or a PULLDOWN
> depending on the direction naturally. That would allow
> leaving out the GPIO completely from this.

OK so no safe mode as MUX_MODE7 on am335x. So based on the
tests done by Dave on various GPIO banks without the reset,
this seems OK to do. So applying into omap-for-v3.15/fixes-v2
to get the board booting properly.

Naturally this is not a reason to stop further work on making
sure the GPIO driver actually knows what state the bank is
as suggested by Felipe.

Tony

  reply	other threads:[~2014-04-25 16:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-21  5:20 [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5 Lokesh Vutla
2014-03-21  5:20 ` Lokesh Vutla
     [not found] ` <1395379213-15451-1-git-send-email-lokeshvutla-l0cyMroinI0@public.gmane.org>
2014-03-21  5:52   ` Felipe Balbi
2014-03-21  5:52     ` Felipe Balbi
2014-03-24 15:29     ` Dave Gerlach
2014-03-24 15:29       ` Dave Gerlach
2014-03-24 18:50       ` Felipe Balbi
2014-03-24 18:50         ` Felipe Balbi
2014-03-24 19:01         ` Nishanth Menon
2014-03-24 19:01           ` Nishanth Menon
2014-03-24 19:22           ` Felipe Balbi
2014-03-24 19:22             ` Felipe Balbi
2014-03-25 15:02 ` Nishanth Menon
2014-03-25 15:02   ` Nishanth Menon
     [not found]   ` <53319A7D.1060904-l0cyMroinI0@public.gmane.org>
2014-04-17 16:34     ` Tony Lindgren
2014-04-17 16:34       ` Tony Lindgren
2014-04-25 16:46       ` Tony Lindgren [this message]
2014-04-25 16:46         ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140425164614.GE20807@atomide.com \
    --to=tony@atomide.com \
    --cc=bcousson@baylibre.com \
    --cc=d-gerlach@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=mark.rutland@arm.com \
    --cc=nm@ti.com \
    --cc=nsekhar@ti.com \
    --cc=rnayak@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.