* [GIT PULL] Convert arch-vt8500 to multiplatform
From: Arnd Bergmann @ 2012-10-26 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351223497.30694.2.camel@gitbox>
On Friday 26 October 2012, Tony Prisk wrote:
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://server.prisktech.co.nz/git/linuxwmt.git/ tags/armsoc-for-3.8
>
> for you to fetch changes up to 6f35f9a9fabe8f0a89a17e353a77a7edef461bb2:
>
> ARM: vt8500: Convert arch-vt8500 to multiplatform (2012-10-26 16:45:19
> +1300)
>
> ----------------------------------------------------------------
> Two patches for 3.8 to finish converting arch-vt8500 to multiplatform.
> Single arch build is maintained as we still need earlyprintk for
> development work.
>
Merged into next/multiplatform
Thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Samsung fixes-2 for v3.7
From: Arnd Bergmann @ 2012-10-26 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <051a01cdb35c$21e39ae0$65aad0a0$%kim@samsung.com>
On Friday 26 October 2012, Kukjin Kim wrote:
> One is spi stuff for fix the device names for the different subtypes of the
> spi controller. And the other is adding missing .smp field for exynos4-dt
> and fixing memory sections for exynos4210-trats board.
>
Applied to fixes branch, thanks!
Arnd
^ permalink raw reply
* [PATCH] ARM: dma-mapping: support debug_dma_mapping_error
From: Ming Lei @ 2012-10-26 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026104355.GB21164@n2100.arm.linux.org.uk>
On Fri, Oct 26, 2012 at 6:43 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 22, 2012 at 08:44:03PM +0800, Ming Lei wrote:
>> Without the patch, kind of below warning will be dumped if DMA-API
>> debug is enabled:
>>
>> [ 11.069763] ------------[ cut here ]------------
>> [ 11.074645] WARNING: at lib/dma-debug.c:948 check_unmap+0x770/0x860()
>> [ 11.081420] ehci-omap ehci-omap.0: DMA-API: device driver failed to
>> check map error[device address=0x0000000
>> 0adb78e80] [size=8 bytes] [mapped as single]
>> [ 11.095611] Modules linked in:
>>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Ming Lei <ming.lei@canonical.com>
>
> Would you mind explaining why you think it's fine to send a patch for the
> mainline kernel adding a function call to a header file which is not even
> in the mainline kernel?
Sorry, I should have made it explicitly that the patch is against -next tree.
Thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH V2 0/4] Adding SATA support for Armada 370/XP
From: Thomas Petazzoni @ 2012-10-26 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026123908.GH21046@lunn.ch>
On Fri, 26 Oct 2012 14:39:08 +0200, Andrew Lunn wrote:
> What about the openblocks-ax3?
Gr?gory does not (yet) have an OpenBlocks AX3, but I'm planning to do
the work for SATA soon for this platform. However, supporting the
OpenBlocks AX3 is not part of our official contract with Marvell, it's
just an additional thing I'm happily doing on my spare time. So I'll
provide support for SATA, network and SMP on OpenBlocks AX3, but we
would like to first see the SATA support for the Marvell evaluation
boards being merged, and on my side the basic support for the
OpenBlocks AX3. I'll send followup patches to enable SATA/network/SMP
on OpenBlocks AX3 later on, if that's ok for you?
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH v3 05/16] ARM: edma: add AM33XX crossbar event support
From: Hebbar, Gururaja @ 2012-10-26 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350566815-409-6-git-send-email-mporter@ti.com>
On Thu, Oct 18, 2012 at 18:56:44, Porter, Matt wrote:
> Adds support for the per-EDMA channel event mux. This is required
> for any peripherals using DMA crossbar mapped events.
>
> Signed-off-by: Matt Porter <mporter@ti.com>
> ---
> arch/arm/common/edma.c | 63 +++++++++++++++++++++++++++++++++++-
> include/linux/platform_data/edma.h | 1 +
> 2 files changed, 63 insertions(+), 1 deletion(-)
>
..snip..
..snip..
> +
> + for (i = 0; xbar_chans[i][0] != -1; i++) {
> + shift = (xbar_chans[i][1] % 4) * 8;
> + offset = xbar_chans[i][1] >> 2;
> + offset <<= 2;
> + mux = __raw_readl((void *)((u32)xbar + offset));
> + mux &= (~(0xff << shift));
> + mux |= (xbar_chans[i][0] << shift);
> + __raw_writel(mux, (void *)((u32)xbar + offset));
This method of calculating Xbar Channel offset has a bug that
the code breaks with unaligned access trap error when requested
channel to be mapped is odd.
This was fixed in Arago tree [1]. Kindly verify
> + }
> +
> + pdata->xbar_chans = xbar_chans;
> +
> + return 0;
> +}
> +
..snip..
..snip..
[1]
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
h=c08d3cb557adf71c79aeefb38888395455824e83
Regards,
Gururaja
^ permalink raw reply
* [PATCH V2 0/4] Adding SATA support for Armada 370/XP
From: Andrew Lunn @ 2012-10-26 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026144804.640eabaf@skate>
On Fri, Oct 26, 2012 at 02:48:04PM +0200, Thomas Petazzoni wrote:
>
> On Fri, 26 Oct 2012 14:39:08 +0200, Andrew Lunn wrote:
>
> > What about the openblocks-ax3?
>
> Gr??gory does not (yet) have an OpenBlocks AX3, but I'm planning to do
> the work for SATA soon for this platform. However, supporting the
> OpenBlocks AX3 is not part of our official contract with Marvell, it's
> just an additional thing I'm happily doing on my spare time.
Ah, O.K. I did not realize that.
> So I'll
> provide support for SATA, network and SMP on OpenBlocks AX3, but we
> would like to first see the SATA support for the Marvell evaluation
> boards being merged, and on my side the basic support for the
> OpenBlocks AX3. I'll send followup patches to enable SATA/network/SMP
> on OpenBlocks AX3 later on, if that's ok for you?
Sure, no problem.
Thanks for the clarification,
Andrew
^ permalink raw reply
* [PATCH V2 0/4] Adding SATA support for Armada 370/XP
From: Gregory CLEMENT @ 2012-10-26 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026123908.GH21046@lunn.ch>
On 10/26/2012 02:39 PM, Andrew Lunn wrote:
> On Fri, Oct 26, 2012 at 02:30:45PM +0200, Gregory CLEMENT wrote:
>> Hello,
>>
>> this patch set adds the SATA support for Armada 370 and Armada XP. Few
>> changes have been done since the first version by taking in account
>> the comments received for the first version.
>>
>> The evaluation boards for Armada 370 and Armada XP come with 2 SATA
>> ports, and when both are enable the coherent pool for DMA mapping was
>> too short. It was exactly the same issue that was fixed for Kirkwood
>> two months ago. So I used the same fix in the first patch. Later when
>> Kirkwood will be part of mach-mvebu, then this fix will be shared
>> between the 2 SoCs families.
>>
>> This patch set is based on 3.7-rc2 and depends one the framework clock
>> support (the last version was posted last week:
>> http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
>> called mvebu-SATA-for-3.8 is also available at
>> https://github.com/MISL-EBU-System-SW/mainline-public.git.
>
> Hi Gregory
>
> What about the openblocks-ax3?
Well I don't have this hardware, Thomas have. But with this question
I guess this board have (a) SATA port(s).
Moreover openblocks-ax3 is not (yet) in Jason branch so I can't make
a patch applying on a file which doesn't exist on my branch. It could
be a dependency but I try to reduce it as far as I can.
But as soon as this series will be applied, adding SATA support for
openblocks-ax3 should be pretty fast and just a matter of updating
the dts.
>
> Andrew
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] spi: mxs: Assign message status after transfer finished
From: Mark Brown @ 2012-10-26 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210261431.54371.marex@denx.de>
On Fri, Oct 26, 2012 at 02:31:53PM +0200, Marek Vasut wrote:
> Dear Mark Brown,
> > Applied both, thanks.
> Will they hit 3.7 please?
I hadn't been going to do that, no - nothing about them seemed
especially urgent?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/f86cf974/attachment.sig>
^ permalink raw reply
* [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler
From: Ingo Molnar @ 2012-10-26 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351254553.16863.52.camel@twins>
* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> [...]
>
> So a sane series would introduce maybe two functions:
> cpu_load() and task_load() and use those where we now use
> rq->load.weight and p->se.load.weight for load balancing
> purposes. Implement these functions using those two
> expression. So effectively this patch is a NOP.
>
> Secondly, switch these two functions over to the per-task
> based averages.
>
> Tada! all done. The load balancer will then try and equalize
> effective load instead of instant load.
>
> It will do the 3x10% vs 100% thing correctly with just those
> two patches. Simply because it will report a lower cpu-load
> for the 3x10% case than it will for the 100% case, no need to
> go fudge about in the load-balance internals.
>
> Once you've got this correctly done, you can go change
> balancing to better utilize the new metric, like use the
> effective load instead of nr_running against the capacity and
> things like that. But for every such change you want to be
> very careful and run all the benchmarks you can find -- in
> fact you want to do that after the 2nd patch too.
If anyone posted that simple two-patch series that switches over
to the new load metrics I'd be happy to test the performance of
those.
Having two parallel load metrics is really not something that we
should tolerate for too long.
Thanks,
Ingo
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC fixes for v3.7 #2
From: Arnd Bergmann @ 2012-10-26 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350629360-27438-1-git-send-email-horms@verge.net.au>
On Friday 19 October 2012, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following fix for the r8a7779 SoC for 3.6.
> It resolves some more fallout from recent IOMEM() changes.
Merged into fixes branch now, sorry for the delay.
Arnd
^ permalink raw reply
* [PATCH 1/2] spi: mxs: Assign message status after transfer finished
From: Marek Vasut @ 2012-10-26 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026130459.GW18814@opensource.wolfsonmicro.com>
Dear Mark Brown,
> On Fri, Oct 26, 2012 at 02:31:53PM +0200, Marek Vasut wrote:
> > Dear Mark Brown,
> >
> > > Applied both, thanks.
> >
> > Will they hit 3.7 please?
>
> I hadn't been going to do that, no - nothing about them seemed
> especially urgent?
They're fixes, I'd be glad if you could slip them in. They're not urgent, but
it'd be nice to have them included. Esp. since 3.7 seems like a really _good_
kernel for MXS, I'd love to have everything nicely polished in it.
Best regards,
Marek Vasut
^ permalink raw reply
* [GIT PULL] vexpress: drivers for v3.8
From: Arnd Bergmann @ 2012-10-26 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350580034.4984.21.camel@hornet>
On Thursday 18 October 2012, Pawel Moll wrote:
> Hi Arnd, Olof,
>
> Could you, please, pull new Versatile Express related drivers for 3.8?
> The hwmon driver is acked by the subsystem maintainer who asked to get
> it merged through arm-soc.
>
Pulled into the next/drivers branch in arm-soc now. Sorry for the delay.
Thanks,
Arnd
^ permalink raw reply
* [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP
From: Jason Cooper @ 2012-10-26 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351254650-26861-3-git-send-email-gregory.clement@free-electrons.com>
On Fri, Oct 26, 2012 at 02:30:47PM +0200, Gregory CLEMENT wrote:
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Lior Amsalem <alior@marvell.com>
> ---
> arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 94b4b9e..a911f7a 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -69,6 +69,15 @@
> compatible = "marvell,armada-addr-decoding-controller";
> reg = <0xd0020000 0x258>;
> };
> +
> + sata at d00a0000 {
> + compatible = "marvell,orion-sata";
> + reg = <0xd00a0000 0x2400>;
> + interrupts = <55>;
> + clocks = <&coreclk 0>;
nit. whitespace?
thx,
Jason.
> + status = "disabled";
> + };
> +
> };
> };
>
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP
From: Andrew Lunn @ 2012-10-26 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026133154.GN18811@titan.lakedaemon.net>
On Fri, Oct 26, 2012 at 09:31:54AM -0400, Jason Cooper wrote:
> On Fri, Oct 26, 2012 at 02:30:47PM +0200, Gregory CLEMENT wrote:
> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > Signed-off-by: Lior Amsalem <alior@marvell.com>
> > ---
> > arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> > index 94b4b9e..a911f7a 100644
> > --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> > +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> > @@ -69,6 +69,15 @@
> > compatible = "marvell,armada-addr-decoding-controller";
> > reg = <0xd0020000 0x258>;
> > };
> > +
> > + sata at d00a0000 {
> > + compatible = "marvell,orion-sata";
> > + reg = <0xd00a0000 0x2400>;
> > + interrupts = <55>;
> > + clocks = <&coreclk 0>;
>
> nit. whitespace?
[Don't shoot the messenger]
How about extending checkpatch to check for this? I guess its just
spaces which should be tabs.
Andrew
^ permalink raw reply
* [GIT PULL] vexpress: soc changes for v3.8
From: Arnd Bergmann @ 2012-10-26 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350579917.4984.19.camel@hornet>
On Thursday 18 October 2012, Pawel Moll wrote:
> Hi Arnd, Olof,
>
> Could you, please, pull the Versatile Express SOC updates for 3.8?
>
Pulled into next/soc now, sorry for the delay.
Since this adds new mfd drivers, it should really have an Ack from
Samuel, and you should keep him on Cc during the submission.
Samuel: I hope you're ok with this going through the arm-soc tree,
if not please let me know and I'll take the branch out again.
Arnd
> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/pawelmoll/linux.git vexpress-soc
>
> for you to fetch changes up to f665f235c6ee31f84049920f16d1ff6e2dabc8f5:
>
> ARM: vexpress: Remove motherboard dependencies in the DTS files (2012-10-18 18:00:07 +0100)
>
> ----------------------------------------------------------------
> Pawel Moll (5):
> mfd: Versatile Express config infrastructure
> mfd: Versatile Express system registers driver
> ARM: vexpress: Add config bus components and clocks to DTs
> ARM: vexpress: Start using new Versatile Express infrastructure
> ARM: vexpress: Remove motherboard dependencies in the DTS files
>
> .../devicetree/bindings/arm/vexpress-sysreg.txt | 50 ++
> Documentation/devicetree/bindings/arm/vexpress.txt | 98 +++-
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 146 +++++-
> arch/arm/boot/dts/vexpress-v2m.dtsi | 146 +++++-
> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 121 ++++-
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 186 ++++++-
> arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 84 ++-
> arch/arm/boot/dts/vexpress-v2p-ca9.dts | 136 ++++-
> arch/arm/include/asm/hardware/sp810.h | 6 -
> arch/arm/mach-vexpress/Kconfig | 4 +-
> arch/arm/mach-vexpress/Makefile | 2 +-
> arch/arm/mach-vexpress/ct-ca9x4.c | 41 +-
> arch/arm/mach-vexpress/include/mach/motherboard.h | 81 ---
> arch/arm/mach-vexpress/platsmp.c | 3 +-
> arch/arm/mach-vexpress/v2m.c | 349 ++++---------
> drivers/mfd/Kconfig | 6 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/vexpress-config.c | 277 ++++++++++
> drivers/mfd/vexpress-sysreg.c | 552 ++++++++++++++++++++
> include/linux/vexpress.h | 121 +++++
> 20 files changed, 1993 insertions(+), 417 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
> create mode 100644 drivers/mfd/vexpress-config.c
> create mode 100644 drivers/mfd/vexpress-sysreg.c
> create mode 100644 include/linux/vexpress.h
>
>
>
>
^ permalink raw reply
* [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP
From: Gregory CLEMENT @ 2012-10-26 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026133446.GM21046@lunn.ch>
On 10/26/2012 03:34 PM, Andrew Lunn wrote:
> On Fri, Oct 26, 2012 at 09:31:54AM -0400, Jason Cooper wrote:
>> On Fri, Oct 26, 2012 at 02:30:47PM +0200, Gregory CLEMENT wrote:
>>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>> Signed-off-by: Lior Amsalem <alior@marvell.com>
>>> ---
>>> arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
>>> index 94b4b9e..a911f7a 100644
>>> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
>>> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
>>> @@ -69,6 +69,15 @@
>>> compatible = "marvell,armada-addr-decoding-controller";
>>> reg = <0xd0020000 0x258>;
>>> };
>>> +
>>> + sata at d00a0000 {
>>> + compatible = "marvell,orion-sata";
>>> + reg = <0xd00a0000 0x2400>;
>>> + interrupts = <55>;
>>> + clocks = <&coreclk 0>;
>>
>> nit. whitespace?
>
> [Don't shoot the messenger]
>
> How about extending checkpatch to check for this? I guess its just
> spaces which should be tabs.
No it is the opposite in fact! On this line it's tabs: 3 tabs of 8
whitespace, so the line start at 24. But as there is a '+', the first
tab is only 7, so it is still start at 24. Whereas for the other lines
it's 24 white spaces, so with the '+' it starts at 25. That's why I
didn't notice it, and if you apply the patch all is fine.
Now, about white spaces vs tab, I don't know what is the rule for .dts
file.
Gregory
^ permalink raw reply
* [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP
From: Andrew Lunn @ 2012-10-26 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508A945C.4010006@free-electrons.com>
> Now, about white spaces vs tab, I don't know what is the rule for .dts
> file.
I personally use tabs, but i don't see anything in the
Documentation/CodingStyle.
Maybe ask on the device tree mailing list?
Andrew
^ permalink raw reply
* [PATCH 2/2] ARM: mach-imx: CAN clock fix for i.MX53
From: Roland Stigge @ 2012-10-26 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508A6E92.1000107@antcom.de>
On 10/26/2012 01:05 PM, Roland Stigge wrote:
> On 10/26/2012 12:30 PM, Marc Kleine-Budde wrote:
>>>>> + clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate",
>>>>> "can_sel", MXC_CCM_CCGR4, 6); + clk[can1_ipg_gate] =
>>>>> imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR4, 8); +
>>>>> clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate",
>>>>> "can_sel", MXC_CCM_CCGR4, 6); + clk[can2_ipg_gate] =
>>>>> imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 8);
>>>>
>>>> This doesn't.
>>>
>>> This may be right, but unfortunately, since the introduction of
>>> your can1 + can2 clocking change, the first block stopped working
>>> for me.
>>
>> You are effectively using can2's clock for can1. Are you sure you
>> haven't mixed up can1 and can2?
>
> Just using the above patch and patch 1/2 from this series (missing can
> pinmuxing), doing like this in custom .dts:
>
> + can1: can at 53fc8000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_can1_1>;
> + clock-frequency = <66500000>;
That was the problem, since in flexcan.c probe():
if (pdev->dev.of_node)
of_property_read_u32(pdev->dev.of_node,
"clock-frequency", &clock_freq);
if (!clock_freq) {
clk_ipg = devm_clk_get(&pdev->dev, "ipg");
if (IS_ERR(clk_ipg)) {
dev_err(&pdev->dev, "no ipg clock defined\n");
err = PTR_ERR(clk_ipg);
goto failed_clock;
}
clock_freq = clk_get_rate(clk_ipg);
clk_per = devm_clk_get(&pdev->dev, "per");
if (IS_ERR(clk_per)) {
dev_err(&pdev->dev, "no per clock defined\n");
err = PTR_ERR(clk_per);
goto failed_clock;
}
}
Sorry for the noise.
The other patches are still current.
Thanks,
Roland
^ permalink raw reply
* [GIT PULL] omap plat header removal for v3.8 merge window, part1
From: Arnd Bergmann @ 2012-10-26 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019023300.GN30550@atomide.com>
On Friday 19 October 2012, Tony Lindgren wrote:
> Hi Arnd & Olof,
>
> Here's the first set of omap plat header removal for v3.8 merge
> window. I have at least one more related set coming, but I wanted
> to get these into linux next before driver patches add more
> things for me to chase down and fix.
>
> Oh, forgot to mention in the tag that the increase in diffstat
> is mostly because plat-omap/clock shared clock code is duplicated
> as that's also needed for the common clock framework patches
> coming up.
Hi Tony,
This is very cool, great work! I'm sorry for taking so long before
we processed them, I wasn't coordinating well with Olof for the last
week.
I've applied all of it to a new next/headers branch. I thought about
using the next/cleanup branch, but since it touches a lot of files
outside of arch/arm, I decided to keep it separate. We might decide
to merge it later after all.
I tried running my old multiplatform scripts again and have a few
comments, but none of them serious:
$ git grep include.*mach-omap2
arch/arm/plat-omap/debug-devices.c:#include "../mach-omap2/debug-devices.h"
arch/arm/plat-omap/dma.c:#include "../mach-omap2/soc.h"
arch/arm/plat-omap/dmtimer.c:#include "../mach-omap2/omap-pm.h"
arch/arm/plat-omap/i2c.c:#include "../mach-omap2/soc.h"
arch/arm/plat-omap/include/plat/cpu.h:#include "../../mach-omap2/soc.h"
arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap_device.h"
arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap-pm.h"
arch/arm/plat-omap/sram.c:#include "../mach-omap2/soc.h"
arch/arm/plat-omap/sram.c:#include "../mach-omap2/iomap.h"
arch/arm/plat-omap/sram.c:#include "../mach-omap2/prm2xxx_3xxx.h"
arch/arm/plat-omap/sram.c:#include "../mach-omap2/sdrc.h"
I don't like the relative include paths too much. I would have preferred
adding the mach-omap2/include/mach path in the plat-omap Makefile, but
I suppose you want to leave it like it is now since you mention you
have already built on top of it.
drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/powerdomain.h>
drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/clockdomain.h>
drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/cm2xxx_3xxx.h>
drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/prm-regbits-34xx.h>
drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/cm-regbits-34xx.h>
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:#include <mach-omap2/prm-regbits-34xx.h>
drivers/staging/tidspbridge/core/tiomap3430_pwr.c:#include <mach-omap2/cm-regbits-34xx.h>
drivers/staging/tidspbridge/rmgr/drv_interface.c:#include <mach-omap2/omap3-opp.h>
This code is broken now. I wonder whether it's time to remove it from
staging since we now have rpmsg/remoteproc, rather than getting it to
compile again.
sound/soc/omap/am3517evm.c:#include <mach-omap2/hardware.h>
sound/soc/omap/am3517evm.c:#include <mach-omap2/gpio.h>
sound/soc/omap/ams-delta.c:#include <mach-omap2/board-ams-delta.h>
sound/soc/omap/n810.c:#include <mach-omap2/hardware.h>
sound/soc/omap/sdp3430.c:#include <mach-omap2/hardware.h>
sound/soc/omap/sdp3430.c:#include <mach-omap2/gpio.h>
sound/soc/omap/zoom2.c:#include <mach-omap2/hardware.h>
sound/soc/omap/zoom2.c:#include <mach-omap2/gpio.h>
sound/soc/omap/zoom2.c:#include <mach-omap2/board-zoom.h>
Not sure if you were just missing these or if you already have other
patch lined up for them.
$ git grep include.*mach-omap1
drivers/video/omap/lcd_ams_delta.c:#include <mach-omap1/board-ams-delta.h>
drivers/video/omap/lcd_inn1510.c:#include <mach-omap1/hardware.h>
drivers/video/omap/lcd_osk.c:#include <mach-omap1/mux.h>
drivers/video/omap/lcdc.c:#include <mach-omap1/lcdc.h>
sound/soc/omap/osk5912.c:#include <mach-omap1/hardware.h>
Same thing here.
Arnd
^ permalink raw reply
* [GIT PULL] vexpress: soc changes for v3.8
From: Pawel Moll @ 2012-10-26 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210261337.16972.arnd@arndb.de>
On Fri, 2012-10-26 at 14:37 +0100, Arnd Bergmann wrote:
> Since this adds new mfd drivers, it should really have an Ack from
> Samuel, and you should keep him on Cc during the submission.
Uh, yes, apologies. I think it happened because get_maintainer.pl said
"supporter" not "maintainer". Will know better next time.
> Samuel: I hope you're ok with this going through the arm-soc tree,
> if not please let me know and I'll take the branch out again.
... and I'll try to address any issues.
Thanks!
Pawe?
^ permalink raw reply
* [PATCH 2/2] ARM: mach-imx: CAN clock fix for i.MX53
From: Marc Kleine-Budde @ 2012-10-26 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508A95B3.3010306@antcom.de>
On 10/26/2012 03:52 PM, Roland Stigge wrote:
> On 10/26/2012 01:05 PM, Roland Stigge wrote:
>> On 10/26/2012 12:30 PM, Marc Kleine-Budde wrote:
>>>>>> + clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate",
>>>>>> "can_sel", MXC_CCM_CCGR4, 6); + clk[can1_ipg_gate] =
>>>>>> imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR4, 8); +
>>>>>> clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate",
>>>>>> "can_sel", MXC_CCM_CCGR4, 6); + clk[can2_ipg_gate] =
>>>>>> imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 8);
>>>>>
>>>>> This doesn't.
>>>>
>>>> This may be right, but unfortunately, since the introduction of
>>>> your can1 + can2 clocking change, the first block stopped working
>>>> for me.
>>>
>>> You are effectively using can2's clock for can1. Are you sure you
>>> haven't mixed up can1 and can2?
>>
>> Just using the above patch and patch 1/2 from this series (missing can
>> pinmuxing), doing like this in custom .dts:
>>
>> + can1: can at 53fc8000 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_can1_1>;
>> + clock-frequency = <66500000>;
>
> That was the problem, since in flexcan.c probe():
>
>
> if (pdev->dev.of_node)
> of_property_read_u32(pdev->dev.of_node,
> "clock-frequency", &clock_freq);
>
> if (!clock_freq) {
> clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> if (IS_ERR(clk_ipg)) {
> dev_err(&pdev->dev, "no ipg clock defined\n");
> err = PTR_ERR(clk_ipg);
> goto failed_clock;
> }
> clock_freq = clk_get_rate(clk_ipg);
>
> clk_per = devm_clk_get(&pdev->dev, "per");
> if (IS_ERR(clk_per)) {
> dev_err(&pdev->dev, "no per clock defined\n");
> err = PTR_ERR(clk_per);
> goto failed_clock;
> }
> }
>
> Sorry for the noise.
We have the possibility to specify the clock frequency in the device
tree as the power pc has no support for generic clock yet.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/641db69d/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: Remove unnecessary prototype for kobjsize()
From: Tobias Klauser @ 2012-10-26 14:29 UTC (permalink / raw)
To: linux-arm-kernel
The prototype for kobjsize() is already defined in linux/mm.h which is
included where kobjsize() is used.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
arch/arm/include/asm/pgtable-nommu.h | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-nommu.h b/arch/arm/include/asm/pgtable-nommu.h
index 7ec60d6..e921533 100644
--- a/arch/arm/include/asm/pgtable-nommu.h
+++ b/arch/arm/include/asm/pgtable-nommu.h
@@ -69,12 +69,6 @@ static inline int pte_file(pte_t pte) { return 0; }
#define pgprot_writecombine(prot) __pgprot(0)
#define pgprot_dmacoherent(prot) __pgprot(0)
-
-/*
- * These would be in other places but having them here reduces the diffs.
- */
-extern unsigned int kobjsize(const void *objp);
-
/*
* No page table caches to initialise.
*/
--
1.7.5.4
^ permalink raw reply related
* [RFC 0/2] Representing interrupt affinity in devicetree
From: Mark Rutland @ 2012-10-26 14:48 UTC (permalink / raw)
To: linux-arm-kernel
Current devicetree bindings for devices which use cpu-affine shared interrupts
assume that interrupts are listed in ascending order of physical cpu id
(MPIDR.Aff{2,1,0}). This is problematic for drivers because:
(1) The driver must convert each physical id to a logical id for the purpose of
managing interrupts.
(2) In multi-cluster systems the physical ids are not necessarily contiguous,
and drivers cannot simply iterate over ids from 0 to NR_CPUS.
(3) It is not possible to specify sets of interrupts which are wired to a
subset of cpus (i.e. clusters) not starting at physical id 0, as we can't
specify which cpu to start from, and can't skip cpus. This makes it
impossible to represent some devices (e.g. cpu PMUs) which may not exist
in the first cluster.
(4) Some devices may either be wired with PPIs or SPIs. It is not possible to
differentiate the two cases in general from the interrupts list (e.g. when
a device has multiple PPIs wired to all cpus).
To represent the general case, we require a mechanism to describe the cpu
affinity of a device, and a consistent way to map each interrupt to a cpu (or
set of cpus). So far, the only usable mechanism I've been able to come up with
is the following:
In addition to the interrupts list, we add an optional 'affinity' list - a list
of phandles, where each phandle points to a cpu node or a cluster node (from
Lorenzo Pieralisi's cpu topology bindings [1]). Each element in the interrupts
list has a corresponding element in the affinity list, at the same index.
Interrupts defined as cluster affine are PPIs, and those defined cpu-affine are
SPIs. This would look something like:
> device at 0 {
> compatible = "example,example-affine-device"
> interrupts = <0 130 4>,
> <0 131 4>,
> <1 12 4>;
> affinity = <&cpu0>,
> <&cpu1>,
> <&cluster1>;
> };
To request/free interrupts, drivers would walk over all interrupts, and request
the affine cpu(s), which can be automatically mapped to logical ids by common
code. This fixes issues 1, 2, and 3. While 4 is partially solved, it doesn't
provide any additional information when you may have multiple interrupts for a
cpu.
The following patches implement common code that could be used by drivers,
assuming the devicetree uses the cluster topology bindings. To not break
existing bindings, when an affinity parameter is not present, interrupts are
assumed to be in increasing order of MPIDR.Aff0, starting at 0. Logical mapping
is always applied to cpu ids.
The patches are based on v3.7-rc2, with Lorenzo Pieralisi's logical mappings
look-up patch [2] applied.
Using this code, an interrupt registration loop would look something like:
> void request_irqs(...)
> {
> int i, irqs, irq, c, cpus, cpu;
>
> irqs = pdev->num_resources;
> for (i = 0; i < irqs; i++) {
> irq = platform_get_irq(pdev, i);
> cpus = count_irq_affine_cpus(pdev, i);
>
> /* SPI if affine to 1 cpu */
> if (cpus == 1) {
> cpu = get_irq_affine_cpu(pdev, i, 1);
> if (cpu < 0)
> continue;
> irq_set_affinity(irq, cpumask_of(cpu));
> request_irq(...);
>
> continue;
> }
>
> /* PPI, build cpumask and register */
> for (c = 0; c < cpus; c++) {
> cpu = get_irq_affine_cpu(pdev, i, c);
>
> /* test, add to mask */
> ...
> }
>
> request_percpu_irq(...);
> }
> }
Does anyone have any better ideas?
Any and all feedback welcome.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080869.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/125882.html
Mark Rutland (2):
of: add of_property_count_phandles
ARM: Add functions to parse dt irq affinity
arch/arm/include/asm/dt_irq.h | 64 ++++++++++++++++
arch/arm/kernel/devtree.c | 165 +++++++++++++++++++++++++++++++++++++++++
drivers/of/base.c | 39 ++++++++++
include/linux/of.h | 8 ++
4 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/dt_irq.h
^ permalink raw reply
* [PATCH 1/2] of: add of_property_count_phandles
From: Mark Rutland @ 2012-10-26 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351262925-10306-1-git-send-email-mark.rutland@arm.com>
Though of_parse_phandle handles lists of phandles, and takes an index
parameter, there is no standard way of discovering how many phandles are
present on a node. This patch adds a function to count how many phandles
are in a phandle list.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
---
drivers/of/base.c | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/of.h | 8 ++++++++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index af3b22a..30ae562 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -884,6 +884,45 @@ int of_property_count_strings(struct device_node *np, const char *propname)
EXPORT_SYMBOL_GPL(of_property_count_strings);
/**
+ * of_property_count_phandles - find and return the number of phandles from a
+ * multiple phandles property.
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device tree node and retrieve the number of
+ * phandles contained in it. Returns the number of phandles on success, -ENOENT
+ * if the property does not exist, -ENODATA if there are no phandles, and
+ * -EINVAL if the property is not correctly sized for an array of phandles.
+ */
+int of_property_count_phandles(struct device_node *np, const char *propname)
+{
+ int size, count, i;
+ const __be32 *phandle;
+
+ phandle = of_get_property(np, propname, &size);
+
+ if (!phandle)
+ return -ENOENT;
+ if (size == 0)
+ return -ENODATA;
+ if (size % (sizeof *phandle))
+ return -EINVAL;
+
+ count = size / (sizeof(*phandle));
+
+ /* Check the phandle targets actually exist */
+ for (i = 0; i < count; i++) {
+ struct device_node *node = of_parse_phandle(np, propname, i);
+ if (!node)
+ return -EINVAL;
+ of_node_put(node);
+ }
+
+ return count;
+}
+EXPORT_SYMBOL_GPL(of_property_count_phandles);
+
+/**
* of_parse_phandle - Resolve a phandle property to a device_node pointer
* @np: Pointer to device node holding phandle property
* @phandle_name: Name of property holding a phandle value
diff --git a/include/linux/of.h b/include/linux/of.h
index b4e50d5..1f03f46 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -258,6 +258,8 @@ extern int of_modalias_node(struct device_node *node, char *modalias, int len);
extern struct device_node *of_parse_phandle(struct device_node *np,
const char *phandle_name,
int index);
+extern int of_property_count_phandles(struct device_node *np,
+ const char *propname);
extern int of_parse_phandle_with_args(struct device_node *np,
const char *list_name, const char *cells_name, int index,
struct of_phandle_args *out_args);
@@ -411,6 +413,12 @@ static inline int of_property_match_string(struct device_node *np,
return -ENOSYS;
}
+static inline int of_property_count_phandles(struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
static inline struct device_node *of_parse_phandle(struct device_node *np,
const char *phandle_name,
int index)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] ARM: Add functions to parse dt irq affinity
From: Mark Rutland @ 2012-10-26 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351262925-10306-1-git-send-email-mark.rutland@arm.com>
This patch adds functions to handle parsing cpu affinity of interrupts
from devicetree. Devices using these functions are dealt with as
follows:
* If the device was not initialised from devicetree, it is considered to
be affine to all CPUs, and interrupts are assumed to be in order of
physical CPU id (MPIDR.Aff0).
* If the device was initialised from devicetree, but does not have an
"affinity" value, the device is considered to be affine to all CPUs,
and interupts are assumed to be in order of physical CPU id
(MPIDR.Aff0).
* If the device was initialised from devicetree, and has an "affinity"
value, then the interrupt at index i in the interrupts list is affine
to the cpu or cluster pointed to by the entry in the affinity list at
index i. Interrupts affine to a cluster are PPIs, and interrupts
affine to a single cpu are SPIs.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm/include/asm/dt_irq.h | 64 ++++++++++++++++
arch/arm/kernel/devtree.c | 164 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 228 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/dt_irq.h
diff --git a/arch/arm/include/asm/dt_irq.h b/arch/arm/include/asm/dt_irq.h
new file mode 100644
index 0000000..ed86ca8
--- /dev/null
+++ b/arch/arm/include/asm/dt_irq.h
@@ -0,0 +1,64 @@
+/*
+ * arch/arm/include/asm/dt_irq.h
+ *
+ * Copyright (C) 2009 ARM Ltd. <mark.rutland@arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#ifndef __ASMARM_DT_IRQ_H
+#define __ASMARM_DT_IRQ_H
+
+#include <linux/cpumask.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#ifdef CONFIG_OF
+
+extern int count_cpus_in_cluster(struct device_node *cluster);
+extern struct device_node *of_get_cluster_cpu(struct device_node *cluster, int idx);
+extern int count_irq_affine_cpus(struct platform_device *pdev, int irq_idx);
+extern int of_get_logical_cpu_id(struct device_node *cpu);
+extern int get_irq_affine_cpu(struct platform_device *pdev, int irq_idx, int cpu_idx);
+extern int get_device_cpu_affinity(struct platform_device *pdev, cpumask_t *mask);
+
+#else /* CONFIG_OF */
+
+static int count_cpus_in_cluster(struct device_node *cluster)
+{
+ return -EINVAL;
+}
+
+static struct device_node *of_get_cluster_cpu(struct device_node *cluster, int idx)
+{
+ return NULL;
+}
+
+static int count_irq_affine_cpus(struct platform_device *pdev, int irq_idx)
+{
+ return 1;
+}
+
+static int of_get_logical_cpu_id(struct device_node *cpu)
+{
+ return -EINVAL;
+}
+
+static int get_irq_affine_cpu(struct platform_device *pdev, int irq_idx, int cpu_idx);
+{
+ if (cpu_idx != 0)
+ return -EINVAL;
+
+ return get_logical_index(irq_idx);
+}
+
+static int get_device_cpu_affinity(struct platform_device *pdev, cpumask_t *mask)
+{
+ cpumask_setall(mask);
+ return 0;
+}
+
+#endif /* CONFIG_OF */
+#endif /* ASMARM_DT_IRQ_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index bee7f9d..4026827 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -132,3 +132,167 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
return mdesc_best;
}
+
+int count_cpus_in_cluster(struct device_node *cluster)
+{
+ struct device_node *cpus, *cpu, *cpu_cluster;
+ int count = 0;
+
+ cpus = of_find_node_by_path("/cpus");
+ if (!cpus)
+ return -EINVAL;
+
+ for_each_child_of_node(cpus, cpu) {
+ cpu_cluster = of_parse_phandle(cpu, "cluster", 0);
+ if (cpu_cluster == cluster)
+ count++;
+ of_node_put(cpu_cluster);
+ }
+
+ of_node_put(cpus);
+ return count;
+}
+
+struct device_node *of_get_cluster_cpu(struct device_node *cluster, int idx)
+{
+ struct device_node *cpus, *cpu, *cpu_cluster;
+
+ cpus = of_find_node_by_path("/cpus");
+ if (!cpus)
+ return NULL;
+
+ for_each_child_of_node(cpus, cpu) {
+ cpu_cluster = of_parse_phandle(cpu, "cluster", 0);
+ if (cpu_cluster == cluster && idx == 0) {
+ of_node_put(cpu_cluster);
+ break;
+ }
+
+ idx--;
+ of_node_put(cpu_cluster);
+ }
+
+ of_node_put(cpus);
+ return cpu;
+}
+
+int count_irq_affine_cpus(struct platform_device *pdev, int irq_idx)
+{
+ struct device_node *node, *affine;
+ int ret = -EINVAL;
+
+ if (!pdev)
+ return -EINVAL;
+
+ node = pdev->dev.of_node;
+
+ /*
+ * For devices not initialised from devicetree, we only support sets of
+ * SPIs.
+ */
+ if (!node)
+ return 1;
+
+ affine = of_parse_phandle(node, "affinity", irq_idx);
+
+ /*
+ * A device initialised from devicetree without an affinity parameter
+ * is assumed to have a set of cpu-affine SPIs (so 1 cpu per irq).
+ */
+ if (!affine)
+ return 1;
+
+ if (!of_node_cmp(affine->name, "cpu"))
+ ret = 1;
+ else if (!of_node_cmp(affine->name, "cluster"))
+ ret = count_cpus_in_cluster(affine);
+
+ of_node_put(affine);
+ return ret;
+}
+
+int of_get_logical_cpu_id(struct device_node *cpu)
+{
+ u32 mpidr;
+ if (of_property_read_u32(cpu, "reg", &mpidr))
+ return -EINVAL;
+
+ return get_logical_index(mpidr);
+}
+
+int get_irq_affine_cpu(struct platform_device *pdev, int irq_idx, int cpu_idx)
+{
+ struct device_node *node, *affine, *cpu;
+ int ret = -EINVAL;
+
+ if (!pdev)
+ return -EINVAL;
+
+ node = pdev->dev.of_node;
+
+ /*
+ * Without devicetree, we only support single cluster systems.
+ * We assume 1 SPI per CPU.
+ * CPUs are assumed to be in increasing order of MPIDR.Aff{0},
+ * starting at 0. MPIDR.Aff{2,1} are assumed to be 0.
+ */
+ if (!node) {
+ if (cpu_idx != 0)
+ return -EINVAL;
+ return get_logical_index(irq_idx);
+ }
+
+ affine = of_parse_phandle(node, "affinity", irq_idx);
+ if (!affine) {
+ if (cpu_idx != 0)
+ return -EINVAL;
+ return get_logical_index(irq_idx);
+ }
+
+ if (!of_node_cmp(affine->name, "cluster")) {
+ cpu = of_get_cluster_cpu(affine, cpu_idx);
+ if (cpu) {
+ ret = of_get_logical_cpu_id(cpu);
+ of_node_put(cpu);
+ }
+ }
+ else if (!of_node_cmp(affine->name, "cpu")) {
+ ret = of_get_logical_cpu_id(affine);
+ }
+
+ of_node_put(affine);
+ return ret;
+}
+
+int get_device_cpu_affinity(struct platform_device *pdev, cpumask_t *mask)
+{
+ struct device_node *node;
+ int affines, a, cpus, c, cpu;
+
+ node = pdev->dev.of_node;
+
+ if (!node) {
+ cpumask_setall(mask);
+ return 0;
+ }
+
+ affines = of_property_count_phandles(node, "affinity");
+ if (affines == -ENOENT) {
+ cpumask_setall(mask);
+ return 0;
+ }
+
+ if (affines < 0)
+ return -EINVAL;
+
+ for (a = 0; a < affines; a++) {
+ cpus = count_irq_affine_cpus(pdev, a);
+ for (c = 0; c < cpus; c++) {
+ cpu = get_irq_affine_cpu(pdev, a, c);
+ if (cpu >= 0)
+ cpumask_set_cpu(cpu, mask);
+ }
+ }
+
+ return 0;
+}
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox