* [PATCH v2 0/9] ARM: multi-platform kconfig cleanup and mach-virt removal
From: Rob Herring @ 2014-02-12 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212134655.GC29132@mudshark.cambridge.arm.com>
On Wed, Feb 12, 2014 at 7:46 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Feb 12, 2014 at 01:26:41PM +0000, Arnd Bergmann wrote:
>> On Tuesday 11 February 2014, Rob Herring wrote:
>> > The previous version [1] was mainly a discussion about v6 vs. v6K.
>> > Several platforms have this wrong and incorrectly select v6 when the
>> > more optimal v6K option could be used. After more research, my memory
>> > about i.MX31 was wrong and it does need to remain v6.
>>
>> Just curious: do you have more information on this? Are all i.MX31 ARMv6
>> and all i.MX35 v6k as the current Kconfig claims, or is it more
>> complicated?
>
> Slightly tangential, but the one to watch out for is 1136. Prior to r1 (i.e.
> r0pX), it is v6 but r1pX+ are v6k (without SMP).
Right. I originally was thinking that the MX31 1.x was r0pX and MX31
2.x was r1pX and that there are no 1.x chips around. However, after
checking the errata sheet, 1.x is r0p1 and 2.x is r0p4. It must have
been one of the other 1136 chips we did that moved to r1pX.
>> * integrator and realview apparently allow both CPU_V6 and CPU_V6K
>> to be manually selected. Is that actually the correct behavior
>> in that both kinds of core tiles exist?
>
> I have 1136 r0p1 on an integrator CP, so I suppose it could also take an
> 1136 r1pX without any trouble.
Presumably some of both exist which is why the config options are as they are?
Rob
^ permalink raw reply
* [PATCH] clk: sirf: update copyright years to 2014
From: Barry Song @ 2014-02-12 14:16 UTC (permalink / raw)
To: linux-arm-kernel
From: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
drivers/clk/sirf/clk-atlas6.c | 3 ++-
drivers/clk/sirf/clk-common.c | 3 ++-
drivers/clk/sirf/clk-prima2.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/sirf/clk-atlas6.c b/drivers/clk/sirf/clk-atlas6.c
index f9f4a15..d63b76c 100644
--- a/drivers/clk/sirf/clk-atlas6.c
+++ b/drivers/clk/sirf/clk-atlas6.c
@@ -1,7 +1,8 @@
/*
* Clock tree for CSR SiRFatlasVI
*
- * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ * Copyright (c) 2011 - 2014 Cambridge Silicon Radio Limited, a CSR plc group
+ * company.
*
* Licensed under GPLv2 or later.
*/
diff --git a/drivers/clk/sirf/clk-common.c b/drivers/clk/sirf/clk-common.c
index 7dde6a8..37af51c 100644
--- a/drivers/clk/sirf/clk-common.c
+++ b/drivers/clk/sirf/clk-common.c
@@ -1,7 +1,8 @@
/*
* common clks module for all SiRF SoCs
*
- * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ * Copyright (c) 2011 - 2014 Cambridge Silicon Radio Limited, a CSR plc group
+ * company.
*
* Licensed under GPLv2 or later.
*/
diff --git a/drivers/clk/sirf/clk-prima2.c b/drivers/clk/sirf/clk-prima2.c
index 7adc5c7..6968e2e 100644
--- a/drivers/clk/sirf/clk-prima2.c
+++ b/drivers/clk/sirf/clk-prima2.c
@@ -1,7 +1,8 @@
/*
* Clock tree for CSR SiRFprimaII
*
- * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ * Copyright (c) 2011 - 2014 Cambridge Silicon Radio Limited, a CSR plc group
+ * company.
*
* Licensed under GPLv2 or later.
*/
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: shmobile: set proper DMA masks for Ether devices
From: Ben Dooks @ 2014-02-12 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB7642.4000506@cogentembedded.com>
On 12/02/14 13:25, Sergei Shtylyov wrote:
> Hello.
>
> On 12-02-2014 15:49, Ben Dooks wrote:
>
>>> Ether MAC is a DMA-capable device and so should have 'dev.dma_mask' and
>>> 'dev.coherent_dma_mask' fields set properly, to reflect 32-bit DMA
>>> addressing
>>> ability. Currently, the code works without DMA masks but in the
>>> future, when
>>> support for NETIF_F_HIGHDMA & NETIF_F_SG would be added to the
>>> 'sh_eth' driver,
>>> the DMA masks should start to matter...
>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
>> Hi, do you have a git branch available with all the changes for getting
>> ethernet working on rcar please?
>
> Depends on whether you want it working via DT or mere platform
> devices. If the second, it's 3.14-rc1. If DT, I don't have a branch,
> only several patches to apply atop of the current 'renesas.git' repo's
> 'devel' branch that I've posted last week (note that only R8A779x is
> currently supported by these patches and NFS boot timeout is still an
> issue with them).
ok, I have a slightly earlier version which seems to work with nfs
boot for me.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH RFC v3 3/3] Documentation: arm: define DT idle states bindings
From: Lorenzo Pieralisi @ 2014-02-12 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADGdYn6O6Vpye8knxXdpGzVQNy9p6mM1Sf-bBs7aQtQv6ReoHQ@mail.gmail.com>
Hi Amit,
On Wed, Feb 12, 2014 at 11:39:28AM +0000, Amit Kachhap wrote:
> Hi Lorenzo,
>
> This patch series looks nice and explains the ARM C state DT bindings clearly.
Thank you.
[...]
> > + - entry-latency
> > + Usage: Required
> > + Value type: <prop-encoded-array>
> > + Definition: u32 value representing worst case latency
> > + in microseconds required to enter the idle state.
> I liked your V2 version of OPP based latency more. However in this way
> also latency supplied can correspond to max OPP and based on the
> current OPP, the cpuidle driver can compute the new latency
> proportionately. In case of frequency this can be linear but may not
> be linear for residency.
I understand that, but the bindings do not preclude having a list instead of
just worst case value. Let's go for the worst case and build on it
(when we have a decent method to express OPP dependencies in the DT bindings,
that is not the case at present). Your point is taken, I just want a first
version that provides the groundwork on top of which more complex
bindings can be defined.
> > +
> > + - exit-latency
> > + Usage: Required
> > + Value type: <prop-encoded-array>
> > + Definition: u32 value representing worst case latency
> > + in microseconds required to exit the idle state.
> > +
> > + - min-residency
> > + Usage: Required
> > + Value type: <prop-encoded-array>
> > + Definition: u32 value representing time in microseconds
> > + required for the CPU to be in the idle state to
> > + make up for the dynamic power consumed to
> > + enter/exit the idle state in order to break even
> > + in terms of power consumption compared to idle
> > + state index 1 (idle_standby).
> > +
> > + - power-domains
> > + Usage: Optional
> > + Value type: <prop-encoded-array>
> > + Definition: List of power domain specifiers ([1]) describing
> > + the power domains that are affected by the idle
> > + state entry.
> I can see power-domains used in 2 places. First in C state definitions
> and second in cpu node cache descriptions. I am not sure but if
> possible than this can be put in one place.
Power domain specifiers are there to link devices (ie caches) to the
idle states. We have to know which devices are affected by an idle state
entry, and that's done through the power-domain (ie all devices that
belong to a power domain affected by the idle state entry must be acted
upon).
All devices have to be linked to the power domain they belong to,
possibly by using a hierarchical representation (to group devices under
a power domain and avoid duplicating the power domain specifier).
> > +
> > + - cache-state-retained
> > + Usage: See definition
> > + Value type: <none>
> > + Definition: if present cache memory is retained on power down,
> > + otherwise it is lost.
> Can the DT bindings support both retained and non-retained with
> different C states? The example shown does not use the retained flag.
> I guess than many combinations are possible.
> Processor retained, cache non-retained = C state 2
> Processor non retained , cache retained = C state 3
> Processor non retained, cache non retained = C state 4
Yes. Those are per idle state properties so the can be used as you defined,
I cannot think of any issue regarding those boolean properties at the
moment, but if you do please flag it up.
Thanks !
Lorenzo
^ permalink raw reply
* [PATCH 2/2] ehci-platform: Change compatible string from usb-ehci to ehci-platform
From: Maxime Ripard @ 2014-02-12 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FA4118.2030100@redhat.com>
On Tue, Feb 11, 2014 at 04:26:16PM +0100, Hans de Goede wrote:
> > I'm even OK with removing "usb-ehci" and "usb-ohci" compatibles
> > from all OMAP dts files since they aren't really compatible with
> > the original PPC driver.
>
> I don't think that is necessary, as your grep has shown there are a
> lot of dts files using compatible = "foo", "usb-?hci"; and some may
> even have the dts in firmware, so we should simply make sure not to
> break such dts.
For these devices, we can't do much, but at least for the DT that are
in Linux, relying on the fact that there is no driver having a
compatible of "usb-ehci" to work looks very fragile. I'd be in favour
of removing it from the OMAP DTs, and every affected DTs.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140212/bac7bc59/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: smp: Add a memory barrier before we start secondary cores
From: Mark Brown @ 2014-02-12 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212134332.GK29702@arm.com>
On Wed, Feb 12, 2014 at 01:43:32PM +0000, Catalin Marinas wrote:
> I think we can drop this until Vincent clarifies the synchronisation
> requirements (still wondering whether spinlocks are needed).
Even if they're not actually required for the topology code the fact
that we're having to think about what is needed suggests that the code
is going to end up being clearer and hence more maintainable going
forwards if we add it.
-------------- 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/20140212/ce0335a1/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/7] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
From: Tomasz Figa @ 2014-02-12 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391788548-13056-2-git-send-email-thomas.ab@samsung.com>
Hi Thomas,
On 07.02.2014 16:55, Thomas Abraham wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> Lookup for the optional boost-frequency property in cpu0 node and if
> available, enable support for boost mode frequencies. The frequencies
> usable in boost mode are determined while preparing the cpufreq table
> from the list of operating points available.
>
> In addition to this, enable the CPU_FREQ_BOOST_SW config option for
> this driver by default. On platforms that do not support boost mode,
> the boost mode frequencies will not be specified in cpu0 node and
> hence the boost mode support will not be enabled. Since this driver
> anyways depends on THERMAL config option, it is safe to enable
> CPU_FREQ_BOOST_SW config option as default.
>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
> Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 2 ++
> drivers/cpufreq/Kconfig | 1 +
> drivers/cpufreq/cpufreq-cpu0.c | 3 +++
> 3 files changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> index f055515..60f321a 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> @@ -19,6 +19,8 @@ Optional properties:
> - cooling-min-level:
> - cooling-max-level:
> Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
> +- boost-frequency:
> + Please refer to Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>
> Examples:
>
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index 4b029c0..52cc704 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -187,6 +187,7 @@ config GENERIC_CPUFREQ_CPU0
> tristate "Generic CPU0 cpufreq driver"
> depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
> select PM_OPP
> + select CPU_FREQ_BOOST_SW
> help
> This adds a generic cpufreq driver for CPU0 frequency management.
> It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index 0c12ffc..06539eb 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -195,6 +195,9 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
> transition_latency += ret * 1000;
> }
>
> + if (of_find_property(cpu_dev->of_node, "boost-frequency", NULL))
> + cpu0_cpufreq_driver.boost_supported = true;
> +
> ret = cpufreq_register_driver(&cpu0_cpufreq_driver);
> if (ret) {
> pr_err("failed register driver: %d\n", ret);
>
I'd say that boost should be enabled depending on user's preference, as
done before in Exynos cpufreq driver. So both presence of
boost-frequency property and state of CPU_FREQ_BOOST_SW should be
considered.
As for CPU_FREQ_BOOST_SW, I don't think it should be always selected,
but ather, either converted to a user-selectable bool entry or made
selectable by other entry, like current ARM_EXYNOS_CPU_FREQ_BOOST_SW.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH] ARM: shmobile: set proper DMA masks for Ether devices
From: Sergei Shtylyov @ 2014-02-12 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB8526.9000601@codethink.co.uk>
Hello.
On 12-02-2014 18:28, Ben Dooks wrote:
>>>> Ether MAC is a DMA-capable device and so should have 'dev.dma_mask' and
>>>> 'dev.coherent_dma_mask' fields set properly, to reflect 32-bit DMA
>>>> addressing
>>>> ability. Currently, the code works without DMA masks but in the
>>>> future, when
>>>> support for NETIF_F_HIGHDMA & NETIF_F_SG would be added to the
>>>> 'sh_eth' driver,
>>>> the DMA masks should start to matter...
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>> Hi, do you have a git branch available with all the changes for getting
>>> ethernet working on rcar please?
>> Depends on whether you want it working via DT or mere platform
>> devices. If the second, it's 3.14-rc1. If DT, I don't have a branch,
>> only several patches to apply atop of the current 'renesas.git' repo's
>> 'devel' branch that I've posted last week (note that only R8A779x is
>> currently supported by these patches and NFS boot timeout is still an
>> issue with them).
> ok, I have a slightly earlier version which seems to work with nfs
> boot for me.
There's no "slightly earlier version" (unless you mean DT support for
BOCK-W posted months ago). Issue with NFS is not fatal, it boots fine, just
somewhat slow.
WBR, Sergei
^ permalink raw reply
* [PATCH v4] gpio: davinci: reuse for keystone soc
From: Linus Walleij @ 2014-02-12 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391615244-12014-1-git-send-email-grygorii.strashko@ti.com>
On Wed, Feb 5, 2014 at 4:47 PM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
> The similar GPIO HW block is used by keystone SoCs as
> in Davinci SoCs.
> Hence, reuse Davinci GPIO driver for Keystone taking into
> account that Keystone contains ARM GIC IRQ controller which
> is implemented using IRQ Chip.
>
> Documentation:
> http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> Changes in v4:
> - rebased on top of v3.14 +
> [patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
I tried applying this and it does not apply on the "devel" branch
in the GPIO tree. Since I haven't touched one line of code in the
DaVinci driver since v3.14-rc1 I seriously doubt that this is
rebased on v3.14[-rc].
Can you please rebase the patch onto v3.14-rc1 for real and
resend it?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv3 2/2] arm: Get rid of meminfo
From: Grygorii Strashko @ 2014-02-12 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392153265-14439-3-git-send-email-lauraa@codeaurora.org>
Hi Laura,
On 02/11/2014 11:14 PM, Laura Abbott wrote:
> memblock is now fully integrated into the kernel and is the prefered
> method for tracking memory. Rather than reinvent the wheel with
> meminfo, migrate to using memblock directly instead of meminfo as
> an intermediate.
>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> ---
> arch/arm/include/asm/mach/arch.h | 4 +-
> arch/arm/include/asm/memblock.h | 3 +-
> arch/arm/include/asm/setup.h | 23 ------
> arch/arm/kernel/atags_parse.c | 5 +-
> arch/arm/kernel/devtree.c | 5 --
> arch/arm/kernel/setup.c | 30 ++------
> arch/arm/mach-clps711x/board-clep7312.c | 7 +-
> arch/arm/mach-clps711x/board-edb7211.c | 10 +--
> arch/arm/mach-clps711x/board-p720t.c | 2 +-
> arch/arm/mach-footbridge/cats-hw.c | 2 +-
> arch/arm/mach-footbridge/netwinder-hw.c | 2 +-
> arch/arm/mach-msm/board-halibut.c | 6 --
> arch/arm/mach-msm/board-mahimahi.c | 13 +---
> arch/arm/mach-msm/board-msm7x30.c | 3 +-
> arch/arm/mach-msm/board-sapphire.c | 13 ++--
> arch/arm/mach-msm/board-trout.c | 8 +--
> arch/arm/mach-orion5x/common.c | 3 +-
> arch/arm/mach-orion5x/common.h | 3 +-
> arch/arm/mach-pxa/cm-x300.c | 3 +-
> arch/arm/mach-pxa/corgi.c | 10 +--
> arch/arm/mach-pxa/eseries.c | 9 +--
> arch/arm/mach-pxa/poodle.c | 8 +--
> arch/arm/mach-pxa/spitz.c | 8 +--
> arch/arm/mach-pxa/tosa.c | 8 +--
> arch/arm/mach-realview/core.c | 11 +--
> arch/arm/mach-realview/core.h | 3 +-
> arch/arm/mach-realview/realview_pb1176.c | 8 +--
> arch/arm/mach-realview/realview_pbx.c | 17 ++---
> arch/arm/mach-s3c24xx/mach-smdk2413.c | 8 +--
> arch/arm/mach-s3c24xx/mach-vstms.c | 8 +--
> arch/arm/mach-sa1100/assabet.c | 2 +-
> arch/arm/mm/init.c | 67 +++++++-----------
> arch/arm/mm/mmu.c | 115 +++++++++---------------------
The arch/arm/mm/nommu.c has to be updated too :)
[...]
I've tested your change on keystone (with some additional printouts in sanity_check_meminfo())
and got following results:
- without your change + HIGHMEM=ON
[ 0.000000] ==== memblock_limit0x00000000af800000, arm_lowmem_limit0x00000000af800000 high_memoryef800000 vmalloc_limit0x00000000af800000
- without your change + HIGHMEM=OFF
[ 0.000000] Truncating RAM at 80000000-bfffffff to -af7fffff (vmalloc region overlap).
[ 0.000000] ==== memblock_limit0x00000000af800000, arm_lowmem_limit0x00000000af800000 high_memoryef800000 vmalloc_limit0x00000000af800000
- with your change + HIGHMEM=ON
[ 0.000000] ==== memblock_limit0x00000000af800000, arm_lowmem_limit0x00000000af800000 high_memoryef800000 vmalloc_limit0x00000000af800000
- with your change + HIGHMEM=OFF
[ 0.000000] Truncating RAM at 0x0000000080000000-0x00000000c0000000 to -0x0000000010800000
^printout changed
[ 0.000000] ==== memblock_limit0x00000000af800000, arm_lowmem_limit0x00000000af800000 high_memoryef800000 vmalloc_limit0x00000000af800000
Keystone mem defined as: from at 0x80000000 size at 0x40000000 (LPAE=OFF)
As result, i have few comments regarding sanity_check_meminfo() changes as I think there are
some issues &side effects changes at least in printouts - see below.
> memblock_reserve(__pa(_sdata), _end - _sdata);
> @@ -413,54 +397,53 @@ free_memmap(unsigned long start_pfn, unsigned long end_pfn)
> /*
> * The mem_map array can get very big. Free the unused area of the memory map.
> */
> -static void __init free_unused_memmap(struct meminfo *mi)
> +static void __init free_unused_memmap(void)
> {
> - unsigned long bank_start, prev_bank_end = 0;
> - unsigned int i;
> + unsigned long start, prev_end = 0;
> + struct memblock_region *reg;
>
> /*
> * This relies on each bank being in address order.
> * The banks are sorted previously in bootmem_init().
> */
> - for_each_bank(i, mi) {
> - struct membank *bank = &mi->bank[i];
> -
> - bank_start = bank_pfn_start(bank);
> + for_each_memblock(memory, reg) {
> + start = __phys_to_pfn(reg->base);
memblock_region_memory_base_pfn() can be used here.
>
> #ifdef CONFIG_SPARSEMEM
> /*
> * Take care not to free memmap entries that don't exist
> * due to SPARSEMEM sections which aren't present.
> */
> - bank_start = min(bank_start,
> - ALIGN(prev_bank_end, PAGES_PER_SECTION));
> + start = min(start,
> + ALIGN(prev_end, PAGES_PER_SECTION));
> #else
> /*
> * Align down here since the VM subsystem insists that the
> * memmap entries are valid from the bank start aligned to
> * MAX_ORDER_NR_PAGES.
> */
> - bank_start = round_down(bank_start, MAX_ORDER_NR_PAGES);
> + start = round_down(start, MAX_ORDER_NR_PAGES);
> #endif
> /*
> * If we had a previous bank, and there is a space
> * between the current bank and the previous, free it.
> */
> - if (prev_bank_end && prev_bank_end < bank_start)
> - free_memmap(prev_bank_end, bank_start);
> + if (prev_end && prev_end < start)
> + free_memmap(prev_end, start);
>
> /*
> * Align up here since the VM subsystem insists that the
> * memmap entries are valid from the bank end aligned to
> * MAX_ORDER_NR_PAGES.
> */
> - prev_bank_end = ALIGN(bank_pfn_end(bank), MAX_ORDER_NR_PAGES);
> + prev_end = ALIGN(start + __phys_to_pfn(reg->size),
I think, start + __phys_to_pfn(reg->size) can be replaced by
memblock_region_memory_end_pfn().
> + MAX_ORDER_NR_PAGES);
> }
>
> #ifdef CONFIG_SPARSEMEM
> - if (!IS_ALIGNED(prev_bank_end, PAGES_PER_SECTION))
> - free_memmap(prev_bank_end,
> - ALIGN(prev_bank_end, PAGES_PER_SECTION));
> + if (!IS_ALIGNED(prev_end, PAGES_PER_SECTION))
> + free_memmap(prev_end,
> + ALIGN(prev_end, PAGES_PER_SECTION));
> #endif
> }
>
> @@ -536,7 +519,7 @@ void __init mem_init(void)
> set_max_mapnr(pfn_to_page(max_pfn) - mem_map);
>
> /* this will put all unused low memory onto the freelists */
> - free_unused_memmap(&meminfo);
> + free_unused_memmap();
> free_all_bootmem();
>
> #ifdef CONFIG_SA1111
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 4f08c13..23433ef 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1046,74 +1046,44 @@ phys_addr_t arm_lowmem_limit __initdata = 0;
> void __init sanity_check_meminfo(void)
> {
> phys_addr_t memblock_limit = 0;
> - int i, j, highmem = 0;
> + int highmem = 0;
> phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;
> + struct memblock_region *reg;
>
> - for (i = 0, j = 0; i < meminfo.nr_banks; i++) {
> - struct membank *bank = &meminfo.bank[j];
> - phys_addr_t size_limit;
> -
> - *bank = meminfo.bank[i];
> - size_limit = bank->size;
> + for_each_memblock(memory, reg) {
> + phys_addr_t block_start = reg->base;
> + phys_addr_t block_end = reg->base + reg->size;
> + phys_addr_t size_limit = reg->size;
>
> - if (bank->start >= vmalloc_limit)
> + if (reg->base >= vmalloc_limit)
> highmem = 1;
> else
> - size_limit = vmalloc_limit - bank->start;
> + size_limit = vmalloc_limit - reg->base;
>
> - bank->highmem = highmem;
>
> -#ifdef CONFIG_HIGHMEM
> - /*
> - * Split those memory banks which are partially overlapping
> - * the vmalloc area greatly simplifying things later.
> - */
> - if (!highmem && bank->size > size_limit) {
> - if (meminfo.nr_banks >= NR_BANKS) {
> - printk(KERN_CRIT "NR_BANKS too low, "
> - "ignoring high memory\n");
> - } else {
> - memmove(bank + 1, bank,
> - (meminfo.nr_banks - i) * sizeof(*bank));
> - meminfo.nr_banks++;
> - i++;
> - bank[1].size -= size_limit;
> - bank[1].start = vmalloc_limit;
> - bank[1].highmem = highmem = 1;
> - j++;
> + if (!IS_ENABLED(CONFIG_HIGHMEM) || cache_is_vipt_aliasing()) {
> +
> + if (highmem) {
> + pr_notice("Ignoring ram at %pa-%pa (!CONFIG_HIGHMEM)\n",
> + &block_start, &block_end);
> + memblock_remove(block_start, block_end);
The wrong size is used here, should be => memblock_remove(block_start, reg->size);
or => memblock_remove(block_start, size_limit);
> + continue;
> }
> - bank->size = size_limit;
> - }
> -#else
> - /*
> - * Highmem banks not allowed with !CONFIG_HIGHMEM.
> - */
> - if (highmem) {
> - printk(KERN_NOTICE "Ignoring RAM at %.8llx-%.8llx "
> - "(!CONFIG_HIGHMEM).\n",
> - (unsigned long long)bank->start,
> - (unsigned long long)bank->start + bank->size - 1);
> - continue;
> - }
>
> - /*
> - * Check whether this memory bank would partially overlap
> - * the vmalloc area.
> - */
> - if (bank->size > size_limit) {
> - printk(KERN_NOTICE "Truncating RAM at %.8llx-%.8llx "
> - "to -%.8llx (vmalloc region overlap).\n",
> - (unsigned long long)bank->start,
> - (unsigned long long)bank->start + bank->size - 1,
> - (unsigned long long)bank->start + size_limit - 1);
> - bank->size = size_limit;
> + if (reg->size > size_limit) {
> + phys_addr_t overlap_size = reg->size - size_limit;
> +
> + pr_notice("Truncating RAM at %pa-%pa to -%pa",
> + &block_start, &block_end, &overlap_size);
Pls, change it back to show new RAM limit instead of size.
pr_notice("Truncating RAM at %pa-%pa to -%pa",
&block_start, &block_end, &vmalloc_limit);
> + memblock_remove(vmalloc_limit, overlap_size);
> + block_end = vmalloc_limit;
> + }
> }
> -#endif
> - if (!bank->highmem) {
> - phys_addr_t bank_end = bank->start + bank->size;
>
> - if (bank_end > arm_lowmem_limit)
> - arm_lowmem_limit = bank_end;
> + if (!highmem) {
> + if (block_end > arm_lowmem_limit)
> + arm_lowmem_limit = reg->base + size_limit;
> +
if !highmem then size_limit will be calculated as vmalloc_limit - reg->base
which in turn can be greater than reg->size. So, arm_lowmem_limit can point on
non existent memory address.
Seems, it should be:
arm_lowmem_limit = block_end;
>
> /*
> * Find the first non-section-aligned page, and point
> @@ -1129,35 +1099,16 @@ void __init sanity_check_meminfo(void)
> * occurs before any free memory is mapped.
> */
> if (!memblock_limit) {
> - if (!IS_ALIGNED(bank->start, SECTION_SIZE))
> - memblock_limit = bank->start;
> - else if (!IS_ALIGNED(bank_end, SECTION_SIZE))
> - memblock_limit = bank_end;
[...]
Thanks for your patience :)
Regards,
-grygorii
^ permalink raw reply
* [PATCH] ARM: shmobile: set proper DMA masks for Ether devices
From: Ben Dooks @ 2014-02-12 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB8C2C.1050909@cogentembedded.com>
On 12/02/14 14:58, Sergei Shtylyov wrote:
> Hello.
>
> On 12-02-2014 18:28, Ben Dooks wrote:
>
>>>>> Ether MAC is a DMA-capable device and so should have 'dev.dma_mask'
>>>>> and
>>>>> 'dev.coherent_dma_mask' fields set properly, to reflect 32-bit DMA
>>>>> addressing
>>>>> ability. Currently, the code works without DMA masks but in the
>>>>> future, when
>>>>> support for NETIF_F_HIGHDMA & NETIF_F_SG would be added to the
>>>>> 'sh_eth' driver,
>>>>> the DMA masks should start to matter...
>
>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
>>>> Hi, do you have a git branch available with all the changes for getting
>>>> ethernet working on rcar please?
>
>>> Depends on whether you want it working via DT or mere platform
>>> devices. If the second, it's 3.14-rc1. If DT, I don't have a branch,
>>> only several patches to apply atop of the current 'renesas.git' repo's
>>> 'devel' branch that I've posted last week (note that only R8A779x is
>>> currently supported by these patches and NFS boot timeout is still an
>>> issue with them).
>
>> ok, I have a slightly earlier version which seems to work with nfs
>> boot for me.
>
> There's no "slightly earlier version" (unless you mean DT support
> for BOCK-W posted months ago). Issue with NFS is not fatal, it boots
> fine, just somewhat slow.
I think actually the version we have in our tree may be an rework
of that. It is a while since we looked at it.
My aim is to rebuild on the newer release and use that going forward
as we are trying to stick as close as possible to the mainline.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Brown @ 2014-02-12 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212114740.GE21992@e106331-lin.cambridge.arm.com>
On Wed, Feb 12, 2014 at 11:47:40AM +0000, Mark Rutland wrote:
> I assume that for the non-dt case it's possible to name clock inputs to
> a device without the clock being associated with the name globally? If
> so we could get rid of the index usage entirely in this case.
Yes, using clk_add_alias().
-------------- 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/20140212/59950f83/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: Add imprecise abort enable/disable macro
From: Fabrice Gasnier @ 2014-02-12 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212131834.GP26684@n2100.arm.linux.org.uk>
Hi Russell,
On 02/12/2014 02:18 PM, Russell King - ARM Linux wrote:
> On Wed, Feb 12, 2014 at 02:05:39PM +0100, Fabrice GASNIER wrote:
>> Hi,
>>
>> Any comments on this patch ?
>>
>> Russell, can I add this patch to your patch tracker system ?
> I don't see how this works on anything but ARMv7M.
Sorry, i'm confused.
In the first patch you proposed,
http://archive.arm.linux.org.uk/lurker/message/20140131.170827.d752a1cc.en.html
there was :
#ifndef CONFIG_CPU_V7M
[...]
/* Enable imprecise aborts */
[...]
#else /* ifndef CONFIG_CPU_V7M */
I understand that abort handling (vectors and masking ?) is different on
armv7-m ?
Or should we make no distinction ?
I have kept the same principle regarding abort enable/disable macro.
#if __LINUX_ARM_ARCH__ >= 6
[...]
#ifndef CONFIG_CPU_V7M
#define local_abt_enable() __asm__("cpsie a @ __sta" : : : "memory",
"cc")
#define local_abt_disable() __asm__("cpsid a @ __cla" : : : "memory",
"cc")
#else
#define local_abt_enable() do { } while (0)
#define local_abt_disable() do { } while (0)
#endif
#else
[...]
#define local_abt_enable() do { } while (0)
#define local_abt_disable() do { } while (0)
#endif
Sorry if this is silly question ...
BR,
Fabrice
>
^ permalink raw reply
* [PATCH 01/17] Documentation: i2c: describe devicetree method for instantiating devices
From: Wolfram Sang @ 2014-02-12 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210122119.115858a7ntu4lr40@67.228.131.205>
> There is now also a means to instantiate I2C devices through
> ACPI. This is documented in Documentation/acpi/enumeration.txt.
>
> Might be worthwhile to reference it from instantiating-devices.
> I guess that would be a separate patch though.
Yes, it would. Thanks for the pointer!
-------------- 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/20140212/c425f758/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-sabresd: Do not place regulator nodes under simple-bus
From: Shawn Guo @ 2014-02-12 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212135736.GB25957@e106331-lin.cambridge.arm.com>
On Wed, Feb 12, 2014 at 01:57:36PM +0000, Mark Rutland wrote:
> As it stands, the dts are buggy. I can appreciate that you don't feel
> this is important, but I do. It's not just an IMX issue, there is
> widespread misunderstanding and abuse of simple-bus.
>
> Said abuse is relying on current Linux implementation details, and that
> can and will create problems if and when probing code is changed.
The reality is the code already gets no chance to change on this regard,
considering the requirement that we need to maintain the interface
between kernel and DT as ABI. The dts have been there like this for
10 kernel releases or so.
> There's no good reason for abusing the binding when we can get it right
> today.
As I said from the beginning, though I personally take it as a churn, I
will still be happy take the change, as long as my upstream folks are
also fine with it.
Shawn
^ permalink raw reply
* [PATCH] gpio: mvebu: use chained_irq_{enter, exit} for GIC compatibility
From: Linus Walleij @ 2014-02-12 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391772559-28357-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Fri, Feb 7, 2014 at 12:29 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On currently supported SoCs, the GPIO block used on Marvell EBU SoCs
> is always connected to the Marvell MPIC. However, we are going to
> introduce the support for newer Marvell EBU SoCs that use the
> Cortex-A9 core, and therefore use the GIC as their main interrupt
> controller, to which the GPIO block controlled by the gpio-mvebu
> driver is connected.
>
> The GIC interrupt controller driver uses the fasteoi flow handler. In
> order to ensure that the eoi hook of the GIC driver gets called, the
> GPIO driver should call chained_irq_enter() and chained_irq_exit() in
> its handler. Without this, the first GPIO interrupt locks up the
> system because it doesn't get acked at the GIC level.
>
> This change is similar to for example commit
> 0d978eb7349941139241a99acf05de6dd49b78d1 ("gpio: davinci: use
> chained_irq_enter/chained_irq_exit API").
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
That's right. Patch applied (w/Jason's ACK).
Now a bigger question: isn't this something that basically *all* GPIO
drivers supporting IRQs should be doing? I think they are basically
all cascaded.
When I grep drivers/gpio/* I see a lot of weird stuff. For example
drivers like gpio-ep93xx that uses irq_set_chained_handler()
but never calls chained_irq_[enter|exit]().
I sense a need of cleanup. Ultimately I want to move a
generic irq_chip into gpiolib, implement this with necessary callbacks
there and try to move drivers over to using that central irqchip
mechanism. But maybe I'm not seeing the irq subsystem in all
its complex glory so this may be a pipe dream.
I'm actually a bit uncertain about the semantics here so I'm
asking you for some advice ...
Ideas?
Yours,
Linus Walleij
^ permalink raw reply
* [BUG] Circular locking dependency - DRM/CMA/MM/hotplug/...
From: Marek Szyprowski @ 2014-02-12 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211183543.GK26684@n2100.arm.linux.org.uk>
Hello,
On 2014-02-11 19:35, Russell King - ARM Linux wrote:
> The cubox-i4 just hit a new lockdep problem - not quite sure what to
> make of this - it looks like an interaction between quite a lot of
> locks - I suspect more than the lockdep code is reporting in its
> "Possible unsafe locking scenario" report.
>
> I'm hoping I've sent this to appropriate people... if anyone thinks
> this needs to go to someone else, please forward it. Thanks.
From the attached log it looks like an issue (AB-BA deadlock) between
device mutex (&dev->struct_mutex) and mm semaphore (&mm->mmap_sem).
Similar issue has been discussed quite a long time ago in v4l2
subsystem:
https://www.mail-archive.com/linux-media at vger.kernel.org/msg38599.html
http://www.spinics.net/lists/linux-media/msg40225.html
Solving it probably requires some changes in DRM core. I see no direct
relation between this issue and CMA itself.
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> 3.14.0-rc2+ #517 Tainted: G W
> -------------------------------------------------------
> Xorg/805 is trying to acquire lock:
> (cma_mutex){+.+.+.}, at: [<c03716f4>] dma_release_from_contiguous+0xb8/0xf8
>
> but task is already holding lock:
> (&dev->struct_mutex){+.+...}, at: [<c03512ec>] drm_gem_object_handle_unreference_unlocked+0xdc/0x148
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
> -> #5 (&dev->struct_mutex){+.+...}:
> [<c0066f04>] __lock_acquire+0x151c/0x1ca0
> [<c0067c28>] lock_acquire+0xa0/0x130
> [<c0698180>] mutex_lock_nested+0x5c/0x3ac
> [<c0350c30>] drm_gem_mmap+0x40/0xdc
> [<c03671d8>] drm_gem_cma_mmap+0x14/0x2c
> [<c00ef4f4>] mmap_region+0x3ac/0x59c
> [<c00ef9ac>] do_mmap_pgoff+0x2c8/0x370
> [<c00dd730>] vm_mmap_pgoff+0x6c/0x9c
> [<c00ee1fc>] SyS_mmap_pgoff+0x54/0x98
> [<c000e6e0>] ret_fast_syscall+0x0/0x48
> -> #4 (&mm->mmap_sem){++++++}:
> [<c0066f04>] __lock_acquire+0x151c/0x1ca0
> [<c0067c28>] lock_acquire+0xa0/0x130
> [<c00e6c5c>] might_fault+0x6c/0x94
> [<c0335440>] con_set_unimap+0x158/0x27c
> [<c032f800>] vt_ioctl+0x1298/0x1388
> [<c0323f44>] tty_ioctl+0x168/0xbf4
> [<c0115fac>] do_vfs_ioctl+0x84/0x664
> [<c01165d0>] SyS_ioctl+0x44/0x64
> [<c000e6e0>] ret_fast_syscall+0x0/0x48
> -> #3 (console_lock){+.+.+.}:
> [<c0066f04>] __lock_acquire+0x151c/0x1ca0
> [<c0067c28>] lock_acquire+0xa0/0x130
> [<c006edcc>] console_lock+0x60/0x74
> [<c006f7b8>] console_cpu_notify+0x28/0x34
> [<c004904c>] notifier_call_chain+0x4c/0x8c
> [<c004916c>] __raw_notifier_call_chain+0x1c/0x24
> [<c0024124>] __cpu_notify+0x34/0x50
> [<c002424c>] cpu_notify_nofail+0x18/0x24
> [<c068e168>] _cpu_down+0x100/0x244
> [<c068e2dc>] cpu_down+0x30/0x44
> [<c036ef8c>] cpu_subsys_offline+0x14/0x18
> [<c036af28>] device_offline+0x94/0xbc
> [<c036b030>] online_store+0x4c/0x74
> [<c0368d3c>] dev_attr_store+0x20/0x2c
> [<c016b2e0>] sysfs_kf_write+0x54/0x58
> [<c016eaa4>] kernfs_fop_write+0xc4/0x160
> [<c0105a54>] vfs_write+0xbc/0x184
> [<c0105dfc>] SyS_write+0x48/0x70
> [<c000e6e0>] ret_fast_syscall+0x0/0x48
> -> #2 (cpu_hotplug.lock){+.+.+.}:
> [<c0066f04>] __lock_acquire+0x151c/0x1ca0
> [<c0067c28>] lock_acquire+0xa0/0x130
> [<c0698180>] mutex_lock_nested+0x5c/0x3ac
> [<c0024218>] get_online_cpus+0x3c/0x58
> [<c00d0ab0>] lru_add_drain_all+0x24/0x190
> [<c0101d3c>] migrate_prep+0x10/0x18
> [<c00cba04>] alloc_contig_range+0xf4/0x30c
> [<c0371588>] dma_alloc_from_contiguous+0x7c/0x130
> [<c0018ef8>] __alloc_from_contiguous+0x38/0x12c
> [<c0908694>] atomic_pool_init+0x74/0x128
> [<c0008850>] do_one_initcall+0x3c/0x164
> [<c0903c98>] kernel_init_freeable+0x104/0x1d0
> [<c068de54>] kernel_init+0x10/0xec
> [<c000e7a8>] ret_from_fork+0x14/0x2c
> -> #1 (lock){+.+...}:
> [<c0066f04>] __lock_acquire+0x151c/0x1ca0
> [<c0067c28>] lock_acquire+0xa0/0x130
> [<c0698180>] mutex_lock_nested+0x5c/0x3ac
> [<c00d0aa8>] lru_add_drain_all+0x1c/0x190
> [<c0101d3c>] migrate_prep+0x10/0x18
> [<c00cba04>] alloc_contig_range+0xf4/0x30c
> [<c0371588>] dma_alloc_from_contiguous+0x7c/0x130
> [<c0018ef8>] __alloc_from_contiguous+0x38/0x12c
> [<c0908694>] atomic_pool_init+0x74/0x128
> [<c0008850>] do_one_initcall+0x3c/0x164
> [<c0903c98>] kernel_init_freeable+0x104/0x1d0
> [<c068de54>] kernel_init+0x10/0xec
> [<c000e7a8>] ret_from_fork+0x14/0x2c
> -> #0 (cma_mutex){+.+.+.}:
> [<c0690850>] print_circular_bug+0x70/0x2f0
> [<c0066f68>] __lock_acquire+0x1580/0x1ca0
> [<c0067c28>] lock_acquire+0xa0/0x130
> [<c0698180>] mutex_lock_nested+0x5c/0x3ac
> [<c03716f4>] dma_release_from_contiguous+0xb8/0xf8
> [<c00197a4>] __arm_dma_free.isra.11+0x194/0x218
> [<c0019868>] arm_dma_free+0x1c/0x24
> [<c0366e34>] drm_gem_cma_free_object+0x68/0xb8
> [<c0351194>] drm_gem_object_free+0x30/0x38
> [<c0351318>] drm_gem_object_handle_unreference_unlocked+0x108/0x148
> [<c0351498>] drm_gem_handle_delete+0xb0/0x10c
> [<c0351508>] drm_gem_dumb_destroy+0x14/0x18
> [<c035e838>] drm_mode_destroy_dumb_ioctl+0x34/0x40
> [<c034f918>] drm_ioctl+0x3f4/0x498
> [<c0115fac>] do_vfs_ioctl+0x84/0x664
> [<c01165d0>] SyS_ioctl+0x44/0x64
> [<c000e6e0>] ret_fast_syscall+0x0/0x48
>
> other info that might help us debug this:
>
> Chain exists of: cma_mutex --> &mm->mmap_sem --> &dev->struct_mutex
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&dev->struct_mutex);
> lock(&mm->mmap_sem);
> lock(&dev->struct_mutex);
> lock(cma_mutex);
>
> *** DEADLOCK ***
>
> 1 lock held by Xorg/805:
> #0: (&dev->struct_mutex){+.+...}, at: [<c03512ec>] drm_gem_object_handle_unreference_unlocked+0xdc/0x148
>
> stack backtrace:
> CPU: 0 PID: 805 Comm: Xorg Tainted: G W 3.14.0-rc2+ #517
> Backtrace:
> [<c00124e0>] (dump_backtrace) from [<c0012680>] (show_stack+0x18/0x1c)
> r6:c0a869f0 r5:c0a8d540 r4:00000000 r3:00000000
> [<c0012668>] (show_stack) from [<c0693310>] (dump_stack+0x70/0x8c)
> [<c06932a0>] (dump_stack) from [<c0690a7c>] (print_circular_bug+0x29c/0x2f0)
> r4:c0a79570 r3:e9338980
> [<c06907e0>] (print_circular_bug) from [<c0066f68>] (__lock_acquire+0x1580/0x1ca0)
> r10:c0a6da70 r8:e9338dc8 r7:c10ed83c r6:00000001 r5:e9338db0 r4:e9338980
> [<c00659e8>] (__lock_acquire) from [<c0067c28>] (lock_acquire+0xa0/0x130)
> r10:00000000 r9:00000002 r8:00000000 r7:00000000 r6:c099e3b0 r5:e8ca2000
> r4:00000000
> [<c0067b88>] (lock_acquire) from [<c0698180>] (mutex_lock_nested+0x5c/0x3ac)
> r10:e9338980 r9:ea16d010 r8:e8ca2000 r7:00000000 r6:c0ebe304 r5:c03716f4
> r4:c099e378
> [<c0698124>] (mutex_lock_nested) from [<c03716f4>] (dma_release_from_contiguous+0xb8/0xf8)
> r10:ebb00000 r9:ea16d010 r8:c0979cc8 r7:0002bb00 r6:000003fc r5:0003bb00
> r4:c10f4a78
> [<c037163c>] (dma_release_from_contiguous) from [<c00197a4>] (__arm_dma_free.isra.11+0x194/0x218)
> r6:003fc000 r5:ea7d8000 r4:ead4e000 r3:c001db4c
> [<c0019610>] (__arm_dma_free.isra.11) from [<c0019868>] (arm_dma_free+0x1c/0x24)
> r10:e9902e20 r9:e8ca3e38 r8:e989e000 r7:e9902e58 r6:e9902f10 r5:e989e030
> r4:e9aad540
> [<c001984c>] (arm_dma_free) from [<c0366e34>] (drm_gem_cma_free_object+0x68/0xb8)
> [<c0366dcc>] (drm_gem_cma_free_object) from [<c0351194>] (drm_gem_object_free+0x30/0x38)
> r4:e9aad540
> [<c0351164>] (drm_gem_object_free) from [<c0351318>] (drm_gem_object_handle_unreference_unlocked+0x108/0x148)
> [<c0351210>] (drm_gem_object_handle_unreference_unlocked) from [<c0351498>] (drm_gem_handle_delete+0xb0/0x10c)
> r5:e9aad540 r4:e9902e00
> [<c03513e8>] (drm_gem_handle_delete) from [<c0351508>] (drm_gem_dumb_destroy+0x14/0x18)
> r10:c06e3448 r8:e8ca3e38 r7:e8ca2000 r6:e9902e00 r5:000000b4 r4:e8ca3e38
> [<c03514f4>] (drm_gem_dumb_destroy) from [<c035e838>] (drm_mode_destroy_dumb_ioctl+0x34/0x40)
> [<c035e804>] (drm_mode_destroy_dumb_ioctl) from [<c034f918>] (drm_ioctl+0x3f4/0x498)
> r4:e989e000 r3:c035e804
> [<c034f524>] (drm_ioctl) from [<c0115fac>] (do_vfs_ioctl+0x84/0x664)
> r10:00000000 r9:e8ca2000 r8:beeb6bb4 r7:e9824560 r6:c01165d0 r5:00000006
> r4:e9b97300
> [<c0115f28>] (do_vfs_ioctl) from [<c01165d0>] (SyS_ioctl+0x44/0x64)
> r10:00000000 r9:e8ca2000 r8:00000006 r7:c00464b4 r6:beeb6bb4 r5:e9b97300
> r4:00000000
> [<c011658c>] (SyS_ioctl) from [<c000e6e0>] (ret_fast_syscall+0x0/0x48)
> r8:c000e8a4 r7:00000036 r6:00000006 r5:c00464b4 r4:beeb6bb4
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 4/4] ARM: Delete asm/system.h
From: David Howells @ 2014-02-12 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212154544.2405.2992.stgit@warthog.procyon.org.uk>
Delete ARM's asm/system.h. It's the last holdout and should be got rid of.
This builds for defconfig, lpc32xx_defconfig, exynos_defconfig + XEN, the
previous changed to a Gemini system and an omap3 config with TI_DAVINCI_EMAC.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Russell King <linux@arm.linux.org.uk>
cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/include/asm/jump_label.h | 1 -
arch/arm/include/asm/sync_bitops.h | 1 -
arch/arm/include/asm/system.h | 7 -------
arch/arm/mach-gemini/idle.c | 2 +-
arch/arm/mach-omap2/am35xx-emac.c | 1 -
drivers/usb/gadget/lpc32xx_udc.c | 1 -
6 files changed, 1 insertion(+), 12 deletions(-)
delete mode 100644 arch/arm/include/asm/system.h
diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
index 863c892..70f9b9b 100644
--- a/arch/arm/include/asm/jump_label.h
+++ b/arch/arm/include/asm/jump_label.h
@@ -4,7 +4,6 @@
#ifdef __KERNEL__
#include <linux/types.h>
-#include <asm/system.h>
#define JUMP_LABEL_NOP_SIZE 4
diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
index 63479ee..9732b8e 100644
--- a/arch/arm/include/asm/sync_bitops.h
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -2,7 +2,6 @@
#define __ASM_SYNC_BITOPS_H__
#include <asm/bitops.h>
-#include <asm/system.h>
/* sync_bitops functions are equivalent to the SMP implementation of the
* original functions, independently from CONFIG_SMP being defined.
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
deleted file mode 100644
index 368165e..0000000
--- a/arch/arm/include/asm/system.h
+++ /dev/null
@@ -1,7 +0,0 @@
-/* FILE TO BE DELETED. DO NOT ADD STUFF HERE! */
-#include <asm/barrier.h>
-#include <asm/compiler.h>
-#include <asm/cmpxchg.h>
-#include <asm/switch_to.h>
-#include <asm/system_info.h>
-#include <asm/system_misc.h>
diff --git a/arch/arm/mach-gemini/idle.c b/arch/arm/mach-gemini/idle.c
index 87dff4f..ddf8ec9 100644
--- a/arch/arm/mach-gemini/idle.c
+++ b/arch/arm/mach-gemini/idle.c
@@ -3,7 +3,7 @@
*/
#include <linux/init.h>
-#include <asm/system.h>
+#include <asm/system_misc.h>
#include <asm/proc-fns.h>
static void gemini_idle(void)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c b/arch/arm/mach-omap2/am35xx-emac.c
index 25b79a2..6a6935c 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -17,7 +17,6 @@
#include <linux/err.h>
#include <linux/davinci_emac.h>
-#include <asm/system.h>
#include "omap_device.h"
#include "am35xx.h"
#include "control.h"
diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx_udc.c
index 049ebab..a94bb10 100644
--- a/drivers/usb/gadget/lpc32xx_udc.c
+++ b/drivers/usb/gadget/lpc32xx_udc.c
@@ -55,7 +55,6 @@
#include <mach/hardware.h>
#include <linux/io.h>
#include <asm/irq.h>
-#include <asm/system.h>
#include <mach/platform.h>
#include <mach/irqs.h>
^ permalink raw reply related
* [PATCH RESEND] ARM: LPC32xx: common.c: Remove unnecessary header inclusion
From: Roland Stigge @ 2014-02-12 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002a01cf2790$3e2d6510$ba882f30$%han@samsung.com>
On 12/02/14 02:17, Jingoo Han wrote:
> common.c includes some header files that are not really used.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> Compile-tested only.
>
> arch/arm/mach-lpc32xx/common.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
> index d7aa54c..9713c8b 100644
> --- a/arch/arm/mach-lpc32xx/common.c
> +++ b/arch/arm/mach-lpc32xx/common.c
> @@ -17,12 +17,6 @@
> */
>
> #include <linux/init.h>
> -#include <linux/platform_device.h>
> -#include <linux/interrupt.h>
> -#include <linux/irq.h>
> -#include <linux/err.h>
> -#include <linux/i2c.h>
> -#include <linux/i2c-pnx.h>
> #include <linux/io.h>
>
> #include <asm/mach/map.h>
>
Acked-by: Roland Stigge <stigge@antcom.de>
^ permalink raw reply
* [PATCH 2/3] ARM: mvebu: use GPIO DT defines in Armada 370/XP boards
From: Jason Cooper @ 2014-02-12 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212102448.06d8cc56@skate>
On Wed, Feb 12, 2014 at 10:24:48AM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Wed, 12 Feb 2014 08:49:46 +0100, Andrew Lunn wrote:
>
> > What i did for kirkwood is include both gpio.h and input.h in
> > kirkwood.dtsi. Quite a few other systems do that, rather than each
> > .dts file having to include them. However i don't have a strong
> > opinion.
>
> Right, I don't have a strong opinion on this either. I did it this way
> because a few other .dts files for Armada boards (Netgear NAS) were
> already including these header files.
>
> I guess it is clearly something that can be factorized later on as the
> number of Armada boards needing this grows.
Same here, it's cleaner, but it can wait for cleanups next window.
thx,
Jason.
^ permalink raw reply
* [PATCH 0/14] Xilinx axi ethernet patches
From: Michal Simek @ 2014-02-12 15:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I have exctracted patches which I have in our
xilinx git tree which are missing in the mainline.
The first two patches fix compilation error and
warnings. Then 5 feature patches
and the rest is OF cleanup and with kernel-doc
and checkpatch problems.
Thanks,
Michal
Michal Simek (4):
net: axienet: Fix compilation error
net: axienet: Fix compilation warnings
net: axienet: Fix comments blocks
net: axienet: Fix kernel-doc warnings
Peter Crosthwaite (2):
net: axienet: Handle 0 packet receive gracefully
net: axienet: Service completion interrupts ASAP
Srikanth Thokala (8):
net: axienet: Support for RGMII
net: axienet: Handle jumbo frames for lesser frame sizes
net: axienet: Support phy-less mode of operation
net: axienet: Removed checkpatch errors/warnings
net: axienet: Use pdev instead of op
net: axienet: Use devm_* calls
net: axienet: Use of_property_* calls
net: axienet: Removed _of_ prefix in probe and remove functions
drivers/net/ethernet/xilinx/xilinx_axienet.h | 108 ++++----
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 307 ++++++++++++----------
drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c | 30 ++-
3 files changed, 241 insertions(+), 204 deletions(-)
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/c0b11373/attachment.sig>
^ permalink raw reply
* [PATCH 01/14] net: axienet: Fix compilation error
From: Michal Simek @ 2014-02-12 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1392220536.git.michal.simek@xilinx.com>
Add missing header to fix compilation error.
drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1575:22:
error: undefined identifier 'irq_of_parse_and_map'
drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1576:22:
error: undefined identifier 'irq_of_parse_and_map'
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 1ec65fe..9fb8ab2 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -26,6 +26,7 @@
#include <linux/netdevice.h>
#include <linux/of_mdio.h>
#include <linux/of_platform.h>
+#include <linux/of_irq.h>
#include <linux/of_address.h>
#include <linux/skbuff.h>
#include <linux/spinlock.h>
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/76d99215/attachment-0001.sig>
^ permalink raw reply related
* [PATCH 02/14] net: axienet: Fix compilation warnings
From: Michal Simek @ 2014-02-12 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1392220536.git.michal.simek@xilinx.com>
Warning log:
xilinx_axienet_main.c: In function 'axienet_start_xmit_done':
xilinx_axienet_main.c:617:16: warning: operation on 'lp->tx_bd_ci' may be undefined [-Wsequence-point]
xilinx_axienet_main.c: In function 'axienet_start_xmit':
xilinx_axienet_main.c:703:18: warning: operation on 'lp->tx_bd_tail' may be undefined [-Wsequence-point]
xilinx_axienet_main.c:719:17: warning: operation on 'lp->tx_bd_tail' may be undefined [-Wsequence-point]
xilinx_axienet_main.c: In function 'axienet_recv':
xilinx_axienet_main.c:792:16: warning: operation on 'lp->rx_bd_ci' may be undefined [-Wsequence-point]
xilinx_axienet_main.c: In function 'axienet_of_probe':
xilinx_axienet_main.c:1501:21: warning: unused variable 'rc' [-Wunused-variable]
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 9fb8ab2..4bfdf8c 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -601,7 +601,8 @@ static void axienet_start_xmit_done(struct net_device *ndev)
size += status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
packets++;
- lp->tx_bd_ci = ++lp->tx_bd_ci % TX_BD_NUM;
+ ++lp->tx_bd_ci;
+ lp->tx_bd_ci %= TX_BD_NUM;
cur_p = &lp->tx_bd_v[lp->tx_bd_ci];
status = cur_p->status;
}
@@ -687,7 +688,8 @@ static int axienet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
skb_headlen(skb), DMA_TO_DEVICE);
for (ii = 0; ii < num_frag; ii++) {
- lp->tx_bd_tail = ++lp->tx_bd_tail % TX_BD_NUM;
+ ++lp->tx_bd_tail;
+ lp->tx_bd_tail %= TX_BD_NUM;
cur_p = &lp->tx_bd_v[lp->tx_bd_tail];
frag = &skb_shinfo(skb)->frags[ii];
cur_p->phys = dma_map_single(ndev->dev.parent,
@@ -703,7 +705,8 @@ static int axienet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
tail_p = lp->tx_bd_p + sizeof(*lp->tx_bd_v) * lp->tx_bd_tail;
/* Start the transfer */
axienet_dma_out32(lp, XAXIDMA_TX_TDESC_OFFSET, tail_p);
- lp->tx_bd_tail = ++lp->tx_bd_tail % TX_BD_NUM;
+ ++lp->tx_bd_tail;
+ lp->tx_bd_tail %= TX_BD_NUM;
return NETDEV_TX_OK;
}
@@ -775,7 +778,8 @@ static void axienet_recv(struct net_device *ndev)
cur_p->status = 0;
cur_p->sw_id_offset = (u32) new_skb;
- lp->rx_bd_ci = ++lp->rx_bd_ci % RX_BD_NUM;
+ ++lp->rx_bd_ci;
+ lp->rx_bd_ci %= RX_BD_NUM;
cur_p = &lp->rx_bd_v[lp->rx_bd_ci];
}
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/89c22860/attachment-0001.sig>
^ permalink raw reply related
* [PATCH 03/14] net: axienet: Support for RGMII
From: Michal Simek @ 2014-02-12 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1392220536.git.michal.simek@xilinx.com>
From: Srikanth Thokala <srikanth.thokala@xilinx.com>
This patch adds support for the RGMII. The h/w configuration
parameter C_PHY_TYPE, which represents the interface configured in
the design, is used to differentiate various interfaces supported
by AXI Ethernet.
Signed-off-by: Srikanth Thokala <sthokal@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 4bfdf8c..3966d83 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -925,9 +925,16 @@ static int axienet_open(struct net_device *ndev)
return ret;
if (lp->phy_node) {
- lp->phy_dev = of_phy_connect(lp->ndev, lp->phy_node,
+ if (lp->phy_type == XAE_PHY_TYPE_GMII) {
+ lp->phy_dev = of_phy_connect(lp->ndev, lp->phy_node,
axienet_adjust_link, 0,
PHY_INTERFACE_MODE_GMII);
+ } else if (lp->phy_type == XAE_PHY_TYPE_RGMII_2_0) {
+ lp->phy_dev = of_phy_connect(lp->ndev, lp->phy_node,
+ axienet_adjust_link, 0,
+ PHY_INTERFACE_MODE_RGMII_ID);
+ }
+
if (!lp->phy_dev) {
dev_err(lp->dev, "of_phy_connect() failed\n");
return -ENODEV;
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/418e2e80/attachment.sig>
^ permalink raw reply related
* [PATCH 04/14] net: axienet: Handle 0 packet receive gracefully
From: Michal Simek @ 2014-02-12 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1392220536.git.michal.simek@xilinx.com>
From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
The AXI-DMA rx-delay interrupt can sometimes be triggered when there are 0
outstanding packets received. This is due to the fact that the receive function
will greedily consume as many packets as possible on interrupt. So if two
packets (with a very particular timing) arrive in succession they will each
cause the rx-delay interrupt, but the first interrupt will consume both packets.
This means the second interrupt is a 0 packet receive.
This is mostly OK, except that the tail pointer register is updated
unconditionally on receive. Currently the tail pointer is always set to the
current bd-ring descriptor under the assumption that the hardware has moved onto
the next descriptor. What this means for length 0 recv is the current descriptor
that the hardware is potentially yet to use will be marked as the tail. This
causes the hardware to think its run out of descriptors deadlocking the whole rx
path.
Fixed by updating the tail pointer to the most recent successfully consumed
descriptor.
Reported-by: Wendy Liang <wendy.liang@xilinx.com>
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Tested-by: Jason Wu <huanyu@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 3966d83..2e21ab2 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -726,15 +726,15 @@ static void axienet_recv(struct net_device *ndev)
u32 csumstatus;
u32 size = 0;
u32 packets = 0;
- dma_addr_t tail_p;
+ dma_addr_t tail_p = 0;
struct axienet_local *lp = netdev_priv(ndev);
struct sk_buff *skb, *new_skb;
struct axidma_bd *cur_p;
- tail_p = lp->rx_bd_p + sizeof(*lp->rx_bd_v) * lp->rx_bd_ci;
cur_p = &lp->rx_bd_v[lp->rx_bd_ci];
while ((cur_p->status & XAXIDMA_BD_STS_COMPLETE_MASK)) {
+ tail_p = lp->rx_bd_p + sizeof(*lp->rx_bd_v) * lp->rx_bd_ci;
skb = (struct sk_buff *) (cur_p->sw_id_offset);
length = cur_p->app4 & 0x0000FFFF;
@@ -786,7 +786,8 @@ static void axienet_recv(struct net_device *ndev)
ndev->stats.rx_packets += packets;
ndev->stats.rx_bytes += size;
- axienet_dma_out32(lp, XAXIDMA_RX_TDESC_OFFSET, tail_p);
+ if (tail_p)
+ axienet_dma_out32(lp, XAXIDMA_RX_TDESC_OFFSET, tail_p);
}
/**
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/e6875092/attachment.sig>
^ 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