Re: [PATCH 00/12][RFC] Intial Kconfig Fragment Demo
cc'ing Ubuntu kernel team. We use their config system today and this might be of interest to them for the future. On Wed, Mar 9, 2011 at 4:32 AM, John Stultz john.stu...@linaro.org wrote: This patch set provides enough to demo how the Kconfig fragment based defconfigs could be used to simplify both generating and managing the configs used to build Linaro kernels. This is for the kernel config managment tool and dependent bluprints: https://blueprints.launchpad.net/linux-linaro/+spec/other-kernel-config-management-tool The basic idea is to use a Kconfig fragment to generate the per-board defconfigs. The Kconfig fragments contain a meta-option that defaults to yes, which then selects the needed config values to enable a system. This has been proposed by others, and we're using Stephen Rothwell's initial patch to start things off. Once we have the infrasturcture to use Kconfig fragments for defconfigs we had to overcome some limitations: 1) We cannot select items from a choice block 2) We need a way to select for values and modules. Limitation #1 is resolved by a patch to the kbuild system I made. Limitation #2 is unsolved, but Jason Hui found a workaround that is sufficient. Basically we can just redefine the default with a short declaration: config VAL default 256 or config VAL default m With these two solutions, I went forward generating basic Kconfig fragments for omap3, imx51 and vexpress. Getting per-board defconfigs is only of limited value, because we also want to be able to have a common policy settings for Linaro kernels. Many distros run into this problem, and use .config fragments which are then assembled at package build time. My solution is to have a Kconfig.distro file, which is patched with Distro specific policy config, such as which filesystems should be enabled, networking policy, debug options, or periphrial driver modules that should be enabled. Basically anything that isn't hardware specific (by that I mean, part of the architecture or wired on the board). The Ubuntu configs do something similar. The config generator makes a 3-level config - distro, arch, board. But this is encapsulated under the debian packaging rather than in the kernel source. That is why you probably haven't seen it yet. Look at git://git.linaro.org/ubuntu/linux-linaro-natty.git under debian.linaro/config. Most kernel developers, however, don't really care about creating a .deb package of the kernel to test new code. They'd rather have the config available in the sources. So I agree that we should fix this problem for them. If it turns out that in fixing this problem we fix it for distros too, great! From there, I add in as much of the generic Linaro config policy as I could, utilizing the config files that were used to build the omap3, imx51 and vexpress hardware packs. Since the Linaro config polciy is not unified at this point (in other words, each board has totally different set of generic policy options configured). I added the per target differences into the board kconfig fragments. No, it doesn't. The system they use allows for unified configs. The Ubuntu kernel has unified configs across 3-4 architectures. The problem is starting a new config for a new board/SoC. The current config system expects a full config for the board dropped into place and then let the tool split it out into distro/arch and board components. If this causes any changes to the distro/arch configs, you know you might have missed some options. Ideally we can review and settle down on specific linaro config policy and this generic per-board stuff can go away. These are initial and rough patches, but are the result of lots of painful manual labor to match the Linaro .configs as closely as possible. There are a few remaining issues, but these can probably be worked around: 1) Omap has a strange tristate choice option for the usb gadget options. So you can only pick one, or you can pick multiple items as modules. My choice selection patch doesn't yet address this. I need to see how common this style of choice is and see if we can either just make it a non-choice options block or if other fixes are needed. 2) Not having a module selction is a little painful, as the module default m entries are numerous and annoyingly separate from the meta-config selects. 3) The Kconfig.distro file should be probably broken up into policy topics, like networking, filesystems, peripherials, etc. 4) The current board Kconfig fragments are named slightly differently from the standard defconfigs to allow testing with both. That will need to be fixed, and the old defconfigs removed prior to submitting. 5) The igep, overo, and panda configs all use the same omap3 config according to the hwpacks. I'm not sure I believe that, but went along with it to get this out the door. They do use the same config - or 'flavour' as they are
Re: [PATCH 00/12][RFC] Intial Kconfig Fragment Demo
On Wed, Mar 9, 2011 at 10:30 AM, Andy Green a...@warmcat.com wrote: On 03/09/2011 08:17 AM, Somebody in the thread at some point said: Hi - 5) The igep, overo, and panda configs all use the same omap3 config according to the hwpacks. I'm not sure I believe that, but went along with it to get this out the door. They do use the same config - or 'flavour' as they are referred to in the Ubuntu kernel config system. Panda is OMAP4 and the other two are OMAP3 AIUI, I am aware they are all under OMAP2+ in the kernel, but there are really significant differences from configuration point of view like SMP or not. How is that handled with the same config? One can build a single kernel binary that runs on OMAP2/3/4 platforms from the mainline kernel. That has been the main requirement from the maintainer to add new board support. Everything under mach-omap2 and plat-omap is written for runtime detection of features. However, last I looked, there were problems with the ARM locking primitives being patched at runtime. So it prevented SMP-on-UP kernels, that is, SMP had to be turned off. But that will eventually get fixed so you could have a SMP kernel running on a UP system. This is how x86 does it today. /Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 1/5] arm/dt: add basic mx51 device tree support
On Wed, Mar 09, 2011, Jason Hui wrote: + * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved. Copyright 2011 Linaro Ltd. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Tue, Mar 8, 2011 at 4:39 PM, Loïc Minier loic.min...@linaro.org wrote:
On Wed, Mar 09, 2011, Shawn Guo wrote:
I just added this one, and it does not help. The l-m-c still fails at
the last step.
mkimage: Write error on /tmp/tmpUiR_m1/boot-disc/uImage: Success
This error sounded a bit weird; I checked the u-boot sources, and this
string is used in a bunch of places, but essentially it's either on
write() or on close() that this fails. I bet it's on write() as I
don't see close() failing without an useful errno, but I could imagine
the write tests failing:
if (write(ifd, tparams-hdr, tparams-header_size)
!= tparams-header_size) {
fprintf (stderr, %s: Write error on %s: %s\n,
params.cmdname, params.imagefile, strerror(errno));
notably if this is a partial write.
libc.info in particular says (of write()):
The return value is the number of bytes actually written. This
may be SIZE, but can always be smaller. Your program should
always call `write' in a loop, iterating until all the data is
written.
We could change mkimage's write()s to actually account for the number
of bytes written rather than just failing when not all bytes were
written.
There's no reason I can see for mkimage to use the low-level POSIX
read/write interface. Life would be simpler (and more portable) if it
just used stdio, because it provides the desired semantics...
More realistically, we could just propose a write() wrapper contains
the necessary loop to provide the expected semantics.
We should check for other instances of the same error, possibly
including calls to read() as well. However, I can't find clear
documentation on whether a short read() should ever occur on a normal
file in the absence of signals, provided there is enough data in the
file. Usually I assume that short reads might happen because
otherwise the program won't work properly on pipes, sockets etc., but
this is probably not so much of a concern for mkimage.
The natty version of u-boot has just the same error with write(); see:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/u-boot/natty/view/head:/tools/mkimage.c
The upstream master branch of U-Boot on git://git.denx.de/u-boot.git
has the bug too.
Cheers
---Dave
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 1/5] arm/dt: add basic mx51 device tree support
Hi, Loic, On Wed, Mar 9, 2011 at 6:33 PM, Loïc Minier loic.min...@linaro.org wrote: On Wed, Mar 09, 2011, Jason Hui wrote: + * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved. Copyright 2011 Linaro Ltd. I will resend the whole patchset and use Linaro copyright and sign off. Thanks for it. BR, Jason -- Loďc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 1/5] arm/dt: add basic mx51 device tree support
On Wed, Mar 09, 2011, Jason Hui wrote: I will resend the whole patchset and use Linaro copyright and sign off. Thanks for it. Awesome, thanks! (And sorry that I can't provide any technical feedback on the patches, but it is certainly nice to see imx51 + DT booting with enough devices in DT to bring up a NFS root!) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCHv2 2/3] hwmem: Add hwmem (part 2)
Add hardware memory driver, part 2.
The main purpose of hwmem is:
* To allocate buffers suitable for use with hardware. Currently
this means contiguous buffers.
* To synchronize the caches for the allocated buffers. This is
achieved by keeping track of when the CPU uses a buffer and when
other hardware uses the buffer, when we switch from CPU to other
hardware or vice versa the caches are synchronized.
* To handle sharing of allocated buffers between processes i.e.
import, export.
Hwmem is available both through a user space API and through a
kernel API.
Signed-off-by: Johan Mossberg johan.xx.mossb...@stericsson.com
---
drivers/misc/hwmem/cache_handler.c | 510
drivers/misc/hwmem/cache_handler.h | 61 +
2 files changed, 571 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/hwmem/cache_handler.c
create mode 100644 drivers/misc/hwmem/cache_handler.h
diff --git a/drivers/misc/hwmem/cache_handler.c
b/drivers/misc/hwmem/cache_handler.c
new file mode 100644
index 000..e0ab4ee
--- /dev/null
+++ b/drivers/misc/hwmem/cache_handler.c
@@ -0,0 +1,510 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * Cache handler
+ *
+ * Author: Johan Mossberg johan.xx.mossb...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+
+#include linux/hwmem.h
+
+#include asm/pgtable.h
+
+#include mach/dcache.h
+
+#include cache_handler.h
+
+#define U32_MAX (~(u32)0)
+
+enum hwmem_alloc_flags cachi_get_cache_settings(
+ enum hwmem_alloc_flags requested_cache_settings);
+void cachi_set_pgprot_cache_options(enum hwmem_alloc_flags cache_settings,
+ pgprot_t *pgprot);
+
+static void sync_buf_pre_cpu(struct cach_buf *buf, enum hwmem_access access,
+ struct hwmem_region *region);
+static void sync_buf_post_cpu(struct cach_buf *buf,
+ enum hwmem_access next_access, struct hwmem_region *next_region);
+
+static void invalidate_cpu_cache(struct cach_buf *buf,
+ struct cach_range *range_2b_used);
+static void clean_cpu_cache(struct cach_buf *buf,
+ struct cach_range *range_2b_used);
+static void flush_cpu_cache(struct cach_buf *buf,
+ struct cach_range *range_2b_used);
+
+static void null_range(struct cach_range *range);
+static void expand_range(struct cach_range *range,
+ struct cach_range *range_2_add);
+/*
+ * Expands range to one of enclosing_range's two edges. The function will
+ * choose which of enclosing_range's edges to expand range to in such a
+ * way that the size of range is minimized. range must be located inside
+ * enclosing_range.
+ */
+static void expand_range_2_edge(struct cach_range *range,
+ struct cach_range *enclosing_range);
+static void shrink_range(struct cach_range *range,
+ struct cach_range *range_2_remove);
+static bool is_non_empty_range(struct cach_range *range);
+static void intersect_range(struct cach_range *range_1,
+ struct cach_range *range_2, struct cach_range *intersection);
+/* Align_up restrictions apply here to */
+static void align_range_up(struct cach_range *range, u32 alignment);
+static u32 range_length(struct cach_range *range);
+static void region_2_range(struct hwmem_region *region, u32 buffer_size,
+ struct cach_range *range);
+
+static void *offset_2_vaddr(struct cach_buf *buf, u32 offset);
+static u32 offset_2_paddr(struct cach_buf *buf, u32 offset);
+
+/* Saturates, might return unaligned values when that happens */
+static u32 align_up(u32 value, u32 alignment);
+static u32 align_down(u32 value, u32 alignment);
+
+/*
+ * Exported functions
+ */
+
+void cach_init_buf(struct cach_buf *buf, enum hwmem_alloc_flags cache_settings,
+ u32 size)
+{
+ buf-vstart = NULL;
+ buf-pstart = 0;
+ buf-size = size;
+
+ buf-cache_settings = cachi_get_cache_settings(cache_settings);
+}
+
+void cach_set_buf_addrs(struct cach_buf *buf, void* vaddr, u32 paddr)
+{
+ bool tmp;
+
+ buf-vstart = vaddr;
+ buf-pstart = paddr;
+
+ if (buf-cache_settings HWMEM_ALLOC_HINT_CACHED) {
+ /*
+* Keep whatever is in the cache. This way we avoid an
+* unnecessary synch if CPU is the first user.
+*/
+ buf-range_in_cpu_cache.start = 0;
+ buf-range_in_cpu_cache.end = buf-size;
+ align_range_up(buf-range_in_cpu_cache,
+ get_dcache_granularity());
+ buf-range_dirty_in_cpu_cache.start = 0;
+ buf-range_dirty_in_cpu_cache.end
[PATCHv2 1/3] hwmem: Add hwmem (part 1)
Add hardware memory driver, part 1.
The main purpose of hwmem is:
* To allocate buffers suitable for use with hardware. Currently
this means contiguous buffers.
* To synchronize the caches for the allocated buffers. This is
achieved by keeping track of when the CPU uses a buffer and when
other hardware uses the buffer, when we switch from CPU to other
hardware or vice versa the caches are synchronized.
* To handle sharing of allocated buffers between processes i.e.
import, export.
Hwmem is available both through a user space API and through a
kernel API.
Signed-off-by: Johan Mossberg johan.xx.mossb...@stericsson.com
---
drivers/misc/Kconfig |1 +
drivers/misc/Makefile|1 +
drivers/misc/hwmem/Kconfig |7 +
drivers/misc/hwmem/Makefile |3 +
drivers/misc/hwmem/hwmem-ioctl.c | 455 ++
drivers/misc/hwmem/hwmem-main.c | 799 ++
include/linux/hwmem.h| 536 +
7 files changed, 1802 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/hwmem/Kconfig
create mode 100644 drivers/misc/hwmem/Makefile
create mode 100644 drivers/misc/hwmem/hwmem-ioctl.c
create mode 100644 drivers/misc/hwmem/hwmem-main.c
create mode 100644 include/linux/hwmem.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index cc8e49d..6d83fb8 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -457,5 +457,6 @@ source drivers/misc/eeprom/Kconfig
source drivers/misc/cb710/Kconfig
source drivers/misc/iwmc3200top/Kconfig
source drivers/misc/ti-st/Kconfig
+source drivers/misc/hwmem/Kconfig
endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 98009cc..698b4f6 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o
obj-$(CONFIG_PCH_PHUB) += pch_phub.o
obj-y += ti-st/
obj-$(CONFIG_AB8500_PWM) += ab8500-pwm.o
+obj-$(CONFIG_HWMEM)+= hwmem/
diff --git a/drivers/misc/hwmem/Kconfig b/drivers/misc/hwmem/Kconfig
new file mode 100644
index 000..c161875
--- /dev/null
+++ b/drivers/misc/hwmem/Kconfig
@@ -0,0 +1,7 @@
+config HWMEM
+ bool Hardware memory driver
+ default n
+ help
+ This driver provides a way to allocate memory suitable for use with
+ both CPU and non-CPU hardware, handles the caches for allocated
+ memory and enables inter-process sharing of allocated memory.
diff --git a/drivers/misc/hwmem/Makefile b/drivers/misc/hwmem/Makefile
new file mode 100644
index 000..18da2ad
--- /dev/null
+++ b/drivers/misc/hwmem/Makefile
@@ -0,0 +1,3 @@
+hwmem-objs := hwmem-main.o hwmem-ioctl.o cache_handler.o
+
+obj-$(CONFIG_HWMEM) += hwmem.o
diff --git a/drivers/misc/hwmem/hwmem-ioctl.c b/drivers/misc/hwmem/hwmem-ioctl.c
new file mode 100644
index 000..69a15a6
--- /dev/null
+++ b/drivers/misc/hwmem/hwmem-ioctl.c
@@ -0,0 +1,455 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * Hardware memory driver, hwmem
+ *
+ * Author: Marcus Lorentzon marcus.xm.lorent...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/idr.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/miscdevice.h
+#include linux/uaccess.h
+#include linux/mm_types.h
+#include linux/hwmem.h
+#include linux/device.h
+#include linux/sched.h
+
+static int hwmem_open(struct inode *inode, struct file *file);
+static int hwmem_ioctl_mmap(struct file *file, struct vm_area_struct *vma);
+static int hwmem_release_fop(struct inode *inode, struct file *file);
+static long hwmem_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg);
+static unsigned long hwmem_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len, unsigned long pgoff,
+ unsigned long flags);
+
+static const struct file_operations hwmem_fops = {
+ .open = hwmem_open,
+ .mmap = hwmem_ioctl_mmap,
+ .unlocked_ioctl = hwmem_ioctl,
+ .release = hwmem_release_fop,
+ .get_unmapped_area = hwmem_get_unmapped_area,
+};
+
+static struct miscdevice hwmem_device = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = hwmem,
+ .fops = hwmem_fops,
+};
+
+struct hwmem_file {
+ struct mutex lock;
+ struct idr idr; /* id - struct hwmem_alloc*, ref counted */
+ struct hwmem_alloc *fd_alloc; /* Ref counted */
+};
+
+static s32 create_id(struct hwmem_file *hwfile, struct hwmem_alloc *alloc)
+{
+ int id, ret;
+
+ while (true) {
+ if (idr_pre_get(hwfile-idr, GFP_KERNEL) == 0)
+ return -ENOMEM;
+
+ ret = idr_get_new_above(hwfile-idr, alloc, 1, id);
+ if (ret == 0)
+ break;
+ else if (ret != -EAGAIN)
+ return -ENOMEM;
[PATCHv2 3/3] hwmem: Add hwmem to ux500
Signed-off-by: Johan Mossberg johan.xx.mossb...@stericsson.com
---
arch/arm/mach-ux500/Makefile |2 +-
arch/arm/mach-ux500/board-mop500.c |1 +
arch/arm/mach-ux500/dcache.c | 266
arch/arm/mach-ux500/devices.c | 31
arch/arm/mach-ux500/include/mach/dcache.h | 26 +++
arch/arm/mach-ux500/include/mach/devices.h |1 +
6 files changed, 326 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-ux500/dcache.c
create mode 100644 arch/arm/mach-ux500/include/mach/dcache.h
diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index b549a8f..b8f02aa 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -3,7 +3,7 @@
#
obj-y := clock.o cpu.o devices.o devices-common.o \
- id.o usb.o
+ id.o usb.o dcache.o
obj-$(CONFIG_UX500_SOC_DB5500) += cpu-db5500.o dma-db5500.o
obj-$(CONFIG_UX500_SOC_DB8500) += cpu-db8500.o devices-db8500.o prcmu.o
obj-$(CONFIG_MACH_U8500) += board-mop500.o board-mop500-sdi.o \
diff --git a/arch/arm/mach-ux500/board-mop500.c
b/arch/arm/mach-ux500/board-mop500.c
index 648da5a..3003b65 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -248,6 +248,7 @@ static void mop500_prox_deactivate(struct device *dev)
/* add any platform devices here - TODO */
static struct platform_device *platform_devs[] __initdata = {
mop500_gpio_keys_device,
+ ux500_hwmem_device,
};
#ifdef CONFIG_STE_DMA40
diff --git a/arch/arm/mach-ux500/dcache.c b/arch/arm/mach-ux500/dcache.c
new file mode 100644
index 000..314e78b
--- /dev/null
+++ b/arch/arm/mach-ux500/dcache.c
@@ -0,0 +1,266 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * Cache handler integration and data cache helpers.
+ *
+ * Author: Johan Mossberg johan.xx.mossb...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+
+#include linux/hwmem.h
+#include linux/dma-mapping.h
+
+#include asm/pgtable.h
+#include asm/cacheflush.h
+#include asm/outercache.h
+#include asm/system.h
+
+/*
+ * Values are derived from measurements on HREFP_1.1_V32_OM_S10 running
+ * u8500-android-2.2_r1.1_v0.21.
+ *
+ * A lot of time can be spent trying to figure out the perfect breakpoints but
+ * for now I've chosen the following simple way.
+ *
+ * breakpoint = best_case + (worst_case - best_case) * 0.666
+ * The breakpoint is moved slightly towards the worst case because a full
+ * clean/flush affects the entire system so we should be a bit careful.
+ *
+ * BEST CASE:
+ * Best case is that the cache is empty and the system is idling. The case
+ * where the cache contains only targeted data could be better in some cases
+ * but it's hard to do measurements and calculate on that case so I choose the
+ * easier alternative.
+ *
+ * outer_clean_breakpoint = time_2_range_clean_on_empty_cache(
+ * complete_clean_on_empty_cache_time)
+ * outer_flush_breakpoint = time_2_range_flush_on_empty_cache(
+ * complete_flush_on_empty_cache_time)
+ *
+ * WORST CASE:
+ * Worst case is that the cache is filled with dirty non targeted data that
+ * will be used after the synchronization and the system is under heavy load.
+ *
+ * outer_clean_breakpoint = time_2_range_clean_on_empty_cache(
+ * complete_clean_on_full_cache_time +
+ * (complete_clean_on_full_cache_time -
+ * complete_clean_on_empty_cache_time))
+ * Plus (complete_flush_on_full_cache_time -
+ * complete_flush_on_empty_cache_time) because no one else can work when we
+ * hog the bus with our unecessary transfer.
+ * outer_flush_breakpoint = time_2_range_flush_on_empty_cache(
+ * complete_flush_on_full_cache_time * 2 +
+ * (complete_flush_on_full_cache_time -
+ * complete_flush_on_empty_cache_time) * 2)
+ *
+ * These values might have to be updated if changes are made to the CPU, L2$,
+ * memory bus or memory.
+ */
+/* 254069 */
+static const u32 outer_clean_breakpoint = 68041 + (347363 - 68041) * 0.666;
+/* 485414 */
+static const u32 outer_flush_breakpoint = 68041 + (694727 - 68041) * 0.666;
+
+static bool is_cache_exclusive(void);
+
+enum hwmem_alloc_flags cachi_get_cache_settings(
+ enum hwmem_alloc_flags requested_cache_settings)
+{
+ static const u32 CACHE_ON_FLAGS_MASK = HWMEM_ALLOC_HINT_CACHED |
+ HWMEM_ALLOC_HINT_CACHE_WB | HWMEM_ALLOC_HINT_CACHE_WT |
+ HWMEM_ALLOC_HINT_CACHE_NAOW | HWMEM_ALLOC_HINT_CACHE_AOW |
+ HWMEM_ALLOC_HINT_INNER_AND_OUTER_CACHE |
+
Re: problem with linaro-media-create
On Tue, Mar 08, 2011 at 04:59:18PM +0100, Loïc Minier wrote: On Tue, Mar 08, 2011, Shawn Guo wrote: I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test. 1) Transend 4GB SD 2) SanDisk 2GB SD 3) KingMax MMC Mobile 2GB All above 3 cards passed the test with giving Could list partitions after 0 seconds! 4) SanDisk 4GB SD 5) SanDisk 4GB SD 6) SanDisk 4GB SD 7) SanDisk 4GB SD All above 4 cards failed with giving Giving up after 30 seconds failing to list partitions. The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it. This is really valuable data; SanDisk 4 GB SDs seem to be a trend above! It would be interesting if you could borrow another USB reader for some hours to run the tests on the same SD cards, but a different adapter. Today in office, with another reader and another maverick machine, the result seems consistent. The new thing is those four failing cards sometime ends up with Could list partitions after 2 seconds!, besides the two possible results reported before, 0 second and failed to list. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[NOTES] Android Platform Team meeting 2011-03-09
Hi, The notes and actions for this weeks Android Platform Team meeting along with team activity reports are now available at: https://wiki.linaro.org/Platform/Android/Meetings/2011-03-09 = Actions Recorded = * jserv-- to produce a Blueprint at http://launchpad.net/linaro-android to capture pandroid fbdev investigations * patrikryd to confirm https://android-build.linaro.org/job/android-u8500href/ tarballs work and fix if necessary * jserv-- and jeremychang to split up Validation Blueprints * jserv-- and jeremychang to split up Linaro toolchain Blueprint * jserv-- and jeremychang to split up Linaro Evaluation Builds for Android Blueprint into board specific Blueprints * jeremychang to check with jstultz on the status of android_omap4_defconfig Regards, Jamie. -- Linaro Release Manager | Platform Project Manager ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Wed, Mar 09, 2011 at 09:01:33PM +0800, Shawn Guo wrote: On Tue, Mar 08, 2011 at 04:59:18PM +0100, Loïc Minier wrote: On Tue, Mar 08, 2011, Shawn Guo wrote: I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test. 1) Transend 4GB SD 2) SanDisk 2GB SD 3) KingMax MMC Mobile 2GB All above 3 cards passed the test with giving Could list partitions after 0 seconds! 4) SanDisk 4GB SD 5) SanDisk 4GB SD 6) SanDisk 4GB SD 7) SanDisk 4GB SD All above 4 cards failed with giving Giving up after 30 seconds failing to list partitions. The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it. This is really valuable data; SanDisk 4 GB SDs seem to be a trend above! It would be interesting if you could borrow another USB reader for some hours to run the tests on the same SD cards, but a different adapter. Today in office, with another reader and another maverick machine, the result seems consistent. The new thing is those four failing cards sometime ends up with Could list partitions after 2 seconds!, besides the two possible results reported before, 0 second and failed to list. I just tried another SanDisk 4GB SD card (#8) borrowed from colleague. With 20 iterations testing, it reports: Could list partitions after 0 seconds! -- 13 times Could list partitions after 2 seconds! -- 5 times Could list partitions after 4 seconds! -- once Could list partitions after 8 seconds! -- once But it never ends up Giving up after 30 seconds failing to list partitions. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Wed, Mar 09, 2011, Shawn Guo wrote: I just tried another SanDisk 4GB SD card (#8) borrowed from colleague. With 20 iterations testing, it reports: Could list partitions after 0 seconds! -- 13 times Could list partitions after 2 seconds! -- 5 times Could list partitions after 4 seconds! -- once Could list partitions after 8 seconds! -- once Gah that's still pretty bad, but I guess we could wait up to 30 seconds and output some messages on the console. Guilherme, what do you think? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[REMINDER] Weekly Release Meeting 2011-03-10
Hi, The weekly Linaro Release Meeting will be held at 17:00 UTC tomorrow. The agenda for the meeting can be found at: https://wiki.linaro.org/Releases/WeeklyReleaseMeeting/2011-03-10 and previous action items were: * Mounir to investigate the status of the Panda display problem * Mounir to ask the kernel team to triage bugs at https://bugs.launchpad.net/linux-linaro If you have points to raise or bugs that need to be discussed please add them to the wiki page above. This meeting is for everyone to discuss issues that may affect the ability to showcase Linaro's efforts in the released images so please add anything to the agenda that you feel falls into this category. The agenda will change a little this week, we will have image reports for our target releases done by: * Ubuntu Desktop and others - Tom Gall * Linaro Android - Patrik Ryd (Jamie Bennett this week) The full agenda is: * Announcements - Jamie Bennett with time for others to announce * Action Item Review - Jamie Bennett chasing * Image Status - Tom Gall and Patrik Ryd * Bugs - Jamie Bennett chair, others discuss * Team release-related reports (any team-focused release topics) * Any Other Business (AOB) Regards, Jamie. -- Linaro Release Manager | Platform Project Manager ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PM] 09/03/2011 - Minutes for the Power Management WG weekly call
Hi All, The minutes of the power management weekly call can be found at : https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-03-09 Highlights: Discussion on Hotplug vs. scheduler tunable to hit retention Regards, Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Notes and actions from the Infrastructure team meeting 2011-03-08
Hi, You can get all the information at https://wiki.linaro.org/Platform/Infrastructure/Meetings/2011-03-08 Thanks, James == Agenda == * Actions from last meeting * Team Status * AOB == Past Action items == * james_w to co-ordinate deployment of salgado's patchwork tree in his absence * james_w to email salgado about patch metrics * james_w to get deepti a machine to host jenkins * mabac to request reviews for some svammel changes, and review some code from other team members * salgado to send deployment docs to the patchwork RT ticket when ready * james_w to request status reports on Monday == Action Items == * james_w to co-ordinate deployment of salgado's patchwork tree in his absence * mabac to request reviews for some svammel changes, and review some code from other team members * salgado to send deployment docs to the patchwork RT ticket when ready * james_w to reassign CI spec and ask for workitems * mwhudson to add some people to https://launchpad.net/~linaro-android-builders * mwhudson to talk to plars about lava ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 01/12] kbuild: Allow configs from choice blocks to be selected.
On Wed, Mar 9, 2011 at 1:38 AM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 09 March 2011 03:32:35 John Stultz wrote: In looking at trying to replace defconfigs with kconfig fragments, one limitation identified is that config items in choice blocks cannot be selected by other config options. One way to doge this would be to create non-visible meta options that change the choice block's default, but that would require additional meta-configs per-choice config, plus a conditional default per meta-config. That just seemed too ugly. So I looked into how to allow the choice default to be overrided by a select statment, and the following patch is the result. I'm very new to kconfig code, so I expect that my changes are probably broken in some subtle way, but in my testing it seems to work. The select only chagnes the default, which can be overrided by the user via the menu. This allows kconfig fragments to work for make defconfig, while not restricting user customization. Thoughts and feedback (or alternate approaches) would be appreciated. thanks -john CC: Grant Likely grant.lik...@secretlab.ca CC: Jason Hui jason@linaro.org CC: patc...@linaro.org Signed-off-by: John Stultz john.stu...@linaro.org The patch looks fine to me (as far as my little Kconfig knowledge goes). Two comments about the submission form though: * Ideally, the initial description is split into two parts: one that is suitable as a changelog and the other that is your personal comment, including the thanks part, and put it below the --- line, so that git can automatically cut it. * I think you should also Cc the Kconfig maintainer, Roman Zippel zip...@linux-m68k.org, and linux-kbu...@vger.kernel.org. And linux-kernel. This definitely needs wider circulation, and I'd like to see a push to get this accepted upstream before adding it to the Linaro kernel tree. g. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Wed, 2011-03-09 at 14:34 +0100, Loïc Minier wrote: On Wed, Mar 09, 2011, Shawn Guo wrote: I just tried another SanDisk 4GB SD card (#8) borrowed from colleague. With 20 iterations testing, it reports: Could list partitions after 0 seconds! -- 13 times Could list partitions after 2 seconds! -- 5 times Could list partitions after 4 seconds! -- once Could list partitions after 8 seconds! -- once Gah that's still pretty bad, but I guess we could wait up to 30 seconds and output some messages on the console. Guilherme, what do you think? Do we know why this happens in some cases? It'd be better if we could only sleep when we know there's a chance that the partitions may be available after that. -- Guilherme Salgado https://launchpad.net/~salgado signature.asc Description: This is a digitally signed message part ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 00/12][RFC] Intial Kconfig Fragment Demo
On Wed, 2011-03-09 at 10:17 +0200, Amit Kucheria wrote: On Wed, Mar 9, 2011 at 4:32 AM, John Stultz john.stu...@linaro.org wrote: My solution is to have a Kconfig.distro file, which is patched with Distro specific policy config, such as which filesystems should be enabled, networking policy, debug options, or periphrial driver modules that should be enabled. Basically anything that isn't hardware specific (by that I mean, part of the architecture or wired on the board). The Ubuntu configs do something similar. The config generator makes a 3-level config - distro, arch, board. But this is encapsulated under the debian packaging rather than in the kernel source. That is why you probably haven't seen it yet. Look at git://git.linaro.org/ubuntu/linux-linaro-natty.git under debian.linaro/config. Most kernel developers, however, don't really care about creating a .deb package of the kernel to test new code. They'd rather have the config available in the sources. So I agree that we should fix this problem for them. If it turns out that in fixing this problem we fix it for distros too, great! Yea, I am aware of some of the approaches that distros use, usually assembling .config fragments into a larger config at build time. And its in part because each distro has tried to solve the same issue out of the kernel that I'm interested in trying to solve the problem in the kernel source at the Kconfig level. From there, I add in as much of the generic Linaro config policy as I could, utilizing the config files that were used to build the omap3, imx51 and vexpress hardware packs. Since the Linaro config polciy is not unified at this point (in other words, each board has totally different set of generic policy options configured). I added the per target differences into the board kconfig fragments. No, it doesn't. The system they use allows for unified configs. The Ubuntu kernel has unified configs across 3-4 architectures. Huh. Are you sure? Because the configs found in the hwpacks are very different. I'll grant that the build system allows for unified config, but I don't think the Linaro kernels are making much use of it. omap vs vexpress being the best example of really wide differences: o cgroup support o bsd process accounting o xattr support for ext3/ext4 o different preempt models o highres timers no_hz etc.. The problem is starting a new config for a new board/SoC. The current config system expects a full config for the board dropped into place and then let the tool split it out into distro/arch and board components. If this causes any changes to the distro/arch configs, you know you might have missed some options. I'll have to take a look at this. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 01/12] kbuild: Allow configs from choice blocks to be selected.
On Wed, 2011-03-09 at 09:38 +0100, Arnd Bergmann wrote: On Wednesday 09 March 2011 03:32:35 John Stultz wrote: Thoughts and feedback (or alternate approaches) would be appreciated. thanks -john CC: Grant Likely grant.lik...@secretlab.ca CC: Jason Hui jason@linaro.org CC: patc...@linaro.org Signed-off-by: John Stultz john.stu...@linaro.org The patch looks fine to me (as far as my little Kconfig knowledge goes). Two comments about the submission form though: * Ideally, the initial description is split into two parts: one that is suitable as a changelog and the other that is your personal comment, including the thanks part, and put it below the --- line, so that git can automatically cut it. Yea, although early on I tend to be a little more informal, I do usually clean up the commit log before actually submitting anything more then RFC level code. * I think you should also Cc the Kconfig maintainer, Roman Zippel zip...@linux-m68k.org, and linux-kbu...@vger.kernel.org. This patch was actually submitted to both a few weeks ago. In this case, as I'm trying to RFC the overview of what I'm trying to accomplish specifically on the linaro list, I trimmed the cc list. Once I sort out the Linaro distro policy bits, and can drop the last quarter of the patch set, I'll likely resubmit the entirety to the kbuild list (and Roman, although he seems to be MIA these days). thanks for the feedback! -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 06/12] Initial omap3 Kconfig fragment
On Wed, 2011-03-09 at 09:48 +0100, Arnd Bergmann wrote: On Wednesday 09 March 2011 03:32:40 John Stultz wrote: + + +source Kconfig.distro + I think we want something more flexible than sourcing a global Kconfig.distro from the board file. First of all, we want at least three levels, as Amit mentioned: distro, arch, board. I can think of at least another one: flavor for common variants of the distro config, e.g. if you want to enable a lot of debugging options or turn your root file systems into =y so you can work without initramfs. Would it be possible to pass multiple Kconfig fragments to the Kconfig parser instead of just one top-level file that sources all the other ones? Yep. I'd like to do exactly this in the future (probably a first pass will just generate a tmp file that sources the multiple fragments provided). But I wanted to get the proof of concept out there first, so it hasn't been as much of a priority. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Making linaro-nano smaller or Give Up Disk Space for Lent
Hi All, In the developer platforms team we're working on getting the linaro-nano image so that it is considerably smaller. To date I've been using the approach I outlined last fall in a previous post to this list. Some highlights to nano: * The linaro-image boots just as our linaro-headless image did (upstart and friends) * it can be updated, or additional pkgs installed via apt-get * networking works * busybox is in use tho not necessarily universally * ureadahead, python, have been removed * docs have been removed * linux-firmware has been removed (binary kernel firmware blobs) * locales is remove Installed image is 125 Megs. (Down from 290 Meg) We're on the cusp of being able to fit into 128 megs of flash. This brings me to the subject of the kernel. hwpacks besides installing linux-firmware (32 Megs) but also approx 50 Megs in modules. Yet on my beagleboard lsmod notes Module Size Used by asix 12805 0 usbnet 17027 1 asix omap2_mcspi 8441 0 omap_wdt4093 0 hid_apple 4999 0 twl4030_usb 4950 0 twl4030_pwrbutton 1298 0 gpio_keys 6072 0 leds_gpio 2198 0 usbhid 39072 0 hid74787 2 hid_apple,usbhid Clearly we don't need all of these modules and I don't think it's an unreasonable change our policy to build what's needed + some reasonable subset of function that our average user might neeed. I don't know why we're installed the firmware deb, does any of the hardware we're supporting even use that? From the directories where modules are located there is the following size info: 812 ./crypto 7568./net 2456./sound 60 ./arch 28372 ./drivers 172 ./lib 272 ./ubuntu 8316./fs 48032 . Going deeper it's pretty easy to spot low hanging fruit: From fs - Do we need afs, jfs, code, minix, hpfs, xfs, hfs, hfsplus, gfs2, reiserfs... I'm thinking no. From drivers - net and media make about about 1/3rd of the 28 meg in use, I'm sure there's a number of drivers in here that can just be turned off. From sound - ac97, are there arm boards that use that? From net - x25, decnet, appletalk ? So that said, what is the best way to proceed? 1) Is there agreement that for all the kernels we supply that we should change the policy for kernel configs to not default to everything on? (Maybe we should be using the upstream config with minimal modifications?) Pro: everyone benefits from the diet Con: Our kernel would be build slightly different than ubuntu's others: 2) Linaro-media-create shouldn't install linux-firmware_1.47_all.deb ? Do we have any any hardware that needs it? If so could there be a --nano option to not install it? 3) linaro-media-create should have some kind of option (--nano) to clear out apt caches (saves ~40 meg of space) Specifically from the installed image after the hwpack deps are installed get rid of the following: rm -f ./var/lib/apt/lists/*Packages rm -f ./var/lib/apt/lists/*Sources rm -f ./var/lib/apt/lists/*Release rm -f ./var/lib/apt/lists/*Release.gpg rm -f ./var/cache/apt/pkgcache.bin rm -f ./var/cache/apt/srcpkgcache.bin Pro: if you never run apt* you won't mind the cold caches Con: if you're running out of nand and you're going to apt-get upgrade your system, you're probably going to run out of space (Probably a problem to solve in a future cycle) It's important through this exercise for people to speak up about what can and can NOT be safely turned off. Thanks for your time, attention, suggestions and feedback. Regards, Tom ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Wed, 2011-03-09 at 20:30 +0100, Loïc Minier wrote: On Wed, Mar 09, 2011, Guilherme Salgado wrote: My concern is that sfdisk -l returning non-zero may not be a very good indication that we should sleep. It will return non-zero on any error and I expect most errors to not go away after a 30 seconds sleep, in which case we'd be delaying l-m-c's exit unnecessarily. That may not be a big deal, though. Ah I see what you mean, for instance if the MMC is definitely dead and wont ever come back, you'd like to be able to detect that. I don't know what to test for though: we just wrote a blank partition table (parted mklabel msdos), and we're just trying sfdisk -l on it. What test did you have in mind? I didn't have anything in mind; just wanted to know what was the cause of the delay to see if there's anything we could use to identify failure modes which can be resolved with just a sleep. -- Guilherme Salgado https://launchpad.net/~salgado signature.asc Description: This is a digitally signed message part ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[REPORT] 2011-03-10 Infrastructure team weekly report
Hi,
The Infrastructure team weekly report for 2011-03-10 is now available
and can be found at:
https://wiki.linaro.org/Platform/Infrastructure/Status/2011-03-10
The report is also reproduced in full below.
Regards,
Jamie.
--
Linaro Release Manager | Platform Project Manager
--
* Period: (20110303-20110309)
* PM: JamieBennett jamie.benn...@linaro.org
* Past reports : https://wiki.linaro.org/Platform/Infrastructure/Status
* Burndown information :
http://status.linaro.org/linaro-infrastructure.html
* Stakeholder process:
https://wiki.linaro.org/Platform/Infrastructure/CurrentProjects
== Key Points for wider discussion ==
* A 'feature-complete' version of the Android build system front-end to
Jenkins is available at {{{https://android-build.linaro.org/mockup/}}}.
Builds can be done by members of the ~linaro-android-builders Launchpad
team and the actual Jenkins instance can be found at
{{{http://android-build.linaro.org/jenkins}}}. Please take a look and
give comments.
* svammel mass bug filing tool for build failures is progressing. Some
more improvements planned but initial reviews are favorable. Code
reviews are welcome.
== Team Highlights ==
* ec2 investigations continue to find the best solution for the
continuous integration service. An ebs instance either small or large
for the master and include slaves as when needed for builds seems the
most effective.
* Mattias and Deepti now have Panda boards although Deepti's is shared
at the moment.
* Initial patch tracking metrics have been given to management.
* Tracking bugs as work items on non-Ubuntu projects was enabled in the
status.linaro.org code.
* Initial work on a planet instance for Linaro has been undertaken. The
results can be found at
[[http://ec2-50-17-53-200.compute-1.amazonaws.com/]]
== Upcoming Deliverables ==
* linaro-image-tools will be getting a release soon (likely before the
monthly release date to ease the process of getting it in to Ubuntu)
* Final patch metrics for the next member report in two weeks.
== Risks / Issues ==
* '''VERY HIGH IMPACT''': Mattias unable to work productively due to IT
restrictions in ST-E (5 weeks): some progress. Has process now to
request changes, but little response to his requests in more than 4
weeks. Mattias is working from home or over 3G in the meantime.
* '''HIGH IMPACT''': PatchTracking requires deploying Patchwork (4
weeks): Discussion with IS, and it is not expected to take them long to
do once they get to it. They have indicated that they may be able to
start at the end of this week, or in the week after.
* '''HIGH IMPACT''': Gerrit instance needed for Android (4 weeks):
Co-ordination with IS has started. Waiting to hear from them if we can
get it this month, and what we need to do to help with that.
* '''HIGH IMPACT''': Deepti believes she has not been granted travel to
Linaro@UDS (2 weeks): She will attend remotely where possible.
* '''HIGH IMPACT''': A large portion of James' time is taken by project
management at the moment (several weeks): investigations are in progress
on how to move most of this work onto a PM.
* '''MEDIUM IMPACT''': Deepti lacking hardware to work with her Panda
board: Deepti has received the Panda board, but doesn't have a
USB-serial cable for it, so is still unable to use it for much. Working
on tasks that don't require it, but unable to participate in image
testing. (many weeks).
* '''MEDIUM IMPACT''': OurOwnOffspring lacking hardware (many weeks):
x86 for master is ready and waiting, XMs for slaves delivered to IS.
Awaiting setup from IS.
* '''MEDIUM IMPACT''': Want a Jenkins/Hudson instance for Continuous
Integration purposes (many weeks): Discussions with IS, and they will
provide one, but timeframe is unclear at this point. Will host ourselves
until IS can provide. Work on getting an ec2 instance for this has
started, and we should have it running in ec2 by next week.
* '''MEDIUM IMPACT''': Deepti and Avik are sharing one Panda board
meaning some hardware specific work is being blocked (1 week).
== Miscellaneous ==
* Guilherme at PyCon 10-15 March
* James away 21st March
* Deepti on vacation 11th March
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[NOTES] 3/09 Linaro Developer Platform Weekly Status Meeting
Enclosed you'll find a link to the agenda, notes and actions from the Linaro Developer Platforms Weekly Status meeting held on March 9th in #linaro-meeting on irc.freenode.net at 16:00 UTC. https://wiki.linaro.org/Platform/Foundations/2011-03-09 Actions from the meeting where as follows: * wookey_ to send a patch to debian-policy to allow multiarch -dev packages * jcrigby and hrw to figure out how to boot efikasb from an external u-boot so hrw can test the latest tree * jcrigby to check with dmart about progress on porting kprobes to thumb-2 * ppearse to investigate how libtool does ldopen for GObject Introspection work Regards, Tom (tgall_foo) Developer Platforms Team We want great men who, when fortune frowns will not be discouraged. - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
On Tue, Mar 8, 2011 at 10:04 AM, Jonathan Corbet cor...@lwn.net wrote: On Tue, 8 Mar 2011 09:13:59 +0100 Hans Verkuil hverk...@xs4all.nl wrote: All these memory-related modules have the same purpose: make it possible to allocate/reserve large amounts of memory and share it between different subsystems (primarily framebuffer, GPU and V4L). It really shouldn't be that hard to get everyone involved together and settle on a single solution (either based on an existing proposal or create a 'the best of' vendor-neutral solution). There is a memory management summit at the LF Collaboration Summit next month. Perhaps this would be a good topic to raise there? I've added Hugh to the Cc list in case he has any thoughts on the matter - and besides, he doesn't have enough to do...:) It's a good suggestion, Jon, thank you. But I don't see that any of the prime movers in this area have applied to come to LSF/MM this year: except for Kamezawa-san, who is coming (but I expect will be focussing on other issues). And now we're full up. Let me keep it in mind when drawing up the agenda; but I doubt this will be the forum to get such a ball rolling this year. Hugh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Better reviews for the same cost in gcc-linaro
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts We're a bit unique as gcc-linaro started from a mature base, running the testsuite takes days, and the product is so big that bzr takes a long time to work on it. If you have experience in running a master branch or ideas on continious integration please have a read. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Better reviews for the same cost in gcc-linaro
On Wed, Mar 9, 2011 at 2:56 PM, Michael Hope michael.h...@linaro.org wrote: We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts We're a bit unique as gcc-linaro started from a mature base, running the testsuite takes days, and the product is so big that bzr takes a long time to work on it. Hey Michael, which target's are you actively building/testing fo (c,c++, etc?) for reference, i'm just doing c,c++, here's my average's.. xM: build: 14 hours, testsuite: 22 hours.. Panda: build: 9.5 hours, testsuite: 12hours.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Better reviews for the same cost in gcc-linaro
On Thu, 10 Mar 2011 09:56:27 +1300, Michael Hope michael.h...@linaro.org wrote: We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts Hi Michael, One thing that isn't clear to me from that page is why patches can go unreviewed for days. Do you tie the review to the testing somehow? The proposal to have a designated person who will review patches promptly is one that has seen success in other projects. It trades off prompt reviews for more interuptions in someone's time, but it seems like that is often worth doing. Some further questions: * How frequently do problems get through review that are found by the test suite? * How frequently do problems get past the testsuite? * Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 00/12][RFC] Intial Kconfig Fragment Demo
On Wed, Mar 9, 2011 at 11:18 AM, John Stultz john.stu...@linaro.org wrote: On Wed, 2011-03-09 at 10:17 +0200, Amit Kucheria wrote: On Wed, Mar 9, 2011 at 4:32 AM, John Stultz john.stu...@linaro.org wrote: My solution is to have a Kconfig.distro file, which is patched with Distro specific policy config, such as which filesystems should be enabled, networking policy, debug options, or periphrial driver modules that should be enabled. Basically anything that isn't hardware specific (by that I mean, part of the architecture or wired on the board). The Ubuntu configs do something similar. The config generator makes a 3-level config - distro, arch, board. But this is encapsulated under the debian packaging rather than in the kernel source. That is why you probably haven't seen it yet. Look at git://git.linaro.org/ubuntu/linux-linaro-natty.git under debian.linaro/config. Most kernel developers, however, don't really care about creating a .deb package of the kernel to test new code. They'd rather have the config available in the sources. So I agree that we should fix this problem for them. If it turns out that in fixing this problem we fix it for distros too, great! Yea, I am aware of some of the approaches that distros use, usually assembling .config fragments into a larger config at build time. And its in part because each distro has tried to solve the same issue out of the kernel that I'm interested in trying to solve the problem in the kernel source at the Kconfig level. From there, I add in as much of the generic Linaro config policy as I could, utilizing the config files that were used to build the omap3, imx51 and vexpress hardware packs. Since the Linaro config polciy is not unified at this point (in other words, each board has totally different set of generic policy options configured). I added the per target differences into the board kconfig fragments. No, it doesn't. The system they use allows for unified configs. The Ubuntu kernel has unified configs across 3-4 architectures. Huh. Are you sure? Because the configs found in the hwpacks are very different. I'll grant that the build system allows for unified config, but I don't think the Linaro kernels are making much use of it. omap vs vexpress being the best example of really wide differences: o cgroup support o bsd process accounting o xattr support for ext3/ext4 o different preempt models o highres timers no_hz etc.. Yes, the configs in the packaged kernel are not in sync. The reason is mostly historical. The omap config started with a ubuntu kernel config which is indeed unified across arches so it has lots of stuff on that we probably don't need in a linaro kernel. The other configs started as configs from the kernel def configs plus whatever it took to make the config checker happy (things like security issues). We probably would not break may linaro supported platforms if we stripped down the omap config to be more similar to the other SOCs. I thought at one time that this was not a good idea because there was a plan for ubuntu to use the linaro omap kernel. That has not yet happened so at this time having the linaro omap kernel config out of sync with the ubuntu one may not be a problem. The problem is starting a new config for a new board/SoC. The current config system expects a full config for the board dropped into place and then let the tool split it out into distro/arch and board components. If this causes any changes to the distro/arch configs, you know you might have missed some options. I'll have to take a look at this. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Better reviews for the same cost in gcc-linaro
On Thu, Mar 10, 2011 at 10:28 AM, James Westby james.wes...@canonical.com wrote: On Thu, 10 Mar 2011 09:56:27 +1300, Michael Hope michael.h...@linaro.org wrote: We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts Hi Michael, One thing that isn't clear to me from that page is why patches can go unreviewed for days. Do you tie the review to the testing somehow? It's the way things are. Andrew has been doing all of the review and doing it as part of the integration phase. This will change. The proposal to have a designated person who will review patches promptly is one that has seen success in other projects. It trades off prompt reviews for more interuptions in someone's time, but it seems like that is often worth doing. Some further questions: * How frequently do problems get through review that are found by the test suite? Ideally the test suite should have been run before the review and have shown no regressions. That's how upstream does it. GCC is complicated so a review will miss subtle things. * How frequently do problems get past the testsuite? Being pessamistic, say every second patch causes a failure found in the field not found in the testsuite. * Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk? Not a quality release, no, but I have good confidence in the patches in general. It's unlikely that a commit would break trunk. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Better reviews for the same cost in gcc-linaro
On Thu, 10 Mar 2011 11:09:21 +1300, Michael Hope michael.h...@linaro.org wrote: * How frequently do problems get through review that are found by the test suite? Ideally the test suite should have been run before the review and have shown no regressions. That's how upstream does it. GCC is complicated so a review will miss subtle things. Sure, but reviews shouldn't be trying to catch every single problem that may exist. If you don't have an idea of how much benefit test-before-merge has over just review-before-merge then it's going to be hard to estimate the risk of changing that scheme. * How frequently do problems get past the testsuite? Being pessamistic, say every second patch causes a failure found in the field not found in the testsuite. That indicates that getting the code out there for (non-production) use would actually be worthwhile, rather than trying too hard to ensure everything goes through the testsuite. (Unless every patch has 10 problems that are not found in review but found by the testsuite.) * Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk? Not a quality release, no, but I have good confidence in the patches in general. It's unlikely that a commit would break trunk. What sense are you using break here? It sounds like prompt review-integration branch-beta testers | `-test suite-trunk would be best if you don't think that you can have a quality release if you merge-before-test. If you feel that you are equipped to recover from problems found by running the test suite against trunk before doing a release then it may be better to avoid the overhead and merge to trunk after prompt review, and deal with test failures when they happen. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] ARM: omap3: Fix assembler breakage in sleep34xx.S
Assembler in latest binutils needs extra option to enable smc instructions introduced in: ARM: omap3: Remove hand-encoded SMC instructions Signed-off-by: John Rigby john.ri...@linaro.org --- arch/arm/mach-omap2/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 898fffe..1d2d1f6 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -71,7 +71,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 -AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a +AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) ifeq ($(CONFIG_PM_VERBOSE),y) CFLAGS_pm_bus.o+= -DDEBUG -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Better reviews for the same cost in gcc-linaro
On Thu, Mar 10, 2011 at 11:36 AM, James Westby james.wes...@canonical.com wrote: On Thu, 10 Mar 2011 11:09:21 +1300, Michael Hope michael.h...@linaro.org wrote: * How frequently do problems get through review that are found by the test suite? Ideally the test suite should have been run before the review and have shown no regressions. That's how upstream does it. GCC is complicated so a review will miss subtle things. Sure, but reviews shouldn't be trying to catch every single problem that may exist. If you don't have an idea of how much benefit test-before-merge has over just review-before-merge then it's going to be hard to estimate the risk of changing that scheme. We currently have review+build+test before merge. If we checkin directly to trunk then it would be review+merge, then build+test automatically afterwards. * How frequently do problems get past the testsuite? Being pessamistic, say every second patch causes a failure found in the field not found in the testsuite. That indicates that getting the code out there for (non-production) use would actually be worthwhile, rather than trying too hard to ensure everything goes through the testsuite. (Unless every patch has 10 problems that are not found in review but found by the testsuite.) Yip. It's quite stable and bugs are quite rare. A huge testsuite like Ubuntu is a good way of exercising the compiler. * Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk? Not a quality release, no, but I have good confidence in the patches in general. It's unlikely that a commit would break trunk. What sense are you using break here? On second reading, too loosely. I meant 'fail to build', but most developers will want to run the testsuite. If the checkin before them caused a testsuite regression then they may get confused. A timely automatic build would help with that: perhaps notify the previous author of the regression, and give the developer somewhere to easily check the state of their baseline. It sounds like prompt review-integration branch-beta testers | `-test suite-trunk would be best if you don't think that you can have a quality release if you merge-before-test. Yip. The integration branch however may be Ubuntu itself. Matthias is fairly happy cherry-picking things so if these checkins/feature branches are at least reviewed and preferably build+tested then he can be the path to beta testers. This may change when Linaro gets set up to build main. If you feel that you are equipped to recover from problems found by running the test suite against trunk before doing a release then it may be better to avoid the overhead and merge to trunk after prompt review, and deal with test failures when they happen. Agreed. The build+testsuite can happen automatically and probably within two days. -- Michae ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Instructions for building Linaro GCC with crosstool-NG
I've written some short instructions on using crosstool-NG to build Linaro GCC: https://wiki.linaro.org/WorkingGroups/ToolChain/Using/CrosstoolNg Could someone review these for me please? Linaro GCC is already available in a bunch of places including OpenBricks, crosstool-NG, OpenEmbedded, OpenWRT, and (of course) Ubuntu. I hope to write a short page on each so people know where to find our toolchain in the distribution of their choice. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Wed, Mar 09, 2011 at 09:01:33PM +0800, Shawn Guo wrote: On Tue, Mar 08, 2011 at 04:59:18PM +0100, Loïc Minier wrote: On Tue, Mar 08, 2011, Shawn Guo wrote: I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test. 1) Transend 4GB SD 2) SanDisk 2GB SD 3) KingMax MMC Mobile 2GB All above 3 cards passed the test with giving Could list partitions after 0 seconds! 4) SanDisk 4GB SD 5) SanDisk 4GB SD 6) SanDisk 4GB SD 7) SanDisk 4GB SD All above 4 cards failed with giving Giving up after 30 seconds failing to list partitions. The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it. This is really valuable data; SanDisk 4 GB SDs seem to be a trend above! It would be interesting if you could borrow another USB reader for some hours to run the tests on the same SD cards, but a different adapter. Today in office, with another reader and another maverick machine, the result seems consistent. The new thing is those four failing cards sometime ends up with Could list partitions after 2 seconds!, besides the two possible results reported before, 0 second and failed to list. I have to add something here to correct the conclusion about reader's impact. I just got the third reader to play with, and interestingly it can get all of these failing cards give 'Could list partitions after 0 seconds!'. Let's focus one failing card (#4, the very first one) to see the difference that readers make here. Reader #1: SSK Reader #2: PISEN Reader #3: another SSK (golden one) Host machine (office one): Intel(R) Pentium(R) 4 CPU 2.80GHz + Maverick Server === wait_device testing === * On reader #1, consistently fails with 30 seconds timeout * On reader #2, very likely succeeds after 2 seconds (5 out of 6 iterations), (fails with 30 seconds timeout on the 6th iteration) * On reader #3, consistently succeeds after 0 seconds === l-m-c installing with sleep(5) === * On reader #1, fails on '/dev/sdb: No medium found' like below. [...] proc umounted /dev/sdb: No medium found sfdisk: cannot open /dev/sdb read-write Traceback (most recent call last): File /usr/bin/linaro-media-create, line 127, in module args.should_format_rootfs) File /usr/lib/pymodules/python2.6/linaro_media_create/partitions.py, line 71, in setup_partitions board_config, media, HEADS, SECTORS, cylinders) File /usr/lib/pymodules/python2.6/linaro_media_create/partitions.py, line 310, in create_partitions run_sfdisk_commands(sfdisk_cmd, heads, sectors, cylinders, media.path) File /usr/lib/pymodules/python2.6/linaro_media_create/partitions.py, line 288, in run_sfdisk_commands return proc.communicate(%s\n % commands) File /usr/lib/python2.6/subprocess.py, line 691, in communicate return self._communicate(input) File /usr/lib/python2.6/subprocess.py, line 1258, in _communicate self.wait() File /usr/lib/pymodules/python2.6/linaro_media_create/cmd_runner.py, line 66, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process ['sudo', '-E', 'sfdisk', '-D', '-H' * On reader #2, fails on 'mkimage: Write error on /tmp/tmpViO9KL/boot-disc/uImage: Success' as below. [...] This filesystem will be automatically checked every 26 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. 162+1 records in 162+1 records out 166624 bytes (167 kB) copied, 0.0407654 s, 4.1 MB/s mkimage: Write error on /tmp/tmpViO9KL/boot-disc/uImage: Success Traceback (most recent call last): File /usr/bin/linaro-media-create, line 134, in module args.device, args.is_live, args.is_lowmem, args.consoles) File /usr/lib/pymodules/python2.6/linaro_media_create/populate_boot.py, line 57, in populate_boot boot_disk, boot_script, boot_device_or_file) File /usr/lib/pymodules/python2.6/linaro_media_create/boards.py, line 118, in make_boot_files boot_device_or_file) File /usr/lib/pymodules/python2.6/linaro_media_create/boards.py, line 312, in _make_boot_files cls.load_addr, uboot_parts_dir, cls.kernel_suffix, boot_dir) File /usr/lib/pymodules/python2.6/linaro_media_create/boards.py, line 389, in make_uImage 'kernel', load_addr, load_addr, 'Linux', img_data, img) File /usr/lib/pymodules/python2.6/linaro_media_create/boards.py, line 363, in _run_mkimage proc.wait() File /usr/lib/pymodules/python2.6/linaro_media_create/cmd_runner.py, line 66, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process ['sudo', '-E', 'mkimage', '-A', 'arm', '-O', 'linux', '-T', 'kernel', '-C', 'none', '-a', '0x90008000', '-e', '0x90008000', '-n', 'Linux',
[PATCH V4 1/5] arm/dt: add basic mx51 device tree support
Signed-off-by: Jason Liu jason@linaro.org
Signed-off-by: Jason Liu r64...@freescale.com
---
arch/arm/mach-mx5/Kconfig |8
arch/arm/mach-mx5/Makefile |1 +
arch/arm/mach-mx5/board-dt.c| 65 +++
arch/arm/mach-mx5/clock-mx51-mx53.c | 43 -
arch/arm/plat-mxc/include/mach/common.h |1 +
5 files changed, 117 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index de4fa99..6438f87 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -47,6 +47,14 @@ config MACH_MX51_BABBAGE
u-boot. This includes specific configurations for the board and its
peripherals.
+config MACH_MX51_DT
+ bool Generic MX51 board (FDT support)
+ select USE_OF
+ select SOC_IMX51
+ help
+Support for generic Freescale i.MX51 boards using Flattened Device
+Tree.
+
config MACH_MX51_3DS
bool Support MX51PDK (3DS)
select SOC_IMX51
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 0d43be9..540697e 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_MACH_EUKREA_CPUIMX51SD) += board-cpuimx51sd.o
obj-$(CONFIG_MACH_EUKREA_MBIMXSD51_BASEBOARD) += eukrea_mbimxsd-baseboard.o
obj-$(CONFIG_MACH_MX51_EFIKAMX) += board-mx51_efikamx.o
obj-$(CONFIG_MACH_MX50_RDP) += board-mx50_rdp.o
+obj-$(CONFIG_MACH_MX51_DT) += board-dt.o
diff --git a/arch/arm/mach-mx5/board-dt.c b/arch/arm/mach-mx5/board-dt.c
new file mode 100644
index 000..19c60a4
--- /dev/null
+++ b/arch/arm/mach-mx5/board-dt.c
@@ -0,0 +1,65 @@
+/*
+ * Copyright 2011 Linaro Ltd.
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/err.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#include linux/of_platform.h
+#include linux/of_fdt.h
+
+#include mach/common.h
+#include mach/hardware.h
+#include mach/imx-uart.h
+#include mach/iomux-mx51.h
+
+#include asm/irq.h
+#include asm/setup.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/time.h
+
+#include devices.h
+
+static struct of_device_id mx51_dt_match_table[] __initdata = {
+ { .compatible = simple-bus, },
+ {}
+};
+
+static void __init mx51_dt_board_init(void)
+{
+ of_platform_bus_probe(NULL, mx51_dt_match_table, NULL);
+}
+
+static void __init mx51_dt_timer_init(void)
+{
+ mx51_clocks_init(32768, 2400, 22579200, 0);
+ mx5_clk_dt_init();
+}
+
+static struct sys_timer mxc_timer = {
+ .init = mx51_dt_timer_init,
+};
+
+static const char *mx51_dt_board_compat[] = {
+ fsl,mx51-babbage,
+ NULL
+};
+
+DT_MACHINE_START(MX51_DT, Freescale MX51 (Flattened Device Tree))
+ .boot_params = PHYS_OFFSET + 0x100,
+ .map_io = mx51_map_io,
+ .init_irq = mx51_init_irq,
+ .init_machine = mx51_dt_board_init,
+ .dt_compat= mx51_dt_board_compat,
+ .timer= mxc_timer,
+MACHINE_END
diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c
b/arch/arm/mach-mx5/clock-mx51-mx53.c
index 0a19e75..dedb7f9 100644
--- a/arch/arm/mach-mx5/clock-mx51-mx53.c
+++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
@@ -15,13 +15,19 @@
#include linux/clk.h
#include linux/io.h
#include linux/clkdev.h
-
+#include linux/err.h
#include asm/div64.h
#include mach/hardware.h
#include mach/common.h
#include mach/clock.h
+#ifdef CONFIG_OF
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_clk.h
+#endif /* CONFIG_OF */
+
#include crm_regs.h
/* External clock values passed-in by the board code */
@@ -1432,3 +1438,38 @@ int __init mx53_clocks_init(unsigned long ckil, unsigned
long osc,
MX53_INT_GPT);
return 0;
}
+
+#ifdef CONFIG_OF
+static struct clk *mx5_dt_clk_get(struct device_node *np,
+ const char *output_id, void *data)
+{
+ return data;
+}
+
+static __init void mx5_dt_scan_clks(void)
+{
+ struct device_node *node;
+ struct clk *clk;
+ const char *id;
+ int rc;
+
+ for_each_compatible_node(node, NULL, clock) {
+ id = of_get_property(node, clock-outputs, NULL);
+ if (!id)
+ continue;
+
+ clk = clk_get_sys(id, NULL);
+ if (IS_ERR(clk))
+ continue;
+
+ rc = of_clk_add_provider(node, mx5_dt_clk_get, clk);
+ if (rc)
+ pr_err(error adding fixed clk %s\n, node-name);
+ }
+}
+
+void __init mx5_clk_dt_init(void)
+{
+
[PATCH V4 4/5] net/fec: check id_entry pointer before using it
The id_entry will possibly be NULL, So, need check
id_entry and make sure it not NULL before using it.
Signed-off-by: Jason Liu jason@linaro.org
Signed-off-by: Jason Liu r64...@freescale.com
---
drivers/net/fec.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 2a71373..02cdd71 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -293,7 +293,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device
*dev)
* the system that it's running on. As the result, driver has to
* swap every frame going to and coming from the controller.
*/
- if (id_entry-driver_data FEC_QUIRK_SWAP_FRAME)
+ if (id_entry id_entry-driver_data FEC_QUIRK_SWAP_FRAME)
swap_buffer(bufaddr, skb-len);
/* Save skb pointer */
@@ -529,7 +529,7 @@ fec_enet_rx(struct net_device *dev)
dma_unmap_single(NULL, bdp-cbd_bufaddr, bdp-cbd_datlen,
DMA_FROM_DEVICE);
- if (id_entry-driver_data FEC_QUIRK_SWAP_FRAME)
+ if (id_entry id_entry-driver_data FEC_QUIRK_SWAP_FRAME)
swap_buffer(data, pkt_len);
/* This does 16 byte alignment, exactly what we need.
@@ -808,7 +808,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* mdio interface in board design, and need to be configured by
* fec0 mii_bus.
*/
- if ((id_entry-driver_data FEC_QUIRK_ENET_MAC) pdev-id) {
+ if (id_entry (id_entry-driver_data FEC_QUIRK_ENET_MAC)
pdev-id) {
/* fec1 uses fec0 mii_bus */
fep-mii_bus = fec0_mii_bus;
return 0;
@@ -851,7 +851,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
goto err_out_free_mdio_irq;
/* save fec0 mii_bus */
- if (id_entry-driver_data FEC_QUIRK_ENET_MAC)
+ if (id_entry id_entry-driver_data FEC_QUIRK_ENET_MAC)
fec0_mii_bus = fep-mii_bus;
return 0;
@@ -1238,7 +1238,7 @@ fec_restart(struct net_device *dev, int duplex)
* enet-mac reset will reset mac address registers too,
* so need to reconfigure it.
*/
- if (id_entry-driver_data FEC_QUIRK_ENET_MAC) {
+ if (id_entry id_entry-driver_data FEC_QUIRK_ENET_MAC) {
memcpy(temp_mac, dev-dev_addr, ETH_ALEN);
writel(cpu_to_be32(temp_mac[0]), fep-hwp + FEC_ADDR_LOW);
writel(cpu_to_be32(temp_mac[1]), fep-hwp + FEC_ADDR_HIGH);
@@ -1294,7 +1294,7 @@ fec_restart(struct net_device *dev, int duplex)
* The phy interface and speed need to get configured
* differently on enet-mac.
*/
- if (id_entry-driver_data FEC_QUIRK_ENET_MAC) {
+ if (id_entry id_entry-driver_data FEC_QUIRK_ENET_MAC) {
val = readl(fep-hwp + FEC_R_CNTRL);
/* MII or RMII */
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V4 5/5] net/fec: add device tree matching support
Signed-off-by: Jason Liu jason@linaro.org
Signed-off-by: Jason Liu r64...@freescale.com
---
drivers/net/fec.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 02cdd71..fcb9768 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -45,6 +45,9 @@
#include linux/phy.h
#include linux/fec.h
+#include linux/of.h
+#include linux/of_address.h
+
#include asm/cacheflush.h
#ifndef CONFIG_ARM
@@ -1523,6 +1526,13 @@ static const struct dev_pm_ops fec_pm_ops = {
};
#endif
+#ifdef CONFIG_OF
+static struct of_device_id fec_matches[] = {
+ { .compatible = fsl,imx-fec },
+ {},
+};
+#endif
+
static struct platform_driver fec_driver = {
.driver = {
.name = DRIVER_NAME,
@@ -1530,6 +1540,9 @@ static struct platform_driver fec_driver = {
#ifdef CONFIG_PM
.pm = fec_pm_ops,
#endif
+#ifdef CONFIG_OF
+ .of_match_table = fec_matches,
+#endif
},
.id_table = fec_devtype,
.probe = fec_probe,
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] ARM: Samsung: Basic CPUIDLE Support
This patch supports cpuidle framework for samsung S5PV310. Currently,
Only one idle state is possible to use, but more idle states can
be added followed by this patch.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
Rebasing the patch for linaro 2.6.38 kernel. This patch adds basic cpuidle
infrastructure and fixes the launchpad bug(bug id: 723543). This patch is
under review in samsung mailing list.
http://www.spinics.net/lists/linux-samsung-soc/msg04268.html
arch/arm/mach-s5pv310/Makefile |1 +
arch/arm/mach-s5pv310/cpuidle.c | 87 +++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/cpuidle.c
diff --git a/arch/arm/mach-s5pv310/Makefile b/arch/arm/mach-s5pv310/Makefile
index 036fb38..c5db0fa 100644
--- a/arch/arm/mach-s5pv310/Makefile
+++ b/arch/arm/mach-s5pv310/Makefile
@@ -15,6 +15,7 @@ obj- :=
obj-$(CONFIG_CPU_S5PV310) += cpu.o init.o clock.o irq-combiner.o
obj-$(CONFIG_CPU_S5PV310) += setup-i2c0.o time.o gpiolib.o irq-eint.o
dma.o
obj-$(CONFIG_CPU_FREQ) += cpufreq.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
obj-$(CONFIG_LOCAL_TIMERS) += localtimer.o
diff --git a/arch/arm/mach-s5pv310/cpuidle.c b/arch/arm/mach-s5pv310/cpuidle.c
new file mode 100644
index 000..f35b537
--- /dev/null
+++ b/arch/arm/mach-s5pv310/cpuidle.c
@@ -0,0 +1,87 @@
+/* linux/arch/arm/mach-s5pv310/cpuidle.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/cpuidle.h
+#include linux/io.h
+
+#include asm/proc-fns.h
+
+static int s5pv310_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state);
+
+static struct cpuidle_state s5pv310_cpuidle_set[] = {
+ [0] = {
+ .enter = s5pv310_enter_idle,
+ .exit_latency = 1,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = IDLE,
+ .desc = ARM clock gating(WFI),
+ },
+};
+
+static DEFINE_PER_CPU(struct cpuidle_device, s5pv310_cpuidle_device);
+
+static struct cpuidle_driver s5pv310_idle_driver = {
+ .name = s5pv310_idle,
+ .owner = THIS_MODULE,
+};
+
+static int s5pv310_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct timeval before, after;
+ int idle_time;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ cpu_do_idle();
+
+ do_gettimeofday(after);
+ local_irq_enable();
+ idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
+ (after.tv_usec - before.tv_usec);
+
+ return idle_time;
+}
+
+static int __init s5pv310_init_cpuidle(void)
+{
+ int i, max_cpuidle_state, cpu_id;
+ struct cpuidle_device *device;
+
+ cpuidle_register_driver(s5pv310_idle_driver);
+
+ for_each_cpu(cpu_id, cpu_online_mask) {
+ device = per_cpu(s5pv310_cpuidle_device, cpu_id);
+ device-cpu = cpu_id;
+
+ device-state_count = (sizeof(s5pv310_cpuidle_set) /
+ sizeof(struct cpuidle_state));
+
+ max_cpuidle_state = device-state_count;
+
+ for (i = 0; i max_cpuidle_state; i++) {
+ memcpy(device-states[i], s5pv310_cpuidle_set[i],
+ sizeof(struct cpuidle_state));
+ }
+
+ if (cpuidle_register_device(device)) {
+ printk(KERN_ERR CPUidle register device failed\n,);
+ return -EIO;
+ }
+ }
+ return 0;
+}
+
+device_initcall(s5pv310_init_cpuidle);
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Fw: [PATCH][RFC] CC_OPTIMIZE_FOR_SIZE should default to N
On Tue, Mar 08, 2011 at 09:07:10AM +1300, Michael Hope wrote: On Tue, Mar 8, 2011 at 8:47 AM, Tom Gall tom.g...@linaro.org wrote: To quote the GCC manual: -Os Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size. -Os disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version That said (and unless there's other undocumented differences), it would seem to take some expertise to comment on the trade off between memory efforts (cache misses, TLB etc) vs instructional effects by having these optimizations off. I am certainly not that expert but I suspect given the memory bus speeds that typical arm hardware has, we'd want -Os over -O2. I don't know about the kernel, but here's the difference for some other programs: * pybench: -Os is 24 % slower than -O2 * skia: -Os is 18 % slower than -O2 * CoreMark is similar (I've lost the numbers) ...so you're going to need a large bandwidth saving to beat the core speed improvement of -O2. So no objections to Jesper Juhl's proposal to make -Os not be default, then? Thanx, Paul ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Instructions for building Linaro GCC with crosstool-NG
Michael == Michael Hope michael.h...@linaro.org writes: Hi, Michael Linaro GCC is already available in a bunch of places including Michael OpenBricks, crosstool-NG, OpenEmbedded, OpenWRT, and (of Michael course) Ubuntu. I hope to write a short page on each so Michael people know where to find our toolchain in the distribution of Michael their choice. Buildroot (can) use crosstool-ng as its toolchain backend. We're currently using ct-ng 1.10, but once I sync with Yann again, we'll have Linaro support as well. -- Bye, Peter Korsgaard ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
