linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Jochen Friedrich <jochen@scram.de>
Cc: linuxppc-dev@ozlabs.org, Arnd Bergmann <arnd@arndb.de>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API
Date: Sun, 27 Jan 2008 19:08:18 +0300	[thread overview]
Message-ID: <20080127160818.GA25859@zarina> (raw)
In-Reply-To: <479C8A34.2000701@scram.de>

On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> Hi Anton,
> 
> > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > +{
> > +	struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > +	struct port_regs *regs = mm_gc->regs;
> > +	u32 pin_mask;
> > +	u32 tmp_val;
> > +
> > +	/* calculate pin location */
> > +	pin_mask = (u32) (1 << (NUM_OF_PINS - 1 - gpio));
> > +
> > +	tmp_val = in_be32(&regs->cpdata);
> > +
> > +	if (val == 0)
> > +		out_be32(&regs->cpdata, ~pin_mask & tmp_val);
> > +	else
> > +		out_be32(&regs->cpdata, pin_mask | tmp_val);
> > +}
> 
> I see a possible problem with this (and in the corresponding call in CPM1, as well):
> 
> if there is a pin configured as open drain, you might accidently switch this pin to 0
> while switching a different pin, if an external device is pulling the pin to 0.

Unfortunately I can't think out any workaround for this, except
implementing generic gpio_bank_{,un}lock(gpio_pin_on_the_bank), and
start using it in the drivers that might care about this issue. Though,
looking into i2c-gpio.c I don't clearly see were we can insert these
locks, there should be "start/end transaction" handlers or something,
but it seems that it's in the bitbanging code, not in the i2c-gpio
driver..

Actually, I see this as a hardware limitation. For example, on ARMs
PXA2xx, there are separate, per bank, read/set/clear GPIO registers,
not all-in-one data register.

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

  reply	other threads:[~2008-01-27 17:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-08 18:43 [PATCH RFC 0/3] PowerPC: implement support for GPIO LIB API Anton Vorontsov
2008-01-08 18:45 ` [PATCH 1/3] [POWERPC] Implement support for the " Anton Vorontsov
2008-01-09  0:20   ` Stephen Rothwell
2008-01-08 18:45 ` [PATCH 2/3] [POWERPC] QE: split par_io_config_pin() Anton Vorontsov
2008-01-08 18:45 ` [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API Anton Vorontsov
2008-01-27 13:42   ` Jochen Friedrich
2008-01-27 16:08     ` Anton Vorontsov [this message]
2008-01-27 20:59       ` Grant Likely
2008-01-27 21:23         ` Anton Vorontsov
2008-01-08 18:50 ` [PATCH RFC 0/3] PowerPC: implement support for " Grant Likely

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=20080127160818.GA25859@zarina \
    --to=cbouatmailru@gmail.com \
    --cc=arnd@arndb.de \
    --cc=david@gibson.dropbear.id.au \
    --cc=jochen@scram.de \
    --cc=linuxppc-dev@ozlabs.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).