From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: imx25-pinfunc: remove SION from all modes
Date: Fri, 3 Jun 2016 21:31:48 +0200 [thread overview]
Message-ID: <20160603193148.GW26768@pengutronix.de> (raw)
In-Reply-To: <20160603140107.GA8659@tiger>
On Fri, Jun 03, 2016 at 10:01:07PM +0800, Shawn Guo wrote:
> On Fri, Jun 03, 2016 at 03:32:47PM +0200, Uwe Kleine-K?nig wrote:
> > I found a regression of the patch under discussion (which was not
> > applied, so no big problem). On the custom mx25 based hardware an
> > SD-card isn't detected any more after removing SION from
> > MX25_PAD_SD1_CMD__SD1_CMD. I verified the same happens on a tx25.
> >
> > Is this expected? IMHO it's unfortunate (if not a silicon bug) that you
> > need the SION bit here as the SION bit has some more side effects. If
> > you ask me, muxing a certain function for a pin should enable the input
> > path to the respective module if the pin is bidirectional.
> >
> > Is there a list of pin/function pairs that need the SION bit set? Shawn,
> > would you agree to accept this patch with the high risk that it
> > introduces regressions? Or maybe we should make the SION bit more easily
> > overridable for board dts files (and default to off unless known it's
> > needed)?
>
> I would be conservative on this. Can we just fix the SION bits that are
> known doing harm?
I didn't do any measurements, but I'd expect that every SION bit that is
set without good reason increases current consumption. So each SION bit
does some harm. Plus debugging a missing SION bit is much easier than a
SION bit that is set without need.
The first problem I debugged was an UART problem and the SION bit had to
be removed from MX25_PAD_KPP_ROW3__GPIO_3_0 (plus back then
MX25_PAD_KPP_ROW3__UART1_RI wasn't defined). The problem I had now was a
broken SD card and I had to add SION to MX25_PAD_SD1_CMD__SD1_CMD.
So I expect my commit to (maybe) introduce some obvious and easy to
debug regressions and to (probably) fix some harder to debug and not so
obvious problems. I'd say it's a net win.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2016-06-03 19:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-19 19:45 [PATCH] ARM: imx25-pinfunc: remove SION from all modes Uwe Kleine-König
2016-04-19 21:19 ` Russell King - ARM Linux
2016-04-20 7:51 ` Uwe Kleine-König
2016-04-20 8:46 ` Lothar Waßmann
2016-04-20 8:58 ` Uwe Kleine-König
2016-06-03 13:32 ` Uwe Kleine-König
2016-06-03 14:01 ` Shawn Guo
2016-06-03 19:31 ` Uwe Kleine-König [this message]
2016-06-13 10:16 ` Uwe Kleine-König
2016-06-13 10:17 ` [PATCH 1/2] ARM: imx25-pinfunc: document SION being important for MX25_PAD_SD1_CMD__SD1_CMD Uwe Kleine-König
2016-06-13 10:17 ` [PATCH 2/2] ARM: imx25-pinfunc: remove SION from all modes Uwe Kleine-König
2016-06-16 0:32 ` [PATCH] " Shawn Guo
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=20160603193148.GW26768@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).