[Patch v1 08/11] Touch: DA9052 touchscreen driver
This driver add support for DA9052 4-wire resistive ADC interfaced touchscreen
controller.
DA9052 is a MFD therefore this driver depends on DA9052 core driver for core
functionalities.
Signed-off-by: David Dajun Chen dc...@diasemi.com
Signed-off-by: Ashish Jangam ashish.jan...@kpitcummins.com
---
drivers/input/touchscreen/Kconfig |7 +
drivers/input/touchscreen/Makefile |1 +
drivers/input/touchscreen/da9052_tsi.c | 489
3 files changed, 497 insertions(+), 0 deletions(-)
create mode 100755 drivers/input/touchscreen/da9052_tsi.c
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index cabd9e5..a5d2e7b 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -144,6 +144,13 @@ config TOUCHSCREEN_DA9034
Say Y here to enable the support for the touchscreen found
on Dialog Semiconductor DA9034 PMIC.
+config TOUCHSCREEN_DA9052
+ tristate Dialog DA9052 TSI
+ depends on PMIC_DA9052
+ help
+ Say y here to support the touchscreen found on
+ Dialog Semiconductor DA9052 PMIC
+
config TOUCHSCREEN_DYNAPRO
tristate Dynapro serial touchscreen
select SERIO
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 282d6f7..a4aeb25 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_TOUCHSCREEN_BITSY) +=
h3600_ts_input.o
obj-$(CONFIG_TOUCHSCREEN_BU21013) += bu21013_ts.o
obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110) += cy8ctmg110_ts.o
obj-$(CONFIG_TOUCHSCREEN_DA9034) += da9034-ts.o
+obj-$(CONFIG_TOUCHSCREEN_DA9052) += da9052_tsi.o
obj-$(CONFIG_TOUCHSCREEN_DYNAPRO) += dynapro.o
obj-$(CONFIG_TOUCHSCREEN_HAMPSHIRE)+= hampshire.o
obj-$(CONFIG_TOUCHSCREEN_GUNZE)+= gunze.o
diff --git a/drivers/input/touchscreen/da9052_tsi.c
b/drivers/input/touchscreen/da9052_tsi.c
new file mode 100755
index 000..dade0a9
--- /dev/null
+++ b/drivers/input/touchscreen/da9052_tsi.c
@@ -0,0 +1,489 @@
+/*
+ * TSI driver for Dialog 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/input.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/freezer.h
+#include linux/kthread.h
+#include linux/kfifo.h
+
+#include linux/mfd/da9052/reg.h
+#include linux/mfd/da9052/da9052.h
+
+#define DA9052_ACTIVE 1
+#define DA9052_INACTIVE0
+
+#define DA9052_TSI_FIFOSIZE640
+
+enum {
+ DA9052_PEN_IDLE,
+ DA9052_PEN_DOWN,
+ DA9052_PEN_UP
+};
+
+struct da9052_tsi_reg {
+ u16 x;
+ u16 y;
+};
+
+struct tsi_thread_type {
+ u8 pid;
+ u8 state;
+ struct completion notifier;
+ struct task_struct *thread_task;
+};
+
+struct da9052_tsi {
+ struct da9052 *da9052;
+ struct input_dev *dev;
+ struct tsi_thread_type tsi_pen_state_thread;
+ struct tsi_thread_type tsi_filter_thread;
+ struct kfifo fifo;
+ struct kfifo fifo_buf;
+ u8 pen_up_detect_interval;
+ u32 zero_data_cnt;
+ u32 valid_penup_count;
+ u8 pen_state;
+ int irq_pendwn;
+ int irq_datardy;
+};
+
+static inline int da9052_ts_start(struct da9052_tsi *tsi)
+{
+ return da9052_reg_update(tsi-da9052, DA9052_TSI_CONT_A_REG,
+1 0, 1 0);
+}
+
+static inline int da9052_ts_stop(struct da9052_tsi *tsi)
+{
+ return da9052_clear_bits(tsi-da9052, DA9052_TSI_CONT_A_REG, 1 0);
+}
+
+static irqreturn_t da9052_ts_pendwn_irq(int irq, void *data)
+{
+ struct da9052_tsi *tsi = (struct da9052_tsi *)data;
+ struct da9052 *da9052 = tsi-da9052;
+ int ret;
+
+ da9052-events_mask |= DA9052_E_PEN_DOWN;
+ da9052-events_mask = ~DA9052_E_TSI_READY;
+
+ /* Mask PEN_DOWN event and unmask TSI_READY event*/
+ ret = da9052_reg_update(da9052, DA9052_IRQ_MASK_B_REG, 0x80, 0x40);
+ if (ret 0)
+ return IRQ_NONE;
+
+ da9052_ts_start(tsi);
+ tsi-pen_state = DA9052_PEN_DOWN;
+
+ return IRQ_HANDLED;
+}
+
+static int da9052_ts_read(struct da9052_tsi *tsi)
+{
+ struct da9052_tsi_reg co_ord = {0, 0};
+ int ret;
+ uint8_t _x, _y, _v;
+
+ ret = da9052_reg_read(tsi-da9052, DA9052_TSI_X_MSB_REG);
+ if (ret 0)
+ return ret;
+
+ _x = (uint8_t) ret;
+
+ ret = da9052_reg_read(tsi-da9052, DA9052_TSI_Y_MSB_REG);
+ if (ret 0)
+
Re: Please tag commits referred to by pinned and release manifests in Android builds
Hello John, On Tue, 12 Jul 2011 02:13:40 -0600 John Rigby john.ri...@linaro.org wrote: [] If I read the prior emails correctly then the commit needs to be reachable by a head but not necessarily the head as in master so I believe that I can still rebase master (or whatever) as long as released commits are still accessible from some other head. So if each time a release happens a branch is created as well as a tag then there is no problem other than the noise of having these extra branches that only exist for keep tags or commits accessible. Please someone correct me if I am wrong. Yes, this should be the case, i.e. besides creating a tag, also to create a branch from the same underlying revision. Yes, that will lead to proliferation of branches (just as proliferation of tags is often the problem for may projects), but let's treat that as temporary solution while we settle this issue. We might end up with something else, or make policy to clean up old branches/tags after good timeout. In the meantime, I posted about the problem to repo mailing list (cc: linaro-dev), initial response was positive, so maybe it would be fixed on repo side. --john -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 2011-07-14 at 09:10 -0400, Jerry Van Baren wrote: Hi Dave, This looks reasonable, with one minor nit... Need spaces around the = I will add the spaces before applying the patch unless you send an updated patch. OK, thanks much. Someone else recently pointed that out to me too. I can generate another update if you wish, but I'll let you handle that unless you say otherwise. FYI: In case it wasn't clear, this all came about because: 1) the Pandaboard has 1GB of RAM; 2) the presence of an fdt causes u-boot to relocate the fdt and ramdisk to the end of ram by default; 3) and the Linux kernel does not like having to access memory beyond about 3/4G (HIGHMEM) during early boot. Thanks again, -dl ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro 11.07 weekly testing 2011-07-14
Hi, As Fathi is out on vacation, I thought I'd send out the call for our weekly test activity. Even if you're only about to test one image/hwpack combination, your participation is greatly appreciated and essential. This is a message sent out once per week to call on those in the Linaro community to encourage all Linux/ARM enthusiasts to try out the latest Linaro Evaluation Builds (LEBs) preview images for both Android and Linux. Linaro Evaluation Builds (LEB) These images showcase the current state of development on our LEBs images on their way to the next release: 11.07. * Android: http://snapshots.linaro.org/11.05-daily/linaro-android/leb-panda/20110714/ * Ubuntu: http://snapshots.linaro.org/11.05-daily/linaro-ubuntu-desktop/20110714/0/images/tar/ http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/panda-x11-base/20110714/0/images/hwpack/ Installation Instructions -- Installation Instructions can be found here: https://wiki.linaro.org/Platform/Android/ImageInstallation https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation Unsupported Images and Board Support Packages -- Besides the official Linaro Evaluation Builds, the Platform Team hosts additional functional images and board support packages. These images and board support packages are not officially supported and are provided on a best-effort basis in the hope that they can be useful for the Linux/ARM enthusiast community. Unsupported Images - * Nano: (Think small) http://snapshots.linaro.org/11.05-daily/linaro-nano/20110714/0/images/tar/ * ALIP: (xfce UI) http://snapshots.linaro.org/11.05-daily/linaro-alip/20110714/0/images/tar/ * Developer: (text UI + developer tools) http://snapshots.linaro.org/11.05-daily/linaro-developer/20110714/0/images/tar/ Unsupported Board Support Packages: -- Board Support Packages come in the form of what is called a hwpack. Hwpacks can be found for efikamx, igep, imx51, lt-mx5, lt-mx53loco, lt-origen, lt-panda-x11-base-natty, lt-panda, lt-s5pv310, lt-snowball, lt-u8500, omap3-x11-base, omap3, overo, panda, s5pv310, and vexpress http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/ Android Developer and Experimental Images -- Developer and Experimental Images based on Android (vanilla AOSP experience using linux-linaro mainline kernel): * Android Mainline for BeagleBoardr-xM: http://snapshots.linaro.org/11.05-daily/linaro-android/beaglexm/20110714/ * Android Mainline for PandaBoard: http://snapshots.linaro.org/11.05-daily/linaro-android/panda/20110714/ Reporting Testing Results -- Report results at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker -- Regards, Tom We want great men who, when fortune frowns will not be discouraged. - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 11.07 weekly testing 2011-07-14
On 07/14/2011 10:27 AM, Tom Gall wrote: * Android: http://snapshots.linaro.org/11.05-daily/linaro-android/leb-panda/20110714/ The latest android build appears to be from last week. Did the build fail for this week? -andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Consistent names for Linaro kernel trees and releases
On 8 July 2011 12:50, john stultz johns...@us.ibm.com wrote: On Fri, 2011-07-08 at 12:35 -0700, Deepak Saxena wrote: On 1 July 2011 12:14, Deepak Saxena dsax...@linaro.org wrote: Each of the trees have various tags and branches based on how each team and developer works and I don't want to ask folks to change what they are doing for their day to work. What I'd like to see is a a separate set of official trees that only get updated with bits that we are ready for non-Linaro developers to use, do not get rebased, and get tagged at the end of each monthly cycle. My proposal: kernel/linux-linaro-$version with tags for each monthly release: v$version-$milestone-$buildcount So tag wise, since its a source release, by build count you mean more like drop number or something? Yes, so if we release a tarball and two days later we update it due to a critical bug, we'd increase the buildcount. So a concrete example would be: v2.6.39-11.06.4 kernel/linux-linaro-android-$version with tags for each monthly release: android-v$version-$milestone-$buildcount android-v2.6.39-11.06.4 ? The catch here is there may be multiple android drops for one linaro drop. So it would seem: v2.6.39-11.06.4-android-2 Or v$version-$milestone-$buildcount-android-$androidbuildcount Yep, that makes sense. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Fri, 2011-07-15 at 03:50 +0900, Grant Likely wrote: Regardless of this patch, the pandaboard uboot still needs to be fixed. Setting an fdt_high variable is useful for debug, but it is not a fix. Then someone needs to own the issue of stopping the current u-boot default behavior of relocating the initrd and fdt to the end of RAM when an fdt is present. This is an issue for any Linux ARM system with more than 3/4GB of RAM, and probably for other 32-bit architectures. The logic that causes the problem is in architecture-independent code, and I'm not sure I'm necessarily the right guy to go rummaging around in there. There are too many implications for any other currently supported targets that use u-boot and fdt. This new u-boot environment variable stands on it's own as potentially useful, and allows us to avoid the problem (admittedly by specifying environment variable values that really should be the default in this case). -dl ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/1] Add ARM cpu topology definition
On Tue, 12 Jul 2011, Amit Kucheria wrote: From: Vincent Guittot vincent.guit...@linaro.org (Patch accepted by Russell for 3.1: http://www.spinics.net/lists/arm-kernel/msg131273.html) That is good enough for me. I merged it in the linaro-2.6.39 tree for now, and I'll pick it up from mainline when linaro-3.0 opens. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [beagleboard] [ANNOUNCE] First Linaro 11.07 Build Released
On Sun, Jul 10, 2011 at 2:07 PM, Zach Pfeffer zach.pfef...@linaro.org wrote: All, I'm happy to announce the first 11.07 build for generic Panda and Beagle C4. Unfortunately Beagle xM doesn't boot, but Panda and Beagle C4 look great! https://android-build.linaro.org/builds/~linaro-android/beagle-11.07-release/ Hi Zach, Nice work. Is there somewhere where the method to write the Linaro tar files to NAND on Beagle is documented? SD corrupts often on reboot. https://wiki.linaro.org/Platform/Android/ImageInstallation talks about MMC only. -Fred ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 14 Jul 2011 15:12:25 -0400 David Long dave.l...@linaro.org wrote: On Fri, 2011-07-15 at 03:50 +0900, Grant Likely wrote: Regardless of this patch, the pandaboard uboot still needs to be fixed. Setting an fdt_high variable is useful for debug, but it is not a fix. Then someone needs to own the issue of stopping the current u-boot default behavior of relocating the initrd and fdt to the end of RAM when an fdt is present. This is an issue for any Linux ARM system with more than 3/4GB of RAM, and probably for other 32-bit architectures. The logic that causes the problem is in architecture-independent code, and I'm not sure I'm necessarily the right guy to go rummaging around in there. There are too many implications for any other currently supported targets that use u-boot and fdt. You need to use lmb_reserve() to exclude any memory regions that are not suitable for boot images -- see powerpc's arch_lmb_reserve() and get_effective_memsize()/CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE. -scott ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
Hi Dave,
This looks reasonable, with one minor nit...
On 07/09/2011 04:40 PM, David A. Long wrote:
From: David A. Longdave.l...@linaro.org
Add a new fdt_high enviroment variable. This can be used to control (or
prevent) the
relocation of the flattened device tree on boot. It can be used to prevent
relocation
of the fdt into highmem. The variable behaves similarly to the existing
initrd_high
variable.
Signed-off-by: David A. Longdave.l...@linaro.org
---
README |9
common/image.c | 60 ++--
2 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/README b/README
index 8bb9c8d..5b95246 100644
--- a/README
+++ b/README
@@ -3281,6 +3281,15 @@ List of environment variables (most likely not complete):
[snip]
diff --git a/common/image.c b/common/image.c
index e542a57..7853de0 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1234,8 +1234,10 @@ int boot_relocate_fdt (struct lmb *lmb, char
**of_flat_tree, ulong *of_size)
{
void*fdt_blob = *of_flat_tree;
void*of_start = 0;
+ char*fdt_high;
ulong of_len = 0;
int err;
+ int disable_relocation=0;
Need spaces around the =
I will add the spaces before applying the patch unless you send an
updated patch.
Thanks,
gvb
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 07/11] Watchdog: DA9052 watchdog support v1
Hi Ashish, Dajun, This driver adds support for the watchdog functionality provided by the Dialog Semiconductor DA9052 PMIC chip. Signed-off-by: David Dajun Chen dc...@diasemi.com Signed-off-by: Ashish Jangam ashish.jan...@kpitcummins.com --- If there are no comments then can you ACK this patch? I remain with my comment of Wed 26 Jan 2011: The ioctl WDIOC_SETOPTIONS call is not in line with the watchdog API. the supported options are: #define WDIOS_DISABLECARD 0x0001 /* Turn off the watchdog timer */ #define WDIOS_ENABLECARD0x0002 /* Turn on the watchdog timer */ #define WDIOS_TEMPPANIC 0x0004 /* Kernel panic on temperature trip */ Your options are: #define DA9052_STROBING_FILTER_ENABLE 0x0001 #define DA9052_STROBING_FILTER_DISABLE 0x0002 #define DA9052_SET_STROBING_MODE_MANUAL 0x0004 #define DA9052_SET_STROBING_MODE_AUTO 0x0008 Please explain what you want to do. FYI: this is how the code looks now: + case WDIOC_SETOPTIONS: + if (get_user(new_value, p)) + return -EFAULT; + if (new_value == DA9052_ENABLE || new_value == DA9052_DISABLE) + da9052_sm_set_strobing_filter(wdt, new_value); + else + wdt-pwdt-sm_strobe_mode_flag = new_value; + return 0; Since the code is still not in line with the watchdog API and since I did not get an answer yet on what you (or Dajun) want to do, there is definitely NO ACK yet. If there is a good reasoning behind your needs, we might conclude that this is indeed worthwhile and extend the API in a proper way. But as it is now, it's not correct. Kind regards, Wim. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 2011-07-14 at 14:43 -0500, Scott Wood wrote: You need to use lmb_reserve() to exclude any memory regions that are not suitable for boot images -- see powerpc's arch_lmb_reserve() and get_effective_memsize()/CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE. If one excludes HIGHMEM from the area u-boot is allowed to relocate the fdt/initrd to, then it will put it at the end of the 3/4GB boundary (can one exclude all memory above the kernel start address?). This splits memory into three, instead of two regions in the kernel. I don't think that split ever goes away. Then there's the additional region we already have to create for the Ducati memory. That's at least five memory regions total. There are only eight regions currently allowed by default. I don't have a feel for the implications of this, but it seems unnecessary. Again, I don't think the problem is where u-boot relocates this data TOO, but the fact that the new default is to relocate it at all. Is there a reason for relocating this stuff? The initrd always used to be happy left where it was. -dl ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 2011-07-14 at 15:21 -0500, Scott Wood wrote: You have memory below where the kernel is loaded? Our boot script loads the kernel 2MB into physical RAM. It loads the initrd and fdt from the same NAND flash file system into RAM below that. When we boot without specifying an FDT, u-boot does not relocate the initrd. When we specify an FDT address in RAM, u-boot relocates both. We do not need that relocation (in this case at least). This splits memory into three, instead of two regions in the kernel. I don't think that split ever goes away. Then there's the additional region we already have to create for the Ducati memory. That's at least five memory regions total. There are only eight regions currently allowed by default. I don't have a feel for the implications of this, but it seems unnecessary. What do you mean by a region here, and why can there only be eight of them? Functionally identical and contiguous sections of RAM recorded in the Linux global meminfo data structure, and (mostly) operated on in code found in arch/arm/mm/. There's a define that sets the size of this array to 8. Again, I don't know the implications, if any, of having several versus a couple of these banks/regions. It just seems a bad idea to create more holes in the middle of physical RAM unless we really have to. Plus, we have to inform the kernel about them somehow. I don't have a clear idea how we would do that in a clean way. Seems to me it'd be uglier than the fdt_high approach. Maybe I'm missing something though. I'm certainly not a VM expert. Again, I don't think the problem is where u-boot relocates this data TOO, but the fact that the new default is to relocate it at all. Is there a reason for relocating this stuff? The initrd always used to be happy left where it was. The user specified address might be in flash. But in our case it is not. And we're now being relocated when we did not get relocated prior to FDT functionality. -dl ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
0xbench clone causing all Android builds to fail
Working on it... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, Jul 14, 2011 at 03:12:25PM -0400, David Long wrote: On Fri, 2011-07-15 at 03:50 +0900, Grant Likely wrote: Regardless of this patch, the pandaboard uboot still needs to be fixed. Setting an fdt_high variable is useful for debug, but it is not a fix. Then someone needs to own the issue of stopping the current u-boot default behavior of relocating the initrd and fdt to the end of RAM when an fdt is present. This is an issue for any Linux ARM system with more than 3/4GB of RAM, and probably for other 32-bit architectures. The logic that causes the problem is in architecture-independent code, and I'm not sure I'm necessarily the right guy to go rummaging around in there. There are too many implications for any other currently supported targets that use u-boot and fdt. You should have everything you need to fix it. If CONFIG_SYS_BOOTMAPSZ is defined, then U-Boot will not use memory larger that that for the dtb or atags. Right now CONFIG_SYS_BOOTMAPSZ is not set by default, but we could default it to a sane value for ARM platforms. A better solution in the long term may be to figure out the actual memory footprint required, and not make things any larger than that, but that requires U-Boot to be given more data about the kernel, or the zImage wrapper to be more intelligent about dtb and initrd ranges when uncompressing g. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 2011-07-14 at 20:53 -0600, Grant Likely wrote: You should have everything you need to fix it. If CONFIG_SYS_BOOTMAPSZ is defined, then U-Boot will not use memory larger that that for the dtb or atags. Right now CONFIG_SYS_BOOTMAPSZ is not set by default, but we could default it to a sane value for ARM platforms. Which makes more sense, setting this or Scott's suggestion of reserving highmem to prevent it's use as is done in the powerpc's arch_lmb_reserve()? The latter would affect all ARM. Wouldn't BOOTMAP need to be set in each boards config file? On Thu, 2011-07-14 at 16:51 -0500, Scott Wood wrote: Well, that does sound strange. I'd think it would be based on whether you define CONFIG_SYS_BOOT_RAMDISK_HIGH, and whether initrd_high is set to 0x. Same kernel, same u-boot, and initrd_high not set at all. This is the crux of the problem. The default changes when any FDT is provided. I think the difference may come from bootm_linux_fdt(). Rereading your earlier mail and looking at the code, we should probably do as you suggest and add logic to arch_lmb_reserve() to reserve highmem like powerpc does. I think the fdt_high patch is still a good idea though. It allows us to continue booting using lowest memory for the initrd and other startup data. Or were you just not telling bootm about the ramdisk before, and letting the kernel know about the address through some other means? We always provide a ramdisk address to bootm. The problem occurs when we add an FDT address. So add a mechanism for the user to override if you can justify a use for it, but the default should be allocated from an lmb that has had unusable addresses excluded. Well, I do find it troubling I'm having to go to so much trouble to convince u-boot to continue to use this data directly from where we put it in the first place. The user specified address might be in flash. But in our case it is not. It still needs to be supported. I can appreciate that, but the default behavior has changed. It's surprising. For the moment it breaks things (granted that it breaks only if you use the fdt feature). -dl ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/1] Add ARM cpu topology definition
On Tue, 2011-07-12 at 18:23 +0300, Amit Kucheria wrote: From: Vincent Guittot vincent.guit...@linaro.org (Patch accepted by Russell for 3.1: http://www.spinics.net/lists/arm-kernel/msg131273.html) The affinity between ARM processors is defined in the MPIDR register. We can identify which processors are in the same cluster, and which ones have performance interdependency. We can define the cpu topology of ARM platform, that is then used by sched_mc and sched_smt. The default state of sched_mc and sched_smt config is disable. When enabled, the behavior of the scheduler can be modified with sched_mc_power_savings and sched_smt_power_savings sysfs interfaces. Changes since v4 : * Remove unnecessary parentheses and blank lines Changes since v3 : * Update the format of printk message * Remove blank line Changes since v2 : * Update the commit message and some comments Changes since v1 : * Update the commit message * Add read_cpuid_mpidr in arch/arm/include/asm/cputype.h * Modify header of arch/arm/kernel/topology.c * Modify tests and manipulation of MPIDR's bitfields * Modify the place and dependancy of the config * Modify Noop functions Signed-off-by: Vincent Guittot vincent.guit...@linaro.org Reviewed-by: Amit Kucheria amit.kuche...@linaro.org Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com Don't have much feedback on the patch, but it applies and boots fine against the android-3.0 branch. I'll be happy to merge it once it lands in Nico's tree. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
