Re: [PATCH] auxdisplay: img-ascii-lcd: fix maybe-uninitialized warning
On Thu, Dec 7, 2017 at 9:16 AM, Xiongfeng Wang
wrote:
> gcc prints the following warning:
> drivers/auxdisplay/img-ascii-lcd.c: In function ‘malta_update’:
> drivers/auxdisplay/img-ascii-lcd.c:109: warning: ‘err’ may be usedun
> initialized in this function
> drivers/auxdisplay/img-ascii-lcd.c: In function ‘sead3_update’:
> drivers/auxdisplay/img-ascii-lcd.c:207: warning: ‘err’ may be used
> uninitialized in this function
>
> When ctx->cfg->num_chars is zero, there will be a false error info
> printed. Fix this by recontruct the code and initializing the variable
> 'err' to zero.
>
> Signed-off-by: Xiongfeng Wang
I wonder how you ran into this. I'm not seeing that warning on my machine,
and I thought I had fixed all '-Wmaybe-uninitialized' warnings. Before you
send it to the maintainer, I'd try to figure out what the difference is between
our setups.
Do you get other -Wmaybe-uninitialized warnings in the same build, or is this
the only one?
> drivers/auxdisplay/img-ascii-lcd.c | 23 +++
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/auxdisplay/img-ascii-lcd.c
> b/drivers/auxdisplay/img-ascii-lcd.c
> index db040b3..15048c1 100644
> --- a/drivers/auxdisplay/img-ascii-lcd.c
> +++ b/drivers/auxdisplay/img-ascii-lcd.c
> @@ -102,12 +102,11 @@ static void malta_update(struct img_ascii_lcd_ctx *ctx)
> for (i = 0; i < ctx->cfg->num_chars; i++) {
> err = regmap_write(ctx->regmap,
>ctx->offset + (i * 8), ctx->curr[i]);
> - if (err)
> - break;
> + if (err) {
> + pr_err_ratelimited("Failed to update LCD display:
> %d\n", err);
> + return;
> + }
> }
> -
> - if (unlikely(err))
> - pr_err_ratelimited("Failed to update LCD display: %d\n", err);
> }
This part looks good.
> static struct img_ascii_lcd_config malta_config = {
> @@ -180,32 +179,32 @@ static int sead3_wait_lcd_idle(struct img_ascii_lcd_ctx
> *ctx)
> static void sead3_update(struct img_ascii_lcd_ctx *ctx)
> {
> unsigned int i;
> - int err;
> + int err = 0;
>
> for (i = 0; i < ctx->cfg->num_chars; i++) {
> err = sead3_wait_lcd_idle(ctx);
> if (err)
> - break;
> + goto out_err;
>
> err = regmap_write(ctx->regmap,
>ctx->offset + SEAD3_REG_LCD_CTRL,
>SEAD3_REG_LCD_CTRL_SETDRAM | i);
> if (err)
> - break;
> + goto out_err;
>
> err = sead3_wait_lcd_idle(ctx);
> if (err)
> - break;
> + goto out_err;
>
> err = regmap_write(ctx->regmap,
>ctx->offset + SEAD3_REG_LCD_DATA,
>ctx->curr[i]);
> if (err)
> - break;
> + goto out_err;
> }
>
> - if (unlikely(err))
> - pr_err_ratelimited("Failed to update LCD display: %d\n", err);
> +out_err:
> + pr_err_ratelimited("Failed to update LCD display: %d\n", err);
> }
I think you forgot a 'return' statement befor ethe label here.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: JITs and 52-bit VA
On Thursday 28 April 2016 16:00:22 Maxim Kuvyrkov wrote: > This is a summary of discussions we had on IRC between kernel and toolchain > engineers regarding support for JITs and 52-bit virtual address space (mostly > in the context of LuaJIT, but this concerns other JITs too). > > The summary is that we need to consider ways of reducing the size of VA for a > given process or container on a Linux system. > > The high-level problem is that JITs tend to use upper bits of addresses to > encode various pieces of data, and that the number of available bits is > shrinking due to VA size increasing. With the usual 42-bit VA (which is what > most JITs assume) they have 22 bits to encode various performance-critical > data. With 48-bit VA (e.g., ThunderX world) things start to get complicated, > and JITs need to be non-trivially patched at the source level to continue > working with less bits available for their performance-critical storage. > With upcoming 52-bit VA things might get dire enough for some JITs to declare > such configurations unsupported. > > On the other hand, most JITs are not expected to requires terabytes of RAM > and huge VA for their applications. Most JIT applications will happily live > in 42-bit world with mere 4 terabytes of RAM that it provides. Therefore, > what JITs need in the modern world is a way to make mmap() return addresses > below a certain threshold, and error out with ENOMEM when "lower" memory is > exhausted. This is very similar to ADDR_LIMIT_32BIT personality, but > extended to common VA sizes on 64-bit systems: 39-bit, 42-bit, 48-bit, > 52-bit, etc. > > Since we do not want to penalize the whole system (using an artificially > low-size VA), it would be best to have a way to enable VA limit on > per-process basis (similar to ADDR_LIMIT_32BIT personality). If that's not > possible -- then on per-container / cgroup basis. If that's not possible -- > then on system level (similar to vm.mmap_min_addr, but from the other end). > > Dear kernel people, what can be done to address the JITs need to reduce > effective VA size? > Thanks for the summary, now it all makes much more sense. One simple (from the kernel's perspective, not from the JIT) approach might be to always use MAP_FIXED whenever an allocation is made for memory that needs these special pointers, and then manage the available address space explicitly. Would that work, or do you require everything including the binary itself to be below the address? Regarding which memory sizes are needed, my impression from your explanation is that a single personality flag (e.g. ADDR_LIMIT_42BIT) would be sufficient for the usecase, and you don't actually need to tie this to the architecture-provided virtual addressing limits at all. If it's only one such flag, we can probably find a way to fit it into the personality flags, though ironically we are actually running out of bits in there as well. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANN] patches.linaro.org upgrade
On Tuesday 09 February 2016 12:28:06 Andy Doan wrote: > tldr; patches.linaro.org will be upgraded tomorrow, Wednesday the 9th > around 16:00UTC. > Hi Andy, I just stumbled over some broken links when looking up old patches in the archive. Specifically, this link https://patches.linaro.org/57380/ was supposed to take me to an older patch I have to revisit, but I get a 404 error. Is this expected? Any chance to redirect the old links to a static archive of the original contents? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Didn't see EBS with FlashBench
On Sunday 31 January 2016 04:09:36 Constantine wrote: > Hello, I couldn't figure out the Erase Block Size of my `Apacer Technology, > Inc. Handy Steno 2.0/HT203` flash stick. > > As I understand, I have to run test as 1024 multiplied by factor of the stick > capacity, is it? So, I ran tests with different blocksizes > http://pastebin.com/Zb00RjfM > > Alas, I didn't see anything resembling EBS ☹ I could suppose it is either of > 16384, 24576, 57344, but searching over the Internet shows that EBS never > appears that low. Any ideas? The erase block sizes have constantly grown in the past, and so have the page sizes. It's possible that this device does not have the classic fixed erase block mapping, but does something else. My guess is that 24576 is the page size, based on the numbers, so you could try using that as the --blocksize= argument and see if you get any more useful numbers out. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Old releases have been archived
On Friday 30 October 2015 17:27:42 Koen Kooi wrote: > On 30 October 2015 at 15:33, Arnd Bergmann wrote: > > On Monday 26 October 2015 10:24:54 Koen Kooi wrote: > >> The first reports of things breaking are tricking in, OpenWRT > >> apparently uses binutils-linaro 13.05 and Fathi mentioned that various > >> LAVA health checks are failing now. If you encounter such an issue, > >> add the 'archive/' bit to the URL, e.g. > >> > > > > Is this old OpenWRT or current trunk? The current code should > > obviously be updated, but it might be better to not break the > > latest official release. > > I have no idea, someone showed up on IRC and said openWRT needed it. > That's all the info I have. I've checked it at http://git.openwrt.org/?p=14.07/openwrt.git;a=blob;f=toolchain/binutils/Makefile The latest release is 15.05, which uses binutils-linaro-2.24.0-2014.09, so that should be fine. The previous release was 14.07 and that used binutils-linaro-2.24-2013.12. Since this is the newest binutils-linaro version that got moved, it would be nice to restore it at the old path and make the cutoff at 2013.11 rather than 2013.12. All older releases of OpenWRT (12.09 and earlier) do not use binutils-linaro and are not affected. I'm guessing that the user that reported the problem was using an outdated snapshot and we don't need to worry about that. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Old releases have been archived
On Monday 26 October 2015 10:24:54 Koen Kooi wrote: > The first reports of things breaking are tricking in, OpenWRT > apparently uses binutils-linaro 13.05 and Fathi mentioned that various > LAVA health checks are failing now. If you encounter such an issue, > add the 'archive/' bit to the URL, e.g. > Is this old OpenWRT or current trunk? The current code should obviously be updated, but it might be better to not break the latest official release. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-dev
Re: issue compiling topic-leg-uefi kernel with UEFI-stub
On Thursday 11 December 2014 19:27:03 Varad Gautam wrote: > I'm getting > > arch/arm/kernel/efi_phys.S: Assembler messages: > arch/arm/kernel/efi_phys.S:42: Error: selected processor does not > support ARM mode `isb' > arch/arm/kernel/efi_phys.S:50: Error: selected processor does not > support ARM mode `isb' > make[1]: *** [arch/arm/kernel/efi_phys.o] Error 1 > > when compiling the topic-leg-uefi kernel [1] with EFI_STUB support for > omap2plus_defconfig (to run on a BeagleBone Black with AM335x SoC). I've > checked that armv7 supports `isb`, and I've tried the kernel.org > 4.6.3-nolibc toolchain [2] and the Linaro gcc-arm-none-eabi-4.8 release. > The build goes fine without EFI support. I need some help figuring out > what's wrong. > The code should be changed to use the instr_sync macro instead of using the isb instruction directly. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Build LSK 3.14 kernel with android-toolchain
On Tuesday 02 December 2014 20:34:59 Shawn Guo wrote: > On Tue, Dec 02, 2014 at 06:29:52PM +0800, Jisheng Zhang wrote: > > On Tue, 2 Dec 2014 02:24:03 -0800 > > Arnd Bergmann wrote: > > > Yes, that's definitely possible. Any idea how the android folks build > > > their > > > kernel? > > > > copied from https://android.googlesource.com/toolchain/build/+/HEAD/README > > > > The Android toolchain supports the following targets: > >a. arm-linux-androideabi > >b. arm-eabi (for Android kernel) > >c. arm-newlib-eabi (for runnng gcc regression tests) > >d. i[3456]86-*-linux-gnu, x86_64-*-linux-gnu (for x86 targets) > > > > So they build android kernel using the arm-eabi- toolchain. > > Thanks Jisheng for all the information. > > Yes, I just built my kernel with arm-eabi in > android-toolchain-eabi-4.9-2014.09 > and it works fine. So we basically conclude that we should build kernel > with arm-eabi rather than arm-linux-androideabi. > > One thing to note - with CONFIG_ARM_UNWIND turned on, even arm-eabi > generate the following warning. This is one difference between android > arm-eabi and arm-linux-gnueabi we can see immediately. > > LD vmlinux > arm-eabi-ld: warning: unwinding may not work because EXIDX input section 31 > of fs/built-in.o is not in EXIDX output section > arm-eabi-ld: warning: unwinding may not work because EXIDX input section 12 > of crypto/built-in.o is not in EXIDX output section > arm-eabi-ld: warning: unwinding may not work because EXIDX input section 27 > of block/built-in.o is not in EXIDX output section > arm-eabi-ld: warning: unwinding may not work because EXIDX input section 27 > of drivers/built-in.o is not in EXIDX output section > arm-eabi-ld: warning: unwinding may not work because EXIDX input section 33 > of net/built-in.o is not in EXIDX output section I looked into this before, I think this is a gold specific warning about an actual kernel bug, but I haven't been able to track it down. It certainly happens with my regular toolchain and gold as well. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Build LSK 3.14 kernel with android-toolchain
On Tuesday 02 December 2014 18:29:52 Jisheng Zhang wrote: > On Tue, 2 Dec 2014 02:24:03 -0800 > > On Tuesday 02 December 2014 17:39:21 Jisheng Zhang wrote: > > > > > > From my experience in last several years > > > > > > 1. the arm-linux-androideabi- toolchain sets some options by default, PIC > > > for example, even -mno-android can't disable all the side effects per my > > > test. > > > > Yes, that's definitely possible. Any idea how the android folks build their > > kernel? > > copied from https://android.googlesource.com/toolchain/build/+/HEAD/README > > The Android toolchain supports the following targets: >a. arm-linux-androideabi >b. arm-eabi (for Android kernel) >c. arm-newlib-eabi (for runnng gcc regression tests) >d. i[3456]86-*-linux-gnu, x86_64-*-linux-gnu (for x86 targets) > > So they build android kernel using the arm-eabi- toolchain. Interesting, I think that's not supported at all, as the ABI is slightly incompatible between arm-eabi and arm-linux-gnueabi, in particular the short-enums that are used only in arm-eabi. I have a patch somewhere that errors out if someone attempts to build the kernel with an arm-eabi toolchain, I should probably submit that upstream. The Android folks will likely just revert it, but it would catch everyone that tries to build a normal kernel in the Android way. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Build LSK 3.14 kernel with android-toolchain
On Tuesday 02 December 2014 17:39:21 Jisheng Zhang wrote:
>
> On Tue, 2 Dec 2014 01:04:54 -0800
> Shawn Guo wrote:
>
> > + LAKML and more people.
> >
> > On Mon, Dec 01, 2014 at 05:38:38PM +0100, Arnd Bergmann wrote:
> > > On Monday 01 December 2014 16:32:21 Shawn Guo wrote:
> > > > Is it a valid or supported use case to build LSK 3.14 kernel with
> > > > android-toolchain? I can build a LSK 3.14 kernel with Linux toolchain
> > > > gcc-linaro-arm-none-eabi-4.9-2014.09, which boots fine on my board.
> > > > When I build the same kernel with
> > > > android-toolchain-eabi-4.9-2014.09-x86, the kernel can be built out
> > > > successfully, but it fails to boot on the board at very early stage
> > > > with only uncompressing message shown up like below.
> > > >
> > > > Uncompressing Linux... done, booting the kernel.
> > > >
> > > > And it's not a LSK 3.14 specific problem, I tried to build mainline
> > > > 3.10, 3.14 and 3.18-rc4 with the android-toolchain, and they all
> > > > failed to boot.
> > > >
> > > > I need some help to understand if it's a valid use case at all, before
> > > > I try to looking into the problem.
> > >
> > > I would expect it to work, it's probably a good idea to find out
> > > why it doesn't. For all I know 'arm-none-eabi' is actually /not/
> > > supported for building the kernel, since that doesn't use the Linux
> > > Linux variant of eabi, while 'arm-*-linux-gnueabi' or
> > > 'arm-*-linux-gnueabihf' is the default for Linux these days and
> > > 'arm-*-linux-android' should be compatible with that.
> >
> > Okay. Thanks for the info. It seems that I should download
> > gcc-linaro-arm-linux-gnueabihf-4.9-2014.09 for comparison testing then.
> > Actually, in the very first testing I used arm-linux-gnueabi-gcc 4.7.3
> > shipped with Ubuntu 14.04.
> >
> > > What is the
> > > exact target triplet you use in those two cases?
> >
> > They are arm-none-eabi and arm-linux-androideabi. And I also replaced
> > the first toolchain with arm-linux-gnueabi one, and got the same result.
Ok, so they are really all different.
> > >
> > > A few things you could try:
> > >
> > > - boot it in qemu using the vexpress or virt platform code, see if
> > > the symptom is the same. If it is, attach gdb to the qemu gdbstub
> > > to look at the contents of the _log_buf.
> > >
> > > - Maybe debug_ll crashes, try disabling that
> > >
> > > - Maybe debug_ll is disabled already, try enabling it to see if you
> > > get more output.
> >
> > I tracked it a little bit with debug_ll routine printch() and found it
> > dies at the first pr_info() call in arch/arm/kernel/setup.c:
> >
> > pr_info("Booting Linux on physical CPU 0x%x\n", mpidr);
> >
> > And I spent some time to find out that the issue was introduced by
> > commit dad5451a322b (ARM: 7605/1: vmlinux.lds: Move .notes section
> > next to the rodata) since v3.8 release. Reverting the commit helps me
> > to get a booting kernel that is built by arm-linux-androideabi
> > toolchain. But I do not have the knowledge to understand what is
> > happening.
> >
>
> From my experience in last several years
>
> 1. the arm-linux-androideabi- toolchain sets some options by default, PIC for
> example, even -mno-android can't disable all the side effects per my test.
Yes, that's definitely possible. Any idea how the android folks build their
kernel?
> 2. the arm-linux-eandroideabi- toolchain use gold for linker by default. Maybe
> gold can't understand vmlinux.lds correctly?
That would be very easy to test, just set LD=${CROSS_COMPILE}ld.bfd on the
command line and rebuild. In my testing, I've encountered a number of different
bugs in both ld.bfd and ld.gold that prevent you from building the kernel.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Build LSK 3.14 kernel with android-toolchain
On Monday 01 December 2014 16:32:21 Shawn Guo wrote: > Is it a valid or supported use case to build LSK 3.14 kernel with > android-toolchain? I can build a LSK 3.14 kernel with Linux toolchain > gcc-linaro-arm-none-eabi-4.9-2014.09, which boots fine on my board. > When I build the same kernel with > android-toolchain-eabi-4.9-2014.09-x86, the kernel can be built out > successfully, but it fails to boot on the board at very early stage > with only uncompressing message shown up like below. > > Uncompressing Linux... done, booting the kernel. > > And it's not a LSK 3.14 specific problem, I tried to build mainline > 3.10, 3.14 and 3.18-rc4 with the android-toolchain, and they all > failed to boot. > > I need some help to understand if it's a valid use case at all, before > I try to looking into the problem. I would expect it to work, it's probably a good idea to find out why it doesn't. For all I know 'arm-none-eabi' is actually /not/ supported for building the kernel, since that doesn't use the Linux Linux variant of eabi, while 'arm-*-linux-gnueabi' or 'arm-*-linux-gnueabihf' is the default for Linux these days and 'arm-*-linux-android' should be compatible with that. What is the exact target triplet you use in those two cases? A few things you could try: - boot it in qemu using the vexpress or virt platform code, see if the symptom is the same. If it is, attach gdb to the qemu gdbstub to look at the contents of the _log_buf. - Maybe debug_ll crashes, try disabling that - Maybe debug_ll is disabled already, try enabling it to see if you get more output. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [rt-app 2/3] add get/setattr for __aarch64__
On Monday 03 November 2014 14:48:56 Ivan T. Ivanov wrote: > > On Mon, 2014-11-03 at 13:08 +0100, Vincent Guittot wrote: > > On 3 November 2014 12:32, Arnd Bergmann wrote: > > > On Monday 03 November 2014 12:06:06 Vincent Guittot wrote: > > > > On 24 October 2014 16:45, Ivan T. Ivanov wrote: > > > > > --- > > > > > libdl/dl_syscalls.h | 5 + > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > diff --git a/libdl/dl_syscalls.h b/libdl/dl_syscalls.h > > > > > index 8d70056..85dc1e9 100644 > > > > > --- a/libdl/dl_syscalls.h > > > > > +++ b/libdl/dl_syscalls.h > > > > > @@ -39,6 +39,11 @@ > > > > > #define __NR_sched_getattr 381 > > > > > #endif > > > > > > > > > > +#ifdef __aarch64__ > > > > > +#define __NR_sched_setattr 380 > > > > > +#define __NR_sched_getattr 381 > > > > > +#endif > > > > > > > > Hi Ivan, > > > > > > > > we have same values for __arm__, can't we merge both declaration on one > > > > ? > > > > > > > > > > arm64 uses 274 and 275 instead of 380 and 381. > > Probably I have been mistaken by arch/arm64/include/asm/unistd32.h > which uses same numbers like arm. Yes, this defines the numbers that arm64 emulates when running arm32 binaries. > > > Why can't libdl just include asm/unistd.h to get the numbers for the > > > architecture it's compiling for? > > > > you're right, it should. > > Just for my clarification. We are talking about headers installed by > linux kernel or provided by compiler tool chain? I am unable to find > above syscall numbers in gcc-linaro-arm-linux-gnueabihf-4.9-2014.09, > for example. On my system, this header is provided by the linux-libc-dev-arm64-cross package and installed to /usr/aarch64-linux-gnu/include/asm/unistd.h. This package contains the headers from the kernel that are required for building a toolchain. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [rt-app 2/3] add get/setattr for __aarch64__
On Monday 03 November 2014 12:06:06 Vincent Guittot wrote: > On 24 October 2014 16:45, Ivan T. Ivanov wrote: > > --- > > libdl/dl_syscalls.h | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/libdl/dl_syscalls.h b/libdl/dl_syscalls.h > > index 8d70056..85dc1e9 100644 > > --- a/libdl/dl_syscalls.h > > +++ b/libdl/dl_syscalls.h > > @@ -39,6 +39,11 @@ > > #define __NR_sched_getattr 381 > > #endif > > > > +#ifdef __aarch64__ > > +#define __NR_sched_setattr 380 > > +#define __NR_sched_getattr 381 > > +#endif > > Hi Ivan, > > we have same values for __arm__, can't we merge both declaration on one ? > arm64 uses 274 and 275 instead of 380 and 381. Why can't libdl just include asm/unistd.h to get the numbers for the architecture it's compiling for? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 32bit binaries on 64-bit linux
On Wednesday 29 January 2014 17:40:54 Wookey wrote: > +++ Arnd Bergmann [2014-01-29 18:14 +0100]: > > On Wednesday 29 January 2014 16:36:49 Wookey wrote: > > > Running 32-bit binaries is quite seriously broken until this is fixed. I > > > presume this currently isn't on anyone's list to fix? I'm not sure who's > > > list it should go on. > > > > Are you running with 4KB or 64KB page size in the kernel? IIRC you > > cannot really run 32-bit binaries with 64KB page size because of > > related issues. > > I'm not sure. The kernel config has: > CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y > # CONFIG_ARM64_64K_PAGES is not set > CONFIG_PAGEFLAGS_EXTENDED=y > # CONFIG_TRANSPARENT_HUGEPAGE is not set > > Is that using 64K pages or not? This is 4K pages, so I was on the wrong track here. > Is there a dynamic switch I can twiddle or does it need a kernel rebuild? If you turn on CONFIG_ARM64_64K_PAGES, you probably won't be able to load any 32-bit executables any more, or more will fail. Also, I guess vm.mmap_min_addr becomes settable only in 64K increments, which would not be helpful for you. I also found this setting in the kernel: config DEFAULT_MMAP_MIN_ADDR int "Low address space to protect from user allocation" depends on MMU default 4096 help This is the portion of low virtual memory which should be protected from userspace allocation. Keeping a user from writing to low pages can help reduce the impact of kernel NULL pointer bugs. For most ia64, ppc64 and x86 users with lots of address space a value of 65536 is reasonable and should cause no problems. On arm and other archs it should not be higher than 32768. Programs which use vm86 functionality or have some need to map this low address space will need CAP_SYS_RAWIO or disable this protection by setting the value to 0. This value can be changed after boot using the /proc/sys/vm/mmap_min_addr tunable. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 32bit binaries on 64-bit linux
On Wednesday 29 January 2014 16:36:49 Wookey wrote: > Running 32-bit binaries is quite seriously broken until this is fixed. I > presume this currently isn't on anyone's list to fix? I'm not sure who's > list it should go on. Are you running with 4KB or 64KB page size in the kernel? IIRC you cannot really run 32-bit binaries with 64KB page size because of related issues. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Back from parental leave
Happy New Year everyone! I'm starting to resume my regular work schedule in Linaro and as the arm-soc co-maintainer now, after five months of parental leave and a bit of vacation. I have started following the mailing lists and replying to more work email a couple of weeks ago, but today is the first day that I'm planning to actually spend entirely on getting set up for productive work myself again. Many thanks to Kevin, Linus and everyone else who has been stepping in for me in the meantime! As Deepak Saxena is now on on leave, I will be taking over some of his work until he returns, and I also need to catch up with what has been going on. I have added a number of people on Cc that I'd like to talk to at some point. I don't yet have any scheduled meetings, so if you'd like to catch up, please just find me on IRC at a time that is convenient for you, I'd be happy to call you back on the phone or just talk on IRC. I should be available most days between 9:00 and 16:00 UTC. I have not yet looked at the current contents of the arm-soc tree, I guess I will have a chat with Olof and Kevin first and then get back into merging and testing branches. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC][PATCH 7/7] USB: OHCI: make ohci-s3c2410 a separate driver
On Friday 07 June 2013 11:33:33 Manjunath Goudar wrote: > > + ohci_setup(hcd); > s3c2410_start_hc(dev, hcd); > > - ohci_hcd_init(hcd_to_ohci(hcd)); > - I'm not sure about this part: s3c2410_start_hc is where the clock gets enabled, presumable we are not supposed to touch the ohci registers before it gets called, so ohci_init() being called implicitly by ohci_setup() seems like a bad idea. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC][PATCH 3/7] USB: OHCI: make ohci-omap3 a separate driver
On Friday 07 June 2013 11:33:29 Manjunath Goudar wrote: > + /* > + * RemoteWakeupConnected has to be set explicitly before > + * calling ohci_run. The reset value of RWC is 0. > + */ Just nitpicking, but you still use the wrong commenting style occasionally. The '*' characters should always be aligned vertically, like /* * RemoteWakeupConnected has to be set explicitly before * calling ohci_run. The reset value of RWC is 0. */ Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC][PATCH 1/7] USB: OHCI: make ohci-exynos a separate driver
On Friday 07 June 2013 11:33:27 Manjunath Goudar wrote:
>
> #if!IS_ENABLED(CONFIG_USB_OHCI_HCD_PCI) && \
> !IS_ENABLED(CONFIG_USB_OHCI_HCD_PLATFORM) && \
> + !IS_ENABLED(CONFIG_USB_OHCI_EXYNOS) && \
> !defined(PLATFORM_DRIVER) &&\
> !defined(OMAP1_PLATFORM_DRIVER) && \
> !defined(OMAP3_PLATFORM_DRIVER) && \
> @@ -1269,7 +1265,6 @@ MODULE_LICENSE ("GPL");
> !defined(SM501_OHCI_DRIVER) && \
> !defined(TMIO_OHCI_DRIVER) && \
> !defined(S3C2410_PLATFORM_DRIVER) && \
> - !defined(EXYNOS_PLATFORM_DRIVER) && \
> !defined(EP93XX_PLATFORM_DRIVER) && \
> !defined(AT91_PLATFORM_DRIVER) && \
> !defined(NXP_PLATFORM_DRIVER) && \
Hi Manjunath,
please note that Greg just merged my patch to remove this entire list and
the #error statement. The next time you rebase your patch, you will have
to remove this hunk in each of your patches.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On Friday 31 May 2013 10:12:38 Alan Stern wrote: > On Thu, 30 May 2013, Arnd Bergmann wrote: > > > > I'll try to replicate your result. I don't have my USB audio device > > > here today, so it will have to wait until tomorrow. > > > > Strange enough, it seems to be working now, on a different base. > > > > The kernel I tried last (based on yesterday's linux-next) also > > had other issues and was very slow, so it may have been something > > different. > > My test ran successfully, no problems. I guess we can ignore this. Ok, good. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On Wednesday 29 May 2013, Alan Stern wrote: > > On Wed, 29 May 2013, Arnd Bergmann wrote: > > > On Wednesday 29 May 2013 12:21:02 Alan Stern wrote: > > > > > > Those error messages are annoying; they don't use dev_err(), so they > > > don't include the device and driver names. There's no way to know what > > > they refer to. I rather suspect they come from the usbaudio driver. > > > > That makes sense. I have a usb audio device, and I don't actually recall > > getting any sound from my speakers while testing it. I only checked > > that the mouse was working and assumed that the usb-audio was driven > > by ehci, but upon closer inspection, they are both on the same OHCI. > > > > > When you ran this test, did you have commit 815fa7b91761 applied? > > > > Yes. > > > > > Does the same problem occur without Manjunath's changes? > > > > No, it was introduced by the first patch, as I found later. > > I'll try to replicate your result. I don't have my USB audio device > here today, so it will have to wait until tomorrow. Strange enough, it seems to be working now, on a different base. The kernel I tried last (based on yesterday's linux-next) also had other issues and was very slow, so it may have been something different. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On Wednesday 29 May 2013 12:21:02 Alan Stern wrote: > > Those error messages are annoying; they don't use dev_err(), so they > don't include the device and driver names. There's no way to know what > they refer to. I rather suspect they come from the usbaudio driver. That makes sense. I have a usb audio device, and I don't actually recall getting any sound from my speakers while testing it. I only checked that the mouse was working and assumed that the usb-audio was driven by ehci, but upon closer inspection, they are both on the same OHCI. > When you ran this test, did you have commit 815fa7b91761 applied? Yes. > Does the same problem occur without Manjunath's changes? No, it was introduced by the first patch, as I found later. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On Tuesday 28 May 2013, Manjunath Goudar wrote: > This series of patches begins the process of splitting ohci-hcd up into > a core library module and independent pci driver modules. > Seems to basically work now, but I'm getting run-time errors after loading the driver, with patch 1/3 applied: [15916.438452] input: Logitech USB-PS/2 Optical Mouse as /devices/pci:00/:00:12.0/usb3/3-1/3-1:1.0/input/input26 [15916.438584] hid-generic 0003:046D:C050.0017: input,hidraw0: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:12.0-1/input0 [15917.465597] usb 3-3: new full-speed USB device number 3 using ohci-pci [15917.636712] usb 3-3: New USB device found, idVendor=0ccd, idProduct=0077 [15917.636717] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [15917.636721] usb 3-3: Product: USB PnP Sound Device [15917.636724] usb 3-3: Manufacturer: C-Media Electronics Inc. [15917.812827] input: C-Media Electronics Inc. USB PnP Sound Device as /devices/pci:00/:00:12.0/usb3/3-3/3-3:1.3/input/input27 [15917.812919] hid-generic 0003:0CCD:0077.0018: input,hidraw1: USB HID v1.00 Device [C-Media Electronics Inc. USB PnP Sound Device] on usb-:00:12.0-3/input3 [15918.789906] cannot submit urb (err = -18) [15918.790163] cannot submit urb (err = -18) [15918.842095] usb 7-1: new full-speed USB device number 2 using ohci-pci [15919.883135] cannot submit urb (err = -18) [15919.883604] cannot submit urb (err = -18) [15919.883613] cannot submit urb (err = -18) [15919.883616] cannot submit urb (err = -18) [15919.883619] cannot submit urb (err = -18) [15919.883623] cannot submit urb (err = -18) [15919.883626] cannot submit urb (err = -18) [15919.883629] cannot submit urb (err = -18) [15919.883632] cannot submit urb (err = -18) [15919.883639] delay: estimated 354, actual 1 [15919.883644] cannot submit urb (err = -18) [15919.883647] delay: estimated 353, actual 0 [15919.883651] cannot submit urb (err = -18) Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC V7 PATCH 3/3] USB: OHCI: make ohci-pci a separate driver
On Monday 27 May 2013, Manjunath Goudar wrote:
> This patch splits the PCI portion of ohci-hcd out into its
> own separate driver module, called ohci-pci.
>
> The major point of difficulty lies in ohci-pci's many vendor- and
> device-specific workarounds. Some of them have to be applied before
> calling ohci_start() some after, which necessitates a fair amount of
> code motion. The other platform drivers require much smaller changes.
>
> The complete sb800_prefetch() function moved to ohci-q.c,because its
> only related to ohci-pci driver.
I just gave this a little test run in qemu and on my server.
> @@ -446,7 +446,7 @@ config USB_OHCI_HCD_PPC_OF
> default USB_OHCI_HCD_PPC_OF_BE || USB_OHCI_HCD_PPC_OF_LE
>
> config USB_OHCI_HCD_PCI
> - bool "OHCI support for PCI-bus USB controllers"
> + tristate "OHCI support for PCI-bus USB controllers"
> depends on PCI && (STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF)
> default y
> select USB_OHCI_LITTLE_ENDIAN
There is a preexisting bug in this symbol: USB_OHCI_HCD_PCI was previously
unused, and has a bogus 'depends' line, which causes it to not be selectable
on anything but PPC.
You have to change this to only 'depends on PCI'.
> }
> - if (ret == 0) {
> - ohci_hcd_init (ohci);
> - return ohci_init (ohci);
> - }
> - return ret;
> -}
I found that the call to ohci_hcd_init() that is removed here is not getting
added in any other place, which caused a NULL pointer dereference the first
time we actually try to use the driver.
Adding the call back into the new ohci_setup function makes it work again.
Please fold the patch below into your patch, unless Alan discovers something
wrong with it.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f948e8f..eef6dc5 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -454,7 +454,7 @@ config USB_OHCI_HCD_PPC_OF
config USB_OHCI_HCD_PCI
tristate "OHCI support for PCI-bus USB controllers"
- depends on PCI && (STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF)
+ depends on PCI
default y
select USB_OHCI_CORE
select USB_OHCI_LITTLE_ENDIAN
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 3da8c3a..5601139 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -763,6 +763,8 @@ int ohci_setup(struct usb_hcd *hcd)
{
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ ohci_hcd_init(ohci);
+
return ohci_init(ohci);
}
EXPORT_SYMBOL_GPL(ohci_setup);
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index ea088c1..3133354 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -250,7 +250,7 @@ static int ohci_pci_reset (struct usb_hcd *hcd)
}
}
if (ret == 0)
- ohci_setup(hcd);
+ ret = ohci_setup(hcd);
/*
* After ohci setup RWC may not be set for add-in PCI cards.
* This transfers PCI PM wakeup capabilities.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC V6 PATCH 3/3] USB: OHCI: make ohci-pci a separate driver
On Thursday 23 May 2013, Alan Stern wrote: > > > > > > > This section of the driver is gone now since 86510bb248 "USB: OHCI: > > clarify Kconfig dependencies", so the change is no longer needed. > > I don't know what tree you're referring to. That commit is not present > in Greg's usb-linus or usb-next branches. The usb-next branch is what > I use for new development. Sorry, my mistake. I had looked at a temporary tree based on linux-next, and I thought that Greg had applied my patch and put it into usb-next, but instead it's a patch I had sitting on the branch I used for build testing. I have not yet submitted that one again, and I'm sure that Manjunath doesn't have it on his machine, so your comment still applies. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC V6 PATCH 3/3] USB: OHCI: make ohci-pci a separate driver
On Thursday 23 May 2013, Alan Stern wrote: > On Thu, 23 May 2013, Manjunath Goudar wrote: > Also, you left out one thing that should still be here. What happened > to the part about changing > > #if !defined(PCI_DRIVER) && \ > > to > > #if !ENABLED(CONFIG_USB_OHCI_HCD_PCI) &&\ > This section of the driver is gone now since 86510bb248 "USB: OHCI: clarify Kconfig dependencies", so the change is no longer needed. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 2/3] USB: OHCI: Generic changes to make ohci-pci a separate driver
On Thursday 23 May 2013, Manjunath Goudar wrote:
> @@ -1275,7 +1266,7 @@ MODULE_LICENSE ("GPL");
> #define PLATFORM_DRIVERohci_platform_driver
> #endif
>
> -#if!defined(PCI_DRIVER) && \
> +#if!defined(PCI_DRIVER) && \
> !defined(PLATFORM_DRIVER) &&\
> !defined(OMAP1_PLATFORM_DRIVER) && \
> !defined(OMAP3_PLATFORM_DRIVER) && \
This part didn't really belong here, otherwise the patch looks right to me.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.
On Tuesday 16 April 2013, Nishanth Menon wrote:
> On 12:50-20130416, Arnd Bergmann wrote:
> > On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote:
> > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > > index 8d1e2bb..73a99e4 100644
> > > > --- a/include/uapi/drm/drm.h
> > > > +++ b/include/uapi/drm/drm.h
> > > > @@ -36,7 +36,7 @@
> > > > #ifndef _DRM_H_
> > > > #define _DRM_H_
> > > >
> > > > -#if defined(__linux__)
> > > > +#if defined(__KERNEL__) || defined(__linux__)
> > > >
> > > > #include
> > > > #include
> >
> > This is still completely bogus, the __KERNEL__ symbol has no significance
> > here.
> > Either make the compiler define __linux__, or remove this #ifdef completely.
> >
> Searching the v.39-rc7 tag, and greping for _linux_ a few interesting
> list pops up. (pruned):
> arch/arc/Makefile:cflags-y+= -mA7 -fno-common -pipe -fno-builtin
> -D__linux__
> arch/h8300/Makefile:KBUILD_CFLAGS += -D__linux__
> arch/hexagon/Makefile:KBUILD_CFLAGS += -ffixed-$(TIR_NAME)
> -DTHREADINFO_REG=$(TIR_NAME) -D__linux__
> arch/score/Makefile: -D__linux__ -ffunction-sections -ffreestanding
> arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__
> ^^ these architectures seem to bypass the pain entirely by defining
> __linux__
Right, that seems like a reasonable approach when the compilers are actually
known
to be compatible.
> arch/mips/include/uapi/asm/sgidefs.h:#ifndef __linux__
On MIPS, they are not. If you are building a Linux kernel with a gcc that
was targetted at another ABI, the system call interface may change, so they
forbid that here.
> drivers/gpu/drm/radeon/radeon_cp.c:#ifdef __linux__
> {snip}
> drivers/scsi/aic7xxx/aic7770.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aic79xx.h:#ifndef __linux__
> {snip}
> drivers/scsi/aic7xxx/aic79xx_core.c:#ifdef __linux__
> {snip}
> drivers/scsi/aic7xxx/aic79xx_pci.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aic7xxx.h:#ifndef __linux__
> drivers/scsi/aic7xxx/aic7xxx.h:#ifndef __linux__
> drivers/scsi/aic7xxx/aic7xxx_93cx6.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aic7xxx_core.c:#ifdef __linux__
> {snip}
> drivers/scsi/aic7xxx/aic7xxx_pci.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm.h:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm_macro_scan.l:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm_scan.l:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__
> drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__))
> drivers/staging/ced1401/machine.h:#if (defined(__linux__) || defined(_linux)
> || defined(__linux)) && !defined(LINUX)
These are all drivers that are shared with another OS, or used
to be. In most of them, we can probably just remove the
#else path, since I don't think they are getting synchronized
any more.
> include/acpi/platform/acenv.h:#if defined(_LINUX) || defined(__linux__)
The acpi header files are maintained outside of Linux and are kept
OS-independent.
> include/linux/coda.h:#if defined(__linux__)
> include/uapi/drm/drm.h:#if defined(__linux__)
> include/uapi/linux/coda.h:#if defined(__linux__)
> include/uapi/linux/fuse.h:#ifdef __linux__
In case of coda, we should not need to care any more, that header just
got broken by the uapi-split for other operating systems.
The drm.h and fuse.h header files are in theory still kept
OS-agnostic and are actively maintained.
> And then we have the following as well..
> fs/ext4/ext4.h:#if defined(__KERNEL__) || defined(__linux__)
This seems to have been copied from the ext2 utils. The ext2/ext3
versions of this file don't have support for other operating systems.
> Trying out a few different prebuilt compilers I had around, I see:
> http://pastebin.com/bTVDLTb1
>
> So, is our approach just to use __linux__ for builds? I am trying to
> understand rationale behind why #include #include
>
> would want __linux__ and why __KERNEL__ check is un-wanted.
> Ofcourse, I cant comment about the "One of the BSDs" in else options..
> and why we'd like to keep it around in kernel :)
We might be in a similar situation on ARM that we are in on MIPS. For
instance, there are some compilers that are targetting (old) Android
that have a slightly different ABI, and building a kernel with those
results in a system call ABI that is incompatible with user space built
with a standard compiler. The safest approach is probably to bail
out early if __linux__ is not set, and force anyone that wants to use
a strange compiler to set the macro manually.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.
On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote: > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > > index 8d1e2bb..73a99e4 100644 > > --- a/include/uapi/drm/drm.h > > +++ b/include/uapi/drm/drm.h > > @@ -36,7 +36,7 @@ > > #ifndef _DRM_H_ > > #define _DRM_H_ > > > > -#if defined(__linux__) > > +#if defined(__KERNEL__) || defined(__linux__) > > > > #include > > #include This is still completely bogus, the __KERNEL__ symbol has no significance here. Either make the compiler define __linux__, or remove this #ifdef completely. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Optimizing Linux with cheap flash drives
On Monday 31 December 2012, Phillip Norisez wrote: > Hello. > > Are you the Arnd Bergmann that published the article "Optimizing Linux > with cheap flash drives" in lwm.net on February 18, 2011? If so, I > would greatly appreciate it if you could answer a question. Yes, that is me. > My name is Phillip Norisez and I am in the process of putting together > an embedded Linux on a custom-designed board using a TI ARM DM3055 > microprocessor. My question is, is there any updated information > about using SD cards as Linux boot devices, especially as regards both > the incompatibilities your article raises and lifetime expectations? > > This latter is due to the fact that the board will be used as part of a > device which must be usable indefinitely in a third-world environment, > without access to high-tech facilities, but must last longer than the > typical cell phone. There are two important recommendations I have: * The Samsung 32GB Class 10 MB-SSBGA and MB-MSBGA cards are apparently based on an eMMC controller that has much better characteristics when using a nonstandard file system on them. This does not apply to the smaller cards or to any other brands I have seen, and of course it may change in the future. I have not yet tested Samsungs new UHS-1 compatible version of those cards. * The new f2fs file system has been merged into the linux kernel for version 3.8. This should have a *much* better long term reliability for normal cards than any of the existing file systems we have in Linux. It is fairly new, so I would not consider it as stable as the other file systems, but on unreliable SD cards, the end result is probably better, especially if the product you want to ship is going to upgrade to a future kernel version that fixes the bugs that are yet to be found. > You may reply to this e-mail directly if so inclined. If you would > prefer that I post this on a message board, please reply with its URL. For more questions, please use the linaro-dev@lists.linaro.org mailing list but keep me on Cc. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: int64_t definition conflict on Aarch64
On Monday 31 December 2012, Riku Voipio wrote: > It's not good enough - the __u64 and friends are used elsewhere in the > fuse code. However just pulling in linux/types.h as done in out OE > overlay is good enough: > > http://git.linaro.org/gitweb?p=openembedded/meta-aarch64.git;a=blob;f=recipes-support/fuse/files/aarch64.patch > > To not break non-linux platforms, I sent to fuse-devel a slightly > different patch that keeps the defines when not on linux: > > http://sourceforge.net/mailarchive/forum.php?thread_name=CAAqcGH%3D-xM_a%3DR0o4cWoLqh7wKRLbiuHa_qPtrOBT2watYq_HA%40mail.gmail.com&forum_name=fuse-devel > > No response back yet, > The patch basically reverts back to the previous state from a few years ago. I think that is fine, but you seem to be missing the #include statement in the #else path. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: int64_t definition conflict on Aarch64
On Thursday 27 December 2012, Arnd Bergmann wrote: > On Wednesday 19 December 2012, Riku Voipio wrote: > > Hi, > > > > The following code fails to build with OE Aarch64 toolchain with > > current kernel headers. While ugly, the code is a reduced testcase > > from fuse build failure ( > > https://bugs.launchpad.net/linaro-oe/+bug/1087757 ) and the same fuse > > code compiles on all other architectures. Before I send a workaround > > for upstream, I'd like to know how we can end up with different > > definitions for int64_t when that happens on no other architectures - > > something wrong with the generic kernel headers? > > I think the problem here is that user space redefines the __s64 type, > which is already defined by the kernel and is in the reserved namespace. > > In the kernel, most architectures nowadays use "long long" for s64, > while in user space, 64 bit platforms traditionally use "long" for > int64_t, hence the conflict that happens here but not on some other > architectures. Normally these don't conflict, since the "long long" > variant is only used for kernel interfaces. > > I don't know why the fuse header does this, because it's otherwise > a straight copy of include/linux/fuse.h, except that it redefines > the basic integer types. It was this commit that introduced the problem in fuse back in 2008, in combination with the kernel moving to int-ll64.t for 64-bit architectures that are presumably all broken now: fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=blob;f=include/fuse_kernel.h;hb=5f722fa8f6561c964fd0bd651b4602ac0f7bc3b4 On x86, this never showed up, because its bits/sigcontext.h does not include asm/sigcontext.h, which it does on arm64, causing the conflicting __s64 definition to be pulled in through linux/types.h. I think it would be good to change the fuse private header file copy to undefine all the __u64 and related types at the end, which will make new fuse version work with the existing glibc and kernel header files on all architectures. We might also want to look into the situation in arm64 glibc: if this is the only architecture that uses asm/sigcontext.h directly, we could change glibc to have a copy of that rather than including the kernel version, just in case some other user space tool has the same dependency, and to make existing fuse versions build. It's a bit of a hack though. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: int64_t definition conflict on Aarch64
On Wednesday 19 December 2012, Riku Voipio wrote: > Hi, > > The following code fails to build with OE Aarch64 toolchain with > current kernel headers. While ugly, the code is a reduced testcase > from fuse build failure ( > https://bugs.launchpad.net/linaro-oe/+bug/1087757 ) and the same fuse > code compiles on all other architectures. Before I send a workaround > for upstream, I'd like to know how we can end up with different > definitions for int64_t when that happens on no other architectures - > something wrong with the generic kernel headers? I think the problem here is that user space redefines the __s64 type, which is already defined by the kernel and is in the reserved namespace. In the kernel, most architectures nowadays use "long long" for s64, while in user space, 64 bit platforms traditionally use "long" for int64_t, hence the conflict that happens here but not on some other architectures. Normally these don't conflict, since the "long long" variant is only used for kernel interfaces. I don't know why the fuse header does this, because it's otherwise a straight copy of include/linux/fuse.h, except that it redefines the basic integer types. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v5 00/17] Introduce Xen support on ARM (based on 3.6-rc5)
On Monday 17 September 2012, Stefano Stabellini wrote: > I am also attaching to this email the dts'es that I am currently using > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs > and it is appended in binary form to the guest kernel image. I am not > sure where they are supposed to live yet, so I am just attaching them > here so that people can actually try out this series if they want to. You can submit the dts files separately so we can include them in the arm-soc tree. Pawel Moll is handling vexpress related changes these days, so it would be reasonable if he included them in a pull request. > The patch series has been rebased on Konrad's stable/for-linus-3.7 > branch. > > Arnd, Russell, what do you think about this series? If you are OK with > it, to whom should I submit it? I have no objections to your patches from this series. IMHO they should be submitted through the Xen tree, but it would be good to have an Ack from Russell. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Call for linux-linaro / linux-linaro-core-tracking topic updates
On Friday 14 September 2012, Sachin Kamat wrote: > Hi Andrey, > > On 12 September 2012 17:56, Andrey Konovalov > wrote: > > Greetings, > > > > The linux-linaro-core-tracking (llct) tree has been moved to v3.6-rc5 base. > > All the topics existed in the 12.08 version of llct have been carried over > > into the updated tree with few easy to resolve conflicts. The only one which > > needs attention is due to commit "ASoC: Samsung: Fix build error" [1]. In > > fact I had to revert it because it doesn't work with the multiplatform topic > > (the latter renames all the arch/arm/mach-/include/mach dirs to > > arch/arm/mach-/include/mach-). Sachin or Tushar, could you take > > a look please? > > CC'd Arnd. > > present in some Samsung driver files esp. related to > audio haven't been converted to /dma.h> form mainly > because most Samsung mach-* directories have a dma.h file and those > need to be consolidated first. Kukjin's team is working on cleaning > this up. See the below link > > http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/12049 > > With the fix patch reverted, you will get build errors if you enable > pcm. However if you do not intend to enable pcm you may go ahead with > it. Alternatively, you may replace with > for your purpose (stopgap solution). I think we need to discuss whether the multiplatform branch should still be included in the linux-linaro-core-tracking tree. At the ARM mini summit in San Diego, we discussed in length about how we want to get to actual multiplatform kernels, and decided *not* to use my testing/mach-headers branch. We could keep using it for a little longer, but I think eventually we will have do thing differently as upstream moves on, so we might decide to remove it right away. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Implement devicetree support for AB8500 Btemp
On Friday 14 September 2012, Anton Vorontsov wrote:
> Power supply subsystem's supplied_to describes not just how driver
> should notify other devices, supplied_to is more generic stuff, in terms
> that it describes power supply hierarchy. It's like a directed graph,
> e.g.:
>
>supplied_to and
> supplied_to and
>supplied_to
> supplied_to
>supplied_to
>supplied_to
>
> How things interact in linux are just implementations details.
> So, device tree is surely a perfect place to describe these things.
>
> Although, in current bindings I see this:
>
> + ab8500-fg {
> + /* Other enery management module */
> + supplied_to = "ab8500_chargalg", "ab8500_usb";
> + num_supplicants = <2>;
> + };
>
> Instead of addressing supplicants by name, it's better to address
> via phandles. And, of course, num_supplicants is not needed, it can
> be derived.
Right. that's what I thought. The other comment I made initially is
that it would be more in the spirit of the existing bindings to have
the supply property in the opposite directory, if we need it, like
(picking up your above example):
/ {
/* power supply property in the root node is used by default */
power-supply = <&main-battery>, <&backup-battery>;
ac-power: power@... {
...
};
usb-power: power@... {
...
};
main-battery: battery@... {
power-supply = <&ac-power>, <&usb-power};
;
...
};
It's the same information and absolutely equivalent as far as I can tell,
but it feel more logical in the way we tend to describe things.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Implement devicetree support for AB8500 Btemp
On Thursday 13 September 2012, Rajanikanth HV wrote: > On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:> > > > If this is true, I don't understand what makes the 'supplied-to' > > properties you list in the device tree binding board specific. Are > > they not always done the same way? If so, you could just leave them > > out. > Precisely 'supplied-to' is not board specific, it was maintained as > platform_data which i migrated to dt-node. It is meant to establish > dependency across bm drivers based on power_supply property and > runtime battery attributes. > Basically, 'supplied-to' provides a way of exporting change in > power_supply_property and runtime batter characteristics so that other > bm devs shall make use or refer the updated values. > Ref: external_power_changed(...) call back api. > Note: all the bm drivers handles subset of power_supply property and > battery attributes, > ref: include/linux/power_supply.h and get_property(...) call back > api across bm drivers. Ok, so you want to just remove the property from the device tree, or do you want to establish a different method to specify these connections? > > What does indeed seem to be needed is a place to identify the battery > > type, but it's not clear if the btemp device is the best place for > > that (maybe it is). > I am not clear whether you are trying to correlate battery-type with > supplied-to. however, battery type is identified based on the > resistance value measured at batctrl pin which is expected to be in the > allowable limit of ab8500 device. This resistance limit varies across > battery types. This happens in btemp driver. I wasn't correlating them. I just mentioned that unlike the supplied-to property, the battery type property does seem to belong into the device tree. > For this, I would suggest you give a list of > > possible batteries and require a property such as > > > > st-ericsson,battery-type: A string identifier for the type of battery, > >which impacts how an operating system interpret > >the sensor readings. Possible values include: > > * "none"-- no battery connected > > * "li-ion-9100" -- Type 9100 Li-ION battery > > * > Can do this, not precisely as "st-ericsson,battery-type", it will be as > battery-type = [unknown|NiMH|LION|...|]], reason being > allowable battery type is based on technology, as you can see the > possible types as: > POWER_SUPPLY_TECHNOLOGY_UNKNOWN = 0, > POWER_SUPPLY_TECHNOLOGY_NiMH, > POWER_SUPPLY_TECHNOLOGY_LION, > POWER_SUPPLY_TECHNOLOGY_LIPO, > POWER_SUPPLY_TECHNOLOGY_LiFe, > POWER_SUPPLY_TECHNOLOGY_NiCd, > POWER_SUPPLY_TECHNOLOGY_LiMn > Ref: include/linux/power_supply.h > Note: doing this will impact my of_probe(...), may slightly bloat the > code. Ok. If you want to make the battery type a generic property, it's probably best to start a separate binding document for this in Documentation/devicetree/bindings/power-supply/common.txt and document a string for each of these. If we expect the property to be needed only for ab8500, please use a vendor prefix like 'stericsson,'. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Implement devicetree support for AB8500 Btemp
On Wednesday 12 September 2012, Rajanikanth HV wrote:
> On Tuesday 11 September 2012 04:52 PM, Arnd Bergmann wrote:
> > On Tuesday 11 September 2012, Rajanikanth HV wrote:
> Consider: USB charging:
> __
>| |
> --(Vbus)-->| USB Charger with |
>| Charger FSM (h/w) |
>|__|
> ||
> ||(Vbat and other signals)
> | __|_
> to | ||(GaugeSense
> Charger FSM| | LION | Signal) _
> | |Battery |--->|FuelGauge blk|
> | |||{Coulomb Ctr}|
> | |-
> |
> | |
> | | (BatCtrl Signal)
> |___|-->[Btemp blk]
> | |
> [ADC] |__Btemp_Low
> |__Btemp_Med
> |__Btemp_High
>
> Note: Charging algorithm is a logical entity.
>
> and what their purpose is?
> a) Coulomb counter comprises '12bit adc' and an 'N sample
> average/accumulation' logic helps to measure battery capacity
> Note: The charge and the discharge current of the battery is
> converted to voltage by an external resistor connected
> between GaugeSenseP and GaugeSenseN pins.
>
> b) Battery temperature monitoring comprises a comparator which is
>enabled only by HW (charger state machine) helps to measure
>the thermal threshold
> Note: The accuracy of the battery temperature measurement depends
> of the accuracy of the thermistor used.
>
> c) Charger provides 'Constant Current Constant Voltage' USB and
>Main(Wall) Charging support, it embeds: voltage detection,
>thermal protection, Constant voltage charging with programmable level,
>clock dithering and battery voltage monitoring
>
> e.g. Correlation between charger and Btemp
> - if the battery temperature is higher than “MaxTemp °C,
> the charger does not start, but is enabled
>
> - if the battery temperature is between 0°C and “MaxTemp” °C
> charging is done in AB8500 Hardware control mode
>
> - charging is done in DB8500 Software control mode, if the battery:
> has a voltage higher than the “BattOK Threshold
>
> - If the battery temperature is between -10°C and 0°C:
> charging is done in AB8500 Hardware control mode
>
> - If the battery temperature is below -10°C, charging is
> done in AB8500 Hardware control mode
Ok, thanks for the explanation, this is starting to make a lot more
sense. So the three blocks (fb, btemp, charger) are all separate
mfd cells, each with their own register set in ab8500 and a separate
driver in drivers/power, right?
Then there is the ab8500-charalg driver which I guess is implementing
the Charger FSM you mention above, but it doesn't have any registers
in the ab8500 but rather ties the other drivers together.
If this is true, I don't understand what makes the 'supplied-to'
properties you list in the device tree binding board specific. Are
they not always done the same way? If so, you could just leave them
out.
What does indeed seem to be needed is a place to identify the battery
type, but it's not clear if the btemp device is the best place for
that (maybe it is). For this, I would suggest you give a list of
possible batteries and require a property such as
st-ericsson,battery-type: A string identifier for the type of battery,
which impacts how an operating system interpret
the sensor readings. Possible values include:
* "none"-- no battery connected
* "li-ion-9100" -- Type 9100 Li-ION battery
*
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: mfd: Implement devicetree support for AB8500 Btemp
On Tuesday 11 September 2012, Rajanikanth HV wrote: > >> +Supplied-to: > >> + This shall be power supply class dependency where in the > runtime battery > >> + properties will be shared across fuel guage and charging > algorithm driver. > > > > I probably don't understand enough of this, but shouldn't the other > devices > > that are supplied by this have a reference to this node rather than doing > > it this way around? Why use strings here instead of phandles? > > This is a logical binding w.r.t power supply event change > across energy-management-module drivers where in runtime battery > properties are shared along with uevent notification. > ref: di->btemp_psy.external_power_ > changed = > ab8500_btemp_external_power_changed; > ref: ab8500_btemp.c > > Need for this property: > btemp, fg and charger updates power-supply properties > based on the events listed above. > Event handler invokes power supply change notifier > which in-turn invokes registered power supply class call-back > based on the 'supplied_to' string. > ref: >power_supply_changed_work(..) ./drivers/power/power_supply_core.c > > In this case how to approach through phandle? > > Sorry, I really tried, but I cannot make sense of what you wrote there. Can you try again and describe in full English sentences how the hardware blocks are connected and what their purpose is? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] mfd: Implement devicetree support for AB8500 fg
On Monday 10 September 2012, Rajanikanth HV wrote:
> +Required Properties:
> +- compatible = "stericsson,ab8500-fg"
> +
> +supplied-to:
> + This is a logical binding w.r.t power supply event change
> + across energy-management-module drivers where in the
> + runtime battery properties are shared along with uevent
> + notification.
> + ref: di->fg.external_power_changed =
> + ab8500_fg_external_power_changed;
> + ab8500_fg.c
> +
> + Need for this property:
> + btemp, fg and charger updates power-supply properties
> + based on the events listed above.
> + Event handler invokes power supply change notifier
> + which in-turn invokes registered power supply class call-back
> + based on the 'supplied_to' string.
> + ref:
> + power_supply_changed_work(..)
> ./drivers/power/power_supply_core.c
> +
> + example:
> + ab8500-fg {
> + /* Other enery management module */
> + supplied_to = "ab8500_chargalg", "ab8500_usb";
> + num_supplicants = <2>;
> + };
same comments as for the btemp driver.
> diff --git a/drivers/power/ab8500_bmdata.h b/drivers/power/ab8500_bmdata.h
> new file mode 100644
> index 000..748334a
> --- /dev/null
> +++ b/drivers/power/ab8500_bmdata.h
> @@ -0,0 +1,442 @@
> +static struct abx500_res_to_temp temp_tbl_A_thermister[] = {
> + {-5, 53407},
> + { 0, 48594},
> + { 5, 43804},
> + {10, 39188},
> + {15, 34870},
Static variable definitions never belong in a header file. If you want to
share these between multiple drivers, put a single copy in one file and
make the symbols extern (or even exported).
If they are used in only one driver, just put the tables into that driver.
You probably want to make them 'const' as well.
> static int __devinit ab8500_fg_probe(struct platform_device *pdev)
> {
> int i, irq;
> int ret = 0;
> struct abx500_bm_plat_data *plat_data = pdev->dev.platform_data;
> + struct device_node *np = pdev->dev.of_node;
> struct ab8500_fg *di;
>
> + di = devm_kzalloc(&pdev->dev, sizeof(*di), GFP_KERNEL);
> + if (!di) {
> + dev_err(&pdev->dev, "%s no mem for ab8500_btemp\n", __func__);
> + ret = -ENOMEM;
> + goto err_no_mem;
> + }
> + if (np) {
> + if (!plat_data) {
> + plat_data =
> + devm_kzalloc(&pdev->dev, sizeof(*plat_data),
> GFP_KERNEL);
> + if (!plat_data) {
> + dev_err(&pdev->dev,
> + "%s no mem for plat_data\n", __func__);
> + ret = -ENOMEM;
> + goto free_device_info;
> + }
> + plat_data->fg = devm_kzalloc(&pdev->dev,
> + sizeof(*plat_data->fg), GFP_KERNEL);
> + if (!plat_data->fg) {
> + devm_kfree(&pdev->dev, plat_data);
> + dev_err(&pdev->dev,
> + "%s no mem for pdata->fg\n",
> + __func__);
> + ret = -ENOMEM;
> + goto free_device_info;
> + }
> + }
> + /* get battery specific platform data */
> + ret = fg_of_probe(&pdev->dev, np, plat_data);
> + if (ret) {
> + devm_kfree(&pdev->dev, plat_data->fg);
> + devm_kfree(&pdev->dev, plat_data);
> + goto free_device_info;
> + }
> + }
I think for this driver it makes more sense to put all the information into
the struct ab8500_fg rather than having some of it in abx500_bm_plat_data,
so you can skip the allocation part here. In case of static platform
definitions, just copy the pointers from the platform data into the
ab8500_fg data.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: mfd: Implement devicetree support for AB8500 Btemp
On Monday 10 September 2012, Rajanikanth HV wrote:
> +
> +supplied-to:
> + This is a logical binding w.r.t power supply event change
> + across energy-management-module drivers where in the
> + runtime battery properties are shared along with uevent
> + notification.
> + ref: di->btemp_psy.external_power_changed =
> + ab8500_btemp_external_power_changed;
> + ab8500_btemp.c
> +
> + Need for this property:
> + btemp, fg and charger updates power-supply properties
> + based on the events listed above.
> + Event handler invokes power supply change notifier
> + which in-turn invokes registered power supply class call-back
> + based on the 'supplied_to' string.
> + ref:
> + power_supply_changed_work(..)
> ./drivers/power/power_supply_core.c
> +
> + example:
> + ab8500-btemp {
> + /* Other enery management module */
> + supplied-to = "ab8500_chargalg", "ab8500_fg";
> + num_supplicants = <2>;
> + };
> +
This looks like you're doing things the opposite way from everyone else.
Normally, each device uses phandles to refer to other objects it depends
on (gpio lines, regulators, clocks, interrupts, ...), rather than listing
things that depend on it.
Can you turn this around to be more like the others?
Note also that device tree identifiers should use '-' as a word separator,
not '_', and that a binding document should specify the exact set of
possible values. If the properties contain strings, please list every
valid string.
> + thermister-internal-to-battery = <1>;
> + li_ion_9100_battery = <0>;
Boolean properties should be empty when enabled and not present when
disabled. In this example, one would just write
thermister-internal-to-battery;
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: UFS Linux Driver
On Thursday 23 August 2012, pioioi wrote: > I am a graduated school student majoring in computer science in Korea and I > am interested in UFS. > > According to the announcement of JEDEC Mobile memory Forum, UFS Linux driver > is developed by LINARO > and it is already available. > > I am wondering whether UFS Linux Driver's code is open and where I can get it. > > If you are not the right person to answer my questions, please forward this > email > to the right person who can handle it. > Hi pioioi, The driver you are referring to is now part of Linux, so you can simply download the latest Linux version (3.5 or a 3.6-rc prerelease version) and use that. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] mfd: Implement devicetree support for AB8500 Btemp
On Tuesday 10 July 2012, Rajanikanth H.V wrote: > --- /dev/null > +++ b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt > @@ -0,0 +1,54 @@ > +AB8500 Battery Termperature Monitor Driver > + > +AB8500 is a mixed signal multimedia and power management > +device comprising: power and energy management module, > +WalliCharger and USB charger interface, audio, general > +purpose ADC TVOut, clock management and SIM card Interface. > + > +Battery temperature monitoring support is part of 'energy > +management module', the other components of this module > +are: 'main and USB Combo charger' and fuel guage. > + > +The properties below describes the node for battery > +temperature monitor driver. > + > +Required Properties: > +- compatible = "stericsson,ab8500-btemp" > + > +interrupts: > + Four battery temperature ranges are be defined > + which results in interrupt events as: > + - Btemp > + - BtempLow > + - BtempMedium > + - BtempHigh > + These names do not match the five interrupts in the example or in the code. When you provide an "interrupt-names" property you have to define the exact strings that are permissible for them in the binding. > +Supplied-to: > + This shall be power supply class dependency where in the runtime battery > + properties will be shared across fuel guage and charging algorithm > driver. I probably don't understand enough of this, but shouldn't the other devices that are supplied by this have a reference to this node rather than doing it this way around? Why use strings here instead of phandles? You are also not listing some of the properties that are in the device tree here, like the "interrupts" property itself. > diff --git a/arch/arm/mach-ux500/board-mop500-bm.c > b/arch/arm/mach-ux500/board-mop500-bm.c > new file mode 100644 > index 000..3349ceb > --- /dev/null > +++ b/arch/arm/mach-ux500/board-mop500-bm.c Didn't we conclude that this file has no board-specific information in it? Either explain why it's still here, or move it into the driver itself. > +/* > + * Note that the batres_vs_temp table must be strictly sorted by falling > + * temperature values to work. > + */ > +#ifdef CONFIG_AB8500_9100_LI_ION_BATTERY > +#define BATRES 180 > +#else > +#define BATRES 300 > +#endif I think I mentioned before that you need to get rid of the CONFIG_AB8500_9100_LI_ION_BATTERY symbol. If you have exclusive compile-time options, it is impossible to build a kernel that runs on all system, so this has to be a run-time option. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] [RFC]: mfd: Implement DT Support for AB8500 Btemp and fg
On Monday 02 July 2012, Lee Jones wrote: > On 02/07/12 11:38, Rajanikanth HV wrote: > > how will you accommodate new battery types information then? > > Add them to the driver too? > > From what I can see, the structs in board-mop500-bm.c are more of a > capability thing than saying "this is what we have". > > Please correct my snap-judgment if I'm incorrect. My first reaction to this would have been to put it all into the device tree, but I agree that the amount of data is a bit excessive. Looking at the Sony xperia sola source code, it seems that the same data is used for *all* boards, and nothing in it looks board specific, so putting it all into the driver itself sounds like the easiest solution. We can always add some form of abstraction if we later need something more complex. The version I'm looking at uses a compile-time configuration symbol "CONFIG_AB8500_BATTERY_THERM_ON_BATCTRL". This has to get removed and turned into a run-time option. The regulator names in the platform data look should probably be taken from the device tree. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro recommended (tm) brand of SD card?
On Wednesday 06 June 2012, Arnd Bergmann wrote: (this was David's bad card) > > > > MMBTR16GUBCA-ME > > | CYJ485GA 144 > > Made in TAIWAN > > > > but I might have an error there (it is tiny). > > Hmm, it had not occurred to me to compare the numbers on the card, rather > than those > on the packaging ;-) > > Now my excellent "Essential" (blue label) 32 GB class 10 card looks like this > > MMBTR32GUBCA-AB > S 32GBUSD1 132 > Made in Korea > > while my bad "Essential" 8GB looks the same from the front with the blue > label, but > has more text on it: > > MB-MS8GA > MBMS8GVCDBCA-RF > ICY11447QZ142 > MADE IN TAIWAN > DESIGNED BY > SAMSUNG fwiw, the ones above were produced in 12/2011 and 02/2012, respectively. I've got a few more samples now: * Excellent Transcend-branded 32GB class 10 microsdhc made by samsung, produced 01/2012 (identical to my Samsung above): MMBTR32GUBCA-AB S N3TVDD9I 203 Made in KOREA * Bad 8 GB microSDHC class 6, produced 09/2011, blue label, "essential series", identical behavior to bad essential 8GB above CE MMBTR08GUBCA-ME I CYG498GA 135 Made in TAIWAN * Bad 8 GB SDHC (not micro, class 6, red label, produced 12/2011, idential behavior to previous one. MB-SS8GA MBSS8GVCDBCA-RF D OLX0 1 4 7 MADE IN KOREA DESIGNED BY SAMSUNG This unfortunately proves that not all "made in korea" cards from samsung are good, which would have been too easy. It's had to find a pattern here, and I could still use more samples. What we have found out by now is that: * Made in Korea doesn't mean it's good, but all good cards we've seen so far are made in Korea. * The string MB-SS?GA does not mean it's good or bad * The string MMBTR??GUBCA seems to have the same meaning and also doesn't mean it's good or bad. * All good cards that we have seen have this string followed by -AB * All bad cards that we have seen have this string followed by -RF or -ME * The three-digit number at the end is always different and has some relation to the production date, but it's not monotonically increasing across different lines. * All fast cards so far are 32GB, all slow ones are between 4 and 16GB I also found a little bit of information at http://www.scribd.com/doc/90864328/Samsung-FLASH-Product-Guide That information suggests that the -AB line is only used for the 32 GB TLC flash based cards, and that it uses a "VJX" controller, as opposed to the "SS66512" controller used in the smaller TLC based cards with the -ME postfix. The "VJX" name sounds similar to what the same document calls their eMMC controllers, and the behavior of that device is also what I'd expect from an eMMC. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro recommended (tm) brand of SD card?
On Wednesday 13 June 2012, Jassi Brar wrote: > > On 6 June 2012 12:41, Arnd Bergmann wrote: > > > > for i in 2 3 30 31 ; do > >sudo flashbench --open-au --open-au-nr=30 --erasesize=$[512 * 1024] \ > >/dev/mmcblk0 --offset=$[24*1024*1024] > > done > > > > The latest version of the code is at > > git://git.linaro.org/people/arnd/flashbench.git > > > Just wanted to share the uFLIP benchmark, in case we could borrow from > it http://uflip.inria.fr/~uFLIP/benchmark/CIDR.pdf > http://uflip.inria.fr/~uFLIP/results/ > Thank you for that link, very interesting. I think we have already far surpassed what they did in terms of reversing the simple devices, although uFLIP seems to be much more useful in giving a feeling for performance on the higher-end devices. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro recommended (tm) brand of SD card?
On Monday 11 June 2012, David Brown wrote: > 4MB variant: > == 2 == > 4MiB4.05M/s > 2MiB6.13M/s > 1MiB6.19M/s > 512KiB 6.14M/s > 256KiB 5.27M/s > 128KiB 4.59M/s > 64KiB 6M/s > 32KiB 5.04M/s > 16KiB 490K/s > == 3 == > 4MiB5.06M/s > 2MiB3.93M/s > 1MiB1.72M/s > 512KiB 1.51M/s > 256KiB 449K/s > 128KiB 206K/s > 64KiB 1.2M/s > 32KiB 1.23M/s > 16KiB 1.66M/s > == 30 == > 4MiB6.66M/s > 2MiB3.29M/s > 1MiB1.64M/s > 512KiB 821K/s > 256KiB 408K/s > 128KiB 204K/s > 64KiB 104K/s > 32KiB 149K/s > 16KiB 660K/s Ok, thank you very much! This confirms that it is the same as my 8 GB essential card, and I would not recommend using this kind of card in production systems with an ext4 or similar file system. >From what I can tell, all the good Samsung cards are marked "Made in Korea" while all the bad ones are "Made in Taiwan". I would not treat this as 100% reliable information as those things tend to change over time, but it's certainly a good indication. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro recommended (tm) brand of SD card?
On Thursday 07 June 2012, David Brown wrote: > On Wed, Jun 06, 2012 at 07:11:37AM +0000, Arnd Bergmann wrote: > > > If you don't need the data on your card, could you run these > > commands on yours: > > > > for i in 2 3 30 31 ; do > > sudo flashbench --open-au --open-au-nr=30 --erasesize=$[512 * 1024] \ > > /dev/mmcblk0 --offset=$[24*1024*1024] > > done > > Did you mean to use $i somewhere in that loop? oops, yes it should be "--open-au-nr=$i" > I ran it with the > command given above (just once since it doesn't mention $i). Also, > this is on a USB card reader. I'd have to get a bit more creative to > be able to run this on my target, since the card is also the root > filesystem. USB card reader is fine for this test. > 512KiB 962K/s > 256KiB 398K/s > 128KiB 201K/s > 64KiB 101K/s > 32KiB 152K/s > 16KiB 719K/s FWIW, these are the results for the "good" card: for i in 2 3 30 31 ; do echo == $i == ; sudo ./flashbench --open-au --open-au-nr=$i --erasesize=$[512 * 1024] /dev/mmcblk0 --offset=$[24*1024*1024] ; done == 2 == 512KiB 7.42M/s 256KiB 7.65M/s 128KiB 7.64M/s 64KiB 7.41M/s 32KiB 6.46M/s 16KiB 4.78M/s == 3 == 512KiB 7.9M/s 256KiB 8.06M/s 128KiB 8.2M/s 64KiB 8.35M/s 32KiB 6.61M/s 16KiB 3.95M/s == 30 == 512KiB 8.41M/s 256KiB 8.21M/s 128KiB 8.16M/s 64KiB 8.32M/s 32KiB 6.76M/s 16KiB 4.31M/s == 31 == 512KiB 8.08M/s 256KiB 7.41M/s 128KiB 6.73M/s 64KiB 5.73M/s 32KiB 3.87M/s 16KiB 1.78M/s note how for values up to open-au-nr=30 the performance is stable for all block sizes over 64k and only degrades a little below that, while for open-au-nr=31 it gets much slower for small block sizes. The "bad" card looks very similar to yours: for i in 2 3 30 31 ; do echo == $i == ; sudo ./flashbench --open-au --open-au-nr=$i --erasesize=$[512 * 1024] /dev/mmcblk0 --offset=$[24*1024*1024] ; done == 2 == 512KiB 382K/s 256KiB 232K/s 128KiB 272K/s 64KiB 535K/s 32KiB 521K/s 16KiB 1.21M/s == 3 == 512KiB 393K/s 256KiB 176K/s 128KiB 223K/s 64KiB 606K/s 32KiB 585K/s 16KiB 976K/s == 30 == 512KiB 752K/s 256KiB 359K/s 128KiB 191K/s 64KiB 103K/s 32KiB 145K/s 16KiB 827K/s == 31 == ^C (I skipped this one, it's rather pointless) The effect becomes much more visible by trying erasesize=4MB: for i in 2 3 4 ; do echo == $i == ; sudo ./flashbench --open-au --open-au-nr=$i --erasesize=$[4096 * 1024] /dev/mmcblk0 --offset=$[24*1024*1024] ; done == 2 == 4MiB3.09M/s 2MiB4.93M/s 1MiB5.52M/s 512KiB 5.52M/s 256KiB 5.53M/s 128KiB 5.51M/s 64KiB 5.52M/s 32KiB 4.51M/s 16KiB 1.87M/s == 3 == 4MiB4.34M/s 2MiB3.61M/s 1MiB1.67M/s 512KiB 1.48M/s 256KiB 1.39M/s 128KiB 1.21M/s 64KiB 1.14M/s 32KiB 1.03M/s 16KiB 2.08M/s == 4 == 4MiB5.52M/s 2MiB3.45M/s 1MiB1.65M/s 512KiB 826K/s 256KiB 414K/s 128KiB 208K/s 64KiB 104K/s 32KiB 247K/s 16KiB 2.24M/s So this card can handle 2 open AUs just fine, three of them barely, but not 4 or more, which is not a particular good behavior. For any block sizes of 16kb or smaller, this card does provide some form of caching though that makes up for this problem to some degree. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro recommended (tm) brand of SD card?
On Monday 04 June 2012, David Brown wrote: > On Mon, Jun 04, 2012 at 03:36:55PM +0000, Arnd Bergmann wrote: > > > I can always need more samples. If anyone has Samsung cards at hand, could > > you > > send the output of "tail -n 100 /sys/block/mmcblk0/device/* > > /proc/partitions"? > > I'm not exactly sure what these are. It says "Samsung 16GB Class 10, > and the back says > > MMBTR16GUBCA-ME > | CYJ485GA 144 > Made in TAIWAN > > but I might have an error there (it is tiny). Hmm, it had not occurred to me to compare the numbers on the card, rather than those on the packaging ;-) Now my excellent "Essential" (blue label) 32 GB class 10 card looks like this MMBTR32GUBCA-AB S 32GBUSD1 132 Made in Korea while my bad "Essential" 8GB looks the same from the front with the blue label, but has more text on it: MB-MS8GA MBMS8GVCDBCA-RF ICY11447QZ142 MADE IN TAIWAN DESIGNED BY SAMSUNG So it seems that the text on your card is a mix of the one one my two cards. > ==> date <== > 11/2011 > > ==> driver <== > > ==> erase_size <== > 512 > > ==> fwrev <== > 0x0 > > ==> hwrev <== > 0x1 > > ==> manfid <== > 0x1b > > ==> name <== > 0 > > ==> oemid <== > 0x534d All of these seem to be the same for all the cards I have, which means that we cannot rely on the fwrev and hwrev fields. > 179 96 15632384 mmcblk1 > 179 97 14680064 mmcblk1p1 > 179 98 951279 mmcblk1p2 15632384 KB is a multiple of 2MB, but no larger power-of-two size, which suggests that this is the erase block size. However, most devices nowdays use larger erase blocks than that. My 32GB card also a size that is a multiple of no more than 1MB. The 8GB card uses a multiple of both 4 MB and 6 MB, and it uses a 6 MB erase block size. If you don't need the data on your card, could you run these commands on yours: for i in 2 3 30 31 ; do sudo flashbench --open-au --open-au-nr=30 --erasesize=$[512 * 1024] \ /dev/mmcblk0 --offset=$[24*1024*1024] done The latest version of the code is at git://git.linaro.org/people/arnd/flashbench.git Running the code will mess up the data but should not harm the device, but I recommend to run the 'erase' command from the flashbench repository on the entire card afterwards to get back the full performance. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro recommended (tm) brand of SD card?
On Wednesday 09 May 2012, Arnd Bergmann wrote: > On Tuesday 08 May 2012, Michael Hudson-Doyle wrote: > We also know that Samsung has caught up recently and is now making > excellent controllers even for their "essential" series cards -- > these behave much better than anything else I've tested before > (except eMMC and actual SSD drives). A quick follow-up on this: I've found another sample of 8GB Samsung "Essential" microSDHC from 2011. This one was rather bad, in fact worse than the 4GB one that I had tested before. The samples I have for samsung are now 4 GB microSDHC "Essential", MB-MS4GA, manf. 11/2011 => rather bad 8 GB microSDHC "Essential", MB-MS8GA, manf. 11/2011 => rather bad, worse or same as 4GB 8 GB SDHC "Plus" Class 10, MB-SP84GA, manf 6/2011 => pretty good, better than most 8 GB microSDHC "Plus" Class 10 MB-MP8GA, identical to SDHC model 32 GB microSDHC "Essential" Class 10 MB-MSBGA, three samples, manf 12/2011 and 1/2012, best cards ever I can always need more samples. If anyone has Samsung cards at hand, could you send the output of "tail -n 100 /sys/block/mmcblk0/device/* /proc/partitions"? I would definitely recommend the Samsung "Plus" models now for 8GB, and the "Essential" 32 GB model, but there is no sample for the 16 GB model yet. If you have a 16GB "Essential" card, I'd love to see the output of "flashbench --open-au /dev/mmcblk0 --open-au-nr=2 --blocksize=3072 --erasesize=$[6*1024*1024]" and "flashbench --open-au /dev/mmcblk0 --open-au-nr=30". WARNING: that test overwrites data on the card. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda mmc issue w/ Linus' current 3.5-rc tree
On Thursday 24 May 2012, John Stultz wrote: > Yep. Good call, that's the one! Reverting it works for me. > Thanks for catching that. After a few hours of bisecting I had gone a > bit braindead. :) > > Playing around with the patch, it looks like its the irq assignment > thats causing problems (twl6030_mmc_card_detect_config() is returning > 368). I can work around it with the hack below. > > Balaji: Any thoughts on a proper fix here? > It sounds like the probe function of that driver should be changed to return -EPROBEDEFER instead of -EINVAL for this case, so we can retry the probe when the interrupt number becomes available. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda mmc issue w/ Linus' current 3.5-rc tree
On Thursday 24 May 2012, John Stultz wrote: > On 05/23/2012 05:05 PM, John Stultz wrote: > > Hey Arnd, > > So it looks like something has gone awry in the 3.5 pull with > > Panda's mmc functionality. Trying to boot the current 3.5-rc tree, > > the boot fails after not finding the root device. Looking at the boot > > log I'm seeing: > > > > omap_hsmmc: probe of omap_hsmmc.0 failed with error -22 > > > > With the same config on 3.4 it boots up fine. I also tried w/ the > > omap2plus_defconfig and see the same behavior. > > > > Before I start bisecting down, I just wanted to raise the issue here > > in case there's a known fix. > > I went ahead and tried to bisect this down, and it was pretty painful as > there's a omap-usb-host build bug somewhere near the issue that keeps me > from being able to totally isolate it. > > Anyway, the bisection finally pointed to this merge: > > commit 8dca6010d44cc722a94dc6da96560f9083dac782 > Merge: 9bc747b 74c4375 > Author: Linus Torvalds > Date: Tue May 22 09:27:39 2012 -0700 Hmm, so the fixes branch by itself is fine and so is the commit before merging it. The only commit that I see that can actually imact this seems to be 1ee47b0. Can you try reverting that? The full list of changes in the fixes branch is this: $ git log --oneline --stat v3.4..74c4375 74c4375 ARM: spear6xx: remove board selection options arch/arm/mach-spear6xx/Kconfig | 18 +++--- 1 file changed, 3 insertions(+), 15 deletions(-) 1b6c352 Merge tag 'omap-fixes-non-critical-for-v3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux b6d3597 Merge tag 'v3.5-fixes-and-cleanups' of git://gitorious.org/linux-davinci/linux-davinci into next/fixes bdbaaf1 Merge branch 'for-3.5/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra into nex b2f44dc ARM: OMAP: igep0020: Specify the VPLL2 regulator unconditionally arch/arm/mach-omap2/board-igep0020.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) 0d09a95 ARM: OMAP2+: INTC: fix Kconfig option for TI81XX arch/arm/mach-omap2/irq.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) d723c17 ARM: OMAP2+: remove incorrect irq_chip ack field arch/arm/mach-omap2/irq.c |1 - 1 file changed, 1 deletion(-) 33ee0db ARM: OMAP4: Adding ID for OMAP4460 ES1.1 arch/arm/mach-omap2/id.c |5 - arch/arm/plat-omap/include/plat/cpu.h |1 + 2 files changed, 5 insertions(+), 1 deletion(-) def1dbb ARM: OMAP4: panda: add statics to remove warnings arch/arm/mach-omap2/board-omap4panda.c |8 1 file changed, 4 insertions(+), 4 deletions(-) 256a4bd ARM: OMAP2+: Incorrect Register Offsets in OMAP Mailbox arch/arm/mach-omap2/mailbox.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 28ee793 ARM: OMAP: fix trivial warnings for dspbridge arch/arm/mach-omap2/dsp.c|5 +++-- arch/arm/plat-omap/devices.c |4 ++-- 2 files changed, 5 insertions(+), 4 deletions(-) 98e3b33 arm: davinci: use for_each_set_bit_from arch/arm/mach-davinci/dma.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 1ee47b0 ARM: OMAP4: hsmmc: check for null pointer arch/arm/mach-omap2/board-4430sdp.c| 44 arch/arm/mach-omap2/board-omap4panda.c | 49 - arch/arm/mach-omap2/common.h |3 +++ arch/arm/mach-omap2/omap4-common.c | 58 ++ 4 files changed, 61 insertions(+), 93 deletions(-) e54bdc1 ARM: OMAP1: fix compilation issue in board-sx1.c arch/arm/mach-omap1/Kconfig |1 + 1 file changed, 1 insertion(+) 3d5e8af ARM: disable SUSPEND/ARCH_SUSPEND_POSSIBLE for ARCH_TEGRA arch/arm/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 59858b7 ARM: davinci: da850-evm: fix section mismatch arch/arm/mach-davinci/board-da850-evm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) aea812e ARM: tegra: add pll_x freq table entry for 750MHz arch/arm/mach-tegra/tegra2_clocks.c |6 ++ 1 file changed, 6 insertions(+) d65566e ARM: davinci: mark spi_board_info arguments as const arch/arm/mach-davinci/davinci.h|4 ++-- arch/arm/mach-davinci/devices-da8xx.c |2 +- arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/include/mach/da8xx.h |3 ++- 5 files changed, 7 insertions(+), 6 deletions(-) 4a6e6a5 ARM: davinci: fix incorrect pdctl next bit position arch/arm/mach-davinci/include/mach/psc.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) > Merge tag 'fixes' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-s > > Pull non-critical arm-soc bug fixes from Olof Johansson: > "These bug fixes were not important enough to have them included > in the >v3.4 release, mostly because they cover harmless warnings or >
Re: Making ARM multiplatform kernels DT-only?
On Saturday 05 May 2012, Arnd Bergmann wrote: > From the statements made so far, I can see no clear policy that we can > apply to everyone. My take on this is that for any work I spend on > multiplatform kernel, I concentrate on the DT-based board files and > get them to work together first, but leave it up to the individual > subarch maintainers whether they want to add other board files into > the mix. A small update that I already posted as a comment in the lwn article covering this discussion: | Over the last week, I've actually tried out building kernels for | multiple platforms combined to get a better feeling for the remaining | problems. The result is in the testing/multiplatform branch of | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git and it | can build arbitrary combinations of four of the five subarchitectures | that the Linaro organization is most interested in (imx, omap, ux500 and | vexpress, but not exynos for now). Most other platforms should actually | be simpler to convert. | | However, this kernel is not yet going to be useful on real hardware | because I had to disable or add hacks for a number of features (SMP, | sparseirq, clocks) that are still being worked on, but as soon as one | oatform has all that work done, we can actually build a kernel with | everything enabled and run on that particular platform and see what | else breaks. | | Unlike I suggested earlier, this kernel at the moment actually allows | enabling all the board files including non-DT ones because that was | easier to do with the Kconfig dependencies, but I found two real technical | issues that would be solved by making the combined kernel DT-only: | | 1. The exynos platform defines static platform devices from files | shared with five other Samsung platforms that are mutually exclusive | because the device definitions depend on platform specific compile-time | constants. Using DT probing we can just drop those static platform device | definitions and make the conflict go away. | | 2. With sparse IRQs, a lot of the hardcoded interrupt numbers in static | platform device definitions are broken, while the definitions from DT | still work. Sparse IRQs are currently needed to build multiplatform | kernels and I expect that requirement to stay. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/5] more clk-next fixes
On Tuesday 08 May 2012, Turquette, Mike wrote: > Arnd, > > Please pull the following changes since commit > 66f75a5d028beaf67c931435fdc3e7823125730c: > > Linux 3.4-rc4 (2012-04-21 14:47:52 -0700) > > are available in the git repository at: > git://git.linaro.org/people/mturquette/linux.git clk-next > Hi Mike, sorry for the delay. Olof was handling the other pull requests this week, and he probably didn't see this one or the discussion leading up to it, because he was not on Cc. I've pulled it into a next/clock branch now and it should show up in the for-next branch when it gets rebuilt without the spear patches that are currently in it and have older confliction versions of some of the same patches. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro recommended (tm) brand of SD card?
On Tuesday 08 May 2012, Michael Hudson-Doyle wrote: > On Tue, 8 May 2012 16:30:05 +0300, Riku Voipio wrote: > > > > I think following any SD card brand for quality is a losing > > proposition. Every brand sources chips wherever they cheapest get, and > > thus what is inside the package changes from one batch to another. > > Everyone has anecdotal evidence of one brands memory cards failing > > more often than another, but nobody has solid statistics... I disagree. We've learned a lot about the various brands and what they do by now. We know that Sandisk consistently has good controllers (unless you end up with a fake one that can be detected by looking into the ID registers) and that it has enabled them to use cheaper flash chips than most others. I'm rather certain that the companies who make their own controllers and flash chips (sandisk, samsung, lexar/micron) actually use their own chips all the time, while most others take whatever they can get their hands on. We also know that Kingston has uses Toshiba controllers with a horribly bad GC algorithm and I suspect that they have to make up for this by using better (MLC instead of TLC) flash chips (which means they are good for video cameras but not for Linux). We also know that Samsung has caught up recently and is now making excellent controllers even for their "essential" series cards -- these behave much better than anything else I've tested before (except eMMC and actual SSD drives). Finally, we have ways to test the erase block size and type (SLC/MLC/TLC) in order to determine whether the cards are any good. TLC is generally not very reliable and any erase block size larger than 4MB will cause too much write amplification according to our simulation, so random write performance and longevity suffer. > I guess you're right, depressingly enough. In any case I bought a > couple of sandisk microsdhc cards, one batch of which appears to have > been quite reliable in the lab... Yes, that seems to be a good choice. I've never encountered a Sandisk "ultra" or "extreme" card that wasn't really good. Their cheaper class 2 or class 4 cards are much less trustworthy IMHO because they use TLC memory. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro recommended (tm) brand of SD card?
On Tuesday 08 May 2012, James Tunnicliffe wrote: > > https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey > is being kept up to date, but at a glance has no reliability comments. > I have 4 Transcend class 10 32GB cards that rocket along, but one has > stopped letting me write images to it with linaro-media-create, so > full marks for speed, but not for reliability. Transcend unfortunately has varying suppliers, so sometimes they are good, and sometimes not so. In the recent tests I've done, Samsung cards are really shining and they tend to be cheaper than the good Sandisk ones, so I'd go for those now. I lot of the better cheap cards have Samsung chips in them as well if you're lucky, but that's not reliable and older Samsung cards are not as good. I don't have a good sample of Patriot cards, but the ones I tested were similar to Kingston. Lexar seems to be rather good, but again I only have a very small data set for those. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On Saturday 05 May 2012, Sascha Hauer wrote: > They should not if they are not interested in these boards, but why > shouldn't I be able to enable these 25 boards plus a few atmel or pxa > boards? > > When there are technical reasons to limit a multiplatform Kernel to DT > only, then fine, lets do it that way. If there are no technical reasons > and this limitation shall only be used to put some political pressure on > platform board maintainers, then I am against it. Look around, people > actually are porting their boards over to device tree, I don't think > that such pressure is necessary. It's definitely not a hard technical reason, just me trying to find ways to simplify the problem space an any possible way. Basically all code that can get built into the kernel has the ability to break other stuff and causes bloat, see the recent discussion about putting late_initcall into the machine_desc. > Only my two cents, it's not that important to me since I want to port my > (relevant) boards over to DT anyway, so I won't argue about this. Ok, thanks for your input! >From the statements made so far, I can see no clear policy that we can apply to everyone. My take on this is that for any work I spend on multiplatform kernel, I concentrate on the DT-based board files and get them to work together first, but leave it up to the individual subarch maintainers whether they want to add other board files into the mix. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On Friday 04 May 2012, Christian Robottom Reis wrote: > Isn't there work by Pawel that adds support for more of the Versatile > platform? My quick searching finds at least: > > http://comments.gmane.org/gmane.linux.drivers.i2c/10143 > http://comments.gmane.org/gmane.linux.ports.arm.kernel/143523 > > I think the latter is merged already, but I may be wrong. That work was done for versatile express, which is very different from versatile, although it shares a few devices like the i2c controller mentioned in the first link. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On Thursday 03 May 2012, Sascha Hauer wrote: > I don't think that enforcing DT only in multiplatform kernels will speed > up porting to DT. As a platform maintainer I am interested in building > multiplatform Kernels, but our customers are mostly uninterested in > this. They probably disable other platforms anyway to save the binary space. I was not asking about enabling multiple board files but multiple mach-* directories, which is something that I'm probably more interested in than you are, and the customers you refer to would certainly not do that if they only want to run on one board. This is really about people who distribute kernels that run on a wide variety of machines across soc vendor boundaries, people like ubuntu or cyanogenmod. The question is really whether you see a reason why they should enable the 25 non-DT board files on your platform, rather than helping out getting DT support for the machines they are interested in? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On Friday 04 May 2012, Wookey wrote: > > This is very important because distros are obviously the primary consumer > > of multiplatform builds (aside from build testing). The goal should very > > much be to reduce the number of distinct kernels that folks like debian, > > fedora or cyanogenmod have to build. > > Just to be clear, we'd very much like to support more hardware, ideally > 'everything a significant number of people have', but the overhead to > the whole distro for each new kernel added to the build (for every > upload, slowing and potentially breaking releases on all arches) is > sufficiently high that we have been strict about what is supported. As > a result a lot of people use Debian with non-distro kernels. Right, and this is the main motivation behind starting the multiplatform kernel anyway: supporting more hardware with fewer kernels. Other distros already aim at supporting only one ARM kernel binary, like things are on other architectures. One related issue is the kernel binary size, which we haven't discussed here yet. If we want to build 200 board files into the kernel, that alone becomes a burden, even if most of it can be discarded from RAM after the initcalls are done. Supporting only DT-enabled machines can significantly reduce the size while only reducing the number of supported boards by a bit, I'd hope. > Obviously missing things are tegra, dove/armada, omap4. Freerunner > would have been nice a while back but probably a bit late now. I can think of a few more: vexpress would be nice for running something useful inside of KVM when we get there, various samsung socs are used in cheap tablet PCs, and stuff like highbank is becoming more relevant for distros now on the server side. > It's not clear to me how many omap platforms our 'omap' kernel > actually serves in practice, and similarly for the other 'generic' > kernels. > > Obviously any and all progress in the direction of making existing > coverage or expanded coverage easier/faster/more-reliable/simpler is > very welcome. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On Friday 04 May 2012, Rob Herring wrote: > On 05/04/2012 07:20 AM, Arnd Bergmann wrote: > > On Thursday 03 May 2012, Russell King - ARM Linux wrote: > > My plan is to have multiplatform kernels in parallel with what we have now, > > so we can avoid breaking working machines but also play with multiplatform > > configurations at the same time for a subset of the platforms and with > > certain restrictions (not all board files, not all drivers, no generic > > early printk, ...). > > > > Many of the headers are simply platform_data structs which may still be > needed on DT platforms, but could be moved elsewhere Yes, as Russell pointed out, these really should go to include/linux/platform_data/. My patchset take a few shortcuts there right now, adding an ugly hack to redirect the header files from their current locations so I can avoid all the hard work to do that. > > > >> We still have irqs.h being SoC dependent, and we still haven't taken > >> debug-macros.S far enough along to get rid of that. > > > > I believe the irqs.h conflict is only for the NR_IRQS constant, all other > > defines in there should only be used inside of the mach-* directory, > > or not at all for fully DT-based platforms. > > A DT-enabled platform does not need irqs.h or NR_IRQS. SPARSE_IRQ should > be selected for DT. However, some DT enabled platforms don't have all > irq chips converted to domains and may still need to set the mach .nr_irqs. Ah, good to know. I hadn't realized that the #include in asm/irq.h is already conditional. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On Friday 04 May 2012, Russell King - ARM Linux wrote: > > On Fri, May 04, 2012 at 03:20:57PM +0100, Wookey wrote: > > Debian tries very hard not to support anything in the kernel that > > upstream don't support in the kernel because otherwise it's way too > > much work. The current list of supplied arm kernels is: > > > > iop32x (ThecusN2100, intel SS4000, GLAN tank) > > ixp4xx (Linksys NSLU2) > > kirkwood (*plugs, QNAP NAS, OPenRD) > > orion5x (QNAP NAS, HP mv2120) > > versatile > > mx5 > > omap > > > > because that's a good compromise between coverage and 'building 20-odd > > images'. I have no idea how much of that lot is going to get DTified, > > but I'm guessing the older stuff won't be? Thanks for the list, Wookey! This is very important because distros are obviously the primary consumer of multiplatform builds (aside from build testing). The goal should very much be to reduce the number of distinct kernels that folks like debian, fedora or cyanogenmod have to build. > Well, my understanding is that there's DT patches around for Versatile. > OMAP and MX5 are both heading for DT. I'm less certain about the Orion > and Kirkwood stuff, but as they're only about 4 years old, I would hope > that there was some active movement for these. FWIW, there is a lot of new activity on orion5x and kirkwood (less on mv78xxx and dove) and new board support for those platforms is being done using DT already, at least for the drivers that have been converted. As soon as the support is complete, I would hope that we can add dts files for the older boards that people are using as well, and a few releases later remove the respective board files. > The iop32x and ixp4xx stuff hasn't seen much in the way of maintenance > so its highly likely that these won't be converted to DT unless someone > with the hardware decides to step up and do it. Right. For those, I agree that it makes sense to support them without DT even in a multiplatform kernel. So I'll revise my initial proposal to * For mach-* directories that we expect to support using DT in the near future, support the ATAG based board files only in the current (single-platform, multi-board) way but not for multiplatform (i.e. multiple mach-*/ combined) builds. * For mach-* directories that look like they will not support DT anytime soon, support them as is in the multiplatform build, possibly enabling all their boards (or a well-defined subset) unconditionally. > So, that means your list should reduce down to five kernels, or three if > the Orion/Kirkwood stuff gets converted to DT. I count four if we were to proceed with the initial proposal: 1. ARMv6/v7 multiplatform: omap2plus, mx5/mx6, vexpress, ... 2. ARMv4/v5 multiplatform: versatile, orion5x, kirkwood, , ... 3. iop32x 4. ixp4xx Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On Friday 04 May 2012, Arnaud Patard wrote: > > On Thu, May 03, 2012 at 01:50:35PM +, Arnd Bergmann wrote: > >> My feeling is that we should just mandate DT booting for multiplatform > >> kernels, because it significantly reduces the combinatorial space > >> at compile time, avoids a lot of legacy board files that we cannot > >> test anyway, reduces the total kernel size and gives an incentive > >> for people to move forward to DT with their existing boards. > > > > On this point, I strongly object, especially as I'm one who uses the > > existing non-DT multiplatform support extensively. It's really not > > a problem for what you're trying to achieve. > > > > Please, don't do this. afaik, the idea was to reduce the numbers of > kernel to deal with. Unfortunately, this kind of restriction would > increase it. Consider orion platforms. This would mean having to deal > with 4 kernels (1 for DT, 1 for orion5x, 1 for kirkwood, 1 for mv78xx0). Ok, point taken. My hope for Orion is that we can actually proceed quicker there than on other platforms because the hardware is relatively simple, especially its clock and pinctrl aspects, so we would be able to boot almost anything with just supplying the right .dts file before we get to the point where we can boot the first multiplatform kernel on orion. > Dropping HW support because one wants to encourage people to convert > their board file into DT seems weird. Doing this, imho, should even be > called a regression. The DT conversion won't happen in an eye blink so > non-DT kernels are still something we should take care of. It's not dropping support for anything and not a regression in that sense. We will have other restrictions with multiplatform kernels for some time, with a lot of drivers breaking at first, and this question is basically about which tradeoffs and priorities we make with the new multiplatform enablement. > > I think what you're proposing is a totally artificial restriction. > > There's no problem with a kernel supporting DT and non-DT together. > > We've proven that many many times. I prove it every night that my > > build and boot system runs - the OMAP LDP boots a multiplatform kernel > > just fine without DT. > > I think it's true for imx too. iirc, one can build a single image for > armv4/armv5 and one other for armv6/armv7 without having to use DT. Yes, it's true for most platforms, and with my proposal, you would still be able to build an i.mx kernel that runs on all boards it runs on today, dt or not, nothing changed. The only question is when you want to build a combined kernel for orion+imx+omap+... whether that should allow the same options or just a subset. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On Thursday 03 May 2012, Russell King - ARM Linux wrote: > I'm basing my comments off mach-zynq. It's a different question because mach-zynq is already DT-only, but we can also discuss this for a bit. > How about we take the following steps towards it? > > 1. create arch/arm/include/mach/ which contains standardized headers >for DT based implementations. This must include all headers included >by asm/ or linux/ includes. This will also be the only mach/ header >directory included for code outside of arch/arm/mach-*. This also >acts as the 'default' set of mach/* includes for stuff like timex.h >and the empty hardware.h > > 2. DT based mach-* directories do not have an include directory; their >include files must be located in the main include/ heirarchy if shared >with other parts of the kernel, otherwise they must be in the mach-* >directory. My idea for the header files was slightly different, reorganizing only the headers that actually conflict between the platforms renaming the ones that conflict by name but not by content. I know you are aware of my experiment with just renaming the header files from mach/*.h to mach-*/*.h, and that has helped me a lot in understanding the specific problems. I don't care about the specific names of the headers but it has helped so far in identifying which drivers are already relying on a specific platform's version of a header and which ones multiplex between different platforms (e.g. sa1100/pxa/mmp or s3c*/s5p*/exynos) and need more work. I also wouldn't change anything for the current configurations where you only have one mach-* directory at a time (or the samsung speciality). My plan is to have multiplatform kernels in parallel with what we have now, so we can avoid breaking working machines but also play with multiplatform configurations at the same time for a subset of the platforms and with certain restrictions (not all board files, not all drivers, no generic early printk, ...). > 3. Allow build multiple mach-* directories (which we already do... see >the samsung stuff.) Incidentally, the samsung headers are what are currently causing the most headaches regarding the header files, because they use a lot of files with soc-specific definitions for the same symbols, which means significant reorganization of the code using to to turn that into run-time selectable values. > We still have irqs.h being SoC dependent, and we still haven't taken > debug-macros.S far enough along to get rid of that. I believe the irqs.h conflict is only for the NR_IRQS constant, all other defines in there should only be used inside of the mach-* directory, or not at all for fully DT-based platforms. > Then there's also the problem of uncompress.h. The last piece of the > puzzle is the common clock stuff. Initially, I think we can live without debug-macros.S and uncompress.h and change the code using those to just not output anything when MULTIPLATFORM is enabled: you'd have to disable MULTIPLATFORM in order to debug the early boot process and hope that any bugs are not specific to multiplatform configurations. In the long run, we probably want to have a better solution, but it's not on my hotlist. The common clock support OTOH is definitely a requirement as soon as we want to actually run multiplatform kernels rather than just building them. > So, I think we're still a way off it yet - maybe six months or so. True, but in order to work on the points you raised and a few others, I would like to know where we're heading because it does impact some decisions like whether we need to make all initcalls in non-DT board files aware of potentially being run on other platforms. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On Thursday 03 May 2012, Russell King - ARM Linux wrote: > On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote: > > My feeling is that we should just mandate DT booting for multiplatform > > kernels, because it significantly reduces the combinatorial space > > at compile time, avoids a lot of legacy board files that we cannot > > test anyway, reduces the total kernel size and gives an incentive > > for people to move forward to DT with their existing boards. > > On this point, I strongly object, especially as I'm one who uses the > existing non-DT multiplatform support extensively. It's really not > a problem for what you're trying to achieve. Just to clarify the terminology, when I said "multiplatform", I did not mean enabling more than one board file inside a given mach-* directory but instead enabling multiple mach-* directories that are currently mutually exclusive, i.e. the future stuff you replied to in the other mail, not what everyone is doing today, and this would not stop anything from working that works today. > I think what you're proposing is a totally artificial restriction. > There's no problem with a kernel supporting DT and non-DT together. > We've proven that many many times. I prove it every night that my > build and boot system runs - the OMAP LDP boots a multiplatform kernel > just fine without DT. Of course it's an artificial restriction, if it was a technical necessity, I would not have needed to ask ;-) IMHO however it's a helpful restriction. My current count of board files is 393 and if you consider that we won't build v6+ and v4/v5 together and that some of them will probably not be multiplatform capable for a long time, we probably end up with about half of them in a given kernel, which is still a lot and I would not expect distributors to make a good decision about which ones of these are important to enable and which ones are not. If we restrict the Kconfig space to just the ones that are DT-enabled, we can be reasonably sure that these have been recently tested on actual hardware by someone who cares about them, and we get only a fraction of the user visible options, roughly one per soc generation. One counterargument that just occurred to me is build coverage, and it would be nice to have "make allyesconfig" actually build everything together as far as possible. We could get a bit closer to that if we allow those platforms that have no DT support to just provide a Kconfig option for multiplatform kernels that enables everything, e.g. when you build an ARMv4/ARMv5 kernel, you can enable all sa1100 based boards together using one option, but when you build an sa1100 kernel, you keep picking them individually. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Making ARM multiplatform kernels DT-only?
Hi everyone, I've been discussing multiplatform kernels with a few people recently, and we will have a lot of discussion sessions about this at Linaro Connect in Hong Kong. One question that came up repeatedly is whether we should support all possible board files for each platform in a multiplatform kernel, or just the ones that are already using DT probing. I would like to get a quick poll of opinions on that and I've tried to put those people on Cc that would be most impacted by this, i.e. the maintainers for platforms that have both DT and non-DT board files at the moment. My feeling is that we should just mandate DT booting for multiplatform kernels, because it significantly reduces the combinatorial space at compile time, avoids a lot of legacy board files that we cannot test anyway, reduces the total kernel size and gives an incentive for people to move forward to DT with their existing boards. The counterargument is that we won't be able to support all the boards we currently do when the user switches on multiplatform, but I think that is acceptable. Note that I would still want to allow users to build platforms separately in order to enable the ATAG style board files, even for platforms that are not multiplatform capable. Other opinions? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Which kernel should outside developers use?
On Wednesday 04 April 2012, Chris Simmonds wrote: > > On 04/04/12 11:53, Amit Kucheria wrote: > > On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds > > wrote: > >> Hello, > >> > >> I am working on behalf of an SoC vendor and I am trying to work out which > >> (if any) of the many git trees at http://git.linaro.org/gitweb we should > > > > Is this a new SoC (no mainline support) or an existing SoC? > > It's a new SoC which will have its own arch/arm/mach-xxx directory In this case, the Linaro kernels don't help you. Just use the upstream kernel from Linus Torvalds directly, starting with v3.4-rc1. This has gained a lot of the new features that you need for new SoC work, including device tree bindings for a lot of subsystems, common clk framework and the pinctrl subsystem. Make sure you pick the right templates for new work. For instance, the mach-highbank and mach-zynq platforms are good examples for how new platforms should be structured. Don't copy from the older ones, as we are currently in the process of rewriting most of them, which would result in you having to do the same changes as the common code changes. This should not be a hard thing to do, because the changes we make upstream are intended to make it easier and require less code to get a new platform supported and merged. The 3.0 LTSI kernel is a bit problematic, because 3.0 predates most of the changes that are impacting your work, so it would not be possible to port bug fixes between 3.0-LTSI and upstream kernels. There will be a new LTSI kernel in the future, presumably based on v3.4, and I would strongly recommend starting with that for a new SoC platform because most of the large scale infrastructure changes have already made it into that version, so it will remain more or less compatible for a far longer time. If you have current users on 3.0 or older private kernel versions, it makes sense to keep them on that platform until 3.4 has stabilized enough, but there is no point in trying hard to make code portable between the two versions -- you should just consider 3.0 as a dead end and move all products away from that in the mid-term. If you need help in getting the new mach-xxx directory right, feel free to send me a git URL or a patch against a kernel release for review (ideally on-list with me on Cc, but private mail is ok if you require confidentiality), so I can tell you which parts you need to change in order to get long term maintainability and get your code merged upstream in a timely manner. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 00/13] common clk framework misc fixes
On Thursday 12 April 2012, Mike Turquette wrote: > This series collects many of the fixes posted for the recently merged > common clock framework as well as some general clean-up. Most of the > code classifies as a clean-up moreso than a bug fix; hopefully this is > not a problem since the common clk framework is new code pulled for 3.4. > > Patches are based on v3.4-rc2 and can be pulled from: > git://git.linaro.org/people/mturquette/linux.git v3.4-rc2-clk-fixes > > Please let me know I missed any critical fixes that were posted to the > list already. > > Arnd & Olof, if there are no objections to these changes can this get > pulled through the arm-soc tree? I think pulling it in through the arm-soc tree is still ok, but it's borderline because of the size and patch 13 is probably too big, in addition to the comments that were made there. Let's pull patches 1 through 12 in to a separate series that we don't mix with the other bug fixes. Mike, please send a pull request with the Acks added in. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Tuesday 20 March 2012, Paul Walmsley wrote: > Hello Arnd, > > On Sat, 17 Mar 2012, Arnd Bergmann wrote: > > > I think it's rather pointless, because the option is not going to > > be user selectable but will get selected by the platform unless I'm > > mistaken. The platform maintainers that care already know the state > > of the framework. > > This is where we have differing views, I think. Clearly, Sascha, > Saravana, Rob, and I have at least slightly different opinions on the > durability of the existing API and code. So it seems reasonable to assume > that others who have not followed the development of the common clock code > might mistake the implementation or API as being stable and well-defined. > > It sounds like the primary objection is to the use of CONFIG_EXPERIMENTAL. > So here is a patch to simply note the status of this code in its Kconfig > text. Yes, looks good to me. If there are no objections, I'll apply this one. Thanks, Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Tuesday 20 March 2012, Robert Lee wrote: > This patch series moves various functionality duplicated in platform > cpuidle drivers to the core cpuidle driver. Also, the platform irq > disabling was removed as it appears that all calls into > cpuidle_call_idle will have already called local_irq_disable(). > > These changes have been pulled into linux-next. > > Len, Andrew, can a request be made for Linus to pull these changes? FWIW, Len seems to be rather inactive on the kernel mailing list right now and generally not very interested in anything outside of x86 and acpi. If he doesn't reply in the next few days and Andrew also isn't interested in handling these patches, I'd suggest you just send the pull request to Linus, with Len on Cc and explain that you tried to send them through him but gave up in the end. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Tuesday 20 March 2012, Kevin Hilman wrote: > Maybe it's time that drivers/cpuidle gets a maintainer. With lots of > discussions of scheduler changes that affect load estimation, I suspect > we're all going to have a bit of CPUidle work to do in the > not-so-distant future. Hmm, according to the script, you are the maintainer ;-) $ scripts/get_maintainer.pl -f drivers/cpuidle/cpuidle.c Kevin Hilman (commit_signer:8/10=80%) Len Brown (commit_signer:7/10=70%) Trinabh Gupta (commit_signer:4/10=40%) Arjan van de Ven (commit_signer:4/10=40%) Deepthi Dharwar (commit_signer:4/10=40%) While I realize that the get_maintainers.pl is not the final word, you could be the acting cpuidle maintainer for this merge window and send the pull request. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Saturday 17 March 2012, Sascha Hauer wrote:
> On Sat, Mar 17, 2012 at 11:02:11AM -0700, Turquette, Mike wrote:
> >
> > Much like experimental I'm not sure how needed this change is. The
> > help section does say to leave it disabled by default, if unsure. If
> > you merge it I won't object but this might be fixing an imaginary
> > problem.
>
> Architectures without common clock support won't build with this option
> enabled (multiple definition of clk_enable etc), so I think this should
> not be user visible.
I've applied this patch now.
Arnd
commit c173033d154e9792b1b5059783b802f82536d48f
Author: Arnd Bergmann
Date: Sat Mar 17 21:10:51 2012 +
clk: make CONFIG_COMMON_CLK invisible
All platforms that use the common clk infrastructure should select
COMMON_CLK from platform code, and on all other platforms, it must
not be enabled, so there is no point making the option visible to
users, and when it is visible, we break randconfig builds.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 2eaf17e..82bcfbd 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -10,18 +10,14 @@ config HAVE_MACH_CLKDEV
bool
menuconfig COMMON_CLK
- bool "Common Clock Framework"
+ bool
select HAVE_CLK_PREPARE
---help---
The common clock framework is a single definition of struct
clk, useful across many platforms, as well as an
implementation of the clock API in include/linux/clk.h.
Architectures utilizing the common struct clk should select
- this automatically, but it may be necessary to manually select
- this option for loadable modules requiring the common clock
- framework.
-
- If in doubt, say "N".
+ this option.
if COMMON_CLK
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Saturday 17 March 2012, Turquette, Mike wrote: > > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig > > index 2eaf17e..a0a83de 100644 > > --- a/drivers/clk/Kconfig > > +++ b/drivers/clk/Kconfig > > @@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV > > > > menuconfig COMMON_CLK > > - bool "Common Clock Framework" > > + bool > >select HAVE_CLK_PREPARE > >---help--- > > The common clock framework is a single definition of struct > > clk, useful across many platforms, as well as an > > Much like experimental I'm not sure how needed this change is. The > help section does say to leave it disabled by default, if unsure. If > you merge it I won't object but this might be fixing an imaginary > problem. Well, it doesn't have any consequences for real users, but it I think it does for randconfig builds, which we are trying to repair currently. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Friday 16 March 2012, Turquette, Mike wrote: > On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley wrote: > > From: Paul Walmsley > > Date: Fri, 16 Mar 2012 16:06:30 -0600 > > Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now > > > > Mark the common clk code as depending on CONFIG_EXPERIMENTAL. The API > > is not well-defined and both it and the underlying mechanics are likely > > to need significant changes to support non-trivial uses of the rate > > changing code, such as DVFS with external I/O devices. So any platforms > > that switch their implementation over to this may need to revise much > > of their driver code and revalidate their implementations until the > > behavior of the code is better-defined. > > > > A good time for removing this EXPERIMENTAL designation would be after at > > least two platforms that do DVFS on groups of external I/O devices have > > ported their clock implementations over to the common clk code. > > > > Signed-off-by: Paul Walmsley > > Cc: Mike Turquette > > ACK. This will set some reasonable expectations while things are in flux. > > Arnd are you willing to take this in? I think it's rather pointless, because the option is not going to be user selectable but will get selected by the platform unless I'm mistaken. The platform maintainers that care already know the state of the framework. Also, there are no user space interfaces that we have to warn users about not being stable, because the framework is internal to the kernel. However, I wonder whether we need the patch below to prevent users from accidentally enabling COMMON_CLK on platforms that already provide their own implementation. Arnd diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..a0a83de 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV menuconfig COMMON_CLK - bool "Common Clock Framework" + bool select HAVE_CLK_PREPARE ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Friday 16 March 2012, Arnd Bergmann wrote: > > > > Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so > > that platform ports can gather speed? Several people are waiting for a > > somewhat stable version before starting their ports. > > > > And what is the path into mainline - will Russell carry it or Arnd > > (with Russell's blessing)? > > I would suggest putting it into a late/* branch of arm-soc so it finally > gets some linux-next exposure, and then sending it in the second week of the > merge window. > > Russell, please let me know if you want to carry it instead or if you > have found any last-minute show stoppers in the code. FWIW, it's in arm-soc now, and it's the last thing I put in there for v3.4. From now on until v3.4-rc1, feature patches can only get removed from arm-soc, not added. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Friday 16 March 2012, Amit Kucheria wrote: > On Fri, Mar 16, 2012 at 12:29 PM, Thomas Gleixner wrote: > > On Fri, 16 Mar 2012, Linus Walleij wrote: > > > >> On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette > >> wrote: > >> > >> > Provide documentation for the common clk structures and APIs. This code > >> > can be found in drivers/clk/ and include/linux/clk*.h. > >> > >> Acked-by: Linus Wallej > >> For this three-piece v7 patchset. > >> > >> It already does magnitudes more advanced stuff than what I need > >> so I'm pretty pleased, any remaining details can surely be ironed out > >> in-tree. > > > > Ack. We really need to get that in now and sort out the details in > > tree otherwise we will never finish that thing. > > > > Thomas, Russell, Arnd, > > Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so > that platform ports can gather speed? Several people are waiting for a > somewhat stable version before starting their ports. > > And what is the path into mainline - will Russell carry it or Arnd > (with Russell's blessing)? I would suggest putting it into a late/* branch of arm-soc so it finally gets some linux-next exposure, and then sending it in the second week of the merge window. Russell, please let me know if you want to carry it instead or if you have found any last-minute show stoppers in the code. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v10] mfd: Add anatop mfd driver
On Friday 16 March 2012, Ying-Chun Liu (PaulLiu) wrote: > From: "Ying-Chun Liu (PaulLiu)" > > Anatop is a mfd chip embedded in Freescale i.MX6Q SoC. > Anatop provides regulators and thermal. > This driver handles the address space and the operation of the mfd device. > > Signed-off-by: Ying-Chun Liu (PaulLiu) > Acked-by: Shawn Guo Reviewed-by: Arnd Bergmann ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9] mfd: Add anatop mfd driver
On Thursday 15 March 2012, Mark Brown wrote: > There were some other mutterings about using regmap for memory mapped > devices, mostly from the point of view of building framework features > like this on top of it. regmap currently makes some assumptions that > the I/O is going to be slow so approximately any amount of CPU time can > usefully be spent on avoiding I/O but we can probably do something about > that. It also uses mutexes to lock I/O which might not be the most > sensible thing for memory mapped devices, but again that's solveable. > Right now there's no memory mapping support but there's no reason that > can't be added. > > In short, it does seem sensible to want to have some support for this > for devices that use appropriate idioms. Ok, I see. I guess there is no reason to change anything in Paul's patch now, but we can keep this in mind if we see a lot of similar drivers in the future. Thanks, Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9] mfd: Add anatop mfd driver
On Thursday 15 March 2012, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> Anatop is a mfd chip embedded in Freescale i.MX6Q SoC.
> Anatop provides regulators and thermal.
> This driver handles the address space and the operation of the mfd device.
Hi Paul,
This looks like a very nice and clean driver, good work!
Very broadly speaking, I wonder whether we could use the regmap
infrastructure for these things in the future, but I would first
need to understand whether that is actually in the scope of regmap.
It seems that you just need a subset of what regmap provides,
so it could work, but it might not actually be better than what
you have now.
Mark, can you comment on that?
> +u32 anatop_get_bits(struct anatop *adata, u32 addr, int bit_shift,
> + int bit_width)
> +{
> + u32 val, mask;
> +
> + if (bit_width == 32)
> + mask = ~0;
> + else
> + mask = (1 << bit_width) - 1;
> +
> + val = readl(adata->ioreg + addr);
> + val = (val >> bit_shift) & mask;
> +
> + return val;
> +}
> +EXPORT_SYMBOL(anatop_get_bits);
I think the exports here should be EXPORT_SYMBOL_GPL. There is no reason
why an out of tree driver would ever use these.
> +static const struct of_device_id of_anatop_subdevice_match[] = {
> + { .compatible = "fsl,anatop-regulator", },
> + { .compatible = "fsl,anatop-thermal", },
> + { },
> +};
> +
> +static int __devinit of_anatop_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + void *ioreg;
> + struct anatop *drvdata;
> +
> + ioreg = of_iomap(np, 0);
> + if (!ioreg)
> + return -EADDRNOTAVAIL;
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> + drvdata->ioreg = ioreg;
> + spin_lock_init(&drvdata->reglock);
> + platform_set_drvdata(pdev, drvdata);
> + of_platform_bus_probe(np, of_anatop_subdevice_match, dev);
> +
> + return 0;
> +}
Why do you list the subdevices in of_anatop_subdevice_match()? I think you
should just use
of_platform_bus_probe(np, of_anatop_match, dev);
here, using the same match table that you have in the platform_driver.
That will automatically create platform devices for any children of this
device, so you don't have to update the list above when you get new
child drivers.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 4/7] cpufreq: add generic cpufreq driver
On Wednesday 21 December 2011, Richard Zhao wrote: > On Wed, Dec 21, 2011 at 09:20:46AM +0800, Richard Zhao wrote: > > > > > You also need to define how the core supplies get looked up. > > > > > > > It's pure software. platform uses this driver have to define "cpu" > > > > consumer. > > > > > > You still need to define this in the binding. > > You mean regulator DT binding? already in ? I'll check it. > Mark, cpu node is not a struct device, sys_device instead. I can not find > regulator via device/dt node. Can I still use the string to get regulator > after converting to DT? I believe Kay and Greg have the plan to unify "class" and "bus" in sysfs, which implies turning sys_device into a derived class of device instead of kobject. If that understanding is correct, we might as well do that now so we can attach a device_node to a sys_device. Kay, does this make sense? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: CMA vs HIGHMEM issue
On Tuesday 20 December 2011, Andy Green wrote: > but your suggestion is more elegant. I'm unsure of the ramifications of > the 2G / 2G scheme so I'll give it a try later. WFIW, the main reason why people don't want the 2G/2G split is to allow user space application to grow to 3GB instead of limiting them to 2GB per task. Most applications are fine with 2GB, but some can run out of address space and die a little sooner. However, those are typically the ones that really want a 64 bit machine anyway. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 4/7] cpufreq: add generic cpufreq driver
On Tuesday 20 December 2011, Richard Zhao wrote: > > +Generic cpufreq driver > > + > > +Required properties in /cpus/cpu@0: > > +- compatible : "generic-cpufreq" > > >>> > > >>> I'm not convinced this is the best way to do this. By requiring a > > >>> generic-cpufreq compatible string we're encoding Linux driver > > >>> information into the hardware description. The only way I can see to > > >>> avoid this is to provide a generic_clk_cpufreq_init() function that > > >>> platforms can call in their machine init code to use the driver. > > > > Agreed on the compatible string. > Assume you reject to use compatible string. > > It's putting Linux specifics into DT. > > > > You could flip this around and have the module make a call into the > > kernel to determine whether to initialize or not. Then platforms could > > set a flag to indicate this. > Could you make it more clear? kernel global variable, macro, or function? > > - Following your idea, I think, we can add in driver/cpufreq/cpufreq.c: > int (*clk_reg_cpufreq_get_op_table) (struct op_table *tbl, int *size); > SoC code set the callback. If it's NULL, driver will exit. We can get rid > of DT. It'll make cpufreq core dirty, but it's the only file built-in. > > - Drop module support. SoC call generic_clk_cpufreq_init as Jamie said. I think you don't actually need a "compatible" property here, as long as we ensure that the "cpu-freqs", "cpu-volts" and "trans-latency" properties are present in the cpu node if and only if the machine works with this driver (why else would you put them there?). CPUs are special in the device trees in a number of ways, so I think we can treat this as a logical extension. This way, you can still make the generic cpufreq driver a loadable module. You don't get module autoloading with this structure, but that is already the case because the cpu nodes in the device tree are not translated into linux devices. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 1/4] cpufreq: add arm soc generic cpufreq driver
On Saturday 17 December 2011 16:00:03 Richard Zhao wrote:
> On Fri, Dec 16, 2011 at 08:32:35AM -0600, Rob Herring wrote:
> > On 12/16/2011 04:30 AM, Richard Zhao wrote:
> > > It support single core and multi-core ARM SoCs. But it assume
> > > all cores share the same frequency and voltage.
> > >
> > > Signed-off-by: Richard Zhao
> > > ---
> > > drivers/cpufreq/Kconfig.arm |8 ++
> > > drivers/cpufreq/Makefile |1 +
> > > drivers/cpufreq/arm-cpufreq.c | 269
> > > +
> > > 3 files changed, 278 insertions(+), 0 deletions(-)
> > > create mode 100644 drivers/cpufreq/arm-cpufreq.c
> > >
> >
> > What makes this specific to ARM and not a generic DT + clk api +
> > regulator api driver?
>
> smp loops_per_jiffy update needs arm header .
I would suggest to instead change the definition of adjust_jiffies in the
core so it can be overridden by the architecture, like this
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 987a165..174584d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -189,6 +189,7 @@ EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
* systems as each CPU might be scaled differently. So, use the arch
* per-CPU loops_per_jiffy value wherever possible.
*/
+#ifndef adjust_jiffies
#ifndef CONFIG_SMP
static unsigned long l_p_j_ref;
static unsigned int l_p_j_ref_freq;
@@ -218,7 +219,8 @@ static inline void adjust_jiffies(unsigned long val, struct
cpufreq_freqs *ci)
{
return;
}
-#endif
+#endif /* CONFIG_SMP */
+#endif /* adjust_jiffies */
/**
Then ARM (and any others that want the driver) can provide their own
implementation and set
#define adjust_jiffies(val, ci) adjust_jiffies((val), (ci))
to let the core use that instead of the generic UP version.
While we're there, we should probably try to fix drivers that use
loops_per_jiffy,
because that is not what they think it is on SMP.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
On Thursday 01 December 2011, Catalin Marinas wrote: > On Thu, Dec 01, 2011 at 03:42:19PM +0000, Arnd Bergmann wrote: > > On Thursday 01 December 2011, Catalin Marinas wrote: > > How do you deal with signed integer arguments passed into SVC or HVC from > > a caller? If I understand the architecture correctly, the upper > > halves of the argument register end up zero-padded, while the callee > > expects sign-extension. > > If you treat it as an "int" (32-bit) and function prototype defined > accordingly, then the generated code only accesses it as a W (rather > than X) register and the top 32-bit part is ignored (no need for > sign-extension). If it is defined as a "long" in the 32-bit world, then > it indeed needs explicit conversion given the different sizes for long > (for example sys_lseek, the second argument is a 'long' and we do > explicit sign extension in the wrapper). Ok, so it's actually different from most other 64 bit architectures, which normally operate on 64-bit registers and expect the caller to do the correct sign-extension. Doing the sign-extension for long arguments then falls into the same category as long long and unsigned long long arguments, which also need a wrapper, as you mentioned. Strictly speaking, we only need to do it for those where the long argument has a meaning outside of the 0..2^31 range, e.g. io_submit can only take small positive numbers although the type is 'long'. What about unsigned long and pointer? Can we always rely on the upper half of the register to be zero-filled when we get an exception from 32 bit into 64 bit state, or do we also have to zero-extend those? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
On Thursday 01 December 2011, Catalin Marinas wrote: > Given the way register banking is done on AArch64, issuing an HVC on a > 32-bit guest OS doesn't require translation on a 64-bit hypervisor. We > have a similar implementation at the SVC level (for 32-bit user apps on > a 64-bit kernel), the only modification was where a 32-bit SVC takes a > 64-bit parameter in two separate 32-bit registers, so packing needs to > be done in a syscall wrapper. How do you deal with signed integer arguments passed into SVC or HVC from a caller? If I understand the architecture correctly, the upper halves of the argument register end up zero-padded, while the callee expects sign-extension. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
On Wednesday 30 November 2011, Ian Campbell wrote: > On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote: > > On Wednesday 30 November 2011, Ian Campbell wrote: > > What I suggested to the KVM developers is to start out with the > > vexpress platform, but then generalize it to the point where it fits > > your needs. All hardware that one expects a guest to have (GIC, timer, > > ...) will still show up in the same location as on a real vexpress, > > while anything that makes no sense or is better paravirtualized (LCD, > > storage, ...) just becomes optional and has to be described in the > > device tree if it's actually there. > > That's along the lines of what I was thinking as well. > > The DT contains the address of GIC, timer etc as well right? So at least > in principal we needn't provide e.g. the GIC at the same address as any > real platform but in practice I expect we will. Yes. > In principal we could also offer the user options as to which particular > platform a guest looks like. At least when using a qemu based simulation. Most platforms have some characteristics that are not meaningful in a classic virtualization scenario, but it would certainly be helpful to use the virtualization extensions to run a kernel that was built for a particular platform faster than with pure qemu, when you want to test that kernel image. It has been suggested in the past that it would be nice to run the guest kernel built for the same platform as the host kernel by default, but I think it would be much better to have just one platform that we end up using for guests on any host platform, unless there is a strong reason to do otherwise. There is also ongoing restructuring in the ARM Linux kernel to allow running the same kernel binary on multiple platforms. While there is still a lot of work to be done, you should assume that we will finish it before you see lots of users in production, there is no need to plan for the current one-kernel-per-board case. > > Ok. It would of course still be possible to agree on an argument passing > > convention so that we can share the macros used to issue the hcalls, > > even if the individual commands are all different. > > I think it likely that we can all agree on a common calling convention > for N-argument hypercalls. It doubt there are that many useful choices > with conflicting requirements yet strongly compelling advantages. Exactly. I think it's only lack of communication that has resulted in different interfaces for each hypervisor on the other architectures. KVM and Xen at least both fall into the single-return-value category, so we should be able to agree on a calling conventions. KVM does not have an hcall API on ARM yet, and I see no reason not to use the same implementation that you have in the Xen guest. Stefano, can you split out the generic parts of your asm/xen/hypercall.h file into a common asm/hypercall.h and submit it for review to the arm kernel list? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
On Wednesday 30 November 2011, Ian Campbell wrote: > On Wed, 2011-11-30 at 13:03 +0000, Arnd Bergmann wrote: > > On Wednesday 30 November 2011, Stefano Stabellini wrote: > > This is the same choice people have made for KVM, but it's not > > necessarily the best option in the long run. In particular, this > > board has a lot of hardware that you claim to have by putting the > > machine number there, when you don't really want to emulate it. > > This code is actually setting up dom0 which (for the most part) sees the > real hardware. Ok, I see. > > Pawell Moll is working on a variant of the vexpress code that uses > > the flattened device tree to describe the present hardware [1], and > > I think that would be a much better target for an official release. > > Ideally, the hypervisor should provide the device tree binary (dtb) > > to the guest OS describing the hardware that is actually there. > > Agreed. Our intention was to use DT so this fits perfectly with our > plans. > > For dom0 we would expose a (possibly filtered) version of the DT given > to us by the firmware (e.g. we might hide a serial port to reserve it > for Xen's use, we'd likely fiddle with the memory map etc). Ah, very good. > For domU the DT would presumably be constructed by the toolstack (in > dom0 userspace) as appropriate for the guest configuration. I guess this > needn't correspond to any particular "real" hardware platform. Correct, but it needs to correspond to some platform that is supported by the guest OS, which leaves the choice between emulating a real hardware platform, adding a completely new platform specifically for virtual machines, or something in between the two. What I suggested to the KVM developers is to start out with the vexpress platform, but then generalize it to the point where it fits your needs. All hardware that one expects a guest to have (GIC, timer, ...) will still show up in the same location as on a real vexpress, while anything that makes no sense or is better paravirtualized (LCD, storage, ...) just becomes optional and has to be described in the device tree if it's actually there. > > This would also be the place where you tell the guest that it should > > look for PV devices. I'm not familiar with how Xen announces PV > > devices to the guest on other architectures, but you have the > > choice between providing a full "binding", i.e. a formal specification > > in device tree format for the guest to detect PV devices in the > > same way as physical or emulated devices, or just providing a single > > place in the device tree in which the guest detects the presence > > of a xen device bus and then uses hcalls to find the devices on that > > bus. > > On x86 there is an emulated PCI device which serves as the hooking point > for the PV drivers. For ARM I don't think it would be unreasonable to > have a DT entry instead. I think it would be fine just represent the > root of the "xenbus" and further discovery would occur using the normal > xenbus mechanisms (so not a full binding). AIUI for buses which are > enumerable this is the preferred DT scheme to use. In general that is the case, yes. One could argue that any software protocol between Xen and the guest is as good as any other, so it makes sense to use the device tree to describe all devices here. The counterargument to that is that Linux and other OSs already support Xenbus, so there is no need to come up with a new binding. I don't care much either way, but I think it would be good to use similar solutions across all hypervisors. The two options that I've seen discussed for KVM were to use either a virtual PCI bus with individual virtio-pci devices as on the PC, or to use the new virtio-mmio driver and individually put virtio devices into the device tree. > > Another topic is the question whether there are any hcalls that > > we should try to standardize before we get another architecture > > with multiple conflicting hcall APIs as we have on x86 and powerpc. > > The hcall API we are currently targeting is the existing Xen API (at > least the generic parts of it). These generally deal with fairly Xen > specific concepts like grant tables etc. Ok. It would of course still be possible to agree on an argument passing convention so that we can share the macros used to issue the hcalls, even if the individual commands are all different. I think I also remember talk about the need for a set of hypervisor independent calls that everyone should implement, but I can't remember what those were. Maybe we can split the number space into a range of some generic and some vendor specific hcalls? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
On Wednesday 30 November 2011, Stefano Stabellini wrote: > On Tue, 29 Nov 2011, Arnd Bergmann wrote: > > On Tuesday 29 November 2011, Stefano Stabellini wrote: > > > > Do you have a pointer to the kernel sources for the Linux guest? > > We have very few changes to the Linux kernel at the moment (only 3 > commits!), just enough to be able to issue hypercalls and start a PV > console. > > A git branch is available here (not ready for submission): > > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm Ok, interesting. There really isn't much of the platform support that I was expecting there. I finally found the information I was looking for in the xen construct_dom0() function: 167 regs->r0 = 0; /* SBZ */ 168 regs->r1 = 2272; /* Machine NR: Versatile Express */ 169 regs->r2 = 0xc100; /* ATAGS */ What this means is that you are emulating the current ARM/Keil reference board, at least to the degree that is necessary to get the guest started. This is the same choice people have made for KVM, but it's not necessarily the best option in the long run. In particular, this board has a lot of hardware that you claim to have by putting the machine number there, when you don't really want to emulate it. Pawell Moll is working on a variant of the vexpress code that uses the flattened device tree to describe the present hardware [1], and I think that would be a much better target for an official release. Ideally, the hypervisor should provide the device tree binary (dtb) to the guest OS describing the hardware that is actually there. This would also be the place where you tell the guest that it should look for PV devices. I'm not familiar with how Xen announces PV devices to the guest on other architectures, but you have the choice between providing a full "binding", i.e. a formal specification in device tree format for the guest to detect PV devices in the same way as physical or emulated devices, or just providing a single place in the device tree in which the guest detects the presence of a xen device bus and then uses hcalls to find the devices on that bus. Another topic is the question whether there are any hcalls that we should try to standardize before we get another architecture with multiple conflicting hcall APIs as we have on x86 and powerpc. Arnd [1] http://www.spinics.net/lists/arm-kernel/msg149604.html ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
On Tuesday 29 November 2011, Stefano Stabellini wrote: > Hi all, > a few weeks ago I (and a few others) started hacking on a > proof-of-concept hypervisor port to Cortex-A15 which uses and requires > ARMv7 virtualization extensions. The intention of this work was to find > out how to best support ARM v7+ on Xen. See > http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html > for more details. > > I am pleased to announce that significant progress has been made, and > that we now have a nascent Xen port for Cortex-A15. The port is based on > xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting > the latest virtualization, LPAE, GIC and generic timer support in > hardware. Very nice! Do you have a pointer to the kernel sources for the Linux guest? Since Xen and KVM are both in an early working state right now, it would be very nice if we could agree on the guest model to make sure that it's always possible to run the same kernel in both (and potentially other future) hypervisors without modifications. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 5/5] clk: export tree topology and clk data via sysfs
On Tuesday 22 November 2011 12:19:51 Grant Likely wrote: > On Tue, Nov 22, 2011 at 11:01 AM, Mike Turquette > wrote: > > > Others have requested to have knobs made available for actually > > performing clk_enable/clk_disable and even clk_set_rate from > > userspace. I hate this idea and won't implement it. I encourage > > anyone that needs this to do it in debugfs. > > > > Does that work-split make sense to you, or do you still not like the > > idea of having topology and read-only info in sysfs? > > Unless there is a solid real-world use case for exporting this data to > userspace, I do not think sysfs is a good idea. As long as the usage > (beyond debug) is theoretical I think the whole thing should be in > debugfs. It can always be moved at a later date If a real use case > does become important. I would recomment not to spend any time on implementing a debugfs interface for this right now. As far as I can tell, nothing relies on exporting the structure to user space, so Mike's time is better spent on getting the other four patches merged. Note that the static topology information about clocks will already be visible in /proc/devicetree when that is enabled and the clocks are described in the .dts file. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 4/5] clk: basic gateable and fixed-rate clks
On Tuesday 22 November 2011, Mark Salter wrote:
>
> On Tue, 2011-11-22 at 13:11 +, Arnd Bergmann wrote:
> > On Tuesday 22 November 2011, Mike Turquette wrote:
> > > +static void clk_hw_gate_set_bit(struct clk *clk)
> > > +{
> > > + struct clk_hw_gate *gate = to_clk_hw_gate(clk);
> > > + u32 reg;
> > > +
> > > + reg = __raw_readl(gate->reg);
> > > + reg |= BIT(gate->bit_idx);
> > > + __raw_writel(reg, gate->reg);
> > > +}
> >
> > You cannot rely on __raw_readl() to do the right thing, especially
> > in architecture independent code. The safe (but slightly inefficient)
> > solution would be readl/writel. For ARM-only code, it would be best
> > to use readl_relaxed()/writel_relaxed(), but most architectures do
> > not implement that. We can probably add a set of helpers in asm-generic/
> > to define them to the default functions, like "#define readl_relaxed(x)
> > readl(x)", which I think is a good idea anyway.
> >
>
> readl/writel won't work for big endian CPU when the registers are on a
> bus that does the endian swabbing in hardware.
That statement doesn't make any sense.
You obviously have to specify the bit index in a way that works with the
driver implementation and with the hardware.
__raw_readl has an unspecified endianess, which is normally the same
as the register endianess of the CPU (assuming a memory-mapped bus),
which means you have to do extra work if the register layout is
independent of the CPU endianess, which is about as common as
MMIO registers defined as being the same endianes as the CPU in
bi-endian implementations.
Considering that hardware makers cannot agree on how to count bits
(IBM calls the MSB bit 0 on big-endian systems), there is no way
to please everyone, though you could debate about what the clearest
semantics are that we should define.
IMHO it would be nicer to use a bit-mask in bus-endian notation, e.g.
reg = readl(gate->reg);
reg |= le32_to_cpu(gate->bit_mask);
writel(reg, gate->reg);
but there are other ways to do this. The only thing that I would
definitely ask for is having the interface clearly documented as
being one of cpu-endian, bus-endian, fixed-endian or having the
endianess specified in the device definition (device tree or platform
data).
Note that I don't object to adding a new cpu-endian mmio accessor,
which has been discussed repeatedly in the past. It's just that
this accessor does not exist, and using __raw_readl as a substitute
causes additional problems.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 4/5] clk: basic gateable and fixed-rate clks
On Tuesday 22 November 2011, Mike Turquette wrote:
> +static void clk_hw_gate_set_bit(struct clk *clk)
> +{
> + struct clk_hw_gate *gate = to_clk_hw_gate(clk);
> + u32 reg;
> +
> + reg = __raw_readl(gate->reg);
> + reg |= BIT(gate->bit_idx);
> + __raw_writel(reg, gate->reg);
> +}
You cannot rely on __raw_readl() to do the right thing, especially
in architecture independent code. The safe (but slightly inefficient)
solution would be readl/writel. For ARM-only code, it would be best
to use readl_relaxed()/writel_relaxed(), but most architectures do
not implement that. We can probably add a set of helpers in asm-generic/
to define them to the default functions, like "#define readl_relaxed(x)
readl(x)", which I think is a good idea anyway.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 5/5] clk: export tree topology and clk data via sysfs
On Tuesday 22 November 2011, Mike Turquette wrote: > Introduces kobject support for the common struct clk, exports per-clk > data via read-only callbacks and models the clk tree topology in sysfs. > > Also adds support for generating the clk tree in clk_init and migrating > nodes when input sources are switches in clk_set_parent. > > Signed-off-by: Mike Turquette > --- > drivers/clk/Kconfig | 10 +++ > drivers/clk/Makefile|1 + > drivers/clk/clk-sysfs.c | 199 > +++ > drivers/clk/clk.c |5 +- > include/linux/clk.h | 36 - > 5 files changed, 248 insertions(+), 3 deletions(-) > create mode 100644 drivers/clk/clk-sysfs.c Since this introduces a new top-level hierarchy in sysfs, it certainly needs to be reviewed by Greg K-H (on Cc now). Also, you have to add a proper documentation for every new node and attribute in Documentation/ABI along with the code. > +static struct kobject *clk_kobj; > +LIST_HEAD(kobj_list); The list head should be static. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: A Plumber's Wish List
On Friday 07 October 2011, Christian Robottom Reis wrote: > > http://lwn.net/Articles/462076/ > > How many of these are relevant to ARM platforms (including Android), and > what would feature on an ARM Plumber's Wish List? They all apply to ARM but I see these more as small annoyances not to have for specific people. While each of the requests sounds reasonable, I don't think any of them are important enough that we should spend a lot of time on them, unless one of us is blocked on a specific item. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changing default root filesystem to ext4
On Monday 26 September 2011, Robert Schwebel wrote: > On Thu, Aug 18, 2011 at 02:28:07PM +0200, Arnd Bergmann wrote: > > ext4 has optimizations for flash media in it and btrfs is better by > > design. > > Do you have a pointer to more info about what kind of optimizations for > flash media ext4 has? We tried to find something, but didn't so far. No, sorry. I think the block allocation work rather differently, and the move from block pointers to extents should also help, but I don't know how much of that was done specifically for flash, or what other optimizations are there. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ioctl ABI considerations for 64b ARM?
On Monday 19 September 2011 19:36:27 Arnd Bergmann wrote: > > > > Hmm, so then since you can build the kernel w/ OABI compatibility, it > > seems like structs should always have padding fields to force them to > > be a multiple of 32bits... > > It depends on whether you want those structures to be compatible with > any other structure. To give a different example, qemu-user supports > converting ioctl data structures to the host data structure for > any commands it knows. When you want to run an arm-oabi binary for > instance on an x86-32 host, you need to conver the data structures > that have this layout, but not when running the same program built > for arm-eabi. > > In either case however, you will have to convert the data structures > that contain pointers running qemu-user on x86-64. Sorry, I misunderstood your question. Yes, as Nicolas explained, the oabi-compat code in an arm-eabi kernel is broken indeed but works most of the time in practice. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ioctl ABI considerations for 64b ARM?
On Monday 19 September 2011 10:43:00 Rob Clark wrote: > On Mon, Sep 19, 2011 at 10:39 AM, Will Deacon wrote: > > Arnd, > > > > On Mon, Sep 19, 2011 at 08:15:45AM +0100, Arnd Bergmann wrote: > >> Assuming that we can prevent any funny stuff from going into such an ABI, > >> we only need to worry about the warts of the current ABI for ARM specific > >> considerations. The one thing that I've noticed before is that structs > >> on ARM (at least on one of the ABIs, forgot which) are padded to 32 bits, > >> even if all members inside are smaller. > > > > This is only the case for the old ABI. EABI lays out structures so that they > > are aligned to their most aligned member and padded to be the smallest > > possible multiple of that alignment which can contain all of their aligned > > members. > > Hmm, so then since you can build the kernel w/ OABI compatibility, it > seems like structs should always have padding fields to force them to > be a multiple of 32bits... It depends on whether you want those structures to be compatible with any other structure. To give a different example, qemu-user supports converting ioctl data structures to the host data structure for any commands it knows. When you want to run an arm-oabi binary for instance on an x86-32 host, you need to conver the data structures that have this layout, but not when running the same program built for arm-eabi. In either case however, you will have to convert the data structures that contain pointers running qemu-user on x86-64. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ioctl ABI considerations for 64b ARM?
On Monday 19 September 2011, Rob Clark wrote: > > * If you use structures, try very hard to avoid pointers in them, > > it messes up all sorts of tools. > > > > * If you use structures, make all members naturally aligned, and pad > > the size of the structures to a multiple of the maximum member size. > > > > * Never put sub-command numbers into a structure. > > I didn't get this comment.. what is special about sub-command #'s? It's mostly general interface cleanliness. We have the ioctl command multiplexer nested inside the syscall command multiplexer, which is both the reason its convenience and for most of the problems associated with ioctl. Nesting another multiplexor inside a single ioctl command gives you more ugliness and more problems without any added convenience (ioctl numbers are cheap). Specifically for 32 bit compat ioctls, you don't want to have to handle sub-commands in different ways but instead have some commands go directly to the native function while only the ones whose author screwed up go through a compat conversion. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ioctl ABI considerations for 64b ARM?
On Sunday 18 September 2011 15:24:37 Rob Clark wrote: > I don't suppose there are any guidelines from ARM about compatibility > between 32bit userspace and 64bit kernel on some hypothetical future > version of the ARM architecture? Some hints about what to do or not > do could perhaps save some ioctl compat glue later on down the line.. There are some rules that should be followed regardless: * ioctl commands should never be written in an architecture specific way. In the example of the OMAP driver, you definitely want to be able ot use the same command when running Linux on the C6x DSP. * If possible, use only scalar values as ioctl arguments * Avoid types that are register sized: 'long', 'size_t', pointer. Instead use only __u8, __u16, __u32 and __u64 and their signed versions. * If you use structures, try very hard to avoid pointers in them, it messes up all sorts of tools. * If you use structures, make all members naturally aligned, and pad the size of the structures to a multiple of the maximum member size. * Never put sub-command numbers into a structure. > > But since there is no 64-bit ARM yet, it might be better to rely on using > > compat code in the future than on making guesses about alignment > > restrictions of the ABI... > > hmm, it might be nice to get some guidelines from ARM on this, since I > really have no idea what a 64b ARM architecture would look like... Assuming that we can prevent any funny stuff from going into such an ABI, we only need to worry about the warts of the current ABI for ARM specific considerations. The one thing that I've noticed before is that structs on ARM (at least on one of the ABIs, forgot which) are padded to 32 bits, even if all members inside are smaller. It would be a huge pain if a 64 bit ABI had /different/ padding rules here, like not padding (logical choice by itself, but hurts is here), or padding everything to 64 bits (maybe not worth porting the kernel to then). Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2] ASoC: omap: convert per-board modules to platform drivers
On Friday 09 September 2011, Russell King - ARM Linux wrote: > That's just twisted and utterly insane - adding more code for precisely > zero benefit what so ever. Think about it - the device tree is already > creating platform devices for entries in the device tree file. What's > the point of having this special ASoC code look up the platform compatible > property in a table of strings to find a different string to manually > create a device with. Why not just add the bloody device to the DT > file in the first place? That's partly what DT is there for - to create > platform specific struct devices. Exactly. No driver or (worse) user program should ever need to look at the top-level compatible property. When you want information about a localized part of the system (e.g. the ASoC components), you should look up the information for that component. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
