[PATCH] mmc: mmc_test: add wait_busy to the async check_result
add missing mmc_test_wait_busy() to the check_result_async(). Host drivers
may fail it not waiting for busy state to go away before starting
the next transaction.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/card/mmc_test.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 5325049..ea8e7b1 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -715,13 +715,14 @@ static int mmc_test_check_result(struct mmc_test_card
*test,
return ret;
}
-
static int mmc_test_check_result_async(struct mmc_card *card,
struct mmc_async_req *areq)
{
struct mmc_test_async_req *test_async =
container_of(areq, struct mmc_test_async_req, areq);
+ mmc_test_wait_busy(test_async-test);
+
return mmc_test_check_result(test_async-test, areq-mrq);
}
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [powerdebug] patches for the segmentation fault error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/27/2011 09:36 AM, Milo (Woogyom) Kim wrote: Hi, Daniel I found some segmentation fault in the powerdebug. If there is no clock information, then windata[win].rowdata is null. (If clock_display() returns -1, then display_set_row_data() is not called) In this case the seg fault error occurs when display_get_row_data() is called. Thanks Milo for reporting the problem. I opened a bug in launchpad for this: https://bugs.launchpad.net/linaro-powerdebug/+bug/802387 Your patches are fixing the problem but I think that does not fix the root problem which is we are setting the display ops on the clocks. At the first glance, I think we should not call display_register in the clock_init function if we are not able to access debugfs. The same should apply to all init function for the different subsystems. (cc'ed linaro-dev) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOCD4vAAoJEAKBbMCpUGYAvW4IALXI8nNyrtiej97/9gjFBhZT cfHZgAgY5f4J+GoCyxX2tyCfbqkHgDGaJDvAWkWxMjBLQiVpnjchOG96aj+o5qud YQ3vFXuLKmXWyAjxhxuXfOKyjhvHf6QcKLXWS7OMBoxfozYJ0EwEvSjfGVL2sF3e rurZVZYU47Ms8jVq/MzaEyi1GZiE5D6ZhjfuSc9XhJ70+NORaVcgChOE3E2XGh5O DfKjFHfr/nsjVGXPp0vTdlHH4ZgecDCkuorK8a9Bi0xX7ijRVUUVgjepuK/Fflqo 33/I995r2utVK+x/FgcyNBi28qhNieeVIBcVdZHEFKGPCiGFdbGkqz2JDagJxnc= =99OZ -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[powerdebug] fix segfault when no clock is available
When there is no clock available, we even register the display ops.
The 'enter' callbakc is set but not data is available int the row
private data which leads to a segfaults.
This patch fix this problem by not registering the ops if the pm
subsystem was not correctly initialized.
In the meantime, we have to erase the window when we are switching
from one window to another. We can say it is the default display
callback.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reported-by: Milo (Woogyom) Kim woogyom@gmail.com
---
clocks.c|8
display.c |5 -
regulator.c |8
sensor.c|8
4 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/clocks.c b/clocks.c
index 0bd0a0e..20a245c 100644
--- a/clocks.c
+++ b/clocks.c
@@ -405,9 +405,6 @@ int clock_init(void)
{
char clk_dir_path[PATH_MAX];
- if (display_register(CLOCK, clock_ops))
- return -1;
-
if (locate_debugfs(clk_dir_path))
return -1;
@@ -420,5 +417,8 @@ int clock_init(void)
if (!clock_tree)
return -1;
- return fill_clock_tree();
+ if (fill_clock_tree())
+ return -1;
+
+ return display_register(CLOCK, clock_ops);
}
diff --git a/display.c b/display.c
index 0cfbf94..ebc4de6 100644
--- a/display.c
+++ b/display.c
@@ -120,7 +120,10 @@ static int display_refresh(int win, bool read)
if (windata[win].ops windata[win].ops-display)
return windata[win].ops-display(read);
- return 0;
+ if (werase(main_win))
+ return -1;
+
+ return wrefresh(main_win);
}
int display_refresh_pad(int win)
diff --git a/regulator.c b/regulator.c
index 849f906..e9b01bb 100644
--- a/regulator.c
+++ b/regulator.c
@@ -236,12 +236,12 @@ static struct display_ops regulator_ops = {
int regulator_init(void)
{
- if (display_register(REGULATOR, regulator_ops))
- return -1;
-
reg_tree = tree_load(SYSFS_REGULATOR, regulator_filter_cb);
if (!reg_tree)
return -1;
- return fill_regulator_tree();
+ if (fill_regulator_tree())
+ return -1;
+
+ return display_register(REGULATOR, regulator_ops);
}
diff --git a/sensor.c b/sensor.c
index d63510e..e172f88 100644
--- a/sensor.c
+++ b/sensor.c
@@ -271,12 +271,12 @@ static struct display_ops sensor_ops = {
int sensor_init(void)
{
- if (display_register(SENSOR, sensor_ops))
- return -1;
-
sensor_tree = tree_load(SYSFS_SENSOR, sensor_filter_cb);
if (!sensor_tree)
return -1;
- return fill_sensor_tree();
+ if (fill_sensor_tree())
+ return -1;
+
+ return display_register(SENSOR, sensor_ops);
}
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/2] ORIGEN Board Support
Adds support for ORIGEN board with MMC Booting. Chander Kashyap (2): ARMV7: Add support for Samsung ORIGEN board ORIGEN: Add MMC SPL support MAINTAINERS |1 + board/samsung/origen/Makefile | 46 ++ board/samsung/origen/lowlevel_init.S | 468 + board/samsung/origen/mem_setup.S | 392 + board/samsung/origen/origen.c | 103 + boards.cfg|1 + include/configs/origen.h | 167 mmc_spl/board/samsung/origen/Makefile | 105 + mmc_spl/board/samsung/origen/mmc_boot.c | 75 mmc_spl/board/samsung/origen/tools/mkv310_image.c | 139 ++ mmc_spl/board/samsung/origen/u-boot.lds | 86 11 files changed, 1583 insertions(+), 0 deletions(-) create mode 100644 board/samsung/origen/Makefile create mode 100644 board/samsung/origen/lowlevel_init.S create mode 100644 board/samsung/origen/mem_setup.S create mode 100644 board/samsung/origen/origen.c create mode 100644 include/configs/origen.h create mode 100644 mmc_spl/board/samsung/origen/Makefile create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] ORIGEN: Add MMC SPL support
Adds mmc boot support.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
mmc_spl/board/samsung/origen/Makefile | 105
mmc_spl/board/samsung/origen/mmc_boot.c | 75 +++
mmc_spl/board/samsung/origen/tools/mkv310_image.c | 139 +
mmc_spl/board/samsung/origen/u-boot.lds | 86 +
4 files changed, 405 insertions(+), 0 deletions(-)
create mode 100644 mmc_spl/board/samsung/origen/Makefile
create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c
create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c
create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds
diff --git a/mmc_spl/board/samsung/origen/Makefile
b/mmc_spl/board/samsung/origen/Makefile
new file mode 100644
index 000..7b62684
--- /dev/null
+++ b/mmc_spl/board/samsung/origen/Makefile
@@ -0,0 +1,105 @@
+#
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, s...@denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, l...@denx.de
+#
+# (C) Copyright 2011
+# Chander Kashyap, Samsung Electronics, k.chan...@samsung.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+CONFIG_MMC_SPL = y
+
+include $(TOPDIR)/config.mk
+
+LDSCRIPT= $(TOPDIR)/mmc_spl/board/$(BOARDDIR)/u-boot.lds
+LDFLAGS= -Bstatic -T $(mmcobj)u-boot.lds -Ttext
$(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+AFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_PRELOADER
+
+SOBJS = start.o mem_setup.o lowlevel_init.o
+COBJS = mmc_boot.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
+__OBJS := $(SOBJS) $(COBJS)
+LNDIR := $(OBJTREE)/mmc_spl/board/$(BOARDDIR)
+
+mmcobj := $(OBJTREE)/mmc_spl/
+
+
+MKV310_MMC_SPL_EXEC = mkv310_mmc_spl_exec
+MMC_SPL_BIN = u-boot-mmc-spl.bin
+
+ALL = $(mmcobj)u-boot-spl $(mmcobj)u-boot-spl.bin $(mmcobj)$(MMC_SPL_BIN)
+
+all:$(obj).depend $(ALL)
+
+$(mmcobj)$(MMC_SPL_BIN): $(mmcobj)u-boot-spl.bin tools/$(MKV310_MMC_SPL_EXEC)
+ ./tools/$(MKV310_MMC_SPL_EXEC) $(mmcobj)u-boot-spl.bin
$(mmcobj)$(MMC_SPL_BIN)
+ rm -f tools/$(MKV310_MMC_SPL_EXEC)
+
+tools/$(MKV310_MMC_SPL_EXEC): tools/mkv310_image.c
+ $(HOSTCC) tools/mkv310_image.c -o tools/$(MKV310_MMC_SPL_EXEC)
+
+$(mmcobj)u-boot-spl.bin: $(mmcobj)u-boot-spl
+ $(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
+
+$(mmcobj)u-boot-spl: $(OBJS) $(mmcobj)u-boot.lds
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(__OBJS) \
+ -Map $(mmcobj)u-boot-spl.map \
+ -o $(mmcobj)u-boot-spl
+
+$(mmcobj)u-boot.lds: $(LDSCRIPT)
+ $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $^ $@
+
+# create symbolic links for common files
+
+# from cpu directory
+start.S:
+ @rm -f $@
+ @ln -s $(TOPDIR)/arch/arm/cpu/armv7/start.S $@
+
+# from board directory
+mem_setup.S:
+ @rm -f $@
+ @ln -s $(TOPDIR)/board/samsung/origen/mem_setup.S $@
+
+lowlevel_init.S:
+ @rm -f $@
+ @ln -s $(TOPDIR)/board/samsung/origen/lowlevel_init.S $@
+
+#
+
+$(obj)%.o: %.S
+ $(CC) $(AFLAGS) -c -o $@ $
+
+$(obj)%.o: %.c
+ $(CC) $(CFLAGS) -c -o $@ $
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/mmc_spl/board/samsung/origen/mmc_boot.c
b/mmc_spl/board/samsung/origen/mmc_boot.c
new file mode 100644
index 000..459d27d
--- /dev/null
+++ b/mmc_spl/board/samsung/origen/mmc_boot.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
[PATCH 1/2] ARMV7: Add support for Samsung ORIGEN board
Origen board is based upon S5PV310 SoC which is similiar to
S5PC210 SoC.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
MAINTAINERS |1 +
board/samsung/origen/Makefile| 46
board/samsung/origen/lowlevel_init.S | 468 ++
board/samsung/origen/mem_setup.S | 392
board/samsung/origen/origen.c| 103
boards.cfg |1 +
include/configs/origen.h | 167
7 files changed, 1178 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/origen/Makefile
create mode 100644 board/samsung/origen/lowlevel_init.S
create mode 100644 board/samsung/origen/mem_setup.S
create mode 100644 board/samsung/origen/origen.c
create mode 100644 include/configs/origen.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 30c327b..c233f82 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -707,6 +707,7 @@ Minkyu Kang mk7.k...@samsung.com
Chander Kashyap k.chan...@samsung.com
SMDKV310ARM ARMV7 (S5PC210 SoC)
+ origen ARM ARMV7 (S5PC210 SoC)
Frederik Kriewitz frede...@kriewitz.eu
diff --git a/board/samsung/origen/Makefile b/board/samsung/origen/Makefile
new file mode 100644
index 000..65eff91
--- /dev/null
+++ b/board/samsung/origen/Makefile
@@ -0,0 +1,46 @@
+#
+# Copyright (C) 2011 Samsung Electronics
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+SOBJS := mem_setup.o
+SOBJS += lowlevel_init.o
+COBJS += origen.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
+
+all:$(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/origen/lowlevel_init.S
b/board/samsung/origen/lowlevel_init.S
new file mode 100644
index 000..cbb3c45
--- /dev/null
+++ b/board/samsung/origen/lowlevel_init.S
@@ -0,0 +1,468 @@
+/*
+ * Lowlevel setup for ORIGEN board based on S5PV310
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include config.h
+#include version.h
+#include asm/arch/cpu.h
+
+/*
+ * Register usages:
+ *
+ * r5 has zero always
+ * r7 has GPIO part1 base 0x1140
+ * r6 has GPIO part2 base 0x1100
+ */
+
+#define MEM_DLLl_ON
+
+_TEXT_BASE:
+ .word CONFIG_SYS_TEXT_BASE
+
+ .globl lowlevel_init
+lowlevel_init:
+ push{lr}
+
+ /* r5 has always zero */
+ mov r5, #0
+ ldr r7, =S5PC210_GPIO_PART1_BASE
+ ldr r6, =S5PC210_GPIO_PART2_BASE
+
+ /* check reset status */
+ ldr r0, =(S5PC210_POWER_BASE + 0x804) @ INFORM1
+ ldr r1, [r0]
+
+ /* AFTR wakeup reset */
+ ldr r2, =S5P_CHECK_DIDLE
+ cmp r1, r2
+ beq exit_wakeup
+
+ /* Sleep wakeup reset */
+ ldr r2, =S5P_CHECK_SLEEP
+ cmp r1, r2
+ beq wakeup_reset
+
+ /*
+* If U-boot is already running in ram, no need to relocate U-Boot.
+* Memory controller must be configured before relocating U-Boot
+* in ram.
+*/
+
Announcement:Linaro Android 2.3.4
Hi, Linaro Android has now moved up to 2.3.4 and all of our patches on the linaro_android_2.3.3 branches have been rebased. The official builds (https://android-build.linaro.org/index) are now based on the linaro_android_2.3.4 branch of the manifest. Please rebase any dev_branches you have to 2.3.4. The linaro_android_2.3.3 branch will no longer be supported. Regards Patrik ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Customization of Gerrit for Android
hi, great news. I think we should use a different hostname for gerrit. like review.android.linaro.org. With that we have the option to make a dedicated android git host using the android.git.l.o name eventually. Will check with android team what hostname to use exactly and let you know. On Jun 24, 2011 10:05 PM, James Westby james.wes...@linaro.org wrote: On Mon, 13 Jun 2011 20:27:34 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: James, Thanks for jumping on this. The need for Gerrit grows by the day. The first thing I'd want to do would be to log in using my openid and upload my ssh key to it. This should now be possible. Everyone can now go to android.git.linaro.org and login by entering your LP profile URL, e.g. https://launchpad.net/~james-w (the form there is hardcoded to display those options which is unfortunate.) You should then be able to add your ssh key. The ssh server runs on port 29418 for your testing. The next two steps I believe is something that you can do so I will leave it up to you. Let me know if there are other things that need configuration in Gerrit for these to proceed. Thanks, James Second, I'd want to sync the Android-LEB and push a test change. Third, I'd want to take the test change through the Gerrit lifecycle. From there I'd want to hook up auto-merging and per-change build validation. -Zach On 13 June 2011 19:34, James Westby james.wes...@linaro.org wrote: Hi Zach, We have a request in the queue to set up Gerrit for the Android team, and I know it's something that you consider very important. We haven't yet talked specifics of the configuration of Gerrit, and so I don't yet have a solid idea of what work there is for the Infrastructure team there. I'd like to rectify that and create an implementation plan for the first steps to where you want to go. To that end, if we had a vanilla Gerrit instance up and running tomorrow, what would be the first things that you would want to do to it before it would be useful to you? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 00/11] mmc: use nonblock mmc requests to minimize latency
On 24 June 2011 10:58, Per Forlin per.for...@linaro.org wrote: On 23 June 2011 15:37, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jun 21, 2011 at 11:26:27AM +0200, Per Forlin wrote: Here are the results. It looks like this patch is either a no-op or slightly worse. As people have been telling me that dsb is rather expensive, and this patch results in less dsbs, I'm finding these results hard to believe. It seems to be saying that dsb is an effective no-op on your platform. The result of your patch depends on the number of sg-elements. With your patch there is only on DSB per list instead of element I can write a test to measure performance per number of sg-element in the sg-list. Fixed transfer size but vary the number of sg-elements in the list. This test may give a better understanding of the affect. I have seen performance gain if using __raw_write instead of writel. Writel test includes both the cost of DSB and the outer_sync, where outer_sync is more expensive one I presume. So either people are wrong about dsb being expensive, the patch is wrong, or there's something wrong with these results/test method. You do have an error in the ported patch, as that hasn't updated the v7 cache cleaning code to remove the dsb() there, but that would only affect the write tests. I will fix that mistake diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index d32f02b..3fb51c5 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -228,7 +228,6 @@ ENTRY(v7_flush_kern_dcache_area) add r0, r0, r2 cmp r0, r1 blo 1b - dsb mov pc, lr ENDPROC(v7_flush_kern_dcache_area) I'll come back with new numbers on Monday. I have extended the test to measure bandwidth for various various length of the sg list. mmc_test without DSB patch: mmc0: Test case 37. Write performance with blocking req 4k to 4MB... mmc0: Transfer of 32768 x 8 sectors (32768 x 4 KiB) took 18.298817895 seconds (7334 kB/s, 7162 KiB/s, 1790.71 IOPS, sg_len 1) mmc0: Transfer of 16384 x 16 sectors (16384 x 8 KiB) took 11.046417371 seconds (12150 kB/s, 11865 KiB/s, 1483.19 IOPS, sg_len 1) mmc0: Transfer of 8192 x 32 sectors (8192 x 16 KiB) took 8.700345332 seconds (15426 kB/s, 15065 KiB/s, 941.57 IOPS, sg_len 1) mmc0: Transfer of 4096 x 64 sectors (4096 x 32 KiB) took 7.428314416 seconds (18068 kB/s, 17644 KiB/s, 551.40 IOPS, sg_len 1) mmc0: Transfer of 2048 x 128 sectors (2048 x 64 KiB) took 6.843811190 seconds (19611 kB/s, 19151 KiB/s, 299.24 IOPS, sg_len 1) mmc0: Transfer of 1024 x 256 sectors (1024 x 128 KiB) took 6.548462043 seconds (20496 kB/s, 20015 KiB/s, 156.37 IOPS, sg_len 1) mmc0: Transfer of 512 x 512 sectors (512 x 256 KiB) took 6.392456168 seconds (20996 kB/s, 20504 KiB/s, 80.09 IOPS, sg_len 1) mmc0: Transfer of 256 x 1024 sectors (256 x 512 KiB) took 6.278533955 seconds (21377 kB/s, 20876 KiB/s, 40.77 IOPS, sg_len 1) mmc0: Transfer of 128 x 2048 sectors (128 x 1024 KiB) took 6.007019613 seconds (22343 kB/s, 21819 KiB/s, 21.30 IOPS, sg_len 1) mmc0: Transfer of 32 x 8192 sectors (32 x 4096 KiB) took 5.975690092 seconds (22460 kB/s, 21934 KiB/s, 5.35 IOPS, sg_len 1) mmc0: Result: OK mmc0: Tests completed. mmc0: Starting tests of card mmc0:80ca... mmc0: Test case 38. Write performance with non-blocking req 4k to 4MB... mmc0: Transfer of 32768 x 8 sectors (32768 x 4 KiB) took 18.006849673 seconds (7453 kB/s, 7279 KiB/s, 1819.75 IOPS, sg_len 1) mmc0: Transfer of 16384 x 16 sectors (16384 x 8 KiB) took 10.744232260 seconds (12492 kB/s, 12199 KiB/s, 1524.91 IOPS, sg_len 1) mmc0: Transfer of 8192 x 32 sectors (8192 x 16 KiB) took 8.378324787 seconds (16019 kB/s, 15644 KiB/s, 977.76 IOPS, sg_len 1) mmc0: Transfer of 4096 x 64 sectors (4096 x 32 KiB) took 7.120544379 seconds (18849 kB/s, 18407 KiB/s, 575.23 IOPS, sg_len 1) mmc0: Transfer of 2048 x 128 sectors (2048 x 64 KiB) took 6.551513699 seconds (20486 kB/s, 20006 KiB/s, 312.59 IOPS, sg_len 1) mmc0: Transfer of 1024 x 256 sectors (1024 x 128 KiB) took 6.252501827 seconds (21466 kB/s, 20963 KiB/s, 163.77 IOPS, sg_len 1) mmc0: Transfer of 512 x 512 sectors (512 x 256 KiB) took 6.102325404 seconds (21994 kB/s, 21479 KiB/s, 83.90 IOPS, sg_len 1) mmc0: Transfer of 256 x 1024 sectors (256 x 512 KiB) took 5.978148815 seconds (22451 kB/s, 21925 KiB/s, 42.82 IOPS, sg_len 1) mmc0: Transfer of 128 x 2048 sectors (128 x 1024 KiB) took 5.873932398 seconds (22849 kB/s, 22314 KiB/s, 21.79 IOPS, sg_len 1) mmc0: Transfer of 32 x 8192 sectors (32 x 4096 KiB) took 5.874753979 seconds (22846 kB/s, 22311 KiB/s, 5.44 IOPS, sg_len 1) mmc0: Result: OK mmc0: Tests completed. mmc0: Starting tests of card mmc0:80ca... mmc0: Test case 39. Read performance with blocking req 4k to 4MB... mmc0: Transfer of 32768 x 8 sectors (32768 x 4 KiB) took 20.897765402 seconds (6422 kB/s, 6272 KiB/s, 1568.01 IOPS, sg_len 1) mmc0: Transfer of 16384 x 16 sectors (16384 x 8 KiB) took 12.921478271 seconds (10387 kB/s, 10143
[Patch 5/11] Regulator: DA9052 regulator support v1
The DA9052 PMIC has below featured regulators:-
4 DVS Buck converters 0.5V - 3.6V upto 1Amp.
10 Programmable LDO's High PSSR, 1% accuracy.
This patch support all the DA9052 regulators. The output voltages are
fully programmable via I2C or SPI interface. The platform data with
regulation constraints is passed down from the board to the regulator.
Signed-off-by: David Dajun Chen dc...@diasemi.com
Signed-off-by: Ashish Jangam ashish.jan...@kpitcummins.com
CC: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/regulator/Kconfig|7 +
drivers/regulator/Makefile |1 +
drivers/regulator/da9052-regulator.c | 543 ++
3 files changed, 551 insertions(+), 0 deletions(-)
create mode 100755 drivers/regulator/da9052-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index fa61fe2..ae80461 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -167,6 +167,13 @@ config REGULATOR_DA903X
Say y here to support the BUCKs and LDOs regulators found on
Dialog Semiconductor DA9030/DA9034 PMIC.
+config REGULATOR_DA9052
+tristate Dialog DA9052 regulators
+depends on PMIC_DA9052
+help
+ Say y here to support the BUCKs and LDOs regulators found on
+ Dialog Semiconductor DA9052 PMIC.
+
config REGULATOR_PCF50633
tristate PCF50633 regulator driver
depends on MFD_PCF50633
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 8cb6d0d..07d340b 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
+obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
diff --git a/drivers/regulator/da9052-regulator.c
b/drivers/regulator/da9052-regulator.c
new file mode 100755
index 000..f609a5c
--- /dev/null
+++ b/drivers/regulator/da9052-regulator.c
@@ -0,0 +1,543 @@
+/*
+* da9052-regulator.c: Regulator driver for DA9052
+*
+* Copyright(c) 2011 Dialog Semiconductor Ltd.
+*
+*Author: David Dajun Chen dc...@diasemi.com
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License as published by
+* the Free Software Foundation; either version 2 of the License, or
+* (at your option) any later version.
+*
+*/
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+
+#include linux/mfd/da9052/da9052.h
+#include linux/mfd/da9052/reg.h
+#include linux/mfd/da9052/pdata.h
+
+/* Buck step size */
+#define DA9052_BUCK_PERI_3uV_STEP 10
+#define DA9052_BUCK_PERI_REG_MAP_UPTO_3uV 24
+#define DA9052_CONST_3uV 300
+
+/* Buck current limits */
+#define DA9052_BUCK_CURRENT_LIMIT_700mA0
+#define DA9052_BUCK_CURRENT_LIMIT_800mA1
+#define DA9052_BUCK_CURRENT_LIMIT_1000mA 2
+#define DA9052_BUCK_CURRENT_LIMIT_1200mA 3
+
+/* Bit masks */
+#define DA9052_BUCK_ILIM_MASK_EVEN 0x3F
+#define DA9052_BUCK_ILIM_MASK_ODD 0xF3
+
+struct da9052_regulator_info {
+ struct regulator_desc reg_desc;
+ int step_uV;
+ int min_uV;
+ int max_uV;
+ unsigned char volt_shift;
+ unsigned char en_bit;
+ unsigned char activate_bit;
+};
+
+struct da9052_regulator {
+ struct da9052 *da9052;
+ struct da9052_regulator_info *info;
+ struct regulator_dev *rdev;
+};
+
+static int verify_range(struct da9052_regulator_info *info,
+int min_uV, int max_uV)
+{
+ if (min_uV info-min_uV || min_uV info-max_uV)
+ return -EINVAL;
+ if (max_uV info-min_uV || max_uV info-max_uV)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int da9052_regulator_enable(struct regulator_dev *rdev)
+{
+ struct da9052_regulator *regulator = rdev_get_drvdata(rdev);
+ struct da9052_regulator_info *info = regulator-info;
+ int offset = rdev_get_id(rdev);
+
+ return da9052_reg_update(regulator-da9052,
+DA9052_BUCKCORE_REG + offset,
+1 info-en_bit, 1);
+}
+
+static int da9052_regulator_disable(struct regulator_dev *rdev)
+{
+ struct da9052_regulator *regulator = rdev_get_drvdata(rdev);
+ struct da9052_regulator_info *info = regulator-info;
+ int offset = rdev_get_id(rdev);
+
+ return da9052_reg_update(regulator-da9052,
+DA9052_BUCKCORE_REG + offset,
+
Re: [PATCH v6 00/11] mmc: use nonblock mmc requests to minimize latency
+static inline void __dma_sync(void)
+{
+ dsb();
+}
+
/*
* Return whether the given device DMA address mask can be supported
* properly. For example, if your device can only drive the low 24-bits
@@ -378,6 +383,7 @@ static inline dma_addr_t dma_map_single(struct device
*dev, void *cpu_addr,
BUG_ON(!valid_dma_direction(dir));
addr = __dma_map_single(dev, cpu_addr, size, dir);
+ __dma_sync();
Russell,
I'm curious about the correctness of this patch for systems with
outer cache. shouldn't the dsb be issued before the outer cache
maintenance?
saeed
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] Samsung ARM:EXYNOS4: DMA Cleanup
Function declaration differs between file:s3c-pl330.c and file:dma.h and SPARSE (Documentation/sparse.txt) gives error messages Signed-off-by: Sangwook Lee sangwook@linaro.org --- arch/arm/plat-samsung/include/plat/dma.h | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/plat-samsung/include/plat/dma.h b/arch/arm/plat-samsung/include/plat/dma.h index 2e8f8c6..7365f46 100644 --- a/arch/arm/plat-samsung/include/plat/dma.h +++ b/arch/arm/plat-samsung/include/plat/dma.h @@ -62,7 +62,7 @@ typedef int (*s3c2410_dma_opfn_t)(struct s3c2410_dma_chan *, * request a dma channel exclusivley */ -extern int s3c2410_dma_request(unsigned int channel, +extern int s3c2410_dma_request(enum dma_ch id, struct s3c2410_dma_client *, void *dev); @@ -71,14 +71,14 @@ extern int s3c2410_dma_request(unsigned int channel, * change the state of the dma channel */ -extern int s3c2410_dma_ctrl(unsigned int channel, enum s3c2410_chan_op op); +extern int s3c2410_dma_ctrl(enum dma_ch id, enum s3c2410_chan_op op); /* s3c2410_dma_setflags * * set the channel's flags to a given state */ -extern int s3c2410_dma_setflags(unsigned int channel, +extern int s3c2410_dma_setflags(enum dma_ch id, unsigned int flags); /* s3c2410_dma_free @@ -86,7 +86,7 @@ extern int s3c2410_dma_setflags(unsigned int channel, * free the dma channel (will also abort any outstanding operations) */ -extern int s3c2410_dma_free(unsigned int channel, struct s3c2410_dma_client *); +extern int s3c2410_dma_free(enum dma_ch id, struct s3c2410_dma_client *); /* s3c2410_dma_enqueue * @@ -95,7 +95,7 @@ extern int s3c2410_dma_free(unsigned int channel, struct s3c2410_dma_client *); * drained before the buffer is given to the DMA system. */ -extern int s3c2410_dma_enqueue(unsigned int channel, void *id, +extern int s3c2410_dma_enqueue(enum dma_ch idx, void *id, dma_addr_t data, int size); /* s3c2410_dma_config @@ -103,14 +103,14 @@ extern int s3c2410_dma_enqueue(unsigned int channel, void *id, * configure the dma channel */ -extern int s3c2410_dma_config(unsigned int channel, int xferunit); +extern int s3c2410_dma_config(enum dma_ch id, int xferunit); /* s3c2410_dma_devconfig * * configure the device we're talking to */ -extern int s3c2410_dma_devconfig(unsigned int channel, +extern int s3c2410_dma_devconfig(enum dma_ch id, enum s3c2410_dmasrc source, unsigned long devaddr); /* s3c2410_dma_getposition @@ -118,7 +118,7 @@ extern int s3c2410_dma_devconfig(unsigned int channel, * get the position that the dma transfer is currently at */ -extern int s3c2410_dma_getposition(unsigned int channel, +extern int s3c2410_dma_getposition(enum dma_ch id, dma_addr_t *src, dma_addr_t *dest); extern int s3c2410_dma_set_opfn(unsigned int, s3c2410_dma_opfn_t rtn); -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 00/11] mmc: use nonblock mmc requests to minimize latency
On Mon, Jun 27, 2011 at 01:34:48PM +0300, saeed bishara wrote: Russell, I'm curious about the correctness of this patch for systems with outer cache. shouldn't the dsb be issued before the outer cache maintenance? Maybe we should do two passes over SG lists then - one for the inner and another for the outer cache? In effect we could do three passes: 1. Calculate the total size of the SG list to determine whether full cache flush is more efficient. 2. Flush inner cache Then dsb() 3. Flush outer cache Another dsb() ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM Cross-Compilation
+++ Marc-André Moreau [2011-06-26 10:41 -0400]: Nothing wrong with this method, and it is reliable, but I find it quicker and easier to use multistrap and do: multistrap -f Will look into that, it could save me time sorry that should read multistrap -f /usr/share/multistrap/ubuntu/armel.conf but then I realised that it's not been updated for natty. I'll do an upload forthwith. xapt: The problem is then that xapt will fail to install the converted packages, saying the package architecture is different from the current architecture, as well as missing dependencies. You are suffering from this problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629595 which is because we are in the middle of a transition to multiarch packages. Ok, so I should assume that this stuff is broken for pretty much anyone using natty? Essentially yes. I'll see if I can get an xapt (or dpkg-cross) update pushed in. however there is then a link failure, when it tries to link the wrong arch of libpthread.so: /usr/lib/gcc/arm-linux-gnueabi/4.5.2/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libpthread.so when searching for -lpthread /usr/lib/x86_64-linux-gnu/libpthread.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status If I understand correctly, xapt is broken on natty, so I could give this build of xapt a try, but then when trying to build FreeRDP I'll still have the problem described above? Correct. I'll have a look at that to see what's going on there and what options we have to fix it. Something is pointing at the wrong-arch version. deb [arch=armel] http://ports.ubuntu.com/ natty main universe deb-src [arch=armel] http://ports.ubuntu.com/ natty main universe That looks OK (except the last line should be: deb-src http://ports.ubuntu.com/ natty main universe (It doesn't actually break anything - just makes no sense - Have I left that in a doc somewhere?) Hum... not sure where I read that, are you referring to the [arch=armel] part? I read in certain places that it was something new that should be there, but it didn't change anything. You need [arch=armel] for the binary line, but not the source line (where it is meaningless). Change it if you see it in docs. So, the easiest way to get cross-building is to do it on a debian wheezy machine/chroot where the tools and build work OK. As you want to do neon dev then you may need to install a new-enough cross-toolchain, which probably means a linaro one. I see the linaro wiki and website refer to ubuntu a lot, and not necessarily debian. There is also much more support and documentation for ubuntu rather than debian for the pandaboard. I understand it would be much easier to get it to compile in the first place with debian wheezy, but I would prefer staying with ubuntu, if it is possible. I tried just tried xapt in oneiric, it doesn't seem to be fixed :( Besides xapt, what would be seriously broken in ubuntu natty? Maybe I could just compile the latest version of xapt myself on natty? linaro does currently do much of its work in Ubuntu so you are likely to find latest stuff there. On the other hand Debian on panadaboard works fine too SFAIK, so they are probably both reasonable choices. In general the cross-tools should work the same in both, but it's one area where some stuff happens first in Debian. I don't expect anything else to be seriously broken in natty, but then I don't expect different link behaviour for a given build on the two systems either, so you never know until you try. So, is a wheezy-based build sufficient for you for the time being? Or do you have to have it building on natty to do useful dev? My main problem would be debian support on the pandaboard which is much less documented than ubuntu. I'd prefer working around the various issues found in natty and work with natty instead, if we can work around all the current problems. If it's just too much of a pain, I'll have to give wheezy a try, but I don't think it'll be as easy to get wheezy up and running on the pandaboard. This thread suggests it's perfectly do-able: http://groups.google.com/group/pandaboard/browse_thread/thread/94773021fbe2a2aa but natty/onieric needs fixing anyway, so I'll do that, which will, as you say probably give you an easier life overall. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: More pinmux feedback, and GPIO vs. pinmux interaction
On Fri, Jun 24, 2011 at 5:51 AM, Mike Frysinger vapier@gmail.com wrote: can you guys start cc-ing uclinux-dist-de...@blackfin.uclinux.org on future pinmux discussions? OK! Please refer to the LKML thread: [PATCH 1/2] drivers: create a pinmux subsystem v3 For now, I'll include blackfin for the v4 post. we already have a thin layer in the Blackfin tree for handling pin muxing that has served us well for a few years, so we want to keep tabs on where this is going. i just happened to stumble across this today. Aha now it's yet another name, portmux, to add to the happy family of pinmux, padmux, fingermux, alternate functions and mission mode terminology soup ;-) arch/blackfin/include/asm/portmux.h: peripheral_request() peripheral_request_list() peripheral_free() peripheral_free_list() this lets you pass in an array of pins and it returns success only if all were available. we find the array request method gets used the vast majority of the time, so any proposed API should include that. I think if you look at the Documentation/pinctrl.txt file from the last iteration of the framework you find that this is exactly what the pinmux part of the pinctrl subsystem does. It avoids pin clashes in a discrete number space. If I'm not mistaken. (Which happens a lot.) we also handle pins that can only be used in peripheral mode. this allows us to write code that requests UART pins without having to know whether the pin is muxed or dedicated or somewhere in between. This is done with pinmux_get() and pinmux_enable() in this framework. Grant does not seem to like the idea of the gpio subsystem meddeling with all this stuff anyway, so I intend to take all that into pinctrl, and then gpio only deal with, well GPIO. Setting bits quickly and such. but there has to be resource management between the two subsystems somewhere. on the Blackfin side, if you request a pin as a GPIO using the GPIO api, and then try to request it in peripheral mode, you get EBUSY back. you cant have the two blocks stepping on each others toes. Yes. Avoiding this is exactly the idea behind the int (*gpio_request_enable) (struct pinmux_dev *pmxdev, unsigned offset); member in the pinmux_ops vtable. We're discussing the exact semantics of this call here. We all agree we need something that can allocate a single pin for GPIO in the number space, I think. some Blackfin parts have this to ease the conflicts between devices that customers want. if UART0 and SPI0 share PF0, PF1, and PF2, sometimes UART0 can be routed to PG3 and PG4 so that SPI0 can be used. This kind usecase is covered extensively in the documentation and previous discussion IIUC. atm we've made this a Kconfig option. obviously that wont fly in the build one image to run on all platforms, but that isnt a problem for Blackfin systems today, and customers have been OK with this minor limitation. I think we may be able to fix that limitation, and would like to make sure we're not engineering in some limitation for Blackfin, so hit us. we implemented this on the Blackfin side by encoding things into the pin data. but that's because we had enough space in u16 to cover all of our parts so far. for example, the PA1 pin can act as GPIO, or as a timer pin, or as part of our high speed peripheral SPORT. #define P_SPORT2_DTSEC (P_DEFINED | P_IDENT(GPIO_PA1) | P_FUNCT(0)) #define P_TMR4 (P_DEFINED | P_IDENT(GPIO_PA1) | P_FUNCT(1)) when someone does peripheral_request(P_TMR4), the code first reserves itself with the GPIO core, and then configures the pinmux logic to set this pin as function 1 (it's a 2 bit field). In ARM we're at the stage now where each mach-foo under arch/arm/* is running its own show in this regard. For example mach-ux500 magically stuff all its pin configuration into a u32 cleverly reusing bits here and there. Everyone is special, just like everybody else... Basically there are as many pinmux implementations as there are machines, and then we end up with that other Linus beating us on the head for not consolidating our stuff into something generic. So I'm doing this framework using some structs and radix trees and no magic bitstuffing for now. we also have pin grouping logic implemented for the parts which dont have per-pin muxing so you cant request different pins in the same group for the same mode. We should be able to solve that I think! Yours, Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Customization of Gerrit for Android
On Mon, 27 Jun 2011 11:25:59 +0200, Alexander Sack a...@linaro.org wrote: hi, great news. I think we should use a different hostname for gerrit. like review.android.linaro.org. With that we have the option to make a dedicated android git host using the android.git.l.o name eventually. I don't understand what this means. What's a dedicated android git host and why can't it co-exist with Gerrit? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] drivers: create a pinmux subsystem v3
On Thu, Jun 16, 2011 at 9:10 PM, Stephen Warren swar...@nvidia.com wrote:
Linus Walleij wrote at Thursday, June 16, 2011 6:47 AM:
NOW I *think* I get it.
So we're basically talking about the function mapping API here.
Yes, basically.
In more detail, I'm talking about making the functions exposed to
clients of the pinmux be a different set than the functions
implemented by the pinmux driver. Perhaps we should call the former
mappings not make that clear; I see you did just below!
OK I get it now I believe.
The mappings, provided by and specific to a particular board/machine
would always expose only the exact configurations actually used on that
board:
mapping device: tegra-kbc
mapping name: config a
mapping function list: row[7:4], row[3:0], col[3:0]
(note how I added a mapping name field here; more on this below. This
is related to mapping and function names being different things)
OK so one mapping reference several functions in this way,
I see.
You will need atleast to move the functions out of the mapping
something like this:
static char *mmc0_10[] = { mmc0-1:0, mmc0-3:2, mmc0-7:4 };
static struct pinmux_map pmx_mapping[] = {
{
.functions = mmc0_10,
.functions_len = ARRAY_SIZE(mmc0_10);
.dev_name = tegra-sdhci.0,
},
};
Which sort of kludges up the syntax for all the simple cases that will
also have to add ARRAY_SIZE() and a separate string array for
each of its single-function maps.
So it has the downside of complicating the simple maps.
Yes, you're right. I think I have a simpler solution that degenerates to
the same syntax as in your current patch. Starting with your original:
static struct pinmux_map pmx_mapping[] = {
{
.dev_name = tegra-sdhci.0,
.function = mmc0-1:0,
},
(where devices look up mappings by .function, among other options)
We then add a new mapping name field; you'll see why soon:
static struct pinmux_map pmx_mapping[] = {
{
.dev_name = tegra-sdhci.0,
.map_name = 2 bit,
.function = mmc0-1:0,
},
(where we now use .map_name for searching the list instead of
.function, which ties into my comment above about having explicit
different sets of names for mapping entries and low-level pinmux driver
internal function names.
We can still set .map_name = NULL and omit it in the simple case where
drivers search based on .dev_name and don't specify any specific
.map_name to search for, and don't have multiple options for mappings
they can switch between.
Now, we can have multiple entries with the same .map_name:
static struct pinmux_map pmx_mapping[] = {
{
.dev_name = tegra-sdhci.0,
.map_name = 4 bit, # Note this is 4 now
.function = mmc0-1:0,
},
{
.dev_name = tegra-sdhci.0,
.map_name = 4 bit,
.function = mmc0-3:2,
},
This means that if a client request map name 4 bit, then both functions
mmc0-1:0 and mmc0-3:2 are part of that mapping.
(...)
In terms of implementation, this is still pretty easy; all we do when
reserving or activating a given mapping is to walk the entire list, find
*all* entries that match the client's search terms, and operate on all of
them, instead of stopping at the first one.
So:
pmx = pinmux_get(dev, 4 bit);
in this case would reserve pins for two functions on pinmux_get() and
activate two different functions after one another when
we pinmux_enable(pmx) on this, mmc0-1:0 and mmc0-3:2 in some
undefined order (inferenced across namespace).
I don't think it's as simple as you say, this gets hairy pretty quickly:
Since my previous pinmux_get() would create a struct pinmux * cookie
for each map entry, assuming a 1:1 relationship between map entries
and pinmuxes, we now break this, and you need to introduce
more complex logic to search through the pinmux_list and dynamically
add more functions to each entry with a matching map_name.
Then you need to take care of the case where acquiring pins for
one of the functions fail: then you need to go back and free the
already acquired pins in the error path.
I tried quickly to see if I could code this up, and it got very complex
real quick, sadly. Maybe if I can just get to iterate a v4 first, I
could venture down this track.
But if you can code up the patch for this, I'm pretty much game for
it!
struct pinmux, as returned by pinmux_get(), would need some adjustments
to store either an array of map entries, or just the .map_name of the
found entry/entries, so the loop could be repeated later.
Yes if we can just write the code for it I buy into it. :-)
So sorry but just to hammer home my point, the disadvantages of the pinmux
driver itself (as opposed to the mapping list) aggregating multiple pins
or groups-of-pins into functions for each supported combination are:
*
Re: FYI: Linaro Validation showcase video at Computex 2011
On 24 June 2011 13:17, Paul Larson paul.lar...@linaro.org wrote: Neat! Any feedback from those who saw it? hi Paul, Yes, we got many feedback and inputs while presenting LAVA and corresponding Android platform support. I think most visitors agreed with the idea and importance of LAVA, but it is a bit hard for some of them to Imagine how (and why) various steps are necessary to perform ordinary concepts such as Built in the cloud - Deploy Linaro Evaluation Build images into target - Execute system benchmark - Collect results and visualize in somewhere. The reason why I attempted to write Gtk+ front-end is simplifying the details of the showcase and even making it visualized for LAVA. By the way, thank Validation team to bring it to the world. :) Sincerely, -jserv On Fri, Jun 24, 2011 at 12:00 AM, Jim Huang jim.hu...@linaro.org wrote: During the first week of June, we prepared the technical showcase[1] about Linaro powered devices and projects including LAVA[1]. To emphasize how LAVA works, we just uploaded another demo video: http://www.youtube.com/watch?v=_3dT68MOzz0 It starts at 2:27. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 00/11] mmc: use nonblock mmc requests to minimize latency
On Mon, Jun 27, 2011 at 12:02 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: The next thing to think about in DMA-land is whether we should total up the size of the SG list and choose whether to flush the individual SG elements or do a full cache flush. There becomes a point where the full cache flush becomes cheaper than flushing each SG element individually. We noticed that even for a single (large) buffer, any cache flush operation above a certain threshold flushing indiviudal lines become more expensive than flushing the entire cache. I requested colleagues to look into implenting this threshold in the arch/arm/mm/cache-v7.S file. but I think they ran into trouble and eventually had to give up on it. Vijay or Srinidhi, can you share your findings? Thanks, Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Building/testing linaro kernels in Thumb-2
There are brief notes about how to enable Thumb-2 kernel building here: https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_a_generic_base Currently, omap and vexpress are known to work in this configuration, and mx51evk seems to have basic support. Other platforms might not work at all. If people can get into the habit of testing both ARM and Thumb-2 kernel configurations when testing the linaro kernel tree, that would be great! Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Multimedia WG status report - wk25.2011 (20110620-20110624)
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Highlights: Approaching the public plans review - blueprints are being created by the team. 5 TRs will be the work focus: - OpenMAX Integration - Userspace UMM - Codec optimization - NEON optimization forum - Audio integration It was decided that due to time shortage because of the planning, the work to release libjpeg-turbo for Android during 11.07 would not be feasible Also in discussions during this week, with Jesse Barker and Kurt Taylor, it was identified that we would need some guidance and support related to Android deliverables. Specifically having someone from the Android team guide our integration tasks, and perhaps set up a regular sync-up about Android integration would be beneficial. BR, -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Graphics WG status - wk25.2011 (20110620-20110624)
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport == Highlights: * glcompbench and glmark2 have been released on 20110627 * unity-gles tarball on its way for the milestone release - getting ironed out as this is written * Last week's Graphics meeting was replaced by the meeting of the Memory Management group which took place on #linaro-mm-sig IRC channel on 20110622. There is more detailed information on the linaro-mm-sig meeting wiki page (https://wiki.linaro.org/OfficeofCTO/MemoryManagement/Notes/2011-06-22). Also don't miss to read the LWN article on Contiguous Memory Allocation : http://lwn.net/Articles/447405/ == Upcoming Deliverables: Planned content for the 11.07 release. == Risks / Issues: This was discussed together with Jesse Barker and Kurt Taylor from MMWG: related to Android released content from the graphics WG, we would need some guidance and support. Specifically having someone from the Android team guide our integration tasks, and perhaps set up a regular sync-up about Android integration would be beneficial. BR, -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH v6 00/11] mmc: use nonblock mmc requests to minimize latency
Hi, The below are the timings on clean flush. /* Size Clean Dirty_cleanFlush Dirty_Flush T1(ns) T2(ns) T3(ns) T2(ns) 4096 3051730517 30517 30517 8192 3051730517 30517 30517 163843051830518 30518 30518 327683051830518 30518 61035-- 368646103661036 61035 61035 655369155391553 91553 91553 131072 183106 183106183106 183106 Full 3051830518 30518 30518-- Cache */ /* Based on Above values, 32768 size is breakeven for flushing/cleaning * full D cache */ I have noticed with 32KB DLIMIT, there is small reduction about 1fps in skiamark profile after this change. It could be because of full flush or clean is causing more cache misses later on in the execution. However with 64KB DLIMIT, there is further degrade in skiamark performance. So I think 32KB is good value. However the problems are seen in the Android UI. Small artifacts are seen during Video playback on UI widgets. This artifacts are not seen if clean is called for each cpu. Also I find it takes some effort to implement clean_all / flush_all API's in cache-V7.S (asm) file to execute on each cpu. And hence it was parked aside. And I have not investigated, why flush on both cases in case of flush all on Both cpu's always works? Thanks Regards Vijay -Original Message- From: Linus Walleij [mailto:linus.wall...@linaro.org] Sent: Monday, June 27, 2011 5:30 PM To: Russell King - ARM Linux; Srinidhi KASAGAR; Vijaya Kumar K-1 Cc: Per Forlin; Nicolas Pitre; Chris Ball; linaro-dev@lists.linaro.org; linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Robert Fekete Subject: Re: [PATCH v6 00/11] mmc: use nonblock mmc requests to minimize latency On Mon, Jun 27, 2011 at 12:02 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: The next thing to think about in DMA-land is whether we should total up the size of the SG list and choose whether to flush the individual SG elements or do a full cache flush. There becomes a point where the full cache flush becomes cheaper than flushing each SG element individually. We noticed that even for a single (large) buffer, any cache flush operation above a certain threshold flushing indiviudal lines become more expensive than flushing the entire cache. I requested colleagues to look into implenting this threshold in the arch/arm/mm/cache-v7.S file. but I think they ran into trouble and eventually had to give up on it. Vijay or Srinidhi, can you share your findings? Thanks, Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Switch to ubuntu-build.linaro.org
On Sun, 26 Jun 2011 11:06:08 +0300, Fathi Boudra fathi.bou...@linaro.org wrote: Yes. 3 consecutive days without any glitches. +1 on my side. Fathi, Do you want to switch this week? (I can't tell you exactly when we can switch as it relies on the availability of an IS sysadmin to make the changes.) Were you planning on taking the 11.06 release from ubuntu-build images or the OEM-built images? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] OCTO status report - wk25.2011 (20110620-20110624)
https://wiki.linaro.org/OfficeofCTO/Status/2011-06-21 == Highlights == - The Memory Management group met on #linaro-mm-sig IRC channel on 20110622. A summary of the meeting: * Most of the discussion revolved around the large physical allocation support (aka CMA) - specifically on the CMA areas initialization, allocations being in a specific area (memory bank), handling device specific attributes. * Towards the end of the meeting the discussion also touched on dma-mapping API status, as well as the participation to Linaro Connect. There are already 5 V4L2 developers interested in collocating a V4L2 brainstorming session with Linaro Connect. there might be a 6th one - ARMHF * Java is fixed - at least gcj seems to work. However immediately after that ecj started complaining. Konstantinos has nevertheless built a lot of packages for armhf - next step is to bootstrap openjdk * kde4libs has been failing lately, leading to not being able to have kde armhf packages ready. This was pinpointed to be due to qt4 atomics being broken on armhf, missing the patch from Ubuntu, so kde packages are now getting fixed * Debian has/is just undergoing a huge number of transitions now, and for debian-ports the team has to act on those manually (status is in http://www.debian-ports.org/~iwamatsu/transition/) - Device tree: Grant Likely has been working on bug https://bugs.launchpad.net/bugs/707047 (Only half of RAM useable when using Device Tree on Panda board). Grant is also coordinating the efforts for the Linaro Connect discussions related to device tree and boot architecture. - Boot architecture: Loïc Minier has started a discussion on the boot-architecture mailing list (see http://lists.linaro.org/pipermail/boot-architecture/2011-June/16.html) - trying to create a reasonable use case which 'expresses the concept of modules that the boot architecture would cover'. == Upcoming Deliverables == * Expected to close some documentation work items for ARMHF and Boot Architecture during week 26 * Bootable SD card images for armhf, for the efikas, pandaboard, trimslice, should be uploaded during week 26 * ARMHF initial set of benchmarks should start appearing during week 26 == Miscellaneous == David Rusling back from holiday Konstantinos Margaritis is back from the Genesi sprint US trip -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Kernel 11.06 Snapshot
The Linaro Kernel Working Group (KWG) is excited to announce the availability our June 2011 development snapshot: linux-linaro-2.6.39-2011.06-0 As the word snapshot implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/2.6.39/2.6.39-2011.06/+download/linux-linaro-2.6.39-2011.06-0.tar.bz2 The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-2.6.39.git tag: linux-linaro-2.6.39-2011.06-0 This snapshot is based on the 2.6.39.1 stable kernel with a number of changes developed by Linaro and integrated from the 3.0-rc. The changes since our 11.05 release, other than what is already in 2.6.39 include: * Fixed LP #754254: imx51 randomly truncates serial input at 31 characters * Ability to append Device Tree to zImage at build time * Support for parallel async MMC requests * Common MMIO clocksource infrastructure * Moving of various drivers out of arch/arm into drivers/ A full changelog against 2.6.39.1 is available at: http://launchpad.net/linux-linaro/2.6.39/2.6.39-2011.06/+download/linux-linaro-2.6.39-2011.06-0.tar.bz2 High Priority Known Issues: * Only half of RAM useable when using Device Tree on Panda board (LP #707047) Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[STATUS] Zach Pfeffer 2011/6/19 - 2011/6/25
== Zach Pfeffer pfefferz == === Highlights === * Finishing up 11.06 milestones * Tested patch to linaro-image-tools for Android LEB * Got Android PoC program underway (Frans for STE, Bernhard for Freescale) * Clarified 11.06 deliverable * Onboarded Bernhard Rosenkraenzer and Frans Gifford * Interviewed * Held meeting and wrote up ideas for AOSP upstreaming * Forward ported EDID parser from Pandroid 35 to Andy's TI LEB to ensure a fully enable LEB with 1080P * Supported STE's Android bringup === Plans === * Finish 11.06 release * Go through the backlog for 11.07 planning * Push Freescale and STE builds forward === Issues === * Need a company-wide AOSP plan * Need AOSP based 3.0 kernels ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Switch to ubuntu-build.linaro.org
On 27 June 2011 19:40, James Westby james.wes...@linaro.org wrote: On Sun, 26 Jun 2011 11:06:08 +0300, Fathi Boudra fathi.bou...@linaro.org wrote: Yes. 3 consecutive days without any glitches. +1 on my side. Fathi, Do you want to switch this week? (I can't tell you exactly when we can switch as it relies on the availability of an IS sysadmin to make the changes.) asap, this week or next week. Were you planning on taking the 11.06 release from ubuntu-build images or the OEM-built images? from ubuntu-build.linaro.org Cheers, Fathi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro GCC 4.4 end-of-life reached on June 28, 2011
This note is to confirm that support for Linaro GCC 4.4 formally ended on June 28, 2011. The recommended upgrade path is to our current Linaro GCC 4.6 development branch or to our Linaro GCC 4.5 maintenance branch. Third-party fixes continue to be accepted for Linaro GCC 4.4 and all releases, branches, and history will remain available. Since entering development in July 2010, we have made eight releases containing many new features 22 bug fixes. Linaro GCC 4.4 was our first release and set the stage for the current, ongoing work. -- Michael Hope Toolchain Technical Lead ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro GCC 4.5 entered maintenance on June 28, 2011
This note is to confirm that Linaro GCC 4.5 entered maintenance on June 28, 2011. The new development branch is the 4.6.1 based Linaro GCC 4.6. Linaro GCC 4.5 continues to be actively supported with select high-impact bug fixes and will remain so until it enters end-of-life, shortly after Linaro GCC 4.7 is released. Monthly releases will be made alongside the new development release. -- Michael Hope Toolchain Technical Lead ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Android Platform Team 2011-05-29 to 2011-06-04
Getting the Android Platform Team status pages out. Sorry for the wait. == Key Points for wider discussion == * Starting to look at shipping a full Panda LEB == Team Highlights == * Started working on Android public plan * Started interviewing new candidates * Created LT panda build to work from * Created GTK LAVA frontend == Risks / Issues == * Need staff * Computex demo needs clarity == Miscellaneous == * None ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Android Platform Team 2011-06-05 to 2011-06-11
== Key Points for wider discussion == * LEB work progressing * Reference builds available == Team Highlights == * Gave Android Public Plan Review * Attended and participated in the Multimedia WG Mini-Summit in Austin * Started bringing in Pandroid build * 4.5 GCC packaging work == Risks / Issues == * Staff == Miscellaneous == * None ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Android Platform Team 2011-06-12 to 2011-06-18
== Key Points for wider discussion == * Android LEB is almost done * Pushing to AOSP == Team Highlights == * Started weekly WG and LT integration meetings * Helped debug SGX issue * Continued SPDX work * Almost finished with Pandroid build * LAVA Gtk+ published * AOSP contribution: https://review.source.android.com//#change,23997 * AOSP contribution: https://review.source.android.com//#change,23998 * Tried snowball community distro: Unable to boot * Frans and Bernhard coming onboard == Risks / Issues == * Staff * Licensing == Miscellaneous == * New starters: Frans Gifford, Bernhard Rosenkränzer ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
