linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[RFC PATCH v2 01/09] ARM: cpu topology: Add update_cpu_topology function

by Vincent Guittot

arch_update_cpu_topology function is called by the scheduler before building its sched_domain hierarchy. Prepare the update of the cpu topology masks in this function in addition to set it in the the store_cpu_topology which is executed only once per cpu. Signed-off-by: Vincent Guittot <vincent.guittot(a)linaro.org> --- arch/arm/kernel/topology.c | 108 +++++++++++++++++++++++++++++++++++--------- 1 files changed, 87 insertions(+), 21 deletions(-) diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c index 8200dea..90352cb 100644 --- a/arch/arm/kernel/topology.c +++ b/arch/arm/kernel/topology.c @@ -43,12 +43,76 @@ struct cputopo_arm cpu_topology[NR_CPUS]; +/* + * cpu topology mask management + */ + +unsigned int advanced_topology = 0; + +/* + * default topology function + */ + const struct cpumask *cpu_coregroup_mask(int cpu) { return &cpu_topology[cpu].core_sibling; } /* + * clear cpu topology masks + */ +static void clear_cpu_topology_mask(void) +{ + unsigned int cpuid; + for_each_possible_cpu(cpuid) { + struct cputopo_arm *cpuid_topo = &(cpu_topology[cpuid]); + cpumask_clear(&cpuid_topo->core_sibling); + cpumask_clear(&cpuid_topo->thread_sibling); + } + smp_wmb(); +} + +/* + * default_cpu_topology_mask set the core and thread mask as described in the + * ARM ARM + */ +static inline void default_cpu_topology_mask(unsigned int cpuid) +{ + struct cputopo_arm *cpuid_topo = &cpu_topology[cpuid]; + unsigned int cpu; + + for_each_possible_cpu(cpu) { + struct cputopo_arm *cpu_topo = &cpu_topology[cpu]; + + if (cpuid_topo->socket_id == cpu_topo->socket_id) { + cpumask_set_cpu(cpuid, &cpu_topo->core_sibling); + if (cpu != cpuid) + cpumask_set_cpu(cpu, + &cpuid_topo->core_sibling); + + if (cpuid_topo->core_id == cpu_topo->core_id) { + cpumask_set_cpu(cpuid, + &cpu_topo->thread_sibling); + if (cpu != cpuid) + cpumask_set_cpu(cpu, + &cpuid_topo->thread_sibling); + } + } + } + smp_wmb(); +} + +static void normal_cpu_topology_mask(void) +{ + unsigned int cpuid; + + for_each_possible_cpu(cpuid) { + default_cpu_topology_mask(cpuid); + } + smp_wmb(); +} + +/* * store_cpu_topology is called at boot when only one cpu is running * and with the mutex cpu_hotplug.lock locked, when several cpus have booted, * which prevents simultaneous write access to cpu_topology array @@ -57,7 +121,6 @@ void store_cpu_topology(unsigned int cpuid) { struct cputopo_arm *cpuid_topo = &cpu_topology[cpuid]; unsigned int mpidr; - unsigned int cpu; /* If the cpu topology has been already set, just return */ if (cpuid_topo->core_id != -1) @@ -99,26 +162,11 @@ void store_cpu_topology(unsigned int cpuid) cpuid_topo->socket_id = -1; } - /* update core and thread sibling masks */ - for_each_possible_cpu(cpu) { - struct cputopo_arm *cpu_topo = &cpu_topology[cpu]; - - if (cpuid_topo->socket_id == cpu_topo->socket_id) { - cpumask_set_cpu(cpuid, &cpu_topo->core_sibling); - if (cpu != cpuid) - cpumask_set_cpu(cpu, - &cpuid_topo->core_sibling); - - if (cpuid_topo->core_id == cpu_topo->core_id) { - cpumask_set_cpu(cpuid, - &cpu_topo->thread_sibling); - if (cpu != cpuid) - cpumask_set_cpu(cpu, - &cpuid_topo->thread_sibling); - } - } - } - smp_wmb(); + /* + * The core and thread sibling masks can also be updated during the + * call of arch_update_cpu_topology + */ + default_cpu_topology_mask(cpuid); printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n", cpuid, cpu_topology[cpuid].thread_id, @@ -127,6 +175,24 @@ void store_cpu_topology(unsigned int cpuid) } /* + * arch_update_cpu_topology is called by the scheduler before building + * a new sched_domain hierarchy. + */ +int arch_update_cpu_topology(void) +{ + if (!advanced_topology) + return 0; + + /* clear core mask */ + clear_cpu_topology_mask(); + + /* update core and thread sibling masks */ + normal_cpu_topology_mask(); + + return 1; +} + +/* * init_cpu_topology is called at boot when only one cpu is running * which prevent simultaneous write access to cpu_topology array */ -- 1.7.4.1

