public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Allen Martin <amartin@nvidia.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] tegra: pinmux: fix FUNCMUX_NDFLASH_KBC_8_BIT
Date: Tue, 22 Jan 2013 17:55:08 -0800	[thread overview]
Message-ID: <20130123015508.GA32309@badger> (raw)
In-Reply-To: <1358893650.1540.27.camel@tellur>

On Tue, Jan 22, 2013 at 02:27:30PM -0800, Lucas Stach wrote:
> Am Dienstag, den 22.01.2013, 09:24 -0700 schrieb Stephen Warren:
> > On 01/21/2013 05:20 PM, Lucas Stach wrote:
> > > Even the 8bit case needs KBCB configured, as pin D7 is located in this
> > > pingroup. Also pingroup ATC seems to come out of reset with config set
> > > to NAND, so we need to explictly configure some other function to this
> > > group in order to avoid clashing settings.
> > 
> > > diff --git a/arch/arm/cpu/tegra20-common/funcmux.c b/arch/arm/cpu/tegra20-common/funcmux.c
> > 
> > > @@ -266,17 +266,25 @@ int funcmux_select(enum periph_id id, int config)
> > >  			break;
> > >  		case FUNCMUX_NDFLASH_KBC_8_BIT:
> > ...
> > > +			/*
> > > +			 * configure pingroup ATC to something unrelated to
> > > +			 * avoid ATC overriding KBC
> > > +			 */
> > > +			pinmux_set_func(PINGRP_ATC, PMUX_FUNC_GMI);
> > > +
> > 
> > This gets a bit dangerous; what if pingroup ATC was already configured
> > for some function other than NAND or GMI? This code will then break that
> > setting. I would suggest one of the following alternatives:
> > 
> > 1) Use the new pinmux_avoid_func() function implemented in the patch
> > that I just sent.
> > 
> > 2) Move Tegra20 over to the new board-wide pinmux style that Tegra30
> > uses, where the entire pinmux is initialized in one shot. This will
> > completely avoid any kind of uninitialized pinmux settings, and to some
> > extent is the only sensible thing to do on a device like Tegra which has
> > the potential for conflicts like this patch tries to avoid.
> > 
> I'll take a look on how much work it is to implement option #2. If it
> isn't too much and I find some time in this U-Boot release cycle, I'm
> very much inclined to do this the ultimately right way.

I think #2 really is the only way to do it.  The reset state is full
of conflicts and unless everything is initialized at once you end up
chasing your tail where you fix conflict A, but that leads to new
conflict B, and fixing that leads to C, etc.

-Allen
-- 
nvpublic

  reply	other threads:[~2013-01-23  1:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22  0:20 [U-Boot] [PATCH] tegra: pinmux: fix FUNCMUX_NDFLASH_KBC_8_BIT Lucas Stach
2013-01-22 16:24 ` Stephen Warren
2013-01-22 22:27   ` Lucas Stach
2013-01-23  1:55     ` Allen Martin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-03-24 12:29 Marcel Ziswiler
2015-03-24 15:21 ` Stephen Warren
2015-03-25  7:42   ` Marcel Ziswiler
2015-03-25 17:46   ` Marcel Ziswiler
2015-03-25 18:08     ` Stephen Warren

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=20130123015508.GA32309@badger \
    --to=amartin@nvidia.com \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox