linaro-dev April 2012

linaro-dev@lists.linaro.org

113 participants
85 discussions

[PATCH v2 1/2] mfd: da9052: add device-tree support for i2c driver

by Ying-Chun Liu (PaulLiu)

From: "Ying-Chun Liu (PaulLiu)" <paul.liu(a)linaro.org> This patch adds device-tree support for dialog MFD and the binding documentations. Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org> Cc: Samuel Ortiz <sameo(a)linux.intel.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Shawn Guo <shawn.guo(a)linaro.org> Cc: Ashish Jangam <ashish.jangam(a)kpitcummins.com> --- .../devicetree/bindings/mfd/da9052-i2c.txt | 64 ++++++++++++++++++++ drivers/mfd/da9052-i2c.c | 51 +++++++++++++--- 2 files changed, 107 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/da9052-i2c.txt diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt new file mode 100644 index 0000000..bf4ea23 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt @@ -0,0 +1,64 @@ +* Dialog DA9052/53 Power Management Integrated Circuit (PMIC) + +Required properties: +- compatible : Should be "dlg,da9052", "dlg,da9053-aa", + "dlg,da9053-ab", or "dlg,da9053-bb" + +Sub-nodes: +- regulators : Contain the regulator nodes. The DA9052/53 regulators are + bound using their names as listed below: + + buck0 : regulator BUCK0 + buck1 : regulator BUCK1 + buck2 : regulator BUCK2 + buck3 : regulator BUCK3 + ldo4 : regulator LDO4 + ldo5 : regulator LDO5 + ldo6 : regulator LDO6 + ldo7 : regulator LDO7 + ldo8 : regulator LDO8 + ldo9 : regulator LDO9 + ldo10 : regulator LDO10 + ldo11 : regulator LDO11 + ldo12 : regulator LDO12 + ldo13 : regulator LDO13 + + The bindings details of individual regulator device can be found in: + Documentation/devicetree/bindings/regulator/regulator.txt + +Examples: + +i2c@63fc8000 { /* I2C1 */ + status = "okay"; + + pmic: dialog@48 { + compatible = "dlg,da9053-aa"; + reg = <0x48>; + + regulators { + buck0 { + regulator-name = "DA9052_BUCK_CORE"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <2075000>; + }; + + buck1 { + regulator-name = "DA9052_BUCK_PRO"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <2075000>; + }; + + buck2 { + regulator-name = "DA9052_BUCK_MEM"; + regulator-min-microvolt = <925000>; + regulator-max-microvolt = <2500000>; + }; + + buck3 { + regulator-name = "DA9052_BUCK_PERI"; + regulator-min-microvolt = <925000>; + regulator-max-microvolt = <2500000>; + }; + }; + }; +}; diff --git a/drivers/mfd/da9052-i2c.c b/drivers/mfd/da9052-i2c.c index 36b88e3..b946b0ff 100644 --- a/drivers/mfd/da9052-i2c.c +++ b/drivers/mfd/da9052-i2c.c @@ -22,6 +22,11 @@ #include <linux/mfd/da9052/da9052.h> #include <linux/mfd/da9052/reg.h> +#ifdef CONFIG_OF +#include <linux/of.h> +#include <linux/of_device.h> +#endif + static int da9052_i2c_enable_multiwrite(struct da9052 *da9052) { int reg_val, ret; @@ -41,6 +46,24 @@ static int da9052_i2c_enable_multiwrite(struct da9052 *da9052) return 0; } +static struct i2c_device_id da9052_i2c_id[] = { + {"da9052", DA9052}, + {"da9053-aa", DA9053_AA}, + {"da9053-ba", DA9053_BA}, + {"da9053-bb", DA9053_BB}, + {} +}; + +#ifdef CONFIG_OF +static const struct of_device_id dialog_dt_ids[] = { + { .compatible = "dlg,da9052", .data = &da9052_i2c_id[0] }, + { .compatible = "dlg,da9053-aa", .data = &da9052_i2c_id[1] }, + { .compatible = "dlg,da9053-ab", .data = &da9052_i2c_id[2] }, + { .compatible = "dlg,da9053-bb", .data = &da9052_i2c_id[3] }, + { /* sentinel */ } +}; +#endif + static int __devinit da9052_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -76,6 +99,23 @@ static int __devinit da9052_i2c_probe(struct i2c_client *client, if (ret < 0) goto err_regmap; +#ifdef CONFIG_OF + if (!id) { + int i; + struct device_node *np = client->dev.of_node; + const struct of_device_id *deviceid; + + deviceid = of_match_node(np, dialog_dt_ids); + id = (const struct i2c_device_id *)(deviceid->data); + } +#endif + + if (!id) { + ret = -ENODEV; + dev_err(&client->dev, "id is null.\n"); + goto err_regmap; + } + ret = da9052_device_init(da9052, id->driver_data); if (ret != 0) goto err_regmap; @@ -100,14 +140,6 @@ static int __devexit da9052_i2c_remove(struct i2c_client *client) return 0; } -static struct i2c_device_id da9052_i2c_id[] = { - {"da9052", DA9052}, - {"da9053-aa", DA9053_AA}, - {"da9053-ba", DA9053_BA}, - {"da9053-bb", DA9053_BB}, - {} -}; - static struct i2c_driver da9052_i2c_driver = { .probe = da9052_i2c_probe, .remove = __devexit_p(da9052_i2c_remove), @@ -115,6 +147,9 @@ static struct i2c_driver da9052_i2c_driver = { .driver = { .name = "da9052", .owner = THIS_MODULE, +#ifdef CONFIG_OF + .of_match_table = dialog_dt_ids, +#endif }, }; -- 1.7.9.5