13 years, 6 months

INFO: possible circular locking dependency detected (v3.2-rc1)

by Shawn Guo

I'm running v3.2-rc1 kernel with CONFIG_PROVE_LOCKING enabled on imx6 and imx5 with Linaro rootfs (nano, developer) and seeing a circular locking dependency warning. ---8<---- [ 3.520947] Freeing init memory: 260K Loading, please wait... [ 3.713140] [ 3.714647] ====================================================== [ 3.720836] [ INFO: possible circular locking dependency detected ] [ 3.727112] 3.2.0-rc1+ #54 [ 3.729825] ------------------------------------------------------- [ 3.736102] udevd/368 is trying to acquire lock: [ 3.740728] (&sig->cred_guard_mutex){+.+.+.}, at: [<8013c688>] lock_trace+0x 28/0x5c [ 3.748544] [ 3.748547] but task is already holding lock: [ 3.754398] (&sb->s_type->i_mutex_key#6){+.+.+.}, at: [<800fc954>] do_lookup +0x1e4/0x32c [ 3.762665] [ 3.762668] which lock already depends on the new lock. [ 3.762674] [ 3.770879] [ 3.770882] the existing dependency chain (in reverse order) is: [ 3.778383] [ 3.778386] -> #1 (&sb->s_type->i_mutex_key#6){+.+.+.}: [ 3.785170] [<8006a7d8>] __lock_acquire+0x14c4/0x1a04 [ 3.790871] [<8006b34c>] lock_acquire+0x124/0x148 [ 3.796211] [<8047999c>] mutex_lock_nested+0x5c/0x394 [ 3.801903] [<800fc954>] do_lookup+0x1e4/0x32c [ 3.806982] [<800fcc6c>] link_path_walk+0x1d0/0x7d0 [ 3.812495] [<800fe750>] path_openat+0xac/0x374 [ 3.817661] [<800feb48>] do_filp_open+0x3c/0x88 [ 3.822826] [<800f5e98>] open_exec+0x2c/0x100 [ 3.827818] [<800f7544>] do_execve+0xd4/0x2a8 [ 3.832810] [<80011790>] sys_execve+0x44/0x64 [ 3.837815] [<8000db00>] ret_fast_syscall+0x0/0x3c [ 3.843245] [ 3.843248] -> #0 (&sig->cred_guard_mutex){+.+.+.}: [ 3.849667] [<80067aa4>] print_circular_bug+0x68/0x2b8 [ 3.855445] [<8006a5ac>] __lock_acquire+0x1298/0x1a04 [ 3.861132] [<8006b34c>] lock_acquire+0x124/0x148 [ 3.866470] [<804791a8>] mutex_lock_killable_nested+0x60/0x464 [ 3.872940] [<8013c688>] lock_trace+0x28/0x5c [ 3.877932] [<8013e79c>] proc_lookupfd_common+0x60/0xc8 [ 3.883795] [<8013e844>] proc_lookupfd+0x1c/0x24 [ 3.889047] [<800fa96c>] d_alloc_and_lookup+0x54/0x70 [ 3.894738] [<800fc978>] do_lookup+0x208/0x32c [ 3.899816] [<800fd434>] path_lookupat+0xfc/0x6c8 [ 3.905155] [<800fda2c>] do_path_lookup+0x2c/0x68 [ 3.910495] [<800feab0>] user_path_at_empty+0x68/0x98 [ 3.916181] [<800feb04>] user_path_at+0x24/0x2c [ 3.921346] [<800f4eb4>] vfs_fstatat+0x44/0x74 [ 3.926425] [<800f4f40>] vfs_stat+0x2c/0x30 [ 3.931243] [<800f5164>] sys_stat64+0x24/0x40 [ 3.936234] [<8000db00>] ret_fast_syscall+0x0/0x3c [ 3.941662] [ 3.941666] other info that might help us debug this: [ 3.941671] [ 3.949702] Possible unsafe locking scenario: [ 3.949708] [ 3.955644] CPU0 CPU1 [ 3.960181] ---- ---- [ 3.964718] lock(&sb->s_type->i_mutex_key); [ 3.969114] lock(&sig->cred_guard_mutex); [ 3.975853] lock(&sb->s_type->i_mutex_key); [ 3.982766] lock(&sig->cred_guard_mutex); [ 3.986984] [ 3.986987] *** DEADLOCK *** [ 3.986991] [ 3.992941] 1 lock held by udevd/368: [ 3.996609] #0: (&sb->s_type->i_mutex_key#6){+.+.+.}, at: [<800fc954>] do_l ookup+0x1e4/0x32c [ 4.005314] [ 4.005317] stack backtrace: [ 4.009712] [<800151dc>] (unwind_backtrace+0x0/0xec) from [<80477088>] (dump_ stack+0x20/0x24) [ 4.018260] [<80477088>] (dump_stack+0x20/0x24) from [<80067ca8>] (print_circ ular_bug+0x26c/0x2b8) [ 4.027242] [<80067ca8>] (print_circular_bug+0x26c/0x2b8) from [<8006a5ac>] ( __lock_acquire+0x1298/0x1a04) [ 4.036918] [<8006a5ac>] (__lock_acquire+0x1298/0x1a04) from [<8006b34c>] (lo ck_acquire+0x124/0x148) [ 4.046072] [<8006b34c>] (lock_acquire+0x124/0x148) from [<804791a8>] (mutex_ lock_killable_nested+0x60/0x464) [ 4.056007] [<804791a8>] (mutex_lock_killable_nested+0x60/0x464) from [<8013c 688>] (lock_trace+0x28/0x5c) [ 4.065593] [<8013c688>] (lock_trace+0x28/0x5c) from [<8013e79c>] (proc_looku pfd_common+0x60/0xc8) [ 4.074572] [<8013e79c>] (proc_lookupfd_common+0x60/0xc8) from [<8013e844>] ( proc_lookupfd+0x1c/0x24) [ 4.083812] [<8013e844>] (proc_lookupfd+0x1c/0x24) from [<800fa96c>] (d_alloc _and_lookup+0x54/0x70) [ 4.092878] [<800fa96c>] (d_alloc_and_lookup+0x54/0x70) from [<800fc978>] (do _lookup+0x208/0x32c) [ 4.101771] [<800fc978>] (do_lookup+0x208/0x32c) from [<800fd434>] (path_look upat+0xfc/0x6c8) [ 4.110317] [<800fd434>] (path_lookupat+0xfc/0x6c8) from [<800fda2c>] (do_pat h_lookup+0x2c/0x68) [ 4.119123] [<800fda2c>] (do_path_lookup+0x2c/0x68) from [<800feab0>] (user_p ath_at_empty+0x68/0x98) [ 4.128275] [<800feab0>] (user_path_at_empty+0x68/0x98) from [<800feb04>] (us er_path_at+0x24/0x2c) [ 4.137253] [<800feb04>] (user_path_at+0x24/0x2c) from [<800f4eb4>] (vfs_fsta tat+0x44/0x74) [ 4.145621] [<800f4eb4>] (vfs_fstatat+0x44/0x74) from [<800f4f40>] (vfs_stat+ 0x2c/0x30) [ 4.153642] [<800f4f40>] (vfs_stat+0x2c/0x30) from [<800f5164>] (sys_stat64+0 x24/0x40) [ 4.161579] [<800f5164>] (sys_stat64+0x24/0x40) from [<8000db00>] (ret_fast_s yscall+0x0/0x3c) [ 4.173173] udevd[369]: starting version 173 [ 4.585095] mmc0: new high speed SDHC card at address aaaa [ 4.591330] mmcblk0: mmc0:aaaa SD04G 3.69 GiB [ 4.597998] mmcblk0: p1 p2 p3 [ 5.384460] mmc1: host does not support reading read-only switch. assuming wr ite-enable. [ 5.796502] mmc1: new high speed SDHC card at address 1234 [ 5.803063] mmcblk1: mmc1:1234 SA04G 3.68 GiB [ 5.810156] mmcblk1: p1 p2 p3 [ 6.032487] EXT4-fs (mmcblk0p3): INFO: recovery required on readonly filesyst em [ 6.039849] EXT4-fs (mmcblk0p3): write access will be enabled during recovery [ 6.064099] EXT4-fs (mmcblk0p3): recovery complete [ 6.074078] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. O pts: (null) Last login: Thu Jan 1 00:00:27 UTC 1970 on tty1 Welcome to Linaro 11.10 (development branch) (GNU/Linux 3.2.0-rc1+ armv7l) * Documentation: https://wiki.linaro.org/ root@linaro-nano:~# ---->8--- As I see this only on v3.2-rc1 kernel, I suspect it's a v3.2-rc1 kernel issue and have reported on LKML[1]. I post it here for information and hope people running other platforms can try to reproduce the issue and confirm it's a common rather than imx only issue. Regards, Shawn https://lkml.org/lkml/2011/11/11/120

13 years, 6 months

Initial linaro-android-3.1 kernel for 11.11

by john stultz

Just wanted to announce that the initial Linaro+Android-3.1 kernel for 11.11 is available. I've tagged it as: linux-linaro-3.1-2011.11-0-android-0 >From the branch: git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-agreen-rebase Please remember Nico is freezing the 11.11 linaro kernel on Monday, and I'll be tagging the 11.11 linaro-android kernel shortly there after. thanks -john

13 years, 6 months

(cross-post) Efika MX anyone?

by Zygmunt Krynicki

W dniu 11.11.2011 03:55, Adilson Oliveira pisze: Hi. I'm re-posting a question from a canonical folk about Efika MX, I think the audience here will be more capable of helping out. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello > > I got an Efika MX and I wondered if anyone qwas able to instrall a > more recent Ubuntu on it. I tried Linaro's image but the SD is not > recognized at boot time. Am I missing something or was the SD supposed > to be detected automatically? > > TIA > > Adilson. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk68jroACgkQYaKG37RGLIp/pACdFvTB3hVssnVCeXNL9EulVb9Z > UccAn3z3YUvON/ji1gdRDaRuHq/IZrA1 > =73EU > -----END PGP SIGNATURE-----

13 years, 6 months

[Activity] Power Management WG Weekly Status report for week ending 2011-11-11

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status report & meeting minutes for the Power Management working group for the week ending 2011-11-11 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-11-10 == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-11-09 == Summary == (For details, see the Weekly Status Report and Meeting Minutes ) * Most of the PMWG team has attended Linaro Connect, many good sessions, discussion and hacking has happened https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Orlando * sched_mc * Presented sched_mc findings at Connect see the presentation at https://wiki.linaro.org/Events/LinaroConnectQ4.11 * Start discussing load balance and ARM topology * Cpuidle * It was decided to to fix the core cpuidle first, which makes porting to the platforms much easier. Will collaborate with Deepthi to clean up the cpuidle core code. * Studying SMP cpuidle, so far the thought is changes to menu governor may be needed. * Common clock framework * Last issue for common clock framework is resolved. *Panda is now 100% converted to use Common Clock Framework.* * Some platform work is happening to convert to the new framework. * Thermal Manager * Started working on upstreaming i.MX6 temperature sensor and thermal driver. Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

13 years, 6 months

[PATCH] pinctrl: Add explicit gpio_disable_free pinmux_op

by Stephen Warren

Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a completely different manner than they select which function to mux out of that pin. In order to support a single "free" pinmux_op, the driver would need to maintain a per-pin state of requested-for-gpio vs. requested-for- function. However, that's a lot of work when the core already has explicit separate paths for gpio request/free and function request/free. So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free() call it when appropriate. When doing this, I noticed that when calling pin_request(): !!gpio == (gpio_range != NULL) ... and so I collapsed those two parameters in both pin_request(), and when adding writing the new code in pin_free(). Also, for pin_free(): !!free_func == (gpio_range != NULL) However, I didn't want pin_free() to know about the GPIO function naming special case, so instead, I reworked pin_free() to always return the pin's previously requested function, and now pinmux_free_gpio() calls kfree(function). This is much more balanced with the allocation having been performed in pinmux_request_gpio(). Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- drivers/pinctrl/pinmux.c | 39 +++++++++++++++++++++++++-------------- include/linux/pinctrl/pinmux.h | 3 +++ 2 files changed, 28 insertions(+), 14 deletions(-) diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c index a5467f8..8a95e45 100644 --- a/drivers/pinctrl/pinmux.c +++ b/drivers/pinctrl/pinmux.c @@ -98,12 +98,11 @@ struct pinmux_hog { * @function: a functional name to give to this pin, passed to the driver * so it knows what function to mux in, e.g. the string "gpioNN" * means that you want to mux in the pin for use as GPIO number NN - * @gpio: if this request concerns a single GPIO pin * @gpio_range: the range matching the GPIO pin if this is a request for a * single GPIO pin */ static int pin_request(struct pinctrl_dev *pctldev, - int pin, const char *function, bool gpio, + int pin, const char *function, struct pinctrl_gpio_range *gpio_range) { struct pin_desc *desc; @@ -152,7 +151,7 @@ static int pin_request(struct pinctrl_dev *pctldev, * If there is no kind of request function for the pin we just assume * we got it by default and proceed. */ - if (gpio && ops->gpio_request_enable) + if (gpio_range && ops->gpio_request_enable) /* This requests and enables a single GPIO pin */ status = ops->gpio_request_enable(pctldev, gpio_range, pin); else if (ops->request) @@ -182,29 +181,39 @@ out: * pin_free() - release a single muxed in pin so something else can be muxed * @pctldev: pin controller device handling this pin * @pin: the pin to free - * @free_func: whether to free the pin's assigned function name string + * @gpio_range: the range matching the GPIO pin if this is a request for a + * single GPIO pin */ -static void pin_free(struct pinctrl_dev *pctldev, int pin, int free_func) +static const char *pin_free(struct pinctrl_dev *pctldev, int pin, + struct pinctrl_gpio_range *gpio_range) { const struct pinmux_ops *ops = pctldev->desc->pmxops; struct pin_desc *desc; + const char *func; desc = pin_desc_get(pctldev, pin); if (desc == NULL) { dev_err(&pctldev->dev, "pin is not registered so it cannot be freed\n"); - return; + return NULL; } - if (ops->free) + /* + * If there is no kind of request function for the pin we just assume + * we got it by default and proceed. + */ + if (gpio_range && ops->gpio_disable_free) + ops->gpio_disable_free(pctldev, gpio_range, pin); + else if (ops->free) ops->free(pctldev, pin); spin_lock(&desc->lock); - if (free_func) - kfree(desc->mux_function); + func = desc->mux_function; desc->mux_function = NULL; spin_unlock(&desc->lock); module_put(pctldev->owner); + + return func; } /** @@ -234,7 +243,7 @@ int pinmux_request_gpio(unsigned gpio) if (!function) return -EINVAL; - ret = pin_request(pctldev, pin, function, true, range); + ret = pin_request(pctldev, pin, function, range); if (ret < 0) kfree(function); @@ -252,6 +261,7 @@ void pinmux_free_gpio(unsigned gpio) struct pinctrl_gpio_range *range; int ret; int pin; + const char *func; ret = pinctrl_get_device_gpio_range(gpio, &pctldev, &range); if (ret) @@ -260,7 +270,8 @@ void pinmux_free_gpio(unsigned gpio) /* Convert to the pin controllers number space */ pin = gpio - range->base; - pin_free(pctldev, pin, true); + func = pin_free(pctldev, pin, range); + kfree(func); } EXPORT_SYMBOL_GPL(pinmux_free_gpio); @@ -350,7 +361,7 @@ static int acquire_pins(struct pinctrl_dev *pctldev, /* Try to allocate all pins in this group, one by one */ for (i = 0; i < num_pins; i++) { - ret = pin_request(pctldev, pins[i], func, false, NULL); + ret = pin_request(pctldev, pins[i], func, NULL); if (ret) { dev_err(&pctldev->dev, "could not get pin %d for function %s " @@ -360,7 +371,7 @@ static int acquire_pins(struct pinctrl_dev *pctldev, /* On error release all taken pins */ i--; /* this pin just failed */ for (; i >= 0; i--) - pin_free(pctldev, pins[i], false); + pin_free(pctldev, pins[i], NULL); return -ENODEV; } } @@ -390,7 +401,7 @@ static void release_pins(struct pinctrl_dev *pctldev, return; } for (i = 0; i < num_pins; i++) - pin_free(pctldev, pins[i], false); + pin_free(pctldev, pins[i], NULL); } /** diff --git a/include/linux/pinctrl/pinmux.h b/include/linux/pinctrl/pinmux.h index 3c430e7..350e32a 100644 --- a/include/linux/pinctrl/pinmux.h +++ b/include/linux/pinctrl/pinmux.h @@ -73,6 +73,9 @@ struct pinmux_ops { int (*gpio_request_enable) (struct pinctrl_dev *pctldev, struct pinctrl_gpio_range *range, unsigned offset); + void (*gpio_disable_free) (struct pinctrl_dev *pctldev, + struct pinctrl_gpio_range *range, + unsigned offset); }; /* External interface to pinmux */ -- 1.7.0.4

13 years, 6 months

[Activity] Kernel WG Weekly Status report for week ending 2011-11-11

by Mounir Bsaibes

Enclosed please find the link to the Weekly Status & Individual Activity reports for the kernel working group for the week ending 2011-11-11 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-11-10 == Individual Activity Report == https://wiki.linaro.org/WorkingGroups/Kernel/ActivityReports/2011-11-04 == Summary == (For more details, refer to the Weekly Status & Individual Activity Reports) * Most of the KWG team has attended Linaro Connect, many good sessions, discussion and hacking has happened. Deepak has summarized the event for KWG: http://www.linaro.org/linaro-blog/2011/11/09/kernel-working-group-a-linaro-… * Due to Thanksgiving holiday, this month's Linaro kernel release will be as follows: Freeze on Monday 2011-11-14 and release on Thursday 2011-11-17. * Based on discussions at LCQ4.11 Connect in Orlando, there will be a new process for the Kernel WG, new sub-team will be designated for each major area. * Device Tree * Submitted rebased version of the samsung's sdhci driver DT patches. * Regulator core DT patches Acked by Mark. Some more minor comments from Olof, will need another final repost. * Initial omap hsmmc DT patches posted. * Pinctrl * Linus Torvalds has pulled the pinctrl subssystem for Linux v3.2. * All GPIO cleanups initially started in the Cambourne sprint in cooperation with Ben Dooks, have been pulled into Linus Torvalds' tree. Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

13 years, 6 months

Patches for SMSC LAN911X driver on UBoot and QEMU

by Cachet Bertrand

Hi, I have made some modification to the SMSC LAN911X driver for both UBoot and QEMU in order to be able to use SMSC LAN9X based network drivers during the u-boot stage. 1) U-Boot In UBoot, when the LAN911X device is reseted, the READY bit is checked and device is wake up by writing onto the TEST_BYTE register if the READY bit cleared (0b). But from the datasheet of the SMSC LAN9118/LAN9115/LAN9220 in the section Power Management (3.10), it is said that READY bit is cleared when PM_MODE is set to D1 or D2 and set only when in D0 mode. 3.10.2 Functional Description There is one normal operating power state, D0 and there are two power saving states: D1, and D2. Upon entry into either of the two power saving states, only the PMT_CTRL register is accessible for read operations. In either of the power saving states the READY bit in the PMT_CTRL register will be cleared. Reads of any other addresses are forbidden until the READY bit is set. All writes, with the exception of the wakeup write to BYTE_TEST, are also forbidden until the READY bit is set. Only when in the D0 (Normal) state, when the READY bit is set, can the rest of the device be accessed. So I modified the code (drivers/net/smc911x.h) to wake up the device only if the READY bit is cleared (0b). If it is set (1b) then we just do nothing. Patch is contained in following commit : https://bitbucket.org/bca/u-boot-linaro-stable/changeset/b870326105da 2) QEMU In the driver for the SMSC LAN9118 device (hw/lan9118.c), I modify the code to update the PM_CTRL register (switch PM_MODE bits to D0 and set (1b) READY bit ) when writing to the BYTE_TEST register. Writing to PM_CTRL was not permitted before this modification => raise an harware error => QEMU crash when happen. So when you try to perform network connection in u-boot stage in QEMU, QEMU crashed. Patch is contained in the following commit : https://bitbucket.org/bca/qemu-linaro/changeset/0aa1f76e5141 If you have any question, or if you find any mistake in my understanding, please feel free to contact me. Hope it helps others and a bit thanks for the Linaro initiative -- Bertrand Cachet, Ingénieur CPE (Lyon, France) Institut REDS, Reconfigurable & Embedded Digital Systems Tél : +41 24/55 77 372 Email : bertrand.cachet(a)heig-vd.ch<mailto:bertrand.cachet@heig-vd.ch> Internet: http://www.reds.ch HEIG-VD, Haute Ecole d'Ingénierie et de Gestion du Canton de Vaud Rte de Cheseaux 1 CH-1401 Yverdon-les-Bains Internet: http://www.heig-vd.ch

13 years, 6 months

android powertop is always segment fault

by Jello huang

Hi Tony when i start up the latest powertop ,and it always complaint # powertop {LINUX} init: untracked pid 1298 exited Cannot load results from file /data/local/powertop/saved_results.powertop Cannot load parameters from file /data/local/powertop/saved_parameters.powertop [1]+ Stopped (signal) powertop # [1]+ Segmentation fault powertop # powertop -v Cannot load results from file /data/local/powertop/saved_results.powertop Cannot load parameters from file /data/local/powertop/saved_parameters.powertop {LINUX} init: untracked pid 1307 exited [1]+ Stopped (signal) powertop -v # [1]+ Segmentation fault powertop -v # strace -f -v -T powertop execve("/system/bin/powertop", ["powertop"], ["EXTERNAL_STORAGE=/mnt/sdcard", "LD_LIBRARY_PATH=/system/lib:/lib"..., "OLDPWD=/system/lib", "ANDROID_ASSETS=/system/app", "BOOTCLASSPATH=/system/framework/"..., "ANDROID_DATA=/data", "PATH=/system/sbin:/system/bin:/s"..., "ANDROID_ROOT=/system", "ASEC_MOUNTPOINT=/mnt/asec", "PWD=/system/bin", "ANDROID_PROPERTY_WORKSPACE=9,327"..., "ANDROID_BOOTLOGO=1"]{LINUX} init: untracked pid 1312 exited ) = 0 <0.001495> -- JUST DO IT,NOTHING IS IMPOSSIBLE

13 years, 6 months

Re: LAVA server going down in 30 minutes

by Paul Larson

Here's a quick status update on the server upgrade we performed today. The major things we were doing were: * Memory upgrades - we now have about 7.5x the memory we had previously, things are *much* faster now * OS updates - We're now running on the latest version of Ubuntu Server * LAVA updates If you take a look at http://validation.linaro.org, you will now see the version we had in staging last week at the connect, with more Linaro theming, menu improvements, and bug fixes. Jobs are running again, and we've mostly cleared the backlog but seem to be having some network problems that are unrelated to the upgrades, causing failures in some of the jobs. The validation team is currently looking at what can be done to improve this soon. Thanks, Paul Larson On Thu, Nov 10, 2011 at 2:31 AM, Dave Pigott <dave.pigott(a)linaro.org> wrote: > Hi all, > > Just a reminder that validation.linaro.org will be taken down in 30 > minutes, at 09:00 UTC. > > Thanks > > Dave Pigott > Validation Engineer > T: +44 1223 45 00 24 | M +44 7940 45 93 44 > Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM > SoCs**** > Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter<http://twitter.com/#%21/linaroorg> > | Blog <http://www.linaro.org/linaro-blog/> > >

13 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev