Is Pandaboard cpuhotplug working stably?

[Barry Song]

Hi guys,
i tried cpuhotplug on pandaboard for both
Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to
work stably.
On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well:
# echo 0 > /sys/devices/system/cpu/cpu1/online
CPU1: shutdown

if i enable the cpu1 again by "echo 1 >
/sys/devices/system/cpu/cpu1/online", the system will restore to 3
random status: hang, normal, panic.

Using  Linaro 11.11 release, "echo 0 >
/sys/devices/system/cpu/cpu1/online" will make system hang and the
whole system will not be able to reset by pressing reset key, the only
way to reset system is pulling out AV power.

i am sorry i can't get more time to debug and find more clues. just
want to ask people whether this is a version the cpuhotplug works
normal on?

Thanks
barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Is Pandaboard cpuhotplug working stably?

[Barry Song]

2011/12/21 Russell King - ARM Linux :
> On Wed, Dec 21, 2011 at 05:23:48PM +0800, Barry Song wrote:
>> Hi guys,
>> i tried cpuhotplug on pandaboard for both
>> Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to
>> work stably.
>> On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well:
>> # echo 0 > /sys/devices/system/cpu/cpu1/online
>> CPU1: shutdown
>>
>> if i enable the cpu1 again by "echo 1 >
>> /sys/devices/system/cpu/cpu1/online", the system will restore to 3
>> random status: hang, normal, panic.
>>
>> Using  Linaro 11.11 release, "echo 0 >
>> /sys/devices/system/cpu/cpu1/online" will make system hang and the
>> whole system will not be able to reset by pressing reset key, the only
>> way to reset system is pulling out AV power.
>>
>> i am sorry i can't get more time to debug and find more clues. just
>> want to ask people whether this is a version the cpuhotplug works
>> normal on?
>
> cpu hotplug is basically totally buggered - the preconditions placed
> upon the bringup code path are basically impossible to satisfy in any
> shape or form at the moment.
>
> There's the requirement that the secondary CPU is marked online and
> active before interrupts are enabled for the thread migration stuff
> to behave correctly.  However, this is incompatible with smp_call_function()
> which will wait for online CPUs to respond to an IPI - which this one
> won't because interrupts are disabled.
>
> I think there was some discussion about how to fix this but I don't
> recall the details.

thanks, Russell. then could i think this is an ARM-kernel-specific bug
which exists on all ARM SMP chips for the moment?
and that bug doesn't happen on x86:
root@ubuntu:~/simple-rootfs/initrd/bin# echo 0 >
/sys/devices/system/cpu/cpu3/online
root@ubuntu:~/simple-rootfs/initrd/bin# echo 1 >
/sys/devices/system/cpu/cpu3/online
root@ubuntu:~/simple-rootfs/initrd/bin# echo 0 >
/sys/devices/system/cpu/cpu2/online
root@ubuntu:~/simple-rootfs/initrd/bin# echo 1 >
/sys/devices/system/cpu/cpu2/online

-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

native gdb for Android

[Barry Song]

Hi guys,
I compile a native gdb using linaro 2011.10 by “./configure
--host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi”, and
the gdb runs on arm target boards directly.
# gdb
GNU gdb (Linaro GDB) 7.3-2011.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi".
For bug reporting instructions, please see:
.
(gdb)

I can use it to debug native programs on target boards directly. For
example, attach process, set breakpoints, check registers and memory.
One issue is I can't see multi-threads, for example:

PID 646 is system_server by ps
"646 1000  159m Ssystem_server"

Then I use gdb to attach it:

# gdb attach 646
(gdb) info threads
  Id   Target Id Frame
* 1process 646 "system_server" __ioctl ()
at bionic/libc/arch-arm/syscalls/__ioctl.S:15

as you see, “info threads” only shows one thread but there are several
threads in system_server.

But if I compile a new program based on glibc and gnu libthread, I can
see multi-threads by the gdb.

So my questions are:

1.  Should I compile the native gdb using android toolchain and android
bionic/libthread libraries?
2.  Why can’t the current gdb capture multithreads for android
processes? This question is actually about the theory for gdb to know
multi-threads. In my opinion, both gnu and android use clone() to fork
threads and threads in one process have same tgid in kernel and all
threads return same getpid() value. Why not gdb just travel process
lists to find multi-threads?

Thanks
Barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: native gdb for Android

[Barry Song]

Hi Ulrich,

2012/2/3 Ulrich Weigand :
> Barry Song <21cn...@gmail.com> wrote:
>
>> So my questions are:
>>
>> 1.   Should I compile the native gdb using android toolchain and android
>> bionic/libthread libraries?
>> 2.   Why can’t the current gdb capture multithreads for android
>> processes? This question is actually about the theory for gdb to know
>> multi-threads. In my opinion, both gnu and android use clone() to fork
>> threads and threads in one process have same tgid in kernel and all
>> threads return same getpid() value. Why not gdb just travel process
>> lists to find multi-threads?
>
> I'm not sure what exactly is going on on Android with bionic.  However,
> GDB currently does require support from the thread library in order to
> debug multi-threaded applications.  This is needed e.g. to properly
> handle thread-local storage variables.  GDB will also use this support
> to detect threads of a running process it is attaching to.
>
> (It is true that GDB *could* e.g. look at /proc to find threads, instead
> of inspecting thread library data structures.  However, since the link
> to those data structures is required anyway, e.g. for TLS, this has not
> been implemented so far ...)
>
> When using glibc's libpthread, the support routines gdb uses to inspect
> target thread library datastructures are provided in libthread_db.so.1
> (which comes with glibc, and is linked into gdb).  I do not know the
> details on whether/how bionic provides a corresponding service.
>
> However, from looking at the gdbserver sources provided with Android,
> it seems there are some differences; in particular, there's this patch:
>
> +/* Android doesn't have libthread_db.so.1, just libthread_db.so.  */
> +#ifdef __ANDROID__
> +#define LIBTHREAD_DB_SO "libthread_db.so"
> +#endif
> +
>
> If libthread_db is named differently, this would explain why GDB is
> unable to find and use it.

there are two ways to handle this issue:
1. ln -s /system/lib/libthread_db.so /system/lib/libthread_db.so.1
2. patching gdb
i did have changed linaro-gdb 11.10 release by:

diff --git a/gdb/arm-linux-tdep.c b/gdb/arm-linux-tdep.c
index ca0bc30..486faf6 100644
--- a/gdb/arm-linux-tdep.c
+++ b/gdb/arm-linux-tdep.c
@@ -98,8 +98,8 @@ static const char arm_linux_thumb2_le_breakpoint[] =
{ 0xf0, 0xf7, 0x00, 0xa0 };
buffer.  This is also true for the SoftFPA model.  However, for the FPA
model the PC is at offset 21 in the buffer.  */
 #define ARM_LINUX_JB_ELEMENT_SIZE  INT_REGISTER_SIZE