12 years

Re: [RFC] Scheduler recorder and playback

by Dmitry Antipov

On 04/12/2012 04:51 PM, Pantelis Antoniou wrote: > The data file is not readable by me version of perf. Oops. This should be investigated. We definitely wants the perf data to be portable (or, at least, portable with some limitations between different hardware of the same major architecture). Could you give me an example of your perf.data? > Can you point to the pandaboard kernel that you use? The kernel is 3.4.0-rc2+ (git 258f742635360175564e9470eb060ff4d4b984e7) cloned from Linus' tree. Dmitry

12 years

About how to integrate android test into LAVA

by YongQin Liu

Hi, All LAVA is an automated validation architecture, and it now has a test framework for running android test tools and parsing the test output. Please NOTE that lava-android-test is just used for running the test tools, parsing the test output, and formatting the test result. Here I will describe how to write and add a test wrapper script for lava-android-test, and how to integrate the test into LAVA. 1. checkout the lava-android-test to your local machine bzr branch lp:lava-android-test 2. if the test tools are just command that can be run on android system, and the output is well formatted, then congratulations, you can go directly to step 6. You don't need to wrapper script again. 3. If the test tools has already been build into the android image or in the host image(normal Ubuntu image), then you won't need to define some scripts for organizing the test tools, you can skip this step, Otherwise, put the actual test tools in some place, normally they are in a sub directory of test_definitions, like the busybox test: the actual test tool is busybox_test.sh, and it is put in the * lava_android_test/test_definitions/busybox *directory 4. add a test wrapper script for your test into the test_definitions directory. like busybox.py: The content of the wrapper script should be something like below: Normally, you just need to redefine the red and bold part in the above. ############################################################################################### import os import lava_android_test.testdef test_name = '*test_sample'* #linux commands that will be run on the host before INSTALL_STEPS_ADB_PRE" *INSTALL_STEPS_HOST_PRE = []* #adb commands that will be run before install apk file into android *INSTALL_STEPS_ADB_PRE = []* #APK file path list that will be intalled into android *APKS= []* #adb commands that will be run before install apk file into android *INSTALL_STEPS_ADB_POST = []* #linux commands that will be run on the host after INSTALL_STEPS_ADB_POST *INSTALL_STEPS_HOST_POST = []* #linux commands that will be run on the host before RUN_STEPS_ADB_PRE *RUN_STEPS_HOST_PRE = []* #adb commands that will be run before install apk file into android *RUN_STEPS_ADB_PRE = []* #commands that will be run on android *ADB_SHELL_STEPS = []* #adb commands that will be run before install apk file into android *RUN_STEPS_ADB_POST = []* #linux commands that will be run on the host after RUN_STEPS_ADB_POST *RUN_STEPS_HOST_POST = []* #pattern to parse the command output to generate the test result. PATTERN =* **"^\s*(?P<test_case_id>\w+)=(?P<result>\w+)\s*$"* inst = lava_android_test.testdef.AndroidTestInstaller(steps_host_pre= INSTALL_STEPS_HOST_PRE, steps_adb_pre=INSTALL_STEPS_ADB_PRE, apks=APKS, steps_adb_post=INSTALL_STEPS_ADB_POST, steps_host_post=INSTALL_STEPS_HOST_POST) run = lava_android_test.testdef.AndroidTestRunner(steps_host_pre= RUN_STEPS_HOST_PRE, steps_adb_pre=RUN_STEPS_ADB_PRE, adbshell_steps=ADB_SHELL_STEPS, steps_adb_post=RUN_STEPS_ADB_POST, steps_host_post=RUN_STEPS_HOST_POST) parser = lava_android_test.testdef.AndroidTestParser(PATTERN) testobj = lava_android_test.testdef.AndroidTest(testname=test_name, installer=inst, runner=run, parser=parser) ############################################################################################### And in the command part, you can use "$(SERIAL)" to represent the device serial number, like: RUN_STEPS_HOST_POST = [ 'python %s/android-0xbenchmark/android_0xbenchmark_wait.py $(SERIAL)' % curdir] and "$(OPTIONS)" to represent the option string passed from command line. Like INSTALL_STEPS_HOST_PRE = [ 'echo $(OPTION)'], RUN_STEPS_HOST_PRE = [ 'echo $(OPTION)'], then you can run *lava-android-test install -o "install options string" *or* **lava-android-test run -O "run options string"* *Note:* * B**ecause lava-android-test will be run on lava-lab, and there will be multiple devices connected simultaneously,* * So we should consider to pass the device serial number for each test tools.* * If the test tools is defined for steps_adb_pre/adbshell_steps/steps_adb_post,* * then there is no need to pass the device serial number,** lava-android-test will do this for you.* 5. you can use "lava-android-test list-tests" to check if the test wrapper created can be recognized, use "lava-android-test install ${test_name}" to install the test, use "lava-android-test run ${test_name}" to execute the test, use "lava-android-test show ${result_id}" to show the output the test executed, use "lava-android-test parse ${result_id}" to to generate the result bundle for the test executed. And here is a blog about install/test lava-android-test that you can reference: http://www.linaro.org/linaro-blog/2011/12/01/local-lava-testing-of-android-… 6. When you have done the above steps and verified your test that works well, then you can integrate it in LAVA with the android-build. Here is a description about that. https://wiki.linaro.org/Platform/Android/AndroidBuild-LavaIntegration If you have any questions, please contact me. Also I have copied it to google docs, https://docs.google.com/a/linaro.org/document/d/1kVyuFZtnMsganZaszQZhgX3QPO… you can comment directly there. Thanks, Yongqin Liu *--------------------------------- Mail: yongqin.liu(a)linaro.org. IRC Nickname: liuyq*

