linaro-dev January 2012

linaro-dev@lists.linaro.org

125 participants
124 discussions

by Ryan Harkin

Hi folks, The way Versatile Express hardware packs are to be delivered is set to change. Currently, both Platform and the ARM Landing Team (Tixy and me) generate hwpacks for Versatile Express A9. In future, only the ARM Landing Team will be generating hardware packs for the Versatile Express platforms. The LT have a some great features to roll out in the coming months, such as UEFI, Device Tree, A5 and A15 CoreTile support. It makes sense for Linaro to only support one variant of the hardware pack and gives the Landing Team more control over feature deployment. You can find our hardware pack in the current Linaro releases, via http://www.linaro.org/downloads in the Developer and Community Builds section and/or via releases.linaro.org. For example, you'll find the current LT hwpack here: http://releases.linaro.org/11.12/ubuntu/oneiric-hwpacks/hwpack_linaro-lt-ve… Regards, Ryan

13 years, 3 months

Re: LAVA and Android Toolchain Benchmarks

by Zach Pfeffer

Dude this totally rocks. Also adding linaro-dev. On 17 January 2012 22:59, Andy Doan <andy.doan(a)linaro.org> wrote: > Sorry for the wide distribution, but I wasn't sure who all would be > interested. > > I spent time over the last month updating the Android monthly toolchain > benchmark process[1] to pull its benchmark data from LAVA tests that are > stored in validation.linaro.org. Here's an example test run[2]. > > This month's results will be published to the wiki as I normally do. > However, I spent some time last weekend looking at how to handle this on > the validation server as well. I first toyed with trying to do a simple > report plugin. However, it really didn't quite have everything I thought > was needed. > > I wound up using the "LAVA kernel CI views" project as a skeleton to > create something for Android. I've got a local prototype that's starting > to do just about everything I want (I'm fighting some issues the the > javascript FLOT library for my charts). I'm attaching a screenshot so > you can get a rough idea. > > Before I really invest time, I wanted to get people's thoughts. Some big > questions for me: > > 1) Is anyone against doing this? > 2) The project is currently called "Android Benchmarks". However, I'm > wondering if we should make more of a generic view for "Android". > "Toolchain Benchmarks" could then be one part of this, but we'd have a > spot to add other things if needed/wanted. Due to how projects are shown > across the top of validation.l.o, I think we need pretty concise entries. > 3) If the general thought is "this looks okay", then are you guys okay > with targeting it for next month? > > [1] > <https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-…> > [2] > <http://validation.linaro.org/lava-server/dashboard/streams/anonymous/doanac… >> > > _______________________________________________ > linaro-android mailing list > linaro-android(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-android > -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 3 months

[PATCH V2 0/4] add arm soc generic cpufreq driver

by Richard Zhao

The driver support single core and multi core ARM SoCs. For multi core, it assume all cores share the same clock and voltage. Changes in v2: - add volatage change support - change '_' in property name to '-' - use initial value to calculate loops_per_jiffy - fix reading cpu_volts property bug - let cpufreq_frequency_table_cpuinfo routines handle cpu_freq_khz_max/min - don't change freq in arm_cpufreq_exit, because every core share the same freq. - use unsigned long describe frequency as much as possible. Because clk use unsigned long, but cpufreq use unsigned int. [PATCH V2 1/4] cpufreq: add arm soc generic cpufreq driver [PATCH V2 2/4] dts/imx6q: add cpufreq property [PATCH V2 3/4] arm/imx6q: register arm_clk as cpu to clkdev [PATCH V2 4/4] arm/imx6q: select ARCH_HAS_CPUFREQ Thanks Richard

13 years, 3 months

Binary Blobs Attack!!!

by Zach Pfeffer

I had my "Binary Blobs Attack!!!" BoF session accepted at ELC this year: Most SoC vendors distribute binary blobs with Linux kernel shims. These binary blobs enable graphics engines, DSPs and other cores on ARM and other architecture SoCs. These binary blobs tend to be tied to specific kernel versions which limits unreadability and hackability and complicates device manufactures, which slows down innovation and the introduction of new and unique computing devices. This BoF is aimed at trying to improve this situation with pragmatic steps. Anyone interested in discussing their experience with binary blob integration, ideas for making this easier to deal with across architectures, ways to encourage openness while allowing vendor differentiation and others interested in a constructive dialog should attend. I was wanted to get some feedback from people about their own binary blob experiences. I think this will be a good place to have a good productive conversation about this critical issue. This is ELC so We'll want to cover issues that affect all Linux distros. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 3 months

[ACTIVITY] Multimedia WG weekly status report - wk01.2012 (20120102-20120106)

by Ilias Biris

Hello! Status dashboard has the details in https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Last weekly meeting: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2012-01-03 Highlights - Coming back from vacation - Wiki page for libjpeg-turbo integration in skia and skia_test usage for jpeg performance test was created - Created a parser for the test definition of Speex - Provided some help to get smoother video playing on xbmc for Ubuntu leb on Panda - live-build a40 should be ready to roll, not able to connect with infra to do the update over the break Issues - Bug #893402 is impeding progress in end-to-end audio testing (only a prototype is available for desktop - pandaboard is not functional). Risks -UCM for Android will be split to cover the different parts of the work - some of the work will be done till LCQ1.12 but the work will be completed after Connect Next steps - Proceed with the release tasks for 12.01. Continue planning for Connect - see the preliminary MMWG plan for LCQ1.12 at https://wiki.linaro.org/TomGall/DraftPlan/2012Plan#anchor-1q12lc Questions/comments? Many thanks, -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

13 years, 3 months

Re: Tracking patches to copy-to-slave Jenkins plugin

by Guilherme Salgado

Hi Paul, On 17/01/12 12:31, Paul Sokolovsky wrote: > Hello Guilherme, > > Here's the matter about "WI" we have from the team meeting. I posted > about that matter previously but here's quick recap: we wanted to > start using the copy-to-slave on android-build, and I found that it has > security hole, essentially it allows a user w/o admin permissions to > get access to admin info, which can be as serious as to allow to steal > EC2 machine time. > > What I did is notified the plugin maintainer, and also quickly whipped > a "short-circuit" type workaround - I just removed the offending option > altogether. In maintainer's place, I wouldn't accept that patch as is - > obviously, is some configurations there's no real security risk with > that option, and some people have it in use. Proper solution would take > adding UI configuration page, but I don't know Jenkisn well enough to > do that (and before going for that, there're 2-3 Jenkins hacking > related tasks waiting in queue for months). Last step in this so far is > that maintainer did some changes (again, I doubt they're based on my > patch much) and asked for review, in my TODO. > > We didn't really exchange email, all communication is as the comments > to the plugin page: > > https://wiki.jenkins-ci.org/display/JENKINS/Copy+To+Slave+Plugin?focusedCom… > > There's also a bug: https://issues.jenkins-ci.org/browse/JENKINS-12281 > > My changes are in the form of fork repo: > https://github.com/pfalcon/copy-to-slave-plugin > > > So, based on all this, I wouldn't think there's something to > patch-track: it's not that much of upstream contribution, more of > upstream bugreport + local workaround. But if you think we could track > anything out of this, I'd appreciate a hint how to start with that. Right, it probably doesn't make sense to teach patches.l.o how to suck patches submitted by Linaro engineers from issues.jenkins-ci.org as we don't expect to see many contributions from Linaro there. If that changes in the future, we can certainly work something out, like we did for gerrit. The way you described it sounds like the patch you submitted isn't even going to be merged upstream, but if you have others that you expect to be, you can just email a copy of them to patches(a)l.o, as described at https://wiki.linaro.org/Process/UpstreamPatches In that case you'll also want to ask for the creation of a new project on patches.l.o (instructions also on the page above) -- Guilherme Salgado <https://launchpad.net/~salgado>

13 years, 3 months

RE: [PATCH] leds-lp5521: additional platform data and attributes

by Kim, Milo

I couldn't contact the author of this driver. I'd like to know who can review and apply my patch. Thanks & BR Milo - -----Original Message----- From: Kim, Milo Sent: Monday, January 16, 2012 3:31 PM To: 'linux-kernel(a)vger.kernel.org'; 'rpurdie(a)rpsys.net' Cc: 'linaro-dev(a)lists.linaro.org'; 'milo.kim(a)ti.com' Subject: RE: [PATCH] leds-lp5521: additional platform data and attributes For better readability, values of LP5521_REG_ENABLE register were redefined. Signed-off-by: Milo(Woogyom) Kim <milo.kim(a)ti.com> --- drivers/leds/leds-lp5521.c | 8 +++----- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c index 8239319..3f7cfe8 100644 --- a/drivers/leds/leds-lp5521.c +++ b/drivers/leds/leds-lp5521.c @@ -261,8 +261,7 @@ static int lp5521_configure(struct i2c_client *client) /* Set engines are set to run state when OP_MODE enables engines */ ret |= lp5521_write(client, LP5521_REG_ENABLE, - LP5521_MASTER_ENABLE | LP5521_LOGARITHMIC_PWM | - LP5521_EXEC_RUN); + LP5521_ENABLE_RUN_PROGRAM); /* enable takes 500us. 1 - 2 ms leaves some margin */ usleep_range(1000, 2000); @@ -313,8 +312,7 @@ static int lp5521_detect(struct i2c_client *client) int ret; u8 buf; - ret = lp5521_write(client, LP5521_REG_ENABLE, - LP5521_MASTER_ENABLE | LP5521_LOGARITHMIC_PWM); + ret = lp5521_write(client, LP5521_REG_ENABLE, LP5521_ENABLE_DEFAULT); if (ret) return ret; /* enable takes 500us. 1 - 2 ms leaves some margin */ @@ -322,7 +320,7 @@ static int lp5521_detect(struct i2c_client *client) ret = lp5521_read(client, LP5521_REG_ENABLE, &buf); if (ret) return ret; - if (buf != (LP5521_MASTER_ENABLE | LP5521_LOGARITHMIC_PWM)) + if (buf != LP5521_ENABLE_DEFAULT) return -ENODEV; return 0; -- 1.7.4.1 -----Original Message----- From: Kim, Milo Sent: Friday, January 06, 2012 11:20 AM To: 'linux-kernel(a)vger.kernel.org'; 'rpurdie(a)rpsys.net' Cc: 'linaro-dev(a)lists.linaro.org'; 'milo.kim(a)ti.com' Subject: [PATCH] leds-lp5521: additional platform data and attributes * Changes of lp5521_platform_data > 'update_config' is added > 'name' is added Value of CONFIG register(Addr 08h) and name of led channels are dependant on the project. So these fields have been added in lp5521_platform_data. > led pattern data lp5521 has autonomous operation mode without external control. This patch includes how to configure the led patterns and load them. * Additional led class device attributes : delay_on, delay_off, blink For supporting blink mode, 3 attributes have been updated. * Additional i2c device attribute : led_pattern Platform specific led pattern can be loaded via the user-space. * Base kernel version : 3.0.9 Signed-off-by: Milo(Woogyom) Kim <milo.kim(a)ti.com> --- Documentation/leds/leds-lp5521.txt | 60 ++++++++++ drivers/leds/leds-lp5521.c | 222 +++++++++++++++++++++++++++++++++--- include/linux/leds-lp5521.h | 25 ++++ 3 files changed, 289 insertions(+), 18 deletions(-) diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt index c4d8d15..b0d6abe 100644 --- a/Documentation/leds/leds-lp5521.txt +++ b/Documentation/leds/leds-lp5521.txt @@ -3,6 +3,7 @@ Kernel driver for lp5521 * National Semiconductor LP5521 led driver chip * Datasheet: http://www.national.com/pf/LP/LP5521.html + or http://www.ti.com/product/lp5521 Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com) @@ -43,17 +44,23 @@ Format: 10x mA i.e 10 means 1.0 mA example platform data: Note: chan_nr can have values between 0 and 2. +Each channel can have own name. +If name field is not defined, the default name will be set to 'xxxx:channelN' +(XXXX : pdata->label or i2c client name, N : channel number) static struct lp5521_led_config lp5521_led_config[] = { { + .name = "red", .chan_nr = 0, .led_current = 50, .max_current = 130, }, { + .name = "green", .chan_nr = 1, .led_current = 0, .max_current = 130, }, { + .name = "blue", .chan_nr = 2, .led_current = 0, .max_current = 130, @@ -86,3 +93,56 @@ static struct lp5521_platform_data lp5521_platform_data = { If the current is set to 0 in the platform data, that channel is disabled and it is not visible in the sysfs. + +update_config : CONFIG register (ADDR 08h) +This value is platform-specific data. If NULL, the default value will be set. + +example) + +#define LP5521_CONFIGS (LP5521_PWM_HF | LP5521_PWRSAVE_EN | \ + LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \ + LP5521_CLK_INT) + +static struct lp5521_platform_data lp5521_pdata = { + .led_config = lp5521_led_config, + .num_channels = ARRAY_SIZE(lp5521_led_config), + .clock_mode = LP5521_CLOCK_INT, + .update_config = LP5521_CONFIGS, +}; + +LED patterns : LP5521 has autonomous operation without external control. +Pattern data can be defined in the platform data. + +example) +/* Pattern : RGB(50,5,0) 500ms on, 500ms off, infinite loop */ +static u8 pattern_red[] = { + 0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00, + }; + +static u8 pattern_green[] = { + 0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00, + }; + +static struct lp5521_led_pattern board_led_patterns[] = { + { + .r = pattern_r, + .g = pattern_g, + .size_r = ARRAY_SIZE(pattern_r), + .size_g = ARRAY_SIZE(pattern_g), + }, +}; + +static struct lp5521_platform_data lp5521_platform_data = { + .led_config = lp5521_led_config, + .num_channels = ARRAY_SIZE(lp5521_led_config), + .clock_mode = LP5521_CLOCK_EXT, + .patterns = board_led_patterns, + .num_patterns = ARRAY_SIZE(board_led_patterns), +}; + +Then the predefined led pattern can be executed via the user-space. +To start the pattern #1, +# echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern +(xxxx : i2c bus & slave address) +To end the pattern, +# echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c index cc1dc48..8239319 100644 --- a/drivers/leds/leds-lp5521.c +++ b/drivers/leds/leds-lp5521.c @@ -80,23 +80,23 @@ /* Bits in ENABLE register */ #define LP5521_MASTER_ENABLE 0x40 /* Chip master enable */ #define LP5521_LOGARITHMIC_PWM 0x80 /* Logarithmic PWM adjustment */ +#define LP5521_EXEC_MASK 0xC0 #define LP5521_EXEC_RUN 0x2A - -/* Bits in CONFIG register */ -#define LP5521_PWM_HF 0x40 /* PWM: 0 = 256Hz, 1 = 558Hz */ -#define LP5521_PWRSAVE_EN 0x20 /* 1 = Power save mode */ -#define LP5521_CP_MODE_OFF 0 /* Charge pump (CP) off */ -#define LP5521_CP_MODE_BYPASS 8 /* CP forced to bypass mode */ -#define LP5521_CP_MODE_1X5 0x10 /* CP forced to 1.5x mode */ -#define LP5521_CP_MODE_AUTO 0x18 /* Automatic mode selection */ -#define LP5521_R_TO_BATT 4 /* R out: 0 = CP, 1 = Vbat */ -#define LP5521_CLK_SRC_EXT 0 /* Ext-clk source (CLK_32K) */ -#define LP5521_CLK_INT 1 /* Internal clock */ -#define LP5521_CLK_AUTO 2 /* Automatic clock selection */ +#define LP5521_EXEC_HOLD 0x00 +#define LP5521_ENABLE_DEFAULT \ + (LP5521_MASTER_ENABLE | LP5521_LOGARITHMIC_PWM) +#define LP5521_ENABLE_RUN_PROGRAM \ + (LP5521_ENABLE_DEFAULT | LP5521_EXEC_RUN) /* Status */ #define LP5521_EXT_CLK_USED 0x08 +/* Blink mode */ +#define ALWAYS_OFF 0 + +/* Pattern Mode */ +#define PATTERN_OFF 0 + struct lp5521_engine { int id; u8 mode; @@ -112,6 +112,8 @@ struct lp5521_led { struct led_classdev cdev; struct work_struct brightness_work; u8 brightness; + int delay_on; + int delay_off; }; struct lp5521_chip { @@ -237,6 +239,7 @@ static void lp5521_init_engine(struct lp5521_chip *chip) static int lp5521_configure(struct i2c_client *client) { struct lp5521_chip *chip = i2c_get_clientdata(client); + u8 cfg = chip->pdata->update_config; int ret; lp5521_init_engine(chip); @@ -244,9 +247,12 @@ static int lp5521_configure(struct i2c_client *client) /* Set all PWMs to direct control mode */ ret = lp5521_write(client, LP5521_REG_OP_MODE, 0x3F); - /* Enable auto-powersave, set charge pump to auto, red to battery */ - ret |= lp5521_write(client, LP5521_REG_CONFIG, - LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT); + if (cfg) + ret |= lp5521_write(client, LP5521_REG_CONFIG, cfg); + else + ret |= lp5521_write(client, LP5521_REG_CONFIG, + LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | + LP5521_R_TO_BATT); /* Initialize all channels PWM to zero -> leds off */ ret |= lp5521_write(client, LP5521_REG_R_PWM, 0); @@ -533,13 +539,184 @@ static ssize_t lp5521_selftest(struct device *dev, return sprintf(buf, "%s\n", ret ? "FAIL" : "OK"); } +static void lp5521_clear_program_memory(struct i2c_client *cl) +{ + int i; + u8 rgb_mem[] = { + LP5521_REG_R_PROG_MEM, + LP5521_REG_G_PROG_MEM, + LP5521_REG_B_PROG_MEM, + }; + + for (i = 0; i < ARRAY_SIZE(rgb_mem); i++) { + lp5521_write(cl, rgb_mem[i], 0); + lp5521_write(cl, rgb_mem[i] + 1, 0); + } +} + +static void lp5521_write_program_memory(struct i2c_client *cl, + u8 base, u8 *rgb, int size) +{ + int i; + + if (!rgb || size <= 0) + return; + + for (i = 0; i < size; i++) + lp5521_write(cl, base + i, *(rgb + i)); + + lp5521_write(cl, base + i, 0); + lp5521_write(cl, base + i + 1, 0); +} + +static inline struct lp5521_led_pattern *lp5521_get_pattern + (struct lp5521_chip *chip, u8 offset) +{ + struct lp5521_led_pattern *pattern; + pattern = chip->pdata->patterns + (offset - 1); + return pattern; +} + +static void lp5521_run_led_pattern(int mode, struct lp5521_chip *chip) +{ + struct lp5521_led_pattern *ptn; + struct i2c_client *cl = chip->client; + u8 num_patterns = chip->pdata->num_patterns; + + if (mode > num_patterns || !(chip->pdata->patterns)) + return; + + if (mode == PATTERN_OFF) { + lp5521_write(cl, LP5521_REG_ENABLE, LP5521_ENABLE_DEFAULT); + usleep_range(1000, 2000); + lp5521_write(cl, LP5521_REG_OP_MODE, LP5521_CMD_DIRECT); + } else { + ptn = lp5521_get_pattern(chip, mode); + if (!ptn) + return; + + lp5521_write(cl, LP5521_REG_OP_MODE, LP5521_CMD_LOAD); + usleep_range(1000, 2000); + + lp5521_clear_program_memory(cl); + + lp5521_write_program_memory(cl, LP5521_REG_R_PROG_MEM, + ptn->r, ptn->size_r); + lp5521_write_program_memory(cl, LP5521_REG_G_PROG_MEM, + ptn->g, ptn->size_g); + lp5521_write_program_memory(cl, LP5521_REG_B_PROG_MEM, + ptn->b, ptn->size_b); + + lp5521_write(cl, LP5521_REG_OP_MODE, LP5521_CMD_RUN); + usleep_range(1000, 2000); + lp5521_write(cl, LP5521_REG_ENABLE, LP5521_ENABLE_RUN_PROGRAM); + } +} + +static ssize_t store_led_pattern(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t len) +{ + struct lp5521_chip *chip = i2c_get_clientdata(to_i2c_client(dev)); + unsigned long val; + int ret; + + ret = strict_strtoul(buf, 16, &val); + if (ret) + return ret; + + lp5521_run_led_pattern(val, chip); + + return len; +} + +static ssize_t show_delay_on(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + + return sprintf(buf, "%d\n", led->delay_on); +} + +static ssize_t store_delay_on(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t len) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + unsigned long curr; + + if (strict_strtoul(buf, 0, &curr)) + return -EINVAL; + + led->delay_on = (int)curr; + + return len; +} + +static ssize_t show_delay_off(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + + return sprintf(buf, "%d\n", led->delay_off); +} + +static ssize_t store_delay_off(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t len) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + unsigned long curr; + + if (strict_strtoul(buf, 0, &curr)) + return -EINVAL; + + led->delay_off = (int)curr; + + return len; +} + +static ssize_t store_blink(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t len) +{ + struct led_classdev *led_cdev = dev_get_drvdata(dev); + struct lp5521_led *led = cdev_to_led(led_cdev); + unsigned long is_blink_set; + unsigned long on = led->delay_on; + unsigned long off = led->delay_off; + + if (strict_strtoul(buf, 0, &is_blink_set)) + return -EINVAL; + + if (!is_blink_set) + on = ALWAYS_OFF; + + led_blink_set(led_cdev, &on, &off); + + return len; +} + /* led class device attributes */ static DEVICE_ATTR(led_current, S_IRUGO | S_IWUSR, show_current, store_current); static DEVICE_ATTR(max_current, S_IRUGO , show_max_current, NULL); +static DEVICE_ATTR(delay_on, S_IRUGO | S_IWUSR, show_delay_on, store_delay_on); +static DEVICE_ATTR(delay_off, S_IRUGO | S_IWUSR, show_delay_off, + store_delay_off); +static DEVICE_ATTR(blink, S_IWUSR, NULL, store_blink); static struct attribute *lp5521_led_attributes[] = { &dev_attr_led_current.attr, &dev_attr_max_current.attr, + &dev_attr_delay_on.attr, + &dev_attr_delay_off.attr, + &dev_attr_blink.attr, NULL, }; @@ -558,6 +735,7 @@ static DEVICE_ATTR(engine1_load, S_IWUSR, NULL, store_engine1_load); static DEVICE_ATTR(engine2_load, S_IWUSR, NULL, store_engine2_load); static DEVICE_ATTR(engine3_load, S_IWUSR, NULL, store_engine3_load); static DEVICE_ATTR(selftest, S_IRUGO, lp5521_selftest, NULL); +static DEVICE_ATTR(led_pattern, S_IWUSR, NULL, store_led_pattern); static struct attribute *lp5521_attributes[] = { &dev_attr_engine1_mode.attr, @@ -567,6 +745,7 @@ static struct attribute *lp5521_attributes[] = { &dev_attr_engine1_load.attr, &dev_attr_engine2_load.attr, &dev_attr_engine3_load.attr, + &dev_attr_led_pattern.attr, NULL }; @@ -617,10 +796,16 @@ static int __devinit lp5521_init_led(struct lp5521_led *led, return -EINVAL; } - snprintf(name, sizeof(name), "%s:channel%d", - pdata->label ?: client->name, chan); led->cdev.brightness_set = lp5521_set_brightness; - led->cdev.name = name; + + if (pdata->led_config[chan].name) { + led->cdev.name = pdata->led_config[chan].name; + } else { + snprintf(name, sizeof(name), "%s:channel%d", + pdata->label ?: client->name, chan); + led->cdev.name = name; + } + res = led_classdev_register(dev, &led->cdev); if (res < 0) { dev_err(dev, "couldn't register led on channel %d\n", chan); @@ -749,6 +934,7 @@ static int lp5521_remove(struct i2c_client *client) struct lp5521_chip *chip = i2c_get_clientdata(client); int i; + lp5521_run_led_pattern(PATTERN_OFF, chip); lp5521_unregister_sysfs(client); for (i = 0; i < chip->num_leds; i++) { diff --git a/include/linux/leds-lp5521.h b/include/linux/leds-lp5521.h index fd548d2..c842527 100644 --- a/include/linux/leds-lp5521.h +++ b/include/linux/leds-lp5521.h @@ -26,23 +26,48 @@ /* See Documentation/leds/leds-lp5521.txt */ struct lp5521_led_config { + char *name; u8 chan_nr; u8 led_current; /* mA x10, 0 if led is not connected */ u8 max_current; }; +struct lp5521_led_pattern { + u8 *r; + u8 *g; + u8 *b; + u8 size_r; + u8 size_g; + u8 size_b; +}; + #define LP5521_CLOCK_AUTO 0 #define LP5521_CLOCK_INT 1 #define LP5521_CLOCK_EXT 2 +/* Bits in CONFIG register */ +#define LP5521_PWM_HF 0x40 /* PWM: 0 = 256Hz, 1 = 558Hz */ +#define LP5521_PWRSAVE_EN 0x20 /* 1 = Power save mode */ +#define LP5521_CP_MODE_OFF 0 /* Charge pump (CP) off */ +#define LP5521_CP_MODE_BYPASS 8 /* CP forced to bypass mode */ +#define LP5521_CP_MODE_1X5 0x10 /* CP forced to 1.5x mode */ +#define LP5521_CP_MODE_AUTO 0x18 /* Automatic mode selection */ +#define LP5521_R_TO_BATT 4 /* R out: 0 = CP, 1 = Vbat */ +#define LP5521_CLK_SRC_EXT 0 /* Ext-clk source (CLK_32K) */ +#define LP5521_CLK_INT 1 /* Internal clock */ +#define LP5521_CLK_AUTO 2 /* Automatic clock selection */ + struct lp5521_platform_data { struct lp5521_led_config *led_config; u8 num_channels; u8 clock_mode; + u8 update_config; int (*setup_resources)(void); void (*release_resources)(void); void (*enable)(bool state); const char *label; + struct lp5521_led_pattern *patterns; + u8 num_patterns; }; #endif /* __LINUX_LP5521_H */ -- 1.7.4.1 Best Regards Milo (Woogyom) Kim Texas Instruments Incorporated

