* DT vs ARM static mappings
From: Arnd Bergmann @ 2011-09-20 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316535403.4611.534.camel@hornet.cambridge.arm.com>
On Tuesday 20 September 2011, Pawel Moll wrote:
> On Tue, 2011-09-20 at 15:37 +0100, Rob Herring wrote
> > > My point is that we should be able to handle _all_ of them using one
> > > DT_MACHINE_START with a single compat value "arm,vexpress". The only
> > > problem with this (so far) is the mapping.
> >
> > Yes, you should have 1 DT_MACHINE_START, but arm,vexpress is too
> > generic. You can and should have a list of compatible strings for each
> > board/machine.
>
> Our DTS has:
>
> compatible = "arm,vexpress-v2p-ca9", "arm,vexpress";
>
> and v2m.c:
>
> static const char *v2m_dt_match[] __initconst = {
> "arm,vexpress",
> NULL,
> };
>
> DT_MACHINE_START(VEXPRESS_DT, "ARM Versatile Express")
> .map_io = v2m_map_io,
> .init_early = v2m_init_early,
> .init_irq = v2m_init_irq,
> .timer = &v2m_timer,
> .init_machine = v2m_dt_init,
> .dt_compat = v2m_dt_match,
> MACHINE_END
>
> Isn't it what you meant?
>
> Essentially I see two ways of doing what we are discussing:
>
> 1. Two DT_MACHINE_START, one matching "arm,vexpress-legacy" with map_io
> = v2m_map_io_legacy and second matching "arm,vexpress-rs1" with map_io =
> v2m_map_io_rs1,
>
> 2. Single DT_MACHINE_START matching (the most generic) "arm,vexpress"
> and doing (rougly) this in v2m_map_io:
>
> of_scan_flat_dt(v2m_dt_iotable_init, NULL);
>
> v2m_dt_iotable_init(...)
> {
> if (depth != 0)
> return 0;
> if (of_flat_dt_is_compatible(node, "arm,vexpress-legacy"))
> iotable_init(v2m_io_desc_legacy);
> else (of_flat_dt_is_compatible(node, "arm,vexpress-rs1"))
> iotable_init(v2m_io_desc_rs1);
> else
> panic();
> }
>
> Neither of them seem particularly appealing... ;-)
But I think both ways would be acceptable in the end. It's not a lot
of extra code either way. In the second case, I would probably have
the legacy case as a special variant of the map_io function and have
all others be the default instead of falling back to panic though.
> > >> In "chosen" like the kernel command line would be the place, but I don't
> > >> think that is the right approach. Chosen is really for things that
> > >> change frequently and this doesn't really fall in that category.
> > >
> > > Again, no argument from me here :-)
> > >
> > > The question is - where should it be?
> >
> > Nowhere. It's an OS specific issue, not a h/w issue.
>
> That's exactly why I didn't like this idea in the first place. This
> doesn't change the fact that current infrastructure isn't really helpful
> here.
Agreed, I think that approach would be much worse.
> > >> Generally, the trend is to get rid of static mappings as much as
> > >> possible. Doing that first might simplify things.
> > >
> > > You can't do ioremap() before kmalloc() is up and running (correct me if
> > > I am wrong), at least you can't do this in map_io. So the static mapping
> > > is a must sometimes. And actually, with the latest Nico's changes:
> > >
> > Correct. You can't do ioremap until init_irq. map_io and init_early are
> > too early. My point was if you can delay h/w access then you can remove
> > the static mappings. But yes, we generally can't remove them all. SCU
> > and LL debug uart are 2 examples.
>
> In my case it's sysreg and sysctl. There are two more users of static
> mappings: timer01 and timer23, but they could at some point do ioremap()
> on their own (especially with Nico's changes).
Well, I think with Nico's cahnges, you /can/ actually do ioremap for
areas that have been mapped through the iotable before kmalloc is up.
IIRC, omap does this for a number of peripherals.
It's a bit of a hack, but I think it's much better than taking hardcoded
addresses.
> > For the short term, I would just have 2 static iotables and select the
> > right one based on the board's (or motherboard's) compatible string.
>
> Yes, as mentioned above. This doesn't help with the sysreg offset
> problem though. I may just scan the flat tree looking for their
> particular names and getting raw offset from their regs... Sounds like a
> hack, though.
With the combination of the points mentioned above, you should be
able to do:
- map the entire I/O area in map_io(), depending on the board
- have an __iomem pointer for the sysreg
- populate that pointer using of_iomap from the device tree address
before you first access it.
Do you think that would work?
Arnd
^ permalink raw reply
* [PATCH v2] pata-generic/of: Make probing via device tree non-powerpc-specific
From: Jeff Garzik @ 2011-09-20 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+wbFdd6aVXkFokinxQ7KDUSDYo06K4mZq8gdZKUKj6gMXBn7A@mail.gmail.com>
On 09/19/2011 06:10 AM, Dave Martin wrote:
> Since this has now been superseded by Grant's patch anyway, I'll leave
> it for others to judge.
Grant's patch is certainly preferable, all other things being equal...
Jeff
^ permalink raw reply
* [PATCH REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
From: Arnd Bergmann @ 2011-09-20 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920180731.GL7781@ponder.secretlab.ca>
On Tuesday 20 September 2011, Grant Likely wrote:
> On Tue, Sep 20, 2011 at 07:43:29PM +0200, Arnd Bergmann wrote:
> > On Tuesday 20 September 2011, Stephen Warren wrote:
> > > The bindings were recently updated to have separate properties for each
> > > type of GPIO. Update the Device Tree source to match that.
> > >
> > > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > > Acked-by: Olof Johansson <olof@lixom.net>
> > > ---
> > > I'd previously sent these to Grant assuming they'd go in his dt/next branch,
> > > but perhaps these should go in through Arnd's arm-soc next/dt branch?
> > >
> >
> > Which tree has the update that changed the bindings? I think it should
> > go into the same one.
> >
> > If it's already upstream, I can take it into the fixes branch.
>
> Already upstream
Ok, I see. I've applied both patches to the fixes branch and will send
it out with the next pull request for 3.1 to Linus then.
Thanks,
Arnd
^ permalink raw reply
* IRQF_TRIGGER_LOW and ARM GIC
From: Stephen Warren @ 2011-09-20 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF04B327A657@HQMAIL01.nvidia.com>
Stephen Warren wrote at Friday, September 02, 2011 1:28 PM:
> Russell, Colin,
>
> The Tegra Harmony board contains a TPS6586x chip, which has an active-low
> interrupt output. This is then fed to Tegra's PMC's PWR_INT pin, which can
> be programmed to accept active-low or active-high interrupt signals. This
> then feeds into a GIC interrupt.
>
> The problem is that the PMC appears to default to expecting the attached
> signal to be active-high not active-low.
>
> At a driver level, it seems that IRQF_TRIGGER_LEVEL_LOW should be passed
> to request_threaded_irq() to solve this. However, gic.c:gic_set_type()
> prohibits IRQ_TYPE_* except LEVEL_HIGH and EDGE_RISING.
>
> I'm not quite sure how to solve this; should gic_set_type() be modified
> to remove the restriction if gic_arch_extn.irq_set_type is present, and
> assume that gic_arch_extn.irq_set_type will handle converting the input
> signal from LEVEL_LOW to LEVEL_HIGH or EDGE_FALLING to EDGE_RISING?
>
> In at least some non-mainline kernels, this has been solved by having
> individual board files poke PMC registers to invert the signal to the
> gic's expected LEVEL_HIGH. However, I assume that's not a good solution
> for mainline.
>
> Thanks.
Russell, Colin, and thoughts on this? Should I simply modify gic_set_type()
to allow LEVEL_LOW/EDGE_FALLING too?
Thanks.
--
nvpublic
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Nicolas Pitre @ 2011-09-20 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920185121.GA17169@n2100.arm.linux.org.uk>
On Tue, 20 Sep 2011, Russell King - ARM Linux wrote:
> On Tue, Sep 20, 2011 at 10:00:06AM -0700, Simon Glass wrote:
> > Hmm even more out there, I wonder if we can modify the BUG macro to
> > put the bug table entry into one of two separate depending on whether
> > BUG is in an __exit function or not? Then at link time, either concat
> > the two tables, or just ignore the exit one...
>
> That was the same thought for the SMP alternatives problem - I think
> Nicolas proposed that there should be some way that the linker can
> do sections based on the current section name. That'd allow us to
> have .alt.smp.exit.text and __bug_table.exit.text etc.
Initially that was proposed by Dave Martin, then I tried to push things
ahead a bit in the Linaro toolchain work group.
The thread with the latest exchanges can be viewed here:
http://news.gmane.org/group/gmane.linux.linaro.toolchain/thread=1270
In a nutshell, it seems that enhancing gas to support this isn't
trivial, and we are asked how beneficial (i.e. how much smaller the
kernel image would be if all those sections could actually be split and
discarded at link time) this would be to justify the effort.
Nicolas
^ permalink raw reply
* [GIT PULL] omap cleanup part1 for v3.2 merge window
From: Arnd Bergmann @ 2011-09-20 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917014623.GC2937@atomide.com>
On Saturday 17 September 2011, Tony Lindgren wrote:
> Please pull the first part of omap cleanup from:
>
> git://github.com/tmlind/linux.git cleanup
>
> This series cleans up early_init functions and removes
> CHIP_IS macro usage. This makes it easier to have SoC
> specific init functions so adding support for new omap
> variants does not require patching all over the place.
Thanks, pulled.
Note that we are trying to get everyone to use the similar
prefixes for patch summaries, so it would be nice if you could
change 'OMAP: powerdomain:' to 'ARM: OMAP: powerdomain' or
'ARM: omap/powerdowmain:' in the future.
Arnd
^ permalink raw reply
* [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Troy Kisky @ 2011-09-20 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920025700.GE28084@S2100-06.ap.freescale.net>
On 9/19/2011 7:57 PM, Shawn Guo wrote:
> On Mon, Sep 19, 2011 at 03:39:30PM -0700, Troy Kisky wrote:
>> On 9/18/2011 4:54 AM, Shawn Guo wrote:
>>> With the unnecessary 1 bit left-shift on fep->phy_speed during the
>>> calculation, the phy_speed always runs at the half frequency of the
>>> optimal one 2.5 MHz.
>>>
>>> The patch removes that 1 bit left-shift to get the optimal phy_speed.
>>>
>>> Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
>>> ---
>>> drivers/net/fec.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
>>> index 5ef0e34..04206e4 100644
>>> --- a/drivers/net/fec.c
>>> +++ b/drivers/net/fec.c
>>> @@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
>>> /*
>>> * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
>>> */
>>> - fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000)<< 1;
>>> + fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
>>> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
>>>
>>> fep->mii_bus = mdiobus_alloc();
>> Do you need to round up to an even value? Is the hardware
>> documentation wrong?
> The round up is something existed, and the patch does not touch that
> part.
That's not what I was referring to. Previously, phy_speed was always
even because of the shift.
The MX53 manual says this field starts at bit 1, and bit 0 is unused.
Therefore, maybe the
correct change would be
fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 2500000)<< 1;
So, the question is, does this field start@bit 0 (your version is correct)
or bit 1? In other words, how did the hardware manual get it wrong? Wrong starting
bit, or divide by 2 not needed. Please document the mistake in the code.
>
>> Does this need a quirk? What boards has this been verified to fix?
>>
> I tested this on i.mx28, i.mx53 and i.mx6q. Do you see problem on
> your platform?
>
I have not tested yet, but will sometime this week.
^ permalink raw reply
* [GIT PULL] omap voltage cleanup for v3.2 merge window
From: Arnd Bergmann @ 2011-09-20 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917015419.GD2937@atomide.com>
On Saturday 17 September 2011, Tony Lindgren wrote:
> Please pull omap voltage cleanup series:
>
> git://github.com/tmlind/linux.git voltage
>
> This has a dependency to the cleanup part 1 series. As
> this contains some voltage fixes too, it's a separate
> series. You can either pull it into cleanup or keep it
> separate.
Hi Tony,
I've pulled it into the for-next branch, but haven't
made up my mind how it I will send it upstream.
I definitely think it's good that you sent it to me
as a separate series, given the number of patches in it.
Thanks,
Arnd
^ permalink raw reply
* [GIT PULL] davinci fixes for v3.2 merge window
From: Arnd Bergmann @ 2011-09-20 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302575A0DD6@dbde02.ent.ti.com>
On Saturday 17 September 2011, Nori, Sekhar wrote:
> Please pull the following two fixes for the v3.2
> merge window. They are not applicable to stable
> tree and hence the stable tag has not been added.
>
> Thanks,
> Sekhar
>
> The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
> Linus Torvalds (1):
> Linux 3.1-rc6
>
> are available in the git repository at:
>
> git://gitorious.org/linux-davinci/linux-davinci.git v3.2/fixes
>
> Ido Yariv (1):
> ARM: davinci: Explicitly set channel controllers' default queues
>
> Thomas Meyer (1):
> ARM: davinci: edma: use kzalloc()
Hi Sekhar,
Looking at the patches, they seem to be more of the cleanup category,
so I think I'd apply them to the next/cleanup branch instead of
the next/fixes branch. Does that make sense?
Arnd
^ permalink raw reply
* [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Troy Kisky @ 2011-09-20 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E78F20A.30001@boundarydevices.com>
On 9/20/2011 1:05 PM, Troy Kisky wrote:
> On 9/19/2011 7:57 PM, Shawn Guo wrote:
>> On Mon, Sep 19, 2011 at 03:39:30PM -0700, Troy Kisky wrote:
>>> On 9/18/2011 4:54 AM, Shawn Guo wrote:
>>>> With the unnecessary 1 bit left-shift on fep->phy_speed during the
>>>> calculation, the phy_speed always runs at the half frequency of the
>>>> optimal one 2.5 MHz.
>>>>
>>>> The patch removes that 1 bit left-shift to get the optimal phy_speed.
>>>>
>>>> Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
>>>> ---
>>>> drivers/net/fec.c | 2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
>>>> index 5ef0e34..04206e4 100644
>>>> --- a/drivers/net/fec.c
>>>> +++ b/drivers/net/fec.c
>>>> @@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct
>>>> platform_device *pdev)
>>>> /*
>>>> * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
>>>> */
>>>> - fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk),
>>>> 5000000)<< 1;
>>>> + fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
>>>> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
>>>>
>>>> fep->mii_bus = mdiobus_alloc();
>>> Do you need to round up to an even value? Is the hardware
>>> documentation wrong?
>> The round up is something existed, and the patch does not touch that
>> part.
> That's not what I was referring to. Previously, phy_speed was always
> even because of the shift.
> The MX53 manual says this field starts at bit 1, and bit 0 is unused.
> Therefore, maybe the
> correct change would be
>
> fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 2500000)<< 1;
oops, I meant
fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 2500000 * 4) << 1;
> So, the question is, does this field start at bit 0 (your version is
> correct)
> or bit 1? In other words, how did the hardware manual get it wrong?
> Wrong starting
> bit, or divide by 2 not needed. Please document the mistake in the code.
>
>
>>
>>> Does this need a quirk? What boards has this been verified to fix?
>>>
>> I tested this on i.mx28, i.mx53 and i.mx6q. Do you see problem on
>> your platform?
>>
> I have not tested yet, but will sometime this week.
>
>
>
^ permalink raw reply
* [PATCH 0/2] pin controller subsystem v7
From: Stephen Warren @ 2011-09-20 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316175182-10700-1-git-send-email-linus.walleij@stericsson.com>
Linus Walleij wrote at Friday, September 16, 2011 6:13 AM:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This is the sixth iteration of the controller subsystem...
Overall, the changelog sounds like a great move in the right direction.
There's just one small thing I'd comment on here:
> ChangeLog v6->v7:
>
> - Make it possible to have several map entries matching the
> same device, pin controller and function, but using
> a different group, and alter the semantics so that
> pinmux_get() will pick all matching map entries, and
> store the associated groups in a list. The list will
> then be iterated over at pinmux_enable()/pinmux_disable()
> and corresponding driver functions called for each
> defined group. Notice that you're only allowed to map
> multiple *groups* to the same
> { device, pin controller, function } triplet, attempts
> to map the same device to multiple pin controllers will
> for example fail. This is hopefully the crucial feature
> requested by Stephen Warren.
I've been viewing the map table as:
input: (device, device's function)
output: list of (controller, controller's group, controller's function)
... hence I was surprised to see that you explicitly note that mapping a
single device to multiple controllers was disallowed.
That said, I suppose this restriction won't cause any issues for any
use-case I'm aware of; the only possibilities might be:
a) Multiple pinmux controllers within the SoC, but perhaps the driver
should just aggregate multiple HW modules into a single Linux device
anyway?
b) Where the pinmux map wants to affect the pinmux on both ends of some
bus, where the two ends are different chips each having obviously separate
pinmux controllers.
Then again, if this need ever does arise, we should be able to just relax
this restriction without causing any backwards-compatibility issues, so
I don't see a specific need to change this now; I just thought I'd mention
it so you're aware of what I'm thinking.
I'll go review the code now.
--
nvpublic
^ permalink raw reply
* [GIT PULL] davinci features for v3.2 merge windiow
From: Arnd Bergmann @ 2011-09-20 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302575A0DD7@dbde02.ent.ti.com>
On Saturday 17 September 2011, Nori, Sekhar wrote:
> Please pull the following feature for v3.2 merge
> window. It adds TI WLAN support on AM18x board.
>
> Thanks,
> Sekhar
>
> The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
> Linus Torvalds (1):
> Linux 3.1-rc6
>
> are available in the git repository at:
>
> git://gitorious.org/linux-davinci/linux-davinci.git v3.2/features
>
Pulled into the next/devel branch.
Thanks,
Arnd
^ permalink raw reply
* [GIT PULL] Samsung cleanup for v3.2
From: Arnd Bergmann @ 2011-09-20 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001901cc76b8$018d4fc0$04a7ef40$%kim@samsung.com>
On Monday 19 September 2011, Kukjin Kim wrote:
> This is Samsung cleanup for v3.2.
>
> Please pull from:
> git://github.com/kgene/linux-samsung.git next-samsung-cleanup
Pulled into arm-soc/next/cleanup.
> If any problems, please let me know.
One tiny conflict with Nico's cross-platform series:
+
+ MACHINE_START(SMDKC210, "SMDKC210")
+ /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
- .boot_params = S5P_PA_SDRAM + 0x100,
++ .atag_offset = 0x100,
+ .init_irq = exynos4_init_irq,
+ .map_io = smdkv310_map_io,
+ .init_machine = smdkv310_machine_init,
+ .timer = &exynos4_timer,
+ MACHINE_END
I'll handle this in the upstream submission.
Thanks,
Arnd
^ permalink raw reply
* [PATCH 0/3] GIC OF bindings
From: Rob Herring @ 2011-09-20 20:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
Hopefully, this is the final or near final version of GIC binding support.
Changes from the previous version:
- SPIs and PPIs are numbered starting at 0. Now the gic has it's own irq
domain translate function instead of the simple domain one.
- interrupt cell format has changed based on Grant's proposal.
- Dropped "ARM: gic: allow irq_start to be 0". Instead, the first 16 irqs
are skipped and the domain irq_base adjusted accordingly.
- Added a fix to of_irq_find_parent when the parent == child.
- Renamed intc_desc.parent to intc_desc.interrupt_parent.
- Implemented Grant's algorithm for walking the list of interrupt
controllers. Added a return value to interrupt init functions, so they
don't get added to the parent list on a init failure.
The changes are significant enough that I did not include previous
acked/reviewed/tested-by's.
Rob
Rob Herring (3):
of/irq: of_irq_find_parent: check for parent equal to child
of/irq: introduce of_irq_init
ARM: gic: add OF based initialization
Documentation/devicetree/bindings/arm/gic.txt | 55 +++++++++++
arch/arm/common/gic.c | 89 ++++++++++++++++-
arch/arm/include/asm/hardware/gic.h | 12 +++
drivers/of/irq.c | 128 +++++++++++++++++++++++--
include/linux/of_irq.h | 1 +
5 files changed, 274 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
--
1.7.5.4
^ permalink raw reply
* [PATCH 1/3] of/irq: of_irq_find_parent: check for parent equal to child
From: Rob Herring @ 2011-09-20 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316550244-3655-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
An interrupt controller may often implicitly inherit itself from a parent
node when in fact the controller is the interrupt root controller. Guard
against the case of child == parent and return NULL in this case.
This can also be fixed by adding an explicit "interrupt-parent;" to a root
interrupt controller node.
Based on code from Grant Likely.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
drivers/of/irq.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9f689f1..6a5b5e7 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -58,27 +58,27 @@ EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
*/
struct device_node *of_irq_find_parent(struct device_node *child)
{
- struct device_node *p;
+ struct device_node *p, *c = child;
const __be32 *parp;
- if (!of_node_get(child))
+ if (!of_node_get(c))
return NULL;
do {
- parp = of_get_property(child, "interrupt-parent", NULL);
+ parp = of_get_property(c, "interrupt-parent", NULL);
if (parp == NULL)
- p = of_get_parent(child);
+ p = of_get_parent(c);
else {
if (of_irq_workarounds & OF_IMAP_NO_PHANDLE)
p = of_node_get(of_irq_dflt_pic);
else
p = of_find_node_by_phandle(be32_to_cpup(parp));
}
- of_node_put(child);
- child = p;
+ of_node_put(c);
+ c = p;
} while (p && of_get_property(p, "#interrupt-cells", NULL) == NULL);
- return p;
+ return (p == child) ? NULL : p;
}
/**
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/3] of/irq: introduce of_irq_init
From: Rob Herring @ 2011-09-20 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316550244-3655-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
of_irq_init will scan the devicetree for matching interrupt controller
nodes. Then it calls an initialization function for each found controller
in the proper order with parent nodes initialized before child nodes.
Based on initial pseudo code from Grant Likely.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
drivers/of/irq.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of_irq.h | 1 +
2 files changed, 115 insertions(+), 0 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 6a5b5e7..1d51bc7 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -19,10 +19,12 @@
*/
#include <linux/errno.h>
+#include <linux/list.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_irq.h>
#include <linux/string.h>
+#include <linux/slab.h>
/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
#ifndef NO_IRQ
@@ -386,3 +388,115 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
return i;
}
+
+struct intc_desc {
+ struct list_head list;
+ struct device_node *dev;
+ struct device_node *interrupt_parent;
+};
+
+typedef int (*irq_init_cb_t)(struct device_node *, struct device_node *);
+
+/**
+ * of_irq_init - Scan the device tree for matching interrupt controllers and
+ * call their initialization functions in order with parents first.
+ * @matches: 0 terminated array of nodes to match and initialization function
+ * to call on match
+ */
+void __init of_irq_init(const struct of_device_id *matches)
+{
+ struct device_node *np;
+ struct intc_desc *desc;
+ struct intc_desc *temp_desc;
+ struct intc_desc *parent_desc = NULL;
+ struct list_head intc_desc_list;
+ struct list_head intc_parent_list;
+
+ INIT_LIST_HEAD(&intc_desc_list);
+ INIT_LIST_HEAD(&intc_parent_list);
+
+ for_each_matching_node(np, matches) {
+ if (!of_find_property(np, "interrupt-controller", NULL))
+ continue;
+ /* Here, we allocate and populate an intc_desc with the node
+ * pointer, interrupt-parent device_node etc. */
+ desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+ if (!desc) {
+ WARN_ON(1);
+ goto err;
+ }
+ desc->dev = np;
+ desc->interrupt_parent = of_irq_find_parent(np);
+ list_add(&desc->list, &intc_desc_list);
+ }
+ if (list_empty(&intc_desc_list))
+ return;
+
+ /*
+ * The root irq controller is the one without an interrupt-parent.
+ * That one goes first, followed by the controllers that reference it,
+ * followed by the ones that reference the 2nd level controllers, etc
+ */
+ while (!list_empty(&intc_desc_list)) {
+ /*
+ * Process all controllers with the current 'parent'.
+ * First pass will be looking for NULL as the parent.
+ * The assumption is that NULL parent means a root controller.
+ */
+ list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
+ const struct of_device_id *match;
+ int ret;
+ irq_init_cb_t irq_init_cb;
+
+ if (parent_desc &&
+ (desc->interrupt_parent != parent_desc->dev))
+ continue;
+
+ list_del(&desc->list);
+ match = of_match_node(matches, desc->dev);
+ if (!match || !match->data)
+ continue;
+
+ pr_debug("of_irq_init: init %s @ %p, parent %p\n",
+ match->compatible,
+ desc->dev, desc->interrupt_parent);
+ irq_init_cb = match->data;
+ ret = irq_init_cb(desc->dev, desc->interrupt_parent);
+ if (ret)
+ continue;
+
+ /*
+ * This one is now set up; add it to the parent list so
+ * its children can get processed in a subsequent pass.
+ */
+ list_add_tail(&desc->list, &intc_parent_list);
+ }
+ /*
+ * All the direct children for the current parent are
+ * processed, so free the parent now.
+ */
+ if (parent_desc)
+ kfree(parent_desc);
+
+ /* Get the next pending parent that might have children */
+ parent_desc = list_first_entry(&intc_parent_list,
+ typeof(*parent_desc), list);
+ if (list_empty(&intc_parent_list) || !parent_desc) {
+ pr_debug("of_irq_init: children remain, but no parents\n");
+ goto err;
+ }
+
+ list_del(&parent_desc->list);
+ }
+ return;
+
+err:
+ list_for_each_entry_safe(desc, temp_desc, &intc_parent_list, list) {
+ list_del(&desc->list);
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
+ list_del(&desc->list);
+ kfree(desc);
+ }
+}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index cd2e61c..032d76c 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -73,6 +73,7 @@ extern int of_irq_to_resource_table(struct device_node *dev,
struct resource *res, int nr_irqs);
extern struct device_node *of_irq_find_parent(struct device_node *child);
+extern void of_irq_init(const struct of_device_id *matches);
#endif /* CONFIG_OF_IRQ */
#endif /* CONFIG_OF */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/3] ARM: gic: add OF based initialization
From: Rob Herring @ 2011-09-20 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316550244-3655-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
This adds ARM gic interrupt controller initialization using device tree
data.
The initialization function is intended to be called by of_irq_init
function like this:
const static struct of_device_id irq_match[] = {
{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
{}
};
static void __init init_irqs(void)
{
of_irq_init(irq_match);
}
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
Documentation/devicetree/bindings/arm/gic.txt | 55 +++++++++++++++
arch/arm/common/gic.c | 89 +++++++++++++++++++++++-
arch/arm/include/asm/hardware/gic.h | 12 ++++
3 files changed, 152 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
new file mode 100644
index 0000000..52916b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -0,0 +1,55 @@
+* ARM Generic Interrupt Controller
+
+ARM SMP cores are often associated with a GIC, providing per processor
+interrupts (PPI), shared processor interrupts (SPI) and software
+generated interrupts (SGI).
+
+Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
+Secondary GICs are cascaded into the upward interrupt controller and do not
+have PPIs or SGIs.
+
+Main node required properties:
+
+- compatible : should be one of:
+ "arm,cortex-a9-gic"
+ "arm,arm11mp-gic"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a <u32> and the value shall be 3.
+
+ The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
+ interrupts.
+
+ The 2nd cell contains the interrupt number for the interrupt type.
+ SPI interrupts are in the range [0-987]. PPI interrupts are in the
+ range [0-15].
+
+ The 3rd cell is the flags, encoded as follows:
+ bits[3:0] trigger type and level flags.
+ 1 = low-to-high edge triggered
+ 2 = high-to-low edge triggered
+ 4 = active high level-sensitive
+ 8 = active low level-sensitive
+ bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
+ the 8 possible cpus attached to the GIC. A bit set to '1' indicated
+ the interrupt is wired to that CPU. Only valid for PPI interrupts.
+
+- reg : Specifies base physical address(s) and size of the GIC registers. The
+ first region is the GIC distributor register base and size. The 2nd region is
+ the GIC cpu interface register base and size.
+
+Optional
+- interrupts : Interrupt source of the parent interrupt controller. Only
+ present on secondary GICs.
+
+Example:
+
+ intc: interrupt-controller at fff11000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0xfff11000 0x1000>,
+ <0xfff10100 0x100>;
+ };
+
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 666b278..84e69a4 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -28,6 +28,10 @@
#include <linux/smp.h>
#include <linux/cpumask.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/irqdomain.h>
#include <asm/irq.h>
#include <asm/mach/irq.h>
@@ -255,6 +259,15 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
irq_set_chained_handler(irq, gic_handle_cascade_irq);
}
+static int gic_irq_count(void __iomem *dist_base)
+{
+ int gic_irqs = readl_relaxed(dist_base + GIC_DIST_CTR) & 0x1f;
+ gic_irqs = (gic_irqs + 1) * 32;
+ if (gic_irqs > 1020)
+ gic_irqs = 1020;
+ return gic_irqs;
+}
+
static void __init gic_dist_init(struct gic_chip_data *gic,
unsigned int irq_start)
{
@@ -277,10 +290,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
* Find out how many interrupts are supported.
* The GIC only supports up to 1020 interrupt sources.
*/
- gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
- gic_irqs = (gic_irqs + 1) * 32;
- if (gic_irqs > 1020)
- gic_irqs = 1020;
+ gic_irqs = gic_irq_count(base);
/*
* Set all global interrupts to be level triggered, active low.
@@ -405,3 +415,74 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
writel_relaxed(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT);
}
#endif
+
+#ifdef CONFIG_OF
+static int gic_cnt __initdata = 0;
+
+int gic_irq_domain_dt_translate(struct irq_domain *d,
+ struct device_node *controller,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq, unsigned int *out_type)
+{
+ struct gic_chip_data *gic_data = d->priv;
+
+ if (d->of_node != controller)
+ return -EINVAL;
+ if (intsize < 3)
+ return -EINVAL;
+
+ *out_hwirq = intspec[1];
+ /*
+ * We've already skipped over SGIs, so PPIs need no translation.
+ * For SPIs, we need to skip over 16 PPIs on primary GICs.
+ */
+ if (!intspec[0] && !gic_data->irq_offset)
+ *out_hwirq += 16;
+
+ *out_type = intspec[2] & IRQ_TYPE_SENSE_MASK;
+ return 0;
+}
+
+struct irq_domain_ops gic_irq_domain_ops = {
+ .dt_translate = gic_irq_domain_dt_translate,
+};
+
+int __init gic_of_init(struct device_node *node, struct device_node *parent)
+{
+ void __iomem *cpu_base;
+ void __iomem *dist_base;
+ int irq;
+ struct irq_domain *domain = &gic_data[gic_cnt].domain;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ dist_base = of_iomap(node, 0);
+ WARN(!dist_base, "unable to map gic dist registers\n");
+
+ cpu_base = of_iomap(node, 1);
+ WARN(!cpu_base, "unable to map gic cpu registers\n");
+
+ domain->nr_irq = gic_irq_count(dist_base);
+ /* subtract off SGIs. Also subtract off PPIs for secondary GICs */
+ if (parent)
+ domain->nr_irq -= 32;
+ else
+ domain->nr_irq -= 16;
+
+ domain->irq_base = irq_alloc_descs(-1, 16, domain->nr_irq, numa_node_id());
+ domain->of_node = of_node_get(node);
+ domain->ops = &gic_irq_domain_ops;
+ domain->priv = &gic_data[gic_cnt];
+ irq_domain_add(domain);
+
+ gic_init(gic_cnt, domain->irq_base, dist_base, cpu_base);
+
+ if (parent) {
+ irq = irq_of_parse_and_map(node, 0);
+ gic_cascade_irq(gic_cnt, irq);
+ }
+ gic_cnt++;
+ return 0;
+}
+#endif
diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index 435d3f8..2862d0e 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -33,10 +33,21 @@
#define GIC_DIST_SOFTINT 0xf00
#ifndef __ASSEMBLY__
+#include <linux/irqdomain.h>
+
extern void __iomem *gic_cpu_base_addr;
extern struct irq_chip gic_arch_extn;
void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
+#ifdef CONFIG_OF
+int gic_of_init(struct device_node *node, struct device_node *parent);
+#else
+static inline void gic_of_init(struct device_node *node,
+ struct device_node *parent)
+{
+ return -ENODEV;
+}
+#endif
void gic_secondary_init(unsigned int);
void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
@@ -46,6 +57,7 @@ struct gic_chip_data {
unsigned int irq_offset;
void __iomem *dist_base;
void __iomem *cpu_base;
+ struct irq_domain domain;
};
#endif
--
1.7.5.4
^ permalink raw reply related
* [GIT PULL] Samsung boards for v3.2
From: Arnd Bergmann @ 2011-09-20 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001a01cc76b8$208e52c0$61aaf840$%kim@samsung.com>
On Monday 19 September 2011, Kukjin Kim wrote:
> Please pull from:
> git://github.com/kgene/linux-samsung.git next-samsung-board
>
> As you see, the next-samsung-board includes new board, SMDK4212. Of course
> to support new SoC, EXYNOS4212 is required for it but current
> arch/arm/mach-exynos4 (ARCH_EXYNOS4) can support it so I merged it into
> next-samsung-board not next-samsung-soc and to support handling of cupid and
> rev. in Samsung stuff for it. As I remember, you said -soc branch of arm-soc
> is for adding new architecture like arch/arm/mach-xxxx.
>
> As a note, this includes samsung-fixes-2 which has been already pulled in
> your tree too.
Looks good. I had to apply the same atag_offset change to the new board
file that was done in all other branches as well.
Pulled into next/board. Thanks!
Arnd
^ permalink raw reply
* [PATCH V7 1/5] AHCI Add the AHCI SATA feature on the MX53 platforms
From: Sascha Hauer @ 2011-09-20 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314762635-3923-2-git-send-email-richard.zhu@linaro.org>
On Wed, Aug 31, 2011 at 11:50:31AM +0800, Richard Zhu wrote:
> Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
> Tested-By: Hector Oron Martinez <hector.oron@gmail.com>
> ---
> arch/arm/mach-mx5/clock-mx51-mx53.c | 19 ++++
> arch/arm/mach-mx5/devices-imx53.h | 4 +
> arch/arm/plat-mxc/Makefile | 1 +
> arch/arm/plat-mxc/ahci_sata.c | 104 +++++++++++++++++++++++
> arch/arm/plat-mxc/devices/Kconfig | 4 +
> arch/arm/plat-mxc/devices/Makefile | 1 +
> arch/arm/plat-mxc/devices/platform-ahci-imx.c | 66 ++++++++++++++
> arch/arm/plat-mxc/include/mach/ahci_sata.h | 33 +++++++
> arch/arm/plat-mxc/include/mach/devices-common.h | 10 ++
> 9 files changed, 242 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/plat-mxc/ahci_sata.c
> create mode 100644 arch/arm/plat-mxc/devices/platform-ahci-imx.c
> create mode 100644 arch/arm/plat-mxc/include/mach/ahci_sata.h
>
> diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
> index 7f20308..e1fadaf 100644
> --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
> +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
> @@ -1397,6 +1397,22 @@ static struct clk esdhc4_mx53_clk = {
> .secondary = &esdhc4_ipg_clk,
> };
>
> diff --git a/arch/arm/plat-mxc/ahci_sata.c b/arch/arm/plat-mxc/ahci_sata.c
> new file mode 100644
> index 0000000..4f54816
> --- /dev/null
> +++ b/arch/arm/plat-mxc/ahci_sata.c
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + */
> +
> +/*
> + * 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.
> +
> + * 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.
> +
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/device.h>
> +#include <mach/ahci_sata.h>
> +
> +static struct clk *sata_clk, *sata_ref_clk;
These variables make the driver single instance only.
> +
> +/* AHCI module Initialization, if return 0, initialization is successful. */
> +int sata_init(struct device *dev, void __iomem *addr)
A global function with such a generic name is not a good idea.
Also I wonder how we want to convert this to devicetree when we
implement this as a platform specific hook. It should be done in the
driver.
> +{
> + u32 tmpdata;
> + int ret = 0;
> + struct clk *clk;
> +
> + sata_clk = clk_get(dev, "ahci");
> + if (IS_ERR(sata_clk)) {
> + dev_err(dev, "no sata clock.\n");
> + return PTR_ERR(sata_clk);
> + }
> + ret = clk_enable(sata_clk);
> + if (ret) {
> + dev_err(dev, "can't enable sata clock.\n");
> + goto put_sata_clk;
> + }
> +
> + /* FSL IMX AHCI SATA uses the internal usb phy1 clk on loco */
So this function is loco specific or is the comment wrong?
> + sata_ref_clk = clk_get(dev, "ahci_phy");
> + if (IS_ERR(sata_ref_clk)) {
> + dev_err(dev, "no sata ref clock.\n");
> + ret = PTR_ERR(sata_ref_clk);
> + goto release_sata_clk;
> + }
> + ret = clk_enable(sata_ref_clk);
> + if (ret) {
> + dev_err(dev, "can't enable sata ref clock.\n");
> + goto put_sata_ref_clk;
> + }
> +
> + /* Get the AHB clock rate, and configure the TIMER1MS reg later */
> + clk = clk_get(dev, "ahci_dma");
> + if (IS_ERR(clk)) {
> + dev_err(dev, "no dma clock.\n");
> + ret = PTR_ERR(clk);
> + goto release_sata_ref_clk;
> + }
> + tmpdata = clk_get_rate(clk) / 1000;
> + clk_put(clk);
> +
> + writel(tmpdata, addr + HOST_TIMER1MS);
> +
> + tmpdata = readl(addr + HOST_CAP);
> + if (!(tmpdata & HOST_CAP_SSS)) {
> + tmpdata |= HOST_CAP_SSS;
> + writel(tmpdata, addr + HOST_CAP);
> + }
> +
> + if (!(readl(addr + HOST_PORTS_IMPL) & 0x1))
> + writel((readl(addr + HOST_PORTS_IMPL) | 0x1),
> + addr + HOST_PORTS_IMPL);
> +
> + return 0;
> +
> +release_sata_ref_clk:
> + clk_disable(sata_ref_clk);
> +put_sata_ref_clk:
> + clk_put(sata_ref_clk);
> +release_sata_clk:
> + clk_disable(sata_clk);
> +put_sata_clk:
> + clk_put(sata_clk);
> +
> + return ret;
> +}
> +
> +void sata_exit(struct device *dev)
> +{
> + clk_disable(sata_ref_clk);
> + clk_put(sata_ref_clk);
> +
> + clk_disable(sata_clk);
> + clk_put(sata_clk);
> +
> +}
> diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
> index bd294ad..f63887b 100644
> --- a/arch/arm/plat-mxc/devices/Kconfig
> +++ b/arch/arm/plat-mxc/devices/Kconfig
> @@ -76,3 +76,7 @@ config IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
>
> config IMX_HAVE_PLATFORM_SPI_IMX
> bool
> +
> +config IMX_HAVE_PLATFORM_AHCI
> + bool
> + default y if ARCH_MX53
> diff --git a/arch/arm/plat-mxc/devices/Makefile b/arch/arm/plat-mxc/devices/Makefile
> index b41bf97..e858ad9 100644
> --- a/arch/arm/plat-mxc/devices/Makefile
> +++ b/arch/arm/plat-mxc/devices/Makefile
> @@ -25,3 +25,4 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_RTC) += platform-mxc_rtc.o
> obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_W1) += platform-mxc_w1.o
> obj-$(CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX) += platform-sdhci-esdhc-imx.o
> obj-$(CONFIG_IMX_HAVE_PLATFORM_SPI_IMX) += platform-spi_imx.o
> +obj-$(CONFIG_IMX_HAVE_PLATFORM_AHCI) += platform-ahci-imx.o
> diff --git a/arch/arm/plat-mxc/devices/platform-ahci-imx.c b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
> new file mode 100644
> index 0000000..9e1b460
> --- /dev/null
> +++ b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
> @@ -0,0 +1,66 @@
> +/*
> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + */
> +
> +/*
> + * 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.
> +
> + * 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.
> +
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#include <linux/dma-mapping.h>
> +#include <asm/sizes.h>
> +#include <mach/hardware.h>
> +#include <mach/devices-common.h>
> +#include <mach/ahci_sata.h>
> +
> +#define imx_ahci_imx_data_entry_single(soc, _devid) \
> + { \
> + .devid = _devid, \
> + .iobase = soc ## _SATA_BASE_ADDR, \
> + .irq = soc ## _INT_SATA, \
> + }
> +
> +#ifdef CONFIG_SOC_IMX53
> +const struct imx_ahci_imx_data imx53_ahci_imx_data __initconst =
> + imx_ahci_imx_data_entry_single(MX53, "imx53-ahci");
> +#endif
> +
> +static struct ahci_platform_data default_sata_pdata = {
> + .init = sata_init,
> + .exit = sata_exit,
> +};
> +
> +struct platform_device *__init imx_add_ahci_imx(
> + const struct imx_ahci_imx_data *data,
> + const struct ahci_platform_data *pdata)
> +{
> + struct resource res[] = {
> + {
> + .start = data->iobase,
> + .end = data->iobase + SZ_4K - 1,
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = data->irq,
> + .end = data->irq,
> + .flags = IORESOURCE_IRQ,
> + },
> + };
> +
> + if (pdata == NULL)
> + pdata = &default_sata_pdata;
> +
> + return imx_add_platform_device_dmamask(data->devid, 0,
> + res, ARRAY_SIZE(res),
> + pdata, sizeof(*pdata), DMA_BIT_MASK(32));
> +}
> diff --git a/arch/arm/plat-mxc/include/mach/ahci_sata.h b/arch/arm/plat-mxc/include/mach/ahci_sata.h
> new file mode 100644
> index 0000000..ba297e1
> --- /dev/null
> +++ b/arch/arm/plat-mxc/include/mach/ahci_sata.h
> @@ -0,0 +1,33 @@
> +/*
> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + */
> +
> +/*
> + * 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.
> +
> + * 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.
> +
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#ifndef __PLAT_MXC_AHCI_SATA_H__
> +#define __PLAT_MXC_AHCI_SATA_H__
> +
> +enum {
> + HOST_CAP = 0x00,
> + HOST_CAP_SSS = (1 << 27), /* Staggered Spin-up */
> + HOST_PORTS_IMPL = 0x0c,
> + HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
> +};
> +
> +extern int sata_init(struct device *dev, void __iomem *addr);
> +extern void sata_exit(struct device *dev);
> +#endif /* __PLAT_MXC_AHCI_SATA_H__ */
> diff --git a/arch/arm/plat-mxc/include/mach/devices-common.h b/arch/arm/plat-mxc/include/mach/devices-common.h
> index 524538a..f04e063 100644
> --- a/arch/arm/plat-mxc/include/mach/devices-common.h
> +++ b/arch/arm/plat-mxc/include/mach/devices-common.h
> @@ -301,3 +301,13 @@ struct platform_device *__init imx_add_spi_imx(
> struct platform_device *imx_add_imx_dma(void);
> struct platform_device *imx_add_imx_sdma(char *name,
> resource_size_t iobase, int irq, struct sdma_platform_data *pdata);
> +
> +#include <linux/ahci_platform.h>
> +struct imx_ahci_imx_data {
> + const char *devid;
> + resource_size_t iobase;
> + resource_size_t irq;
> +};
> +struct platform_device *__init imx_add_ahci_imx(
> + const struct imx_ahci_imx_data *data,
> + const struct ahci_platform_data *pdata);
> --
> 1.7.1
>
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2] mach-ep93xx: break out GPIO driver specifics
From: Linus Walleij @ 2011-09-20 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920174012.GE7781@ponder.secretlab.ca>
On Tue, Sep 20, 2011 at 7:40 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Tue, Sep 20, 2011 at 10:42:12AM +0200, Linus Walleij wrote:
>> From: Linus Walleij <linus.walleij@linaro.org>
>>
>> The <mach/gpio.h> file is included from upper directories
>> and deal with generic GPIO and gpiolib stuff. Break out the
>> platform and driver specific defines and functions into its own
>> header file.
>>
>> Cc: Hartley Sweeten <hsweeten@visionengravers.com>
>> Cc: Ryan Mallon <rmallon@gmail.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v1->v2:
>> - Move the irq_to_gpio() into the driver since it was the only
>> ? thing actually using it, as a result the ep93xx gpio.h
>> ? is trivial and becomes empty.
>> - Putting this into the patch tracker as 7042/2 soon-ish.
>> ---
>> ?arch/arm/mach-ep93xx/core.c ? ? ? ? ? ? ? ? ? ? | ? ?1 +
>> ?arch/arm/mach-ep93xx/edb93xx.c ? ? ? ? ? ? ? ? ?| ? ?1 +
>> ?arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h | ?100 +++++++++++++++++++++
>> ?arch/arm/mach-ep93xx/include/mach/gpio.h ? ? ? ?| ?105 -----------------------
>
> Please use the --find-renames flag for patches like this, but otherwise:
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Thanks, I'll fix that.
> Which tree will this go through? ?I don't think it should go via the
> gpio tree since it is mostly within arch/arm.
It'd dependent on Russells cleanups so it'll go through Russells
tree and his gpio cleanup branch there.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] mach-integrator: fix VGA base regression
From: Linus Walleij @ 2011-09-20 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109051621.18382.arnd@arndb.de>
On Mon, Sep 5, 2011 at 4:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 05 September 2011, Linus Walleij wrote:
>> On Sun, Sep 4, 2011 at 11:40 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> > The changes introduced in commit
>> > cc22b4c18540e5e8bf55c7d124044f9317527d3c
>> > "ARM: set vga memory base at run-time"
>>
>> Arnd can you choose whether to apply this patch or revert
>> the commit making it necessary?
>
> I'm still stuck with master.kernel.org being down, so I can't really push
> any updates right now. I'll do it once it's up again.
Ping on this. Rob agreed to merge the patch, this is a regression
making Integrator non-bootable in 3.1 so I'd really like to see it
merged ASAP.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] spi: Fix builderror in spi-pl022.c
From: Linus Walleij @ 2011-09-20 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb=Bt2j4iMV5NJHmPG8wDi6__CRD6kn_KOoaQ1R6uwrWQ@mail.gmail.com>
On Mon, Sep 5, 2011 at 2:45 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sun, Aug 28, 2011 at 9:26 PM, Peter Huewe <peterhuewe@gmx.de> wrote:
>
>> This patch fixes a build error, introduced by commit (67fc8b9f, "PM: add
>> runtime PM support to core Primecell driver") which unfortunately was a little
>> bit incomplete and did contain a typo (11 instead of 22).
>> I'm not sure how this patch could have been tested back then, if it
>> doesn't even compile ;)
>
> Grant can you please apply this patch? Right now linux-next is
> breaking because of this missing patch...
Ping on this... ignore if it's been picked already.
Thanks,
Linus Walleij
^ permalink raw reply
* [GIT PULL] ux500-core for 3.2
From: Arnd Bergmann @ 2011-09-20 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZofKjOrPFWNR-2D0LWx3NGMiLwyhf7gAVdvBGvQHqJLQ@mail.gmail.com>
On Tuesday 20 September 2011, Linus Walleij wrote:
> could you please pull:
>
> git://git.linaro.org/people/triad/linux-stericsson.git for-arnd
>
> to the ARM SoC tree (ux500 branch or however you prefer to handle it)?
> They have all been reviewed on the ARM list recently and are mostly
> minor fixes and Lee Jones nice cleanup patch.
I would really like to see this split into logical branches, even
if there are just a few patches for each of them. It looks like
the series currently contains bug fixes and cleanups mixed together,
which makes it hard to backport fixes and for me to aggregate patches
across soc families by category.
It's also not clear if the two bug fix patches should be applied
to 3.1 and -stable as well as 3.2. My feeling is that they should.
If you want bug fixes to be backported, please add a 'Cc: stable at kernel.org'
line after your Signed-off-by. If not, add an explanation to the
pull request why they are not relevant for backporting.
I've applied the first four patches to the stericsson/cleanup
and next/cleanup branches now, since these look like they are
purely cleanup branches without noticeable code changes.
Please submit the two bug fixes again, rebased to an -rc release.
there is a dependency on one of the cleanup patches. Don't worry
about that, I'll take care of resolving this conflict after you
have rebased the bug fix to the mainline kernel.
Thanks,
Arnd
^ permalink raw reply
* [GIT PULL] omap cleanup part1 for v3.2 merge window
From: Tony Lindgren @ 2011-09-20 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202201.18574.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [110920 12:27]:
> On Saturday 17 September 2011, Tony Lindgren wrote:
> > Please pull the first part of omap cleanup from:
> >
> > git://github.com/tmlind/linux.git cleanup
> >
> > This series cleans up early_init functions and removes
> > CHIP_IS macro usage. This makes it easier to have SoC
> > specific init functions so adding support for new omap
> > variants does not require patching all over the place.
>
> Thanks, pulled.
>
> Note that we are trying to get everyone to use the similar
> prefixes for patch summaries, so it would be nice if you could
> change 'OMAP: powerdomain:' to 'ARM: OMAP: powerdomain' or
> 'ARM: omap/powerdowmain:' in the future.
Already did that for my patches.. Paul and Kevin, can you
please also start following that standard too?
Thanks,
Tony
^ permalink raw reply
* [PATCH] mach-integrator: fix VGA base regression
From: Arnd Bergmann @ 2011-09-20 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb5jdgR+_aZxVzaedr1FJdUWSi9b7utcB6NsiXhX3GvLA@mail.gmail.com>
On Tuesday 20 September 2011, Linus Walleij wrote:
> On Mon, Sep 5, 2011 at 4:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 05 September 2011, Linus Walleij wrote:
> >> On Sun, Sep 4, 2011 at 11:40 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >>
> >> > The changes introduced in commit
> >> > cc22b4c18540e5e8bf55c7d124044f9317527d3c
> >> > "ARM: set vga memory base at run-time"
> >>
> >> Arnd can you choose whether to apply this patch or revert
> >> the commit making it necessary?
> >
> > I'm still stuck with master.kernel.org being down, so I can't really push
> > any updates right now. I'll do it once it's up again.
>
> Ping on this. Rob agreed to merge the patch, this is a regression
> making Integrator non-bootable in 3.1 so I'd really like to see it
> merged ASAP.
>
Applied, thanks for the reminder!
Arnd
^ 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