Some of the boards under mach-exynos4 initialize frame-buffers
for which the memory requirement is more than 2MB (Nuri board requires
around 4MB, Origen requires around 2.6MB), hence the default dma pool
allocation size of 2MB is not sufficient. The consistent dma size is
hence increased to successfully allocate memory for those boards.
Depends on "ARM: Add init_consistent_dma_size()"
by Jon Medhurst (99d1717dd7fecf2b10195b0d864323b952b4eba0).
CC: Jon Medhurst <tixy(a)yxit.co.uk>
Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org>
---
arch/arm/mach-exynos4/cpu.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..45d8bfa 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,7 @@
#include <linux/sched.h>
#include <linux/sysdev.h>
+#include <linux/dma-mapping.h>
#include <asm/mach/map.h>
#include <asm/mach/irq.h>
@@ -136,6 +137,7 @@ static void exynos4_idle(void)
void __init exynos4_map_io(void)
{
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
+ init_consistent_dma_size(SZ_8M);
/* initialize device information early */
exynos4_default_sdhci0();
--
1.7.4.1
Hi Zach,
I noticed that you introduced BUGREPORTED on Android blueprints for
the work items.
It raised a couple of questions:
1. what does BUGREPORTED means ?
2. do we need to update
https://wiki.linaro.org/Process/WorkItemsHowto#Work_items_in_the_whiteboard
?
The whiteboard work items are parsed to update status.linaro.org so I
guess these work items are simply skipped.
Cheers,
--
Fathi Boudra
Linaro Release Manager | Validation Project Manager
Linaro.org | Open source software for ARM SoCs
Hello,
I am working on improving the hwpack names delivered by the Linaro Kernel
Continuous Integration.
To start on this I needed inputs from the kernel team.
currently the hwpack containing the newly built kernel debian package is
named for example as
hwpack_linaro-panda_20111004-1126_armel_supported.tar.gz
and it includes
1) The board on which the hwpack can be booted
2) The hwpack creation timestamp includes the date in yyyymmdd format along
with the time in hhmm format.
The hwpack name does not include any defconfig related information, which
was used to build the kernel.
Do we need to use the defconfig name as well to be part of the hwpack name ?
Is there any other information you would like to include in the hwpack name
?
Or do we need to continue with the current hwpack names ?
--
Thanks and Regards,
Deepti
Infrastructure Team Member, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
All,
Our oneiric based images and hwpacks are shaping up in advance of the
11.10 based release. Already you can download from
http://snapshots.linaro.org/oneiric.
Some important things you'll want to be aware of.
We'll be upgrading the version of live-build that we use to generate
our images very soon. (today? tomorrow?) When we do so, it'll change
the format of the root file system tarballs. This unfortunately will
also mean you'll need to obtain a latest greatest version of
linaro-media-create otherwise linaro-media-create will fail.
The change in format of the tarball also means that the rootfs
tarballs will appear to be larger. Don't panic. Once installed with
linaro-media-create the installed image sizes are close to what they
were in natty. The reason for the extra size is live-build is putting
a copy of all the installed .debs into the tarball.
--
Regards,
Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
In drivers/gpio/gpio-samsung.c, there are certain structures
and functions which are not getting used if the particular
CPU is not selected. These code segments are moved under CPU
specific macros to remove compilation warnings.
Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org>
---
It has been build tested with s3c2410_defconfig, s3c6400_defconfig,
s5p64x0_defconfig, s5pc100_defconfig, s5pv210_defconfig and
exynos4_defconfig.
The patch has been rebased onto
Commit: gpio/samsung: correct pin configuration for S5PC100/S5PC110/EXYNOS4
on git://github.com/kgene/linux-samsung.git (next/topic-gpio-samsung)
drivers/gpio/gpio-samsung.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index b6be77a..33d62d1 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -318,6 +318,7 @@ static unsigned samsung_gpio_getcfg_4bit(struct samsung_gpio_chip *chip,
return S3C_GPIO_SPECIAL(con);
}
+#ifdef CONFIG_PLAT_S3C24XX
/*
* s3c24xx_gpio_setcfg_abank - S3C24XX style GPIO configuration (Bank A)
* @chip: The gpio chip that is being configured.
@@ -379,7 +380,9 @@ static unsigned s3c24xx_gpio_getcfg_abank(struct samsung_gpio_chip *chip,
return S3C_GPIO_SFN(con);
}
+#endif
+#if defined(CONFIG_CPU_S5P6440) || defined(CONFIG_CPU_S5P6450)
static int s5p64x0_gpio_setcfg_rbank(struct samsung_gpio_chip *chip,
unsigned int off, unsigned int cfg)
{
@@ -417,6 +420,7 @@ static int s5p64x0_gpio_setcfg_rbank(struct samsung_gpio_chip *chip,
return 0;
}
+#endif
static void __init samsung_gpiolib_set_cfg(struct samsung_gpio_cfg *chipcfg,
int nr_chips)
@@ -438,10 +442,12 @@ struct samsung_gpio_cfg s3c24xx_gpiocfg_default = {
.get_config = samsung_gpio_getcfg_2bit,
};
+#ifdef CONFIG_PLAT_S3C24XX
static struct samsung_gpio_cfg s3c24xx_gpiocfg_banka = {
.set_config = s3c24xx_gpio_setcfg_abank,
.get_config = s3c24xx_gpio_getcfg_abank,
};
+#endif
static struct samsung_gpio_cfg exynos4_gpio_cfg = {
.set_pull = exynos4_gpio_setpull,
@@ -450,6 +456,7 @@ static struct samsung_gpio_cfg exynos4_gpio_cfg = {
.get_config = samsung_gpio_getcfg_4bit,
};
+#if defined(CONFIG_CPU_S5P6440) || defined(CONFIG_CPU_S5P6450)
static struct samsung_gpio_cfg s5p64x0_gpio_cfg_rbank = {
.cfg_eint = 0x3,
.set_config = s5p64x0_gpio_setcfg_rbank,
@@ -457,6 +464,7 @@ static struct samsung_gpio_cfg s5p64x0_gpio_cfg_rbank = {
.set_pull = samsung_gpio_setpull_updown,
.get_pull = samsung_gpio_getpull_updown,
};
+#endif
static struct samsung_gpio_cfg samsung_gpio_cfgs[] = {
{
@@ -682,6 +690,7 @@ static int samsung_gpiolib_4bit2_output(struct gpio_chip *chip,
return 0;
}
+#ifdef CONFIG_PLAT_S3C24XX
/* The next set of routines are for the case of s3c24xx bank a */
static int s3c24xx_gpiolib_banka_input(struct gpio_chip *chip, unsigned offset)
@@ -717,6 +726,7 @@ static int s3c24xx_gpiolib_banka_output(struct gpio_chip *chip,
local_irq_restore(flags);
return 0;
}
+#endif
/* The next set of routines are for the case of s5p64x0 bank r */
--
1.7.4.1
Thanks Michael. I added the toolchain process to the links section.
On 12 October 2011 05:01, Michael Hope <michael.hope(a)linaro.org> wrote:
> For reference, here are the toolchain processes:
> https://wiki.linaro.org/WorkingGroups/ToolChain/GCC/ReleaseProcess
> https://wiki.linaro.org/WorkingGroups/ToolChain/GDB/ReleaseProcess
> https://wiki.linaro.org/WorkingGroups/ToolChain/QemuReleaseProcess
>
> which matches yours pretty well. Our tag names are different - we use
> $product-$upstream-$yyyy.mm instead of $upstream-$yyyy.mm and a
> different commit message.
>
> -- Michael
>
> On Tue, Oct 11, 2011 at 7:09 PM, Fathi Boudra <fathi.boudra(a)linaro.org> wrote:
>> Hi,
>>
>> A document describing how to release Linaro components has been added:
>> http://wiki.linaro.org/Process/ReleaseComponents
>>
>> If you release Linaro components, please take a look.
>> Feedback is welcome to improve the document.
>>
>> Cheers,
>> --
>> Fathi Boudra
>> Linaro Release Manager | Validation Project Manager
>> Linaro.org | Open source software for ARM SoCs
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev(a)lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>>
>
--
Fathi Boudra
Linaro Release Manager | Validation Project Manager
Linaro.org | Open source software for ARM SoCs
One output from the 11.09 release was a reasonably painless way of
cross-building whole images against an archive, which also forms the
basis for an auto-crossbuilder.
There is a HOWTO (for building linaro-nano images) here:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/CrossBuildNano
(It uses armel as the example, but should work the same for armhf)
Summary of process
------------------
Essentially you can generate a cross-building chroot in one command
(using multistrap), chroot into that (using schroot), and give the
builder (xbuilder-simple) a list of packages to build - either a
pre-generated one for an image, or your own.
It chunters through and builds them all (using xdeb), and leaving
build-logs for each package.
Then at the end (from outside the chroot) you cross-generate an image
from the debs (using multistrap, but the pile could be input for a
different tool if you prefer).
------------------
To make this work usefully against a stable (natty) baseline, updated
versions of both tools and packages are in two PPAs at:
https://launchpad.net/~linaro-foundations/+archive/cross-build-tools
and
https://launchpad.net/~linaro-foundations/+archive/cross-alip
Caveats
-------
This is currently a technology demonstration in so far as some of the
packages needed for a nano image don't successfully cross-build, so
you can't actually currently cross-build all of it, but that should be
fixed quite soon. Anyone who wants to help with that is very welcome.
I've filed current status and remaining bugs here:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LinaroNanoStatus
The autobuilder can actually run just as well using pdebuild-cross as
xdeb to do the build-work, but that's not been tested for a while and
is not covered in the HOWTO.
The existing xbuilder is pretty stupid (that's why it's called
xbuilder-simple) and it does not yet fully ensure a clean build
environment every time (when using xdeb, it should if using
pbuilder-cross), but it does enough to work reasonably well in
practice. A more rigorous environment reset is on the list of
improvements RSN.
Ongoing work
------------
The current focus is on getting the remaining packages cross-building
so that the whole process works to completeion without cheating by
bringing in pre-built packages from the existing archive (That's a
useful way to proceed if you want to use this tech today - just adjust
the multistrap config to include the base natty armel/armhf archive too)
Once this is completed I'll be setting up a continuously-running
autobuilder so that the cross-buildability or otherwise of packages
can be more easily discovered and more people can get involved in
fixing up packages so that cross-building of larger images becomes
realistic.
It should be a simple matter of three multistrap config file changes
to use this on an oneiric base, but it broke in a painfull mess of
bind-mounts of deleted /run dirs when I tried it last week, so I'd
hold off that for a little while, and stick with the nice natty-based
examples. I'll add destructions to the HOWTO when I've got it going.
I hope some of you find this useful, or at least interesting. I could
really use some help on fixing up breakage in assorted packages, and
this HOWTO makes it easy to set up a consistent build environment, so
do give it a try and get stuck in if you'd like to see this working
fully sooner rather than later.
Reports of success, breakage, miserable failure, or how this
almost-but-doesn't-quite address your use case are always welcome of
course.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
I work to link the cpu_power of ARM cores to their frequency by using
arch_scale_freq_power. It's explained in the kernel that cpu_power is
used to distribute load on cpus and a cpu with more cpu_power will
pick up more load. The default value is SCHED_POWER_SCALE and I
increase the value if I want a cpu to have more load than another one.
Is there an advised range for cpu_power value as well as some time
scale constraints for updating the cpu_power value ?
I'm also wondering why this scheduler feature is currently disable by default ?
Regards,
Vincent