linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch 1/2] imx51: fix gpiolib support
Date: Wed, 1 Dec 2010 10:25:29 +0100	[thread overview]
Message-ID: <20101201092529.GE32355@pengutronix.de> (raw)
In-Reply-To: <20101201084257.327766974@rtp-net.org>

Hello Arnaud,

On Wed, Dec 01, 2010 at 09:37:16AM +0100, Arnaud Patard wrote:
> The gpiolib code is always returning 0 when reading pad values if the pads
> are configured as output. Using DR registers instead of PSR is fixing that.
> 
> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
> Index: linux-2.6-submit/arch/arm/plat-mxc/gpio.c
> ===================================================================
> --- linux-2.6-submit.orig/arch/arm/plat-mxc/gpio.c	2010-11-24 18:00:47.000000000 +0100
> +++ linux-2.6-submit/arch/arm/plat-mxc/gpio.c	2010-11-24 18:06:54.000000000 +0100
> @@ -276,6 +276,10 @@
>  {
>  	struct mxc_gpio_port *port =
>  		container_of(chip, struct mxc_gpio_port, chip);
> +	u32 l = __raw_readl(port->base + GPIO_GDIR);
> +
> +	if (cpu_is_mx51() && (l & (1 << offset)))
> +		return (__raw_readl(port->base + GPIO_DR) >> offset) & 1;
Maybe only read GDIR on mx51?  Isn't the direction saved by gpiolib
somewhere in RAM?  Is the same needed on other SoCs, too (see below for
my grouping)?  Technically it's not needed at all I think.
(Documentation/gpio.txt has: "However, note that not all platforms can
read the value of output pins; those that can't should always return
zero.".  I didn't check if the implementation conforms here though.)

I wonder if cpu_is_mx51 is the right macro to test, I'd prefer something
like imx_gpio_vX().  IMHO the gpio stuff needs a major overhaul getting
rid of most runtime checks.

We have at least the following groups:

	mx1
	mx21, mx27
	mx25, mx31, mx35, mx51, mxc91231

("at least" in the sense that socs on different lines are different.
I don't guarantee that e.g. mx35 and mxc91231 are really equivalent.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  parent reply	other threads:[~2010-12-01  9:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-01  8:37 [patch 0/2] iMX51 small fixes Arnaud Patard (Rtp)
2010-12-01  8:37 ` [patch 1/2] imx51: fix gpiolib support Arnaud Patard (Rtp)
2010-12-01  9:22   ` Lothar Waßmann
2010-12-01 10:03     ` Arnaud Patard (Rtp)
2010-12-01  9:25   ` Uwe Kleine-König [this message]
2010-12-01 10:09     ` Arnaud Patard (Rtp)
2010-12-01 10:59       ` Alexander Stein
2010-12-01 11:24         ` Arnaud Patard (Rtp)
2010-12-01  8:37 ` [patch 2/2] Fix imx cpufreq driver as module Arnaud Patard (Rtp)

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=20101201092529.GE32355@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).