* READ THIS: the next mach-types update
From: Richard Cochran @ 2011-09-19 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2659680.vCa59q5ODA@wuerfel>
On Sun, Sep 18, 2011 at 05:44:25PM +0200, Arnd Bergmann wrote:
> Post them for review again. The rules for new boards are much stricter
> now, but we still allow them to get merged if they look good enough.
Okay. I think I can combine the three boards into one set of source
files.
Thanks,
Richard
^ permalink raw reply
* [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
From: Hiremath, Vaibhav @ 2011-09-19 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109161506.16505.laurent.pinchart@ideasonboard.com>
> -----Original Message-----
> From: Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com]
> Sent: Friday, September 16, 2011 6:36 PM
> To: Ravi, Deepthy
> Cc: linux-media at vger.kernel.org; tony at atomide.com; linux at arm.linux.org.uk;
> linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; mchehab at infradead.org; g.liakhovetski at gmx.de;
> Hiremath, Vaibhav
> Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
>
> Hi Deepthy,
>
> On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
> > On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
> > > On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
> > >> From: Vaibhav Hiremath <hvaibhav@ti.com>
> > >>
> > >> In order to support TVP5146 (for that matter any video decoder),
> > >> it is important to support G/S/ENUM_STD ioctl on /dev/videoX
> > >> device node.
> > >
> > > Why so ? Shouldn't it be queried on the subdev output pad directly ?
> >
> > Because standard v4l2 application for analog devices will call these std
> > ioctls on the streaming device node. So it's done on /dev/video to make
> the
> > existing apllication work.
>
> Existing applications can't work with the OMAP3 ISP (and similar complex
> embedded devices) without userspace support anyway, either in the form of
> a
> GStreamer element or a libv4l plugin. I still believe that analog video
> standard operations should be added to the subdev pad operations and
> exposed
> through subdev device nodes, exactly as done with formats.
>
[Hiremath, Vaibhav] Laurent,
I completely agree with your point that, existing application will not work without setting links properly. But I believe the assumption here is, media-controller should set the links (along with pad formants) and all existing application should work as is. Isn't it?
The way it is being done currently is, set the format at the pad level which is same as analog standard resolution and use existing application for streaming...
I am ok, if we add s/g/enum_std api support at sub-dev level but this should also be supported on streaming device node.
Thanks,
Vaibhav
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
From: Marc Zyngier @ 2011-09-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919150526.GV16381@n2100.arm.linux.org.uk>
On 19/09/11 16:05, Russell King - ARM Linux wrote:
> On Mon, Sep 19, 2011 at 04:00:34PM +0100, Marc Zyngier wrote:
>> Replying to myself after a quick investigation... Looks like the Qualcomm
>> implementation does exactly what is mentioned above:
>>
>> arch/arm/mach-msm/platsmp.c:
>> void __cpuinit platform_secondary_init(unsigned int cpu)
>> {
>> /* Configure edge-triggered PPIs */
>> writel(GIC_PPI_EDGE_MASK, MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4);
>> [...]
>>
>> The way I understand it, this "MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4"
>> is a banked register (otherwise we would not do it in platform_secondary_init(),
>> right?) So doing a set_type() from __setup_irq() would be just wrong. It really
>> needs to be done on a per-CPU basis.
>
> All the registers to do with the first 32 interrupts in the distributer
> are banked - the enable, configuration, and priority registers are all
> only accessible to the specific CPU which owns the PPIs and SGIs.
Indeed. The major difference is that the configuration registers for the
PPIs seem to be writable on MSM (11MP and A9 have them RO).
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARM: supply a DTB file to be appended
From: Nicolas Pitre @ 2011-09-19 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ+s_y=4VJuz5WetaU1tUFF-f6g38bpy6TSRjt9Q_VgLg@mail.gmail.com>
On Mon, 19 Sep 2011, Linus Walleij wrote:
> On Thu, Sep 8, 2011 at 12:14 PM, Linus Walleij
> <linus.walleij@stericsson.com> wrote:
>
> > This makes it easy to script the kernel build with
> > different device trees, and it also vastly simplifies
> > building uImages since "make uImage" will now pick
> > up the devcie tree and include it in the final image
> > as part of the build process.
>
> A clarification here on what it actually simplifies.
>
> make zImage
> cat my.dtb >> arch/arm/boot/zImage
> make uImage
>
> Does *not* work.
You must have been confused by what this patch fixes:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7016/1
Some confusion on my part made me create a similar patch and send it to
RMK, but the issue being fixed is the same.
So yes, the above now *does* work.
Nicolas
^ permalink raw reply
* [PATCH 06/19] ARM: mach-at91: remove arch specific special handling for ioremap
From: Nicolas Pitre @ 2011-09-19 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919141307.GS16381@n2100.arm.linux.org.uk>
On Mon, 19 Sep 2011, Russell King - ARM Linux wrote:
> On Mon, Sep 19, 2011 at 03:35:47PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 03:07 Fri 16 Sep , Nicolas Pitre wrote:
> > > From: Nicolas Pitre <nicolas.pitre@linaro.org>
> > >
> > > A generic version should replace this later.
> > >
> > > Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> > Untill the replace will availlable
> >
> > do not remove it
>
> This patch series is all about adding that replacement.
>
> But yes, as a general point of principle, the replacement should be
> in place before the old stuff is pulled out. I don't see any reason
> why that can't be the case, because __arm_ioremap() can be rigged up
> to use the static mappings first, and then the individual platform
> interception of ioremap() can be removed afterwards.
Some of them were using IOREMAP_END assuming it was below the static
mappings, so it was easier to simply remove those first before the
IOREMAP_END was redefined. And then it looks strange to remove some of
them before, then some others after. Hence I opted for removing them
all first. And as I said, this doesn't create any functional
regression to have this optimization removed temporarily.
Nicolas
^ permalink raw reply
* [PATCH 06/19] ARM: mach-at91: remove arch specific special handling for ioremap
From: Nicolas Pitre @ 2011-09-19 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919130703.GG16141@game.jcrosoft.org>
On Mon, 19 Sep 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 03:07 Fri 16 Sep , Nicolas Pitre wrote:
> > From: Nicolas Pitre <nicolas.pitre@linaro.org>
> >
> > A generic version should replace this later.
> >
> > Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> Untill the replace will availlable
>
> do not remove it
The replacement is introduced later in the same patch series. Removing
this first doesn't cause any functional regression.
Nicolas
^ permalink raw reply
* [PATCH v2 1/2] OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration
From: Cousson, Benoit @ 2011-09-19 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E773F91.3030704@ti.com>
On 9/19/2011 3:11 PM, Cousson, Benoit wrote:
> On 9/17/2011 6:05 PM, Grant Likely wrote:
>> On Fri, Sep 16, 2011 at 04:43:18PM +0200, Benoit Cousson wrote:
[...]
>>> - pr_debug("omap_device: %s: building with %d hwmods\n", pdev_name,
>>> - oh_cnt);
>>> + /* Set the dev_name early to allow dev_xxx in omap_device_alloc */
>>> + if (pdev->id != -1)
>>> + dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
>>> + else
>>> + dev_set_name(&pdev->dev, "%s", pdev->name);
>>
>> This is duplicated from the core platform_device code. What is the
>> reasoning for doing it again here?
>
> Well, it is written in the comment... But this is maybe not that obvious
> :-)
> That part is only needed for the legacy path that will create a
> omap_device before having created the device, and thus at that time the
> dev_xxx will not give the device name. This is not a big deal, but that
> was painful for the debug.
>
> That being said, by writing that, I'm now realizing that this is due to
> the way the legacy code was working, because I didn't try to change the
> sequence.
> But maybe, I can easily avoid that by changing the original sequence.
> In fact If I create the omap_device after the omap_device_register, the
> platform_device will already have the correct name...
>
> That should work, I'll give it a try.
Mmm, that's funny because it still does require to copy some part of the
platform_device_add to make that work.
This is now the resource name that are missing in that case :-(
So I will have to add at least that part to make that work:
if (r->name == NULL)
r->name = dev_name(&pdev->dev);
And the real function is doing s little bit more:
p = r->parent;
if (!p) {
if (resource_type(r) == IORESOURCE_MEM)
p = &iomem_resource;
else if (resource_type(r) == IORESOURCE_IO)
p = &ioport_resource;
}
if (p && insert_resource(p, r)) {
printk(KERN_ERR
"%s: failed to claim resource %d\n",
dev_name(&pdev->dev), i);
ret = -EBUSY;
goto failed;
}
It seems that in both cases, some part of the platform core code has to
be copied to make that work properly.
Except if someone has a better idea, I'd rather stick to the original
dev_set_name hack. Considering that this code should be removed at some
point anyway.
Any thoughts?
Regards,
Benoit
^ permalink raw reply
* [PATCH 16/19] ARM: move iotable mappings within the vmalloc region
From: Nicolas Pitre @ 2011-09-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919112050.GN16381@n2100.arm.linux.org.uk>
On Mon, 19 Sep 2011, Russell King - ARM Linux wrote:
> On Mon, Sep 19, 2011 at 12:18:09AM -0400, Nicolas Pitre wrote:
> > OK, here we go with version 2:
>
> Looks fine, thanks.
This is an ACK?
Nicolas
^ permalink raw reply
* [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
From: Russell King - ARM Linux @ 2011-09-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E775912.3060502@arm.com>
On Mon, Sep 19, 2011 at 04:00:34PM +0100, Marc Zyngier wrote:
> Replying to myself after a quick investigation... Looks like the Qualcomm
> implementation does exactly what is mentioned above:
>
> arch/arm/mach-msm/platsmp.c:
> void __cpuinit platform_secondary_init(unsigned int cpu)
> {
> /* Configure edge-triggered PPIs */
> writel(GIC_PPI_EDGE_MASK, MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4);
> [...]
>
> The way I understand it, this "MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4"
> is a banked register (otherwise we would not do it in platform_secondary_init(),
> right?) So doing a set_type() from __setup_irq() would be just wrong. It really
> needs to be done on a per-CPU basis.
All the registers to do with the first 32 interrupts in the distributer
are banked - the enable, configuration, and priority registers are all
only accessible to the specific CPU which owns the PPIs and SGIs.
^ permalink raw reply
* [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
From: Marc Zyngier @ 2011-09-19 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E770B3E.9040401@arm.com>
On 19/09/11 10:28, Marc Zyngier wrote:
> On 19/09/11 00:20, Abhijeet Dharmapurikar wrote:
>> > + * @devname: An ascii name for the claiming device
>> > + * @dev_id: A percpu cookie passed back to the handler function
>> > + *
>> > + * This call allocates interrupt resources, but doesn't
>> > + * automatically enable the interrupt. It has to be done on each
>> > + * CPU using enable_percpu_irq().
>> > + *
>> > + * Dev_id must be globally unique. It is a per-cpu variable, and
>> > + * the handler gets called with the interrupted CPU's instance of
>> > + * that variable.
>> > + */
>> > +int request_percpu_irq(unsigned int irq, irq_handler_t handler,
>> > + const char *devname, void __percpu *dev_id)
>>
>> Can we add irqflags argument. I think it will be useful to pass flags,
>> at least the IRQF_TRIGGER_MASK since it ends up calling __setup_irq().
>> The chip could use a set_type callback for ppi's too.
>
> We're entering dangerous territory here. While this would work with the
> GIC (the interrupt type is at the distributor level), you could easily
> imagine an interrupt controller with the PPI configuration at the CPU
> interface level... In that case, calling set_type from __setup_irq()
> would end up doing the wrong thing, and I'd hate the API to give the
> idea it can do things it may not do in the end...
>
> Furthermore, do we actually have a GIC implementation where PPI
> configuration isn't read-only? I only know about the ARM implementation,
> and the Qualcomm may well be different (the spec says it's
> implementation defined).
Replying to myself after a quick investigation... Looks like the Qualcomm
implementation does exactly what is mentioned above:
arch/arm/mach-msm/platsmp.c:
void __cpuinit platform_secondary_init(unsigned int cpu)
{
/* Configure edge-triggered PPIs */
writel(GIC_PPI_EDGE_MASK, MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4);
[...]
The way I understand it, this "MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4"
is a banked register (otherwise we would not do it in platform_secondary_init(),
right?) So doing a set_type() from __setup_irq() would be just wrong. It really
needs to be done on a per-CPU basis.
Do you agree?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* READ THIS: the next mach-types update
From: Pedanekar, Hemant @ 2011-09-19 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917143427.GA16591@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote on Saturday, September 17, 2011 8:04 PM:
> On Sat, Sep 17, 2011 at 07:58:20PM +0530, Pedanekar, Hemant wrote:
>> But since I had submitted v1 (see [1]) and am working on v2 post review,
>> can you please suggest how to go about it as I will need the above for
>> adding support for TI8148 EVM?
>
> The answer you require is in this statement:
>
> # This is a cut-down version of the file; it contains only
> machines that
> # are merged into mainline or have been edited in the machine database
> # within the last 12 months. References to machine_is_NAME()
> do not count!
>
> which highlights the policy. The key thing there is "edited".
Thanks, got it.
Hemant
^ permalink raw reply
* [PATCH] ARM: BUG() dies silently
From: Russell King - ARM Linux @ 2011-09-19 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAB-zwWi1K8y8fHzy0hgcFPgSfhMrZNfoKQ9xuU00Y1sLg6ZBmw@mail.gmail.com>
On Mon, Sep 19, 2011 at 09:26:49AM -0500, Ramirez Luna, Omar wrote:
> Hi
>
> On Sat, Sep 17, 2011 at 1:07 AM, Rabin Vincent <rabin@rab.in> wrote:
> > If the "Use generic BUG() handler" patch is only scheduled for the next
> > merge window and not for 3.1, can this patch be merged instead for 3.1
> > and -stable? ?This problem is easily seen with GCC 4.6.
>
> I can send it for both and let the maintainers decide.
>
> Russell, do you give your ack?
I think it's too large a change for -stable and 3.1 - let's get it into
3.2 first, and make sure no one sees any regressions there. Then we can
think about submitting it to stable once its proven itself.
^ permalink raw reply
* [PATCH] ARM: kdump: copy kernel relocation code at the kexec prepare stage
From: Russell King - ARM Linux @ 2011-09-19 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53612FE6B944314AAADB181E45A45B641387938501@sc-vexch3.marvell.com>
On Mon, Sep 19, 2011 at 07:11:59AM -0700, Lei Wen wrote:
> Thanks for this reminding!
> Then how about add flush_icache_range at the end of machine_kexec_prepare?
> Could it be acceptable?
I think it should be done.
> Also with this change, do we still need flush icache at the end stage of
> machine_kexec?
You need to use flush_icache_range() whenever you write _instructions_
to an area of memory which you intend to execute. If you're not writing
instructions, you shouldn't use flush_icache_range().
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Cousson, Benoit @ 2011-09-19 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E774847.3020104@gmail.com>
On 9/19/2011 3:48 PM, Rob Herring wrote:
> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>> On 09/15/2011 11:43 AM, Rob Herring wrote:
>>>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>
>> [...]
>>
>>>>>>> I have another concern on a similar topic.
>>>>>>>
>>>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have
>>>>>>> an offset of 32. Only the internal PPI are between 0 and
>>>>>>> 31.
>>>>>>>
>>>>>>> For the moment we add 32 to every SoC interrupts in the
>>>>>>> irq.h define,
>>>>>>
>>>>>> Those defines will not be used in the DT case. So the
>>>>>> question is whether to add 32 or not in the DT. Since we have
>>>>>> just a single node and a linear mapping of PPIs and SPIs, the
>>>>>> only choice is to have SPIs start at 32. And from the h/w
>>>>>> definition, SPIs always start at 32, so it's in agreement.
>>>>>
>>>>> This is a agreement inside the MPUSS, but not outside. Both
>>>>> Tegra and OMAP4 must add an offset to the HW irq number to
>>>>> deal with that today.
>>>>>
>>>>>>> but I'm assuming that this offset calculation should be
>>>>>>> done thanks to a dedicated irq domain for the SPI. The real
>>>>>>> HW physical number start at 0, and thus this is that value
>>>>>>> that should be in the irq binding of the device.
>>>>>>>
>>>>>>> So ideally we should have a irq domain for the PPI starting
>>>>>>> at 0 and another one for the SPI starting at 32. Or 32 and
>>>>>>> 64 for the exynos4 case, but it looks like the PPI/SPI
>>>>>>> offset is always 32.
>>>>>>>
>>>>>>
>>>>>> That offset of SPIs is always there. If you have a GIC as a
>>>>>> secondary controller, It will have 32 reserved interrupts and
>>>>>> the register layout is exactly the same as a cpu's GIC.
>>>>>
>>>>> Yep, but that's the GIC view and not the SoC one. My concern is
>>>>> to have to tweak the HW number provided by the HW spec in order
>>>>> to add that offset. If you look at SoC level, the MPUSS is just
>>>>> an IP that can be potentially replaced by other one that will
>>>>> not have a GIC. In that case you will not change the IRQ
>>>>> mapping at SoC level. For example if you replace the
>>>>> Dual-cortexA9 by a single CortexA8, then all the interrupts
>>>>> will have to be shifted by 32 just because the MPU subsystem is
>>>>> different.
>>>>>
>>>>
>>>> Is that a realistic case? That would be a new chip and new device
>>>> tree. You could argue that the whole peripheral subsystem DT
>>>> could be reused and the numbering needs to be the same. However,
>>>> there's one thing that would prevent that. The number of
>>>> interrupt cells is defined by the controller binding. So you have
>>>> to change the peripheral nodes anyway.
>>>>
>>>> It's good that OMAP is trying to standardize the peripheral
>>>> layout, but in my experience that's not something you can rely
>>>> on.
>>>>
>>>> At some point the interrupt numbering is going to differ from the
>>>> h/w documentation. If it's not in the DT, then it will be in
>>>> linux. Right now its just offset of 32, but if irqdescs get
>>>> assigned on demand as PPC is doing, then there will be no
>>>> relationship to the documentation.
>>>>
>>>>> Since that offset is dependent of the GIC internals and is not
>>>>> exposed outside the MPUSS, it should not be visible by the SoC
>>>>> IPs. And the HW spec is exposing exactly that.
>>>>>
>>>>>> Since the idea of splitting PPIs for each core out to a
>>>>>> flattened linux irq map has been abandoned, I see no reason
>>>>>> to have more than 1 domain with a simple linear translation.
>>>>>> Ultimately, domains will do dynamic irqdesc allocation and
>>>>>> the translation within the gic will be completely dynamic.
>>>>>
>>>>> I think the only reason to do that is to separate internal MPU
>>>>> interrupts with the external ones that should not have a clue
>>>>> about the GIC.
>>>>
>>>> I see 2 options (besides leaving it as is):
>>>>
>>>> - Revert back to my previous binding where PPIs are a sub-node
>>>> and a different interrupt parent.
>>>>
>>>> - Use the current binding, but allow SPIs to start at 0. We can
>>>> still distinguish PPIs and SPIs by the cpu mask cell. A cpu mask
>>>> of 0 is a SPI. If there was ever a reason to have a cpu mask for
>>>> an SPI, you would not be able to with this scheme.
>>>>
>>>> Either way you will still have the above issue with the cell size
>>>> changing.
>>>>
>>>
>>> I was headed down the path of implementing the 2nd option above,
>>> but had a dilemma. What would be the numbering base for PPIs in
>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>> stay at 16?
>>
>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>> processor has its own private timers that can generate interrupts,
>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>> its own watchdog timers that can generate interrupts, using ID30.
>>
>> So in that case, it can makes sense to use the ID. But it is
>> interesting to note that the PPI is identified with a 0 based index
>> number.
>>
> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
> for the timer interrupt. The first would match 0 based SPI convention.
I didn't even noticed that mess :-(
Maybe that PPI number is not that relevant in that case. It looks like
there are using the last 4 lines (28-31).
> The last 2 would both match the documentation. We could never use 2 as
> this will for sure be different and the GIC code will have no way to
> know how to do the translation to ID. The only sane choice is using the
> ID as you say.
In that case, this is indeed the case.
> But you can't have it both ways. It does not make sense to use the ID
> for some interrupts and a different scheme for others.
Maybe not, the idea is to use the scheme that is the most relevant for a
particular subsystem. Inside the CortexA9 MP the documentation clearly
gives the mapping based on ID#. But for SPIs, it is just written start
as ID32.
>>> Numbering PPIs at 0 will just cause confusion as will numbering
>>> differently from SPIs. There is absolutely no mention of SPI0 or
>>> SPIx numbering in the GIC spec.
>>
>> Probably because it is the generic GIC spec that focus on internals
>> stuff only, it not an integration spec that will show how the SPIs
>> are connected to the outside world. But it is clear that the SPIs are
>> identified as 0-XXX lines outside the Cortex MP core.
>>
>
> What if the A9 or some other implementation used some SPIs internally?
> Then the external connection would be shifted differently.
Potentially yes.
> The interrupt
> binding for a peripheral is defined by it's interrupt parent (the
> interrupt controller). The number of cells and what the values mean are
> defined by the interrupt controller binding. This is independent of any
> SOC. The binding must be defined from the perspective of the interrupt
> controller.
In fact, it is dependent on both the interrupt controller binding, and
the way the interrupt controller is connected to the SoC. It should be
defined as well based on the interface exposed to the outside of the
subsystem.
>> In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are
>> triggered by events generated on associated interrupt input lines.
>> The Interrupt Controller can support up to 224 interrupt input lines.
>> The interrupt input lines can be configured to be edge sensitive
>> (posedge) or level sensitive (high level). SPIs start at ID32.
>>
>>> All interrupt number references refer to the absolute interrupt ID,
>>> not a relative number based on the type. The fact that the
>>> Cortex-A9 implementation has interrupt lines numbered equal to the
>>> GIC SPI interrupts is an implementation detail of the A9.
>>
>>> Other cores could have different arrangement including bringing out
>>> PPI interrupts or reserving some SPIs.
>>
>> Absolutely, that's why we should not use that internal GIC convention
>> to capture external IRQ mapping. It you separate the PPI and the SPI
>> controller, you can allow any kind of internal mapping.
>>
>
> The GIC convention is the only part that is consistent and not dependent
> on the implementation.
Again, for the point of view of the GIC, but not necessarily for the SoC
point of view.
>>> As there are many users of the GIC, it makes more sense to align
>>> with the GIC documentation rather than the documentation of 1 SOC.
>>> BTW, I have the exact same issue in our documentation.
>>
>> It is not about one SoC, this is probably done like that for every
>> other SoCs. I do not have the TRM for the other SoCs, but here is how
>> it is done in various irqs.h file today:
>>
>> - arch/arm/mach-exynos4/include/mach
>>
>> /* PPI: Private Peripheral Interrupt */ #define IRQ_PPI(x)
>> S5P_IRQ(x+16)
>>
>> /* SPI: Shared Peripheral Interrupt */ #define IRQ_SPI(x)
>> S5P_IRQ(x+32)
>>
>> #define IRQ_EINT0 IRQ_SPI(16) #define IRQ_EINT1 IRQ_SPI(17) #define
>> IRQ_EINT2 IRQ_SPI(18) #define IRQ_EINT3 IRQ_SPI(19)
>>
>>
>> - arch/arm/mach-tegra/include/mach
>>
>> /* Primary Interrupt Controller */ #define INT_PRI_BASE
>> (INT_GIC_BASE + 32) #define INT_TMR1 (INT_PRI_BASE + 0) #define
>> INT_TMR2 (INT_PRI_BASE + 1) #define INT_RTC (INT_PRI_BASE + 2)
>> #define INT_I2S2 (INT_PRI_BASE + 3)
>>
>>
>> - arch/arm/mach-ux500/include/mach
>>
>> /* Shared Peripheral Interrupt (SHPI) */ #define IRQ_SHPI_START 32
>>
>> #define IRQ_MTU0 (IRQ_SHPI_START + 4)
>>
>>
>> - arch/arm/plat-omap/include/plat
>>
>> #define OMAP44XX_IRQ_GIC_START 32
>>
>> #define OMAP44XX_IRQ_PL310 (0 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_CTI0 (1 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_CTI1 (2 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_ELM (4 + OMAP44XX_IRQ_GIC_START)
>>
>>
>> Every CortexA9 based SoC have to add the 32 offset to the SoC level
>> interrupt number line. The ID numbering scheme is relevant only
>> inside the GIC, but at SoC level only the IRQ lines that entered the
>> MP core are relevant. That ID is a pure internal GIC encoding.
>>
> Exactly. For DT, the irq numbering is supposed to be local to the
> interrupt controller. So from a GIC perspective, what numbering makes sense?
The number relevant to the GIC will depend of the context.
Inside the Cortex MP, the ID# is relevant, outside, this is not the case
anymore, because only the SPIs will be connected.
> It's also relevant to the software running on the system.
For the SW/driver case, it will be abstracted by the DT core code, so
the real HW value should never matter.
Bottom-line: I understand your GIC centric point of view. At GIC level
you have to handle a bunch of IDs.
And at Soc level we just want to handle a subset of them with a slightly
different numbering scheme. So you're right, the GIC node is maybe not
the proper place to handle that if you want the GIC code to be generic.
What is maybe just missing is a intermediate node in between to
translate the SoC view to the GIC view.
This is probably the interrupt nexus Grant was referring to, the only
issue today is the lack of easy support for basic translation.
>> If you refer to the GIC-400 spec [2] (Please note that I do not know
>> what that GIC is exactly...) p 25: "SPIs are triggered by events
>> generated on associated interrupt input lines. The GIC-400 can
>> support up to 480 SPIs corresponding to the external IRQS[479:0]
>> signal. The number of SPIs available depends on the implemented
>> configuration of the GIC-400. The permitted values are 0-480, in
>> steps of 32. SPIs start at ID32."
>>
>> In that case the external IRQS numbering scheme is clear: [479:0],
>> which is exactly what will be seen outside of the MP core.
>>
>> Having two interrupt controllers, one for SGIs + PPIs starting at 0
>> (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to
>> me a much better approach. Moreover, it will avoid exposing a cpumask
>> for SPIs.
>>
>
> Having implemented both ways already, I'm fine either way, but the
> current consensus seems to be to use the cpumask.
I missed that thread, what was the point? To have a more generic
interface that can handle both cases?
Regards,
Benoit
^ permalink raw reply
* [PATCH] ARM: BUG() dies silently
From: Ramirez Luna, Omar @ 2011-09-19 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH+eYFBSiL44CMOpgED+TAOTUH_dQMaKKu=hC3ynG0Y2nQ8ekw@mail.gmail.com>
Hi
On Sat, Sep 17, 2011 at 1:07 AM, Rabin Vincent <rabin@rab.in> wrote:
> If the "Use generic BUG() handler" patch is only scheduled for the next
> merge window and not for 3.1, can this patch be merged instead for 3.1
> and -stable? ?This problem is easily seen with GCC 4.6.
I can send it for both and let the maintainers decide.
Russell, do you give your ack?
Regards,
Omar
^ permalink raw reply
* [PATCH v2 2/6] arm/imx6q: add core definitions and low-level debug uart
From: Shawn Guo @ 2011-09-19 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919095544.GL31404@pengutronix.de>
On Mon, Sep 19, 2011 at 11:55:44AM +0200, Sascha Hauer wrote:
> On Mon, Sep 19, 2011 at 05:45:59PM +0800, Eric Miao wrote:
> > On Mon, Sep 19, 2011 at 5:35 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > On Thu, Sep 15, 2011 at 10:45:22PM +0800, Shawn Guo wrote:
> > >> It adds the core definitions and low-level debug uart support
> > >> for imx6q.
> > >>
> > >>
> > >> ?#define UART_VADDR ? IMX_IO_ADDRESS(UART_PADDR)
> > >> diff --git a/arch/arm/plat-mxc/include/mach/entry-macro.S b/arch/arm/plat-mxc/include/mach/entry-macro.S
> > >> index 066d464..341f800 100644
> > >> --- a/arch/arm/plat-mxc/include/mach/entry-macro.S
> > >> +++ b/arch/arm/plat-mxc/include/mach/entry-macro.S
> > >> @@ -1,6 +1,6 @@
> > >> ?/*
> > >> ? * ?Copyright (C) 2007 Lennert Buytenhek <buytenh@wantstofly.org>
> > >> - * ?Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
> > >> + * ?Copyright 2004-2011 Freescale Semiconductor, Inc. All Rights Reserved.
> > >> ? */
> > >>
> > >> ?/*
> > >> @@ -11,6 +11,17 @@
> > >>
> > >> ?#include <mach/hardware.h>
> > >>
> > >> +#ifdef CONFIG_ARM_GIC
> > >> +#include <asm/hardware/entry-macro-gic.S>
> > >> +
> > >> + ? ? .macro ?disable_fiq
> > >> + ? ? .endm
> > >> +
> > >> + ? ? .macro ?arch_ret_to_user, tmp1, tmp2
> > >> + ? ? .endm
> > >> +
> > >> +#else
> > >
> > > That's the third interrupt entry code handled here with ifdefs. I
> > > remember there was some infrastructure to have multiple irq
> > > controllers. I can't find any pointers, but I think Eric (added him
> > > to Cc) told me about it.
> > > As this is also the last roadblock to compile i.MX3 and i.MX5 into a
> > > single kernel this might be the right moment to work on this.
> >
It seems to be a work that basically need to touch very imx platforms.
I would like to work on it, but I do not think it belongs to this
series.
Regards,
Shawn
> > It's CONFIG_MULTIPLE_IRQ_HANDLER. And check arch/arm/mach-pxa/irq.c
> > for example. Basically to use a C function to handle the interrupts, and
> > have each machine to specify the correct handler.
> >
> > E.g. in pxa - there are pxa25x_handle_irq, pxa3xx_handle_irq ...
>
> Nice, it's already merged. I should have used grep instead of google.
> For reference, it's CONFIG_MULTI_IRQ_HANDLER.
>
^ permalink raw reply
* [PATCH 06/19] ARM: mach-at91: remove arch specific special handling for ioremap
From: Russell King - ARM Linux @ 2011-09-19 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919130703.GG16141@game.jcrosoft.org>
On Mon, Sep 19, 2011 at 03:35:47PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 03:07 Fri 16 Sep , Nicolas Pitre wrote:
> > From: Nicolas Pitre <nicolas.pitre@linaro.org>
> >
> > A generic version should replace this later.
> >
> > Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> Untill the replace will availlable
>
> do not remove it
This patch series is all about adding that replacement.
But yes, as a general point of principle, the replacement should be
in place before the old stuff is pulled out. I don't see any reason
why that can't be the case, because __arm_ioremap() can be rigged up
to use the static mappings first, and then the individual platform
interception of ioremap() can be removed afterwards.
^ permalink raw reply
* [PATCH] ARM: kdump: copy kernel relocation code at the kexec prepare stage
From: Lei Wen @ 2011-09-19 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919122059.GQ16381@n2100.arm.linux.org.uk>
Hi Russell,
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Monday, September 19, 2011 8:21 PM
> To: Lei Wen
> Cc: Chao Xie; Yu Tang; linux-arm-kernel at lists.infradead.org;
> kexec at lists.infradead.org
> Subject: Re: [PATCH] ARM: kdump: copy kernel relocation code at the kexec prepare
> stage
>
> On Thu, Sep 15, 2011 at 10:32:09PM -0700, Lei Wen wrote:
> > diff --git a/arch/arm/kernel/machine_kexec.c
> b/arch/arm/kernel/machine_kexec.c
> > index e59bbd4..f60fc90 100644
> > --- a/arch/arm/kernel/machine_kexec.c
> > +++ b/arch/arm/kernel/machine_kexec.c
> > @@ -32,6 +32,21 @@ static atomic_t waiting_for_crash_ipi;
> >
> > int machine_kexec_prepare(struct kimage *image)
> > {
> > + unsigned long page_list;
> > + void *reboot_code_buffer;
> > + page_list = image->head & PAGE_MASK;
> > +
> > + reboot_code_buffer = page_address(image->control_code_page);
> > +
> > + /* Prepare parameters for reboot_code_buffer*/
> > + kexec_start_address = image->start;
> > + kexec_indirection_page = page_list;
> > + kexec_mach_type = machine_arch_type;
> > + kexec_boot_atags = image->start - KEXEC_ARM_ZIMAGE_OFFSET +
> KEXEC_ARM_ATAGS_OFFSET;
> > +
> > + /* copy our kernel relocation code to the control code page */
> > + memcpy(reboot_code_buffer,
> > + relocate_new_kernel, relocate_new_kernel_size);
> > return 0;
> > }
> >
> > @@ -82,29 +97,14 @@ void (*kexec_reinit)(void);
> >
> > void machine_kexec(struct kimage *image)
> > {
> > - unsigned long page_list;
> > unsigned long reboot_code_buffer_phys;
> > void *reboot_code_buffer;
> >
> > -
> > - page_list = image->head & PAGE_MASK;
> > -
> > /* we need both effective and real address here */
> > reboot_code_buffer_phys =
> > page_to_pfn(image->control_code_page) << PAGE_SHIFT;
> > reboot_code_buffer = page_address(image->control_code_page);
> >
> > - /* Prepare parameters for reboot_code_buffer*/
> > - kexec_start_address = image->start;
> > - kexec_indirection_page = page_list;
> > - kexec_mach_type = machine_arch_type;
> > - kexec_boot_atags = image->start - KEXEC_ARM_ZIMAGE_OFFSET +
> KEXEC_ARM_ATAGS_OFFSET;
> > -
> > - /* copy our kernel relocation code to the control code page */
> > - memcpy(reboot_code_buffer,
> > - relocate_new_kernel, relocate_new_kernel_size);
> > -
> > -
> > flush_icache_range((unsigned long) reboot_code_buffer,
> > (unsigned long) reboot_code_buffer + KEXEC_CONTROL_PAGE_SIZE);
>
> You should keep this flush with the memcpy - the two are intimately
> related - the flush is to ensure I/D cache coherency for the code
> which was copied into the page. Splitting them into two different
> functions is asking for future bugs.
Thanks for this reminding!
Then how about add flush_icache_range at the end of machine_kexec_prepare? Could it be acceptable?
Also with this change, do we still need flush icache at the end stage of machine_kexec?
Thanks,
Lei
^ permalink raw reply
* [PATCH 11/11] at91/gpio: fix display of number of irq setuped
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-19 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316436695-19194-1-git-send-email-plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Reviewed-by: Ryan Mallon <rmallon@gmail.com>
---
arch/arm/mach-at91/gpio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
index e709406..743f668 100644
--- a/arch/arm/mach-at91/gpio.c
+++ b/arch/arm/mach-at91/gpio.c
@@ -528,7 +528,7 @@ void __init at91_gpio_irq_setup(void)
irq_set_chip_data(id, this);
irq_set_chained_handler(id, gpio_irq_handler);
}
- pr_info("AT91: %d gpio irqs in %d banks\n", irq, gpio_banks);
+ pr_info("AT91: %d gpio irqs in %d banks\n", irq - gpio_to_irq(0), gpio_banks);
}
/* gpiolib support */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 10/11] at91/gpio: drop PIN_BASE
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-19 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316436695-19194-1-git-send-email-plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Reviewed-by: Ryan Mallon <rmallon@gmail.com>
---
arch/arm/mach-at91/gpio.c | 54 ++--
arch/arm/mach-at91/include/mach/gpio.h | 454 ++++++++++++++++----------------
2 files changed, 254 insertions(+), 254 deletions(-)
rewrite arch/arm/mach-at91/include/mach/gpio.h (78%)
diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
index 04beff1..e709406 100644
--- a/arch/arm/mach-at91/gpio.c
+++ b/arch/arm/mach-at91/gpio.c
@@ -60,18 +60,17 @@ static int at91_gpiolib_direction_input(struct gpio_chip *chip,
}
static struct at91_gpio_chip gpio_chip[] = {
- AT91_GPIO_CHIP("A", 0x00 + PIN_BASE, 32),
- AT91_GPIO_CHIP("B", 0x20 + PIN_BASE, 32),
- AT91_GPIO_CHIP("C", 0x40 + PIN_BASE, 32),
- AT91_GPIO_CHIP("D", 0x60 + PIN_BASE, 32),
- AT91_GPIO_CHIP("E", 0x80 + PIN_BASE, 32),
+ AT91_GPIO_CHIP("A", 0x00, 32),
+ AT91_GPIO_CHIP("B", 0x20, 32),
+ AT91_GPIO_CHIP("C", 0x40, 32),
+ AT91_GPIO_CHIP("D", 0x60, 32),
+ AT91_GPIO_CHIP("E", 0x80, 32),
};
static int gpio_banks;
static inline void __iomem *pin_to_controller(unsigned pin)
{
- pin -= PIN_BASE;
pin /= 32;
if (likely(pin < gpio_banks))
return gpio_chip[pin].regbase;
@@ -81,7 +80,6 @@ static inline void __iomem *pin_to_controller(unsigned pin)
static inline unsigned pin_to_mask(unsigned pin)
{
- pin -= PIN_BASE;
return 1 << (pin % 32);
}
@@ -276,8 +274,9 @@ static u32 backups[MAX_GPIO_BANKS];
static int gpio_irq_set_wake(struct irq_data *d, unsigned state)
{
- unsigned mask = pin_to_mask(d->irq);
- unsigned bank = (d->irq - PIN_BASE) / 32;
+ unsigned pin = irq_to_gpio(d->irq);
+ unsigned mask = pin_to_mask(pin);
+ unsigned bank = pin / 32;
if (unlikely(bank >= MAX_GPIO_BANKS))
return -EINVAL;
@@ -346,8 +345,9 @@ void at91_gpio_resume(void)
static void gpio_irq_mask(struct irq_data *d)
{
- void __iomem *pio = pin_to_controller(d->irq);
- unsigned mask = pin_to_mask(d->irq);
+ unsigned pin = irq_to_gpio(d->irq);
+ void __iomem *pio = pin_to_controller(pin);
+ unsigned mask = pin_to_mask(pin);
if (pio)
__raw_writel(mask, pio + PIO_IDR);
@@ -355,8 +355,9 @@ static void gpio_irq_mask(struct irq_data *d)
static void gpio_irq_unmask(struct irq_data *d)
{
- void __iomem *pio = pin_to_controller(d->irq);
- unsigned mask = pin_to_mask(d->irq);
+ unsigned pin = irq_to_gpio(d->irq);
+ void __iomem *pio = pin_to_controller(pin);
+ unsigned mask = pin_to_mask(pin);
if (pio)
__raw_writel(mask, pio + PIO_IER);
@@ -384,7 +385,7 @@ static struct irq_chip gpio_irqchip = {
static void gpio_irq_handler(unsigned irq, struct irq_desc *desc)
{
- unsigned pin;
+ unsigned irq_pin;
struct irq_data *idata = irq_desc_get_irq_data(desc);
struct irq_chip *chip = irq_data_get_irq_chip(idata);
struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(idata);
@@ -407,12 +408,12 @@ static void gpio_irq_handler(unsigned irq, struct irq_desc *desc)
continue;
}
- pin = at91_gpio->chip.base;
+ irq_pin = gpio_to_irq(at91_gpio->chip.base);
while (isr) {
if (isr & 1)
- generic_handle_irq(pin);
- pin++;
+ generic_handle_irq(irq_pin);
+ irq_pin++;
isr >>= 1;
}
}
@@ -440,7 +441,7 @@ static int at91_gpio_show(struct seq_file *s, void *unused)
seq_printf(s, "%i:\t", j);
for (bank = 0; bank < gpio_banks; bank++) {
- unsigned pin = PIN_BASE + (32 * bank) + j;
+ unsigned pin = (32 * bank) + j;
void __iomem *pio = pin_to_controller(pin);
unsigned mask = pin_to_mask(pin);
@@ -493,10 +494,10 @@ static struct lock_class_key gpio_lock_class;
*/
void __init at91_gpio_irq_setup(void)
{
- unsigned pioc, pin;
+ unsigned pioc, irq = gpio_to_irq(0);
struct at91_gpio_chip *this, *prev;
- for (pioc = 0, pin = PIN_BASE, this = gpio_chip, prev = NULL;
+ for (pioc = 0, this = gpio_chip, prev = NULL;
pioc++ < gpio_banks;
prev = this, this++) {
unsigned id = this->bank->id;
@@ -504,16 +505,17 @@ void __init at91_gpio_irq_setup(void)
__raw_writel(~0, this->regbase + PIO_IDR);
- for (i = 0, pin = this->chip.base; i < 32; i++, pin++) {
- irq_set_lockdep_class(pin, &gpio_lock_class);
+ for (i = 0, irq = gpio_to_irq(this->chip.base); i < 32;
+ i++, irq++) {
+ irq_set_lockdep_class(irq, &gpio_lock_class);
/*
* Can use the "simple" and not "edge" handler since it's
* shorter, and the AIC handles interrupts sanely.
*/
- irq_set_chip_and_handler(pin, &gpio_irqchip,
+ irq_set_chip_and_handler(irq, &gpio_irqchip,
handle_simple_irq);
- set_irq_flags(pin, IRQF_VALID);
+ set_irq_flags(irq, IRQF_VALID);
}
/* The toplevel handler handles one bank of GPIOs, except
@@ -526,7 +528,7 @@ void __init at91_gpio_irq_setup(void)
irq_set_chip_data(id, this);
irq_set_chained_handler(id, gpio_irq_handler);
}
- pr_info("AT91: %d gpio irqs in %d banks\n", pin - PIN_BASE, gpio_banks);
+ pr_info("AT91: %d gpio irqs in %d banks\n", irq, gpio_banks);
}
/* gpiolib support */
@@ -615,7 +617,7 @@ void __init at91_gpio_init(struct at91_gpio_bank *data, int nr_banks)
at91_gpio = &gpio_chip[i];
at91_gpio->bank = &data[i];
- at91_gpio->chip.base = PIN_BASE + i * 32;
+ at91_gpio->chip.base = i * 32;
at91_gpio->regbase = ioremap(at91_gpio->bank->regbase, 512);
if (!at91_gpio->regbase) {
diff --git a/arch/arm/mach-at91/include/mach/gpio.h b/arch/arm/mach-at91/include/mach/gpio.h
dissimilarity index 78%
index 056dc66..5213879 100644
--- a/arch/arm/mach-at91/include/mach/gpio.h
+++ b/arch/arm/mach-at91/include/mach/gpio.h
@@ -1,228 +1,226 @@
-/*
- * arch/arm/mach-at91/include/mach/gpio.h
- *
- * Copyright (C) 2005 HP Labs
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- */
-
-#ifndef __ASM_ARCH_AT91RM9200_GPIO_H
-#define __ASM_ARCH_AT91RM9200_GPIO_H
-
-#include <linux/kernel.h>
-#include <asm/irq.h>
-
-#define PIN_BASE NR_AIC_IRQS
-
-#define MAX_GPIO_BANKS 5
-#define NR_BUILTIN_GPIO (PIN_BASE + (MAX_GPIO_BANKS * 32))
-
-/* these pin numbers double as IRQ numbers, like AT91xxx_ID_* values */
-
-#define AT91_PIN_PA0 (PIN_BASE + 0x00 + 0)
-#define AT91_PIN_PA1 (PIN_BASE + 0x00 + 1)
-#define AT91_PIN_PA2 (PIN_BASE + 0x00 + 2)
-#define AT91_PIN_PA3 (PIN_BASE + 0x00 + 3)
-#define AT91_PIN_PA4 (PIN_BASE + 0x00 + 4)
-#define AT91_PIN_PA5 (PIN_BASE + 0x00 + 5)
-#define AT91_PIN_PA6 (PIN_BASE + 0x00 + 6)
-#define AT91_PIN_PA7 (PIN_BASE + 0x00 + 7)
-#define AT91_PIN_PA8 (PIN_BASE + 0x00 + 8)
-#define AT91_PIN_PA9 (PIN_BASE + 0x00 + 9)
-#define AT91_PIN_PA10 (PIN_BASE + 0x00 + 10)
-#define AT91_PIN_PA11 (PIN_BASE + 0x00 + 11)
-#define AT91_PIN_PA12 (PIN_BASE + 0x00 + 12)
-#define AT91_PIN_PA13 (PIN_BASE + 0x00 + 13)
-#define AT91_PIN_PA14 (PIN_BASE + 0x00 + 14)
-#define AT91_PIN_PA15 (PIN_BASE + 0x00 + 15)
-#define AT91_PIN_PA16 (PIN_BASE + 0x00 + 16)
-#define AT91_PIN_PA17 (PIN_BASE + 0x00 + 17)
-#define AT91_PIN_PA18 (PIN_BASE + 0x00 + 18)
-#define AT91_PIN_PA19 (PIN_BASE + 0x00 + 19)
-#define AT91_PIN_PA20 (PIN_BASE + 0x00 + 20)
-#define AT91_PIN_PA21 (PIN_BASE + 0x00 + 21)
-#define AT91_PIN_PA22 (PIN_BASE + 0x00 + 22)
-#define AT91_PIN_PA23 (PIN_BASE + 0x00 + 23)
-#define AT91_PIN_PA24 (PIN_BASE + 0x00 + 24)
-#define AT91_PIN_PA25 (PIN_BASE + 0x00 + 25)
-#define AT91_PIN_PA26 (PIN_BASE + 0x00 + 26)
-#define AT91_PIN_PA27 (PIN_BASE + 0x00 + 27)
-#define AT91_PIN_PA28 (PIN_BASE + 0x00 + 28)
-#define AT91_PIN_PA29 (PIN_BASE + 0x00 + 29)
-#define AT91_PIN_PA30 (PIN_BASE + 0x00 + 30)
-#define AT91_PIN_PA31 (PIN_BASE + 0x00 + 31)
-
-#define AT91_PIN_PB0 (PIN_BASE + 0x20 + 0)
-#define AT91_PIN_PB1 (PIN_BASE + 0x20 + 1)
-#define AT91_PIN_PB2 (PIN_BASE + 0x20 + 2)
-#define AT91_PIN_PB3 (PIN_BASE + 0x20 + 3)
-#define AT91_PIN_PB4 (PIN_BASE + 0x20 + 4)
-#define AT91_PIN_PB5 (PIN_BASE + 0x20 + 5)
-#define AT91_PIN_PB6 (PIN_BASE + 0x20 + 6)
-#define AT91_PIN_PB7 (PIN_BASE + 0x20 + 7)
-#define AT91_PIN_PB8 (PIN_BASE + 0x20 + 8)
-#define AT91_PIN_PB9 (PIN_BASE + 0x20 + 9)
-#define AT91_PIN_PB10 (PIN_BASE + 0x20 + 10)
-#define AT91_PIN_PB11 (PIN_BASE + 0x20 + 11)
-#define AT91_PIN_PB12 (PIN_BASE + 0x20 + 12)
-#define AT91_PIN_PB13 (PIN_BASE + 0x20 + 13)
-#define AT91_PIN_PB14 (PIN_BASE + 0x20 + 14)
-#define AT91_PIN_PB15 (PIN_BASE + 0x20 + 15)
-#define AT91_PIN_PB16 (PIN_BASE + 0x20 + 16)
-#define AT91_PIN_PB17 (PIN_BASE + 0x20 + 17)
-#define AT91_PIN_PB18 (PIN_BASE + 0x20 + 18)
-#define AT91_PIN_PB19 (PIN_BASE + 0x20 + 19)
-#define AT91_PIN_PB20 (PIN_BASE + 0x20 + 20)
-#define AT91_PIN_PB21 (PIN_BASE + 0x20 + 21)
-#define AT91_PIN_PB22 (PIN_BASE + 0x20 + 22)
-#define AT91_PIN_PB23 (PIN_BASE + 0x20 + 23)
-#define AT91_PIN_PB24 (PIN_BASE + 0x20 + 24)
-#define AT91_PIN_PB25 (PIN_BASE + 0x20 + 25)
-#define AT91_PIN_PB26 (PIN_BASE + 0x20 + 26)
-#define AT91_PIN_PB27 (PIN_BASE + 0x20 + 27)
-#define AT91_PIN_PB28 (PIN_BASE + 0x20 + 28)
-#define AT91_PIN_PB29 (PIN_BASE + 0x20 + 29)
-#define AT91_PIN_PB30 (PIN_BASE + 0x20 + 30)
-#define AT91_PIN_PB31 (PIN_BASE + 0x20 + 31)
-
-#define AT91_PIN_PC0 (PIN_BASE + 0x40 + 0)
-#define AT91_PIN_PC1 (PIN_BASE + 0x40 + 1)
-#define AT91_PIN_PC2 (PIN_BASE + 0x40 + 2)
-#define AT91_PIN_PC3 (PIN_BASE + 0x40 + 3)
-#define AT91_PIN_PC4 (PIN_BASE + 0x40 + 4)
-#define AT91_PIN_PC5 (PIN_BASE + 0x40 + 5)
-#define AT91_PIN_PC6 (PIN_BASE + 0x40 + 6)
-#define AT91_PIN_PC7 (PIN_BASE + 0x40 + 7)
-#define AT91_PIN_PC8 (PIN_BASE + 0x40 + 8)
-#define AT91_PIN_PC9 (PIN_BASE + 0x40 + 9)
-#define AT91_PIN_PC10 (PIN_BASE + 0x40 + 10)
-#define AT91_PIN_PC11 (PIN_BASE + 0x40 + 11)
-#define AT91_PIN_PC12 (PIN_BASE + 0x40 + 12)
-#define AT91_PIN_PC13 (PIN_BASE + 0x40 + 13)
-#define AT91_PIN_PC14 (PIN_BASE + 0x40 + 14)
-#define AT91_PIN_PC15 (PIN_BASE + 0x40 + 15)
-#define AT91_PIN_PC16 (PIN_BASE + 0x40 + 16)
-#define AT91_PIN_PC17 (PIN_BASE + 0x40 + 17)
-#define AT91_PIN_PC18 (PIN_BASE + 0x40 + 18)
-#define AT91_PIN_PC19 (PIN_BASE + 0x40 + 19)
-#define AT91_PIN_PC20 (PIN_BASE + 0x40 + 20)
-#define AT91_PIN_PC21 (PIN_BASE + 0x40 + 21)
-#define AT91_PIN_PC22 (PIN_BASE + 0x40 + 22)
-#define AT91_PIN_PC23 (PIN_BASE + 0x40 + 23)
-#define AT91_PIN_PC24 (PIN_BASE + 0x40 + 24)
-#define AT91_PIN_PC25 (PIN_BASE + 0x40 + 25)
-#define AT91_PIN_PC26 (PIN_BASE + 0x40 + 26)
-#define AT91_PIN_PC27 (PIN_BASE + 0x40 + 27)
-#define AT91_PIN_PC28 (PIN_BASE + 0x40 + 28)
-#define AT91_PIN_PC29 (PIN_BASE + 0x40 + 29)
-#define AT91_PIN_PC30 (PIN_BASE + 0x40 + 30)
-#define AT91_PIN_PC31 (PIN_BASE + 0x40 + 31)
-
-#define AT91_PIN_PD0 (PIN_BASE + 0x60 + 0)
-#define AT91_PIN_PD1 (PIN_BASE + 0x60 + 1)
-#define AT91_PIN_PD2 (PIN_BASE + 0x60 + 2)
-#define AT91_PIN_PD3 (PIN_BASE + 0x60 + 3)
-#define AT91_PIN_PD4 (PIN_BASE + 0x60 + 4)
-#define AT91_PIN_PD5 (PIN_BASE + 0x60 + 5)
-#define AT91_PIN_PD6 (PIN_BASE + 0x60 + 6)
-#define AT91_PIN_PD7 (PIN_BASE + 0x60 + 7)
-#define AT91_PIN_PD8 (PIN_BASE + 0x60 + 8)
-#define AT91_PIN_PD9 (PIN_BASE + 0x60 + 9)
-#define AT91_PIN_PD10 (PIN_BASE + 0x60 + 10)
-#define AT91_PIN_PD11 (PIN_BASE + 0x60 + 11)
-#define AT91_PIN_PD12 (PIN_BASE + 0x60 + 12)
-#define AT91_PIN_PD13 (PIN_BASE + 0x60 + 13)
-#define AT91_PIN_PD14 (PIN_BASE + 0x60 + 14)
-#define AT91_PIN_PD15 (PIN_BASE + 0x60 + 15)
-#define AT91_PIN_PD16 (PIN_BASE + 0x60 + 16)
-#define AT91_PIN_PD17 (PIN_BASE + 0x60 + 17)
-#define AT91_PIN_PD18 (PIN_BASE + 0x60 + 18)
-#define AT91_PIN_PD19 (PIN_BASE + 0x60 + 19)
-#define AT91_PIN_PD20 (PIN_BASE + 0x60 + 20)
-#define AT91_PIN_PD21 (PIN_BASE + 0x60 + 21)
-#define AT91_PIN_PD22 (PIN_BASE + 0x60 + 22)
-#define AT91_PIN_PD23 (PIN_BASE + 0x60 + 23)
-#define AT91_PIN_PD24 (PIN_BASE + 0x60 + 24)
-#define AT91_PIN_PD25 (PIN_BASE + 0x60 + 25)
-#define AT91_PIN_PD26 (PIN_BASE + 0x60 + 26)
-#define AT91_PIN_PD27 (PIN_BASE + 0x60 + 27)
-#define AT91_PIN_PD28 (PIN_BASE + 0x60 + 28)
-#define AT91_PIN_PD29 (PIN_BASE + 0x60 + 29)
-#define AT91_PIN_PD30 (PIN_BASE + 0x60 + 30)
-#define AT91_PIN_PD31 (PIN_BASE + 0x60 + 31)
-
-#define AT91_PIN_PE0 (PIN_BASE + 0x80 + 0)
-#define AT91_PIN_PE1 (PIN_BASE + 0x80 + 1)
-#define AT91_PIN_PE2 (PIN_BASE + 0x80 + 2)
-#define AT91_PIN_PE3 (PIN_BASE + 0x80 + 3)
-#define AT91_PIN_PE4 (PIN_BASE + 0x80 + 4)
-#define AT91_PIN_PE5 (PIN_BASE + 0x80 + 5)
-#define AT91_PIN_PE6 (PIN_BASE + 0x80 + 6)
-#define AT91_PIN_PE7 (PIN_BASE + 0x80 + 7)
-#define AT91_PIN_PE8 (PIN_BASE + 0x80 + 8)
-#define AT91_PIN_PE9 (PIN_BASE + 0x80 + 9)
-#define AT91_PIN_PE10 (PIN_BASE + 0x80 + 10)
-#define AT91_PIN_PE11 (PIN_BASE + 0x80 + 11)
-#define AT91_PIN_PE12 (PIN_BASE + 0x80 + 12)
-#define AT91_PIN_PE13 (PIN_BASE + 0x80 + 13)
-#define AT91_PIN_PE14 (PIN_BASE + 0x80 + 14)
-#define AT91_PIN_PE15 (PIN_BASE + 0x80 + 15)
-#define AT91_PIN_PE16 (PIN_BASE + 0x80 + 16)
-#define AT91_PIN_PE17 (PIN_BASE + 0x80 + 17)
-#define AT91_PIN_PE18 (PIN_BASE + 0x80 + 18)
-#define AT91_PIN_PE19 (PIN_BASE + 0x80 + 19)
-#define AT91_PIN_PE20 (PIN_BASE + 0x80 + 20)
-#define AT91_PIN_PE21 (PIN_BASE + 0x80 + 21)
-#define AT91_PIN_PE22 (PIN_BASE + 0x80 + 22)
-#define AT91_PIN_PE23 (PIN_BASE + 0x80 + 23)
-#define AT91_PIN_PE24 (PIN_BASE + 0x80 + 24)
-#define AT91_PIN_PE25 (PIN_BASE + 0x80 + 25)
-#define AT91_PIN_PE26 (PIN_BASE + 0x80 + 26)
-#define AT91_PIN_PE27 (PIN_BASE + 0x80 + 27)
-#define AT91_PIN_PE28 (PIN_BASE + 0x80 + 28)
-#define AT91_PIN_PE29 (PIN_BASE + 0x80 + 29)
-#define AT91_PIN_PE30 (PIN_BASE + 0x80 + 30)
-#define AT91_PIN_PE31 (PIN_BASE + 0x80 + 31)
-
-#ifndef __ASSEMBLY__
-/* setup setup routines, called from board init or driver probe() */
-extern int __init_or_module at91_set_GPIO_periph(unsigned pin, int use_pullup);
-extern int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup);
-extern int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup);
-extern int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup);
-extern int __init_or_module at91_set_gpio_output(unsigned pin, int value);
-extern int __init_or_module at91_set_deglitch(unsigned pin, int is_on);
-extern int __init_or_module at91_set_multi_drive(unsigned pin, int is_on);
-
-/* callable at any time */
-extern int at91_set_gpio_value(unsigned pin, int value);
-extern int at91_get_gpio_value(unsigned pin);
-
-/* callable only from core power-management code */
-extern void at91_gpio_suspend(void);
-extern void at91_gpio_resume(void);
-
-/*-------------------------------------------------------------------------*/
-
-/* wrappers for "new style" GPIO calls. the old AT91-specific ones should
- * eventually be removed (along with this errno.h inclusion), and the
- * gpio request/free calls should probably be implemented.
- */
-
-#include <asm/errno.h>
-#include <asm-generic/gpio.h> /* cansleep wrappers */
-
-#define gpio_get_value __gpio_get_value
-#define gpio_set_value __gpio_set_value
-#define gpio_cansleep __gpio_cansleep
-
-#define gpio_to_irq(gpio) (gpio)
-#define irq_to_gpio(irq) (irq)
-
-#endif /* __ASSEMBLY__ */
-
-#endif
+/*
+ * arch/arm/mach-at91/include/mach/gpio.h
+ *
+ * Copyright (C) 2005 HP Labs
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#ifndef __ASM_ARCH_AT91RM9200_GPIO_H
+#define __ASM_ARCH_AT91RM9200_GPIO_H
+
+#include <linux/kernel.h>
+#include <asm/irq.h>
+
+#define MAX_GPIO_BANKS 5
+#define NR_BUILTIN_GPIO (MAX_GPIO_BANKS * 32)
+
+/* these pin numbers double as IRQ numbers, like AT91xxx_ID_* values */
+
+#define AT91_PIN_PA0 (0x00 + 0)
+#define AT91_PIN_PA1 (0x00 + 1)
+#define AT91_PIN_PA2 (0x00 + 2)
+#define AT91_PIN_PA3 (0x00 + 3)
+#define AT91_PIN_PA4 (0x00 + 4)
+#define AT91_PIN_PA5 (0x00 + 5)
+#define AT91_PIN_PA6 (0x00 + 6)
+#define AT91_PIN_PA7 (0x00 + 7)
+#define AT91_PIN_PA8 (0x00 + 8)
+#define AT91_PIN_PA9 (0x00 + 9)
+#define AT91_PIN_PA10 (0x00 + 10)
+#define AT91_PIN_PA11 (0x00 + 11)
+#define AT91_PIN_PA12 (0x00 + 12)
+#define AT91_PIN_PA13 (0x00 + 13)
+#define AT91_PIN_PA14 (0x00 + 14)
+#define AT91_PIN_PA15 (0x00 + 15)
+#define AT91_PIN_PA16 (0x00 + 16)
+#define AT91_PIN_PA17 (0x00 + 17)
+#define AT91_PIN_PA18 (0x00 + 18)
+#define AT91_PIN_PA19 (0x00 + 19)
+#define AT91_PIN_PA20 (0x00 + 20)
+#define AT91_PIN_PA21 (0x00 + 21)
+#define AT91_PIN_PA22 (0x00 + 22)
+#define AT91_PIN_PA23 (0x00 + 23)
+#define AT91_PIN_PA24 (0x00 + 24)
+#define AT91_PIN_PA25 (0x00 + 25)
+#define AT91_PIN_PA26 (0x00 + 26)
+#define AT91_PIN_PA27 (0x00 + 27)
+#define AT91_PIN_PA28 (0x00 + 28)
+#define AT91_PIN_PA29 (0x00 + 29)
+#define AT91_PIN_PA30 (0x00 + 30)
+#define AT91_PIN_PA31 (0x00 + 31)
+
+#define AT91_PIN_PB0 (0x20 + 0)
+#define AT91_PIN_PB1 (0x20 + 1)
+#define AT91_PIN_PB2 (0x20 + 2)
+#define AT91_PIN_PB3 (0x20 + 3)
+#define AT91_PIN_PB4 (0x20 + 4)
+#define AT91_PIN_PB5 (0x20 + 5)
+#define AT91_PIN_PB6 (0x20 + 6)
+#define AT91_PIN_PB7 (0x20 + 7)
+#define AT91_PIN_PB8 (0x20 + 8)
+#define AT91_PIN_PB9 (0x20 + 9)
+#define AT91_PIN_PB10 (0x20 + 10)
+#define AT91_PIN_PB11 (0x20 + 11)
+#define AT91_PIN_PB12 (0x20 + 12)
+#define AT91_PIN_PB13 (0x20 + 13)
+#define AT91_PIN_PB14 (0x20 + 14)
+#define AT91_PIN_PB15 (0x20 + 15)
+#define AT91_PIN_PB16 (0x20 + 16)
+#define AT91_PIN_PB17 (0x20 + 17)
+#define AT91_PIN_PB18 (0x20 + 18)
+#define AT91_PIN_PB19 (0x20 + 19)
+#define AT91_PIN_PB20 (0x20 + 20)
+#define AT91_PIN_PB21 (0x20 + 21)
+#define AT91_PIN_PB22 (0x20 + 22)
+#define AT91_PIN_PB23 (0x20 + 23)
+#define AT91_PIN_PB24 (0x20 + 24)
+#define AT91_PIN_PB25 (0x20 + 25)
+#define AT91_PIN_PB26 (0x20 + 26)
+#define AT91_PIN_PB27 (0x20 + 27)
+#define AT91_PIN_PB28 (0x20 + 28)
+#define AT91_PIN_PB29 (0x20 + 29)
+#define AT91_PIN_PB30 (0x20 + 30)
+#define AT91_PIN_PB31 (0x20 + 31)
+
+#define AT91_PIN_PC0 (0x40 + 0)
+#define AT91_PIN_PC1 (0x40 + 1)
+#define AT91_PIN_PC2 (0x40 + 2)
+#define AT91_PIN_PC3 (0x40 + 3)
+#define AT91_PIN_PC4 (0x40 + 4)
+#define AT91_PIN_PC5 (0x40 + 5)
+#define AT91_PIN_PC6 (0x40 + 6)
+#define AT91_PIN_PC7 (0x40 + 7)
+#define AT91_PIN_PC8 (0x40 + 8)
+#define AT91_PIN_PC9 (0x40 + 9)
+#define AT91_PIN_PC10 (0x40 + 10)
+#define AT91_PIN_PC11 (0x40 + 11)
+#define AT91_PIN_PC12 (0x40 + 12)
+#define AT91_PIN_PC13 (0x40 + 13)
+#define AT91_PIN_PC14 (0x40 + 14)
+#define AT91_PIN_PC15 (0x40 + 15)
+#define AT91_PIN_PC16 (0x40 + 16)
+#define AT91_PIN_PC17 (0x40 + 17)
+#define AT91_PIN_PC18 (0x40 + 18)
+#define AT91_PIN_PC19 (0x40 + 19)
+#define AT91_PIN_PC20 (0x40 + 20)
+#define AT91_PIN_PC21 (0x40 + 21)
+#define AT91_PIN_PC22 (0x40 + 22)
+#define AT91_PIN_PC23 (0x40 + 23)
+#define AT91_PIN_PC24 (0x40 + 24)
+#define AT91_PIN_PC25 (0x40 + 25)
+#define AT91_PIN_PC26 (0x40 + 26)
+#define AT91_PIN_PC27 (0x40 + 27)
+#define AT91_PIN_PC28 (0x40 + 28)
+#define AT91_PIN_PC29 (0x40 + 29)
+#define AT91_PIN_PC30 (0x40 + 30)
+#define AT91_PIN_PC31 (0x40 + 31)
+
+#define AT91_PIN_PD0 (0x60 + 0)
+#define AT91_PIN_PD1 (0x60 + 1)
+#define AT91_PIN_PD2 (0x60 + 2)
+#define AT91_PIN_PD3 (0x60 + 3)
+#define AT91_PIN_PD4 (0x60 + 4)
+#define AT91_PIN_PD5 (0x60 + 5)
+#define AT91_PIN_PD6 (0x60 + 6)
+#define AT91_PIN_PD7 (0x60 + 7)
+#define AT91_PIN_PD8 (0x60 + 8)
+#define AT91_PIN_PD9 (0x60 + 9)
+#define AT91_PIN_PD10 (0x60 + 10)
+#define AT91_PIN_PD11 (0x60 + 11)
+#define AT91_PIN_PD12 (0x60 + 12)
+#define AT91_PIN_PD13 (0x60 + 13)
+#define AT91_PIN_PD14 (0x60 + 14)
+#define AT91_PIN_PD15 (0x60 + 15)
+#define AT91_PIN_PD16 (0x60 + 16)
+#define AT91_PIN_PD17 (0x60 + 17)
+#define AT91_PIN_PD18 (0x60 + 18)
+#define AT91_PIN_PD19 (0x60 + 19)
+#define AT91_PIN_PD20 (0x60 + 20)
+#define AT91_PIN_PD21 (0x60 + 21)
+#define AT91_PIN_PD22 (0x60 + 22)
+#define AT91_PIN_PD23 (0x60 + 23)
+#define AT91_PIN_PD24 (0x60 + 24)
+#define AT91_PIN_PD25 (0x60 + 25)
+#define AT91_PIN_PD26 (0x60 + 26)
+#define AT91_PIN_PD27 (0x60 + 27)
+#define AT91_PIN_PD28 (0x60 + 28)
+#define AT91_PIN_PD29 (0x60 + 29)
+#define AT91_PIN_PD30 (0x60 + 30)
+#define AT91_PIN_PD31 (0x60 + 31)
+
+#define AT91_PIN_PE0 (0x80 + 0)
+#define AT91_PIN_PE1 (0x80 + 1)
+#define AT91_PIN_PE2 (0x80 + 2)
+#define AT91_PIN_PE3 (0x80 + 3)
+#define AT91_PIN_PE4 (0x80 + 4)
+#define AT91_PIN_PE5 (0x80 + 5)
+#define AT91_PIN_PE6 (0x80 + 6)
+#define AT91_PIN_PE7 (0x80 + 7)
+#define AT91_PIN_PE8 (0x80 + 8)
+#define AT91_PIN_PE9 (0x80 + 9)
+#define AT91_PIN_PE10 (0x80 + 10)
+#define AT91_PIN_PE11 (0x80 + 11)
+#define AT91_PIN_PE12 (0x80 + 12)
+#define AT91_PIN_PE13 (0x80 + 13)
+#define AT91_PIN_PE14 (0x80 + 14)
+#define AT91_PIN_PE15 (0x80 + 15)
+#define AT91_PIN_PE16 (0x80 + 16)
+#define AT91_PIN_PE17 (0x80 + 17)
+#define AT91_PIN_PE18 (0x80 + 18)
+#define AT91_PIN_PE19 (0x80 + 19)
+#define AT91_PIN_PE20 (0x80 + 20)
+#define AT91_PIN_PE21 (0x80 + 21)
+#define AT91_PIN_PE22 (0x80 + 22)
+#define AT91_PIN_PE23 (0x80 + 23)
+#define AT91_PIN_PE24 (0x80 + 24)
+#define AT91_PIN_PE25 (0x80 + 25)
+#define AT91_PIN_PE26 (0x80 + 26)
+#define AT91_PIN_PE27 (0x80 + 27)
+#define AT91_PIN_PE28 (0x80 + 28)
+#define AT91_PIN_PE29 (0x80 + 29)
+#define AT91_PIN_PE30 (0x80 + 30)
+#define AT91_PIN_PE31 (0x80 + 31)
+
+#ifndef __ASSEMBLY__
+/* setup setup routines, called from board init or driver probe() */
+extern int __init_or_module at91_set_GPIO_periph(unsigned pin, int use_pullup);
+extern int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup);
+extern int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup);
+extern int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup);
+extern int __init_or_module at91_set_gpio_output(unsigned pin, int value);
+extern int __init_or_module at91_set_deglitch(unsigned pin, int is_on);
+extern int __init_or_module at91_set_multi_drive(unsigned pin, int is_on);
+
+/* callable at any time */
+extern int at91_set_gpio_value(unsigned pin, int value);
+extern int at91_get_gpio_value(unsigned pin);
+
+/* callable only from core power-management code */
+extern void at91_gpio_suspend(void);
+extern void at91_gpio_resume(void);
+
+/*-------------------------------------------------------------------------*/
+
+/* wrappers for "new style" GPIO calls. the old AT91-specific ones should
+ * eventually be removed (along with this errno.h inclusion), and the
+ * gpio request/free calls should probably be implemented.
+ */
+
+#include <asm/errno.h>
+#include <asm-generic/gpio.h> /* cansleep wrappers */
+
+#define gpio_get_value __gpio_get_value
+#define gpio_set_value __gpio_set_value
+#define gpio_cansleep __gpio_cansleep
+
+#define gpio_to_irq(gpio) (gpio + NR_AIC_IRQS)
+#define irq_to_gpio(irq) (irq - NR_AIC_IRQS)
+
+#endif /* __ASSEMBLY__ */
+
+#endif
--
1.7.5.4
^ permalink raw reply related
* [PATCH 09/11] at92/ohci: use gpio_is_valid to check the gpio
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-19 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316436695-19194-1-git-send-email-plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: linux-usb at vger.kernel.org
---
Hi,
I'd like to apply this patch via AT91 with the whole gpio patch series
Best Regards,
J.
drivers/usb/host/ohci-at91.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index e08cb10..70701f4 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -276,7 +276,7 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
* active-low power switches.
*/
for (i = 0; i < ARRAY_SIZE(pdata->vbus_pin); i++) {
- if (pdata->vbus_pin[i] <= 0)
+ if (!gpio_is_valid(pdata->vbus_pin[i]))
continue;
gpio_request(pdata->vbus_pin[i], "ohci_vbus");
gpio_direction_output(pdata->vbus_pin[i], 0);
@@ -294,7 +294,7 @@ static int ohci_hcd_at91_drv_remove(struct platform_device *pdev)
if (pdata) {
for (i = 0; i < ARRAY_SIZE(pdata->vbus_pin); i++) {
- if (pdata->vbus_pin[i] <= 0)
+ if (!gpio_is_valid(pdata->vbus_pin[i]))
continue;
gpio_direction_output(pdata->vbus_pin[i], 1);
gpio_free(pdata->vbus_pin[i]);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 08/11] at92/udc: use gpio_is_valid to check the gpio
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-19 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316436695-19194-1-git-send-email-plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: linux-usb at vger.kernel.org
---
Hi,
I'd like to apply this patch via AT91 with the whole gpio patch series
Best Regards,
J.
drivers/usb/gadget/at91_udc.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index ddb118a..205498d 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -1758,7 +1758,7 @@ static int __init at91udc_probe(struct platform_device *pdev)
/* rm9200 needs manual D+ pullup; off by default */
if (cpu_is_at91rm9200()) {
- if (udc->board.pullup_pin <= 0) {
+ if (gpio_is_valid(udc->board.pullup_pin)) {
DBG("no D+ pullup?\n");
retval = -ENODEV;
goto fail0;
@@ -1825,7 +1825,7 @@ static int __init at91udc_probe(struct platform_device *pdev)
DBG("request irq %d failed\n", udc->udp_irq);
goto fail1;
}
- if (udc->board.vbus_pin > 0) {
+ if (gpio_is_valid(udc->board.vbus_pin)) {
retval = gpio_request(udc->board.vbus_pin, "udc_vbus");
if (retval < 0) {
DBG("request vbus pin failed\n");
@@ -1869,10 +1869,10 @@ static int __init at91udc_probe(struct platform_device *pdev)
INFO("%s version %s\n", driver_name, DRIVER_VERSION);
return 0;
fail4:
- if (udc->board.vbus_pin > 0 && !udc->board.vbus_polled)
+ if (gpio_is_valid(udc->board.vbus_pin) && !udc->board.vbus_polled)
free_irq(udc->board.vbus_pin, udc);
fail3:
- if (udc->board.vbus_pin > 0)
+ if (gpio_is_valid(udc->board.vbus_pin))
gpio_free(udc->board.vbus_pin);
fail2:
free_irq(udc->udp_irq, udc);
@@ -1907,7 +1907,7 @@ static int __exit at91udc_remove(struct platform_device *pdev)
device_init_wakeup(&pdev->dev, 0);
remove_debug_file(udc);
- if (udc->board.vbus_pin > 0) {
+ if (gpio_is_valid(udc->board.vbus_pin)) {
free_irq(udc->board.vbus_pin, udc);
gpio_free(udc->board.vbus_pin);
}
@@ -1951,7 +1951,7 @@ static int at91udc_suspend(struct platform_device *pdev, pm_message_t mesg)
enable_irq_wake(udc->udp_irq);
udc->active_suspend = wake;
- if (udc->board.vbus_pin > 0 && !udc->board.vbus_polled && wake)
+ if (gpio_is_valid(udc->board.vbus_pin) && !udc->board.vbus_polled && wake)
enable_irq_wake(udc->board.vbus_pin);
return 0;
}
@@ -1961,7 +1961,7 @@ static int at91udc_resume(struct platform_device *pdev)
struct at91_udc *udc = platform_get_drvdata(pdev);
unsigned long flags;
- if (udc->board.vbus_pin > 0 && !udc->board.vbus_polled &&
+ if (gpio_is_valid(udc->board.vbus_pin) && !udc->board.vbus_polled &&
udc->active_suspend)
disable_irq_wake(udc->board.vbus_pin);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 07/11] at92/nand: use gpio_is_valid to check the gpio
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-19 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316436695-19194-1-git-send-email-plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: linux-mtd at lists.infradead.org
---
Hi,
I'd like to apply this patch via AT91 with the whole gpio patch series
Best Regards,
J.
drivers/mtd/nand/atmel_nand.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 55da20c..e20ac1f 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -113,7 +113,7 @@ static int cpu_has_dma(void)
*/
static void atmel_nand_enable(struct atmel_nand_host *host)
{
- if (host->board->enable_pin)
+ if (gpio_is_valid(host->board->enable_pin))
gpio_set_value(host->board->enable_pin, 0);
}
@@ -122,7 +122,7 @@ static void atmel_nand_enable(struct atmel_nand_host *host)
*/
static void atmel_nand_disable(struct atmel_nand_host *host)
{
- if (host->board->enable_pin)
+ if (gpio_is_valid(host->board->enable_pin))
gpio_set_value(host->board->enable_pin, 1);
}
@@ -535,7 +535,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
nand_chip->IO_ADDR_W = host->io_base;
nand_chip->cmd_ctrl = atmel_nand_cmd_ctrl;
- if (host->board->rdy_pin)
+ if (gpio_is_valid(host->board->rdy_pin))
nand_chip->dev_ready = atmel_nand_device_ready;
regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -573,7 +573,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, host);
atmel_nand_enable(host);
- if (host->board->det_pin) {
+ if (gpio_is_valid(host->board->det_pin)) {
if (gpio_get_value(host->board->det_pin)) {
printk(KERN_INFO "No SmartMedia card inserted.\n");
res = -ENXIO;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 06/11] at91/mmc: use gpio_is_valid to check the gpio
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-19 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316436695-19194-1-git-send-email-plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: linux-mmc at vger.kernel.org
---
Hi,
I'd like to apply this patch via AT91 with the whole gpio patch series
Best Regards,
J.
drivers/mmc/host/at91_mci.c | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/host/at91_mci.c b/drivers/mmc/host/at91_mci.c
index a4aa3af..7504b22 100644
--- a/drivers/mmc/host/at91_mci.c
+++ b/drivers/mmc/host/at91_mci.c
@@ -741,7 +741,7 @@ static void at91_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
at91_mci_write(host, AT91_MCI_MR, (at91_mci_read(host, AT91_MCI_MR) & ~AT91_MCI_CLKDIV) | clkdiv);
/* maybe switch power to the card */
- if (host->board->vcc_pin) {
+ if (gpio_is_valid(host->board->vcc_pin)) {
switch (ios->power_mode) {
case MMC_POWER_OFF:
gpio_set_value(host->board->vcc_pin, 0);
@@ -893,7 +893,7 @@ static int at91_mci_get_ro(struct mmc_host *mmc)
{
struct at91mci_host *host = mmc_priv(mmc);
- if (host->board->wp_pin)
+ if (gpio_is_valid(host->board->wp_pin))
return !!gpio_get_value(host->board->wp_pin);
/*
* Board doesn't support read only detection; let the mmc core
@@ -987,21 +987,21 @@ static int __init at91_mci_probe(struct platform_device *pdev)
* Reserve GPIOs ... board init code makes sure these pins are set
* up as GPIOs with the right direction (input, except for vcc)
*/
- if (host->board->det_pin) {
+ if (gpio_is_valid(host->board->det_pin)) {
ret = gpio_request(host->board->det_pin, "mmc_detect");
if (ret < 0) {
dev_dbg(&pdev->dev, "couldn't claim card detect pin\n");
goto fail4b;
}
}
- if (host->board->wp_pin) {
+ if (gpio_is_valid(host->board->wp_pin)) {
ret = gpio_request(host->board->wp_pin, "mmc_wp");
if (ret < 0) {
dev_dbg(&pdev->dev, "couldn't claim wp sense pin\n");
goto fail4;
}
}
- if (host->board->vcc_pin) {
+ if (gpio_is_valid(host->board->vcc_pin)) {
ret = gpio_request(host->board->vcc_pin, "mmc_vcc");
if (ret < 0) {
dev_dbg(&pdev->dev, "couldn't claim vcc switch pin\n");
@@ -1053,7 +1053,7 @@ static int __init at91_mci_probe(struct platform_device *pdev)
/*
* Add host to MMC layer
*/
- if (host->board->det_pin) {
+ if (gpio_is_valid(host->board->det_pin)) {
host->present = !gpio_get_value(host->board->det_pin);
}
else
@@ -1064,7 +1064,7 @@ static int __init at91_mci_probe(struct platform_device *pdev)
/*
* monitor card insertion/removal if we can
*/
- if (host->board->det_pin) {
+ if (gpio_is_valid(host->board->det_pin)) {
ret = request_irq(gpio_to_irq(host->board->det_pin),
at91_mmc_det_irq, 0, mmc_hostname(mmc), host);
if (ret)
@@ -1083,13 +1083,13 @@ fail0:
fail1:
clk_put(host->mci_clk);
fail2:
- if (host->board->vcc_pin)
+ if (gpio_is_valid(host->board->vcc_pin))
gpio_free(host->board->vcc_pin);
fail3:
- if (host->board->wp_pin)
+ if (gpio_is_valid(host->board->wp_pin))
gpio_free(host->board->wp_pin);
fail4:
- if (host->board->det_pin)
+ if (gpio_is_valid(host->board->det_pin))
gpio_free(host->board->det_pin);
fail4b:
if (host->buffer)
@@ -1121,7 +1121,7 @@ static int __exit at91_mci_remove(struct platform_device *pdev)
dma_free_coherent(&pdev->dev, MCI_BUFSIZE,
host->buffer, host->physical_address);
- if (host->board->det_pin) {
+ if (gpio_is_valid(host->board->det_pin)) {
if (device_can_wakeup(&pdev->dev))
free_irq(gpio_to_irq(host->board->det_pin), host);
device_init_wakeup(&pdev->dev, 0);
@@ -1136,9 +1136,9 @@ static int __exit at91_mci_remove(struct platform_device *pdev)
clk_disable(host->mci_clk); /* Disable the peripheral clock */
clk_put(host->mci_clk);
- if (host->board->vcc_pin)
+ if (gpio_is_valid(host->board->vcc_pin))
gpio_free(host->board->vcc_pin);
- if (host->board->wp_pin)
+ if (gpio_is_valid(host->board->wp_pin))
gpio_free(host->board->wp_pin);
iounmap(host->baseaddr);
@@ -1159,7 +1159,7 @@ static int at91_mci_suspend(struct platform_device *pdev, pm_message_t state)
struct at91mci_host *host = mmc_priv(mmc);
int ret = 0;
- if (host->board->det_pin && device_may_wakeup(&pdev->dev))
+ if (gpio_is_valid(host->board->det_pin) && device_may_wakeup(&pdev->dev))
enable_irq_wake(host->board->det_pin);
if (mmc)
@@ -1174,7 +1174,7 @@ static int at91_mci_resume(struct platform_device *pdev)
struct at91mci_host *host = mmc_priv(mmc);
int ret = 0;
- if (host->board->det_pin && device_may_wakeup(&pdev->dev))
+ if (gpio_is_valid(host->board->det_pin) && device_may_wakeup(&pdev->dev))
disable_irq_wake(host->board->det_pin);
if (mmc)
--
1.7.5.4
^ permalink raw reply related
* [PATCH] ARM: mach-qong: Add watchdog support
From: Fabio Estevam @ 2011-09-19 13:59 UTC (permalink / raw)
To: linux-arm-kernel
Add watchdog support for mach-qong target.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/mach-qong.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 0519dd7..8748531 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -485,6 +485,7 @@ config MACH_QONG
bool "Support Dave/DENX QongEVB-LITE platform"
select SOC_IMX31
select IMX_HAVE_PLATFORM_IMX_UART
+ select IMX_HAVE_PLATFORM_IMX2_WDT
help
Include support for Dave/DENX QongEVB-LITE platform. This includes
specific configurations for the board and its peripherals.
diff --git a/arch/arm/mach-imx/mach-qong.c b/arch/arm/mach-imx/mach-qong.c
index 3626f48..44462ce 100644
--- a/arch/arm/mach-imx/mach-qong.c
+++ b/arch/arm/mach-imx/mach-qong.c
@@ -249,6 +249,7 @@ static void __init qong_init(void)
mxc_init_imx_uart();
qong_init_nor_mtd();
qong_init_fpga();
+ imx31_add_imx2_wdt(NULL);
}
static void __init qong_timer_init(void)
--
1.6.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox