All of lore.kernel.org
 help / color / mirror / Atom feed
From: nicolas.pitre@linaro.org (Nicolas Pitre)
To: linux-arm-kernel@lists.infradead.org
Subject: PLEA: Please fix mach/gpio.h includes (was: Re: [RFC PATCH 2/2] GPIO: add gpiolib and irqchip for CSR SiRFprimaII GPIO controller)
Date: Tue, 26 Jul 2011 22:51:08 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.1107262222340.12766@xanadu.home> (raw)
In-Reply-To: <CAGsJ_4xFLH9-2aDQdtr6S5ugADJx-tFxO-G420WCcTDSV+azXA@mail.gmail.com>

On Wed, 27 Jul 2011, Barry Song wrote:

> 2011/7/27 Nicolas Pitre <nicolas.pitre@linaro.org>:
> > On Tue, 26 Jul 2011, Russell King - ARM Linux wrote:
> >
> >> I don't think there's any plans to break the:
> >>
> >> linux/gpio.h -> asm/gpio.h -> mach/gpio.h
> >>
> >> include path at the moment, as platforms do define ARCH_NR_GPIO,
> >> which has to be done before asm-generic/gpiolib.h is included.
> >
> > Well, this GPIO business is the biggest hurdle towards a single kernel
> > image that can support multiple SOCs at the moment, and the only one for
> > which I have no solution yet. ?Anything that could help removing
> > mach/gpio.h from asm/gpio.h would be welcome.
> 
> After reading all the following patches,
> 
> 1. use CONFIG_PHYS_OFFSET to prepare for removal of a bunch of
> <mach/memory.h> files
> 
> 2. move from ARM_DMA_ZONE_SIZE to mdesc->dma_zone_size
> 
> 3. convert boot_params to atag_offset
> 
> Have i lost anything for the work on 1 and 2? considering some
> platforms need CONSISTENT_DMA_SIZE more than the default 2MB in
> arch/arm/include/asm/memory.h, we can't remove all memory.h only by
> defining CONFIG_PHYS_OFFSET and moving ARM_DMA_ZONE_SIZE to
> mdesc->dma_zone_size. So CONSISTENT_DMA_SIZE should also be a left
> issue except gpio.h.

CONSISTENT_DMA_SIZE can be solved the same way as ARM_DMA_ZONE_SIZE, 
plus a few changes in dma-mapping.c to dynamically allocate the 
consistent_pte array.

But that's far from the end of it.  In a nutshell:

- We have to get rid of mach/vmalloc.h (trivial)

- We have to kill every SOC specific definition for CLOCK_TICK_RATE and 
  remove mach/timex.h.

- All mach/io.h need a similar refactoring.

- asm/irq.h must stop including mach/irqs.h, and everyone should 
  initialize mdesc->nr_irqs

- mach/entry-macro.S should be translated into something that hooks to 
  mdesc->handle_irq.

- mach/system.h content needs to be moved to out-of-line indirect calls.

- A multy-SOC kernel binary might not support CONFIG_DEBUG_LL out of the 
  box.

- And there are a few odd cases we probably might not find sufficient 
  motivation to fix them and simply exclude them from a single image 
  config.

But there is mach/gpio.h which is the real bummer at the moment.


Nicolas

  reply	other threads:[~2011-07-27  2:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-26  8:13 [RFC PATCH 0/2] add pinmux and gpio for CSR SiRFprimaII Barry Song
2011-07-26  8:13 ` [RFC PATCH 1/2] ARM: CSR: Add pinmux support for SiRFprimaII Barry Song
2011-07-26  8:13 ` [RFC PATCH 2/2] GPIO: add gpiolib and irqchip for CSR SiRFprimaII GPIO controller Barry Song
2011-07-26 10:09   ` Russell King - ARM Linux
2011-07-26 10:46     ` PLEA: Please fix mach/gpio.h includes (was: Re: [RFC PATCH 2/2] GPIO: add gpiolib and irqchip for CSR SiRFprimaII GPIO controller) Russell King - ARM Linux
2011-07-26 18:32       ` Colin Cross
2011-07-26 18:39         ` Russell King - ARM Linux
2011-07-26 19:10           ` Nicolas Pitre
2011-07-27  2:08             ` Barry Song
2011-07-27  2:51               ` Nicolas Pitre [this message]
2011-07-29 15:58             ` Linus Walleij
2011-08-09  7:22               ` Barry Song
2011-08-09 13:15                 ` Arnd Bergmann
2011-08-11  2:25                   ` Barry Song
2011-08-11  8:30                     ` Russell King - ARM Linux
2011-09-19  9:10                   ` Linus Walleij
2011-09-19 15:53                     ` Arnd Bergmann
2011-08-08  9:09     ` [RFC PATCH 2/2] GPIO: add gpiolib and irqchip for CSR SiRFprimaII GPIO controller Barry Song
2011-08-08  9:32     ` Linus Walleij

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=alpine.LFD.2.00.1107262222340.12766@xanadu.home \
    --to=nicolas.pitre@linaro.org \
    --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 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.