Re: Thermal release for this month.
On 04/13/2012 07:22 PM, Amit Kucheria wrote: > Adding Guodong and Tushar to make sure that the LT trees also have > thermal management turned on for 12.04. > In Samsung LT kernel, we have included thermal_v2 patchset from Amit. > 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. >> As for merging various topic branches to linux-linaro-tracking, I would expect that the individual branches also enable relevant defconfig options. I don't see any better way to enable a specific feature in linux-linaro-tracking. >> 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 -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 三, 2012-04-11 at 18:17 +0530, Amit Kachhap wrote:
> Hi Rui,
>
> Thanks for looking into the patches.
>
> On 10 April 2012 06:28, Zhang Rui wrote:
> > Hi, Amit,
> >
> > On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
> >> Hi Len/Rui,
> >>
> >> Any comment or feedback from your side about the status of this patch?
> >> Is it merge-able or major re-work is needed? I have fixed most of the
> >> comments in this patchset and currently working on some of the minor
> >> comments received and will submit them shortly.
> >>
> > Sorry for the late response.
> >
> > First of all, it makes sense to me to introduce the generic cpufrq
> > cooling implementation.
> ok thanks
> > But I still have some questions.
> > I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
> > that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
> > current passive handling in the generic thermal layer well, right?
> > e.g. there is no tc1/tc2 on exynos4.
> >
> > If yes, is it possible that we can enhance the passive cooling to
> > support the generic processor cooling?
> > say, introduce another way to throttle the processor in
> > thermal_zone_device_passive when tc1 and tc2 are not available?
>
> I agree that this new trip type code can be moved into passive trip
> type when tc1 and tc2 are 0. but this is special type of cooling
> devices behaviour where only instances of the same cooling device is
> binded to a trip point. The order of mapping is the only
> differentiating criteria and there are some checks used to implement
> this like
> 1) The trip points should be in ascending order.(This is missing in my
> original patch, so I added below)
> 2) The set_cur_state has to be called for the exact temp range so
> get_cur_state(&state) and set_cur_state(state ++/state--) logic is not
> possible.
> 3) set_cur_state is called as set_cur_state(cdev_instance).
Do you really need two THERMAL_TRIP_STATE_INSTANCE trip points?
I'm not sure if my understanding is right, but IMO, we can have one
THERMAL_TRIP_STATE_INSTANCE only, for both MONIROR_ZONE and WARN_ZONE,
and the trip temperature equals MONIROR_ZONE.
The cpufreq cooling device will work in the same way, no?
thanks,
rui
> There is a chance that people might confuse that these checks are
> applicable for passive trip types also which is not the case here.
>
> @@ -1187,6 +1228,21 @@ struct thermal_zone_device
> *thermal_zone_device_register(char *type,
> tz->ops->get_trip_type(tz, count, &trip_type);
> if (trip_type == THERMAL_TRIP_PASSIVE)
> passive = 1;
> + /*
> +* For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
> +* be in ascending order.
> + */
> + if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
> + tz->ops->get_trip_temp(tz, count, &trip_temp);
> + if (first_trip_temp == 0)
> + first_trip_temp = trip_temp;
> + else if (first_trip_temp < trip_temp)
> + first_trip_temp = trip_temp;
> + else if (first_trip_temp > trip_temp) {
> + pr_warn("Zone trip points should be in
> ascending order\n");
> + goto unregister;
> + }
> + }
> }
>
> if (!passive)
>
> Anyway there is other alternative where this new trip type is not
> needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
> and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
> I had thought to make this generic and just to manage with 1 cooling
> device.
> What is your view?
>
> Thanks,
> Amit Daniel
>
>
> >
> > thanks,
> > rui
> >
> >> Regards,
> >> Amit Daniel
> >>
> >> On 19 March 2012 11:47, Amit Daniel Kachhap
> >> wrote:
> >> > Changes since V1:
> >> > *Moved the sensor driver to driver/thermal folder from driver/hwmon
> >> > folder
> >> > as suggested by Mark Brown and Guenter Roeck
> >> > *Added notifier support to notify the registered drivers of any cpu
> >> > cooling
> >> > action. The driver can modify the default cooling behaviour(eg set
> >> > different
> >> > max clip frequency).
> >> > *The percentage based frequency replaced with absolute clipped frequency.
> >> > *Some more conditional checks when setting max frequency.
> >> > *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
> >> > THERMAL_TRIP_STATE_INSTANCE
> >> > *Many review comments from R, Durgadoss and
> >> > eduardo.valen...@ti.com implemented.
> >> > *Removed cooling stats through debugfs patch
> >> > *The V1 based can be found here,
> >> > https://lkml.org/lkml/2012/2/22/123
> >> > http://lkml.org/lkml/2012/3/3/32
> >> >
> >> > Changes since RFC:
> >> > *Changed the cpu cooling registration/unregistration API's to instance
> >> > based
> >> > *Changed the STATE_ACTIVE
Re: [PATCH v2] rtc: add support for Freescale SNVS RTC
On Sat, 14 Apr 2012 15:07:17 +0800
"Ying-Chun Liu (PaulLiu)" wrote:
> atic 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;
> +}
> +
Please consider removing this unless truly necessary.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: error occurring in qemu-linaro revisions pulled since March 30th
On 12 April 2012 16:22, Russell Keith Davis wrote: > The only thing that changed in my setup, Virtualbox, scratchbox2, arm debian > rootfs & qemu-linaro is that i pulled a newer version than march 30th and i > went from some expected errors http://pastebin.com/QTt8S9kT to > http://pastebin.com/2SRJRvdp For the record, this is fixed by the following patch: http://patchwork.ozlabs.org/patch/152614/ which will go into qemu-linaro 2012.05. Thanks for reporting this bug. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v4] 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 | 60
drivers/mfd/da9052-i2c.c | 50 +---
2 files changed, 102 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..1857f4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
@@ -0,0 +1,60 @@
+* 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-min-microvolt = <50>;
+ regulator-max-microvolt = <2075000>;
+ };
+
+ buck1 {
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <2075000>;
+ };
+
+ buck2 {
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <250>;
+ };
+
+ buck3 {
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <250>;
+ };
+ };
+ };
+};
diff --git a/drivers/mfd/da9052-i2c.c b/drivers/mfd/da9052-i2c.c
index 36b88e3..d8abdb3 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,22 @@ static int __devinit da9052_i2c_probe(struct i2c_client
*client,
if (ret < 0)
goto err_regmap;
+#ifdef CONFIG_OF
+ if (!id) {
+ 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 +139,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,
