From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] tegra30: fix UART2 pinmux table entry
Date: Wed, 09 Jan 2013 11:48:39 -0700 [thread overview]
Message-ID: <50EDBB87.1030702@wwwdotorg.org> (raw)
In-Reply-To: <20130109175822.GA25746@badger>
On 01/09/2013 10:58 AM, Allen Martin wrote:
> On Tue, Jan 08, 2013 at 07:46:03PM -0800, Stephen Warren wrote:
>> On 01/08/2013 06:23 PM, Allen Martin wrote:
>>> UART2_TXD and UART2_RXD mux 0 SFIO entries should be IRDA not UARTB.
>>
>> IRDA is just a needlessly different synonym for UARTB; there shouldn't
>> be any mention of IRDA in the pinmux code anywhere, or any users of the
>> pinmux code.
>
> Oh suck, I didn't realize we had synonyms in the pinmux tables, that
> seems like a really bad idea. Unfortunately it looks like this
> particular synonym is widespread. I see it used in the pinmux
> spreadsheets, the downstream Android kernel source, and gfshell code.
It will disappear from the downstream kernels once they've picked up the
upstream pinctrl driver; I spent a fair bit of time correlating all the
various documentation sources and eliminating duplicate names for the
upstream kernel pinctrl driver.
> The bug I was trying to fix here is that IRDA is referenced in the
> u-boot cardhu pinmux table.
Oh, I didn't notice that the second time round; I'm pretty sure I
pointed it out in the very first review. Maybe that was just of the
U-Boot pinmux driver and not the Cardhu file.
> I guess the fix is to change that to
> UARTB, but it sounds like maybe a larger synonym cleanup is needed
> everywhere, do you know of any others?
I can't recall for sure; I think there were some. I'd suggest comparing
upstream U-Boot's pinmux driver with the upstream kernel's pinctrl
driver, treating the kernel as canonical now.
> I'm thinking there needs to be some better run time error checking in
> the u-boot pinmux code too. There are some debug asserts in there
> now, but because I didn't have debug turned on this particular bug
> lead to silent corruption of the pinmux registers which was a PITA to
> track down. Thoughts on turning those asserts into always on error
> checking code? Not sure how much it will slow down pinmux programming.
I doubt the speed would be significantly affected, unless an error
triggers and the printf/... actually happens, but you don't really care
about speed then.
prev parent reply other threads:[~2013-01-09 18:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 1:23 [U-Boot] [PATCH] tegra30: fix UART2 pinmux table entry Allen Martin
2013-01-09 3:46 ` Stephen Warren
2013-01-09 17:58 ` Allen Martin
2013-01-09 18:48 ` Stephen Warren [this message]
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=50EDBB87.1030702@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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