* [GIT PULL] Xilinx Zynq fix for v3.14
From: Kevin Hilman @ 2014-02-10 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F8C356.8060209@monstr.eu>
Michal Simek <monstr@monstr.eu> writes:
> Hi,
>
> please consider to queue this bug fix for v3.14.
>
> Bug was reported here:
> https://lkml.org/lkml/2014/1/27/212
>
> I have also discussed this with Rob regarding memreserve DT feature.
> Here is thread with Rob:
> https://lkml.org/lkml/2014/1/31/105
>
> Moving kernel start is currently enabled by:
> "ARM: ignore memory below PHYS_OFFSET"
> (sha1: 571b14375019c3a66ef70d4d4a7083f4238aca30)
>
> Thanks,
> Michal
>
>
> The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
>
> Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
>
> are available in the git repository at:
>
> git://git.xilinx.com/linux-xlnx.git tags/zynq-fixes-for-3.14
>
> for you to fetch changes up to a73cbb758171c34cc3d58f3dfb80feef501a2079:
>
> ARM: zynq: Reserve not DMAable space in front of the kernel (2014-02-10 13:04:35 +0100)
>
> ----------------------------------------------------------------
> arm: Xilinx Zynq fixes for v3.14
>
> - Protect DMA buffer allocation below
> kernel start address
>
> ----------------------------------------------------------------
Applied to fixes,
Thanks,
Kevin
^ permalink raw reply
* [GIT PULL] at91: fixes for 3.14 #1
From: Kevin Hilman @ 2014-02-10 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391790986-31936-1-git-send-email-nicolas.ferre@atmel.com>
Nicolas Ferre <nicolas.ferre@atmel.com> writes:
> Arnd, Olof, Kevin,
>
> This is a first "fixes" series for AT91 on 3.14.
> The content is only DT-related and quite boring.
> I took the opportunity of this early "fixes" pull-request to collect
> some Documentation patches that were lying around and I guess that
> they can be merged by arm-soc nicely (addition of CCF to 2 drivers).
> A new board is added to the lot because it is dead simple and integrates
> well with the new sama5d36 SoC that we added earlier in this development cycle.
>
> Thanks, best regards,
>
> The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
>
> Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
>
> are available in the git repository at:
>
> git://github.com/at91linux/linux-at91.git tags/at91-fixes
>
> for you to fetch changes up to b7c2b6157079811586180d13c44a1095b57c2d47:
>
> ARM: at91: add Atmel's SAMA5D3 Xplained board (2014-02-07 17:20:39 +0100)
>
> ----------------------------------------------------------------
> First series of AT91 fixes for 3.14.
> All of them are DT-related.
> - fixes for typos in i2c and ohci clocks
> - addition of a USB host node for at91sam9n12ek
> - 2 DT documentation updates that have been sent a long time ago
> - a new board based on the sama5d36 SoC
>
> ----------------------------------------------------------------
Pulled into fixes,
Thanks,
Kevin
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: Select CONFIG_SOC_DRA7XX
From: Kevin Hilman @ 2014-02-10 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391700571-31784-1-git-send-email-nm@ti.com>
Nishanth Menon <nm@ti.com> writes:
> Select CONFIG_SOC_DRA7XX so that we can boot dra7-evm.
> DRA7 family are A15 based processors that supports LPAE and an
> evolutionary update to the OMAP5 generation of processors.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>
> based on v3.13-rc1 kernel tag - tested on v3.14-rc1 and next-20140206
Applied to arm-soc/fixes for v3.14-rc.
Kevin
^ permalink raw reply
* [GIT PULL] ARM: imx: fixes for 3.14
From: Kevin Hilman @ 2014-02-10 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206145058.GA6610@S2101-09.ap.freescale.net>
Shawn Guo <shawn.guo@linaro.org> writes:
> Hi,
>
> The 3.13 stable tree will also need this fix. But since it does not
> apply to 3.13 cleanly, we will need to send another one for 3.13
> stable kernel, after this one hits mainline.
>
> Shawn
>
> The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
>
> Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.14
>
> for you to fetch changes up to 5d0a87ba5875794ec3df14aa74ee8e18ef47d6b4:
>
> ARM: imx6: Initialize low-power mode early again (2014-02-06 20:26:26 +0800)
>
> ----------------------------------------------------------------
> i.MX fixes for 3.14:
> - Fix a regression (system hang) when preemption is enabled
> (CONFIG_PREEMPT=y).
>
> ----------------------------------------------------------------
Applied to fixes.
Thanks,
Kevin
> Philipp Zabel (1):
> ARM: imx6: Initialize low-power mode early again
>
> arch/arm/mach-imx/clk-imx6q.c | 3 +++
> arch/arm/mach-imx/clk-imx6sl.c | 3 +++
> arch/arm/mach-imx/pm-imx6q.c | 2 --
> 3 files changed, 6 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH] ARM: pxa: fix various compilation problems
From: Kevin Hilman @ 2014-02-10 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdac3UW-ZzvgfsZt2cHaUsOeDcLS++ip=diYoLCUy7HFRA@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> On Tue, Feb 4, 2014 at 3:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 04 February 2014 13:53:07 Linus Walleij wrote:
>>> Hi ARM SoC folks: please apply this patch directly to the ARM
>>> SoC tree fixes branch if you are happy with it.
>>
>> It's also needed for 3.13-backports, right?
>
> Yes. Tagging for stable # v3.13+ should do the trick.
Applied to fixes, and tagged for stable v3.13+
Kevin
^ permalink raw reply
* [PATCH] ARM: mvebu: rename mvebu_defconfig to mvebu_v7_defconfig
From: Andrew Lunn @ 2014-02-10 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392056399-20908-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Mon, Feb 10, 2014 at 07:19:59PM +0100, Thomas Petazzoni wrote:
> With the merge of the Kirkwood support into arch/arm/mach-mvebu/, the
> mvebu platform will no longer only contain ARMv7 compatible processors
> (Armada 370, Armada XP, and soon Armada 375, Armada 38x and Dove), but
> also ARMv5 compatible processors (Kirkwood, and hopefully Orion5x in
> the future).
>
> However, a single mvebu_defconfig cannot work, since it is not
> possible to build a kernel that supports both ARMv5 and ARMv7
> platforms in the same binary. As a consequence, this commit renames
> mvebu_defconfig to mvebu_v7_defconfig, which is the configuration that
> will build a kernel that supports all ARMv7 mvebu platforms. As
> Kirkwood support gets merged into mach-mvebu, an additional
> mvebu_v5_defconfig will be added.
>
> Even though we already have a multi_v7_defconfig, the mvebu developers
> found it more convenient for development to have a defconfig that
> builds only the mvebu platforms.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/configs/{mvebu_defconfig => mvebu_v7_defconfig} | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename arch/arm/configs/{mvebu_defconfig => mvebu_v7_defconfig} (100%)
>
> diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_v7_defconfig
> similarity index 100%
> rename from arch/arm/configs/mvebu_defconfig
> rename to arch/arm/configs/mvebu_v7_defconfig
Acked-by: Andrew Lunn <andrew@lunn.ch>
Thanks Thomas,
Andrew
^ permalink raw reply
* [alsa-devel] [PATCH 0/7] Audio support for Armada 370 DB
From: Mark Brown @ 2014-02-10 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210160432.27281741@skate>
On Mon, Feb 10, 2014 at 04:04:32PM +0100, Thomas Petazzoni wrote:
> Sure, sorry. The patches that are of interest to you are prefixed by
> "sound: codec" (for the patch touching sound/soc/codecs) and "sound:
> soc" (for the patches touching sound/soc/kirkwood).
> If you want, I can resend with subject lines containing 'ASoC:',
> however maybe it's better if some other comments are made before, to
> avoid additional noise.
It's OK, they are on the list and I will get to them (most likely
tomorrow now) - I did notice them.
-------------- 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/20140210/6d6702e2/attachment.sig>
^ permalink raw reply
* [PATCH 01/17] Documentation: i2c: describe devicetree method for instantiating devices
From: linux at roeck-us.net @ 2014-02-10 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392026654-5343-2-git-send-email-wsa@the-dreams.de>
Quoting Wolfram Sang <wsa@the-dreams.de>:
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> Cc: devicetree at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>
> Documentation/i2c/instantiating-devices | 34
> +++++++++++++++++++++++++++++++--
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/i2c/instantiating-devices
> b/Documentation/i2c/instantiating-devices
> index c70e7a7..6df095a 100644
> --- a/Documentation/i2c/instantiating-devices
> +++ b/Documentation/i2c/instantiating-devices
> @@ -8,8 +8,8 @@ reason, the kernel code must instantiate I2C devices
> explicitly. There are
> several ways to achieve this, depending on the context and requirements.
>
>
> -Method 1: Declare the I2C devices by bus number
> ------------------------------------------------
> +Method 1a: Declare the I2C devices by bus number
> +------------------------------------------------
>
> This method is appropriate when the I2C bus is a system bus as is the case
> for many embedded systems. On such systems, each I2C bus has a number
> @@ -51,6 +51,36 @@ The devices will be automatically unbound and
> destroyed when the I2C bus
> they sit on goes away (if ever.)
>
>
> +Method 1b: Declare the I2C devices via devicetree
> +-------------------------------------------------
> +
Hi Wolfram,
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.
Thanks,
Guenter
^ permalink raw reply
* [PATCH] ARM: mvebu: rename mvebu_defconfig to mvebu_v7_defconfig
From: Thomas Petazzoni @ 2014-02-10 18:19 UTC (permalink / raw)
To: linux-arm-kernel
With the merge of the Kirkwood support into arch/arm/mach-mvebu/, the
mvebu platform will no longer only contain ARMv7 compatible processors
(Armada 370, Armada XP, and soon Armada 375, Armada 38x and Dove), but
also ARMv5 compatible processors (Kirkwood, and hopefully Orion5x in
the future).
However, a single mvebu_defconfig cannot work, since it is not
possible to build a kernel that supports both ARMv5 and ARMv7
platforms in the same binary. As a consequence, this commit renames
mvebu_defconfig to mvebu_v7_defconfig, which is the configuration that
will build a kernel that supports all ARMv7 mvebu platforms. As
Kirkwood support gets merged into mach-mvebu, an additional
mvebu_v5_defconfig will be added.
Even though we already have a multi_v7_defconfig, the mvebu developers
found it more convenient for development to have a defconfig that
builds only the mvebu platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/configs/{mvebu_defconfig => mvebu_v7_defconfig} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename arch/arm/configs/{mvebu_defconfig => mvebu_v7_defconfig} (100%)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_v7_defconfig
similarity index 100%
rename from arch/arm/configs/mvebu_defconfig
rename to arch/arm/configs/mvebu_v7_defconfig
--
1.8.3.2
^ permalink raw reply
* [GIT PULL] mvebu: phy and ata fixes for v3.14
From: Kevin Hilman @ 2014-02-10 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140208172217.GK8533@titan.lakedaemon.net>
Hi Jason,
Jason Cooper <jason@lakedaemon.net> writes:
> All,
>
> Here is a small set of fixes for fix a boot hang we are currently
> experiencing in the boot farm. Now that we are probing for the phy, we
> didn't take into account optional phys, which causes the hang. These
> patches fix this and restore booting on the affected platforms.
>
> thx,
>
> Jason.
>
>
> The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
>
> Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-phy_ata-fixes-3.14
>
> for you to fetch changes up to 90aa2997029fa623fe9e3ec3a469a00a34130237:
>
> ata: sata_mv: Fix probe failures with optional phys (2014-02-05 05:48:58 +0000)
>
> ----------------------------------------------------------------
> mvebu phy and ata fixes for v3.14
>
> - phy
> - add support for optional phys via NULL
>
> - ata
> - fix boot hang due to probe failure of optional phys
>
> NOTE: Series has been Ack'd by both the phy maintainer and the ata maintainer
> for going through arm-soc
>
> ----------------------------------------------------------------
Thanks, applied to fixes.
Note that the openblocks ax3 will still fail boot test on
mvebu_defconfig in arm-soc because we're missing the the 'select
GENERIC_PHY' Kconfig fix which seems to have gone through libata/next.
That's fine though as things should boot fine in -next now.
Thanks for the fixes,
Kevin
^ permalink raw reply
* [PATCH v5] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
From: Brian Norris @ 2014-02-10 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F201A7.2040401@ti.com>
On Wed, Feb 05, 2014 at 02:47:27PM +0530, Sekhar Nori wrote:
> On Thursday 30 January 2014 04:33 PM, Ivan Khoronzhuk wrote:
> > The problem that the set timings code contains the call of Davinci
> > platform function davinci_aemif_setup_timing() which is not
> > accessible if kernel is built for another platform like Keystone.
> >
> > The Keysone platform is going to use TI AEMIF driver.
> > If TI AEMIF is used we don't need to set timings and bus width.
> > It is done by AEMIF driver.
> >
> > To get rid of davinci-nand driver dependency on aemif platform code
> > we moved aemif code to davinci platform.
> >
> > The platform AEMIF code (aemif.c) has to be removed once Davinci
> > will be converted to DT and use ti-aemif.c driver.
> >
> > Acked-by: Brian Norris <computersforpeace@gmail.com>
> > Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> > [nsekhar at ti.com: fixed checkpatch error and a build breakage due to
> > missing include, rebased onto l2-mtd/master]
> > Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>
> Hope this patch looks good to you now. I would like to take it for v3.15
> via DaVinci tree.
Sure. Just don't send any conflicting patches to me in the meantime!
I'll try to leave it alone, or at least check linux-next first.
Brian
^ permalink raw reply
* OMAP baseline test results for v3.14-rc2
From: Paul Walmsley @ 2014-02-10 18:14 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic OMAP test results for Linux v3.14-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.14-rc2/20140210103104/
Test summary
------------
Build: uImage+dtb:
Pass ( 9/ 9): omap2plus_defconfig_am33xx_only/am335x-bone,
omap2plus_defconfig/omap4-panda,
omap2plus_defconfig/omap4-panda-es,
omap2plus_defconfig/am3517-evm,
omap2plus_defconfig/omap2430-sdp,
omap2plus_defconfig/omap3-beagle,
omap2plus_defconfig/omap3-beagle-xm,
omap2plus_defconfig/omap3-evm-37xx,
omap2plus_defconfig/omap4-var-som
Build: zImage:
Pass (13/13): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
omap2plus_defconfig_2430sdp_only,
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_n800_only_a,
omap2plus_defconfig_n800_multi_omap2xxx,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only
Boot to userspace:
FAIL ( 1/10): 2430sdp
skip ( 2/ 2): 5912osk, cmt3517
Pass ( 9/10): 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
4430es2panda, 4460pandaes, am335xbone, am335xbonelt,
4460varsomom
PM: chip retention via suspend:
FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom
Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm
PM: chip retention via dynamic idle:
FAIL ( 7/ 7): 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm,
4430es2panda, 4460pandaes, 4460varsomom
PM: chip off except CORE via suspend:
FAIL ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle:
FAIL ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes,
4460varsomom
PM: chip off via dynamic idle:
FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes,
4460varsomom
vmlinux object size
(delta in bytes from test_v3.14-rc1 (38dbfb59d1175ef458d006556061adeaa8751b72)):
text data bss total kernel
+393 0 0 +393 omap1_defconfig
+393 0 0 +393 omap1_defconfig_1510innovator_only
+361 0 0 +361 omap1_defconfig_5912osk_only
+705 +64 0 +769 omap2plus_defconfig
-3467 0 0 -3467 omap2plus_defconfig_2430sdp_only
+649 0 0 +649 omap2plus_defconfig_am33xx_only
+705 0 0 +705 omap2plus_defconfig_am43xx_only
+701 +64 0 +765 omap2plus_defconfig_cpupm
+769 +64 0 +833 omap2plus_defconfig_dra7xx_only
+805 0 0 +805 omap2plus_defconfig_n800_multi_omap2xxx
+805 0 0 +805 omap2plus_defconfig_n800_only_a
+705 +64 0 +769 omap2plus_defconfig_no_pm
+705 +64 0 +769 omap2plus_defconfig_omap2_4_only
+705 +64 0 +769 omap2plus_defconfig_omap3_4_only
+705 +64 0 +769 omap2plus_defconfig_omap5_only
+652 0 +64 +716 rmk_omap3430_ldp_allnoconfig
+769 0 0 +769 rmk_omap3430_ldp_oldconfig
+620 0 +96 +716 rmk_omap4430_sdp_allnoconfig
+777 -40 0 +737 rmk_omap4430_sdp_oldconfig
Boot-time memory difference
(delta in bytes from test_v3.14-rc1 (38dbfb59d1175ef458d006556061adeaa8751b72))
avail rsrvd high freed board kconfig
(no differences)
^ permalink raw reply
* [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Roger Quadros @ 2014-02-10 18:10 UTC (permalink / raw)
To: linux-arm-kernel
The OMAP EHCI controller is not compatible with the EHCI
platform HCD driver so don't claim that we are.
This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
e.g. multi_v7_defconfig
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 2 +-
arch/arm/boot/dts/omap4.dtsi | 2 +-
arch/arm/boot/dts/omap5.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..6b5dbf8 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -641,7 +641,7 @@
};
usbhsehci: ehci at 48064800 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x48064800 0x400>;
interrupt-parent = <&intc>;
interrupts = <77>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..f5d754b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -706,7 +706,7 @@
};
usbhsehci: ehci at 4a064c00 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..42fcffd 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -784,7 +784,7 @@
};
usbhsehci: ehci at 4a064c00 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 21/21] ARM: Kirkwood: Remove DT support
From: Andrew Lunn @ 2014-02-10 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207160954.69fbca38@skate>
> Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both
> Dove and Armada 370/XP (and the other ones we are going to introduce
> soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find
> enough time to work on this platform).
Hi Thomas
Could you produce a patch moving mvebu_defconfig to
mvebu_v7_defconfig? I will generate the mvebu_v5_defconfig based on
kirkwood_defconfig as part of my patchset.
Thanks
Andrew
>
> This way, ultimately we can simply remove kirkwood_defconfig and
> dove_defconfig, as soon as all legacy platforms have been either
> converted to DT, or removed.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH] pci: Add support for creating a generic host_bridge from device tree
From: Tanmay Inamdar @ 2014-02-10 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140208142207.GR4993@e106497-lin.cambridge.arm.com>
On Sat, Feb 8, 2014 at 6:22 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> On Sat, Feb 08, 2014 at 12:21:56AM +0000, Tanmay Inamdar wrote:
>> On Thu, Feb 6, 2014 at 2:18 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > On Wed, Feb 05, 2014 at 10:26:27PM +0000, Tanmay Inamdar wrote:
>> >> Hello Liviu,
>> >>
>> >> I did not get the first email of this particular patch on any of
>> >> subscribed mailing lists (don't know why), hence replying here.
>> >
>> > Strange, it shows in the MARC and GMANE archive for linux-pci, probably
>> > a hickup on your receiving side?
>> >
>> >>
>> >> +struct pci_host_bridge *
>> >> +pci_host_bridge_of_init(struct device *parent, int busno, struct pci_ops *ops,
>> >> + void *host_data, struct list_head *resources)
>> >> +{
>> >> + struct pci_bus *root_bus;
>> >> + struct pci_host_bridge *bridge;
>> >> +
>> >> + /* first parse the host bridge bus ranges */
>> >> + if (pci_host_bridge_of_get_ranges(parent->of_node, resources))
>> >> + return NULL;
>> >> +
>> >> + /* then create the root bus */
>> >> + root_bus = pci_create_root_bus(parent, busno, ops, host_data, resources);
>> >> + if (!root_bus)
>> >> + return NULL;
>> >> +
>> >> + bridge = to_pci_host_bridge(root_bus->bridge);
>> >> +
>> >> + return bridge;
>> >> +}
>> >>
>> >> You are keeping the domain_nr inside pci_host_bridge structure. In
>> >> above API, domain_nr is required in 'pci_find_bus' function called
>> >> from 'pci_create_root_bus'. Since the bridge is allocated after
>> >> creating root bus, 'pci_find_bus' always gets domain_nr as 0. This
>> >> will cause problem for scanning multiple domains.
>> >
>> > Good catch. I was switching between creating a pci_controller in arch/arm64 and
>> > adding the needed bits in pci_host_bridge. After internal review I've decided to
>> > add the domain_nr to pci_host_bridge, but forgot to update the code everywhere.
>> >
>> > Thanks for reviewing this, will fix in v2.
>> >
>> > Do you find porting to the new API straight forward?
>>
>> It is quite straight forward for MEM regions but for IO regions it is
>> not. You always assume IO resource starting at 0x0. IMO, this will
>> cause problem for systems with multiple ports / IO windows. You can
>> take a look at 'drivers/pci/host/pcie-designware.c'.
>>
>> Also the manipulations of addresses for IO_RESOURCES can be dangerous.
>> It can make some value negative. For example if my PCI IO range starts
>> in 32 bit address range say 0x8000_0000 with CPU address
>> 0xb0_8000_0000, window->offset after manipulation will become
>> negative.
>>
>> Personally I would like to do get all the PCI and CPU addresses from
>> my device tree as is and do the 'pci_add_resource_offset'. This will
>> help me setup my regions correctly without any further arithmetic.
>> Please let me know what you think.
>
> Yes, that parsing code of ranges is incorrect in light of the current discussion. I
> will try to propose a fix in the v2 series.
Okay. Thanks.
>
> Regarding your PCI IO range: if your bus address starts at 0x8000_0000, would
> that not cause problems with devices that use less than 32bits for address
> decoding? It is a rather unusual setup, I believe the x86 world (even PCI spec?)
> mandates IO bus ranges in the first 16MB of address range?
>
Yes. It will cause problem with few devices. Anyways it was just an example.
> Best regards,
> Liviu
>
>>
>> >
>> > Best regards,
>> > Liviu
>> >
>> >>
>> >>
>> >> On Mon, Feb 3, 2014 at 10:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> > On Monday 03 February 2014 18:33:48 Liviu Dudau wrote:
>> >> >> +/**
>> >> >> + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
>> >> >> + * @dev: device node of the host bridge having the range property
>> >> >> + * @resources: list where the range of resources will be added after DT parsing
>> >> >> + *
>> >> >> + * This function will parse the "ranges" property of a PCI host bridge device
>> >> >> + * node and setup the resource mapping based on its content. It is expected
>> >> >> + * that the property conforms with the Power ePAPR document.
>> >> >> + *
>> >> >> + * Each architecture will then apply their filtering based on the limitations
>> >> >> + * of each platform. One general restriction seems to be the number of IO space
>> >> >> + * ranges, the PCI framework makes intensive use of struct resource management,
>> >> >> + * and for IORESOURCE_IO types they can only be requested if they are contained
>> >> >> + * within the global ioport_resource, so that should be limited to one IO space
>> >> >> + * range.
>> >> >
>> >> > Actually we have quite a different set of restrictions around I/O space on ARM32
>> >> > at the moment: Each host bridge can have its own 64KB range in an arbitrary
>> >> > location on MMIO space, and the total must not exceed 2MB of I/O space.
>> >> >
>> >> >> + */
>> >> >> +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
>> >> >> + struct list_head *resources)
>> >> >> +{
>> >> >> + struct resource *res;
>> >> >> + struct of_pci_range range;
>> >> >> + struct of_pci_range_parser parser;
>> >> >> + int err;
>> >> >> +
>> >> >> + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
>> >> >> +
>> >> >> + /* Check for ranges property */
>> >> >> + err = of_pci_range_parser_init(&parser, dev);
>> >> >> + if (err)
>> >> >> + return err;
>> >> >> +
>> >> >> + pr_debug("Parsing ranges property...\n");
>> >> >> + for_each_of_pci_range(&parser, &range) {
>> >> >> + /* Read next ranges element */
>> >> >> + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
>> >> >> + range.pci_space, range.pci_addr);
>> >> >> + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
>> >> >> + range.cpu_addr, range.size);
>> >> >> +
>> >> >> + /* If we failed translation or got a zero-sized region
>> >> >> + * (some FW try to feed us with non sensical zero sized regions
>> >> >> + * such as power3 which look like some kind of attempt
>> >> >> + * at exposing the VGA memory hole) then skip this range
>> >> >> + */
>> >> >> + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
>> >> >> + continue;
>> >> >> +
>> >> >> + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
>> >> >> + if (!res) {
>> >> >> + err = -ENOMEM;
>> >> >> + goto bridge_ranges_nomem;
>> >> >> + }
>> >> >> +
>> >> >> + of_pci_range_to_resource(&range, dev, res);
>> >> >> +
>> >> >> + pci_add_resource_offset(resources, res,
>> >> >> + range.cpu_addr - range.pci_addr);
>> >> >> + }
>> >> >
>> >> > I believe of_pci_range_to_resource() will return the MMIO aperture for the
>> >> > I/O space window here, which is not what you are supposed to pass into
>> >> > pci_add_resource_offset.
>> >> >
>> >> >> +EXPORT_SYMBOL(pci_host_bridge_of_init);
>> >> >
>> >> > EXPORT_SYMBOL_GPL
>> >> >
>> >> >> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> >> >> index 6e34498..16febae 100644
>> >> >> --- a/drivers/pci/probe.c
>> >> >> +++ b/drivers/pci/probe.c
>> >> >> @@ -1787,6 +1787,17 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
>> >> >> list_for_each_entry_safe(window, n, resources, list) {
>> >> >> list_move_tail(&window->list, &bridge->windows);
>> >> >> res = window->res;
>> >> >> + /*
>> >> >> + * IO resources are stored in the kernel with a CPU start
>> >> >> + * address of zero. Adjust the data accordingly and remember
>> >> >> + * the offset
>> >> >> + */
>> >> >> + if (resource_type(res) == IORESOURCE_IO) {
>> >> >> + bridge->io_offset = res->start;
>> >> >> + res->end -= res->start;
>> >> >> + window->offset -= res->start;
>> >> >> + res->start = 0;
>> >> >> + }
>> >> >> offset = window->offset;
>> >> >> if (res->flags & IORESOURCE_BUS)
>> >> >
>> >> > Won't this break all existing host bridges?
>> >> >
>> >> > Arnd
>> >> >
>> >> > _______________________________________________
>> >> > linux-arm-kernel mailing list
>> >> > linux-arm-kernel at lists.infradead.org
>> >> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> >>
>> >
>> > --
>> > ====================
>> > | I would like to |
>> > | fix the world, |
>> > | but they're not |
>> > | giving me the |
>> > \ source code! /
>> > ---------------
>> > ?\_(?)_/?
>> >
>> > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>> >
>> > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
>> > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ?\_(?)_/?
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
>
^ permalink raw reply
* [PATCH 05/17] mmc: mmci: Put the device into low power state at system suspend
From: Kevin Hilman @ 2014-02-10 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFo4QG+D0wKnSEXR=2TW93HKUAbb1EUqGk_U56rS339B3Q@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> On 4 February 2014 20:22, Kevin Hilman <khilman@linaro.org> wrote:
>> Ulf Hansson <ulf.hansson@linaro.org> writes:
>>
>>> Due to the available runtime PM callbacks, we are now able to put our
>>> device into low power state at system suspend.
>>>
>>> Earlier we could not accomplish this without trusting a power domain
>>> for the device to take care of it. Now we are able to cope with
>>> scenarios both with and without a power domain.
>>>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>> ---
>>> drivers/mmc/host/mmci.c | 45 +++++++++++++++++++++++++--------------------
>>> 1 file changed, 25 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>>> index c88da1c..074e0cb 100644
>>> --- a/drivers/mmc/host/mmci.c
>>> +++ b/drivers/mmc/host/mmci.c
>>> @@ -1723,33 +1723,38 @@ static int mmci_remove(struct amba_device *dev)
>>> return 0;
>>> }
>>>
>>> -#ifdef CONFIG_SUSPEND
>>> -static int mmci_suspend(struct device *dev)
>>> +#ifdef CONFIG_PM_SLEEP
>>> +static int mmci_suspend_late(struct device *dev)
>>> {
>>> - struct amba_device *adev = to_amba_device(dev);
>>> - struct mmc_host *mmc = amba_get_drvdata(adev);
>>> + int ret = 0;
>>>
>>> - if (mmc) {
>>> - struct mmci_host *host = mmc_priv(mmc);
>>> - pm_runtime_get_sync(dev);
>>> - writel(0, host->base + MMCIMASK0);
>>> - }
>>> + if (pm_runtime_status_suspended(dev))
>>> + return 0;
>>>
>>> - return 0;
>>> + if (dev->pm_domain && dev->pm_domain->ops.runtime_suspend)
>>> + ret = dev->pm_domain->ops.runtime_suspend(dev);
>>> + else
>>> + ret = dev->bus->pm->runtime_suspend(dev);
>>> +
>>> + if (!ret)
>>> + pm_runtime_set_suspended(dev);
>>
>> Isn't this basically open-coding pm_runtime_suspend()...
>
> It is similar, but with once big difference.
>
> Since the PM core prevents pm_runtime_suspend() from invoking our
> ->runtime_suspend callback during system suspend (it does so by
> invoking pm_runtime_get_sync() before starting the suspend sequence),
> we then need to make the driver handle that by itself.
Yeah, I still think we need to allow a bus/pm_domain to override that
behavior.
Kevin
^ permalink raw reply
* OMAP baseline test results for v3.14-rc1
From: Paul Walmsley @ 2014-02-10 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F913A5.7040207@ti.com>
On Mon, 10 Feb 2014, Nishanth Menon wrote:
> On 02/10/2014 11:48 AM, Paul Walmsley wrote:
> [...]
> > Boot to userspace:
> > FAIL ( 1/10): 2430sdp
>
> Comparing boot logs I reported
> http://marc.info/?l=linux-omap&m=139144642318949&w=2 Vs
> http://www.pwsan.com/omap/testlogs/test_v3.14-rc1/20140210035354/boot/2430sdp/2430sdp_log.txt
>
> I see that bootargs are different -> I was attempting to boot sdp2430
> with nfs boot which seems to work fine for me, I believe you are
> attempting mmc boot here.
Yep. My 2430SDP's Ethernet interface flaked out a month or two ago, so,
switched it to serial booting. Hey, better test coverage from us ;-)
- Paul
^ permalink raw reply
* OMAP baseline test results for v3.14-rc1
From: Nishanth Menon @ 2014-02-10 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1402101733340.30435@utopia.booyaka.com>
On 02/10/2014 11:48 AM, Paul Walmsley wrote:
[...]
> Boot to userspace:
> FAIL ( 1/10): 2430sdp
Comparing boot logs I reported
http://marc.info/?l=linux-omap&m=139144642318949&w=2 Vs
http://www.pwsan.com/omap/testlogs/test_v3.14-rc1/20140210035354/boot/2430sdp/2430sdp_log.txt
I see that bootargs are different -> I was attempting to boot sdp2430
with nfs boot which seems to work fine for me, I believe you are
attempting mmc boot here.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 6/6] dt: Update binding information for mvebu gating clocks with Armada 380/385
From: Thomas Petazzoni @ 2014-02-10 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210175350.GD9995@lunn.ch>
Dear Andrew Lunn,
On Mon, 10 Feb 2014 18:53:50 +0100, Andrew Lunn wrote:
> > +The following is a list of provided IDs for Armada 380/385:
> > +ID Clock Peripheral
> > +-----------------------------------
> > +0 audio Audio
> > +2 ge2 Gigabit Ethernet 2
> > +3 ge1 Gigabit Ethernet 1
> > +4 ge0 Gigabit Ethernet 0
> > +5 pex1 PCIe 1
> > +6 pex2 PCIe 2
> > +7 pex3 PCIe 3
> > +8 pex4 PCIe 0
>
> Is that last one a typo? It at least looks a bit odd.
Right, this should be:
8 pex0 PCIe 0
(just checked again in the datasheet)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH RFC v2 00/35] Second preview of imx-drm cleanup series
From: Russell King - ARM Linux @ 2014-02-10 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+gwMcd+oMUpd2kNCVP4ojsKJtPwCXMgA2RsHT0+=p347n3ODw@mail.gmail.com>
On Mon, Feb 10, 2014 at 06:37:26PM +0100, Philipp Zabel wrote:
> I'd like all of them to go through, too. If you don't want to have the DT
> changes integrated, I'd appreciate if you could have a look at my
> patches on top of your series and possibly append them to your
> series or let me synchronize somehow:
>
> http://archive.arm.linux.org.uk/lurker/message/20140106.145159.a1d82ba9.en.html
I replied to your 2nd patch there...
I'm not happy ending up with a hard dependency between v4l2 code and
code needed for the display side to work, especially when we can end
up with imx-drm being the primary console display. I've outlined my
thoughts about what I think needs to happen in the reply to patch 2.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 07/11] ARM: mvebu: add initial support for the Armada 380/385 SOCs
From: Thomas Petazzoni @ 2014-02-10 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210174404.GC9995@lunn.ch>
Dear Andrew Lunn,
On Mon, 10 Feb 2014 18:44:04 +0100, Andrew Lunn wrote:
> > +config MACH_ARMADA_380
>
> Should this maybe be MACH_ARMADA_38X. You have PINCTRL_ARMADA_38X, so
> it seems a bit inconsistent.
True, will fix this in v2.
> > +static void __init armada_380_timer_and_clk_init(void)
> > +{
> > + of_clk_init(NULL);
> > + clocksource_of_init();
> > + BUG_ON(mvebu_mbus_dt_init());
> > + l2x0_of_init(0, ~0UL);
> > +}
> > +
> > +static const char * const armada_380_dt_compat[] = {
> > + "marvell,armada380",
> > + "marvell,armada385",
> > + NULL,
> > +};
> > +
> > +DT_MACHINE_START(ARMADA_XP_DT, "Marvell Armada 380/385 (Device Tree)")
> > + .init_time = armada_380_timer_and_clk_init,
> > + .restart = mvebu_restart,
> > + .dt_compat = armada_380_dt_compat,
> > +MACHINE_END
>
> This looks very similar to the 375 code. Could they be combined?
It is not entirely clear at this point how different they will be. For
now, the external abort workaround applies only to Armada 375, but that
can easily be checked by looking at the DT compatible string. Maybe we
can decide to have a common file for now, and split it later on if we
realize that the differences are too complex?
Only problem with that (but a problem that is often difficult to
solve) : what should be the same of this file? armada-375-38x.c ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 6/6] dt: Update binding information for mvebu gating clocks with Armada 380/385
From: Andrew Lunn @ 2014-02-10 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392053569-28037-7-git-send-email-gregory.clement@free-electrons.com>
> +The following is a list of provided IDs for Armada 380/385:
> +ID Clock Peripheral
> +-----------------------------------
> +0 audio Audio
> +2 ge2 Gigabit Ethernet 2
> +3 ge1 Gigabit Ethernet 1
> +4 ge0 Gigabit Ethernet 0
> +5 pex1 PCIe 1
> +6 pex2 PCIe 2
> +7 pex3 PCIe 3
> +8 pex4 PCIe 0
Is that last one a typo? It at least looks a bit odd.
Thanks
Andrew
^ permalink raw reply
* OMAP baseline test results for v3.14-rc1
From: Paul Walmsley @ 2014-02-10 17:48 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic OMAP test results for Linux v3.14-rc1.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.14-rc1/20140210035354/
Test summary
------------
Build: uImage+dtb:
Pass ( 9/ 9): omap2plus_defconfig_am33xx_only/am335x-bone,
omap2plus_defconfig/omap4-panda,
omap2plus_defconfig/omap4-panda-es,
omap2plus_defconfig/am3517-evm,
omap2plus_defconfig/omap2430-sdp,
omap2plus_defconfig/omap3-beagle,
omap2plus_defconfig/omap3-beagle-xm,
omap2plus_defconfig/omap3-evm-37xx,
omap2plus_defconfig/omap4-var-som
Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only
Build: zImage:
Pass (13/13): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
omap2plus_defconfig_2430sdp_only,
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_n800_only_a,
omap2plus_defconfig_n800_multi_omap2xxx,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Boot to userspace:
FAIL ( 1/10): 2430sdp
skip ( 2/ 2): 5912osk, cmt3517
Pass ( 9/10): 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
4430es2panda, 4460pandaes, am335xbone, am335xbonelt,
4460varsomom
PM: chip retention via suspend:
FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom
Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm
PM: chip retention via dynamic idle:
FAIL ( 7/ 7): 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm,
4430es2panda, 4460pandaes, 4460varsomom
PM: chip off except CORE via suspend:
FAIL ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle:
FAIL ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes,
4460varsomom
PM: chip off via dynamic idle:
FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes,
4460varsomom
vmlinux object size
(delta in bytes from test_v3.13 (d8ec26d7f8287f5788a494f56e8814210f0e64be)):
text data bss total kernel
+39941 +888 +640 +41469 omap1_defconfig
+38701 +816 +608 +40125 omap1_defconfig_1510innovator_only
+38949 +816 +640 +40405 omap1_defconfig_5912osk_only
+94801 -17448 -9016 +68337 omap2plus_defconfig
+7161037 +361508 +5611136 +13133681 omap2plus_defconfig_2430sdp_only
+101806 +1712 -9144 +94374 omap2plus_defconfig_am33xx_only
+7641123 +429388 +5621344 +13691855 omap2plus_defconfig_am43xx_only
+8210228 +771260 +5651768 +14633256 omap2plus_defconfig_cpupm
+7889789 +453764 +5649080 +13992633 omap2plus_defconfig_dra7xx_only
+3431616 +268188 +5360432 +9060236 omap2plus_defconfig_n800_multi_omap2xxx
+3400380 +241748 +5360424 +9002552 omap2plus_defconfig_n800_only_a
+8094759 +758028 +5642680 +14495467 omap2plus_defconfig_no_pm
+8073679 +611084 +5650040 +14334803 omap2plus_defconfig_omap2_4_only
+8120107 +707676 +5651192 +14478975 omap2plus_defconfig_omap3_4_only
+7886749 +445660 +5649144 +13981553 omap2plus_defconfig_omap5_only
+2117724 +247972 +182980 +2548676 rmk_omap3430_ldp_allnoconfig
+4906713 +344676 +5360616 +10612005 rmk_omap3430_ldp_oldconfig
+2085088 +163420 +183428 +2431936 rmk_omap4430_sdp_allnoconfig
+5408423 +278900 +5392280 +11079603 rmk_omap4430_sdp_oldconfig
Boot-time memory difference
(delta in bytes from test_v3.13 (d8ec26d7f8287f5788a494f56e8814210f0e64be))
avail rsrvd high freed board kconfig
-32k 32k . -8k 2420n800 omap2plus_defconfig_n800_only_a
-88k 88k . -384k 2430sdp omap2plus_defconfig
-188k 188k . . 3517evm omap2plus_defconfig
-220k 220k . . 3530es3beagle omap2plus_defconfig
-220k 220k . . 3730beaglexm omap2plus_defconfig
-180k 180k . . 37xxevm omap2plus_defconfig
-144k 144k . . 4430es2panda omap2plus_defconfig
-144k 144k . . 4460pandaes omap2plus_defconfig
-116k 116k . 12k am335xbone omap2plus_defconfig_am33xx_only
-88k 88k . . am335xbonelt omap2plus_defconfig
The large vmlinux size deltas are due to the OMAP2+ shift from uImage
builds to zImage builds. The script here doesn't track size differences
across kernel build formats, so to that script, it appears that the builds
just started working.
Full-chip power management for OMAP3 is now clearly broken. Folks who
need that for their application should use older kernels. Recollection is
foggy but v3.7 should be pretty good for OMAP3; the clock code & data in
that one is a bit more mature.
The good news is that the 4460 VAR-SOM-OM is now booting again. Removed
the LCD board, which got rid of the noise on the serial line - must have
been leaking through from the inverter. Also switched serial interfaces.
Clearly this needs a bit more investigation.
Looks like the kernel runtime memory bloat trend has resumed.
^ permalink raw reply
* [PATCH 00/11] Core support for Marvell Armada 375 and 38x
From: Jason Gunthorpe @ 2014-02-10 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392053002-19831-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Mon, Feb 10, 2014 at 06:23:11PM +0100, Thomas Petazzoni wrote:
> It is worth noting that contrary to the Marvell 370 and XP support,
> which has been pushed mainline fairly late in the development cycle of
> the SOCs, the support for Armada 375 and 38x is now being pushed quite
> early in the development cycle of the SOCs. We are having mainline
> support pretty much at the same time as the SOCs are being made
> available to customers, which is really great!
Congratulations to Marvell, this is a major achievement!
Jason
^ permalink raw reply
* [PATCH 05/11] ARM: mvebu: add Device Tree for the Armada 375 DB board
From: Thomas Petazzoni @ 2014-02-10 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210173759.GB9995@lunn.ch>
Dear Andrew Lunn,
On Mon, 10 Feb 2014 18:37:59 +0100, Andrew Lunn wrote:
> Hi Thomas
>
> > + mvsdio at d4000 {
> > + pinctrl-0 = <&sdio_pins &sdio_st_pins>;
> > + pinctrl-names = "default";
> > + status = "okay";
> > + cd-gpios = <&gpio1 12 0>;
> > + wp-gpios = <&gpio1 13 0>;
>
> Kirkwood recently started using include/dt-bindings/gpio/gpio.h. Maybe
> you can do the same here?
Sure, will do for the v2!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox