All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben-linux@fluff.org>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: 'Ben Dooks' <ben-linux@fluff.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, kyungmin.park@samsung.com
Subject: Re: [PATCH] ARM: S5P: Dynamicly numbered GPIO interrupt support
Date: Sat, 15 May 2010 01:11:03 +0100	[thread overview]
Message-ID: <20100515001103.GQ26401@trinity.fluff.org> (raw)
In-Reply-To: <008e01caf345$50ad0610$f2071230$%szyprowski@samsung.com>

On Fri, May 14, 2010 at 11:10:19AM +0200, Marek Szyprowski wrote:
> Hello,
> 
> On Friday, May 14, 2010 10:40 AM Ben Dooks wrote:
> 
> > Add support for GPIO interrupts where the interrupt number
> > is dynamically allocated at first request from gpiolib.
> > 
> > This method is employed as the newer SoCs have a large number
> > of possible interrupt numbers which are very rarely heavily
> > used. However, the classic code has always registered all
> > possible interrupts, using a large amount of memory for the
> > irq_desc[] table.
> 
> I like this idea, however I already see some problems. This solves
> only gpio to irq mappings, but what about reverse mappings? There
> are many i2c/spi/whatever drivers that requires a irq number to be
> passed with platform data. With static gpio-irq mappings this is
> trivial. However with dynamic gpio2irq mappings this becomes more
> complicated. 
> 
> Machine startup code would need to:
> 1. request the gpio pin used for interrupt (ok)
> 2. convert it to irq number (ok)
> 3. put it in driver specific platform data (ok)
> 4. release the gpio pin (?)
> 
> Would request_irq() work after release of that gpio pin?

I was actually considering exporting it as both a gpiolib call
and a call which is s5p specific, say s5p_map_gpio_irq() which
odes the neessary chip mampping.

At the moment, we don't release the interrupt range once we get
it as there's no call in gpiolib to reverse to_irq() and even
if you release the irq, it is still possible the driver will
have noted the irq number and then re-request it.
  
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

WARNING: multiple messages have this Message-ID (diff)
From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: S5P: Dynamicly numbered GPIO interrupt support
Date: Sat, 15 May 2010 01:11:03 +0100	[thread overview]
Message-ID: <20100515001103.GQ26401@trinity.fluff.org> (raw)
In-Reply-To: <008e01caf345$50ad0610$f2071230$%szyprowski@samsung.com>

On Fri, May 14, 2010 at 11:10:19AM +0200, Marek Szyprowski wrote:
> Hello,
> 
> On Friday, May 14, 2010 10:40 AM Ben Dooks wrote:
> 
> > Add support for GPIO interrupts where the interrupt number
> > is dynamically allocated at first request from gpiolib.
> > 
> > This method is employed as the newer SoCs have a large number
> > of possible interrupt numbers which are very rarely heavily
> > used. However, the classic code has always registered all
> > possible interrupts, using a large amount of memory for the
> > irq_desc[] table.
> 
> I like this idea, however I already see some problems. This solves
> only gpio to irq mappings, but what about reverse mappings? There
> are many i2c/spi/whatever drivers that requires a irq number to be
> passed with platform data. With static gpio-irq mappings this is
> trivial. However with dynamic gpio2irq mappings this becomes more
> complicated. 
> 
> Machine startup code would need to:
> 1. request the gpio pin used for interrupt (ok)
> 2. convert it to irq number (ok)
> 3. put it in driver specific platform data (ok)
> 4. release the gpio pin (?)
> 
> Would request_irq() work after release of that gpio pin?

I was actually considering exporting it as both a gpiolib call
and a call which is s5p specific, say s5p_map_gpio_irq() which
odes the neessary chip mampping.

At the moment, we don't release the interrupt range once we get
it as there's no call in gpiolib to reverse to_irq() and even
if you release the irq, it is still possible the driver will
have noted the irq number and then re-request it.
  
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

  reply	other threads:[~2010-05-15  0:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-14  8:40 [PATCH] ARM: S5P: Dynamicly numbered GPIO interrupt support Ben Dooks
2010-05-14  8:40 ` Ben Dooks
2010-05-14  9:10 ` Marek Szyprowski
2010-05-14  9:10   ` Marek Szyprowski
2010-05-15  0:11   ` Ben Dooks [this message]
2010-05-15  0:11     ` Ben Dooks
2010-05-14  9:16 ` Jassi Brar
2010-05-14  9:16   ` Jassi Brar

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=20100515001103.GQ26401@trinity.fluff.org \
    --to=ben-linux@fluff.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.