-#define ARM_LINUX_JB_PC_FPA21
-#define ARM_LINUX_JB_PC_EABI   9
+#define ARM_LINUX_JB_PC_FPA24/*21*/
+#define ARM_LINUX_JB_PC_EABI   24/*9*/

 /*
Dynamic Linking on ARM GNU/Linux
diff --git a/gdb/gdb_thread_db.h b/gdb/gdb_thread_db.h
index 957ed2c..51ed4fa 100644
--- a/gdb/gdb_thread_db.h
+++ b/gdb/gdb_thread_db.h
@@ -2,7 +2,7 @@
 #include 

 #ifndef LIBTHREAD_DB_SO
-#define LIBTHREAD_DB_SO "libthread_db.so.1"
+#define LIBTHREAD_DB_SO "libthread_db.so"
 #endif

 #ifndef LIBTHREAD_DB_SEARCH_PATH

But both 1 and 2 can't simply fix the problem. if we compile gdb
statically by "make LDFLAGS=-static", it will finally come into a
crash:
# gdb attach 643
GNU gdb (Linaro GDB) 7.3-2011.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
this is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
attach: No such file or directory.
Attaching to process 643
Reading symbols from /system/bin/app_process...done.
BFD: /system/bin/linker: warning: sh_link not set for section `.ARM.exidx'

warning: Could not load shared library symbols for 6 libraries, e.g.
gralloc.default.so.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Reading symbols from /system/bin/linker...(no debugging symbols found)...done.
Loaded symbols for /system/bin/linker
Reading symbols from /system/lib/libc.so...done.
Loaded symbols for /system/lib/libc.so
Reading symbols from /system/lib/libstdc++.so...(no debugging symbols
found)...done.
Loaded symbols for /system/lib/libstdc++.so
Reading symbols from /system/lib/libm.so...(no debugging symbols found)...done.
Loaded symbols for /system/lib/libm.so
...
__ioctl () at bionic/libc/arch-arm/syscalls/__ioctl.S:15
15  bionic/libc/arch-arm/syscalls/__ioctl.S: No such file or directory.
in bionic/libc/arch-a

Re: native gdb for Android

[Barry Song]

2012/2/3 Thiago Jung Bauermann :
> Hi Barry,
>
> On Thu, 2012-02-02 at 10:23 +0800, Barry Song wrote:
>> 2.    Why can’t the current gdb capture multithreads for android
>> processes? This question is actually about the theory for gdb to know
>> multi-threads. In my opinion, both gnu and android use clone() to fork
>> threads and threads in one process have same tgid in kernel and all
>> threads return same getpid() value. Why not gdb just travel process
>> lists to find multi-threads?
>
> Would you mind opening a bug report at
>
> https://bugs.launchpad.net/gdb-linaro
>
> with this issue? If possible, with a small testcase to reproduce the
> problem, and the steps to build the testcase.
>
> To be honest I can only look into this issue late next week though...

Thiago, yes. i will.
PS: now there is a platform/external/gdb.git tree in
http://android.git.linaro.org/gitweb. i would suggest linaro make the
gdb compilable with an Android.mk by arm-eabi-gcc just like other
external components something like:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE_TAGS := eng

LOCAL_MODULE := gdb

LOCAL_SRC_FILES += \
   ... \

include $(BUILD_EXECUTABLE)

finally, i hope that will result in a native gdb running on boards and
supporting multithreads. that is actually very useful to many users.

> --
> []'s
> Thiago Jung Bauermann
> Linaro Toolchain Working Group

-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: native gdb for Android

[Barry Song]

Ulrich,
thanks a lot!

2012/2/4 Ulrich Weigand :
> Barry Song <21cn...@gmail.com> wrote.
>> 2012/2/3 Ulrich Weigand :
>> > However, from looking at the gdbserver sources provided with Android,
>> > it seems there are some differences; in particular, there's this patch:
>> >
>> > +/* Android doesn't have libthread_db.so.1, just libthread_db.so.  */
>> > +#ifdef __ANDROID__
>> > +#define LIBTHREAD_DB_SO "libthread_db.so"
>> > +#endif
>> > +
>> >
>> > If libthread_db is named differently, this would explain why GDB is
>> > unable to find and use it.
>>
>> there are two ways to handle this issue:
>> 1. ln -s /system/lib/libthread_db.so /system/lib/libthread_db.so.1
>
> That would seem a good thing in any case.  (Is there any reason for
> Android to use nonstandard shared library naming conventions?)
>
>> this "fixed" Assertion `_rtld_global_ro._dl_pagesize != 0' , but it
>> still can't find multi-threads for android processes:
>> (gdb) info threads
>>   Id   Target Id         Frame
>> * 1    process 645 "system_server" __ioctl ()
>>     at bionic/libc/arch-arm/syscalls/__ioctl.S:15
>>
>> (gdb) info threads
>>   Id   Target Id         Frame
>> * 1    process 938 "mediaserver" __ioctl ()
>>     at bionic/libc/arch-arm/syscalls/__ioctl.S:15
>
> I had a quick look at the AOSP sources, and found that there actually
> is an implementation of libthread_db that is supposed to work with
> bionic.  Well, there seem to be multiple versions:
>
> ./bionic/libthread_db
> ./ndk/sources/android/libthread_db/gdb-6.6
> ./ndk/sources/android/libthread_db/gdb-7.1.x
>
> I'm not sure why there needs to be a different version for each
> GDB(server) release ...   Maybe there's something in there that
> also needs changing when it's being used by GDB directly instead
> of by gdbserver.
>
> I'll probably not be able to help you very much here; I'd suggest
> you 1) make sure your GDB actually uses the correct version of
> libthread_db (in particular, not one from glibc, but this one that
> handles bionic) and 2) if it still doesn't work, you'll have to
> debug what's going wrong.

for 1, i think gdb has loaded /system/lib/libthread_db.so of android
according to log info after patching gdb:
--- a/gdb/gdb_thread_db.h
+++ b/gdb/gdb_thread_db.h
@@ -2,7 +2,7 @@
 #include 

 #ifndef LIBTHREAD_DB_SO
-#define LIBTHREAD_DB_SO "libthread_db.so.1"
+#define LIBTHREAD_DB_SO "libthread_db.so"
 #endif

for 2, the answer is it doesn't work yet.  i reported this issue at:
https://bugs.launchpad.net/gdb-linaro/+bug/926472
as Thiago pointed out. Thanks, Thiago!

>
> Note that from a quick look at the above libthread_db sources,
> those actually do not look into bionic data structures at all,
> but rather just traverse /proc to get a thread list.  While this
> is somewhat odd (if you want to do that, you could just do it in
> gdb/server itself -- the only reason why libthread_db is a separate
> project is its close integration with the thread library), it ought
> to make it easier to understand what's going on / wrong.
>
>
> Mit freundlichen Gruessen / Best Regards
>
> Ulrich Weigand
>
-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: implementing "suspend to ram" on cortex A8 based on linux 3.0.8

[Barry Song]

hi yang,

在 2012年3月10日 下午10:37，yang gqyang  写道：
>  Thanks for your comment.
>  Finally, i find out that i made a mistake.  The uart(8250) have not been
>  restore after resume, instead, it use the configuration got from boot. The
>  uart have not been restored correctly, so that "ls" can not output result
>  correctly resulting in it seems that the busybox can not work correctly.
>  Now, i still have a question about the uart: why the "printk" can work
>  correctly, but the "printf" not?
>
>  Before this, i believe that the "printk" work correctly, then the uart
>  work ok. but now, i  need more reconsidaration about
>  the relation between the "printk", "printf" and "uart".
>  Can anyone give me some suggestion? Any comment is welcome, thanks a
>  lot.

printk use "struct console" driver, it doesn't depend on a device node
for userspace.
printf actaully depends on uart_driver and a /dev/ttySx device node,
stdout and stderr are redirected to /dev/ttySx
uart is just a hardware which can be a tty or kernel console output.


>
>
-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/2] pinmux: add a driver for the U300 pinmux

[Barry Song]

2011/6/14 Linus Walleij :
> From: Linus Walleij 
>
> This adds a driver for the U300 pinmux portions of the system
> controller "SYSCON". It also serves as an example of how to use
> the pinmux subsystem. This driver also houses the platform data
> for the only supported platform.
>
> Signed-off-by: Linus Walleij 
> ---
>  arch/arm/mach-u300/core.c     |   19 ++
>  drivers/pinctrl/pinmux-u300.c |  433 
> +
>  drivers/pinctrl/pinmux-u300.h |  141 +
>  3 files changed, 593 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/pinctrl/pinmux-u300.c
>  create mode 100644 drivers/pinctrl/pinmux-u300.h
>
> diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
> index 513d6ab..d52e0bd 100644
> --- a/arch/arm/mach-u300/core.c
> +++ b/arch/arm/mach-u300/core.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -1630,6 +1631,20 @@ static struct platform_device dma_device = {
>        },
>  };
>
> +static struct platform_device pinmux_device = {
> +       .name = "pinmux-u300",
> +       .id = -1,
> +       .num_resources = ARRAY_SIZE(pinmux_resources),
> +       .resource = pinmux_resources,
> +};
> +
> +/* Padmux settings */
> +static struct pinmux_map u300_padmux_map[] = {
> +       PINMUX_MAP("mmc0", "mmci"),
> +       PINMUX_MAP("spi0", "pl022"),
> +       PINMUX_MAP("uart0", "uart0"),
> +};
> +
>  /*
>  * Notice that AMBA devices are initialized before platform devices.
>  *
> @@ -1828,6 +1843,10 @@ void __init u300_init_devices(void)
>
>        u300_assign_physmem();
>
> +       /* Initialize pinmuxing */
> +       pinmux_register_mappings(u300_padmux_map,
> +                                ARRAY_SIZE(u300_padmux_map));
> +
>        /* Register subdevices on the I2C buses */
>        u300_i2c_register_board_devices();
>
> diff --git a/drivers/pinctrl/pinmux-u300.c b/drivers/pinctrl/pinmux-u300.c
> new file mode 100644
> index 000..da26789
> --- /dev/null
> +++ b/drivers/pinctrl/pinmux-u300.c
> @@ -0,0 +1,433 @@
> +/*
> + * Driver for the U300 pinmux
> + *
> + * Based on the original U300 padmux functions
> + * Copyright (C) 2009-2011 ST-Ericsson AB
> + * Author: Martin Persson 
> + * Author: Linus Walleij 
> + *
> + * The DB3350 design and control registers are oriented around pads rather 
> than
> + * pins, so we enumerate the pads we can mux rather than actual pins. The 
> pads
> + * are connected to different pins in different packaging types, so it would
> + * be confusing.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +/*
> + * Usually you want the board to define the pins, but we have only one board,
> + * so let us do it all in this all-encompassing file.
> + */
> +#include 
> +#include 
> +
> +#include "pinmux-u300.h"
> +
> +#define DRIVER_NAME "pinmux-u300"
> +
> +/*
> + * The DB3350 has 467 pads, I have enumerated the pads clockwise around the
> + * edges of the silicon, finger by finger. LTCORNER upper left is pad 0.
> + * Data taken from the PadRing chart, arranged like this:
> + *
> + *   0 . 104
> + * 466        105
> + *   .        .
> + *   .        .
> + * 358        224
> + *  357  225
> + */
> +#define U300_NUM_PADS 467
> +
> +/* Pad names for the pinmux subsystem */
> +const struct pinctrl_pin_desc __initdata u300_pads[] = {
> +       PINCTRL_PIN(0, "P PAD VDD 28"),
> +       PINCTRL_PIN(1, "P PAD GND 28"),
> +       PINCTRL_PIN(2, "PO SIM RST N"),
> +       PINCTRL_PIN(3, "VSSIO 25"),
> +       PINCTRL_PIN(4, "VSSA ADDA ESDSUB"),
> +       PINCTRL_PIN(5, "PWR VSSCOMMON"),
> +       PINCTRL_PIN(6, "PI ADC I1 POS"),
> +       PINCTRL_PIN(7, "PI ADC I1 NEG"),
> +       PINCTRL_PIN(8, "PWR VSSAD0"),
> +       PINCTRL_PIN(9, "PWR VCCAD0"),
> +       PINCTRL_PIN(10, "PI ADC Q1 NEG"),
> +       PINCTRL_PIN(11, "PI ADC Q1 POS"),
> +       PINCTRL_PIN(12, "PWR VDDAD"),
> +       PINCTRL_PIN(13, "PWR GNDAD"),
> +       PINCTRL_PIN(14, "PI ADC I2 POS"),
> +       PINCTRL_PIN(15, "PI ADC I2 NEG"),
> +       PINCTRL_PIN(16, "PWR VSSAD1"),
> +       PINCTRL_PIN(17, "PWR VCCAD1"),
> +       PINCTRL_PIN(18, "PI ADC Q2 NEG"),
> +       PINCTRL_PIN(19, "PI ADC Q2 POS"),
> +       PINCTRL_PIN(20, "VSSA ADDA ESDSUB"),
> +       PINCTRL_PIN(21, "PWR VCCGPAD"),
> +       PINCTRL_PIN(22, "PI TX POW"),
> +       PINCTRL_PIN(23, "PWR VSSGPAD"),
> +       PINCTRL_PIN(24, "PO DAC I POS"),
> +       PINCTRL_PIN(25, "PO DAC I NEG"),
> +       PINCTRL_PIN(26, "PO DAC Q POS"),
> +       PINCTRL_PIN(27, "PO DAC Q NEG"),
> +       PINCTRL_PIN(28, "PWR VSSDA"),
> +       PINCTRL_PIN(29, "PWR VCCDA"),
> +       PINCTRL_PIN(30, "VSSA ADDA ESDSUB"),
> +       PINCTRL_PIN(31, "P PAD VDDIO 11"),
> +       PINCTRL_PIN(32, "PI PLL 26 FILTVDD"),
> +       PINCTRL_PIN(33, "PI PLL 26 VCONT"),
> +       PINCTRL_PIN(34, "PWR AGNDPLL2V5 32 13"),
> +       PINCTRL_PIN(35, "PWR AVDDPLL2V5 32 13"),
> +       PINCTRL_PIN(36, "VDDA PLL ESD"),
> +       PINCTRL_PIN(3

Re: [PATCH 1/2] drivers: create a pinmux subsystem v3

[Barry Song]

Hi Linus,

>> diff --git a/Documentation/ABI/testing/sysfs-class-pinmux 
>> b/Documentation/ABI/testing/sysfs-class-pinmux
>> new file mode 100644
>> index 000..c2ea843
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-pinmux
>> @@ -0,0 +1,11 @@
>> +What:  /sys/class/pinmux/.../name
>> +Date:  May 2011
>> +KernelVersion: 3.1
>
> has this been ready for 3.1? we have been planning to write pinmux
> driver based on this framework.

What is the status of pincfg subsystem? what's the plan about merging
this subsystem?

>
>> +Contact:   Linus Walleij 
>> +Description:
>> +   Each pinmux directory will contain a field called
>> +   name. This holds a string identifying the pinmux for
>> +   display purposes.
>> +
>> +   NOTE: this will be empty if no suitable name is provided
>> +   by platform or pinmux drivers.
>> diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
>> new file mode 100644
>> index 000..c4b6f48
>> --- /dev/null
>> +++ b/Documentation/pinctrl.txt
>> @@ -0,0 +1,397 @@
>> +PINCTRL (PIN CONTROL) subsystem
>> +This document outlines the pin control subsystem in Linux
>> +
>> +This subsystem deals with:
>> +
-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/4 v4] pinmux: add a driver for the U300 pinmux

[Barry Song]

Hi Linus,
Looks pretty good. just some minors.

2011/8/19 Linus Walleij :
> From: Linus Walleij 
>
> This adds a driver for the U300 pinmux portions of the system
> controller "SYSCON". It also serves as an example of how to use
> the pinmux subsystem. This driver also houses the platform data
> for the only supported platform.

yes. it is a good example for us to follow.

>
> Signed-off-by: Linus Walleij 
>
> +
> +static int __exit u300_pmx_remove(struct platform_device *pdev)
> +{
> +       struct u300_pmx *upmx = platform_get_drvdata(pdev);
> +
> +       if (upmx) {

why do you need to check whether upmx is not NULL. if it is NULL, we
have failed in probe().
and it is also impossible to call this remove() twice.

> +               pinmux_unregister(upmx->pmx);
> +               iounmap(upmx->virtbase);
> +               release_mem_region(upmx->phybase, upmx->physize);
> +               platform_set_drvdata(pdev, NULL);
> +               kfree(upmx);
> +       }
> +
> +       return 0;
> +}
> +
> +static struct platform_driver u300_pmx_driver = {
> +       .driver = {
> +               .name = DRIVER_NAME,
> +               .owner = THIS_MODULE,
> +       },
> +       .remove = __exit_p(u300_pmx_remove),

if you want to add deepsleep support(i mean pinmux crl will lose power
while suspending), what do you plan to add?
save U300_SYSCON_PMC1LR, U300_SYSCON_PMC1HR, U300_SYSCON_PMC2R,
U300_SYSCON_PMC3R, U300_SYSCON_PMC4R in suspend and restore them in
resume?

it is also a generic issue to pinmux.

> +/*
> + * Register definitions for the U300 Padmux control registers in the
> + * system controller
> + */
> +
> +/* PAD MUX Control register 1 (LOW) 16bit (R/W) */
> +#define U300_SYSCON_PMC1LR                                     (0x007C)
...
> +#define U300_SYSCON_PMC4R_APP_MISC_16_EMIF_1_STATIC_CS5_N      (0x0200)

do you want these "(" ")" for macros?

Thanks
barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 0/4 v4] pin controller subsystem v4

[Barry Song]

> - Rewrite the interaction with the GPIO subsystem - the pin
>  controller descriptor now handles this by defining an offset
>  into the GPIO numberspace for its handled pin range. This is
>  used to look up the apropriate pin controller for a GPIO pin.
>  Then that specific GPIO range is matched 1-1 for the target
>  controller instance.
...
>
> Linus Walleij (4):
>  drivers: create a pinmux subsystem v4
>  pinmux: add a driver for the U300 pinmux
>  amba: request muxing for PrimeCell devices
>  mach-u300: activate pinmux driver, delete old padmux driver

it seems there is not an actual example that gpio requests pin from
pinctrl yet. i might give one on SiRFprimaII.

Thanks
Barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/4 v4] drivers: create a pin control subsystem

[Barry Song]

> +
> +Pinmux board/machine configuration
> +==
> +
> +Boards and machines define how a certain complete running system is put
> +together, including how GPIOs and devices are muxed, how regulators are
> +constrained and how the clock tree looks. Of course pinmux settings are also
> +part of this.
> +
> +A pinmux config for a machine looks pretty much like a simple regulator
> +configuration, so for the example array above we want to enable i2c and
> +spi on the second function mapping:
> +
> +#include 
> +
> +static struct pinmux_map pmx_mapping[] = {
> +       {
> +               .function = "spi0-1",
> +               .dev_name = "foo-spi.0",
> +               .ctrl_dev_name = "pinctrl.0",
> +       },
> +       {
> +               .function = "i2c0",
> +               .dev_name = "foo-i2c.0",
> +               .ctrl_dev_name = "pinctrl.0",
> +       },
> +       {
> +               .function = "mmc0-4bit",
> +               .dev_name = "foo-mmc.0",
> +               .ctrl_dev_name = "pinctrl.0",
> +       },
> +};
> +
I have a little worry about how will this map work after all foo-spi,
foo-i2c, foo-mmc use DT. they will lose those simple name just
foo-spi.0, foo-spi.1, foo-spi.2 except that we use OF_DEV_AUXDATA_ID.
the actual device name might be foo-spi.200fee or something like that.
then this map will have the same problem with the current clock/device
mapping.
could we have a way to define the connection between device and pinmux
in DTS directly?

Thanks
barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/4 v4] pinmux: add a driver for the U300 pinmux

[Barry Song]

Hi Linus,
This patch can't compile
> +
> +/**
> + * @dev: a pointer back to containing device
> + * @virtbase: the offset to the controller in virtual memory
> + */
> +struct u300_pmx {
> +       struct device *dev;
> +       struct pinmux_dev *pmx;

no this structure in head file, now it is pinctrl_desc.

> +       u32 phybase;
> +       u32 physize;
> +       void __iomem *virtbase;
> +};

> +       /* Now register the pin controller and all pins it handles */
> +       upmx->pctl = pinctrl_register(&u300_pmx_desc, &pdev->dev, upmx);

no this field in upmx structure.

> +       if (IS_ERR(upmx->pctl)) {

Did you send the wrong version?

-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/4 v4] drivers: create a pin control subsystem

[Barry Song]

> +int foo_list(struct pinmux_dev *pmxdev, unsigned selector)

pinctrl_dev?

> +{
> +       if (selector >= ARRAY_SIZE(myfuncs))
> +               return -EINVAL;
> +       return 0;
> +}
> +
> +const char *foo_get_fname(struct pinmux_dev *pmxdev, unsigned selector)

pinctrl_dev?

> +{
> +       if (selector >= ARRAY_SIZE(myfuncs))
> +               return NULL;
> +       return myfuncs[selector].name;
> +}
> +
> +static int foo_get_pins(struct pinmux_dev *pmxdev, unsigned selector,
> +                       unsigned ** const pins, unsigned * const num_pins)

pinctrl_dev?

> +{
> +       if (selector >= ARRAY_SIZE(myfuncs))
> +               return -EINVAL;
> +       *pins = myfuncs[selector].pins;
> +       *num_pins = myfuncs[selector].num_pins;
> +       return 0;
> +}
> +
> +int foo_enable(struct pinmux_dev *pmxdev, unsigned selector)
> +{
> +       if (selector < ARRAY_SIZE(myfuncs))
> +               write((read(MUX)|(1< +               return 0;
> +       }
> +       return -EINVAL;
> +}
> +
> +int foo_disable(struct pinmux_dev *pmxdev, unsigned selector)

pinctrl_dev?

-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/4 v4] pinmux: add a driver for the U300 pinmux

[Barry Song]

> +/**
> + * @dev: a pointer back to containing device
> + * @virtbase: the offset to the controller in virtual memory
> + */
> +struct u300_pmx {
> +       struct device *dev;
> +       struct pinmux_dev *pmx;

 pinctrl_dev?

> +static int u300_pmx_enable(struct pinmux_dev *pmxdev, unsigned selector)

 pinctrl_dev?

> +{
> +       struct u300_pmx *upmx;
> +
> +       if (selector >= ARRAY_SIZE(u300_pmx_funcs))
> +               return -EINVAL;
> +       upmx = pmxdev_get_drvdata(pmxdev);
> +       u300_pmx_endisable(upmx, selector, true);
> +
> +       return 0;
> +}
> +
> +static void u300_pmx_disable(struct pinmux_dev *pmxdev, unsigned selector)

 pinctrl_dev?

> +{
> +       struct u300_pmx *upmx;
> +
> +       if (selector >= ARRAY_SIZE(u300_pmx_funcs))
> +               return;
> +       upmx = pmxdev_get_drvdata(pmxdev);

pctrldev_get_drvdata?

> +       u300_pmx_endisable(upmx, selector, false);
> +}
> +
> +static int u300_pmx_list(struct pinmux_dev *pmxdev, unsigned selector)

 pinctrl_dev?

> +{
> +       if (selector >= ARRAY_SIZE(u300_pmx_funcs))
> +               return -EINVAL;
> +       return 0;
> +}
> +
> +static const char *u300_pmx_get_fname(struct pinmux_dev *pmxdev,
> +                                     unsigned selector)

 pinctrl_dev?

> +{
> +       if (selector >= ARRAY_SIZE(u300_pmx_funcs))
> +               return NULL;
> +       return u300_pmx_funcs[selector].name;
> +}
> +
> +static int u300_pmx_get_pins(struct pinmux_dev *pmxdev, unsigned selector,
> +                            unsigned ** const pins, unsigned * const 
> num_pins)

 pinctrl_dev?

> +{
> +       if (selector >= ARRAY_SIZE(u300_pmx_funcs))
> +               return -EINVAL;
> +       *pins = (unsigned *) u300_pmx_funcs[selector].pins;
> +       *num_pins = u300_pmx_funcs[selector].num_pins;
> +       return 0;
> +}
> +
> +static void u300_dbg_show(struct pinmux_dev *pmxdev, struct seq_file *s,

 pinctrl_dev?

> +                  unsigned offset)
> +{
> +       seq_printf(s, " " DRIVER_NAME);
> +}
> +
> +static struct pinmux_ops u300_pmx_ops = {
> +       .list_functions = u300_pmx_list,
> +       .get_function_name = u300_pmx_get_fname,
> +       .get_function_pins = u300_pmx_get_pins,
> +       .enable = u300_pmx_enable,
> +       .disable = u300_pmx_disable,
> +       .dbg_show = u300_dbg_show,
> +};
> +
> +static struct pinmux_desc u300_pmx_desc = {
> +       .name = DRIVER_NAME,
> +       .pins = u300_pads,
> +       .npins = ARRAY_SIZE(u300_pads),
> +       .maxpin = U300_NUM_PADS-1,
> +       .pmxops = &u300_pmx_ops,
> +       .owner = THIS_MODULE,
> +};
> +
> +static int __init u300_pmx_probe(struct platform_device *pdev)
> +{
> +       int ret;
> +       struct u300_pmx *upmx;
> +       struct resource *res;
> +
> +       /* Create state holders etc for this driver */
> +       upmx = kzalloc(sizeof(struct u300_pmx), GFP_KERNEL);
> +       if (!upmx)
> +               return -ENOMEM;
> +
> +       upmx->dev = &pdev->dev;
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       if (!res) {
> +               ret = -ENOENT;
> +               goto out_no_resource;
> +       }
> +       upmx->phybase = res->start;
> +       upmx->physize = resource_size(res);
> +
> +       if (request_mem_region(upmx->phybase, upmx->physize,
> +                              DRIVER_NAME) == NULL) {
> +               ret = -EBUSY;
> +               goto out_no_memregion;
> +       }
> +
> +       upmx->virtbase = ioremap(upmx->phybase, upmx->physize);
> +       if (!upmx->virtbase) {
> +               ret = -ENOMEM;
> +               goto out_no_remap;
> +       }
> +
> +       /* Now register the pin controller and all pins it handles */
> +       upmx->pctl = pinctrl_register(&u300_pmx_desc, &pdev->dev, upmx);
> +       if (IS_ERR(upmx->pctl)) {
> +               dev_err(&pdev->dev, "could not register U300 pinmux 
> driver\n");
> +               ret = PTR_ERR(upmx->pmx);
> +               goto out_no_pmx;
> +       }
> +       platform_set_drvdata(pdev, upmx);
> +
> +       dev_info(&pdev->dev, "initialized U300 pinmux driver\n");
> +
> +       return 0;
> +
> +out_no_pmx:
> +       iounmap(upmx->virtbase);
> +out_no_remap:
> +       platform_set_drvdata(pdev, NULL);

where have you set drv data to non-NULL?

> +out_no_memregion:
> +       release_mem_region(upmx->phybase, upmx->physize);
> +out_no_resource:
> +       kfree(upmx);
> +       return ret;
> +}
> +

-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 0/4 v4] pin controller subsystem v4

[Barry Song]

2011/8/22 Linus Walleij :
> On Sun, Aug 21, 2011 at 4:42 PM, Barry Song <21cn...@gmail.com> wrote:
>
>> it seems there is not an actual example that gpio requests pin from
>> pinctrl yet. i might give one on SiRFprimaII.
>
> No good example yet, no.
>
> The reason is that for the U300 that I use as guinea pig, the
> GPIO driver is tangled up in discussions about how to handle
> the special control mechanics like requesting muxing and
> biasing pins. Right now it seems easier to rewrite all that
> to use the new pinctrl subsystem rather than actually trying
> to work it into the GPIO subsystem first and refactor from
> there, and that needs quite a bit of upfront work...

Do you want the pinmux_request_gpio called by the gpiolib driver or by
every device driver who uses this gpio?
Do you think the following make sense in gpiolib driver?
static int xxx_gpio_request(struct gpio_chip *chip, unsigned offset)
{
int ret = 0;

ret = pinmux_request_gpio(chip->base + offset);
if (ret)
goto out;
.
out:
return ret;
}


>
> Linus Walleij
>

Thanks
Barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/4 v4] drivers: create a pin control subsystem

[Barry Song]

2011/8/19 Linus Walleij :
> From: Linus Walleij 
>
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
>
> Currently it handled pinmuxing, i.e. assign electronic functions
> to groups of pins of pins on primarily PGA and BGA type of chip
> packages and common in embedded systems.
>
> The plan is to also handle other I/O pin control aspects such as
> biasing, driving, input properties such as schmitt-triggering,
> load capacitance etc within this subsystem.
>
> This is being done to depopulate the arch/arm/* directory of such
> custom drivers and try to abstract the infrastructure they all
> need. See the Documentation/pinmux.txt file that is part of this
> patch for more details.
>
> Cc: Grant Likely 
> Cc: Stephen Warren 
> Cc: Joe Perches 
> Cc: Russell King 
> Signed-off-by: Linus Walleij 

Tested-by: Barry Song 

even there are still many discussions about data model and
device/function mapping, it is basically usable to CSR SiRFprimaII.
Then i moved the old prima2 pinmux to this framework and made some
basic tests.
Basic APIs like pinmux_get/pinmux_enable/pinmux_disable/pinmux_put
should be working.

Linus, i'll also send the patch of csr pinmux prototype. you might
review and take it as another example except your stericsson U300 and
take care while you merge pinmux.

> ---
>  Documentation/ABI/testing/sysfs-class-pinmux |   11 +
>  Documentation/pinctrl.txt                    |  512 +++
>  MAINTAINERS                                  |    5 +
>  drivers/Kconfig                              |    4 +
>  drivers/Makefile                             |    2 +
>  drivers/pinctrl/Kconfig                      |   29 ++
>  drivers/pinctrl/Makefile                     |    6 +
>  drivers/pinctrl/core.c                       |  437 
>  drivers/pinctrl/core.h                       |   22 +
>  drivers/pinctrl/pinmux.c                     |  700 
> ++
>  drivers/pinctrl/pinmux.h                     |    4 +
>  include/linux/pinctrl/machine.h              |   62 +++
>  include/linux/pinctrl/pinctrl.h              |  120 +
>  include/linux/pinctrl/pinmux.h               |  122 +
>  14 files changed, 2036 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-pinmux
>  create mode 100644 Documentation/pinctrl.txt
>  create mode 100644 drivers/pinctrl/Kconfig
>  create mode 100644 drivers/pinctrl/Makefile
>  create mode 100644 drivers/pinctrl/core.c
>  create mode 100644 drivers/pinctrl/core.h
>  create mode 100644 drivers/pinctrl/pinmux.c
>  create mode 100644 drivers/pinctrl/pinmux.h
>  create mode 100644 include/linux/pinctrl/machine.h
>  create mode 100644 include/linux/pinctrl/pinctrl.h
>  create mode 100644 include/linux/pinctrl/pinmux.h
>

Thanks
Barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/4 v5] drivers: create a pin control subsystem v5

[Barry Song]

> +Interaction with the GPIO subsystem
> +===
> +
> +The GPIO drivers may want to perform operations of various types on the
> same
> +physical pins that are also registered as GPIO pins.
> +
> +Since the pin controller subsystem have its pinspace local to the pin
> +controller we need a mapping so that the pin control subsystem can figure
> out
> +which pin controller handles control of a certain GPIO pin. Since a single
> +pin controller may be muxing several GPIO ranges (typically SoCs that have
> +one set of pins but internally several GPIO silicon blocks, each modeled as
> +a struct gpio_chip) any number of GPIO ranges can be added to a pin
> controller
> +instance like this:
> +
> +struct gpio_chip chip_a;
> +struct gpio_chip chip_b;
> +
> +static struct pinctrl_gpio_range gpio_range_a = {
> + .name = "chip a",
> + .id = 0,
> + .base = 32,
> + .npins = 16,
> + .gc = &chip_a;
> +};
> +
> +static struct pinctrl_gpio_range gpio_range_a = {
> + .name = "chip b",
> + .id = 0,
> + .base = 48,
> + .npins = 8,
> + .gc = &chip_b;
> +};
> +
> +
> +{
> + struct pinctrl_dev *pctl;
> + ...
> + pinctrl_add_gpio_range(pctl, &gpio_range_a);
> + pinctrl_add_gpio_range(pctl, &gpio_range_b);

people might like a pinctrl_add_gpio_range*s* too.

-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/4 v6] pinmux: add a driver for the U300 pinmux

[Barry Song]

2011/9/13 Linus Walleij :
> On Fri, Sep 2, 2011 at 6:04 PM, Stephen Warren  wrote:
>> Linus Walleij wrote at Friday, September 02, 2011 2:12 AM:
>>> On Thu, Sep 1, 2011 at 11:33 PM, Stephen Warren  wrote:
>>>
>>> >> +static const struct u300_pmx_func u300_pmx_functions[] = {
>>> >> +     {
>>> >> +             .name = "power",
>>> >> +             .groups = { POWERGRP_INDEX },
>>> >> +             /* Mask is N/A */
>>> >> +     },
>>> >
>>> > Hmmm. That's a lot of _INDEX defines that'd need to be set up, at least
>>> > to fully represent a chip like Tegra. Can the pinmux core be modified
>>> > such that the group list is an array of names (char*) rather than the
>>> > actual numeric IDs of the groups? Still, perhaps we could use the enum
>>> > we already have for this, so perhaps it isn't a big deal...
>>>
>>> Well I could think about a lot of ways to do this, but it's basically up
>>> to the driver, the U300 is just some simple example of what you can
>>> do, it's just trying to satisfy the API.
>>>
>>> Maybe as part of writing the nVidia driver you find a clever
>>> mechanism for doing this, if it's looking generally useful at that
>>> point then let's move it to the core I'd say.
>>
>> The reason I asked about the pinmux core handling this is because the
>> driver op get_function_groups:
>>
>> +       int (*get_function_groups) (struct pinctrl_dev *pctldev,
>> +                                 unsigned selector,
>> +                                 unsigned ** const groups,
>> +                                 unsigned * const num_groups);
>>
>> returns an array of integer indexes. I think the only way to get rid of
>> the index definitions in the drivers is to allow get_function_groups to
>> return an array of strings instead.
>
> OK good idea, I reworked this interface to get an array of strings
> instead, I've been told several times to use strings rather than numbers
> when possible, so I think this is the right thing to do.
>
> Check it out in v7!

well. we'll rebase prima2 pinmux on v7.

>
> Yours,
> Linus Walleij
>
-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/2] pinmux: add a driver for the U300 pinmux

[Barry Song]

> +static int __init u300_pmx_probe(struct platform_device *pdev)
> +{
> +       int ret;
> +       struct u300_pmx *upmx;
> +       struct resource *res;
> +
> +       /* Create state holders etc for this driver */
> +       upmx = devm_kzalloc(&pdev->dev, sizeof(struct u300_pmx), GFP_KERNEL);

and this would be "devm_kzalloc(&pdev->dev, sizeof(*upmx), GFP_KERNEL); " ?

> +       if (!upmx)
> +               return -ENOMEM;
> +
> +       upmx->dev = &pdev->dev;
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       if (!res) {
> +               ret = -ENOENT;
> +               goto out_no_resource;
> +       }
> +       upmx->phybase = res->start;
> +       upmx->physize = resource_size(res);
> +
> +       if (request_mem_region(upmx->phybase, upmx->physize,
> +                              DRIVER_NAME) == NULL) {
> +               ret = -EBUSY;
> +               goto out_no_memregion;
> +       }
> +
> +       upmx->virtbase = ioremap(upmx->phybase, upmx->physize);
> +       if (!upmx->virtbase) {
> +               ret = -ENOMEM;
> +               goto out_no_remap;
> +       }
> +
> +       upmx->pctl = pinctrl_register(&u300_pmx_desc, &pdev->dev, upmx);
> +       if (IS_ERR(upmx->pctl)) {
> +               dev_err(&pdev->dev, "could not register U300 pinmux 
> driver\n");
> +               ret = PTR_ERR(upmx->pctl);
> +               goto out_no_pmx;
> +       }
> +
> +       /* We will handle a range of GPIO pins */
> +       pinctrl_add_gpio_range(upmx->pctl, &u300_gpio_range);
> +
> +       platform_set_drvdata(pdev, upmx);
> +
> +       u300_pmx_dumpregs(upmx);
> +
> +       dev_info(&pdev->dev, "initialized U300 pinmux driver\n");
> +
> +       return 0;
> +
> +out_no_pmx:
> +       iounmap(upmx->virtbase);
> +out_no_remap:
> +       platform_set_drvdata(pdev, NULL);
> +out_no_memregion:
> +       release_mem_region(upmx->phybase, upmx->physize);
> +out_no_resource:
> +       devm_kfree(&pdev->dev, upmx);
> +       return ret;
> +}
> +
-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/2] pinmux: add a driver for the U300 pinmux

[Barry Song]

> +static void __init u300_pmx_dumpregs(struct u300_pmx *upmx)
> +{
> +       u16 regval;
> +       int i;
> +
> +       for (i = 0; i < ARRAY_SIZE(u300_pmx_registers); i++) {
> +               regval = readw(upmx->virtbase + u300_pmx_registers[i]);
> +               dev_info(upmx->dev, "PMX%u: 0x%04x\n", i, regval);
> +       }
> +}
> +

is this a debug information or do you want it to be in mainline?

-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/2] pinmux: add a driver for the U300 pinmux

[Barry Song]

2011/10/10 Linus Walleij :
> On Sat, Oct 8, 2011 at 11:09 AM, Barry Song <21cn...@gmail.com> wrote:
>>> +static void __init u300_pmx_dumpregs(struct u300_pmx *upmx)
>>> +{
>>> +       u16 regval;
>>> +       int i;
>>> +
>>> +       for (i = 0; i < ARRAY_SIZE(u300_pmx_registers); i++) {
>>> +               regval = readw(upmx->virtbase + u300_pmx_registers[i]);
>>> +               dev_info(upmx->dev, "PMX%u: 0x%04x\n", i, regval);
>>> +       }
>>> +}
>>
>> is this a debug information or do you want it to be in mainline?
>
> Debug info, I'll delete it. Not that it hurt, but I'll kill it.
>
>>> +       /* Create state holders etc for this driver */
>>> +       upmx = devm_kzalloc(&pdev->dev, sizeof(struct u300_pmx), 
>>> GFP_KERNEL);
>>
>> and this would be "devm_kzalloc(&pdev->dev, sizeof(*upmx), GFP_KERNEL); " ?
>
> Same semantic effect, but if you prefer it that way, sure :-)
>
> I've seen both used in the kernel before...

coding style document says :
"
  Chapter 14: Allocating memory

  The kernel provides the following general purpose memory allocators:
  kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc().  Please refer to
  the API documentation for further information about them.

 The preferred form for passing a size of a struct is the following:

  p = kmalloc(sizeof(*p), ...);

  The alternative form where struct name is spelled out hurts readability and
  introduces an opportunity for a bug when the pointer variable type is changed
  but the corresponding sizeof that is passed to a memory allocator is not.
"
>
> Can I have your Reviewed-by: tag after this?

yes. of course.

>
> Linus Walleij
>
Thanks
barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v10] pinctrl: add a driver for the U300 pinmux

[Barry Song]

2011/10/10 Linus Walleij :
> From: Linus Walleij 
>
> This adds a driver for the U300 pinmux portions of the system
> controller "SYSCON". It also serves as an example of how to use
> the pinmux subsystem. This driver also houses the platform data
> for the only supported platform.
>
> This deletes the old U300 driver in arch/arm/mach-u300 and
> replace it with a driver using the new subsystem.
>
> The new driver is considerably fatter than the old one, but it
> also registers all 467 pins of the system and adds the power
> and EMIF pin groups and corresponding functions. The idea
> is to use this driver as a a reference for other
> implementation so it needs to be as complete and verbose
> as possible.
>
> Signed-off-by: Linus Walleij 

Reviewed-by: Barry Song <21cn...@gmail.com>

> ---
> ChangeLog v9 -> v10
> - Removed debug register dump (review from Barry Song)
> - Allocate sizeof(*ptr) instead of sizeof(struct foo)


-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/2] pinctrl: add a generic control interface

[Barry Song]

2011/10/20 Shawn Guo :
>>  #ifdef CONFIG_DEBUG_FS
>>
>>  static int pinctrl_pins_show(struct seq_file *s, void *what)
>> diff --git a/include/linux/pinctrl/pinctrl.h 
>> b/include/linux/pinctrl/pinctrl.h
>> index 4f8d208..189c047 100644
>> --- a/include/linux/pinctrl/pinctrl.h
>> +++ b/include/linux/pinctrl/pinctrl.h
>> @@ -19,6 +19,87 @@
>>  #include 
>>  #include 
>>
>> +/**
>> + * enum pin_config_param - possible pin configuration parameters
>> + * @PIN_CONFIG_BIAS_UNKNOWN: this bias mode is not known to us
>> + * @PIN_CONFIG_BIAS_FLOAT: no specific bias, the pin will float or state
>> + *   is not controlled by software
>> + * @PIN_CONFIG_BIAS_HIGH_IMPEDANCE: the pin will be set to a high impedance
>> + *   mode, also know as "third-state" (tristate) or "high-Z" or "floating".
>> + *   On output pins this effectively disconnects the pin, which is useful
>> + *   if for example some other pin is going to drive the signal connected
>> + *   to it for a while. Pins used for input are usually always high
>> + *   impedance.
>> + * @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with high
>> + *   impedance to VDD), if the controller supports specifying a certain
>> + *   pull-up resistance, this is given as an argument (in Ohms) when
>> + *   setting this parameter
>> + * @PIN_CONFIG_BIAS_PULL_DOWN: the pin will be pulled down (usually with 
>> high
>> + *   impedance to GROUND), if the controller supports specifying a certain
>> + *   pull-down resistance, this is given as an argument (in Ohms) when
>> + *   setting this parameter
>> + * @PIN_CONFIG_BIAS_HIGH: the pin will be wired high, connected to VDD
>> + * @PIN_CONFIG_BIAS_GROUND: the pin will be grounded, connected to GROUND
>> + * @PIN_CONFIG_DRIVE_UNKNOWN: we don't know the drive mode of this pin, for
>> + *   example since it is controlled by hardware or the information is not
>> + *   accessible but we need a meaningful enumerator in e.g. initialization
>> + *   code
>> + * @PIN_CONFIG_DRIVE_PUSH_PULL: the pin will be driven actively high and
>> + *   low, this is the most typical case and is typically achieved with two
>> + *   active transistors on the output. If the pin can support different
>> + *   drive strengths for push/pull, the strength is given on a custom format
>> + *   as argument when setting pins to this mode
>> + * @PIN_CONFIG_DRIVE_OPEN_DRAIN: the pin will be driven with open drain 
>> (open
>> + *   collector) which means it is usually wired with other output ports
>> + *   which are then pulled up with an external resistor. If the pin can
>> + *   support different drive strengths for the open drain pin, the strength
>> + *   is given on a custom format as argument when setting pins to this mode
>> + * @PIN_CONFIG_DRIVE_OPEN_SOURCE: the pin will be driven with open drain
>> + *   (open emitter) which is the same as open drain mutatis mutandis but
>> + *   pulled to ground. If the pin can support different drive strengths for
>> + *   the open drain pin, the strength is given on a custom format as
>> + *   argument when setting pins to this mode
>> + * @PIN_CONFIG_DRIVE_OFF: the pin is set to inactive drive mode, off
>> + * @PIN_CONFIG_INPUT_SCHMITT: this will configure an input pin to run in
>> + *   schmitt-trigger mode. If the schmitt-trigger has adjustable hysteresis,
>> + *   the threshold value is given on a custom format as argument when
>> + *   setting pins to this mode
>> + * @PIN_CONFIG_SLEW_RATE_RISING: this will configure the slew rate for 
>> rising
>> + *   signals on the pin. The argument gives the rise time in nanoseconds
>> + * @PIN_CONFIG_SLEW_RATE_FALLING: this will configure the slew rate for 
>> falling
>> + *   signals on the pin. The argument gives the fall time in nanoseconds
>> + * @PIN_CONFIG_LOAD_CAPACITANCE: some pins have inductive characteristics 
>> and
>> + *   will deform waveforms when signals are transmitted on them, by
>> + *   applying a load capacitance, the waveform can be rectified. The
>> + *   argument gives the load capacitance in picofarad (pF)
>> + * @PIN_CONFIG_WAKEUP_ENABLE: this will configure an input pin such that if 
>> a
>> + *   signal transition arrives at the pin when the pin controller/system
>> + *   is sleeping, it will wake up the system
>> + * @PIN_CONFIG_END: this is the last enumerator for pin configurations, if
>> + *   you need to pass in custom configurations to the pin controller, use
>> + *   PIN_CONFIG_END+1 as the base offset
>> + */
>> +enum pin_config_param {
>> +     PIN_CONFIG_BIAS_UNKNOWN,
>> +     PIN_CONFIG_BIAS_FLOAT,
>> +     PIN_CONFIG_BIAS_HIGH_IMPEDANCE,
>> +     PIN_CONFIG_BIAS_PULL_UP,
>> +     PIN_CONFIG_BIAS_PULL_DOWN,
>> +     PIN_CONFIG_BIAS_HIGH,
>> +     PIN_CONFIG_BIAS_GROUND,
>> +     PIN_CONFIG_DRIVE_UNKNOWN,
>> +     PIN_CONFIG_DRIVE_PUSH_PULL,
>> +     PIN_CONFIG_DRIVE_OPEN_DRAIN,
>> +     PIN_CONFIG_DRIVE_OPEN_SOURCE,
>> +     PIN_CONFIG_DRIVE_OFF,
>> +     PIN_CONFIG_INPUT_SCHMITT,
>> +     PIN_CONFIG_SLEW_RATE_RISING,

Re: [PATCH 2/4] pinctrl: Remove unsafe __refdata

[Barry Song]

2011/10/20 Stephen Warren :
> A pin controller's pin definitions are used both during pinctrl_register()
> and pinctrl_unregister(). The latter happens outside of __init/__devinit
> time, and hence it is unsafe to mark the pin array as __refdata.

Thanks.
Acked-by: Barry Song 

missed this when porting prima2 pinmux driver. is this __refdata used
just due to a typo?
i don't find prima2 pinctrl_pin_desc tables uses any code/data in __init/__exit.

if we need the table to be in init section, we should have used
__initconst/__initdata instead.

>
> Signed-off-by: Stephen Warren 
> ---
>  drivers/pinctrl/pinmux-sirf.c |    2 +-
>  drivers/pinctrl/pinmux-u300.c |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinmux-sirf.c b/drivers/pinctrl/pinmux-sirf.c
> index cad4f5d..3bc083c 100644
> --- a/drivers/pinctrl/pinmux-sirf.c
> +++ b/drivers/pinctrl/pinmux-sirf.c
> @@ -30,7 +30,7 @@
>  * pad list for the pinmux subsystem
>  * refer to CS-131858-DC-6A.xls
>  */
> -static const struct pinctrl_pin_desc __refdata sirfsoc_pads[] = {
> +static const struct pinctrl_pin_desc sirfsoc_pads[] = {
>        PINCTRL_PIN(4, "pwm0"),
>        PINCTRL_PIN(5, "pwm1"),
>        PINCTRL_PIN(6, "pwm2"),
> diff --git a/drivers/pinctrl/pinmux-u300.c b/drivers/pinctrl/pinmux-u300.c
> index be6e04d..ed8bcd8 100644
> --- a/drivers/pinctrl/pinmux-u300.c
> +++ b/drivers/pinctrl/pinmux-u300.c
> @@ -179,7 +179,7 @@
>  #define U300_NUM_PADS 467
>
>  /* Pad names for the pinmux subsystem */
> -static const struct pinctrl_pin_desc __refdata u300_pads[] = {
> +static const struct pinctrl_pin_desc u300_pads[] = {
>        /* Pads along the top edge of the chip */
>        PINCTRL_PIN(0, "P PAD VDD 28"),
>        PINCTRL_PIN(1, "P PAD GND 28"),
> --
> 1.7.0.4

-barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

linaro powertop doesn't work well on a single core ARM SoC

[Barry Song]

Hi Tony/Amit,
anybody has tried to use powertop from linaro on a single core ARM
SoC? What i am using is
git://android.git.linaro.org/platform/external/powertop.git.
I got two questions:
1. powertop will crash in handle_one_cpu() due to it gets wrong cpu
number(-1), then i made the following change to make it work:

powertop: fix segment fault for single cpu env

Signed-off-by: Barry Song 

diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
index 29fc72c..c56c746 100644
--- a/cpu/cpu.cpp
+++ b/cpu/cpu.cpp
@@ -302,6 +302,9 @@ void enumerate_cpus(void)
model = strtoull(c, NULL, 10);
}
}
+
+   if (number == -1)
+   number = 0;
if (strncasecmp(line, "bogomips\t", 9) == 0) {
handle_one_cpu(number, vendor, family, model);
set_max_cpu(number);

2. after fixing problem1, powertop can run on PrimaII, but i always
get 0.0% for every p states as you can see from attached pic.
but if we check cpufreq stats in
/sys/devices/system/cpu/cpu0/cpufreq/stats, my system does change freq
based on ondemand.

# cat time_in_state
80 2064
60 181
40 341
20 60381

# cat trans_table
   From  :To
 :80604020
   80: 0131314
   60: 5 0 3 5
   40: 5 0 011
   20:29 0 0 0

# cat total_trans
98

does anyone have experiences about it?

Thanks
barry
<>___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linaro powertop doesn't work well on a single core ARM SoC

[Barry Song]

Hi Amit,

Thanks!

2011/12/12 Amit Kachhap :
> Hi Barry,
>
> You fix for invalid cpu id looks fine.

so will you merge some fixes into linaro tree?

> As for the P states this new
> powertop combines with the cpuidle numbers. so if the system is highly
> idle it means processor is idle and hence P states is shown as 0.

i did have a highly idle in my last test as you can see from attached
picture. my C state "WFI" holds 98%.

but i wrote a program:
main()
{
while(1);
}
and run it, then it makes C state to 0%.

but i still got all p state with 0%.

anything have i missed?

>
> Thanks,
> Amit Daniel
>
>
> On 12 December 2011 15:55, Barry Song <21cn...@gmail.com> wrote:
>> Hi Tony/Amit,
>> anybody has tried to use powertop from linaro on a single core ARM
>> SoC? What i am using is
>> git://android.git.linaro.org/platform/external/powertop.git.
>> I got two questions:
>> 1. powertop will crash in handle_one_cpu() due to it gets wrong cpu
>> number(-1), then i made the following change to make it work:
>>
>>    powertop: fix segment fault for single cpu env
>>
>>    Signed-off-by: Barry Song 
>>
>> diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
>> index 29fc72c..c56c746 100644
>> --- a/cpu/cpu.cpp
>> +++ b/cpu/cpu.cpp
>> @@ -302,6 +302,9 @@ void enumerate_cpus(void)
>>                                model = strtoull(c, NULL, 10);
>>                        }
>>                }
>> +
>> +               if (number == -1)
>> +                       number = 0;
>>                if (strncasecmp(line, "bogomips\t", 9) == 0) {
>>                        handle_one_cpu(number, vendor, family, model);
>>                        set_max_cpu(number);
>>
>> 2. after fixing problem1, powertop can run on PrimaII, but i always
>> get 0.0% for every p states as you can see from attached pic.
>> but if we check cpufreq stats in
>> /sys/devices/system/cpu/cpu0/cpufreq/stats, my system does change freq
>> based on ondemand.
>>
>> # cat time_in_state
>> 80 2064
>> 60 181
>> 40 341
>> 20 60381
>>
>> # cat trans_table
>>   From  :    To
>>         :    80    60    40    20
>>   80:         0        13        13        14
>>   60:         5         0         3         5
>>   40:         5         0         0        11
>>   20:        29         0         0         0
>>
>> # cat total_trans
>> 98
>>
>> does anyone have experiences about it?
>>
>> Thanks
>> barry

Thanks
barry
<>___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linaro powertop doesn't work well on a single core ARM SoC

[Barry Song]

ok now. the reason is the powertop depends on
CONFIG_EVENT_POWER_TRACING_DEPRECATED, after selecting it, powertop
gets to work on SiRFprimaII.
Thanks
barry
2011/12/14 Barry Song <21cn...@gmail.com>:
> Hi Amit,
>
> Thanks!
>
> 2011/12/12 Amit Kachhap :
>> Hi Barry,
>>
>> You fix for invalid cpu id looks fine.
>
> so will you merge some fixes into linaro tree?
>
>> As for the P states this new
>> powertop combines with the cpuidle numbers. so if the system is highly
>> idle it means processor is idle and hence P states is shown as 0.
>
> i did have a highly idle in my last test as you can see from attached
> picture. my C state "WFI" holds 98%.
>
> but i wrote a program:
> main()
> {
>        while(1);
> }
> and run it, then it makes C state to 0%.
>
> but i still got all p state with 0%.
>
> anything have i missed?
>
>>
>> Thanks,
>> Amit Daniel
>>
>>
>> On 12 December 2011 15:55, Barry Song <21cn...@gmail.com> wrote:
>>> Hi Tony/Amit,
>>> anybody has tried to use powertop from linaro on a single core ARM
>>> SoC? What i am using is
>>> git://android.git.linaro.org/platform/external/powertop.git.
>>> I got two questions:
>>> 1. powertop will crash in handle_one_cpu() due to it gets wrong cpu
>>> number(-1), then i made the following change to make it work:
>>>
>>>    powertop: fix segment fault for single cpu env
>>>
>>>    Signed-off-by: Barry Song 
>>>
>>> diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
>>> index 29fc72c..c56c746 100644
>>> --- a/cpu/cpu.cpp
>>> +++ b/cpu/cpu.cpp
>>> @@ -302,6 +302,9 @@ void enumerate_cpus(void)
>>>                                model = strtoull(c, NULL, 10);
>>>                        }
>>>                }
>>> +
>>> +               if (number == -1)
>>> +                       number = 0;
>>>                if (strncasecmp(line, "bogomips\t", 9) == 0) {
>>>                        handle_one_cpu(number, vendor, family, model);
>>>                        set_max_cpu(number);
>>>
>>> 2. after fixing problem1, powertop can run on PrimaII, but i always
>>> get 0.0% for every p states as you can see from attached pic.
>>> but if we check cpufreq stats in
>>> /sys/devices/system/cpu/cpu0/cpufreq/stats, my system does change freq
>>> based on ondemand.
>>>
>>> # cat time_in_state
>>> 80 2064
>>> 60 181
>>> 40 341
>>> 20 60381
>>>
>>> # cat trans_table
>>>   From  :    To
>>>         :    80    60    40    20
>>>   80:         0        13        13        14
>>>   60:         5         0         3         5
>>>   40:         5         0         0        11
>>>   20:        29         0         0         0
>>>
>>> # cat total_trans
>>> 98
>>>
>>> does anyone have experiences about it?
>>>
>>> Thanks
>>> barry
>
> Thanks
> barry
<>___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

how to sync with mainline

[Barry Song]

Hi All,
I am a freshman to linaro. I found people sent some patches to
linaro-dev@lists.linaro.org. Here I have 2 questions:
1. Whether will linaro send those patches based on newest tree to
Linus' mainline or not?  Or developers need to send those patches to
mainline by themselves?
Is there any document to describe how linaro contribute patches to mainline?
2. If other SoC companies work based on linaro's
linux-linaro-next.git, whether it will not need to work based on
Linus' tree since linux-linaro-next.git will sync with mainline?
Thanks
Barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: how to sync with mainline

[Barry Song]

Hi Lee,
Great! Thanks a lot. It looks like the communication between linaro
and mainline is that linaro can backport some bug fixes and features
from mainline to linaro tree. Linaro doesn't help to review patches
and send to mainline.
Then I have two more questions
1. is there a detailed list of backport and bug fix in linaro kernel
tree since those are the difference between mainline and linaro tree?
2. will linaro accept patches from non-member companies and help to
maintain, I mean a SoC company which doesn't join linaro?

Thanks
Barry

2011/3/8 Lee Jones :
> Hi Barry,
>
>> I am a freshman to linaro. I found people sent some patches to
>> linaro-dev@lists.linaro.org. Here I have 2 questions:
>> 1. Whether will linaro send those patches based on newest tree to
>> Linus' mainline or not?  Or developers need to send those patches to
>> mainline by themselves?
>
> Authors need to post their own patches to the relevant mailing lists [1]
> for inclusion into the Mainline kernel.
>
>> Is there any document to describe how linaro contribute patches to
> mainline?
>
> As above.
>
>> 2. If other SoC companies work based on linaro's
>> linux-linaro-next.git, whether it will not need to work based on
>> Linus' tree since linux-linaro-next.git will sync with mainline?
>
> If your patches are going into Mainline, they will need to be built
> against the Mainline tree. If they are not going upstream, then the
> chances are they won't be accepted into the Linaro tree either.
>
> [1] http://vger.kernel.org/vger-lists.html
>
> Kind regards,
> Lee
>



-- 
Barry Song, Linux Kernel Developer
http://21cnbao.blog.51cto.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: how to sync with mainline

[Barry Song]

Thanks. Amit.

2011/3/8 Amit Kucheria :
> On Tue, Mar 8, 2011 at 10:34 AM, Barry Song <21cn...@gmail.com> wrote:
>> Hi Lee,
>> Great! Thanks a lot. It looks like the communication between linaro
>> and mainline is that linaro can backport some bug fixes and features
>> from mainline to linaro tree. Linaro doesn't help to review patches
>> and send to mainline.
>
> We prefer to see it this way:
>
> Develop against mainline and get those features integrated there. Keep
> linaro-dev in cc if these are features might be something Linaro would
> care about.
>
> The Linaro kernel (maintained by Nicolas Pitre and packaged by John
> Rigby) is a sort of technology demonstration to show what we achieve
> every 6 months. Some patches in it are backports, others are features
> that are still under review in mainline. But I doubt if Nicolas will
> take un-reviewed code directly into his tree.
>
>> Then I have two more questions
>> 1. is there a detailed list of backport and bug fix in linaro kernel
>> tree since those are the difference between mainline and linaro tree?
>
> 'git log' with the right incantations should be able to tell you that.
> Look up Nicolas' email announcements for the high-level overview of
> what he has integrated.
>
>> 2. will linaro accept patches from non-member companies and help to
>> maintain, I mean a SoC company which doesn't join linaro?
>
> Linaro doesn't want to maintain dead code that isn't going upstream.
> It won't even do it for member companies. At most it is the incubator
> where the code lives and gets wider testing _while_ it is being
> reworked for mainline.

If patches are going mainline, but they are not from members TI,
Freescale, ST-E etc, can they be merged into linaro kernel?

>
> /Amit
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: how to sync with mainline

[Barry Song]

Thanks.  Amit.

2011/3/9 Lee Jones :
> On 09/03/11 02:44, Barry Song wrote:
>> Thanks. Amit.
>>
>> 2011/3/8 Amit Kucheria :
>>> On Tue, Mar 8, 2011 at 10:34 AM, Barry Song <21cn...@gmail.com> wrote:
>>>> Hi Lee,
>>>> Great! Thanks a lot. It looks like the communication between linaro
>>>> and mainline is that linaro can backport some bug fixes and features
>>>> from mainline to linaro tree. Linaro doesn't help to review patches
>>>> and send to mainline.
>>> We prefer to see it this way:
>>>
>>> Develop against mainline and get those features integrated there. Keep
>>> linaro-dev in cc if these are features might be something Linaro would
>>> care about.
>>>
>>> The Linaro kernel (maintained by Nicolas Pitre and packaged by John
>>> Rigby) is a sort of technology demonstration to show what we achieve
>>> every 6 months. Some patches in it are backports, others are features
>>> that are still under review in mainline. But I doubt if Nicolas will
>>> take un-reviewed code directly into his tree.
>>>
>>>> Then I have two more questions
>>>> 1. is there a detailed list of backport and bug fix in linaro kernel
>>>> tree since those are the difference between mainline and linaro tree?
>>> 'git log' with the right incantations should be able to tell you that.
>>> Look up Nicolas' email announcements for the high-level overview of
>>> what he has integrated.
>>>
>>>> 2. will linaro accept patches from non-member companies and help to
>>>> maintain, I mean a SoC company which doesn't join linaro?
>>> Linaro doesn't want to maintain dead code that isn't going upstream.
>>> It won't even do it for member companies. At most it is the incubator
>>> where the code lives and gets wider testing _while_ it is being
>>> reworked for mainline.
>> If patches are going mainline, but they are not from members TI,
>> Freescale, ST-E etc, can they be merged into linaro kernel?
>
> I don't see any reason why not, but the overall decision will be made by Nico.

That's important to market.  In case customers of TI, Freescale, ST-E
are also using SoC from non-member companies, since they are using
linaro kernel and utilitis well on TI/Freescale/ST-E,
they want to use the same linaro kernel on non-member chips, if linaro
accepts and maintains non-member patches, then this tree can be useful
and customers can use the only tree as their platform to support both
member chips and non-member chips.

If so, maybe SoC companies don't need to join linaro, but they can get
the benefit of linaro too.  So what's the opinion of Nico?
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: how to sync with mainline

[Barry Song]

Thank all of you very much. My all questions have got good answers.
Comparing linaro kernel and mainline with same versions, there are a
lot of backport, bug fixes and new feature commit logs in fact. Great!

2011/3/17 Nicolas Pitre :
>
> Sorry for not answering earlier.  I was on vacation last week, and my
> email backlog is incredibly large.  I'm going through it with generous
> usage of the delete key so it is possible that I might have missed
> something.
>
> On Fri, 11 Mar 2011, Barry Song wrote:
>
>> 2011/3/9 Lee Jones :
>> > On 09/03/11 02:44, Barry Song wrote:
>> >> 2011/3/8 Amit Kucheria :
>> >>> On Tue, Mar 8, 2011 at 10:34 AM, Barry Song <21cn...@gmail.com> wrote:
>> >>>> Hi Lee,
>> >>>> Great! Thanks a lot. It looks like the communication between linaro
>> >>>> and mainline is that linaro can backport some bug fixes and features
>> >>>> from mainline to linaro tree. Linaro doesn't help to review patches
>> >>>> and send to mainline.
>> >>> We prefer to see it this way:
>> >>>
>> >>> Develop against mainline and get those features integrated there. Keep
>> >>> linaro-dev in cc if these are features might be something Linaro would
>> >>> care about.
>> >>>
>> >>> The Linaro kernel (maintained by Nicolas Pitre and packaged by John
>> >>> Rigby) is a sort of technology demonstration to show what we achieve
>> >>> every 6 months. Some patches in it are backports, others are features
>> >>> that are still under review in mainline. But I doubt if Nicolas will
>> >>> take un-reviewed code directly into his tree.
>
> Exact.
>
>> >>>> Then I have two more questions
>> >>>> 1. is there a detailed list of backport and bug fix in linaro kernel
>> >>>> tree since those are the difference between mainline and linaro tree?
>> >>> 'git log' with the right incantations should be able to tell you that.
>> >>> Look up Nicolas' email announcements for the high-level overview of
>> >>> what he has integrated.
>
> The general policy for the Linaro kernel tree is described here:
>
> https://wiki.linaro.org/WorkingGroups/KernelConsolidation/KernelTree
>
>> >>>> 2. will linaro accept patches from non-member companies and help to
>> >>>> maintain, I mean a SoC company which doesn't join linaro?
>> >>> Linaro doesn't want to maintain dead code that isn't going upstream.
>> >>> It won't even do it for member companies. At most it is the incubator
>> >>> where the code lives and gets wider testing _while_ it is being
>> >>> reworked for mainline.
>> >> If patches are going mainline, but they are not from members TI,
>> >> Freescale, ST-E etc, can they be merged into linaro kernel?
>> >
>> > I don't see any reason why not, but the overall decision will be made by 
>> > Nico.
>
> Yes they can, as long as there is some assurance that they are headed
> for mainline as well.  But the Linaro kernel won't help maintain
> patches.  Long term maintenance should be done in the upstream kernel.
>
>> That's important to market.  In case customers of TI, Freescale, ST-E
>> are also using SoC from non-member companies, since they are using
>> linaro kernel and utilitis well on TI/Freescale/ST-E,
>> they want to use the same linaro kernel on non-member chips, if linaro
>> accepts and maintains non-member patches, then this tree can be useful
>> and customers can use the only tree as their platform to support both
>> member chips and non-member chips.
>
> Sure.
>
>> If so, maybe SoC companies don't need to join linaro, but they can get
>> the benefit of linaro too.  So what's the opinion of Nico?
>
> You should realize that for your patches to be merged into the Linaro
> kernel, they must be in a similar state as if you were about to submit
> them upstream.  Therefore you must have made the effort of making your
> code clean already.  And once you're there, then you may just post them
> for upstream inclusion as well -- that's always our ultimate goal.
>
> The advantage of having those patches also merged into the Linaro kernel
> is all about early visibility and exposure.  The latest developments
> from upstream and the Linaro members are put together, in a kernel that
> gets packaged and distributed along with user space components through
> the Linaro infrastructure, to test and demonstrate the technology being
> worked on without having to wait for the next upstream kernel release.
>
> Of course, if you are not a Linaro member, then you might have more
> difficulties keeping up to date with the work being done in the various
> groups as your platform won't be covered explicitly by those working
> groups, and it won't be supported in the Linaro release.  But your
> patches would be accepted nevertheless, given that they also are on
> their way to be merged upstream.
>
> I hope this helps.
>
>
> Nicolas
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

1105 delivery of pm, multimedia, graphics

[Barry Song]

Hi all,
it is easy to get toolchain/uboot/kernel/android source codes. but i
have been really searching all over the website but still fail to get
source codes of pm(expect powerdebug last updated 6 weeks ago),
multimedia, graphics. so i am really difficult to find delivery of pm,
multimedia, graphics team. is there a delivery list for these teams?

Thanks very much
Barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 1105 delivery of pm, multimedia, graphics

[Barry Song]

Hi Amit,
Thanks very much for your reply.

2011/5/20 Amit Kucheria :
> On 11 May 19, Barry Song wrote:
>> Hi all,
>> it is easy to get toolchain/uboot/kernel/android source codes. but i
>> have been really searching all over the website but still fail to get
>> source codes of pm(expect powerdebug last updated 6 weeks ago),
>> multimedia, graphics. so i am really difficult to find delivery of pm,
>> multimedia, graphics team. is there a delivery list for these teams?
>
> Powerdebug was last updated that long ago.
>
> Having said that, please look to more news on the powerdebug front soon since
> we're planning to implement new features as discussed last week at the Linaro
> developer summit.
i am not asking why powerdebug was last updated 6 weeks ago. i just
want to find a way to get source codes of pm, mm, graphics team to
research :-)
now i can get powerdebug/powertop git tree, and know thermal status for PM.

>
> We also hope to do more regular releases of the tool.
>
> Regards,
> Amit
>
Regards
Barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

linaro-uboot: device tree without ramdisk and boot_relocate_fdt cause illegal memory access in kernel

[Barry Song]

Hi all,
i am using linaro uboot(u-boot-linaro-stable.git).  i have let our
prima2 board support device tree with some workaround in uboot.  two
problems i have meet:
1. device tree without ramdisk
now uboot used commands like
"bootm kernel_address  ramdisk_address dtb_address"
to start linux kernel.
in many cases, people have no ramdisk at all, but the following codes
will still stop people to use device tree to start kernel since it got
an illegal ramdisk:

common/cmd_bootm.c:
if (((images.os.type == IH_TYPE_KERNEL) ||
 (images.os.type == IH_TYPE_MULTI)) &&
(images.os.os == IH_OS_LINUX)) {
/* find ramdisk */
ret = boot_get_ramdisk (argc, argv, &images, IH_INITRD_ARCH,
&images.rd_start, &images.rd_end);
if (ret) {
puts ("Ramdisk image is corrupt or invalid\n");
   return 1;
}

#if defined(CONFIG_OF_LIBFDT)
/* find flattened device tree */
ret = boot_get_fdt (flag, argc, argv, &images,
&images.ft_addr, &images.ft_len);
if (ret) {
puts ("Could not find a valid device tree\n");
return 1;
}
then i delete the first return 1 to let uboot ignore the ramdisk checking.

2. boot_relocate_fdt in common/image.c
this function will relocate fdt to an new address by:
lmb_alloc_base(lmb, of_len, 0x1000, getenv_bootm_mapsize() + getenv_bootm_low())

but the return address is probably not in the initilized scale which
kernel will build mapping in head.S. then in the function
setup_machine_fdt() of arch/arm/kernel/devtree.c, when executing:
 devtree = phys_to_virt(dt_phys);

/* check device tree validity */
if (be32_to_cpu(devtree->magic) != OF_DT_HEADER)
return NULL;
kernel will die due to illegal memory access since dt_phys was not
mapped to virtual address yet.

For problem1 , could uboot have a way to ignore ramdisk by itself?
since we need 3 param in bootm to support device tree. For problem2,
could uboot just relocate fdt to the original address of old ATAG,
OFF+ 0x100?

Thanks
Barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linaro-uboot: device tree without ramdisk and boot_relocate_fdt cause illegal memory access in kernel

[Barry Song]

hi Shawn,
thanks a lot.
-barry

2011/5/27 Shawn Guo :
> On Fri, May 27, 2011 at 04:52:38PM +0800, Barry Song wrote:
>> Hi all,
>> i am using linaro uboot(u-boot-linaro-stable.git).  i have let our
>> prima2 board support device tree with some workaround in uboot.  two
>> problems i have meet:
>> 1. device tree without ramdisk
>> now uboot used commands like
>> "bootm kernel_address  ramdisk_address dtb_address"
>> to start linux kernel.
>> in many cases, people have no ramdisk at all, but the following codes
>> will still stop people to use device tree to start kernel since it got
>> an illegal ramdisk:
>>
>> common/cmd_bootm.c:
>>         if (((images.os.type == IH_TYPE_KERNEL) ||
>>              (images.os.type == IH_TYPE_MULTI)) &&
>>             (images.os.os == IH_OS_LINUX)) {
>>                 /* find ramdisk */
>>                 ret = boot_get_ramdisk (argc, argv, &images, IH_INITRD_ARCH,
>>                                 &images.rd_start, &images.rd_end);
>>                 if (ret) {
>>                         puts ("Ramdisk image is corrupt or invalid\n");
>>                        return 1;
>>                 }
>>
>> #if defined(CONFIG_OF_LIBFDT)
>>                 /* find flattened device tree */
>>                 ret = boot_get_fdt (flag, argc, argv, &images,
>>                                     &images.ft_addr, &images.ft_len);
>>                 if (ret) {
>>                         puts ("Could not find a valid device tree\n");
>>                         return 1;
>>                 }
>> then i delete the first return 1 to let uboot ignore the ramdisk checking.
>>
>> 2. boot_relocate_fdt in common/image.c
>> this function will relocate fdt to an new address by:
>> lmb_alloc_base(lmb, of_len, 0x1000, getenv_bootm_mapsize() + 
>> getenv_bootm_low())
>>
>> but the return address is probably not in the initilized scale which
>> kernel will build mapping in head.S. then in the function
>> setup_machine_fdt() of arch/arm/kernel/devtree.c, when executing:
>>          devtree = phys_to_virt(dt_phys);
>>
>>         /* check device tree validity */
>>         if (be32_to_cpu(devtree->magic) != OF_DT_HEADER)
>>                 return NULL;
>> kernel will die due to illegal memory access since dt_phys was not
>> mapped to virtual address yet.
>>
>> For problem1 , could uboot have a way to ignore ramdisk by itself?
>> since we need 3 param in bootm to support device tree. For problem2,
>
> bootm kernel_address - dtb_address
>
> Use '-' for ramdisk address, if you do not have a ramdisk image.
>
>> could uboot just relocate fdt to the original address of old ATAG,
>> OFF+ 0x100?
>>
> Do you have the following commit on your kernel tree?
>
> commit 4d901c4271951d110afb13ee9aa73d27a6c8e53d
> Author: Rob Herring 
> Date:   Wed Feb 2 16:33:17 2011 +0100
>
>    ARM: 6648/1: map ATAGs when not in first 1MB of RAM
>
>    If ATAGs or DTB pointer is not within first 1MB of RAM, then the boot 
> params
>    will not be mapped early enough, so map the 1MB region that r2 points to. 
> Only
>    map the first 1MB when r2 is 0.
>
>    Some assembly improvements from Nicolas Pitre.
>
>    Acked-by: Tony Lindgren 
>    Acked-by: Nicolas Pitre 
>    Signed-off-by: Rob Herring 
>    Signed-off-by: Russell King 
>
> You can get it from linux-linaro-2.6.38 tree.

>
> --
> Regards,
> Shawn
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

android-toolchain-eabi-4.5-2011.05 fail to compile dalvik

[Barry Song]

Dear Jim,
After changing TARGET_TOOLS_PREFIX in
build/core/combo/TARGET_linux-arm.mk to
android-toolchain-eabi-4.5-2011.05, then source build/envsetup.sh. go
to dalvik/vm dir by:
cd dalvik/vm
compile dalvik in this dir:
mm -B
we will find many compiling error like: "break strict-aliasing rules",
"used uninitialized in this function" and so on. all those actually
are warnings which become errors due to -Werror option. A patch like
the below can make compiling pass, but we feel strange why old
toolchain has no this issue.
Index: Dvm.mk
===
--- Dvm.mk  (revision 4149)
+++ Dvm.mk  (working copy)
@@ -26,7 +26,8 @@
 #
 LOCAL_CFLAGS += -fstrict-aliasing -Wstrict-aliasing=2 -fno-align-jumps
 #LOCAL_CFLAGS += -DUSE_INDIRECT_REF
-LOCAL_CFLAGS += -Wall -Wextra -Wno-unused-parameter
+#LOCAL_CFLAGS += -Wall -Wextra -Wno-unused-parameter
+LOCAL_CFLAGS += -Wextra -Wno-unused-parameter
 LOCAL_CFLAGS += -DARCH_VARIANT=\"$(dvm_arch_variant)\"

 #
@@ -264,7 +265,7 @@
 ifeq ($(dvm_arch),arm)
   #dvm_arch_variant := armv7-a
   #LOCAL_CFLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=vfp
-  LOCAL_CFLAGS += -Werror
+#  LOCAL_CFLAGS += -Werror
   MTERP_ARCH_KNOWN := true
   # Select architecture-specific sources (armv4t, armv5te etc.)
   LOCAL_SRC_FILES += \

Any configuration error from us?
Thanks
Barry

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev