linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: alexander.stein@systec-electronic.com (Alexander Stein)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch 1/2] imx51: fix gpiolib support
Date: Wed, 1 Dec 2010 11:59:59 +0100	[thread overview]
Message-ID: <201012011200.25430.alexander.stein@systec-electronic.com> (raw)
In-Reply-To: <87hbexu7mr.fsf@lechat.rtp-net.org>

On Wednesday 01 December 2010, 11:09:32 Arnaud Patard wrote:
> > 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.)
> 
> yeah, I know that the gpiolib allows that and in this case, it's always
> returning 0 but while I was debugging an other problem, I wanted to read
> output value and it was not working. The manual was not explicitely
> saying it was not possible so I thought it was a bug and propose a
> fix. Hopefully, sending this patch allows me to get more feedback and
> tell me if I got something wrong and there's a better fix.
> 
> > 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.
> 
> I used cpu_is_mx51() because I only had tested/seen that on imx515. I
> wanted to avoid breaking other systems while trying to fix mine.
> As regards getting rid of runtime checks, maybe registering different
> gpiochip depending on the SoC would allow to check it a init time and no
> more check later.

I can conform, that reading from GPIO_DR on mx35 works too. Also checked with 
the description is this register. It seem to show exactly what we want, 
regarding GPIO_GDIR value. So even evaluating GPIO_DIR isn't needed at all.
My fix was to simply replace GPIO_PSR with GPIO_DR.

Best regards,
Alexander

  reply	other threads:[~2010-12-01 10:59 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
2010-12-01 10:09     ` Arnaud Patard (Rtp)
2010-12-01 10:59       ` Alexander Stein [this message]
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=201012011200.25430.alexander.stein@systec-electronic.com \
    --to=alexander.stein@systec-electronic.com \
    --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).