* [PATCH] ARM: vexpress: initial device tree support
From: Mitch Bradley @ 2011-09-21 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921171545.GG2872@arm.com>
On 9/21/2011 7:15 AM, Dave Martin wrote:
> On Wed, Sep 21, 2011 at 11:37:54AM -0500, Rob Herring wrote:
>> On 09/21/2011 09:57 AM, Grant Likely wrote:
>>> On Wed, Sep 21, 2011 at 7:24 AM, Rob Herring<robherring2@gmail.com> wrote:
>>>> On 09/21/2011 04:19 AM, Dave Martin wrote:
>>>>> * arm,amba-bus -- widely used by other boards and patchsets, but
>>>>> seems not to be documented.
>>>>>
>>>>
>>>> This should be dropped. There's not really any bus component to an amba
>>>> bus. All the probing info is within the primecell peripherals.
>>>
>>> No, if it is an AMBA bus, then it is entirely appropriate to declare
>>> it as an amba bus, but to also be compatible with "simple-bus". In
>>> fact, it would be better to use a compatible string that specifies the
>>> specific implementation of AMBA bus since there are several versions
>>> of the spec.
>>
>> And type of AMBA bus as the spec includes AXI, AHB, and APB. None of
>> which have any sort of programmability or software view.
>>
>> If this is required, then the policy should be simple-bus should never
>> be allowed alone as every bus has some underlying type. Seems like
>> overkill for buses like this.
>
> The key question is _where_ to draw the line between generic and specific.
> By definition, the DT can never be a comprehensive description of the
> hardware -- rather a good DT is a description of those details of the hardware
> which could relevant to any hypothetical OS.
>
> The flipside is that details which were thought to be irrelevant at
> design/implementation time can turn out to be relevant in practice, due
> to errata and implementation issues etc. So taking the description slightly
> beyond what the OS needs to know can still have some merit.
>
>
> I still don't know how to say where the line should be drawn in this particular
> case though.
Here are some criteria:
If the controller for the bus itself has registers, include the bus node
If it is possible to plug new stuff into the bus, include the bus node
If the base address for the bus can be changed, thereby changing all the
addresses of its subordinates by the same offset, include the bus node
(this usually goes along with "has registers".)
ARM buses typically don't have any of those attributes, but there are
some weaker criteria that can be used to justify including a bus node.
The SoC on which I'm currently working has some peripherals on AXI and
others on APB. That doesn't matter from that addressing standpoint -
the individual peripherals can each be viewed as having an address, end
of story - but it does matter from a power management standpoint. The
clock tree is quite related to the bus layout. Including bus nodes in
the device tree might provide useful place-holders for properties
describing power or clock domains.
So, on the whole, I'm in favor of including bus nodes for ARM standard
buses. There is little down side to doing so, and a fair chance that it
might come in handy in the future.
>
> Cheers
> ---Dave
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply
* DT vs ARM static mappings
From: Nicolas Pitre @ 2011-09-21 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316519479.4611.150.camel@hornet.cambridge.arm.com>
On Tue, 20 Sep 2011, Pawel Moll wrote:
> ARM machine description contains a "map_io" method, which is used to
> create static memory mappings (using iotable_init() function) for things
> like peripherals or SRAMs. At least that's the theory, because most of
> the platforms are doing much more stuff there, like clocking/GPIOs/UARTs
> initialization, hardware probing etc.
No, most of them don't. Maybe a few cases do for historical reasons,
but there are other hooks now to link probing and initialization code
to.
The static mappings should be just that: static. Most things should be
dynamically mapped instead. With the series I'm working on, everybody
will get the benefit of a static mapping when one is available even if
the dynamic mapping interface like ioremap() is used. So having a bunch
of static mappings is not bad, especially if they are easy. But you
should defer as much hardware probing as possible after the memory is
initialized and the standard interfaces are available, keeping reliance
on direct access to static mappings as small as possible.
> Now the Versatile Express platform: it consists of a motherboard with a
> set of peripherals and a processor daughterboard (core tile), both
> connected via a static memory bus, which is mapped into processor's
> physical address space. The motherboard can be shared between different
> types of the tiles (eg. A9, A5, A15 etc.). The present one is probed byt
> he motherboard firmware and exposed in "system registers".
>
> Everything is fine so far. The interesting part starts here:
>
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0447e/CACIHGFE.html
>
> In brief, depending on the configuration, the system can have one of
> two, totally different, memory maps (please, do spare me the "but why
> did they do that" comments - not my idea nor decision, I just have to
> live with this ;-), depending on the core tile being used.
>
> In result, the static mapping as defined currently in
> arch/arm/mach-vexpress/v2m.c for A9 variant:
>
> #define V2M_PA_CS7 0x10000000
>
> static struct map_desc v2m_io_desc[] __initdata = {
> {
> .virtual = __MMIO_P2V(V2M_PA_CS7),
> .pfn = __phys_to_pfn(V2M_PA_CS7),
> .length = SZ_128K,
> .type = MT_DEVICE,
> },
> };
>
> is no longer valid for A5/A15. It would rather look like this:
>
> #define V2M_PA_CS3 0x1c000000
>
> static struct map_desc v2m_io_desc[] __initdata = {
> {
> .virtual = __MMIO_P2V(V2M_PA_CS3),
> .pfn = __phys_to_pfn(V2M_PA_CS3),
> .length = SZ_2M,
> .type = MT_DEVICE,
> },
> };
>
> Not only the peripherals base address is changed but also "internal"
> alignment, thus offsets to peripherals. Some of them are not being
> ioremap()ed, but directly used via the static mapping and MMIO_P2V macro
> (like "readl(MMIO_P2V(V2M_SYS_PROCID0))" in v2m_populate_ct_desc(void)
> function). For example, these two:
>
> #define V2M_SYSREGS (V2M_PA_CS7 + 0x00000000)
> #define V2M_SYSCTL (V2M_PA_CS7 + 0x00001000)
>
> would have to become:
>
> #define V2M_SYSREGS (V2M_PA_CS3 + 0x00010000)
> #define V2M_SYSCTL (V2M_PA_CS3 + 0x00020000)
Your best bet would probably consist of keeping the virtual address
constant while the physical address is variable. Adjusting the .pfn
field in the v2m_io_desc table right before calling iotable_init()
should be fine. Alternatively you could have two such tables and select
the right one at run time. The io_p2v macro doesn't make any sense
anymore in that context so it should be eliminated, and keeping only a
minimum set of fixed virtual addresses for the peripherals that can't
wait until ioremap is available should be fine.
Of course you should use the largest alignment for the same peripheral
mapping.
[...]
> To my mind it looked like the whole mechanism was not flexible enough,
> so I wanted to explore other options...
>
> The obvious one was to describe the required static mapping in the DTS.
> I don't like this idea, though. It can hardly be called "hardware
> description". Besides, what node would carry such data? "chosen"?
> Hardly...
>
> Would it contain a "regs" property with the physical address and
> "virtual-reg" with the virtual one? Again, doesn't sound right to me
> (especially the virtual bit, however the virtual address could be common
> between different variants and be defined in the board support code, not
> the DTS).
That's what I'm suggesting: keep the virtual addresses constant, and
adjust the static mapping's physical address accordingly. But never
should virtual addresses be part of DT as this is just an implementation
detail.
And if static mappings are a problem, then try to live without them as
much as possible. Again there is no reason you should be doing too much
hardware probing at .map_io time.
Nicolas
^ permalink raw reply
* [PATCH 3/3] ARM: gic: add OF based initialization
From: Rob Herring @ 2011-09-21 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E7A1BCA.1090006@ti.com>
Benoit,
On 09/21/2011 12:15 PM, Cousson, Benoit wrote:
> Hi Rob,
>
> I'm testing that series with OMAP4 but have some issues for the moment :-(
>
> [ 0.000000] WARNING: at kernel/irq/irqdomain.c:34 gic_of_init+0x10c/0x180()
> [ 0.000000] error: irq_desc already assigned to a domain
> [ 0.000000] Modules linked in:
> [ 0.000000] [<c001b284>] (unwind_backtrace+0x0/0xf0) from [<c0051c34>] (warn_slowpath_common+0x4c/0x64)
> [ 0.000000] [<c0051c34>] (warn_slowpath_common+0x4c/0x64) from [<c0051ce0>] (warn_slowpath_fmt+0x30/0x40)
> [ 0.000000] [<c0051ce0>] (warn_slowpath_fmt+0x30/0x40) from [<c05f6874>] (gic_of_init+0x10c/0x180)
> [ 0.000000] [<c05f6874>] (gic_of_init+0x10c/0x180) from [<c05fa2e0>] (omap_gic_of_init+0x8/0x28)
> [ 0.000000] [<c05fa2e0>] (omap_gic_of_init+0x8/0x28) from [<c0616b44>] (of_irq_init+0x148/0x28c)
> [ 0.000000] [<c0616b44>] (of_irq_init+0x148/0x28c) from [<c05f3074>] (init_IRQ+0x14/0x1c)
> [ 0.000000] [<c05f3074>] (init_IRQ+0x14/0x1c) from [<c05f0650>] (start_kernel+0x184/0x2fc)
> [ 0.000000] [<c05f0650>] (start_kernel+0x184/0x2fc) from [<80008040>] (0x80008040)
>
> I'm not super familiar with all the irq stuff but I'm wondering if there is not something wrong with the test that print that message:
>
> void irq_domain_add(struct irq_domain *domain)
> {
> struct irq_data *d;
> int hwirq;
>
> /*
> * This assumes that the irq_domain owner has already allocated
> * the irq_descs. This block will be removed when support for dynamic
> * allocation of irq_descs is added to irq_domain.
> */
> for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
> d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
> if (d || d->domain) {
> /* things are broken; just report, don't clean up */
> WARN(1, "error: irq_desc already assigned to a domain");
> return;
> }
> [...]
>
> Is the (d || d->domain) correct? Shouldn't it be (d && d->domain)?
>
> But since that used to work properly, I have some doubt. Moreover the driver will not even get the proper interrupt later...
>
> Do you have any clue?
I fixed that in the prior series and tglx picked it up, so I did not
repost. It should hit mainline for 3.1, but I haven't verified if it is
in yet. Sorry for the confusion, I should have mentioned that.
Rob
^ permalink raw reply
* [GIT PULL] OMAP: omap_device cleanup for v3.2
From: Tony Lindgren @ 2011-09-21 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y5xps6kv.fsf@ti.com>
* Kevin Hilman <khilman@ti.com> [110915 16:23]:
> Kevin Hilman <khilman@ti.com> writes:
>
> > Please pull this omap_device cleanup series for v3.2. This sets the
> > groundwork for Benoit's DT infrastructure work.
>
> Turns out this series has a dependency on a patch[1] in Russell's
> for-next branch.
>
> Russell, any chance of picking this patch into your devel-stable so we
> have a fixed point to merge with?
Or maybe Kevin can add it to his series instead?
Tony
> [1]
> commit 456f69c544d4298e921dc0c606492cdbaa60b34b
> Author: Kevin Hilman <khilman@deeprootsystems.com>
> Date: Tue Sep 6 21:04:10 2011 +0100
>
> ARM: 7082/1: platform_device: pdev_archdata: add omap_device pointer
>
> Add omap_device pointer to the ARM-specific arch data in the
> platform_device. This will be used to attach OMAP-specific
> device-data to the platform device with device lifetime.
>
> Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/2] mmc: clarifications on host.post_req()
From: Chris Ball @ 2011-09-21 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314624959-4634-1-git-send-email-per.forlin@linaro.org>
Hi Per,
On Mon, Aug 29 2011, Per Forlin wrote:
> Fixes for 3.1.
> This patchset doesn't fix any bugs in 3.1 but it improves the documentation
> in order to prevent new bugs.
I've merged this into mmc-next now, but I'm planning on sending it for
3.2 instead of 3.1 at this point; hope that's okay.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [GIT PULL] OMAP: omap_device cleanup for v3.2
From: Kevin Hilman @ 2011-09-21 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921182051.GH2937@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Kevin Hilman <khilman@ti.com> [110915 16:23]:
>> Kevin Hilman <khilman@ti.com> writes:
>>
>> > Please pull this omap_device cleanup series for v3.2. This sets the
>> > groundwork for Benoit's DT infrastructure work.
>>
>> Turns out this series has a dependency on a patch[1] in Russell's
>> for-next branch.
>>
>> Russell, any chance of picking this patch into your devel-stable so we
>> have a fixed point to merge with?
>
> Or maybe Kevin can add it to his series instead?
Sure.
Russell, if you're OK with dropping it from your for-next, I'll just
add it to my series where the dependencies are.
Kevin
^ permalink raw reply
* [PATCH 0/2] mmc: clarifications on host.post_req()
From: Per Fridén Förlin @ 2011-09-21 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2k4913fzs.fsf@bob.laptop.org>
On Wed, Sep 21, 2011 at 8:30 PM, Chris Ball <cjb@laptop.org> wrote:
> Hi Per,
>
> On Mon, Aug 29 2011, Per Forlin wrote:
>> Fixes for 3.1.
>> This patchset doesn't fix any bugs in 3.1 but it improves the documentation
>> in order to prevent new bugs.
>
> I've merged this into mmc-next now, but I'm planning on sending it for
> 3.2 instead of 3.1 at this point; hope that's okay.
>
Fine with me.
Thanks,
Per
^ permalink raw reply
* [PATCH] mmc: sdhci-esdhc-imx: add basic imx6q usdhc support
From: Chris Ball @ 2011-09-21 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316424742-18502-1-git-send-email-shawn.guo@linaro.org>
Hi Shawn,
On Mon, Sep 19 2011, Shawn Guo wrote:
> This patch adds the basic support for imx6q usdhc, which is a
> derivative of esdhc controller.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Thanks, pushed to mmc-next for 3.2.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Konrad Rzeszutek Wilk @ 2011-09-21 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001501cc766b$0cb7eba0$2627c2e0$%dae@samsung.com>
> > > > > + DRM_ERROR("desired size is bigger then real
> size.\n");
> > > >
> > > > So .. you can't continue by just using the real size instead?
> > > >
> > >
> > > I am afraid I don't understand what you mean but I think that condition
> > is
> > > fine. size is a vm area to user-desired size and you could request
> > mapping
> > > as specific size. so it just check user-requested virtual space region
> > it
> > > bigger than allocated physical memory region to be mapped. if there is
> > my
> > > missing points, I would be happy to you give me your comments. thank
> you.
> >
> > I meant that you return -EINVAL. But I am wondering if it would be
> > possible
> > to just continue on, but ignore what the user specified.
> >
> > I think the issue here is that you are outputing the DRM_ERROR and
> > I am not sure if it is that neccessary. Perhaps DRM_DEBUG, but DRM_ERROR
> > just seems a bit.. heavy handed.
> >
>
> I thought this condition would be critical issue as user application should
> be terminated. is your wondering if user application could go ahead after
> mmap failed? this is just my view so I would be happy you to give me your
> advice. Thank you.
I think terminating the appliaction is the right thing. But the DRM_ERROR
is not neccessary.
^ permalink raw reply
* Git pull request: OMAP/Davinci debug-macro.S cleanups
From: Nicolas Pitre @ 2011-09-21 19:18 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, please pull:
git://git.linaro.org/people/nico/linux debug-macro
This is the OMAP and Davinci debug-macro cleanups I've done in the
course of the mach/memory.h removal series. The odds for that series to
be merged as is before the next merge window appear thin (I may only
speculate about the reasons at this point), but at least some of its
basic prerequisites may certainly go in this cycle, simplifying that
series for the next cycle.
The included patches were reviewed and tested by Tony and Kevin already.
If ever new SOC architectures are merged into arm-soc.git at this point,
you might have to fix their addruart macro to include an extra tmp
argument (nothing appears to require that now).
Nicolas Pitre (6):
ARM: add an extra temp register to the low level debugging addruart macro
ARM: plat-omap: make OMAP_UART_INFO into a relative offset
ARM: mach-omap1: clean up debug-macro.S
ARM: mach-omap2: clean up debug-macro.S
ARM: mach-davinci: make DAVINCI_UART_INFO into a relative offset
ARM: mach-davinci: clean up debug-macro.S
arch/arm/kernel/debug.S | 4 +-
arch/arm/kernel/head.S | 2 +-
arch/arm/mach-at91/include/mach/debug-macro.S | 2 +-
arch/arm/mach-clps711x/include/mach/debug-macro.S | 2 +-
arch/arm/mach-cns3xxx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-davinci/include/mach/debug-macro.S | 52 ++++-----
arch/arm/mach-davinci/include/mach/serial.h | 3 +-
arch/arm/mach-davinci/include/mach/uncompress.h | 7 +-
arch/arm/mach-dove/include/mach/debug-macro.S | 2 +-
arch/arm/mach-ebsa110/include/mach/debug-macro.S | 2 +-
arch/arm/mach-ep93xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-exynos4/include/mach/debug-macro.S | 2 +-
.../arm/mach-footbridge/include/mach/debug-macro.S | 4 +-
arch/arm/mach-gemini/include/mach/debug-macro.S | 2 +-
arch/arm/mach-h720x/include/mach/debug-macro.S | 2 +-
.../arm/mach-integrator/include/mach/debug-macro.S | 2 +-
arch/arm/mach-iop13xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-iop32x/include/mach/debug-macro.S | 2 +-
arch/arm/mach-iop33x/include/mach/debug-macro.S | 2 +-
arch/arm/mach-ixp2000/include/mach/debug-macro.S | 2 +-
arch/arm/mach-ixp23xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-ixp4xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-kirkwood/include/mach/debug-macro.S | 2 +-
arch/arm/mach-ks8695/include/mach/debug-macro.S | 2 +-
arch/arm/mach-l7200/include/mach/debug-macro.S | 2 +-
arch/arm/mach-lpc32xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-mmp/include/mach/debug-macro.S | 2 +-
arch/arm/mach-msm/include/mach/debug-macro.S | 4 +-
arch/arm/mach-mv78xx0/include/mach/debug-macro.S | 2 +-
arch/arm/mach-mxs/include/mach/debug-macro.S | 2 +-
arch/arm/mach-netx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-nomadik/include/mach/debug-macro.S | 2 +-
arch/arm/mach-omap1/include/mach/debug-macro.S | 48 ++++-----
arch/arm/mach-omap2/include/mach/debug-macro.S | 81 ++++++--------
arch/arm/mach-orion5x/include/mach/debug-macro.S | 2 +-
arch/arm/mach-pnx4008/include/mach/debug-macro.S | 2 +-
arch/arm/mach-prima2/include/mach/debug-macro.S | 2 +-
arch/arm/mach-pxa/include/mach/debug-macro.S | 2 +-
arch/arm/mach-realview/include/mach/debug-macro.S | 2 +-
arch/arm/mach-rpc/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s3c2410/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s3c64xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5p64x0/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5pc100/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5pv210/include/mach/debug-macro.S | 2 +-
arch/arm/mach-sa1100/include/mach/debug-macro.S | 2 +-
arch/arm/mach-shark/include/mach/debug-macro.S | 2 +-
arch/arm/mach-tegra/include/mach/debug-macro.S | 2 +-
arch/arm/mach-u300/include/mach/debug-macro.S | 2 +-
arch/arm/mach-ux500/include/mach/debug-macro.S | 2 +-
arch/arm/mach-versatile/include/mach/debug-macro.S | 2 +-
arch/arm/mach-vexpress/include/mach/debug-macro.S | 2 +-
arch/arm/mach-vt8500/include/mach/debug-macro.S | 2 +-
arch/arm/mach-zynq/include/mach/debug-macro.S | 2 +-
arch/arm/plat-mxc/include/mach/debug-macro.S | 2 +-
arch/arm/plat-omap/include/plat/serial.h | 6 +-
arch/arm/plat-omap/include/plat/uncompress.h | 8 +-
arch/arm/plat-spear/include/plat/debug-macro.S | 2 +-
arch/arm/plat-tcc/include/mach/debug-macro.S | 2 +-
59 files changed, 153 insertions(+), 162 deletions(-)
Nicolas
^ permalink raw reply
* [PATCH 3/3] ARM: gic: add OF based initialization
From: Cousson, Benoit @ 2011-09-21 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E7A252F.2000402@gmail.com>
On 9/21/2011 7:55 PM, Rob Herring wrote:
[...]
> I fixed that in the prior series and tglx picked it up, so I did not
> repost. It should hit mainline for 3.1, but I haven't verified if it is
> in yet. Sorry for the confusion, I should have mentioned that.
OK, I remember now as well that Thomas took patched 2 patches from your
previous one. And I found it:
https://lkml.org/lkml/2011/9/14/190
Now, I have to find why the twl interrupt-controller is not working
anymore even with that fix.
Almost-Tested-by: Benoit Cousson <b-cousson@ti.com>
Thanks,
Benoit
^ permalink raw reply
* [PATCH 1/3] arm/tegra: Move EN_VDD_1V05_GPIO to board-harmony.h
From: Stephen Warren @ 2011-09-21 19:33 UTC (permalink / raw)
To: linux-arm-kernel
This centralizes all GPIO naming in one header.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This patch series relies on various previous changes to the Tegra GPIO
driver that were made in Russell's GPIO tree. I assume this series will
go in through that tree.
This first patch is cleanup which makes the second slightly cleaner (no
need to edit board-harmony-pcie.c in patch 2). Usually, it would go in
through the Tegra tree, but I think it makes sense to merge these 3
patches all together in one place.
arch/arm/mach-tegra/board-harmony-pcie.c | 10 ++++------
arch/arm/mach-tegra/board-harmony.h | 1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-tegra/board-harmony-pcie.c b/arch/arm/mach-tegra/board-harmony-pcie.c
index 9c27b95..6db7d69 100644
--- a/arch/arm/mach-tegra/board-harmony-pcie.c
+++ b/arch/arm/mach-tegra/board-harmony-pcie.c
@@ -24,12 +24,10 @@
#include <mach/pinmux.h>
#include "board.h"
+#include "board-harmony.h"
#ifdef CONFIG_TEGRA_PCI
-/* GPIO 3 of the PMIC */
-#define EN_VDD_1V05_GPIO (TEGRA_NR_GPIOS + 2)
-
static int __init harmony_pcie_init(void)
{
struct regulator *regulator = NULL;
@@ -38,11 +36,11 @@ static int __init harmony_pcie_init(void)
if (!machine_is_harmony())
return 0;
- err = gpio_request(EN_VDD_1V05_GPIO, "EN_VDD_1V05");
+ err = gpio_request(TEGRA_GPIO_EN_VDD_1V05_GPIO, "EN_VDD_1V05");
if (err)
return err;
- gpio_direction_output(EN_VDD_1V05_GPIO, 1);
+ gpio_direction_output(TEGRA_GPIO_EN_VDD_1V05_GPIO, 1);
regulator = regulator_get(NULL, "pex_clk");
if (IS_ERR_OR_NULL(regulator))
@@ -68,7 +66,7 @@ err_pcie:
regulator_disable(regulator);
regulator_put(regulator);
err_reg:
- gpio_free(EN_VDD_1V05_GPIO);
+ gpio_free(TEGRA_GPIO_EN_VDD_1V05_GPIO);
return err;
}
diff --git a/arch/arm/mach-tegra/board-harmony.h b/arch/arm/mach-tegra/board-harmony.h
index d85142e..280d203 100644
--- a/arch/arm/mach-tegra/board-harmony.h
+++ b/arch/arm/mach-tegra/board-harmony.h
@@ -31,6 +31,7 @@
#define TEGRA_GPIO_HP_DET TEGRA_GPIO_PW2
#define TEGRA_GPIO_INT_MIC_EN TEGRA_GPIO_PX0
#define TEGRA_GPIO_EXT_MIC_EN TEGRA_GPIO_PX1
+#define TEGRA_GPIO_EN_VDD_1V05_GPIO HARMONY_GPIO_TPS6586X(2)
void harmony_pinmux_init(void);
int harmony_regulator_init(void);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] arm/tegra: Replace <mach/gpio.h> with <mach/gpio-tegra.h>
From: Stephen Warren @ 2011-09-21 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316633620-13184-1-git-send-email-swarren@nvidia.com>
This will eventually allow <mach/gpio.h> to be deleted. This mirrors
LinusW's recent equivalent work on various other ARM platforms.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/mach-tegra/board-harmony.h | 2 +
arch/arm/mach-tegra/board-paz00.h | 2 +
arch/arm/mach-tegra/board-seaboard.h | 2 +
arch/arm/mach-tegra/board-trimslice.h | 2 +
arch/arm/mach-tegra/include/mach/gpio-tegra.h | 39 +++++++++++++++++++++++++
arch/arm/mach-tegra/include/mach/gpio.h | 39 -------------------------
arch/arm/mach-tegra/usb_phy.c | 1 +
drivers/gpio/gpio-tegra.c | 1 +
drivers/mmc/host/sdhci-tegra.c | 2 +
9 files changed, 51 insertions(+), 39 deletions(-)
create mode 100644 arch/arm/mach-tegra/include/mach/gpio-tegra.h
diff --git a/arch/arm/mach-tegra/board-harmony.h b/arch/arm/mach-tegra/board-harmony.h
index 280d203..139d96c 100644
--- a/arch/arm/mach-tegra/board-harmony.h
+++ b/arch/arm/mach-tegra/board-harmony.h
@@ -17,6 +17,8 @@
#ifndef _MACH_TEGRA_BOARD_HARMONY_H
#define _MACH_TEGRA_BOARD_HARMONY_H
+#include <mach/gpio-tegra.h>
+
#define HARMONY_GPIO_TPS6586X(_x_) (TEGRA_NR_GPIOS + (_x_))
#define HARMONY_GPIO_WM8903(_x_) (HARMONY_GPIO_TPS6586X(4) + (_x_))
diff --git a/arch/arm/mach-tegra/board-paz00.h b/arch/arm/mach-tegra/board-paz00.h
index 86057c3..2dc1899 100644
--- a/arch/arm/mach-tegra/board-paz00.h
+++ b/arch/arm/mach-tegra/board-paz00.h
@@ -17,6 +17,8 @@
#ifndef _MACH_TEGRA_BOARD_PAZ00_H
#define _MACH_TEGRA_BOARD_PAZ00_H
+#include <mach/gpio-tegra.h>
+
/* SDCARD */
#define TEGRA_GPIO_SD1_CD TEGRA_GPIO_PV5
#define TEGRA_GPIO_SD1_WP TEGRA_GPIO_PH1
diff --git a/arch/arm/mach-tegra/board-seaboard.h b/arch/arm/mach-tegra/board-seaboard.h
index d06c334..4c45d4c 100644
--- a/arch/arm/mach-tegra/board-seaboard.h
+++ b/arch/arm/mach-tegra/board-seaboard.h
@@ -17,6 +17,8 @@
#ifndef _MACH_TEGRA_BOARD_SEABOARD_H
#define _MACH_TEGRA_BOARD_SEABOARD_H
+#include <mach/gpio-tegra.h>
+
#define SEABOARD_GPIO_TPS6586X(_x_) (TEGRA_NR_GPIOS + (_x_))
#define SEABOARD_GPIO_WM8903(_x_) (SEABOARD_GPIO_TPS6586X(4) + (_x_))
diff --git a/arch/arm/mach-tegra/board-trimslice.h b/arch/arm/mach-tegra/board-trimslice.h
index 7a7dee8..50f128d 100644
--- a/arch/arm/mach-tegra/board-trimslice.h
+++ b/arch/arm/mach-tegra/board-trimslice.h
@@ -17,6 +17,8 @@
#ifndef _MACH_TEGRA_BOARD_TRIMSLICE_H
#define _MACH_TEGRA_BOARD_TRIMSLICE_H
+#include <mach/gpio-tegra.h>
+
#define TRIMSLICE_GPIO_SD4_CD TEGRA_GPIO_PP1 /* mmc4 cd */
#define TRIMSLICE_GPIO_SD4_WP TEGRA_GPIO_PP2 /* mmc4 wp */
diff --git a/arch/arm/mach-tegra/include/mach/gpio-tegra.h b/arch/arm/mach-tegra/include/mach/gpio-tegra.h
new file mode 100644
index 0000000..87d37fd
--- /dev/null
+++ b/arch/arm/mach-tegra/include/mach/gpio-tegra.h
@@ -0,0 +1,39 @@
+/*
+ * arch/arm/mach-tegra/include/mach/gpio.h
+ *
+ * Copyright (C) 2010 Google, Inc.
+ *
+ * Author:
+ * Erik Gilling <konkers@google.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __MACH_TEGRA_GPIO_TEGRA_H
+#define __MACH_TEGRA_GPIO_TEGRA_H
+
+#include <linux/types.h>
+#include <mach/irqs.h>
+
+#define TEGRA_NR_GPIOS INT_GPIO_NR
+
+#define TEGRA_GPIO_TO_IRQ(gpio) (INT_GPIO_BASE + (gpio))
+
+struct tegra_gpio_table {
+ int gpio; /* GPIO number */
+ bool enable; /* Enable for GPIO at init? */
+};
+
+void tegra_gpio_config(struct tegra_gpio_table *table, int num);
+void tegra_gpio_enable(int gpio);
+void tegra_gpio_disable(int gpio);
+
+#endif
diff --git a/arch/arm/mach-tegra/include/mach/gpio.h b/arch/arm/mach-tegra/include/mach/gpio.h
index 7910d26..e69de29 100644
--- a/arch/arm/mach-tegra/include/mach/gpio.h
+++ b/arch/arm/mach-tegra/include/mach/gpio.h
@@ -1,39 +0,0 @@
-/*
- * arch/arm/mach-tegra/include/mach/gpio.h
- *
- * Copyright (C) 2010 Google, Inc.
- *
- * Author:
- * Erik Gilling <konkers@google.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#ifndef __MACH_TEGRA_GPIO_H
-#define __MACH_TEGRA_GPIO_H
-
-#include <linux/types.h>
-#include <mach/irqs.h>
-
-#define TEGRA_NR_GPIOS INT_GPIO_NR
-
-#define TEGRA_GPIO_TO_IRQ(gpio) (INT_GPIO_BASE + (gpio))
-
-struct tegra_gpio_table {
- int gpio; /* GPIO number */
- bool enable; /* Enable for GPIO at init? */
-};
-
-void tegra_gpio_config(struct tegra_gpio_table *table, int num);
-void tegra_gpio_enable(int gpio);
-void tegra_gpio_disable(int gpio);
-
-#endif
diff --git a/arch/arm/mach-tegra/usb_phy.c b/arch/arm/mach-tegra/usb_phy.c
index 88081bb..37576a7 100644
--- a/arch/arm/mach-tegra/usb_phy.c
+++ b/arch/arm/mach-tegra/usb_phy.c
@@ -28,6 +28,7 @@
#include <linux/usb/otg.h>
#include <linux/usb/ulpi.h>
#include <asm/mach-types.h>
+#include <mach/gpio-tegra.h>
#include <mach/usb_phy.h>
#include <mach/iomap.h>
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index df64536..6b65207 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -27,6 +27,7 @@
#include <asm/mach/irq.h>
+#include <mach/gpio-tegra.h>
#include <mach/iomap.h>
#include <mach/suspend.h>
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 67176af..067a4cd 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -25,6 +25,8 @@
#include <linux/module.h>
#include <asm/gpio.h>
+
+#include <mach/gpio-tegra.h>
#include <mach/sdhci.h>
#include "sdhci-pltfm.h"
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] arm/tegra: Move "gpio-names.h" into <mach/gpio-tegra.h>
From: Stephen Warren @ 2011-09-21 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316633620-13184-1-git-send-email-swarren@nvidia.com>
This centralizes all SoC-level GPIO-related definitions into a single
header file.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/mach-tegra/board-harmony-pinmux.c | 1 -
arch/arm/mach-tegra/board-harmony.c | 1 -
arch/arm/mach-tegra/board-paz00-pinmux.c | 1 -
arch/arm/mach-tegra/board-paz00.c | 1 -
arch/arm/mach-tegra/board-seaboard-pinmux.c | 1 -
arch/arm/mach-tegra/board-seaboard.c | 1 -
arch/arm/mach-tegra/board-trimslice-pinmux.c | 1 -
arch/arm/mach-tegra/board-trimslice.c | 2 -
arch/arm/mach-tegra/devices.c | 2 +-
arch/arm/mach-tegra/gpio-names.h | 247 -------------------------
arch/arm/mach-tegra/include/mach/gpio-tegra.h | 225 ++++++++++++++++++++++
11 files changed, 226 insertions(+), 257 deletions(-)
delete mode 100644 arch/arm/mach-tegra/gpio-names.h
diff --git a/arch/arm/mach-tegra/board-harmony-pinmux.c b/arch/arm/mach-tegra/board-harmony-pinmux.c
index 4d63e2e..4191a9f 100644
--- a/arch/arm/mach-tegra/board-harmony-pinmux.c
+++ b/arch/arm/mach-tegra/board-harmony-pinmux.c
@@ -18,7 +18,6 @@
#include <linux/gpio.h>
#include <mach/pinmux.h>
-#include "gpio-names.h"
#include "board-harmony.h"
static struct tegra_pingroup_config harmony_pinmux[] = {
diff --git a/arch/arm/mach-tegra/board-harmony.c b/arch/arm/mach-tegra/board-harmony.c
index 5835225..1e6a20f 100644
--- a/arch/arm/mach-tegra/board-harmony.c
+++ b/arch/arm/mach-tegra/board-harmony.c
@@ -42,7 +42,6 @@
#include "board-harmony.h"
#include "clock.h"
#include "devices.h"
-#include "gpio-names.h"
static struct plat_serial8250_port debug_uart_platform_data[] = {
{
diff --git a/arch/arm/mach-tegra/board-paz00-pinmux.c b/arch/arm/mach-tegra/board-paz00-pinmux.c
index 2225769..39a4858 100644
--- a/arch/arm/mach-tegra/board-paz00-pinmux.c
+++ b/arch/arm/mach-tegra/board-paz00-pinmux.c
@@ -18,7 +18,6 @@
#include <linux/gpio.h>
#include <mach/pinmux.h>
-#include "gpio-names.h"
#include "board-paz00.h"
static struct tegra_pingroup_config paz00_pinmux[] = {
diff --git a/arch/arm/mach-tegra/board-paz00.c b/arch/arm/mach-tegra/board-paz00.c
index c888b0e..ae94f79 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -42,7 +42,6 @@
#include "board-paz00.h"
#include "clock.h"
#include "devices.h"
-#include "gpio-names.h"
static struct plat_serial8250_port debug_uart_platform_data[] = {
{
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index 74f78b7..fbfeb9c 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -19,7 +19,6 @@
#include <mach/pinmux.h>
#include <mach/pinmux-t2.h>
-#include "gpio-names.h"
#include "board-seaboard.h"
#define DEFAULT_DRIVE(_name) \
diff --git a/arch/arm/mach-tegra/board-seaboard.c b/arch/arm/mach-tegra/board-seaboard.c
index bf13ea3..53e6ce6 100644
--- a/arch/arm/mach-tegra/board-seaboard.c
+++ b/arch/arm/mach-tegra/board-seaboard.c
@@ -39,7 +39,6 @@
#include "board-seaboard.h"
#include "clock.h"
#include "devices.h"
-#include "gpio-names.h"
static struct plat_serial8250_port debug_uart_platform_data[] = {
{
diff --git a/arch/arm/mach-tegra/board-trimslice-pinmux.c b/arch/arm/mach-tegra/board-trimslice-pinmux.c
index bcb1916..b358aac 100644
--- a/arch/arm/mach-tegra/board-trimslice-pinmux.c
+++ b/arch/arm/mach-tegra/board-trimslice-pinmux.c
@@ -19,7 +19,6 @@
#include <mach/pinmux.h>
-#include "gpio-names.h"
#include "board-trimslice.h"
static __initdata struct tegra_pingroup_config trimslice_pinmux[] = {
diff --git a/arch/arm/mach-tegra/board-trimslice.c b/arch/arm/mach-tegra/board-trimslice.c
index e3ff88b..b0f77ea 100644
--- a/arch/arm/mach-tegra/board-trimslice.c
+++ b/arch/arm/mach-tegra/board-trimslice.c
@@ -37,8 +37,6 @@
#include "board.h"
#include "clock.h"
#include "devices.h"
-#include "gpio-names.h"
-
#include "board-trimslice.h"
static struct plat_serial8250_port debug_uart_platform_data[] = {
diff --git a/arch/arm/mach-tegra/devices.c b/arch/arm/mach-tegra/devices.c
index 57e35d2..a5ea0ac 100644
--- a/arch/arm/mach-tegra/devices.c
+++ b/arch/arm/mach-tegra/devices.c
@@ -25,11 +25,11 @@
#include <linux/i2c-tegra.h>
#include <linux/platform_data/tegra_usb.h>
#include <asm/pmu.h>
+#include <mach/gpio-tegra.h>
#include <mach/irqs.h>
#include <mach/iomap.h>
#include <mach/dma.h>
#include <mach/usb_phy.h>
-#include "gpio-names.h"
static struct resource i2c_resource1[] = {
[0] = {
diff --git a/arch/arm/mach-tegra/gpio-names.h b/arch/arm/mach-tegra/gpio-names.h
deleted file mode 100644
index f28220a..0000000
--- a/arch/arm/mach-tegra/gpio-names.h
+++ /dev/null
@@ -1,247 +0,0 @@
-/*
- * arch/arm/mach-tegra/include/mach/gpio-names.h
- *
- * Copyright (c) 2010 Google, Inc
- *
- * Author:
- * Erik Gilling <konkers@google.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#ifndef __MACH_TEGRA_GPIO_NAMES_H
-#define __MACH_TEGRA_GPIO_NAMES_H
-
-#define TEGRA_GPIO_PA0 0
-#define TEGRA_GPIO_PA1 1
-#define TEGRA_GPIO_PA2 2
-#define TEGRA_GPIO_PA3 3
-#define TEGRA_GPIO_PA4 4
-#define TEGRA_GPIO_PA5 5
-#define TEGRA_GPIO_PA6 6
-#define TEGRA_GPIO_PA7 7
-#define TEGRA_GPIO_PB0 8
-#define TEGRA_GPIO_PB1 9
-#define TEGRA_GPIO_PB2 10
-#define TEGRA_GPIO_PB3 11
-#define TEGRA_GPIO_PB4 12
-#define TEGRA_GPIO_PB5 13
-#define TEGRA_GPIO_PB6 14
-#define TEGRA_GPIO_PB7 15
-#define TEGRA_GPIO_PC0 16
-#define TEGRA_GPIO_PC1 17
-#define TEGRA_GPIO_PC2 18
-#define TEGRA_GPIO_PC3 19
-#define TEGRA_GPIO_PC4 20
-#define TEGRA_GPIO_PC5 21
-#define TEGRA_GPIO_PC6 22
-#define TEGRA_GPIO_PC7 23
-#define TEGRA_GPIO_PD0 24
-#define TEGRA_GPIO_PD1 25
-#define TEGRA_GPIO_PD2 26
-#define TEGRA_GPIO_PD3 27
-#define TEGRA_GPIO_PD4 28
-#define TEGRA_GPIO_PD5 29
-#define TEGRA_GPIO_PD6 30
-#define TEGRA_GPIO_PD7 31
-#define TEGRA_GPIO_PE0 32
-#define TEGRA_GPIO_PE1 33
-#define TEGRA_GPIO_PE2 34
-#define TEGRA_GPIO_PE3 35
-#define TEGRA_GPIO_PE4 36
-#define TEGRA_GPIO_PE5 37
-#define TEGRA_GPIO_PE6 38
-#define TEGRA_GPIO_PE7 39
-#define TEGRA_GPIO_PF0 40
-#define TEGRA_GPIO_PF1 41
-#define TEGRA_GPIO_PF2 42
-#define TEGRA_GPIO_PF3 43
-#define TEGRA_GPIO_PF4 44
-#define TEGRA_GPIO_PF5 45
-#define TEGRA_GPIO_PF6 46
-#define TEGRA_GPIO_PF7 47
-#define TEGRA_GPIO_PG0 48
-#define TEGRA_GPIO_PG1 49
-#define TEGRA_GPIO_PG2 50
-#define TEGRA_GPIO_PG3 51
-#define TEGRA_GPIO_PG4 52
-#define TEGRA_GPIO_PG5 53
-#define TEGRA_GPIO_PG6 54
-#define TEGRA_GPIO_PG7 55
-#define TEGRA_GPIO_PH0 56
-#define TEGRA_GPIO_PH1 57
-#define TEGRA_GPIO_PH2 58
-#define TEGRA_GPIO_PH3 59
-#define TEGRA_GPIO_PH4 60
-#define TEGRA_GPIO_PH5 61
-#define TEGRA_GPIO_PH6 62
-#define TEGRA_GPIO_PH7 63
-#define TEGRA_GPIO_PI0 64
-#define TEGRA_GPIO_PI1 65
-#define TEGRA_GPIO_PI2 66
-#define TEGRA_GPIO_PI3 67
-#define TEGRA_GPIO_PI4 68
-#define TEGRA_GPIO_PI5 69
-#define TEGRA_GPIO_PI6 70
-#define TEGRA_GPIO_PI7 71
-#define TEGRA_GPIO_PJ0 72
-#define TEGRA_GPIO_PJ1 73
-#define TEGRA_GPIO_PJ2 74
-#define TEGRA_GPIO_PJ3 75
-#define TEGRA_GPIO_PJ4 76
-#define TEGRA_GPIO_PJ5 77
-#define TEGRA_GPIO_PJ6 78
-#define TEGRA_GPIO_PJ7 79
-#define TEGRA_GPIO_PK0 80
-#define TEGRA_GPIO_PK1 81
-#define TEGRA_GPIO_PK2 82
-#define TEGRA_GPIO_PK3 83
-#define TEGRA_GPIO_PK4 84
-#define TEGRA_GPIO_PK5 85
-#define TEGRA_GPIO_PK6 86
-#define TEGRA_GPIO_PK7 87
-#define TEGRA_GPIO_PL0 88
-#define TEGRA_GPIO_PL1 89
-#define TEGRA_GPIO_PL2 90
-#define TEGRA_GPIO_PL3 91
-#define TEGRA_GPIO_PL4 92
-#define TEGRA_GPIO_PL5 93
-#define TEGRA_GPIO_PL6 94
-#define TEGRA_GPIO_PL7 95
-#define TEGRA_GPIO_PM0 96
-#define TEGRA_GPIO_PM1 97
-#define TEGRA_GPIO_PM2 98
-#define TEGRA_GPIO_PM3 99
-#define TEGRA_GPIO_PM4 100
-#define TEGRA_GPIO_PM5 101
-#define TEGRA_GPIO_PM6 102
-#define TEGRA_GPIO_PM7 103
-#define TEGRA_GPIO_PN0 104
-#define TEGRA_GPIO_PN1 105
-#define TEGRA_GPIO_PN2 106
-#define TEGRA_GPIO_PN3 107
-#define TEGRA_GPIO_PN4 108
-#define TEGRA_GPIO_PN5 109
-#define TEGRA_GPIO_PN6 110
-#define TEGRA_GPIO_PN7 111
-#define TEGRA_GPIO_PO0 112
-#define TEGRA_GPIO_PO1 113
-#define TEGRA_GPIO_PO2 114
-#define TEGRA_GPIO_PO3 115
-#define TEGRA_GPIO_PO4 116
-#define TEGRA_GPIO_PO5 117
-#define TEGRA_GPIO_PO6 118
-#define TEGRA_GPIO_PO7 119
-#define TEGRA_GPIO_PP0 120
-#define TEGRA_GPIO_PP1 121
-#define TEGRA_GPIO_PP2 122
-#define TEGRA_GPIO_PP3 123
-#define TEGRA_GPIO_PP4 124
-#define TEGRA_GPIO_PP5 125
-#define TEGRA_GPIO_PP6 126
-#define TEGRA_GPIO_PP7 127
-#define TEGRA_GPIO_PQ0 128
-#define TEGRA_GPIO_PQ1 129
-#define TEGRA_GPIO_PQ2 130
-#define TEGRA_GPIO_PQ3 131
-#define TEGRA_GPIO_PQ4 132
-#define TEGRA_GPIO_PQ5 133
-#define TEGRA_GPIO_PQ6 134
-#define TEGRA_GPIO_PQ7 135
-#define TEGRA_GPIO_PR0 136
-#define TEGRA_GPIO_PR1 137
-#define TEGRA_GPIO_PR2 138
-#define TEGRA_GPIO_PR3 139
-#define TEGRA_GPIO_PR4 140
-#define TEGRA_GPIO_PR5 141
-#define TEGRA_GPIO_PR6 142
-#define TEGRA_GPIO_PR7 143
-#define TEGRA_GPIO_PS0 144
-#define TEGRA_GPIO_PS1 145
-#define TEGRA_GPIO_PS2 146
-#define TEGRA_GPIO_PS3 147
-#define TEGRA_GPIO_PS4 148
-#define TEGRA_GPIO_PS5 149
-#define TEGRA_GPIO_PS6 150
-#define TEGRA_GPIO_PS7 151
-#define TEGRA_GPIO_PT0 152
-#define TEGRA_GPIO_PT1 153
-#define TEGRA_GPIO_PT2 154
-#define TEGRA_GPIO_PT3 155
-#define TEGRA_GPIO_PT4 156
-#define TEGRA_GPIO_PT5 157
-#define TEGRA_GPIO_PT6 158
-#define TEGRA_GPIO_PT7 159
-#define TEGRA_GPIO_PU0 160
-#define TEGRA_GPIO_PU1 161
-#define TEGRA_GPIO_PU2 162
-#define TEGRA_GPIO_PU3 163
-#define TEGRA_GPIO_PU4 164
-#define TEGRA_GPIO_PU5 165
-#define TEGRA_GPIO_PU6 166
-#define TEGRA_GPIO_PU7 167
-#define TEGRA_GPIO_PV0 168
-#define TEGRA_GPIO_PV1 169
-#define TEGRA_GPIO_PV2 170
-#define TEGRA_GPIO_PV3 171
-#define TEGRA_GPIO_PV4 172
-#define TEGRA_GPIO_PV5 173
-#define TEGRA_GPIO_PV6 174
-#define TEGRA_GPIO_PV7 175
-#define TEGRA_GPIO_PW0 176
-#define TEGRA_GPIO_PW1 177
-#define TEGRA_GPIO_PW2 178
-#define TEGRA_GPIO_PW3 179
-#define TEGRA_GPIO_PW4 180
-#define TEGRA_GPIO_PW5 181
-#define TEGRA_GPIO_PW6 182
-#define TEGRA_GPIO_PW7 183
-#define TEGRA_GPIO_PX0 184
-#define TEGRA_GPIO_PX1 185
-#define TEGRA_GPIO_PX2 186
-#define TEGRA_GPIO_PX3 187
-#define TEGRA_GPIO_PX4 188
-#define TEGRA_GPIO_PX5 189
-#define TEGRA_GPIO_PX6 190
-#define TEGRA_GPIO_PX7 191
-#define TEGRA_GPIO_PY0 192
-#define TEGRA_GPIO_PY1 193
-#define TEGRA_GPIO_PY2 194
-#define TEGRA_GPIO_PY3 195
-#define TEGRA_GPIO_PY4 196
-#define TEGRA_GPIO_PY5 197
-#define TEGRA_GPIO_PY6 198
-#define TEGRA_GPIO_PY7 199
-#define TEGRA_GPIO_PZ0 200
-#define TEGRA_GPIO_PZ1 201
-#define TEGRA_GPIO_PZ2 202
-#define TEGRA_GPIO_PZ3 203
-#define TEGRA_GPIO_PZ4 204
-#define TEGRA_GPIO_PZ5 205
-#define TEGRA_GPIO_PZ6 206
-#define TEGRA_GPIO_PZ7 207
-#define TEGRA_GPIO_PAA0 208
-#define TEGRA_GPIO_PAA1 209
-#define TEGRA_GPIO_PAA2 210
-#define TEGRA_GPIO_PAA3 211
-#define TEGRA_GPIO_PAA4 212
-#define TEGRA_GPIO_PAA5 213
-#define TEGRA_GPIO_PAA6 214
-#define TEGRA_GPIO_PAA7 215
-#define TEGRA_GPIO_PBB0 216
-#define TEGRA_GPIO_PBB1 217
-#define TEGRA_GPIO_PBB2 218
-#define TEGRA_GPIO_PBB3 219
-#define TEGRA_GPIO_PBB4 220
-#define TEGRA_GPIO_PBB5 221
-#define TEGRA_GPIO_PBB6 222
-#define TEGRA_GPIO_PBB7 223
-
-#endif
diff --git a/arch/arm/mach-tegra/include/mach/gpio-tegra.h b/arch/arm/mach-tegra/include/mach/gpio-tegra.h
index 87d37fd..b06b998 100644
--- a/arch/arm/mach-tegra/include/mach/gpio-tegra.h
+++ b/arch/arm/mach-tegra/include/mach/gpio-tegra.h
@@ -23,6 +23,231 @@
#include <linux/types.h>
#include <mach/irqs.h>
+#define TEGRA_GPIO_PA0 0
+#define TEGRA_GPIO_PA1 1
+#define TEGRA_GPIO_PA2 2
+#define TEGRA_GPIO_PA3 3
+#define TEGRA_GPIO_PA4 4
+#define TEGRA_GPIO_PA5 5
+#define TEGRA_GPIO_PA6 6
+#define TEGRA_GPIO_PA7 7
+#define TEGRA_GPIO_PB0 8
+#define TEGRA_GPIO_PB1 9
+#define TEGRA_GPIO_PB2 10
+#define TEGRA_GPIO_PB3 11
+#define TEGRA_GPIO_PB4 12
+#define TEGRA_GPIO_PB5 13
+#define TEGRA_GPIO_PB6 14
+#define TEGRA_GPIO_PB7 15
+#define TEGRA_GPIO_PC0 16
+#define TEGRA_GPIO_PC1 17
+#define TEGRA_GPIO_PC2 18
+#define TEGRA_GPIO_PC3 19
+#define TEGRA_GPIO_PC4 20
+#define TEGRA_GPIO_PC5 21
+#define TEGRA_GPIO_PC6 22
+#define TEGRA_GPIO_PC7 23
+#define TEGRA_GPIO_PD0 24
+#define TEGRA_GPIO_PD1 25
+#define TEGRA_GPIO_PD2 26
+#define TEGRA_GPIO_PD3 27
+#define TEGRA_GPIO_PD4 28
+#define TEGRA_GPIO_PD5 29
+#define TEGRA_GPIO_PD6 30
+#define TEGRA_GPIO_PD7 31
+#define TEGRA_GPIO_PE0 32
+#define TEGRA_GPIO_PE1 33
+#define TEGRA_GPIO_PE2 34
+#define TEGRA_GPIO_PE3 35
+#define TEGRA_GPIO_PE4 36
+#define TEGRA_GPIO_PE5 37
+#define TEGRA_GPIO_PE6 38
+#define TEGRA_GPIO_PE7 39
+#define TEGRA_GPIO_PF0 40
+#define TEGRA_GPIO_PF1 41
+#define TEGRA_GPIO_PF2 42
+#define TEGRA_GPIO_PF3 43
+#define TEGRA_GPIO_PF4 44
+#define TEGRA_GPIO_PF5 45
+#define TEGRA_GPIO_PF6 46
+#define TEGRA_GPIO_PF7 47
+#define TEGRA_GPIO_PG0 48
+#define TEGRA_GPIO_PG1 49
+#define TEGRA_GPIO_PG2 50
+#define TEGRA_GPIO_PG3 51
+#define TEGRA_GPIO_PG4 52
+#define TEGRA_GPIO_PG5 53
+#define TEGRA_GPIO_PG6 54
+#define TEGRA_GPIO_PG7 55
+#define TEGRA_GPIO_PH0 56
+#define TEGRA_GPIO_PH1 57
+#define TEGRA_GPIO_PH2 58
+#define TEGRA_GPIO_PH3 59
+#define TEGRA_GPIO_PH4 60
+#define TEGRA_GPIO_PH5 61
+#define TEGRA_GPIO_PH6 62
+#define TEGRA_GPIO_PH7 63
+#define TEGRA_GPIO_PI0 64
+#define TEGRA_GPIO_PI1 65
+#define TEGRA_GPIO_PI2 66
+#define TEGRA_GPIO_PI3 67
+#define TEGRA_GPIO_PI4 68
+#define TEGRA_GPIO_PI5 69
+#define TEGRA_GPIO_PI6 70
+#define TEGRA_GPIO_PI7 71
+#define TEGRA_GPIO_PJ0 72
+#define TEGRA_GPIO_PJ1 73
+#define TEGRA_GPIO_PJ2 74
+#define TEGRA_GPIO_PJ3 75
+#define TEGRA_GPIO_PJ4 76
+#define TEGRA_GPIO_PJ5 77
+#define TEGRA_GPIO_PJ6 78
+#define TEGRA_GPIO_PJ7 79
+#define TEGRA_GPIO_PK0 80
+#define TEGRA_GPIO_PK1 81
+#define TEGRA_GPIO_PK2 82
+#define TEGRA_GPIO_PK3 83
+#define TEGRA_GPIO_PK4 84
+#define TEGRA_GPIO_PK5 85
+#define TEGRA_GPIO_PK6 86
+#define TEGRA_GPIO_PK7 87
+#define TEGRA_GPIO_PL0 88
+#define TEGRA_GPIO_PL1 89
+#define TEGRA_GPIO_PL2 90
+#define TEGRA_GPIO_PL3 91
+#define TEGRA_GPIO_PL4 92
+#define TEGRA_GPIO_PL5 93
+#define TEGRA_GPIO_PL6 94
+#define TEGRA_GPIO_PL7 95
+#define TEGRA_GPIO_PM0 96
+#define TEGRA_GPIO_PM1 97
+#define TEGRA_GPIO_PM2 98
+#define TEGRA_GPIO_PM3 99
+#define TEGRA_GPIO_PM4 100
+#define TEGRA_GPIO_PM5 101
+#define TEGRA_GPIO_PM6 102
+#define TEGRA_GPIO_PM7 103
+#define TEGRA_GPIO_PN0 104
+#define TEGRA_GPIO_PN1 105
+#define TEGRA_GPIO_PN2 106
+#define TEGRA_GPIO_PN3 107
+#define TEGRA_GPIO_PN4 108
+#define TEGRA_GPIO_PN5 109
+#define TEGRA_GPIO_PN6 110
+#define TEGRA_GPIO_PN7 111
+#define TEGRA_GPIO_PO0 112
+#define TEGRA_GPIO_PO1 113
+#define TEGRA_GPIO_PO2 114
+#define TEGRA_GPIO_PO3 115
+#define TEGRA_GPIO_PO4 116
+#define TEGRA_GPIO_PO5 117
+#define TEGRA_GPIO_PO6 118
+#define TEGRA_GPIO_PO7 119
+#define TEGRA_GPIO_PP0 120
+#define TEGRA_GPIO_PP1 121
+#define TEGRA_GPIO_PP2 122
+#define TEGRA_GPIO_PP3 123
+#define TEGRA_GPIO_PP4 124
+#define TEGRA_GPIO_PP5 125
+#define TEGRA_GPIO_PP6 126
+#define TEGRA_GPIO_PP7 127
+#define TEGRA_GPIO_PQ0 128
+#define TEGRA_GPIO_PQ1 129
+#define TEGRA_GPIO_PQ2 130
+#define TEGRA_GPIO_PQ3 131
+#define TEGRA_GPIO_PQ4 132
+#define TEGRA_GPIO_PQ5 133
+#define TEGRA_GPIO_PQ6 134
+#define TEGRA_GPIO_PQ7 135
+#define TEGRA_GPIO_PR0 136
+#define TEGRA_GPIO_PR1 137
+#define TEGRA_GPIO_PR2 138
+#define TEGRA_GPIO_PR3 139
+#define TEGRA_GPIO_PR4 140
+#define TEGRA_GPIO_PR5 141
+#define TEGRA_GPIO_PR6 142
+#define TEGRA_GPIO_PR7 143
+#define TEGRA_GPIO_PS0 144
+#define TEGRA_GPIO_PS1 145
+#define TEGRA_GPIO_PS2 146
+#define TEGRA_GPIO_PS3 147
+#define TEGRA_GPIO_PS4 148
+#define TEGRA_GPIO_PS5 149
+#define TEGRA_GPIO_PS6 150
+#define TEGRA_GPIO_PS7 151
+#define TEGRA_GPIO_PT0 152
+#define TEGRA_GPIO_PT1 153
+#define TEGRA_GPIO_PT2 154
+#define TEGRA_GPIO_PT3 155
+#define TEGRA_GPIO_PT4 156
+#define TEGRA_GPIO_PT5 157
+#define TEGRA_GPIO_PT6 158
+#define TEGRA_GPIO_PT7 159
+#define TEGRA_GPIO_PU0 160
+#define TEGRA_GPIO_PU1 161
+#define TEGRA_GPIO_PU2 162
+#define TEGRA_GPIO_PU3 163
+#define TEGRA_GPIO_PU4 164
+#define TEGRA_GPIO_PU5 165
+#define TEGRA_GPIO_PU6 166
+#define TEGRA_GPIO_PU7 167
+#define TEGRA_GPIO_PV0 168
+#define TEGRA_GPIO_PV1 169
+#define TEGRA_GPIO_PV2 170
+#define TEGRA_GPIO_PV3 171
+#define TEGRA_GPIO_PV4 172
+#define TEGRA_GPIO_PV5 173
+#define TEGRA_GPIO_PV6 174
+#define TEGRA_GPIO_PV7 175
+#define TEGRA_GPIO_PW0 176
+#define TEGRA_GPIO_PW1 177
+#define TEGRA_GPIO_PW2 178
+#define TEGRA_GPIO_PW3 179
+#define TEGRA_GPIO_PW4 180
+#define TEGRA_GPIO_PW5 181
+#define TEGRA_GPIO_PW6 182
+#define TEGRA_GPIO_PW7 183
+#define TEGRA_GPIO_PX0 184
+#define TEGRA_GPIO_PX1 185
+#define TEGRA_GPIO_PX2 186
+#define TEGRA_GPIO_PX3 187
+#define TEGRA_GPIO_PX4 188
+#define TEGRA_GPIO_PX5 189
+#define TEGRA_GPIO_PX6 190
+#define TEGRA_GPIO_PX7 191
+#define TEGRA_GPIO_PY0 192
+#define TEGRA_GPIO_PY1 193
+#define TEGRA_GPIO_PY2 194
+#define TEGRA_GPIO_PY3 195
+#define TEGRA_GPIO_PY4 196
+#define TEGRA_GPIO_PY5 197
+#define TEGRA_GPIO_PY6 198
+#define TEGRA_GPIO_PY7 199
+#define TEGRA_GPIO_PZ0 200
+#define TEGRA_GPIO_PZ1 201
+#define TEGRA_GPIO_PZ2 202
+#define TEGRA_GPIO_PZ3 203
+#define TEGRA_GPIO_PZ4 204
+#define TEGRA_GPIO_PZ5 205
+#define TEGRA_GPIO_PZ6 206
+#define TEGRA_GPIO_PZ7 207
+#define TEGRA_GPIO_PAA0 208
+#define TEGRA_GPIO_PAA1 209
+#define TEGRA_GPIO_PAA2 210
+#define TEGRA_GPIO_PAA3 211
+#define TEGRA_GPIO_PAA4 212
+#define TEGRA_GPIO_PAA5 213
+#define TEGRA_GPIO_PAA6 214
+#define TEGRA_GPIO_PAA7 215
+#define TEGRA_GPIO_PBB0 216
+#define TEGRA_GPIO_PBB1 217
+#define TEGRA_GPIO_PBB2 218
+#define TEGRA_GPIO_PBB3 219
+#define TEGRA_GPIO_PBB4 220
+#define TEGRA_GPIO_PBB5 221
+#define TEGRA_GPIO_PBB6 222
+#define TEGRA_GPIO_PBB7 223
+
#define TEGRA_NR_GPIOS INT_GPIO_NR
#define TEGRA_GPIO_TO_IRQ(gpio) (INT_GPIO_BASE + (gpio))
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2 v7] pinmux: add a driver for the U300 pinmux
From: Stephen Warren @ 2011-09-21 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY5ETbJxSpwJL-7KZhjOnhwrdT1=djwByek75ye=S9L9w@mail.gmail.com>
Linus Walleij wrote at Wednesday, September 21, 2011 2:25 AM:
> On Wed, Sep 21, 2011 at 12:15 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > Linus Walleij wrote at Friday, September 16, 2011 6:14 AM:
> >> + ? ? for (i = 0; i < ARRAY_SIZE(u300_mux_hogs); i++) {
> >> + ? ? ? ? ? ? struct pinmux *pmx;
> >> + ? ? ? ? ? ? int ret;
> >> +
> >> + ? ? ? ? ? ? pmx = pinmux_get(u300_mux_hogs[i].dev, NULL);
> >> + ? ? ? ? ? ? if (IS_ERR(pmx)) {
> >> + ? ? ? ? ? ? ? ? ? ? pr_err("u300: could not get pinmux hog %s\n",
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?u300_mux_hogs[i].name);
> >> + ? ? ? ? ? ? ? ? ? ? continue;
> >> + ? ? ? ? ? ? }
> >> + ? ? ? ? ? ? ret = pinmux_enable(pmx);
> >> + ? ? ? ? ? ? if (ret) {
> >> + ? ? ? ? ? ? ? ? ? ? pr_err("u300: could enable pinmux hog %s\n",
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?u300_mux_hogs[i].name);
> >> + ? ? ? ? ? ? ? ? ? ? continue;
> >> + ? ? ? ? ? ? }
> >> + ? ? ? ? ? ? u300_mux_hogs[i].pmx = pmx;
> >> + ? ? }
> >> + ? ? return 0;
> >> +}
> >> +subsys_initcall(u300_pinmux_fetch);
> >
> > Why not just have the pinmux core support hogging on non-"system" mapping
> > entries; then everything I quoted above except u300_pinmux_map[] could
> > be deleted, and the "hog" flag set on the last 3 u300_pinmux_map[] entries.
>
> Very good question, luckily I have a good answer.
>
> There is no way for the pinmux core to traverse the system and look
> up the apropriate struct device * pointers.
It's unclear to me why that would be needed.
For non-system mappings, either the device-driver in question will be
get'ing and enabling them (this case isn't relevant to this discussion),
or they'll be hogged. In the hog case, I doubt anything would ever want
to disable them and switch the device to a different mapping entry; if
that were the case, the entries shouldn't be hogged, but get/enabled by
the device anyway. Hence, I don't see the need for an activation of a
hog'd non-system mapping entry to care about the device fields that are
in the mapping table at all; they could just be ignored couldn't they?
> When/if we have device tree support, I think this will be possible, then I
> will be able to have the pinmux hog look up devices from device tree
> and hog their pinmux.
>
> At that point we'll likely have the mapping in the device tree too and
> the core does not need to be involved at all.
>
> What I could do right now is add some open-ended function like
> pinmux_hog_device_pinmuxes(struct device **devices);
> that can take an array of devices and hog their respective
> pinmuxes in the hog list. Do you think it's a good idea?
--
nvpublic
^ permalink raw reply
* [PATCH 1/2] drivers: create a pin control subsystem v7
From: Stephen Warren @ 2011-09-21 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZyhkydTutHXfry_dUPK_Ts_jq+5VHcr8XdgrHSExTyww@mail.gmail.com>
Linus Walleij wrote at Wednesday, September 21, 2011 3:17 AM:
> On Tue, Sep 20, 2011 at 11:58 PM, Stephen Warren <swarren@nvidia.com> wrote:
> > Linus Walleij wrote at Friday, September 16, 2011 6:13 AM:
> >> This creates a subsystem for handling of pin control devices.
> >> These are devices that control different aspects of package
> >> pins.
> >
> > I've read through the documentation and header files, but not the .c files,
> > and this looks almost perfect as far as I can tell right now. I'll try to
> > review the .c files sometime too.
>
> Great, I'm hunting your Acked-by/Reviewed-by ...
Very close; I was just holding off until we resolved the discussion on
hog'd non-system mapping table entries, and I figured I'd wait until v8
which presumably would delete the pinmux_config function from the header?
> I will likely request inclusion into linux-next soon-ish.
>
> > I just have one comment:
> >
> >> diff --git a/include/linux/pinctrl/pinmux.h b/include/linux/pinctrl/pinmux.h
> > ...
> >> +/* External interface to pinmux */
> >> +extern int pinmux_request_gpio(unsigned gpio);
> >> +extern void pinmux_free_gpio(unsigned gpio);
> >> +extern struct pinmux * __must_check pinmux_get(struct device *dev, const char *name);
> >> +extern void pinmux_put(struct pinmux *pmx);
> >> +extern int pinmux_enable(struct pinmux *pmx);
> >> +extern void pinmux_disable(struct pinmux *pmx);
> >> +extern int pinmux_config(struct pinmux *pmx, u16 param, unsigned long *data);
> >
> > That definition of pinmux_config doesn't seem as useful as it could be;
>
> It should be removed. It's just there in the header file, I killed off
> the implementation because specific control of a mux doesn't make
> sense. We want to do stuff to pin groups directly, not related to
> muxing, so that kind of thing needs to be in the generic pinctrl
> interface.
OK.
> > I'd like the ability to execute pinmux_config on a /named/ group, and I
> > can certainly see a use-case for applying it to /named/ pins too.
>
> That sounds correct to me.
>
> To abstract things the stuff we can do with the group should be
> something enumerated too. So:
>
> pinctrl_config_group(const char *pinctrl_device, const char *group,
> const char *mode);
> pinctrl_config_pin(const char *pinctrl_device, int pin, const char *mode);
>
> So the driver need an API to enumerate pin and group modes.
>
> I might want to save this thing for post-merge of the basic API and
> pinmux stuff though so we don't try to push too much upfront
> design at once.
Yes, adding in a replacement _config API can certainly be a later patch.
One comment on the API above: I think you want "mode" (or "setting"?)
/and/ a value parameter; Tegra's pull strength definition for example
is:
enum tegra_pull_strength {
TEGRA_PULL_0 = 0,
TEGRA_PULL_1,
// ... (every value in between)
TEGRA_PULL_30,
TEGRA_PULL_31,
TEGRA_MAX_PULL,
};
And it seems better to represent that as ("pull", 0) ... ("pull", 31) than
"pull0" .. "pull31" such that the value needs to be parsed out of the "mode"
string somehow by the driver.
--
nvpublic
^ permalink raw reply
* [PATCH 3/3] arm/tegra: Move "gpio-names.h" into <mach/gpio-tegra.h>
From: Olof Johansson @ 2011-09-21 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316633620-13184-3-git-send-email-swarren@nvidia.com>
Hi,
On Wed, Sep 21, 2011 at 12:33 PM, Stephen Warren <swarren@nvidia.com> wrote:
> This centralizes all SoC-level GPIO-related definitions into a single
> header file.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>
> ?arch/arm/mach-tegra/gpio-names.h ? ? ? ? ? ? ?| ?247 -------------------------
> ?arch/arm/mach-tegra/include/mach/gpio-tegra.h | ?225 ++++++++++++++++++++++
> ?11 files changed, 226 insertions(+), 257 deletions(-)
> ?delete mode 100644 arch/arm/mach-tegra/gpio-names.h
The main reason that gpio-names.h was only in the mach directory and
not under include in the first place, is to discourage use outside of
the base platform code and board definitions.
There should be no need for drivers and non-mach-tegra code to use the
file, so doing a current-directory include of it should be OK. Or do
you have other plans for it?
-Olof
^ permalink raw reply
* [PATCH 1/3] arm/tegra: Move EN_VDD_1V05_GPIO to board-harmony.h
From: Olof Johansson @ 2011-09-21 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316633620-13184-1-git-send-email-swarren@nvidia.com>
On Wed, Sep 21, 2011 at 12:33 PM, Stephen Warren <swarren@nvidia.com> wrote:
> This centralizes all GPIO naming in one header.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Olof Johansson <olof@lixom.net>
> ---
> This patch series relies on various previous changes to the Tegra GPIO
> driver that were made in Russell's GPIO tree. I assume this series will
> go in through that tree.
>
> This first patch is cleanup which makes the second slightly cleaner (no
> need to edit board-harmony-pcie.c in patch 2). Usually, it would go in
> through the Tegra tree, but I think it makes sense to merge these 3
> patches all together in one place.
Works for me. Or I could stage it in a topic branch that would be
merged after Russell's GPIO tree.
Russell, Arnd, got any preferences for one or the other?
-Olof
^ permalink raw reply
* [PATCH 2/3] arm/tegra: Replace <mach/gpio.h> with <mach/gpio-tegra.h>
From: Olof Johansson @ 2011-09-21 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316633620-13184-2-git-send-email-swarren@nvidia.com>
On Wed, Sep 21, 2011 at 12:33 PM, Stephen Warren <swarren@nvidia.com> wrote:
> This will eventually allow <mach/gpio.h> to be deleted. This mirrors
> LinusW's recent equivalent work on various other ARM platforms.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* [PATCH 49/57] video: irq: Remove IRQF_DISABLED
From: David Brown @ 2011-09-21 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316597339-29861-50-git-send-email-yong.zhang0@gmail.com>
On Wed, Sep 21, 2011 at 05:28:50PM +0800, Yong Zhang wrote:
> Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> ---
> drivers/video/msm/mddi.c | 2 +-
> drivers/video/msm/mdp.c | 2 +-
Acked-by: David Brown <davidb@codeaurora.org>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 3/3] ARM: gic: add OF based initialization
From: Cousson, Benoit @ 2011-09-21 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E7A3AF0.1020809@ti.com>
On 9/21/2011 9:28 PM, Cousson, Benoit wrote:
> On 9/21/2011 7:55 PM, Rob Herring wrote:
>
> [...]
>
>> I fixed that in the prior series and tglx picked it up, so I did not
>> repost. It should hit mainline for 3.1, but I haven't verified if it is
>> in yet. Sorry for the confusion, I should have mentioned that.
>
> OK, I remember now as well that Thomas took patched 2 patches from your
> previous one. And I found it:
> https://lkml.org/lkml/2011/9/14/190
>
> Now, I have to find why the twl interrupt-controller is not working
> anymore even with that fix.
This is much better with the proper #interrupt-cells size:-)
> Almost-Tested-by: Benoit Cousson<b-cousson@ti.com>
Tested-by: Benoit Cousson<b-cousson@ti.com>
With a still very limited number of OMAP4 peripherals for the moment.
Regards,
Benoit
^ permalink raw reply
* [PATCH 3/3] arm/tegra: Move "gpio-names.h" into <mach/gpio-tegra.h>
From: Stephen Warren @ 2011-09-21 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhdkrtjvXWHhbLSj804s+CzTthn_hrGafp5K=Va5MTZ=w@mail.gmail.com>
Olof Johansson wrote at Wednesday, September 21, 2011 2:15 PM:
> On Wed, Sep 21, 2011 at 12:33 PM, Stephen Warren <swarren@nvidia.com> wrote:
> > This centralizes all SoC-level GPIO-related definitions into a single
> > header file.
> >
> > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> >
> > ?arch/arm/mach-tegra/gpio-names.h ? ? ? ? ? ? ?| ?247 -------------------------
> > ?arch/arm/mach-tegra/include/mach/gpio-tegra.h | ?225 ++++++++++++++++++++++
> > ?11 files changed, 226 insertions(+), 257 deletions(-)
> > ?delete mode 100644 arch/arm/mach-tegra/gpio-names.h
>
> The main reason that gpio-names.h was only in the mach directory and
> not under include in the first place, is to discourage use outside of
> the base platform code and board definitions.
>
> There should be no need for drivers and non-mach-tegra code to use the
> file, so doing a current-directory include of it should be OK. Or do
> you have other plans for it?
My primary motivation was to bring Tegra into line with what appears to
be common practice amongst other ARM sub-architectures; many of
mach-$x/include/mach/gpio-$x.h define the GPIO names there.
Still, your argument is valid; I don't foresee a need to anything other
than mach-tegra/*.c to need the GPIO names file.
So, feel free to take/drop this patch as you desire.
--
nvpublic
^ permalink raw reply
* [PATCH v2 1/3] TI81XX: Prepare for addition of TI814X support
From: Tony Lindgren @ 2011-09-21 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316626735-5597-1-git-send-email-hemantp@ti.com>
* Hemant Pedanekar <hemantp@ti.com> [110921 10:05]:
> --- a/arch/arm/mach-omap2/board-ti8168evm.c
> +++ b/arch/arm/mach-omap2/board-ti8168evm.c
> @@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void)
>
> static void __init ti8168_evm_map_io(void)
> {
> - omap2_set_globals_ti816x();
> - omapti816x_map_common_io();
> + omap2_set_globals_ti81xx();
> + omapti81xx_map_common_io();
> }
>
> MACHINE_START(TI8168EVM, "ti8168evm")
> /* Maintainer: Texas Instruments */
> .atag_offset = 0x100,
> .map_io = ti8168_evm_map_io,
> - .init_early = ti816x_init_early,
> - .init_irq = ti816x_init_irq,
> + .init_early = ti81xx_init_early,
> + .init_irq = ti81xx_init_irq,
> .timer = &omap3_timer,
> .init_machine = ti8168_evm_init,
> MACHINE_END
Looks like you still need a minor rebase on the current cleanup
branch as the ti8668_evm_map_io is no longer needed. The cleanup
branch already has Paul's CHIP_IS removal, so that should be
trivial.
Ideally the rename patch would be separate without any functional
changes, maybe you can move the changes and additions to the next
patch?
Tony
^ permalink raw reply
* [PATCH v2 3/3] TI814X: Create board support and enable build for TI8148 EVM
From: Tony Lindgren @ 2011-09-21 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316626754-5764-1-git-send-email-hemantp@ti.com>
* Hemant Pedanekar <hemantp@ti.com> [110921 10:05]:
> +
> +static struct omap_board_config_kernel ti8148_evm_config[] __initdata = {
> +};
> +
> +static void __init ti8148_evm_init(void)
> +{
> + omap_serial_init();
> + omap_board_config = ti8148_evm_config;
> + omap_board_config_size = ARRAY_SIZE(ti8148_evm_config);
> +}
> +
> +static void __init ti8148_evm_map_io(void)
> +{
> + omap2_set_globals_ti81xx();
> + omapti81xx_map_common_io();
> +}
Hmm I guess we still have board specific map_io in board-ti8668evm.c
also. Those would be better replaced with ti81xx_map_io in
mach-omap2/common.c. Care to take a look at that?
> +MACHINE_START(TI8148EVM, "ti8148evm")
> + /* Maintainer: Texas Instruments */
> + .atag_offset = 0x100,
> + .map_io = ti8148_evm_map_io,
> + .init_early = ti81xx_init_early,
> + .init_irq = ti81xx_init_irq,
> + .timer = &omap3_timer,
> + .init_machine = ti8148_evm_init,
> +MACHINE_END
Please add this all to board-ti8168evm.c instead of adding a new
board-*.c file. With the upcoming device tree conversion most of
these will disappear anyways.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/2] OMAP: omap_device: Add a method to build an omap_device from a DT node
From: Kevin Hilman @ 2011-09-21 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E77421C.3000202@ti.com>
"Cousson, Benoit" <b-cousson@ti.com> writes:
> On 9/17/2011 6:13 PM, Grant Likely wrote:
>> On Fri, Sep 16, 2011 at 04:43:19PM +0200, Benoit Cousson wrote:
[...]
>>> +}
>>> +
>>> +static int _omap_device_notifier_call(struct notifier_block *nb,
>>> + unsigned long event, void *dev)
>>
>> Nit: Why the preceding underscore? Generally that is only done for
>> 'special' variants of public functions. ie. for a variant that
>> expects a lock to already be held.
>
> Yeah, the convention in this file is not that strict, and it is used
> for internal static helper function as well.
> I'll let Kevin arbitrate that point :-)
The convention in this file is the leading '_' is used for internal
helper functions.
I'd prefer to keep it that way, and if we decide to change the coding
convention to match a coding convention elsewhere, we should do it all
at the same time.
Kevin
^ permalink raw reply
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