Re: Linaro 12.04 3.4-rc1 based androidization branch is available
Hi John On 11/04/12 20:19, John Stultz wrote: On 04/09/2012 03:18 PM, John Stultz wrote: I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1. You can grab it here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.4-jstultz-rebase Sigh. Looks like the Google devs are following close behind and released their own 3.4-rc2 based tree. Don't get me wrong: Its great to see them keeping up with mainline, but I've clearly duplicated their work this cycle. I've gone ahead and mirrored the AOSP 3.4 tree here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.4 Are you going to add "merge_config.sh" into this branch? Andrey: Probably you're call on this. If you've already merged in my rebase tree it should be fine for 12.04, but if not you might want to jump over to the AOSP 3.4 tree. thanks -john ___ 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 00/13] common clk framework misc fixes
On Wed, Apr 11, 2012 at 06:02:38PM -0700, Mike Turquette wrote: > This series collects many of the fixes posted for the recently merged > common clock framework as well as some general clean-up. Most of the > code classifies as a clean-up moreso than a bug fix; hopefully this is > not a problem since the common clk framework is new code pulled for 3.4. Can you please CC people on your cover letters as well as on the individual patches? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 12.04 3.4-rc1 based androidization branch is available
Hi John When using the linaro-android-3.4 branch the mouse buttons don't seem to work. I've tracked the problem down to something you fixed in linaro-android-3.4-jstultz-rebase, namely: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commit;h=2d571b539f94918e416971d0d2a7584544906f2c Can you add this to linaro-android-3.4 and any other fixes you did that might be missing? Cheers -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Which kernel should outside developers use?
On Wednesday 04 April 2012, Chris Simmonds wrote: > > On 04/04/12 11:53, Amit Kucheria wrote: > > On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds > > wrote: > >> 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 > > > > Is this a new SoC (no mainline support) or an existing SoC? > > It's a new SoC which will have its own arch/arm/mach-xxx directory In this case, the Linaro kernels don't help you. Just use the upstream kernel from Linus Torvalds directly, starting with v3.4-rc1. This has gained a lot of the new features that you need for new SoC work, including device tree bindings for a lot of subsystems, common clk framework and the pinctrl subsystem. Make sure you pick the right templates for new work. For instance, the mach-highbank and mach-zynq platforms are good examples for how new platforms should be structured. Don't copy from the older ones, as we are currently in the process of rewriting most of them, which would result in you having to do the same changes as the common code changes. This should not be a hard thing to do, because the changes we make upstream are intended to make it easier and require less code to get a new platform supported and merged. The 3.0 LTSI kernel is a bit problematic, because 3.0 predates most of the changes that are impacting your work, so it would not be possible to port bug fixes between 3.0-LTSI and upstream kernels. There will be a new LTSI kernel in the future, presumably based on v3.4, and I would strongly recommend starting with that for a new SoC platform because most of the large scale infrastructure changes have already made it into that version, so it will remain more or less compatible for a far longer time. If you have current users on 3.0 or older private kernel versions, it makes sense to keep them on that platform until 3.4 has stabilized enough, but there is no point in trying hard to make code portable between the two versions -- you should just consider 3.0 as a dead end and move all products away from that in the mid-term. If you need help in getting the new mach-xxx directory right, feel free to send me a git URL or a patch against a kernel release for review (ideally on-list with me on Cc, but private mail is ok if you require confidentiality), so I can tell you which parts you need to change in order to get long term maintainability and get your code merged upstream in a timely manner. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 12.04 3.4-rc1 based androidization branch is available
On 04/13/2012 02:48 PM, Sangwook Lee wrote: > Hi John > > On 11/04/12 20:19, John Stultz wrote: >> On 04/09/2012 03:18 PM, John Stultz wrote: >>> I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1. >>> >>> You can grab it here: >>> git://git.linaro.org/people/jstultz/android.git >>> linaro-android-3.4-jstultz-rebase >> >> Sigh. Looks like the Google devs are following close behind and released >> their own 3.4-rc2 based tree. >> >> Don't get me wrong: Its great to see them keeping up with mainline, but >> I've clearly duplicated their work this cycle. >> >> I've gone ahead and mirrored the AOSP 3.4 tree here: >> git://git.linaro.org/people/jstultz/android.git linaro-android-3.4 > > Are you going to add "merge_config.sh" into this branch? > merge_config.sh is in linaro-configs-3.4 on John's tree. The related patches have also been part of topic/base. >> >> Andrey: Probably you're call on this. If you've already merged in my >> rebase tree it should be fine for 12.04, but if not you might want to >> jump over to the AOSP 3.4 tree. >> >> thanks >> -john >> >> >> ___ >> 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 -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 12.04 3.4-rc1 based androidization branch is available
On 04/13/2012 04:19 PM, Tushar Behera wrote: > On 04/13/2012 02:48 PM, Sangwook Lee wrote: >> Hi John >> >> On 11/04/12 20:19, John Stultz wrote: >>> On 04/09/2012 03:18 PM, John Stultz wrote: I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1. You can grab it here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.4-jstultz-rebase >>> >>> Sigh. Looks like the Google devs are following close behind and released >>> their own 3.4-rc2 based tree. >>> >>> Don't get me wrong: Its great to see them keeping up with mainline, but >>> I've clearly duplicated their work this cycle. >>> >>> I've gone ahead and mirrored the AOSP 3.4 tree here: >>> git://git.linaro.org/people/jstultz/android.git linaro-android-3.4 >> >> Are you going to add "merge_config.sh" into this branch? >> > merge_config.sh is in linaro-configs-3.4 on John's tree. The related > patches have also been part of topic/base. > I mean topic/base in Samsung's Landing team kernel. >>> >>> Andrey: Probably you're call on this. If you've already merged in my >>> rebase tree it should be fine for 12.04, but if not you might want to >>> jump over to the AOSP 3.4 tree. >>> >>> thanks >>> -john >>> >>> >>> ___ >>> 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 > > -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: About how to integrate android test into LAVA
| Put this email in a Wiki:
| https://wiki.linaro.org/Platform/Android/IntegrateATestIntoLava
Thank you for put it into a wiki, Zach!
The wiki is a good place.
Add in MANIFEST.in if there is a folder for the test case:
> include lava_android_test/test_definitions/${test_folder}/*
>
> Add an entry in doc/tests.rst and document if more:
> + * `${test_name}`_
>
> Spring, Thanks for your comments.
I have updated the wiki and the google doc.
Thanks
Yongqin Liu
> On 13 April 2012 06:10, Botao Sun wrote:
>
>> Amazing!
>>
>> I'm reading it...
>>
>>
>> BR
>> Botao Sun
>>
>>
>> On Fri, Apr 13, 2012 at 12:45 AM, Zach Pfeffer
>> wrote:
>>
>>> Awesome YongQin.
>>>
>>> On 12 April 2012 05:51, YongQin Liu wrote:
>>> > 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\w+)=(?P\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
Re: Linaro 12.04 3.4-rc1 based androidization branch is available
On 13 April 2012 12:01, Tushar Behera wrote: > On 04/13/2012 04:19 PM, Tushar Behera wrote: > > On 04/13/2012 02:48 PM, Sangwook Lee wrote: > >> Hi John > >> > >> On 11/04/12 20:19, John Stultz wrote: > >>> On 04/09/2012 03:18 PM, John Stultz wrote: > I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1. > > You can grab it here: > git://git.linaro.org/people/jstultz/android.git > linaro-android-3.4-jstultz-rebase > >>> > >>> Sigh. Looks like the Google devs are following close behind and > released > >>> their own 3.4-rc2 based tree. > >>> > >>> Don't get me wrong: Its great to see them keeping up with mainline, but > >>> I've clearly duplicated their work this cycle. > >>> > >>> I've gone ahead and mirrored the AOSP 3.4 tree here: > >>> git://git.linaro.org/people/jstultz/android.git linaro-android-3.4 > >> > >> Are you going to add "merge_config.sh" into this branch? > >> > > merge_config.sh is in linaro-configs-3.4 on John's tree. The related > > patches have also been part of topic/base. > > > > I mean topic/base in Samsung's Landing team kernel. > > Thanks for info. > >>> > >>> Andrey: Probably you're call on this. If you've already merged in my > >>> rebase tree it should be fine for 12.04, but if not you might want to > >>> jump over to the AOSP 3.4 tree. > >>> > >>> thanks > >>> -john > >>> > >>> > >>> ___ > >>> 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 > > > > > > > -- > Tushar Behera > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v2 2/2] regulator: da9052: add device tree support
From: "Ying-Chun Liu (PaulLiu)"
This patch adds device tree support for dialog regulators
Signed-off-by: Ying-Chun Liu (PaulLiu)
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Samuel Ortiz
Cc: Shawn Guo
Cc: Ashish Jangam
---
drivers/regulator/da9052-regulator.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/da9052-regulator.c
b/drivers/regulator/da9052-regulator.c
index b6c8c4b..2678cbe 100644
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -19,6 +19,9 @@
#include
#include
#include
+#ifdef CONFIG_OF
+#include
+#endif
#include
#include
@@ -425,8 +428,32 @@ static int __devinit da9052_regulator_probe(struct
platform_device *pdev)
}
config.dev = &pdev->dev;
- config.init_data = pdata->regulators[pdev->id];
config.driver_data = regulator;
+ if (pdata && pdata->regulators) {
+ config.init_data = pdata->regulators[pdev->id];
+ } else {
+#ifdef CONFIG_OF
+ struct device_node *nproot = da9052->dev->of_node;
+ struct device_node *np;
+
+ if (!nproot)
+ return -ENODEV;
+
+ nproot = of_find_node_by_name(nproot, "regulators");
+ if (!nproot)
+ return -ENODEV;
+
+ for (np = of_get_next_child(nproot, NULL); !np;
+np = of_get_next_child(nproot, np)) {
+ if (!of_node_cmp(np->name,
+regulator->info->reg_desc.name)) {
+ config.init_data = of_get_regulator_init_data(
+ &pdev->dev, np);
+ break;
+ }
+ }
+#endif
+ }
regulator->rdev = regulator_register(®ulator->info->reg_desc,
&config);
--
1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v2 1/2] mfd: da9052: add device-tree support for i2c driver
From: "Ying-Chun Liu (PaulLiu)"
This patch adds device-tree support for dialog MFD and the binding
documentations.
Signed-off-by: Ying-Chun Liu (PaulLiu)
Cc: Samuel Ortiz
Cc: Mark Brown
Cc: Shawn Guo
Cc: Ashish Jangam
---
.../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 000..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 = <50>;
+ regulator-max-microvolt = <2075000>;
+ };
+
+ buck1 {
+ regulator-name = "DA9052_BUCK_PRO";
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <2075000>;
+ };
+
+ buck2 {
+ regulator-name = "DA9052_BUCK_MEM";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <250>;
+ };
+
+ buck3 {
+ regulator-name = "DA9052_BUCK_PERI";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <250>;
+ };
+ };
+ };
+};
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
#include
+#ifdef CONFIG_OF
+#include
+#include
+#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)
Re: [RFC] Scheduler recorder and playback
Hi Dmitry, Yes, I know, the non-portability of perf.data is a big issue, and one of the design goals of spr-replay. The generated program by spr-replay is perfectly portable, but due to the way perf data format is, they are not. We can't do anything about perf.data, but the spr-replay program should be trivially portable. I'll switch on the mainline kernel tag and retry. Regards -- Pantelis On Apr 13, 2012, at 9:27 AM, Dmitry Antipov wrote: > 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Thermal release for this month.
Adding Guodong and Tushar to make sure that the LT trees also have thermal management turned on for 12.04. And cc'ing linaro-dev and the release manager. :) /Amit On Fri, Apr 13, 2012 at 4:47 PM, Amit Kachhap wrote: > Hi Andrey, > > Please pull the thermal management work for exynos4 and imx6 platforms > for this month release. > > git://git.linaro.org/people/amitdanielk/linux.git thermal_exynos4_imx6_work > > since commit id 258f742635360175564e9470eb060ff4d4b984e7 > > The necessary configs to be enabled are, > https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig#Thermal > > Thanks, > Amit Daniel ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/2] mfd: da9052: add device-tree support for i2c driver
On Fri, Apr 13, 2012 at 09:37:40PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> + regulators {
> + buck0 {
> + regulator-name = "DA9052_BUCK_CORE";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <2075000>;
> + };
This is more of a nit but these names look like they aren't terribly
idiomatic and could just be omitted - normally the name is used to tie
the name to the supply on the schematic so the above might be "VCORE" or
something. If no name is provided then whatever the driver provides
will be used.
signature.asc
Description: Digital signature
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/2] regulator: da9052: add device tree support
On Fri, Apr 13, 2012 at 09:37:41PM +0800, Ying-Chun Liu (PaulLiu) wrote: > From: "Ying-Chun Liu (PaulLiu)" > > This patch adds device tree support for dialog regulators Applied, thanks. It'd be good to correct the documentation in patch 1 but there should be no code dependency on the core changes so it seems safe for them to go in separately. signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] rtc: add support for Freescale SNVS RTC
(2012年03月22日 23:11), Shawn Guo wrote:
> On Mon, Mar 19, 2012 at 09:04:29PM +0800, Ying-Chun Liu (PaulLiu) wrote:
>> +
>> +#define RTC_READ_TIME_47BIT _IOR('p', 0x20, unsigned long long)
>> +/* blocks until LPSCMR is set, returns difference */
>> +#define RTC_WAIT_TIME_SET _IOR('p', 0x21, int64_t)
>> +
>
> What are these local ioctl number exactly for? How can user space
> use these driver private numbers?
>
>> +
>> +rtc_write_sync_lp(ioaddr);
>> +
>> +new_time_47bit = (((u64) (readl(ioaddr + SNVS_LPSRTCMR) &
>> +((0x1 << CNTR_TO_SECS_SH) - 1)) << 32) |
>> +((u64) readl(ioaddr + SNVS_LPSRTCLR)));
>> +
>> +time_diff = new_time_47bit - old_time_47bit;
>> +
>> +/* signal all waiting threads that time changed */
>> +complete_all(&snvs_completion);
>> +
>> +/* allow signalled threads to handle the time change notification */
>> +schedule();
>> +
>> +/* reinitialize completion variable */
>> +INIT_COMPLETION(snvs_completion);
>> +
>
> Are you sure all these sync need to get done in driver?
>
>> +return -EINVAL;
>> +}
>> +}
>> +
>> +spin_lock_irqsave(&rtc_lock, lock_flags);
>> +
>> +ret = rtc_update_alarm(dev, &alrm->time);
>> +if (ret)
>> +goto out;
>> +
>> +lp_cr = readl(ioaddr + SNVS_LPCR);
>> +
>> +if (alrm->enabled)
>> +lp_cr |= (SNVS_LPCR_LPTA_EN | SNVS_LPCR_LPWUI_EN);
>> +else
>> +lp_cr &= ~(SNVS_LPCR_LPTA_EN | SNVS_LPCR_LPWUI_EN);
>> +
>> +if (lp_cr & SNVS_LPCR_ALL_INT_EN) {
>> +if (!pdata->irq_enable) {
>> +enable_irq(pdata->irq);
>> +pdata->irq_enable = true;
>> +}
>> +} else {
>> +if (pdata->irq_enable) {
>> +disable_irq(pdata->irq);
>> +pdata->irq_enable = false;
>> +}
>> +}
>> +
>> +writel(lp_cr, ioaddr + SNVS_LPCR);
>> +
>> +out:
>> +rtc_write_sync_lp(ioaddr);
>> +spin_unlock_irqrestore(&rtc_lock, lock_flags);
>> +
>> +return ret;
>> +}
>> +
>> +/*!
>> + * This function is used to provide the content for the /proc/driver/rtc
>> + * file.
>> + *
>> + * @param seq buffer to hold the information that the driver wants to
>> write
>> + *
>> + * @return The number of bytes written into the rtc file.
>> + */
>> +static int snvs_rtc_proc(struct device *dev, struct seq_file *seq)
>> +{
>> +struct rtc_drv_data *pdata = dev_get_drvdata(dev);
>> +void __iomem *ioaddr = pdata->ioaddr;
>> +
>> +seq_printf(seq, "alarm_IRQ\t: %s\n",
>> + (((readl(ioaddr + SNVS_LPCR)) & SNVS_LPCR_LPTA_EN) !=
>> +0) ? "yes" : "no");
>> +
>> +return 0;
>> +}
>> +
>> +static int snvs_rtc_alarm_irq_enable(struct device *dev, unsigned int
>> enable)
>> +{
>> +struct rtc_drv_data *pdata = dev_get_drvdata(dev);
>> +void __iomem *ioaddr = pdata->ioaddr;
>> +u32 lp_cr;
>> +unsigned long lock_flags = 0;
>> +
>> +spin_lock_irqsave(&rtc_lock, lock_flags);
>> +
>> +if (enable) {
>> +if (!pdata->irq_enable) {
>> +enable_irq(pdata->irq);
>> +pdata->irq_enable = true;
>> +}
>> +lp_cr = readl(ioaddr + SNVS_LPCR);
>> +lp_cr |= (SNVS_LPCR_LPTA_EN | SNVS_LPCR_LPWUI_EN);
>> +writel(lp_cr, ioaddr + SNVS_LPCR);
>> +} else {
>> +lp_cr = readl(ioaddr + SNVS_LPCR);
>> +lp_cr &= ~(SNVS_LPCR_LPTA_EN | SNVS_LPCR_LPWUI_EN);
>> +if (((lp_cr & SNVS_LPCR_ALL_INT_EN) == 0)
>> +&& (pdata->irq_enable)) {
>> +disable_irq(pdata->irq);
>> +pdata->irq_enable = false;
>> +}
>> +writel(lp_cr, ioaddr + SNVS_LPCR);
>> +}
>> +
>> +rtc_write_sync_lp(ioaddr);
>> +spin_unlock_irqrestore(&rtc_lock, lock_flags);
>> +
>> +return 0;
>> +}
>> +
>> +/*!
>> + * This function is used to support some ioctl calls directly.
>> + * Other ioctl calls are supported indirectly through the
>> + * arm/common/rtctime.c file.
>> + *
>> + * @param cmd ioctl command as defined in include/linux/rtc.h
>> + * @param arg value for the ioctl command
>> + *
>> + * @return 0 if successful or negative value otherwise.
>> + */
>> +static int snvs_rtc_ioctl(struct device *dev, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> +struct rtc_drv_data *pdata = dev_get_drvdata(dev);
>> +void __iomem *ioaddr = pdata->ioaddr;
>> +u64 time_47bit;
>> +int retVal;
>> +
>> +switch (cmd) {
>> +case RTC_READ_TIME_47BIT:
>> +time_47bit = (((u64) (readl(ioaddr + SNVS_LPSRTCMR) &
>> +((0x1 << CNTR_TO_SECS_SH) - 1)) << 32) |
>> +((u64) readl(ioaddr + SNVS_LPSRTCLR)));
>> +
>> +if (arg && copy_to_user((u64 *) arg, &time_47bit, sizeof(u64)))
>> +return -EFAULT;
>> +
Re: Linaro 12.04 3.4-rc1 based androidization branch is available
On 04/13/2012 03:22 AM, Jon Medhurst (Tixy) wrote: Hi John When using the linaro-android-3.4 branch the mouse buttons don't seem to work. I've tracked the problem down to something you fixed in linaro-android-3.4-jstultz-rebase, namely: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commit;h=2d571b539f94918e416971d0d2a7584544906f2c Can you add this to linaro-android-3.4 and any other fixes you did that might be missing? Just re-added that one. Thanks for pointing it out, sorry for making you chase it down. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Thermal release for this month.
Greetings, On 04/13/2012 05:52 PM, Amit Kucheria wrote: Adding Guodong and Tushar to make sure that the LT trees also have thermal management turned on for 12.04. And cc'ing linaro-dev and the release manager. :) /Amit On Fri, Apr 13, 2012 at 4:47 PM, Amit Kachhap wrote: Hi Andrey, Please pull the thermal management work for exynos4 and imx6 platforms for this month release. git://git.linaro.org/people/amitdanielk/linux.git thermal_exynos4_imx6_work since commit id 258f742635360175564e9470eb060ff4d4b984e7 Amit (Kachhap), First of all, thank you for updating your code in linux-linaro! 1) The thermal_exynos4_imx6_work branch contains two commits on top of v3.4-rc2 which aren't related to thermal: - the "android, lowmemorykiller: remove task handoff notifier". If needed this commit should go into the android topic. This commit precedes the one I should start pulling from, so I will not include it into the linux-linaro. - commit 258f742635360175564e9470eb060ff4d4b984e7 "modpost: Fix modpost license checking of vmlinux.o" looks like an important fix, but the thermal topic is wrong place for it. This commit is present in mainline tip, so I'll cherry-pick it from there into a proper topic. 2) So the new thermal_exynos4_imx6_work obsoletes the old exynos_thermal_framework_V2 topic. You should mention that explicitly when asking to add the new one to linux-linaro! (I am also not very happy with one topic replacing another every month vs updating the existing topic. And it looks like your new topic could be made from the old one by rebasing onto more recent mainline tree, and adding new commits) Tushar, I am going to drop your thermal_v2 topic as it is a copy of exynos_thermal_framework_V2 plus defconfig update. The former will be replaced by the thermal_exynos4_imx6_work topic, and I would add the config fragment to this topic to add the required options to exynos4_defconfig. Thanks, Andrey The necessary configs to be enabled are, https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig#Thermal Thanks, Amit Daniel ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 00/13] common clk framework misc fixes
On Fri, Apr 13, 2012 at 2:21 AM, Mark Brown wrote: > On Wed, Apr 11, 2012 at 06:02:38PM -0700, Mike Turquette wrote: >> This series collects many of the fixes posted for the recently merged >> common clock framework as well as some general clean-up. Most of the >> code classifies as a clean-up moreso than a bug fix; hopefully this is >> not a problem since the common clk framework is new code pulled for 3.4. > > Can you please CC people on your cover letters as well as on the > individual patches? Yes. Regards, Mike ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 01/13] clk: core: correct clk_set_rate kerneldoc
On Wed, Apr 11, 2012 at 9:28 PM, Viresh Kumar wrote: > On 4/12/2012 6:32 AM, Mike Turquette wrote: >> - * If clk has the CLK_SET_RATE_GATE flag set and it is enabled this call >> - * will fail; only when the clk is disabled will it be able to change >> - * its rate. > > Why is CLK_SET_RATE_GATE removed? I already sent a patch to fix clk_set_rate() > for this. And i think it should be required. I removed it from the documentation since it was not present in the code. I was originally targeting this for an -rc and I was trying to limit the changes purely to fixes and cleanups, not new features. I haven't finished digging through all of the responses yet, so my goal for where these patches are headed might change. Regards, Mike ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 02/13] clk: core: remove dead code paths
On Wed, Apr 11, 2012 at 11:14 PM, Viresh Kumar wrote:
> On 4/12/2012 6:32 AM, Mike Turquette wrote:
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 3ed36d3..4daacf5 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -194,7 +194,7 @@ static int __init clk_debug_init(void)
>> late_initcall(clk_debug_init);
>> #else
>> static inline int clk_debug_register(struct clk *clk) { return 0; }
>> -#endif /* CONFIG_COMMON_CLK_DEBUG */
>> +#endif
>
> Why is this updated? Isn't this considered good practice anymore?
See comments in this thread:
http://article.gmane.org/gmane.linux.kernel/1276102
Regards,
Mike
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Thermal release for this month.
On Sat, Apr 14, 2012 at 01:02:59AM +0400, Andrey Konovalov wrote: > 2) So the new thermal_exynos4_imx6_work obsoletes the old > exynos_thermal_framework_V2 topic. You should mention that > explicitly when asking to add the new one to linux-linaro! I was a bit surprised at something related to this as well -- the new Exynos4 thermal patchset actually includes the generic cpu cooling patchset instead of keeping it separate. I realized later this was added because the maintainer suggested including a user of the generic code to demonstrate its usefulness, so it seems fine to me, though it might have been easier to understand if you had maintained the original subject "Add generic cpu cooling devices" and just expanded the patchset by including the Exynos4 implementation at the end. At any range, Andrey's comment is right -- you need to let him know when you're merging or splitting patchsets/topics or it'll be hard for him to keep track of them. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