12 years

Which kernel should outside developers use?

by Chris Simmonds

Hello, I am working on behalf of an SoC vendor and I am trying to work out which (if any) of the many git trees at http://git.linaro.org/gitweb we should base our work on. I would like to use the Linaro code base because the arch/arm support is ahead of mainline. But I also need a degree of stability. Ideally I would like a "long term support" Linaro kernel. Since that doesn't exist, one approach is use the linux-linaro-tracking tree but only use the linux-linaro-3.0* tagged versions so that we can easily merge in changes from v3.0 from kernel.org linux-stable. So my questions are 1. Is this a rational approach? 2. Is this how you imagine other projects interfacing with Linaro? Or should we really be waiting for Linaro code to be mainlined and pulling from kernel.org? Bye for now, Chris Simmonds

12 years

Flyswatter2 + origen board

by Subash Patel

Hello, I am interested to know if anyone from Linaro has attempted using Flyswatter2 on origen board. I am trying to use openocd for origen board, and found issues as early as in reading tapid. Any pointers/help on this is appreciated. Note: I saw some discussion on this in irc-logs, but I couldn't get any response on irc yesterday. Regards, Subash

12 years

Linaro embedded Linux distro?

by Zach Pfeffer

During ELC a few people asked me if Linaro had something bigger than nano and smaller than Ubuntu that they could use to build stuff. Of course I said Android, but a lot of people actually want a regular Linux platform where they can easily recompile what they need to hack on, add their own libs and scripts and generally work in an "embedded, cross build way." I know there's OpenEmbedded and I've heard of something called "livebuild." Does anyone have anymore info? This class of users is arguably the largest class of people using these boards so creating something targeted at them would allow them to get all the benefits of Linaro in a easy to use fashion. -- 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

12 years

[PATCH 1/2] mfd: da9052: add device-tree support for i2c driver

by Ying-Chun Liu (PaulLiu)

From: "Ying-Chun Liu (PaulLiu)" <paul.liu(a)linaro.org> This patch adds device-tree support for dialog MFD and the binding documentations. Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu(a)linaro.org> Cc: Samuel Ortiz <sameo(a)linux.intel.com> Cc: Shawn Guo <shawn.guo(a)linaro.org> Cc: Ashish Jangam <ashish.jangam(a)kpitcummins.com> --- .../devicetree/bindings/mfd/da9052-i2c.txt | 58 ++++++++++++++++++++ drivers/mfd/da9052-i2c.c | 54 +++++++++++++++--- 2 files changed, 104 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/da9052-i2c.txt diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt new file mode 100644 index 0000000..042d042 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt @@ -0,0 +1,58 @@ +* Dialog DA9052/53 Power Management Integrated Circuit (PMIC) + +Required properties: +- compatible : Should be "dialog,da9052", "dialog,da9053-aa", + "dialog,da9053-ab", or "dialog,da9053-bb" + +Sub-nodes: +- regulators : Contain the regulator nodes. The DA9052 regulators are + sorted as following: + + buck_core : regulator BUCK_CORE (id: 0 ) + buck_pro : regulator BUCK_PRO (id: 1 ) + buck_mem : regulator BUCK_MEM (id: 2 ) + buck_peri : regulator BUCK_PERI (id: 3 ) + ldo1 : regulator LDO1 (id: 4 ) + ldo2 : regulator LDO2 (id: 5 ) + ldo3 : regulator LDO3 (id: 6 ) + ldo4 : regulator LDO4 (id: 7 ) + ldo5 : regulator LDO5 (id: 8 ) + ldo6 : regulator LDO6 (id: 9 ) + ldo7 : regulator LDO7 (id: 10) + ldo8 : regulator LDO8 (id: 11) + ldo9 : regulator LDO9 (id: 12) + ldo10 : regulator LDO10 (id: 13) + + The bindings details of individual regulator device can be found in: + Documentation/devicetree/bindings/regulator/regulator.txt + +Examples: + +i2c@63fc8000 { /* I2C1 */ + status = "okay"; + + pmic: dialog@48 { + compatible = "dialog,da9053-aa"; + reg = <0x48>; + + regulators { + regulator-buck0 { + regulator-name = "DA9052_BUCK_CORE"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <2075000>; + }; + + regulator-buck1 { + regulator-name = "DA9052_BUCK_PRO"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <2075000>; + }; + + regulator-buck2 { + regulator-name = "DA9052_BUCK_MEM"; + regulator-min-microvolt = <925000>; + regulator-max-microvolt = <2500000>; + }; + }; + }; +}; diff --git a/drivers/mfd/da9052-i2c.c b/drivers/mfd/da9052-i2c.c index 36b88e3..e07bcfa 100644 --- a/drivers/mfd/da9052-i2c.c +++ b/drivers/mfd/da9052-i2c.c @@ -22,6 +22,11 @@ #include <linux/mfd/da9052/da9052.h> #include <linux/mfd/da9052/reg.h> +#ifdef CONFIG_OF +#include <linux/of.h> +#include <linux/of_device.h> +#endif + static int da9052_i2c_enable_multiwrite(struct da9052 *da9052) { int reg_val, ret; @@ -41,6 +46,24 @@ static int da9052_i2c_enable_multiwrite(struct da9052 *da9052) return 0; } +static struct i2c_device_id da9052_i2c_id[] = { + {"da9052", DA9052}, + {"da9053-aa", DA9053_AA}, + {"da9053-ba", DA9053_BA}, + {"da9053-bb", DA9053_BB}, + {} +}; + +#ifdef CONFIG_OF +static const struct of_device_id dialog_dt_ids[] = { + { .compatible = "dialog,da9052" }, + { .compatible = "dialog,da9053-aa" }, + { .compatible = "dialog,da9053-ab" }, + { .compatible = "dialog,da9053-bb" }, + { /* sentinel */ } +}; +#endif + static int __devinit da9052_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -76,6 +99,26 @@ static int __devinit da9052_i2c_probe(struct i2c_client *client, if (ret < 0) goto err_regmap; +#ifdef CONFIG_OF + if (!id) { + int i; + struct device_node *np = client->dev.of_node; + + for (i = 0; + i < sizeof(dialog_dt_ids)/sizeof(dialog_dt_ids[0]); + i++) + if (of_device_is_compatible(np, + dialog_dt_ids[i].compatible)) + id = &da9052_i2c_id[i]; + } +#endif + + if (!id) { + ret = -ENODEV; + dev_err(&client->dev, "id is null.\n"); + goto err_regmap; + } + ret = da9052_device_init(da9052, id->driver_data); if (ret != 0) goto err_regmap; @@ -100,14 +143,6 @@ static int __devexit da9052_i2c_remove(struct i2c_client *client) return 0; } -static struct i2c_device_id da9052_i2c_id[] = { - {"da9052", DA9052}, - {"da9053-aa", DA9053_AA}, - {"da9053-ba", DA9053_BA}, - {"da9053-bb", DA9053_BB}, - {} -}; - static struct i2c_driver da9052_i2c_driver = { .probe = da9052_i2c_probe, .remove = __devexit_p(da9052_i2c_remove), @@ -115,6 +150,9 @@ static struct i2c_driver da9052_i2c_driver = { .driver = { .name = "da9052", .owner = THIS_MODULE, +#ifdef CONFIG_OF + .of_match_table = dialog_dt_ids, +#endif }, }; -- 1.7.9.5

