Re: End of support for Snowball V2 board
On 02/11/11 14:49, anmar.ou...@linaro.org wrote: > On 1 November 2011 12:32, Zach Pfeffer wrote: >> This email seems to be out of step with our recent EOL meeting where >> we talked about giving a month notice, needing new boards before we >> EOL boardsetc. > > It is fair a statement but It doesn't apply here. Snowball V2 was not > widely shared outside ST-Ericsson and Linaro. Therefore, there is no > possibility of having anybody outside depending on it or sponsoring > it. Having it linger for another month will only cause confusion. > > I recommend that we terminate the Snowball V2 support immediately. > > Lee: We should also rename the Snowball V3 HWPacks to just Snowball HWPack. I'm going to refrain from doing so atm. There is be another version of the hwpack looming due to new startupfiles which do not support v2 & v5 hw. Kind regards, Lee -- Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 0/11] ARM: cpu topology Cortex-A9
Vincent, What is the status of this after talks with the scheduler maintainers in Prague last week? Have you shared this with Peter Z et al. Regards, Amit On Fri, Oct 21, 2011 at 12:52 PM, Vincent Guittot wrote: > The sched_mc feature has been originally designed to improve power > consumption of multi-package system and several architecture functions > are available to tune the topology and the scheduler's parameters when > scheduler rebuilds the sched_domain hierarchy (change the > sched_mc_power_savings level). This patches series is a trial to > improve the power consumption of dual and quad cortex-A9 when the > sched_mc_power_savings is set to 2. The following patch's policy is to > accept up to 4 threads (can be configured) in the run queue of a core > before starting to load balance if cpu runs at low frequencies but to > accept only 1 thread for high frequencies, which is the normal > behaviour. The goal is to use only one cpu in light load situation and > both cpu in heavy load situation > > Patches [1-3] modify the ARM cpu topology according to > sched_mc_power_savings value and Cortex id > Patch [4] enables ARCH_POWER feature of the scheduler > Patch [5] adds ARCH_POWER function for ARM platform > Patches [6-7] modify the cpu_power of CA-9 according to > sched_mc_power_savings' level and current frequency. The main goal is > to increase the capacity of a core when using low cpu frequency in > order to pull tasks on this core. Note that this behaviour is not > really advised but it can be seen as an intermediate step between the > use of cpu hotplug (which is not a power saving feature) and a new > load balancer which will take into account low load situation on dual > core. > Patch [8] ensures that cpu0 is used in priority when only one CPU is running > Patch [9] adds some debugfs interface for test purpose > Patch [10] ensures that the cpu_power will be update periodically > Patch [11] fixes an issue around the trigger of ilb. > > TODO list: > -remove useless start of ilb when the core has capacity. > -add a method (DT, sysfs, ...) to set threshold for using 1 or 2 cpus > for dual CA-9 > -irq balancing > > The tests hereafter have been done on a u8500 with kernel linaro-3.1. > They check that there is no obvious lost of performance when > sched_mc=2. > > sysbench --test=cpu --num-threads=12 --max-time=20 run > Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug > total number of events: 665 664 > 336 > per-request statistics: > min: 92.68ms 70.53ms > 618.89ms > avg: 361.75ms 361.38ms 725.29ms > max: 421.08ms 420.73ms 840.74ms > approx. 95 percentile: 402.28ms 390.53ms 760.17ms > > sysbench --test=threads --thread-locks=9 --num-threads=12 --max-time=20 run > Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug > total number of events: 1 1 3129 > per-request statistics: > min: 1.62ms 1.70ms > 13.16ms > avg: 22.23ms 21.87ms > 76.77ms > max: 153.52ms 133.99ms 173.82ms > approx. 95 percentile: 54.12ms 52.65ms 136.32ms > > sysbench --test=threads --thread-locks=2 --num-threads=3 --max-time=20 run > Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug > total number of events: 1 1 1 > per-request statistics: > min: 1.38ms 1.38ms > 5.70ms > avg: 4.67ms 5.37ms > 11.85ms > max: 36.84ms 32.42ms 32.58ms > approx. 95 percentile: 14.34ms 12.89ms 21.30ms > > cyclictest -q -t -D 20 > Only one cpu is used during this test when sched_mc=2 whereas both cpu > are used when sched_mc=0 > Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug > > Avg, Max: 15, 434 19, 2145 17, > 3556 > Avg, Max: 14, 104 19, 1686 17, > 3593 > > Regards, > Vincent > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] ARM: EXYNOS4: Enable Bluetooth on ORIGEN
Sangwook Lee wrote:
>
> This patch enables Bluetooth support on ORIGEN board.
>
> Signed-off-by: Sangwook
> ---
> arch/arm/mach-exynos4/mach-origen.c | 32
>
> 1 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index f80b563..f8c50d7 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -232,6 +233,7 @@ static struct regulator_init_data __initdata
> max8997_ldo9_data = {
> .min_uV = 280,
> .max_uV = 280,
> .apply_uV = 1,
> + .always_on = 1,
> .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> .state_mem = {
> .disabled = 1,
> @@ -275,6 +277,7 @@ static struct regulator_init_data __initdata
> max8997_ldo14_data = {
> .min_uV = 180,
> .max_uV = 180,
> .apply_uV = 1,
> + .always_on = 1,
> .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> .state_mem = {
> .disabled = 1,
> @@ -290,6 +293,7 @@ static struct regulator_init_data __initdata
> max8997_ldo17_data = {
> .min_uV = 330,
> .max_uV = 330,
> .apply_uV = 1,
> + .always_on = 1,
> .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> .state_mem = {
> .disabled = 1,
> @@ -588,6 +592,21 @@ static struct s3c_fb_platdata origen_lcd_pdata
__initdata
> = {
> .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
> };
>
> +/* Bluetooth rfkill gpio platform data */
> +struct rfkill_gpio_platform_data origen_bt_pdata = {
> + .reset_gpio = EXYNOS4_GPX2(2),
> + .shutdown_gpio = -1,
> + .type = RFKILL_TYPE_BLUETOOTH,
> + .name = "origen-bt",
> +};
> +
> +/* Bluetooth Platform device */
> +static struct platform_device origen_device_bluetooth = {
> + .name = "rfkill_gpio",
> + .id = -1,
> + .dev.platform_data = &origen_bt_pdata,
> +};
> +
> static struct platform_device *origen_devices[] __initdata = {
> &s3c_device_hsmmc2,
> &s3c_device_hsmmc0,
> @@ -615,6 +634,7 @@ static struct platform_device *origen_devices[]
__initdata =
> {
> &exynos4_device_pd[PD_MFC],
> &origen_device_gpiokeys,
> &origen_lcd_hv070wsa,
> + &origen_device_bluetooth,
> };
>
> /* LCD Backlight data */
> @@ -628,6 +648,16 @@ static struct platform_pwm_backlight_data
> origen_bl_data = {
> .pwm_period_ns = 1000,
> };
>
> +static void __init origen_bt_setup(void)
> +{
> + gpio_request(EXYNOS4_GPA0(0), "GPIO BT_UART");
> + /* 4 UART Pins configuration */
> + s3c_gpio_cfgrange_nopull(EXYNOS4_GPA0(0), 4, S3C_GPIO_SFN(2));
> + /* Setup BT Reset, this gpio will be requesed by rfkill-gpio */
> + s3c_gpio_cfgpin(EXYNOS4_GPX2(2), S3C_GPIO_OUTPUT);
> + s3c_gpio_setpull(EXYNOS4_GPX2(2), S3C_GPIO_PULL_NONE);
> +}
> +
> static void s5p_tv_setup(void)
> {
> /* Direct HPD to HDMI chip */
> @@ -687,6 +717,8 @@ static void __init origen_machine_init(void)
> s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
>
> samsung_bl_set(&origen_bl_gpio_info, &origen_bl_data);
> +
> + origen_bt_setup();
> }
>
> MACHINE_START(ORIGEN, "ORIGEN")
> --
> 1.7.4.1
Applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