13 years, 3 months

Architectures to support when releasing binaries

by Michael Hope

Hi there. I have a style question. For the pre-built versions of gcc-linaro, should we release a i686 version that also runs on x86_64, or do separate i686 and x86_64 builds? If we do just an i686 version then: * There's less to test * There's one 'linux' binary so less confusion on what to download and a simpler download page * Most end users will already have the 32 bit libraries due to Skype or Flash but it has some downsides: * May not work 'out of the box' * Cryptic failures if you don't have the 32 bit libraries installed * Some users can't install extra packages and may not be allowed the 32 bit libraries There's no real performance or compatibility advantage in also having an x86_64 build. Any thoughts? I quite like having an i686 only build but am worried about the initial experience. -- Michael

13 years, 3 months

gold generate broken sysv-style hash table when --hash-style=both

by Kito Cheng

Hello, Recently we are make the dynamic linker support GNU-style hash, but for the compatible reason we build android with -Wl,--hash-style=both instead of -Wl,--hash-style=gnu. And then we discover this bug in gold, gold generate broken sysv-style hash table when --hash-style=both, we already file a bug to bugzilla for bintuils[1]. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=13597

13 years, 3 months

[PATCH] mx53_loco: add DA9053 PMIC support

by Ying-Chun Liu (PaulLiu)

From: "Ying-Chun Liu (PaulLiu)" <paul.liu(a)linaro.org> Hi, This patch adds da9053 init for Freescale QuickStart Loco board. DA9053 is a MFD device. On QuickStart Loco board we are using the regulators provided by it. Please help us to review this patch. Many Thanks. Ying-Chun Liu (PaulLiu) (1): mx53_loco: add DA9053 PMIC support arch/arm/mach-mx5/board-mx53_loco.c | 128 +++++++++++++++++++++++++++++++++ arch/arm/plat-mxc/include/mach/irqs.h | 10 +++- 2 files changed, 137 insertions(+), 1 deletions(-) -- 1.7.8.3

13 years, 3 months

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev January 2012