12 years

Re: [Activity] (Omar Ramirez) Apr 2 - Apr 8

by Christian Robottom Reis

On Mon, Apr 09, 2012 at 08:24:51PM -0500, Omar Ramirez Luna wrote: > == Omar Ramirez <omarrmz> == > > === Highlights === > > * Working on device tree for mailbox: > > Find a kernel that works with DT for pandaboard (OMAP4): > - k3.4-rc1 doesn't recognize DT blob, k3.3 DT panics at boot. > - DT has to be appended to zImage. > > Find a DT uboot: > - secretlab.ca uboot doesn't have usb support for panda, having > problems with fatload and mmc. > - linaro uboot has problems recognizing dt blob in memory (bootm > ${kern} - ${dtb}; doesn't work properly). This is a bit unexpected -- is there really nobody currently booting Panda using a DT? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs

12 years

3.4 based config-fragment tree for 12.04

by John Stultz

Hey Andrey, I rebased the config-fragment tree to 3.4-rc2, and you can find it here: git://git.linaro.org/people/jstultz/android.git linaro-configs-3.4 Let me know if you run into any issues. thanks -john

12 years

ANN: live-build_3.0~a45-1-1linaro3

by Tom Gall

Announcing the release of live-build_3.0~a45-1-1linaro3 to ppa:linaro-maintainers/tools Included in this release are two minor but important fixes 1) for cross builds make sure to qualify the use of the linaro-overlay ppa correctly so armel isn't hardcoded 2) for precise, defend against the movement of insserv out of the system path, which if not present will cause packages such as module-init-tools to fail. -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

12 years

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev April 2012