- linaro-kernel - lists.linaro.org

Re: [PATCH v3 3/3] hwmon: add ST-Ericsson ABX500 hwmon driver

by Hongbo Zhang

Guenter, Thanks for you thorough review very much, will adopt all your comments. On 27 February 2013 13:56, Guenter Roeck <linux(a)roeck-us.net> wrote: > On Thu, Feb 21, 2013 at 06:32:41PM +0800, Hongbo Zhang wrote: >> Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500 >> chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for >> all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this designed >> structure, other chip specific files can be added simply using the same common >> layer abx500.c. >> >> Signed-off-by: Hongbo Zhang <hongbo.zhang(a)linaro.org> >> --- >> Documentation/hwmon/ab8500 | 22 ++ >> Documentation/hwmon/abx500 | 26 +++ >> drivers/hwmon/Kconfig | 13 ++ >> drivers/hwmon/Makefile | 1 + >> drivers/hwmon/ab8500.c | 178 ++++++++++++++++ >> drivers/hwmon/abx500.c | 501 +++++++++++++++++++++++++++++++++++++++++++++ >> drivers/hwmon/abx500.h | 87 ++++++++ >> 7 files changed, 828 insertions(+) >> create mode 100644 Documentation/hwmon/ab8500 >> create mode 100644 Documentation/hwmon/abx500 >> create mode 100644 drivers/hwmon/ab8500.c >> create mode 100644 drivers/hwmon/abx500.c >> create mode 100644 drivers/hwmon/abx500.h >> >> diff --git a/Documentation/hwmon/ab8500 b/Documentation/hwmon/ab8500 >> new file mode 100644 >> index 0000000..76c534d >> --- /dev/null >> +++ b/Documentation/hwmon/ab8500 >> @@ -0,0 +1,22 @@ >> +Kernel driver ab8500 >> +==================== >> + >> +Supported chips: >> + * ST-Ericsson AB8500 >> + Prefix: 'ab8500' >> + Addresses scanned: - >> + Datasheet: http://www.stericsson.com/developers/documentation.jsp >> + >> +Authors: >> + Martin Persson <martin.persson(a)stericsson.com> >> + Hongbo Zhang <hongbo.zhang(a)linaro.org> >> + >> +Description >> +----------- >> + >> +See also Documentation/hwmon/abx500. This is ST-Ericsson AB8500 hwmon specific >> +initialization. >> + > "This is the ST-Ericsson AB8500 specific driver" or similar might be better. > >> +Currently only the AB8500 internal sensor and one external sensor for battery >> +temperature are monitored. Other GPADC channels can also be monitored if needed >> +in future. >> diff --git a/Documentation/hwmon/abx500 b/Documentation/hwmon/abx500 >> new file mode 100644 >> index 0000000..f60b73c >> --- /dev/null >> +++ b/Documentation/hwmon/abx500 >> @@ -0,0 +1,26 @@ >> +Kernel driver abx500 >> +==================== >> + >> +Supported chips: >> + * ST-Ericsson ABx500 series >> + Prefix: 'abx500' >> + Addresses scanned: - >> + Datasheet: http://www.stericsson.com/developers/documentation.jsp >> + >> +Authors: >> + Martin Persson <martin.persson(a)stericsson.com> >> + Hongbo Zhang <hongbo.zhang(a)linaro.org> >> + >> +Description >> +----------- >> + >> +Every ST-Ericsson Ux500 SOC consists of both ABx500 and DBx500 physically, >> +this is kernel hwmon driver for ABx500. >> + >> +There are some GPADCs inside ABx500 which are designed for connecting to >> +thermal sensors, and there is also a thermal sensor inside ABx500 too, which >> +raises interrupt when critical temperature reached. >> + >> +This abx500 is a common layer which can monitor all of the sensors, every >> +specific abx500 chip has its special configurations in its own file, e.g. some >> +sensors can be configured invisible if they are not available on that chip. > > Given that limits are disabled if set to 0, you really should document that > here. > >> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig >> index 32f238f..0a6fd21 100644 >> --- a/drivers/hwmon/Kconfig >> +++ b/drivers/hwmon/Kconfig >> @@ -39,6 +39,19 @@ config HWMON_DEBUG_CHIP >> >> comment "Native drivers" >> >> +config SENSORS_AB8500 >> + tristate "AB8500 thermal monitoring" >> + depends on AB8500_GPADC >> + default n >> + help >> + If you say yes here you get support for the thermal sensor part >> + of the AB8500 chip. The driver includes thermal management for >> + AB8500 die and two GPADC channels. The GPADC channel are preferably >> + used to access sensors outside the AB8500 chip. >> + >> + This driver can also be built as a module. If so, the module >> + will be called abx500-temp. >> + >> config SENSORS_ABITUGURU >> tristate "Abit uGuru (rev 1 & 2)" >> depends on X86 && DMI >> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile >> index 5da2874..06dfe85 100644 >> --- a/drivers/hwmon/Makefile >> +++ b/drivers/hwmon/Makefile >> @@ -19,6 +19,7 @@ obj-$(CONFIG_SENSORS_W83795) += w83795.o >> obj-$(CONFIG_SENSORS_W83781D) += w83781d.o >> obj-$(CONFIG_SENSORS_W83791D) += w83791d.o >> >> +obj-$(CONFIG_SENSORS_AB8500) += abx500.o ab8500.o >> obj-$(CONFIG_SENSORS_ABITUGURU) += abituguru.o >> obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o >> obj-$(CONFIG_SENSORS_AD7314) += ad7314.o >> diff --git a/drivers/hwmon/ab8500.c b/drivers/hwmon/ab8500.c >> new file mode 100644 >> index 0000000..33221e7 >> --- /dev/null >> +++ b/drivers/hwmon/ab8500.c >> @@ -0,0 +1,178 @@ >> +/* >> + * Copyright (C) ST-Ericsson SA 2010 > > 2010 - 1013 ? > >> + * Author: Martin Persson <martin.persson(a)stericsson.com> >> + * Hongbo Zhang <hongbo.zhang(a)linaro.org> >> + * License Terms: GNU General Public License v2 >> + * >> + * If/when the AB8500 thermal warning temperature is reached (threshold cannot >> + * be changed by SW), an interrupt is set and the driver notifies user space >> + * via a sysfs event. If a shut down is not triggered by user space within a >> + * certain time frame, pm_power off is called. >> + * >> + * If/when AB8500 thermal shutdown temperature is reached a hardware shutdown >> + * of the AB8500 will occur. >> + */ >> + >> +#include <linux/err.h> >> +#include <linux/hwmon.h> >> +#include <linux/hwmon-sysfs.h> >> +#include <linux/mfd/abx500.h> >> +#include <linux/mfd/abx500/ab8500-bm.h> >> +#include <linux/mfd/abx500/ab8500-gpadc.h> >> +#include <linux/module.h> >> +#include <linux/platform_device.h> >> +#include <linux/slab.h> >> +#include <linux/sysfs.h> >> +#include "abx500.h" >> + >> +#define DEFAULT_POWER_OFF_DELAY 10000 > > I notice you define all delays in ms just to convert them to jiffies, yet the > delays are hardly ever reported to the user anywhere. I think it would make > more sense to just define the delays in HZ, use them directly, and use > msecs_to_jiffies() in the one case where a delay reported to the user. > This would have the added benefit that (HZ * 10) is easier to understand > than an unexplained 10000 when reading the code. > >> +#define NUM_MONITORED_SENSORS 4 >> +#define THERMAL_VCC 1800 >> +#define PULL_UP_RESISTOR 47000 >> + >> +/* >> + * The hardware connection is like this: >> + * VCC----[ R_up ]-----[ NTC ]----GND >> + * where R_up is pull-up resistance, and GPADC measures voltage on NTC. >> + * and res_to_temp table is strictly sorted by falling resistance values. >> + */ >> +static int voltage_to_temp(int vcc, int r_up, int v_ntc, >> + const struct abx500_res_to_temp *tbl, int tbl_sz, int *temp) >> +{ >> + int r_ntc, i = 0; >> + >> + if (vcc < 0 || v_ntc > vcc) > > Should be 'v_ntc >= vcc' to avoid the == case and resulting division by zero. > >> + return -EINVAL; >> + >> + r_ntc = v_ntc * r_up / (vcc - v_ntc); >> + if (r_ntc > tbl[0].resist || r_ntc < tbl[tbl_sz - 1].resist) >> + return -EINVAL; >> + >> + while (!(r_ntc <= tbl[i].resist && r_ntc > tbl[i + 1].resist) >> + && i < tbl_sz - 2) >> + i++; >> + >> + *temp = tbl[i].temp + ((tbl[i + 1].temp - tbl[i].temp) * >> + (r_ntc - tbl[i].resist)) / (tbl[i + 1].resist - tbl[i].resist); >> + >> + return 0; >> +} >> + >> +static int ab8500_read_sensor(struct abx500_temp *data, u8 sensor) >> +{ >> + int temp, voltage, ret; >> + >> + if (sensor == BAT_CTRL) >> + temp = ab8500_btemp_get_batctrl_temp(data->ab8500_btemp); > > That can return a valid number below zero unless I am missing something > (BTEMP_THERMAL_LOW_LIMIT is -10). Which means you can not return the error > and the return value and need to use a pointer for the return value after all. > >> + >> + else if (sensor == BTEMP_BALL) >> + temp = ab8500_btemp_get_temp(data->ab8500_btemp); > > Same here. > >> + >> + else { >> + voltage = ab8500_gpadc_convert(data->ab8500_gpadc, sensor); >> + if (voltage < 0) >> + return -EINVAL; > > return voltage; >> + >> + ret = voltage_to_temp(THERMAL_VCC, PULL_UP_RESISTOR, voltage, >> + temp_tbl_A_thermistor, temp_tbl_A_size, &temp); > > This can also return a negative temperature (the first temperature entry in > temp_tbl_A_thermistor is negative). > >> + if (ret < 0) >> + return -EINVAL; > > return ret; > >> + temp *= 1000; >> + } >> + >> + return temp; >> +} >> + >> +static void ab8500_thermal_power_off(struct work_struct *work) >> +{ >> + struct abx500_temp *data = container_of(work, struct abx500_temp, >> + power_off_work.work); >> + >> + dev_warn(&data->pdev->dev, >> + "Power off due to AB8500 thermal warning.\n"); >> + pm_power_off(); >> +} >> + >> +static ssize_t ab8500_show_name(struct device *dev, >> + struct device_attribute *devattr, >> + char *buf) >> +{ >> + return sprintf(buf, "ab8500\n"); >> +} >> + >> +static ssize_t ab8500_show_label(struct device *dev, >> + struct device_attribute *devattr, >> + char *buf) >> +{ >> + char *name; > > Nitpick: label, really. > >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + int index = attr->index; >> + >> + switch (index) { >> + case 1: >> + name = "ext_adc1"; >> + break; >> + case 2: >> + name = "ext_adc2"; >> + break; >> + case 3: >> + name = "bat_temp"; >> + break; >> + case 4: >> + name = "bat_ctrl"; >> + break; >> + default: >> + return -EINVAL; >> + } >> + return sprintf(buf, "%s\n", name); >> +} >> + >> +static int ab8500_is_visible(struct attribute *attr, int n) >> +{ >> + return attr->mode; >> +} > > Instead of providing an empty function, you should make is_visible optional > and have the calling code return attr->mode directly if it is not defined > (ie NULL). > >> + >> +static int ab8500_temp_irq_handler(int irq, struct abx500_temp *data) >> +{ >> + unsigned long delay_in_jiffies; >> + >> + dev_info(&data->pdev->dev, "AB8500 warning, power off in %lu s\n", >> + data->power_off_delay); >> + > dev_warn, and "AB8500 warning" is redundant. > >> + delay_in_jiffies = msecs_to_jiffies(data->power_off_delay); >> + schedule_delayed_work(&data->power_off_work, delay_in_jiffies); >> + return 0; >> +} >> + >> +int abx500_hwmon_init(struct abx500_temp *data) >> +{ >> + data->ab8500_gpadc = ab8500_gpadc_get("ab8500-gpadc.0"); >> + if (IS_ERR(data->ab8500_gpadc)) >> + return PTR_ERR(data->ab8500_gpadc); >> + >> + data->ab8500_btemp = ab8500_btemp_get(); >> + if (IS_ERR(data->ab8500_btemp)) >> + return PTR_ERR(data->ab8500_btemp); >> + >> + INIT_DELAYED_WORK(&data->power_off_work, ab8500_thermal_power_off); >> + >> + /* >> + * ADC_AUX1 and ADC_AUX2, connected to external NTC >> + * BTEMP_BALL and BAT_CTRL, fixed usage >> + */ >> + data->gpadc_addr[0] = ADC_AUX1; >> + data->gpadc_addr[1] = ADC_AUX2; >> + data->gpadc_addr[2] = BTEMP_BALL; >> + data->gpadc_addr[3] = BAT_CTRL; >> + >> + data->power_off_delay = DEFAULT_POWER_OFF_DELAY; >> + data->monitored_sensors = NUM_MONITORED_SENSORS; >> + >> + data->ops.read_sensor = ab8500_read_sensor; >> + data->ops.irq_handler = ab8500_temp_irq_handler; >> + data->ops.show_name = ab8500_show_name; >> + data->ops.show_label = ab8500_show_label; >> + data->ops.is_visible = ab8500_is_visible; >> + >> + return 0; >> +} >> diff --git a/drivers/hwmon/abx500.c b/drivers/hwmon/abx500.c >> new file mode 100644 >> index 0000000..69ea8cb >> --- /dev/null >> +++ b/drivers/hwmon/abx500.c >> @@ -0,0 +1,501 @@ >> +/* >> + * Copyright (C) ST-Ericsson SA 2010 > > 2010 - 1023 ? > >> + * Author: Martin Persson <martin.persson(a)stericsson.com> >> + * Hongbo Zhang <hongbo.zhang(a)linaro.org> >> + * License Terms: GNU General Public License v2 >> + * >> + * ABX500 does not provide auto ADC, so to monitor the required temperatures, >> + * a periodic work is used. It is more important to not wake up the CPU than >> + * to perform this job, hence the use of a deferred delay. >> + * >> + * A deferred delay for thermal monitor is considered safe because: >> + * If the chip gets too hot during a sleep state it's most likely due to >> + * external factors, such as the surrounding temperature. I.e. no SW decisions >> + * will make any difference. >> + * >> + * If/when the ABX500 thermal warning temperature is reached (threshold cannot >> + * be changed by SW), an interrupt is set and the driver notifies user space >> + * via a sysfs event. >> + * >> + * If/when ABX500 thermal shutdown temperature is reached a hardware shutdown >> + * of the ABX500 will occur. >> + */ >> + >> +#include <linux/err.h> >> +#include <linux/hwmon.h> >> +#include <linux/hwmon-sysfs.h> >> +#include <linux/interrupt.h> >> +#include <linux/jiffies.h> >> +#include <linux/module.h> >> +#include <linux/mutex.h> >> +#include <linux/of.h> >> +#include <linux/platform_device.h> >> +#include <linux/pm.h> >> +#include <linux/slab.h> >> +#include <linux/sysfs.h> >> +#include <linux/workqueue.h> >> +#include "abx500.h" >> + >> +#define DEFAULT_MONITOR_DELAY 1000 >> + >> +static inline void schedule_monitor(struct abx500_temp *data) >> +{ >> + unsigned long delay_in_jiffies; >> + delay_in_jiffies = msecs_to_jiffies(data->gpadc_monitor_delay); >> + data->work_active = true; >> + schedule_delayed_work(&data->work, delay_in_jiffies); >> +} >> + >> +static void threshold_updated(struct abx500_temp *data) >> +{ >> + int i; >> + for (i = 0; i < data->monitored_sensors; i++) >> + if (data->max[i] != 0 || data->min[i] != 0) { >> + schedule_monitor(data); >> + return ; > > Extra ' ' before ; > >> + } >> + >> + dev_dbg(&data->pdev->dev, "No active thresholds.\n"); >> + cancel_delayed_work_sync(&data->work); >> + data->work_active = false; >> +} >> + >> +static void gpadc_monitor(struct work_struct *work) >> +{ >> + int val, i, ret; >> + char alarm_node[30]; >> + bool updated_min_alarm = false; >> + bool updated_max_alarm = false; >> + struct abx500_temp *data = container_of(work, struct abx500_temp, >> + work.work); >> + >> + mutex_lock(&data->lock); >> + for (i = 0; i < data->monitored_sensors; i++) { >> + /* Thresholds are considered inactive if set to 0 */ >> + if (data->max[i] == 0 && data->min[i] == 0) >> + continue; >> + /* >> + * In case we are in the temporary state that one threshold >> + * has been changed, but the other hasn't yet. >> + */ >> + if (data->max[i] < data->min[i]) >> + continue; >> + >> + val = data->ops.read_sensor(data, data->gpadc_addr[i]); >> + if (val < 0) { >> + dev_err(&data->pdev->dev, "GPADC read failed\n"); >> + continue; >> + } >> + >> + if (data->min[i] != 0) { >> + if (val < data->min[i]) { >> + if (data->min_alarm[i] == false) { >> + data->min_alarm[i] = true; >> + updated_min_alarm = true; >> + } >> + } else { >> + if (data->min_alarm[i] == true) { >> + data->min_alarm[i] = false; >> + updated_min_alarm = true; >> + } >> + } >> + > Unnecessary empty line. > >> + } >> + if (data->max[i] != 0) { >> + if (val > data->max[i]) { >> + if (data->max_alarm[i] == false) { >> + data->max_alarm[i] = true; >> + updated_max_alarm = true; >> + } >> + } else if (val < data->max[i] - data->max_hyst[i]) { >> + if (data->max_alarm[i] == true) { >> + data->max_alarm[i] = false; >> + updated_max_alarm = true; >> + } >> + } >> + } >> + >> + if (updated_min_alarm) { >> + ret = sprintf(alarm_node, "temp%d_min_alarm", i); >> + sysfs_notify(&data->pdev->dev.kobj, NULL, alarm_node); >> + } >> + if (updated_max_alarm) { >> + ret = sprintf(alarm_node, "temp%d_max_alarm", i); >> + sysfs_notify(&data->pdev->dev.kobj, NULL, alarm_node); >> + } >> + >> + updated_min_alarm = false; >> + updated_max_alarm = false; >> + } >> + >> + schedule_monitor(data); >> + mutex_unlock(&data->lock); >> +} >> + >> +/* HWMON sysfs interfaces */ >> +static ssize_t show_name(struct device *dev, struct device_attribute *devattr, >> + char *buf) >> +{ >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + /* Show chip name */ >> + return data->ops.show_name(dev, devattr, buf); >> +} >> + >> +static ssize_t show_label(struct device *dev, >> + struct device_attribute *devattr, char *buf) >> +{ >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + /* Show each sensor label */ >> + return data->ops.show_label(dev, devattr, buf); >> +} >> + >> +static ssize_t show_input(struct device *dev, >> + struct device_attribute *devattr, char *buf) >> +{ >> + int val; >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + u8 gpadc_addr = data->gpadc_addr[attr->index]; >> + >> + val = data->ops.read_sensor(data, gpadc_addr); >> + if (val < 0) >> + dev_err(&data->pdev->dev, "GPADC read failed\n"); >> + >> + return sprintf(buf, "%d\n", val); >> +} >> + >> +/* Set functions (RW nodes) */ >> +static ssize_t set_min(struct device *dev, struct device_attribute *devattr, >> + const char *buf, size_t count) >> +{ >> + unsigned long val; >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + int res = kstrtoul(buf, 10, &val); >> + if (res < 0) >> + return res; >> + > > You should use kstrtol, and use clamp_val() to limit the range. We don't expect > users to know the valid limits for this chip, and furthermore the limit could be > the result of a calculation. > > Sure you want to accept arbitrary upper limits ? 1,000,000 degrees C ? > OK, learned, thanks. >> + mutex_lock(&data->lock); >> + data->min[attr->index] = val; >> + threshold_updated(data); >> + mutex_unlock(&data->lock); >> + >> + return count; >> +} >> + >> +static ssize_t set_max(struct device *dev, struct device_attribute *devattr, >> + const char *buf, size_t count) >> +{ >> + unsigned long val; >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + int res = kstrtoul(buf, 10, &val); > > Same as above. > >> + if (res < 0) >> + return res; >> + >> + mutex_lock(&data->lock); >> + data->max[attr->index] = val; >> + threshold_updated(data); >> + mutex_unlock(&data->lock); >> + >> + return count; >> +} >> + >> +static ssize_t set_max_hyst(struct device *dev, >> + struct device_attribute *devattr, >> + const char *buf, size_t count) >> +{ >> + unsigned long val; >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + int res = kstrtoul(buf, 10, &val); >> + if (res < 0) >> + return res; >> + >> + mutex_lock(&data->lock); >> + data->max_hyst[attr->index] = val; >> + threshold_updated(data); >> + mutex_unlock(&data->lock); >> + >> + return count; >> +} >> + >> +/* Show functions (RO nodes) */ >> +static ssize_t show_min(struct device *dev, >> + struct device_attribute *devattr, char *buf) >> +{ >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + >> + return sprintf(buf, "%ld\n", data->min[attr->index]); >> +} >> + >> +static ssize_t show_max(struct device *dev, >> + struct device_attribute *devattr, char *buf) >> +{ >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + >> + return sprintf(buf, "%ld\n", data->max[attr->index]); >> +} >> + >> +static ssize_t show_max_hyst(struct device *dev, >> + struct device_attribute *devattr, char *buf) >> +{ >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + >> + return sprintf(buf, "%ld\n", data->max_hyst[attr->index]); >> +} >> + >> +static ssize_t show_min_alarm(struct device *dev, >> + struct device_attribute *devattr, char *buf) >> +{ >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + >> + return sprintf(buf, "%d\n", data->min_alarm[attr->index]); >> +} >> + >> +static ssize_t show_max_alarm(struct device *dev, >> + struct device_attribute *devattr, char *buf) >> +{ >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); >> + >> + return sprintf(buf, "%d\n", data->max_alarm[attr->index]); >> +} >> + >> +static mode_t abx500_attrs_visible(struct kobject *kobj, >> + struct attribute *a, int n) >> +{ >> + struct device *dev = container_of(kobj, struct device, kobj); >> + struct abx500_temp *data = dev_get_drvdata(dev); >> + >> + return data->ops.is_visible(a, n); >> +} >> + >> +/* Chip name, required by hwmon */ >> +static SENSOR_DEVICE_ATTR(name, S_IRUGO, show_name, NULL, 0); >> + >> +/* GPADC - SENSOR1 */ >> +static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL, 0); >> +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_input, NULL, 0); >> +static SENSOR_DEVICE_ATTR(temp1_min, S_IWUSR | S_IRUGO, show_min, set_min, 0); >> +static SENSOR_DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO, show_max, set_max, 0); >> +static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IWUSR | S_IRUGO, >> + show_max_hyst, set_max_hyst, 0); >> +static SENSOR_DEVICE_ATTR(temp1_min_alarm, S_IRUGO, show_min_alarm, NULL, 0); >> +static SENSOR_DEVICE_ATTR(temp1_max_alarm, S_IRUGO, show_max_alarm, NULL, 0); >> + >> +/* GPADC - SENSOR2 */ >> +static SENSOR_DEVICE_ATTR(temp2_label, S_IRUGO, show_label, NULL, 1); >> +static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_input, NULL, 1); >> +static SENSOR_DEVICE_ATTR(temp2_min, S_IWUSR | S_IRUGO, show_min, set_min, 1); >> +static SENSOR_DEVICE_ATTR(temp2_max, S_IWUSR | S_IRUGO, show_max, set_max, 1); >> +static SENSOR_DEVICE_ATTR(temp2_max_hyst, S_IWUSR | S_IRUGO, >> + show_max_hyst, set_max_hyst, 1); >> +static SENSOR_DEVICE_ATTR(temp2_min_alarm, S_IRUGO, show_min_alarm, NULL, 1); >> +static SENSOR_DEVICE_ATTR(temp2_max_alarm, S_IRUGO, show_max_alarm, NULL, 1); >> + >> +/* GPADC - SENSOR3 */ >> +static SENSOR_DEVICE_ATTR(temp3_label, S_IRUGO, show_label, NULL, 2); >> +static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, show_input, NULL, 2); >> +static SENSOR_DEVICE_ATTR(temp3_min, S_IWUSR | S_IRUGO, show_min, set_min, 2); >> +static SENSOR_DEVICE_ATTR(temp3_max, S_IWUSR | S_IRUGO, show_max, set_max, 2); >> +static SENSOR_DEVICE_ATTR(temp3_max_hyst, S_IWUSR | S_IRUGO, >> + show_max_hyst, set_max_hyst, 2); >> +static SENSOR_DEVICE_ATTR(temp3_min_alarm, S_IRUGO, show_min_alarm, NULL, 2); >> +static SENSOR_DEVICE_ATTR(temp3_max_alarm, S_IRUGO, show_max_alarm, NULL, 2); >> + >> +/* GPADC - SENSOR4 */ >> +static SENSOR_DEVICE_ATTR(temp4_label, S_IRUGO, show_label, NULL, 3); >> +static SENSOR_DEVICE_ATTR(temp4_input, S_IRUGO, show_input, NULL, 3); >> +static SENSOR_DEVICE_ATTR(temp4_min, S_IWUSR | S_IRUGO, show_min, set_min, 3); >> +static SENSOR_DEVICE_ATTR(temp4_max, S_IWUSR | S_IRUGO, show_max, set_max, 3); >> +static SENSOR_DEVICE_ATTR(temp4_max_hyst, S_IWUSR | S_IRUGO, >> + show_max_hyst, set_max_hyst, 3); >> +static SENSOR_DEVICE_ATTR(temp4_min_alarm, S_IRUGO, show_min_alarm, NULL, 3); >> +static SENSOR_DEVICE_ATTR(temp4_max_alarm, S_IRUGO, show_max_alarm, NULL, 3); >> + >> +struct attribute *abx500_temp_attributes[] = { >> + &sensor_dev_attr_name.dev_attr.attr, >> + >> + &sensor_dev_attr_temp1_label.dev_attr.attr, >> + &sensor_dev_attr_temp1_input.dev_attr.attr, >> + &sensor_dev_attr_temp1_min.dev_attr.attr, >> + &sensor_dev_attr_temp1_max.dev_attr.attr, >> + &sensor_dev_attr_temp1_max_hyst.dev_attr.attr, >> + &sensor_dev_attr_temp1_min_alarm.dev_attr.attr, >> + &sensor_dev_attr_temp1_max_alarm.dev_attr.attr, >> + >> + &sensor_dev_attr_temp2_label.dev_attr.attr, >> + &sensor_dev_attr_temp2_input.dev_attr.attr, >> + &sensor_dev_attr_temp2_min.dev_attr.attr, >> + &sensor_dev_attr_temp2_max.dev_attr.attr, >> + &sensor_dev_attr_temp2_max_hyst.dev_attr.attr, >> + &sensor_dev_attr_temp2_min_alarm.dev_attr.attr, >> + &sensor_dev_attr_temp2_max_alarm.dev_attr.attr, >> + >> + &sensor_dev_attr_temp3_label.dev_attr.attr, >> + &sensor_dev_attr_temp3_input.dev_attr.attr, >> + &sensor_dev_attr_temp3_min.dev_attr.attr, >> + &sensor_dev_attr_temp3_max.dev_attr.attr, >> + &sensor_dev_attr_temp3_max_hyst.dev_attr.attr, >> + &sensor_dev_attr_temp3_min_alarm.dev_attr.attr, >> + &sensor_dev_attr_temp3_max_alarm.dev_attr.attr, >> + >> + &sensor_dev_attr_temp4_label.dev_attr.attr, >> + &sensor_dev_attr_temp4_input.dev_attr.attr, >> + &sensor_dev_attr_temp4_min.dev_attr.attr, >> + &sensor_dev_attr_temp4_max.dev_attr.attr, >> + &sensor_dev_attr_temp4_max_hyst.dev_attr.attr, >> + &sensor_dev_attr_temp4_min_alarm.dev_attr.attr, >> + &sensor_dev_attr_temp4_max_alarm.dev_attr.attr, >> + NULL >> +}; >> + >> +static const struct attribute_group abx500_temp_group = { >> + .attrs = abx500_temp_attributes, >> + .is_visible = abx500_attrs_visible, >> +}; >> + >> +static irqreturn_t abx500_temp_irq_handler(int irq, void *irq_data) >> +{ >> + struct platform_device *pdev = irq_data; >> + struct abx500_temp *data = platform_get_drvdata(pdev); >> + >> + data->ops.irq_handler(irq, data); >> + return IRQ_HANDLED; >> +} >> + >> +static int setup_irqs(struct platform_device *pdev) >> +{ >> + int ret; >> + int irq = platform_get_irq_byname(pdev, "ABX500_TEMP_WARM"); >> + >> + if (irq < 0) { >> + dev_err(&pdev->dev, "Get irq by name failed\n"); >> + return irq; >> + } >> + >> + ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, >> + abx500_temp_irq_handler, IRQF_NO_SUSPEND, "abx500-temp", pdev); >> + if (ret < 0) >> + dev_err(&pdev->dev, "Request threaded irq failed (%d)\n", ret); >> + >> + return ret; >> +} >> + >> +static int abx500_temp_probe(struct platform_device *pdev) >> +{ >> + struct abx500_temp *data; >> + int err; >> + >> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL); >> + if (!data) >> + return -ENOMEM; >> + >> + data->pdev = pdev; >> + mutex_init(&data->lock); >> + >> + /* Chip specific initialization */ >> + err = abx500_hwmon_init(data); >> + if (err < 0 || !data->ops.read_sensor || !data->ops.show_name >> + || !data->ops.show_label || !data->ops.is_visible) { > > Nitpick: Second line should be aligned with '('. > >> + dev_err(&pdev->dev, "ABx500 hwmon init failed"); >> + return -EINVAL; >> + } >> + >> + INIT_DEFERRABLE_WORK(&data->work, gpadc_monitor); >> + data->gpadc_monitor_delay = DEFAULT_MONITOR_DELAY; > > Any benefit of having this as variable in the first place ? Why not just use the > define ? > > Nitpick: Extra space after '='. > >> + platform_set_drvdata(pdev, data); >> + >> + err = sysfs_create_group(&pdev->dev.kobj, &abx500_temp_group); >> + if (err < 0) { >> + dev_err(&pdev->dev, "Create sysfs group failed (%d)\n", err); >> + return err; >> + } >> + >> + data->hwmon_dev = hwmon_device_register(&pdev->dev); >> + if (IS_ERR(data->hwmon_dev)) { >> + err = PTR_ERR(data->hwmon_dev); >> + dev_err(&pdev->dev, "Class registration failed (%d)\n", err); >> + goto exit_sysfs_group; >> + } >> + >> + if (data->ops.irq_handler) { >> + err = setup_irqs(pdev); >> + if (err < 0) { >> + dev_err(&pdev->dev, "irq setup failed (%d)\n", err); >> + goto exit_hwmon_reg; >> + } >> + } >> + return 0; >> + >> +exit_hwmon_reg: >> + hwmon_device_unregister(data->hwmon_dev); >> +exit_sysfs_group: >> + sysfs_remove_group(&pdev->dev.kobj, &abx500_temp_group); >> + return err; >> +} >> + >> +static int abx500_temp_remove(struct platform_device *pdev) >> +{ >> + struct abx500_temp *data = platform_get_drvdata(pdev); >> + >> + mutex_lock(&data->lock); >> + hwmon_device_unregister(data->hwmon_dev); >> + sysfs_remove_group(&pdev->dev.kobj, &abx500_temp_group); >> + cancel_delayed_work_sync(&data->work); > > Should come first. > >> + mutex_unlock(&data->lock); > > This mutex protection is definitely not needed. > >> + >> + return 0; >> +} >> + >> +static int abx500_temp_suspend(struct platform_device *pdev, >> + pm_message_t state) >> +{ >> + struct abx500_temp *data = platform_get_drvdata(pdev); >> + >> + mutex_lock(&data->lock); >> + if (data->work_active) >> + cancel_delayed_work_sync(&data->work); >> + mutex_unlock(&data->lock); > > I don't think this mutex protection is needed. Looking into other drivers, they > commonly cancel work outside mutex protection. > > What happens if poweroff due to overheating is pending ? > >> + >> + return 0; >> +} >> + >> +static int abx500_temp_resume(struct platform_device *pdev) >> +{ >> + struct abx500_temp *data = platform_get_drvdata(pdev); >> + >> + if (data->work_active) >> + schedule_monitor(data); >> + return 0; >> +} >> + >> +#ifdef CONFIG_OF >> +static const struct of_device_id abx500_temp_match[] = { >> + { .compatible = "stericsson,abx500-temp" }, >> + {}, >> +}; >> +#endif >> + >> +static struct platform_driver abx500_temp_driver = { >> + .driver = { >> + .owner = THIS_MODULE, >> + .name = "abx500-temp", >> + .of_match_table = of_match_ptr(abx500_temp_match), >> + }, >> + .suspend = abx500_temp_suspend, >> + .resume = abx500_temp_resume, >> + .probe = abx500_temp_probe, >> + .remove = abx500_temp_remove, >> +}; >> + >> +module_platform_driver(abx500_temp_driver); >> + >> +MODULE_AUTHOR("Martin Persson <martin.persson(a)stericsson.com>"); >> +MODULE_DESCRIPTION("ABX500 temperature driver"); >> +MODULE_LICENSE("GPL"); >> diff --git a/drivers/hwmon/abx500.h b/drivers/hwmon/abx500.h >> new file mode 100644 >> index 0000000..c1dd41d >> --- /dev/null >> +++ b/drivers/hwmon/abx500.h >> @@ -0,0 +1,87 @@ >> +/* >> + * Copyright (C) ST-Ericsson SA 2010 > > 2010 - 2013 ? > >> + * License terms: GNU General Public License v2 >> + * Author: Martin Persson <martin.persson(a)stericsson.com> >> + */ >> + >> +#ifndef _ABX500_H >> +#define _ABX500_H >> + >> +#define NUM_SENSORS 5 >> + >> +struct ab8500_gpadc; >> +struct ab8500_btemp; >> +struct abx500_temp; >> + >> +extern struct abx500_res_to_temp temp_tbl_A_thermistor[]; >> +extern int temp_tbl_A_size; > > Those variables should be defined in the defining code in an exporting > include file, which this driver should include. Also, the name should be less > generic and refer to the introducing module (abx500_temp_tbl_a_thermistor, > maybe). > > Also, CamelCase variable names are discouraged nowadays and create a checkpatch > warning. Please take that into account when selecting a different name. > Talked to the owner of that part, we will move the data to proper place, and rename the variables. >> + >> +/* >> + * struct abx500_temp_ops - abx500 chip specific ops >> + * @read_sensor: reads gpadc output >> + * @irq_handler: irq handler >> + * @show_name: hwmon device name >> + * @show_label: hwmon attribute label >> + * @is_visible: is attribute visible >> + */ >> +struct abx500_temp_ops { >> + int (*read_sensor)(struct abx500_temp *, u8); >> + int (*irq_handler)(int, struct abx500_temp *); >> + ssize_t (*show_name)(struct device *, >> + struct device_attribute *, char *); >> + ssize_t (*show_label) (struct device *, >> + struct device_attribute *, char *); >> + int (*is_visible)(struct attribute *, int); >> +}; >> + >> +/* >> + * struct abx500_temp - representation of temp mon device >> + * @pdev: platform device >> + * @hwmon_dev: hwmon device >> + * @ab8500_gpadc: gpadc interface for ab8500 >> + * @btemp: battery temperature interface for ab8500 >> + * @gpadc_addr: gpadc channel address >> + * @min: sensor temperature min value >> + * @max: sensor temperature max value >> + * @max_hyst: sensor temperature hysteresis value for max limit >> + * @crit: sensor temperature critical value >> + * @min_alarm: sensor temperature min alarm >> + * @max_alarm: sensor temperature max alarm >> + * @crit_alarm: sensor temperature critical value alarm >> + * @work: delayed work scheduled to monitor temperature periodically >> + * @work_active: True if work is active >> + * @power_off_work: delayed work scheduled to power off the system >> + * when critical temperature is reached >> + * @lock: mutex >> + * @gpadc_monitor_delay: delay between temperature readings in ms >> + * @power_off_delay: delay before power off in ms >> + * @monitored_sensors: number of monitored sensors >> + */ >> +struct abx500_temp { >> + struct platform_device *pdev; >> + struct device *hwmon_dev; >> + struct ab8500_gpadc *ab8500_gpadc; >> + struct ab8500_btemp *ab8500_btemp; >> + struct abx500_temp_ops ops; >> + u8 gpadc_addr[NUM_SENSORS]; >> + unsigned long min[NUM_SENSORS]; >> + unsigned long max[NUM_SENSORS]; >> + unsigned long max_hyst[NUM_SENSORS]; >> + unsigned long crit[NUM_SENSORS]; > > Not used anywhere. > >> + bool min_alarm[NUM_SENSORS]; >> + bool max_alarm[NUM_SENSORS]; >> + bool crit_alarm[NUM_SENSORS]; > > Not used anywhere. > >> + struct delayed_work work; >> + bool work_active; >> + struct delayed_work power_off_work; >> + struct mutex lock; >> + /* Delay (ms) between temperature readings */ >> + unsigned long gpadc_monitor_delay; >> + /* Delay (ms) before power off */ >> + unsigned long power_off_delay; >> + int monitored_sensors; > > Many of those variables are only used in the abx500 code. You should have two > structures, one defined inside the abx500 code for variables only used there, > and one exported to other drivers. The exported structure could be embedded in > the private one. > > Similar, you should have a private data structure in the ab8500 driver, for > variables only used there. > Yes, will consider this. (historic reason is that these two files was one file before, and then separated into two) >> +}; >> + >> +int abx500_hwmon_init(struct abx500_temp *data); >> + >> +#endif /* _ABX500_H */ >> -- >> 1.8.0 >> >>

12 years, 3 months

1
0
0 0

[PATCH v6 0/5] Add DRM FIMD DT support for Exynos4 DT Machines

by Vikas Sajjan

This patch series adds support for DRM FIMD DT for Exynos4 DT Machines, specifically for Exynos4412 SoC. changes since v5: - renamed the fimd binding documentation file name as "samsung.fimd.txt", since it not only talks about exynos display controller but also about previous samsung display controllers. - rephrased an abmigious statement about the interrupt combiner in the fimd binding documentation as pointed out by Sachin Kamat <sachin.kamat.linaro.org> changes since v4: - moved the fimd binding documentation to Documentation/devicetree/bindings/video/ as suggested by Sylwester Nawrocki <sylvester.nawrocki(a)gmail.com> - added more fimd compatiblity strings in fimd documentation as discussed at https://patchwork.kernel.org/patch/2144861/ with Sylwester Nawrocki <sylvester.nawrocki(a)gmail.com> and Tomasz Figa <tomasz.figa(a)gmail.com> - modified compatible string for exynos4 fimd as "exynos4210-fimd" exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible value should be named after first specific SoC model in which this particular IP version was included as discussed at https://patchwork.kernel.org/patch/2144861/ - documented more about the interrupt combiner and their order as suggested by Sylwester Nawrocki <sylvester.nawrocki(a)gmail.com> changes since v3: - rebased on http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=shortlo… changes since v2: - added alias to 'fimd@11c00000' node (reported by: Rahul Sharma <r.sh.open(a)gmail.com>) - removed 'lcd0_data' node as there was already a similar node lcd_data24 (reported by: Jingoo Han <jg1.han(a)samsung.com> - replaced spaces with tabs in display-timing node changes since v1: - added new patch to add FIMD DT binding Documentation - removed patch enabling SAMSUNG_DEV_BACKLIGHT and SAMSUNG_DEV_PMW for mach-exynos4 DT - added 'status' property to fimd DT node Is based on branch "for-next-next" http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=shortlo… Sachin Kamat (1): ARM: dts: Add lcd pinctrl node entries for EXYNOS4412 SoC Vikas Sajjan (4): ARM: dts: Add FIMD node to exynos4 ARM: dts: Add FIMD node and display timing node to exynos4412-origen.dts ARM: dts: add FIMD AUXDATA node entry for exynos4 DT ARM: dts: Add FIMD DT binding Documentation .../devicetree/bindings/video/samsung-fimd.txt | 54 ++++++++++++++++++++ arch/arm/boot/dts/exynos4.dtsi | 7 +++ arch/arm/boot/dts/exynos4412-origen.dts | 22 ++++++++ arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 14 +++++ arch/arm/mach-exynos/mach-exynos4-dt.c | 2 + 5 files changed, 99 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/samsung-fimd.txt -- 1.7.9.5

12 years, 3 months

1
5
0 0

RE: [PATCH 0/4] time: dynamic irq affinity

by Shakti Swain

My first post in to the mailing list. Deep power idle state is nothing but CPU power domain off. Its not impossible but would require some hw change. If kernel is aware of a CPU being in power off state, can we first do a CPU wakeup before issuing SGI. The wakeup routine has to be implemented by SoC provider as it will be different for each vendor. Regds Shakti Sent from my Nokia Lumia 920 ________________________________ From: Santosh Shilimkar<mailto:santosh.shilimkar@ti.com> Sent: ‎2/‎26/‎2013 10:00 PM To: Daniel Lezcano<mailto:daniel.lezcano@linaro.org> Cc: jacob.jun.pan(a)linux.intel.com<mailto:jacob.jun.pan@linux.intel.com>; Russell King - ARM Linux<mailto:linux@arm.linux.org.uk>; linus.walleij(a)stericsson.com<mailto:linus.walleij@stericsson.com>; linux-pm(a)vger.kernel.org<mailto:linux-pm@vger.kernel.org>; viresh.kumar(a)linaro.org<mailto:viresh.kumar@linaro.org>; patches(a)linaro.org<mailto:patches@linaro.org>; linux-kernel(a)vger.kernel.org<mailto:linux-kernel@vger.kernel.org>; linaro-kernel(a)lists.linaro.org<mailto:linaro-kernel@lists.linaro.org>; linux-arm-kernel(a)lists.infradead.org<mailto:linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 0/4] time: dynamic irq affinity On Wednesday 27 February 2013 03:47 AM, Daniel Lezcano wrote: > When a cpu goes to a deep idle state where its local timer is shutdown, > it notifies the time framework to use the broadcast timer instead. > > Unfortunately, the broadcast device could wake up any CPU, including an > idle one which is not concerned by the wake up at all. > > This implies, in the worst case, an idle CPU will wake up to send an IPI > to another idle cpu. > > This patch solves this by setting the irq affinity to the cpu concerned > by the nearest timer event, by this way, the CPU which is wake up is > guarantee to be the one concerned by the next event and we are safe with > unnecessary wakeup for another idle CPU. > > As the irq affinity is not supported by all the archs, a flag is needed > to specify which clocksource can handle it. > Not completely related to this series but there is another issue where this local timer not wakeup capable hurts. So far we are discussing only the timer related future events which are known and can be programmed with broadcast device. But think of the scenario's where we need to send asynchronous IPIs to CPUs to do some work. e.g generic_exec_single(). If the CPU which is suppose to be available after IPI call is in deep low power state, then the IPI(implemented on ARM) isn't effective. In CPU off idle modes, a GIC SGI will not wake the CPU and hence a special wakeup is needed to bring out those CPUs out of idle. This special wakeup is handled by broad-cast timer in case of CPUIDLE. In short what I mean is, you need to have IPI which can wakeup CPUs from any deep idle power state to address above. Has anybody thought of this one ? Regards, Santosh P.S: Time and again it proves that making the local timer wakeup capable solves the issue. _______________________________________________ linaro-kernel mailing list linaro-kernel(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel

12 years, 3 months

1
0
0 0

Obtaining an vmocre (linaro guest core).

by phi debian

Hi All, I am new on this mailing list, I browsed archive against vmcore but got no hit so the question here. I am running ./Foundation_v8pkg/Foundation_v8 \ --image ./img-foundation.axf \ --block-device ./vexpress64-openembedded_sdk-armv8_20130127-242.img \ --network=nat That gives Linux genericarmv8 3.8.0-1-linaro-vexpress64 #1ubuntu1~ci+130127041142 SMP Sun Jan 27 04:15:58 UTC 2013 aarch64 GNU/Linux root@genericarmv8:/usr# I am doing some linux crashdump analysis tools, and I'd like to prepare the future. At the moment I am not sure how to obtain an aa64 linux crashdump (vmcore), as I got no HW then no distro. I was wondering, is it possible to send a signal to the Foundation_v8 and then got a copy of the guest emulated main memory ? along with a savestate per cpu ? And to make this usable, is there a way to obtain the vmlinux (and possibly modules) a.out non stripped with debuginfos that was used to obtain the img.axf (abd the modules in the .img if any) If this is not doable with file on the server used during the build of ./img-foundation.axf and ./vexpress64-openembedded_sdk-armv8_20130127-242.img then may be I got to expliclty build my own .axf .img and keep the debuginfo from this build. Any advises appreciated. Thank you for the linaro that booted straightaway. Cheers, Phi

12 years, 3 months

1
0
0 0

Re: 13.01 Versatile Express Android build unstable

by D D

Hi Tixy, Yes, I have tried both the config in the release notes as well as configurations to boot A7. The configurations to boot A7 hang while executing the BOOTSCRIPT. The release note configurations get past that state, boot up the kernel and hang as shown in this thread. As a first step, I am just trying to get the release note configuration working without the hang. Thanks Dinesh On Tue, Feb 26, 2013 at 9:43 AM, Jon Medhurst (Tixy) <tixy(a)linaro.org>wrote: > On Tue, 2013-02-26 at 09:24 -0800, D D wrote: > > Thanks Tixy, I tried 0x0032F003, but still seeing the same hang. > > Looks like 0x0032F003 powers down the non boot cluster (in this case > > A7), while I wanted to try running with the A7s online. That was the > > reason why I was trying to boot with 0x00320003. > > So you have other config changes to get the board booting on A7? I've > never tried to do that. > > Does the config produced by our release notes work for you? (Which will > boot on the A15's.) > > I'm trying to understand if we're debugging a problem with the Linaro > release, or debugging whatever modified setup you have. > > -- > Tixy > > >

12 years, 3 months

1
0
0 0

arm_big_little: More CPUIdle states?

by Eric Huang

Lorenzo, Looking in the cpuidle code in Linaro's 13.01 kernel, there are only two idle states supported in the cpuidle/arm_big_little.c, one is WFI, the other is C1. So to have more than these 2 idle states supported on a SoC, it looks like I have to create SoC specific CPU idle driver to replace the arm_big_little.c. Is this the intended design? It would be better if there is a way the arm_big_little.c can support SoC specific idle sets, via device tree maybe? Eric Huang

12 years, 3 months

5
7
0 0

13.01 Versatile Express Android build unstable

by D D

Hi, 13.01 Versatile Express kernel hangs on TC2 during bootup. I am not seeing much help with build 13.02 either. Anyone seeing the same issue, please let me know. Thanks Dinesh Cmd> Powering up system... Daughterboard fitted to site 1. Switching on ATXPSU... ATX3V3: ON VIOset: 1.8V MBtemp: 35 degC Configuring motherboard (rev D, var A)... IOFPGA config: PASSED MUXFPGA config: PASSED OSC CLK config: PASSED Testing SMC devices (FPGA build 16)... SRAM 32MB test: PASSED VRAM 8MB test: PASSED LAN9118 test: PASSED USB & OTG test: PASSED KMI1/KMI2 test: PASSED MMC & SD test: PASSED DVI image test: PASSED AACI AC97 test: PASSED CF card test: PASSED UART port test: PASSED MAC addrs test: PASSED Reading Site 1 Board File \SITE1\HBI0249A\board.txt DB1 JTAG configuration complete. Setting DB1 OSCCLKS... DB1.0 DCC 0 SPI configuration complete. Writing SCC 0x40610007 with 0xFF00FF00 Writing SCC 0x40610046 with 0x01CD1011 Writing SCC 0x406101C0 with 0x00320003 Writing SCC 0x40610048 with 0x022F1010 Writing SCC 0x40610049 with 0x0011710D Writing SCC 0x4061004A with 0x022F1010 Writing SCC 0x4061004B with 0x0011710D Writing SCC 0x4061004C with 0x022F1010 Writing SCC 0x4061004D with 0x0011710D Writing SCC 0x4061004E with 0x022F1010 Writing SCC 0x4061004F with 0x0011710D Writing SCC 0x40610300 with 0x00000005 Writing SCC 0x40610301 with 0x060E0356 Writing SCC 0x40610302 with 0x00000000 Writing SCC 0x40610303 with 0x00000000 Writing SCC 0x40610304 with 0x384061A8 Writing SCC 0x40610305 with 0x38407530 Writing SCC 0x40610306 with 0x384088B8 Writing SCC 0x40610307 with 0x38409C40 Writing SCC 0x40610308 with 0x3840AFC8 Writing SCC 0x40610309 with 0x3840C350 Writing SCC 0x4061030A with 0x3CF0D6D8 Writing SCC 0x4061030B with 0x41A0EA60 Writing SCC 0x4061030C with 0x3840445C Writing SCC 0x4061030D with 0x38404E20 Writing SCC 0x4061030E with 0x384061A8 Writing SCC 0x4061030F with 0x38407530 Writing SCC 0x40610310 with 0x384088B8 Writing SCC 0x40610311 with 0x38409C40 Writing SCC 0x40610312 with 0x3CF0AFC8 Writing SCC 0x40610313 with 0x41A0C350 DB1.0 DCC 0 SCC configuration complete. DB SMB clock enabled. Waiting for SITE1 CB_READY... Testing SMB clock... Configuring MUXFPGA for MB. Setting DVI mode for VGA. Releasing Daughterboard resets. Switching MCC log to UART1. ARM Versatile Express Boot Monitor Version: V5.1.9 Build Date: Dec 3 2012 Daughterboard Site 1: V2P-CA15_A7 Cortex A15 Daughterboard Site 2: Not Used Running boot script from flash - BOOTSCRIPT UEFI firmware (version built at 12:16:16 on Jan 25 2013) add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Info: 2GB Test Chip 2 detected. add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading DxeCore at 0x00BFAB6000 EntryPoint=0x00BFAB6241 add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0HOBLIST address in DXE = 0xBF8C8010 Memory Allocation 0x00000004 0xBFFEB000 - 0xBFFEBFFF Memory Allocation 0x00000004 0xBFFE3000 - 0xBFFEAFFF Memory Allocation 0x00000004 0xBFFE2000 - 0xBFFE2FFF Memory Allocation 0x00000004 0xBFFE1000 - 0xBFFE1FFF Memory Allocation 0x00000004 0xBFFE0000 - 0xBFFE0FFF Memory Allocation 0x00000004 0xBFFDF000 - 0xBFFDFFFF Memory Allocation 0x00000004 0xBFFEC000 - 0xC0003FFF Memory Allocation 0x00000004 0xBFFCF000 - 0xBFFDEFFF Memory Allocation 0x00000004 0xBFD57000 - 0xBFFCEFFF Memory Allocation 0x00000004 0xBFADF000 - 0xBFD56FFF Memory Allocation 0x00000004 0xBFAB6000 - 0xBFADEFFF Memory Allocation 0x00000003 0xBFAB6000 - 0xBFADEFFF FV Hob 0x81000000 - 0x810AFFFF FV Hob 0xBFADF000 - 0xBFD55A3F FV2 Hob 0xBFADF000 - 0xBFD55A3F add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BFA5C000 EntryPoint=0x000BFA5C26D ArmCpuDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BFA74000 EntryPoint=0x000BFA7426D RuntimeDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BFA50000 EntryPoint=0x000BFA5026D SecurityStubDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BFA43000 EntryPoint=0x000BFA4326D FaultTolerantWriteDxe.eadd-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BAAA2000 EntryPoint=0x000BAAA226D Reset.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BAA95000 EntryPoint=0x000BAA9526D RealTimeClock.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BFA26000 EntryPoint=0x000BFA2626D HiiDatabase.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BFA1C000 EntryPoint=0x000BFA1C26D SerialDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BFA10000 EntryPoint=0x000BFA1026D SP805WatchdogDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BF9FF000 EntryPoint=0x000BF9FF26D AcpiTableDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BF9EF000 EntryPoint=0x000BF9EF26D DevicePathDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BF9E1000 EntryPoint=0x000BF9E126D ArmVeNorFlashDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BAA82000 EntryPoint=0x000BAA8226D VariableRuntimeDxe.efi Variable driver failed to add EFI_MEMORY_RUNTIME attribute to Flash. add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BF9D6000 EntryPoint=0x000BF9D626D MetronomeDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BF9CA000 EntryPoint=0x000BF9CA26D PL390GicDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BF9BB000 EntryPoint=0x000BF9BB26D HdLcdGraphicsDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BF9AA000 EntryPoint=0x000BF9AA26D MmcDxe.efi add-symbol-file /mnt/ci_build/workspace/uefi/uefi/Build/ArmVExpress-CTA15-A7/DE0Loading driver at 0x000BF99E000 EntryPoint=0x000BF99E26D PL180MciDxe.efi Card is SD2.0 => Supports high capacity High capacity card. The default boot selection will start in 1 seconds PEI 492 ms DXE 9975 ms BDS 12778 ms Total Time = 23246 ms Starting the kernel: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.8.0-rc4-00183-g134b797 (jenkins-build@ip-10-10-13[ 0.000000] Kernel was built at commit id '' (Lin [ 0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=50c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: ARM-Versatile Express, model: V2P-CA15_CA7 [ 0.000000] Truncating memory at 0x80000000 to fit in 32-bit physical address space [ 0.000000] Memory policy: ECC disabled, Data cache writealloc [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x80000000-0xaf7fffff] [ 0.000000] HighMem [mem 0xaf800000-0xffffefff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x80000000-0xffffefff] [ 0.000000] PERCPU: Embedded 9 pages/cpu @c1bbc000 s14336 r8192 d14336 u36864 [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)n. Total pag[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)=/d[ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] Memory: 2032MB = 2032MB total [ 0.000000] Memory: 2051160k/2051160k available, 29608k reserved, 1302528K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf800000 - 0xbfe00000 ( 6 MB) [ 0.000000] .text : 0xc0008000 - 0xc05b252c (5802 kB) [ 0.000000] .data : 0xc05f2000 - 0xc063ccf0 ( 300 kB) [ 0.000000] .bss : 0xc063ccf0 - 0xc0b950e0 (5473 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=5. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] Using SP804 '/smb/motherboard/iofpga@3,00000000/timer@110000' as [ 0.000000] Architected local timer running at 24.00MHz (virt). [ 0.000000] Switching to timer-based delay loop [ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 17895[ 0.000000] Console: colour dummy device 80x30 [ 0.000000] console [tty0] enabled [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo[ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 [ 0.000000] ... CHAINHASH_SIZE: 16384 [ 0.000000] memory used by lock dependency info: 3695 kB [ 0.000000] per task-struct memory footprint: 1152 bytes [ 0.003236] Calibrating delay loop (skipped), value calculated using timer fr[ 0.003289] pid_max: default: 32768 minimum: 301 [ 0.003776] Mount-cache hash table entries: 512 [ 0.014055] CPU: Testing write buffer coherency: ok [ 0.014161] ftrace: allocating 19832 entries in 39 pages [ 0.039247] CPU0: update cpu_power 1441 [ 0.039271] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.039325] Setting up static identity map for 0x803d9688 - 0x803d96d4 [ 0.042226] vexpress_spc loaded at f0008000 [ 0.042247] TC2 power management initialized [ 1.040319] CPU1: failed to come online [ 2.041345] CPU2: failed to come online [ 3.042400] CPU3: failed to come online [ 4.043450] CPU4: failed to come online [ 4.043684] Brought up 1 CPUs [ 4.043701] SMP: Total of 1 processors activated (48.00 BogoMIPS). [ 4.054586] sched: registering cpufreq notifiers for scale-invariant loads [ 4.058640] regulator-dummy: no parameters [ 4.060168] NET: Registered protocol family 16 [ 4.060460] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 4.064390] hw perfevents: enabled with CCI PMU driver, 5 counters available [ 4.064538] CCI loaded at f0060000 [ 4.088926] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint [ 4.088955] hw-breakpoint: maximum watchpoint size is 8 bytes. [ 4.088980] Serial: AMBA PL011 UART driver [ 4.089432] 1c090000.uart: ttyAMA0 at MMIO 0x1c090000 (irq = 37) is a PL011 r[ 5.430079] console [ttyAMA0] enabled [ 5.441952] 1c0a0000.uart: ttyAMA1 at MMIO 0x1c0a0000 (irq = 38) is a PL011 r[ 5.465048] 1c0b0000.uart: ttyAMA2 at MMIO 0x1c0b0000 (irq = 39) is a PL011 r[ 5.487744] 1c0c0000.uart: ttyAMA3 at MMIO 0x1c0c0000 (irq = 40) is a PL011 r[ 5.547539] bio: create slab <bio-0> at 0 [ 5.560951] 3V3: 3300 mV [ 5.570555] SCSI subsystem initialized [ 5.583825] usbcore: registered new interface driver usbfs [ 5.600553] usbcore: registered new interface driver hub [ 5.616884] usbcore: registered new device driver usb [ 5.633769] Advanced Linux Sound Architecture Driver Initialized. [ 5.654438] Switching to clocksource arch_sys_counter [ 5.744636] NET: Registered protocol family 2 [ 5.758733] TCP established hash table entries: 8192 (order: 4, 65536 bytes) [ 5.780155] TCP bind hash table entries: 8192 (order: 6, 294912 bytes) [ 5.802052] TCP: Hash tables configured (established 8192 bind 8192) [ 5.821238] TCP: reno registered [ 5.830930] UDP hash table entries: 512 (order: 3, 40960 bytes) [ 5.848993] UDP-Lite hash table entries: 512 (order: 3, 40960 bytes) [ 5.868771] NET: Registered protocol family 1 [ 5.882478] RPC: Registered named UNIX socket transport module. [ 5.900236] RPC: Registered udp transport module. [ 5.914338] RPC: Registered tcp transport module. [ 5.928441] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 5.948251] Trying to unpack rootfs image as initramfs... [ 5.977969] Freeing initrd memory: 216K [ 5.989794] hw perfevents: enabled with ARMv7_Cortex_A15 PMU driver, 7 counte[ 6.014395] hw perfevents: enabled with ARMv7_Cortex_A7 PMU driver, 7 counter[ 6.044892] bounce pool size: 64 pages [ 6.056509] VFS: Disk quotas dquot_6.5.2 [ 6.068394] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 6.090805] NFS: Registering the id_resolver key type [ 6.106159] Key type id_resolver registered [ 6.118706] Key type id_legacy registered [ 6.130794] jffs2: version 2.2. (NAND) (SUMMARY) ?? 2001-2006 Red Hat, Inc. [ 6.152278] fuse init (API version 7.20) [ 6.165002] Btrfs loaded [ 6.172615] msgmni has been set to 1462 [ 6.186181] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 2[ 6.208399] io scheduler noop registered [ 6.220160] io scheduler deadline registered [ 6.233005] io scheduler cfq registered (default) [ 6.257649] hdlcd 2b000000.hdlcd: HDLCD: found ARM HDLCD version r0p0 [ 6.276976] hdlcd 2b000000.hdlcd: using 1024x768-16@60 mode [ 6.312590] Console: switching to colour frame buffer device 128x48 [ 6.409815] A15 Vcore: 800 <--> 1050 mV at 896 mV [ 6.439818] A7 Vcore: 800 <--> 1050 mV at 900 mV [ 6.469810] VIO: at 1780 mV [ 6.642067] brd: module loaded [ 6.659909] loop: module loaded [ 6.671444] mtdoops: mtd device (mtddev=name/number) must be supplied [ 6.692034] mmci-pl18x 1c050000.mmci: mmc0: PL180 manf 41 rev0 at 0x1c050000 [ 6.754190] smsc911x: Driver version 2008-10-21 [ 6.768250] smsc911x 1a000000.ethernet (unregistered net_device): couldn't ge[ 6.795437] libphy: smsc911x-mdio: probed [ 6.807649] smsc911x 1a000000.ethernet eth0: attached PHY driver [Generic PHY[ 6.842068] smsc911x 1a000000.ethernet eth0: MAC Address: 00:02:f7:00:3b:7a [ 6.864237] nxp-isp1760 1b000000.usb: NXP ISP1760 USB Host Controller [ 6.884936] nxp-isp1760 1b000000.usb: new USB bus registered, assigned bus nu[ 7.109107] nxp-isp1760 1b000000.usb: bus width: 32, oc: digital [ 7.148306] nxp-isp1760 1b000000.usb: irq 48, io mem 0x1b000000 [ 7.167322] nxp-isp1760 1b000000.usb: USB ISP 1761 HW rev. 1 started [ 7.190699] Initializing USB Mass Storage driver... [ 7.206808] usbcore: registered new interface driver usb-storage [ 7.225997] USB Mass Storage support registered. [ 7.243260] mousedev: PS/2 mouse device common for all mice [ 7.263760] rtc-pl031 1c170000.rtc: rtc core: registered pl031 as rtc0 [ 7.289063] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-d[ 7.316347] arm_big_little: CPU 0 initialized [ 7.333009] arm_big_little: bL_cpufreq_register: Registered platform driver: [ 7.358424] cpuidle: using governor ladder [ 7.371768] cpuidle: using governor menu [ 7.387848] usbcore: registered new interface driver usbhid [ 7.405548] usbhid: USB HID core driver [ 7.419100] ashmem: initialized [ 7.429948] logger: created 256K log 'log_main' [ 7.444855] logger: created 256K log 'log_events' [ 7.460242] logger: created 256K log 'log_radio' [ 7.475295] nxp-isp1760 1b000000.usb: port 1 high speed [ 7.492132] logger: created 256K log 'log_system' [ 7.515908] mmc0: new SDHC card at address d72a [ 7.538679] mmcblk0: mmc0:d72a SD08G 7.40 GiB [ 7.553791] aaci-pl041 1c040000.aaci: ARM AC'97 Interface PL041 rev0 at 0x1c0[ 7.579549] aaci-pl041 1c040000.aaci: FIFO 512 entries [ 7.598744] oprofile: using timer interrupt. [ 7.612909] TCP: cubic registered [ 7.623837] Initializing XFRM netlink socket [ 7.637832] NET: Registered protocol family 10 [ 7.653470] NET: Registered protocol family 17 [ 7.667749] NET: Registered protocol family 15 [ 7.682113] Key type dns_resolver registered [ 7.695875] VFP support v0.3: implementor 41 architecture 4 part 30 variant f[ 7.719851] Registering SWP/SWPB emulation handler [ 7.735337] nxp-isp1760 1b000000.usb: port 1 high speed [ 7.753161] rtc-pl031 1c170000.rtc: setting system clock to 2013-02-14 03:47:[ 7.780583] CPUidle for CPU0 registered [ 7.793338] ALSA device list: [ 7.803297] #0: ARM AC'97 Interface PL041 rev0 at 0x1c040000, irq 43 [ 7.824873] Freeing init memory: 244K [ 7.841441] mmcblk0: p1 p2 p3 p4 < p5 p6 > [ 7.860577] init (1): /proc/1/oom_adj is deprecated, please use /proc/1/oom_s[ 8.260264] atkbd serio0: keyboard reset failed on 1c060000.kmi [ 8.561474] input: CHICONY HP Basic USB Keyboard as /devices/smb.23/motherbo0[ 8.612606] hid-generic 0003:03F0:0024.0001: input: USB HID v1.10 Keyboard [0 ********************************************* Hangs here ***************************************************************

12 years, 3 months

2
2
0 0

[RFC] cpufreq: governor: Set MIN_LATENCY_MULTIPLIER to 20

by Viresh Kumar

Currently MIN_LATENCY_MULTIPLIER is set defined as 100 and so on a system with transition latency of 1 ms, the minimum sampling time comes to be around 100 ms. That is quite big if you want to get better performance for your system. Redefine MIN_LATENCY_MULTIPLIER to 20 so that we can support 20ms sampling rate for such platforms. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- Hi Guys, I really don't know how this figure (100) came initially, but we really need to have 20ms support for my platform: ARM TC2. Pushed here: http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/h… drivers/cpufreq/cpufreq_governor.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h index d2ac911..adb8e30 100644 --- a/drivers/cpufreq/cpufreq_governor.h +++ b/drivers/cpufreq/cpufreq_governor.h @@ -34,7 +34,7 @@ */ #define MIN_SAMPLING_RATE_RATIO (2) #define LATENCY_MULTIPLIER (1000) -#define MIN_LATENCY_MULTIPLIER (100) +#define MIN_LATENCY_MULTIPLIER (20) #define TRANSITION_LATENCY_LIMIT (10 * 1000 * 1000) /* Ondemand Sampling types */ -- 1.7.12.rc2.18.g61b472e

12 years, 3 months

2
3
0 0

[PATCH 1/2] time : pass broadcast device parameter

by Daniel Lezcano

The broadcast timer could be passed as parameter to the function instead of using again tick_broadcast_device.evtdev which was previously used in the caller function. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- kernel/time/tick-broadcast.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c index f113755..baf9b0e7 100644 --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@ -370,10 +370,9 @@ struct cpumask *tick_get_broadcast_oneshot_mask(void) return to_cpumask(tick_broadcast_oneshot_mask); } -static int tick_broadcast_set_event(ktime_t expires, int force) +static int tick_broadcast_set_event(struct clock_event_device *bc, + ktime_t expires, int force) { - struct clock_event_device *bc = tick_broadcast_device.evtdev; - if (bc->mode != CLOCK_EVT_MODE_ONESHOT) clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT); @@ -443,7 +442,7 @@ again: * Rearm the broadcast device. If event expired, * repeat the above */ - if (tick_broadcast_set_event(next_event, 0)) + if (tick_broadcast_set_event(dev, next_event, 0)) goto again; } raw_spin_unlock(&tick_broadcast_lock); @@ -486,7 +485,7 @@ void tick_broadcast_oneshot_control(unsigned long reason) cpumask_set_cpu(cpu, tick_get_broadcast_oneshot_mask()); clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN); if (dev->next_event.tv64 < bc->next_event.tv64) - tick_broadcast_set_event(dev->next_event, 1); + tick_broadcast_set_event(bc, dev->next_event, 1); } } else { if (cpumask_test_cpu(cpu, tick_get_broadcast_oneshot_mask())) { @@ -555,7 +554,7 @@ void tick_broadcast_setup_oneshot(struct clock_event_device *bc) clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT); tick_broadcast_init_next_event(to_cpumask(tmpmask), tick_next_period); - tick_broadcast_set_event(tick_next_period, 1); + tick_broadcast_set_event(bc, tick_next_period, 1); } else bc->next_event.tv64 = KTIME_MAX; } else { -- 1.7.9.5

12 years, 3 months

4
9
0 0

[PATCH] clocksource : nomadik-mtu : fix missing irq initialization

by Daniel Lezcano

This patch fix the clock device irq field which is not initialized. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- drivers/clocksource/nomadik-mtu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/nomadik-mtu.c b/drivers/clocksource/nomadik-mtu.c index 8914c3c..7cbcaa0 100644 --- a/drivers/clocksource/nomadik-mtu.c +++ b/drivers/clocksource/nomadik-mtu.c @@ -226,5 +226,6 @@ void __init nmdk_timer_init(void __iomem *base, int irq) /* Timer 1 is used for events, register irq and clockevents */ setup_irq(irq, &nmdk_timer_irq); nmdk_clkevt.cpumask = cpumask_of(0); + nmdk_clkevt.irq = irq; clockevents_config_and_register(&nmdk_clkevt, rate, 2, 0xffffffffU); } -- 1.7.9.5

12 years, 3 months

2
2
0 0

[ACTIVITY] (John Stultz) Feb 18 - 22

by John Stultz

=== Highlights === * Flew to SF and presented at ABS, then flew back home on Monday. Slides are here: http://events.linuxfoundation.org/images/stories/slides/abs2013_stultz.pdf * Spurred by discussion at ABS, worked out how to get ADB running on vanilla linux: https://plus.google.com/u/0/111524780435806926688/posts/AaEccFjKNHE * My discussion proposal for lsf/mm-minisummit on volatile ranges was accepted and I was formally invited to attend * Discussed Serbans' ashmem compat_ioctl patches with Arve and Serban. * Sent out late android upstreaming subteam mail * Synced up with Jakub on Android Upstreaming session at connect * Got my 3.9 timekeeping queue merged upstream, and reviewed and queued a number of timekeeping patches for 3.10 * Discussed some timekeeping changes with tglx, and reviewed some of his patches. * Implemented a first pass at using valid-cycle-ranges with vdso based gettime calls to avoid potential race windows with virtualized kernels. This will allow for reduced lock hold times in the future. === Plans === * Review Serban's binder patches * Look into Androids support of large-files with 32bit applications * Send out sync driver for staging (as I've not heard back from Erik or other folks at Google) * Prep for Connect === Issues === * NA

12 years, 3 months

1
0
0 0

[ACTIVITY] (David Long) 2013-02-16 - 2013-02-22

by David Long

=== David Long === === Travel/Time Off === * Monday February 18th (U.S. Washington's Birthday, aka President's Day) === Highlights === * I'm dealing with problems getting the uprobe uprobe patch to correctly process the breakpoint. I see the breakpoint being placed but the result when it hits it seems to be corrupted context. * I received email back from Rabin Vincent saying he had no plans to work on this any more and he is happy if I want to take it over. He has volunteered to supply his tests, which I hope to see shortly. === Plans === * Debug the problems I'm experiencing with the patch, then move on to addressing the upstream concerns about its integration. === Issues === -dl

12 years, 3 months

1
0
0 0

[PATCH 0/2] cpustat: use atomic operations to read/update stats

by Kevin Hilman

On 64-bit platforms, reads/writes of the various cpustat fields are atomic due to native 64-bit loads/stores. However, on non 64-bit platforms, reads/writes of the cpustat fields are not atomic and could lead to inconsistent statistics. This problem was originally reported by Frederic Weisbecker as a 64-bit limitation with the nsec granularity cputime accounting for full dynticks, but then we realized that it's a problem that's been around for awhile and not specific to the new cputime accounting. This series fixes this by first converting all access to the cputime fields to use accessor functions, and then converting the accessor functions to use the atomic64 functions. Implemented based on idea proposed by Frederic Weisbecker. Kevin Hilman (2): cpustat: use accessor functions for get/set/add cpustat: convert to atomic operations arch/s390/appldata/appldata_os.c | 16 +++++++-------- drivers/cpufreq/cpufreq_governor.c | 18 ++++++++--------- drivers/cpufreq/cpufreq_ondemand.c | 2 +- drivers/macintosh/rack-meter.c | 6 +++--- fs/proc/stat.c | 40 +++++++++++++++++++------------------- fs/proc/uptime.c | 2 +- include/linux/kernel_stat.h | 11 ++++++++++- kernel/sched/core.c | 12 +++++------- kernel/sched/cputime.c | 29 +++++++++++++-------------- 9 files changed, 70 insertions(+), 66 deletions(-) -- 1.8.1.2

12 years, 3 months

7
24
0 0

[ACTIVITY] (Linus Walleij) 2013-02-11 - 2013-02-22

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Finalized a GPIO+pinctrl presentation for the Embedded Linux Conference, and presented on the first day of the conference. Slides will be posted. * Finalized the pinctrl tree before traveling, sent a pull request to Torvalds as soon as the merge window opened and he pulled it in. * AB8500 GPIO patches and all other cleanup has been merged up to the pinctrl and ARM SoC trees and pulled in by Torvalds. MFD is pending but Sam has sent a pull request for this part as well. * Other queued fixes for mach-ux500 and also the PCI regression fix has propagated upstream. * Reviewed misc GPIO, pinctrl and other patches, updated blueprints... === Plans === * Fix regressions popping up in the merge window. There are always such... * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Convert the Nomadik to multiplatform. * Convert Nomadik pinctrl driver to register GPIO ranges from the gpiochip side. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Get hands dirty with regmap. === Issues === * N/A Thanks, Linus Walleij

12 years, 3 months

1
0
0 0

[PATCH v2] arm: add check for global exclusive monitor

by Vladimir Murzin

Since ARMv6 new atomic instructions have been introduced: ldrex/strex. Several implementation are possible based on (1) global and local exclusive monitors and (2) local exclusive monitor and snoop unit. In case of the 2nd options exclusive store operation on uncached region may be faulty. Check for availability of global monitor to provide some hint about possible issues. Signed-off-by: Vladimir Murzin <murzin.v(a)gmail.com> --- Changes since v1: - Using L_PTE_MT_BUFFERABLE instead of L_PTE_MT_UNCACHABLE Thanks to Russell for ponting this silly error - added comment about how checking is done arch/arm/include/asm/bugs.h | 14 +++++++++-- arch/arm/mm/fault-armv.c | 55 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/bugs.h b/arch/arm/include/asm/bugs.h index a97f1ea..29d73cd 100644 --- a/arch/arm/include/asm/bugs.h +++ b/arch/arm/include/asm/bugs.h @@ -13,9 +13,19 @@ #ifdef CONFIG_MMU extern void check_writebuffer_bugs(void); -#define check_bugs() check_writebuffer_bugs() +#if __LINUX_ARM_ARCH__ < 6 +static void check_gmonitor_bugs(void) {}; #else -#define check_bugs() do { } while (0) +extern void check_gmonitor_bugs(void); +#endif + +static inline void check_bugs(void) +{ + check_writebuffer_bugs(); + check_gmonitor_bugs(); +} +#else +static inline void check_bugs(void) { } #endif #endif diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c index 2a5907b..6a1a07e 100644 --- a/arch/arm/mm/fault-armv.c +++ b/arch/arm/mm/fault-armv.c @@ -205,6 +205,61 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long addr, __flush_icache_all(); } } +#else +/* + * Check for the global exclusive monitor. The global monitor is a external + * transaction monitoring block for tracking exclusive accesses to sharable + * memory regions. LDREX/STREX rely on this monitor when accessing uncached + * shared memory. + * If global monitor is not implemented STREX operation on uncached shared + * memory region always fail, returning 0 in the destination register. + * We rely on this property to check whether global monitor is implemented + * or not. + * NB: The name of L_PTE_MT_BUFFERABLE is not for B bit, but for normal + * non-cacheable memory type (XXCB = 0001). + */ +void __init check_gmonitor_bugs(void) +{ + struct page *page; + const char *reason; + unsigned long res = 1; + + printk(KERN_INFO "CPU: Testing for global monitor: "); + + page = alloc_page(GFP_KERNEL); + if (page) { + unsigned long *p; + pgprot_t prot = __pgprot_modify(PAGE_KERNEL, + L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE); + + p = vmap(&page, 1, VM_IOREMAP, prot); + + if (p) { + int temp, res; + + __asm__ __volatile__( + "ldrex %1, [%2]\n" + "strex %0, %1, [%2]" + : "=&r" (res), "=&r" (temp) + : "r" (p) + : "cc", "memory"); + + reason = "n/a (atomic ops may be faulty)"; + } else { + reason = "unable to map memory\n"; + } + + vunmap(p); + put_page(page); + } else { + reason = "unable to grab page\n"; + } + + if (res) + printk("failed, %s\n", reason); + else + printk("ok\n"); +} #endif /* __LINUX_ARM_ARCH__ < 6 */ /* -- 1.7.10.4

12 years, 3 months

1
0
0 0

[PATCH] arm: add check for global exclusive monitor

by Vladimir Murzin

Thanks for review Russel! On Mon, Feb 18, 2013 at 04:44:20PM +0000, Russell King - ARM Linux wrote: > On Mon, Feb 18, 2013 at 08:26:50PM +0400, Vladimir Murzin wrote: > > Since ARMv6 new atomic instructions have been introduced: > > ldrex/strex. Several implementation are possible based on (1) global > > and local exclusive monitors and (2) local exclusive monitor and snoop > > unit. > > > > In case of the 2nd option exclusive store operation on uncached > > region may be faulty. > > > > Check for availability of the global monitor to provide some hint about > > possible issues. > > How does this code actually do that? According to DHT0008A_arm_synchronization_primitives.pdf the global monitor is introduce to track exclusive accesses to sharable memory regions. This article also says about some system-wide implication which should be taken into account: (1) for systems with coherency management (2) for systems without coherency management The first one lay on SCU, L1 data cache and local monitor. The second one requires implementation of global monitor if memory regions cannot be cached. It set up the behaviour for store-exclusive operations when global monitor is not available: these operations always fail. Taking all these into account we can guess about availability of global monitor by using store-exclusive operation on uncached memory region. > > > +void __init check_gmonitor_bugs(void) > > +{ > > + struct page *page; > > + const char *reason; > > + unsigned long res = 1; > > + > > + printk(KERN_INFO "CPU: Testing for global monitor: "); > > + > > + page = alloc_page(GFP_KERNEL); > > + if (page) { > > + unsigned long *p; > > + pgprot_t prot = __pgprot_modify(PAGE_KERNEL, > > + L_PTE_MT_MASK, L_PTE_MT_UNCACHED); > > + > > + p = vmap(&page, 1, VM_IOREMAP, prot); > > This is bad practise. Remapping a page of already mapped kernel memory > using different attributes (in this case, strongly ordered) is _definitely_ > a violation of the architecture requirements. The behaviour you will see > from this are in no way guaranteed. DDI0406C_arm_architecture_reference_manual.pdf (A3-131) says: A memory location can be marked as having different cacheability attributes, for example when using aliases in a virtual to physical address mapping: * if the attributes differ only in the cache allocation hint this does not affect the behavior of accesses to that location * for other cases see Mismatched memory attributes on page A3-136. Isn't L_PTE_MT_UNCACHED about cache allocation hint? > > If you want to do this, it must either come from highmem, or not already > be mapped. > > Moreover, this is absolutely silly - the ARM ARM says: > > "LDREX and STREX operations *must* be performed only on memory with the > Normal memory attribute." DDI0406C_arm_architecture_reference_manual.pdf (A3-121) says: It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be performed to a memory region with the Device or Strongly-ordered memory attribute. Unless the implementation documentation explicitly states that LDREX and STREX operations to a memory region with the Device or Strongly-ordered attribute are permitted, the effect of such operations is UNPREDICTABLE. At least it allows to perform operations on memory region with the Strongly-ordered attribute... but still unpredictable. > > L_PTE_MT_UNCACHED doesn't get you that. As I say above, that gets you > strongly ordered memory, not "normal memory" as required by the > architecture for use with exclusive types. > > > + > > + if (p) { > > + int temp; > > + > > + __asm__ __volatile__( \ > > + "ldrex %1, [%2]\n" \ > > + "strex %0, %1, [%2]" \ > > + : "=&r" (res), "=&r" (temp) \ > > + : "r" (p) \ > > \ character not required for any of the above. Neither is the __ version > of "asm" and "volatile". Thanks. > > > + : "cc", "memory"); > > + > > + reason = "n\\a (atomic ops may be faulty)"; > > "n\\a" ? "not detected"? > So... at the moment this has me wondering - you're testing atomic > operations with a strongly ordered memory region, which ARM already > define this to be outside of the architecture spec. The behaviour you > see is not defined architecturally. > > And if you're trying to use LDREX/STREX to a strongly ordered or device > memory region, then you're quite right that it'll be unreliable. It's > not defined to even work. That's not because they're faulty, it's because > you're abusing them. However, IRL it is not hard to meet this undefined difference. At least I'm able to see it on Tegra2 Harmony and Pandaboard. Moreover, demand on Normal memory attribute breaks up ability to turn caches off. In this case we are not able to boot the system up (seen on Tegra2 harmony). This patch is aimed to highlight the difference in implementation. That's why it has some softering in guessing about faulty. Might be it worth warning about unpredictable effect instead? Best wishes Vladimir

12 years, 3 months

2
2
0 0

13.1 Versatile Express kernel spewing lock warnings

by Eric Van Hensbergen

I was trying out the new linaro binary image for 13.1 on my TC2 and am getting lock warnings on my console. Should I be worried or is this expected behavior? ----- [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.8.0-1-linaro-vexpress (buildd@wani10) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #1ubuntu1~ci+130125174543-Ubuntu SMP Sat Jan 26 00:47:35 UTC 201 ... [ 602.909859] [ 602.909864] ====================================================== [ 602.909868] [ INFO: possible circular locking dependency detected ] [ 602.909877] 3.8.0-1-linaro-vexpress #1ubuntu1~ci+130125174543-Ubuntu Not tainted [ 602.909881] ------------------------------------------------------- [ 602.909887] kworker/0:1/376 is trying to acquire lock: [ 602.909922] ((fb_notifier_list).rwsem){.+.+.+}, at: [<c00385b9>] __blocking_notifier_call_chain+0x1d/0x40 [ 602.909926] [ 602.909926] but task is already holding lock: [ 602.909953] (console_lock){+.+.+.}, at: [<c0285103>] console_callback+0xf/0xe0 [ 602.909957] [ 602.909957] which lock already depends on the new lock. [ 602.909957] [ 602.909960] [ 602.909960] the existing dependency chain (in reverse order) is: [ 602.909976] [ 602.909976] -> #1 (console_lock){+.+.+.}: [ 602.909994] [<c005b041>] __lock_acquire+0x29d/0x858 [ 602.910010] [<c005b93f>] lock_acquire+0x5f/0xbc [ 602.910027] [<c001d2f5>] console_lock+0x31/0x40 [ 602.910041] [<c028350f>] register_con_driver+0x27/0xe8 [ 602.910054] [<c0283ded>] take_over_console+0x19/0x240 [ 602.910071] [<c0269263>] fbcon_takeover+0x3b/0x88 [ 602.910083] [<c00383ed>] notifier_call_chain+0x45/0x54 [ 602.910097] [<c00385cb>] __blocking_notifier_call_chain+0x2f/0x40 [ 602.910110] [<c00385f3>] blocking_notifier_call_chain+0x17/0x1c [ 602.910123] [<c0265d35>] register_framebuffer+0x109/0x1cc [ 602.910135] [<c026fdbb>] hdlcd_probe+0x507/0x5d0 [ 602.910148] [<c02909d3>] platform_drv_probe+0x17/0x18 [ 602.910159] [<c028fd49>] driver_probe_device+0x51/0x170 [ 602.910169] [<c028febf>] __driver_attach+0x57/0x58 [ 602.910185] [<c028ec9b>] bus_for_each_dev+0x2b/0x4c [ 602.910195] [<c028f7dd>] bus_add_driver+0xe5/0x170 [ 602.910206] [<c02901ef>] driver_register+0x43/0xd0 [ 602.910218] [<c0008511>] do_one_initcall+0xc9/0x114 [ 602.910231] [<c03d5ceb>] kernel_init+0xcf/0x1ec [ 602.910245] [<c000ce95>] ret_from_fork+0x11/0x20 [ 602.910261] [ 602.910261] -> #0 ((fb_notifier_list).rwsem){.+.+.+}: [ 602.910274] [<c005a799>] validate_chain.isra.26+0xafd/0xbe4 [ 602.910288] [<c005b041>] __lock_acquire+0x29d/0x858 [ 602.910301] [<c005b93f>] lock_acquire+0x5f/0xbc [ 602.910316] [<c03dfe8d>] down_read+0x25/0x30 [ 602.910329] [<c00385b9>] __blocking_notifier_call_chain+0x1d/0x40 [ 602.910342] [<c00385f3>] blocking_notifier_call_chain+0x17/0x1c [ 602.910354] [<c0264e7d>] fb_blank+0x29/0x64 [ 602.910364] [<c026a859>] fbcon_blank+0x135/0x1ac [ 602.910377] [<c0283471>] do_blank_screen+0x109/0x180 [ 602.910391] [<c028513d>] console_callback+0x49/0xe0 [ 602.910402] [<c00304a1>] process_one_work+0x12d/0x3c4 [ 602.910413] [<c00309a7>] worker_thread+0x117/0x344 [ 602.910426] [<c0033dd3>] kthread+0x77/0x84 [ 602.910439] [<c000ce95>] ret_from_fork+0x11/0x20 [ 602.910443] [ 602.910443] other info that might help us debug this: [ 602.910443] [ 602.910446] Possible unsafe locking scenario: [ 602.910446] [ 602.910450] CPU0 CPU1 [ 602.910453] ---- ---- [ 602.910463] lock(console_lock); [ 602.910472] lock((fb_notifier_list).rwsem); [ 602.910481] lock(console_lock); [ 602.910489] lock((fb_notifier_list).rwsem); [ 602.910493] [ 602.910493] *** DEADLOCK *** [ 602.910493] [ 602.910499] 3 locks held by kworker/0:1/376: [ 602.910523] #0: (events){.+.+.+}, at: [<c003044e>] process_one_work+0xda/0x3c4 [ 602.910546] #1: (console_work){+.+...}, at: [<c003044e>] process_one_work+0xda/0x3c4 [ 602.910572] #2: (console_lock){+.+.+.}, at: [<c0285103>] console_callback+0xf/0xe0 [ 602.910575] [ 602.910575] stack backtrace: [ 602.910596] [<c0011fd1>] (unwind_backtrace+0x1/0x9c) from [<c03da9cb>] (print_circular_bug+0x1a7/0x1f0) [ 602.910614] [<c03da9cb>] (print_circular_bug+0x1a7/0x1f0) from [<c005a799>] (validate_chain.isra.26+0xafd/0xbe4) [ 602.910632] [<c005a799>] (validate_chain.isra.26+0xafd/0xbe4) from [<c005b041>] (__lock_acquire+0x29d/0x858) [ 602.910649] [<c005b041>] (__lock_acquire+0x29d/0x858) from [<c005b93f>] (lock_acquire+0x5f/0xbc) [ 602.910665] [<c005b93f>] (lock_acquire+0x5f/0xbc) from [<c03dfe8d>] (down_read+0x25/0x30) [ 602.910683] [<c03dfe8d>] (down_read+0x25/0x30) from [<c00385b9>] (__blocking_notifier_call_chain+0x1d/0x40) [ 602.910701] [<c00385b9>] (__blocking_notifier_call_chain+0x1d/0x40) from [<c00385f3>] (blocking_notifier_call_chain+0x17/0x1c) [ 602.910718] [<c00385f3>] (blocking_notifier_call_chain+0x17/0x1c) from [<c0264e7d>] (fb_blank+0x29/0x64) [ 602.910732] [<c0264e7d>] (fb_blank+0x29/0x64) from [<c026a859>] (fbcon_blank+0x135/0x1ac) [ 602.910746] [<c026a859>] (fbcon_blank+0x135/0x1ac) from [<c0283471>] (do_blank_screen+0x109/0x180) [ 602.910764] [<c0283471>] (do_blank_screen+0x109/0x180) from [<c028513d>] (console_callback+0x49/0xe0) [ 602.910780] [<c028513d>] (console_callback+0x49/0xe0) from [<c00304a1>] (process_one_work+0x12d/0x3c4) [ 602.910793] [<c00304a1>] (process_one_work+0x12d/0x3c4) from [<c00309a7>] (worker_thread+0x117/0x344) [ 602.910808] [<c00309a7>] (worker_thread+0x117/0x344) from [<c0033dd3>] (kthread+0x77/0x84) [ 602.910825] [<c0033dd3>] (kthread+0x77/0x84) from [<c000ce95>] (ret_from_fork+0x11/0x20)

12 years, 3 months

2
1
0 0

Re: [PATCH v3 2/3] ab8500: make res_to_temp tables public

by Hongbo Zhang

On 22 February 2013 08:49, Guenter Roeck <linux(a)roeck-us.net> wrote: > On Thu, Feb 21, 2013 at 02:24:23PM -0800, Anton Vorontsov wrote: >> On Thu, Feb 21, 2013 at 06:32:40PM +0800, Hongbo Zhang wrote: >> > These NTC resistance to temperature tables should be public, so others such as >> > ab8500 hwmon driver can look up these tables to convert NTC resistance to >> > temperature. >> > >> > Signed-off-by: Hongbo Zhang <hongbo.zhang(a)linaro.org> >> > --- >> >> For 1/3 and 2/3 patches: >> >> Acked-by: Anton Vorontsov <anton(a)enomsg.org> >> >> (Do you need EXPORT_SYMBOL()? You don't use this from modules?) >> > I would think so. Also, the variables should be exported through an include > file. > I have these two lines in drivers/hwmon/ab8500.h, extern struct abx500_res_to_temp temp_tbl_A_thermistor[]; extern int temp_tbl_A_size; Do you mean this? Or do you mean we should create a public header file holding all the tables? Where to place these tables really baffled me, if the current hwmon driver is acceptable, I will talk to the ab8500_bmdata.c author to discuss how to re-arrange all the tables, that should be another patch in future if possible. > The variable names are quite generic for global variables; we need to find > something more specific/descriptive. > I noticed this too, this original naming isn't so good, there are also other names like this. I will rename these two tables I am using this time. > There is also some overlap with functionality in drivers/hwmon/ntc_thermistor.c. > Wonder if it would be possible to unify the code. > It seems not so easy to unify the code for me, if necessary and possible, that should be another dedicated patch I think. > Guenter > >> Thanks. >> >> > drivers/power/ab8500_bmdata.c | 8 ++++++-- >> > 1 file changed, 6 insertions(+), 2 deletions(-) >> > >> > diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c >> > index f034ae4..53f3324 100644 >> > --- a/drivers/power/ab8500_bmdata.c >> > +++ b/drivers/power/ab8500_bmdata.c >> > @@ -11,7 +11,7 @@ >> > * Note that the res_to_temp table must be strictly sorted by falling resistance >> > * values to work. >> > */ >> > -static struct abx500_res_to_temp temp_tbl_A_thermistor[] = { >> > +struct abx500_res_to_temp temp_tbl_A_thermistor[] = { >> > {-5, 53407}, >> > { 0, 48594}, >> > { 5, 43804}, >> > @@ -29,7 +29,9 @@ static struct abx500_res_to_temp temp_tbl_A_thermistor[] = { >> > {65, 12500}, >> > }; >> > >> > -static struct abx500_res_to_temp temp_tbl_B_thermistor[] = { >> > +int temp_tbl_A_size = ARRAY_SIZE(temp_tbl_A_thermistor); >> > + >> > +struct abx500_res_to_temp temp_tbl_B_thermistor[] = { >> > {-5, 200000}, >> > { 0, 159024}, >> > { 5, 151921}, >> > @@ -47,6 +49,8 @@ static struct abx500_res_to_temp temp_tbl_B_thermistor[] = { >> > {65, 82869}, >> > }; >> > >> > +int temp_tbl_B_size = ARRAY_SIZE(temp_tbl_B_thermistor); >> > + >> > static struct abx500_v_to_cap cap_tbl_A_thermistor[] = { >> > {4171, 100}, >> > {4114, 95}, >> > -- >> > 1.8.0 >>

12 years, 3 months

2
1
0 0

[PATCH v2] memcg: Add memory.pressure_level events

by Anton Vorontsov

With this patch userland applications that want to maintain the interactivity/memory allocation cost can use the pressure level notifications. The levels are defined like this: The "low" level means that the system is reclaiming memory for new allocations. Monitoring this reclaiming activity might be useful for maintaining cache level. Upon notification, the program (typically "Activity Manager") might analyze vmstat and act in advance (i.e. prematurely shutdown unimportant services). The "medium" level means that the system is experiencing medium memory pressure, the system might be making swap, paging out active file caches, etc. Upon this event applications may decide to further analyze vmstat/zoneinfo/memcg or internal memory usage statistics and free any resources that can be easily reconstructed or re-read from a disk. The "critical" level means that the system is actively thrashing, it is about to out of memory (OOM) or even the in-kernel OOM killer is on its way to trigger. Applications should do whatever they can to help the system. It might be too late to consult with vmstat or any other statistics, so it's advisable to take an immediate action. The events are propagated upward until the event is handled, i.e. the events are not pass-through. Here is what this means: for example you have three cgroups: A->B->C. Now you set up an event listener on cgroups A, B and C, and suppose group C experiences some pressure. In this situation, only group C will receive the notification, i.e. groups A and B will not receive it. This is done to avoid excessive "broadcasting" of messages, which disturbs the system and which is especially bad if we are low on memory or thrashing. So, organize the cgroups wisely, or propagate the events manually (or, ask us to implement the pass-through events, explaining why would you need them.) Signed-off-by: Anton Vorontsov <anton.vorontsov(a)linaro.org> Acked-by: Kirill A. Shutemov <kirill(a)shutemov.name> --- Hi all, Many thanks for the previous reviews! In this revision: - Addressed Glauber Costa's comments: o Use parent_mem_cgroup() instead of own parent function (also suggested by Kamezawa). This change also affected events distribution logic, so it became more like memory thresholds notifications, i.e. we deliver the event to the cgroup where the event originated, not to the parent cgroup; (This also addreses Kamezawa's remark regarding which cgroup receives which event.) o Register vmpressure cgroup file directly in memcontrol.c. - Addressed Greg Thelen's comments: o Fixed bool/int inconsistency in the code; o Fixed nr_scanned accounting; o Don't use cryptic 's', 'r' abbreviations; get rid of confusing 'window' argument. - Addressed Kamezawa Hiroyuki's comments: o Moved declarations from mm/internal.h into linux/vmpressue.h; o Removed Kconfig symbol. Vmpressure is pretty lightweight (especially comparing to the memcg accounting). If it ever causes any measurable performance effect, we want to fix it, not paper it over with a Kconfig option. :-) o Removed read operation on pressure_level cgroup file. In apps, we only use notifications, we don't need the content of the file, so let's keep things simple for now. Plus this resolves questions like what should we return there when the system is not reclaiming; o Reworded documentation; o Improved comments for vmpressure_prio(). Old changelogs/submissions: v1: http://lkml.org/lkml/2013/2/10/140 mempressure cgroup: http://lkml.org/lkml/2013/1/4/55 Thanks! Anton Documentation/cgroups/memory.txt | 61 +++++++++- include/linux/vmpressure.h | 47 ++++++++ mm/Makefile | 2 +- mm/memcontrol.c | 28 +++++ mm/vmpressure.c | 252 +++++++++++++++++++++++++++++++++++++++ mm/vmscan.c | 8 ++ 6 files changed, 396 insertions(+), 2 deletions(-) create mode 100644 include/linux/vmpressure.h create mode 100644 mm/vmpressure.c diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index addb1f1..0c004de 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -40,6 +40,7 @@ Features: - soft limit - moving (recharging) account at moving a task is selectable. - usage threshold notifier + - memory pressure notifier - oom-killer disable knob and oom-notifier - Root cgroup has no limit controls. @@ -65,6 +66,7 @@ Brief summary of control files. memory.stat # show various statistics memory.use_hierarchy # set/show hierarchical account enabled memory.force_empty # trigger forced move charge to parent + memory.pressure_level # set memory pressure notifications memory.swappiness # set/show swappiness parameter of vmscan (See sysctl's vm.swappiness) memory.move_charge_at_immigrate # set/show controls of moving charges @@ -778,7 +780,64 @@ At reading, current status of OOM is shown. under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may be stopped.) -11. TODO +11. Memory Pressure + +The pressure level notifications can be used to monitor the memory +allocation cost; based on the pressure, applications can implement +different strategies of managing their memory resources. The pressure +levels are defined as following: + +The "low" level means that the system is reclaiming memory for new +allocations. Monitoring this reclaiming activity might be useful for +maintaining cache level. Upon notification, the program (typically +"Activity Manager") might analyze vmstat and act in advance (i.e. +prematurely shutdown unimportant services). + +The "medium" level means that the system is experiencing medium memory +pressure, the system might be making swap, paging out active file caches, +etc. Upon this event applications may decide to further analyze +vmstat/zoneinfo/memcg or internal memory usage statistics and free any +resources that can be easily reconstructed or re-read from a disk. + +The "critical" level means that the system is actively thrashing, it is +about to out of memory (OOM) or even the in-kernel OOM killer is on its +way to trigger. Applications should do whatever they can to help the +system. It might be too late to consult with vmstat or any other +statistics, so it's advisable to take an immediate action. + +The events are propagated upward until the event is handled, i.e. the +events are not pass-through. Here is what this means: for example you have +three cgroups: A->B->C. Now you set up an event listener on cgroups A, B +and C, and suppose group C experiences some pressure. In this situation, +only group C will receive the notification, i.e. groups A and B will not +receive it. This is done to avoid excessive "broadcasting" of messages, +which disturbs the system and which is especially bad if we are low on +memory or thrashing. So, organize the cgroups wisely, or propagate the +events manually (or, ask us to implement the pass-through events, +explaining why would you need them.) + +The file memory.pressure_level is only used to setup an eventfd, +read/write operations are no implemented. + +Test: + + Here is a small script example that makes a new cgroup, sets up a + memory limit, sets up a notification in the cgroup and then makes child + cgroup experience a critical pressure: + + # cd /sys/fs/cgroup/memory/ + # mkdir foo + # cd foo + # cgroup_event_listener memory.pressure_level low & + # echo 8000000 > memory.limit_in_bytes + # echo 8000000 > memory.memsw.limit_in_bytes + # echo $$ > tasks + # dd if=/dev/zero | read x + + (Expect a bunch of notifications, and eventually, the oom-killer will + trigger.) + +12. TODO 1. Add support for accounting huge pages (as a separate controller) 2. Make per-cgroup scanner reclaim not-shared pages first diff --git a/include/linux/vmpressure.h b/include/linux/vmpressure.h new file mode 100644 index 0000000..fa84783 --- /dev/null +++ b/include/linux/vmpressure.h @@ -0,0 +1,47 @@ +#ifndef __LINUX_VMPRESSURE_H +#define __LINUX_VMPRESSURE_H + +#include <linux/mutex.h> +#include <linux/list.h> +#include <linux/workqueue.h> +#include <linux/gfp.h> +#include <linux/types.h> +#include <linux/cgroup.h> + +struct vmpressure { + unsigned int scanned; + unsigned int reclaimed; + /* The lock is used to keep the scanned/reclaimed above in sync. */ + struct mutex sr_lock; + + struct list_head events; + /* Have to grab the lock on events traversal or modifications. */ + struct mutex events_lock; + + struct work_struct work; +}; + +struct mem_cgroup; + +#ifdef CONFIG_MEMCG +extern void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, + unsigned long scanned, unsigned long reclaimed); +extern void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio); +#else +static inline void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, + unsigned long scanned, unsigned long reclaimed) {} +static inline void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, + int prio) {} +#endif /* CONFIG_MEMCG */ + +extern void vmpressure_init(struct vmpressure *vmpr); +extern struct vmpressure *memcg_to_vmpr(struct mem_cgroup *memcg); +extern struct cgroup_subsys_state *vmpr_to_css(struct vmpressure *vmpr); +extern struct vmpressure *css_to_vmpr(struct cgroup_subsys_state *css); +extern int vmpressure_register_event(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd, + const char *args); +extern void vmpressure_unregister_event(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd); + +#endif /* __LINUX_VMPRESSURE_H */ diff --git a/mm/Makefile b/mm/Makefile index 3a46287..72c5acb 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -50,7 +50,7 @@ obj-$(CONFIG_FS_XIP) += filemap_xip.o obj-$(CONFIG_MIGRATION) += migrate.o obj-$(CONFIG_QUICKLIST) += quicklist.o obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o -obj-$(CONFIG_MEMCG) += memcontrol.o page_cgroup.o +obj-$(CONFIG_MEMCG) += memcontrol.o page_cgroup.o vmpressure.o obj-$(CONFIG_CGROUP_HUGETLB) += hugetlb_cgroup.o obj-$(CONFIG_MEMORY_FAILURE) += memory-failure.o obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 25ac5f4..b41727b 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -49,6 +49,7 @@ #include <linux/fs.h> #include <linux/seq_file.h> #include <linux/vmalloc.h> +#include <linux/vmpressure.h> #include <linux/mm_inline.h> #include <linux/page_cgroup.h> #include <linux/cpu.h> @@ -370,6 +371,9 @@ struct mem_cgroup { atomic_t numainfo_events; atomic_t numainfo_updating; #endif + + struct vmpressure vmpr; + /* * Per cgroup active and inactive list, similar to the * per zone LRU lists. @@ -570,6 +574,24 @@ struct mem_cgroup *mem_cgroup_from_css(struct cgroup_subsys_state *s) return container_of(s, struct mem_cgroup, css); } +/* Some nice accessors for the vmpressure. */ +struct vmpressure *memcg_to_vmpr(struct mem_cgroup *memcg) +{ + if (!memcg) + memcg = root_mem_cgroup; + return &memcg->vmpr; +} + +struct cgroup_subsys_state *vmpr_to_css(struct vmpressure *vmpr) +{ + return &container_of(vmpr, struct mem_cgroup, vmpr)->css; +} + +struct vmpressure *css_to_vmpr(struct cgroup_subsys_state *css) +{ + return &mem_cgroup_from_css(css)->vmpr; +} + static inline bool mem_cgroup_is_root(struct mem_cgroup *memcg) { return (memcg == root_mem_cgroup); @@ -6000,6 +6022,11 @@ static struct cftype mem_cgroup_files[] = { .unregister_event = mem_cgroup_oom_unregister_event, .private = MEMFILE_PRIVATE(_OOM_TYPE, OOM_CONTROL), }, + { + .name = "pressure_level", + .register_event = vmpressure_register_event, + .unregister_event = vmpressure_unregister_event, + }, #ifdef CONFIG_NUMA { .name = "numa_stat", @@ -6291,6 +6318,7 @@ mem_cgroup_css_alloc(struct cgroup *cont) memcg->move_charge_at_immigrate = 0; mutex_init(&memcg->thresholds_lock); spin_lock_init(&memcg->move_lock); + vmpressure_init(&memcg->vmpr); return &memcg->css; diff --git a/mm/vmpressure.c b/mm/vmpressure.c new file mode 100644 index 0000000..ae0ff8e --- /dev/null +++ b/mm/vmpressure.c @@ -0,0 +1,252 @@ +/* + * Linux VM pressure + * + * Copyright 2012 Linaro Ltd. + * Anton Vorontsov <anton.vorontsov(a)linaro.org> + * + * Based on ideas from Andrew Morton, David Rientjes, KOSAKI Motohiro, + * Leonid Moiseichuk, Mel Gorman, Minchan Kim and Pekka Enberg. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include <linux/cgroup.h> +#include <linux/fs.h> +#include <linux/sched.h> +#include <linux/mm.h> +#include <linux/vmstat.h> +#include <linux/eventfd.h> +#include <linux/swap.h> +#include <linux/printk.h> +#include <linux/vmpressure.h> + +/* + * The window size is the number of scanned pages before we try to analyze + * the scanned/reclaimed ratio (or difference). + * + * It is used as a rate-limit tunable for the "low" level notification, + * and for averaging medium/critical levels. Using small window sizes can + * cause lot of false positives, but too big window size will delay the + * notifications. + * + * TODO: Make the window size depend on machine size, as we do for vmstat + * thresholds. + */ +static const unsigned int vmpressure_win = SWAP_CLUSTER_MAX * 16; +static const unsigned int vmpressure_level_med = 60; +static const unsigned int vmpressure_level_critical = 95; +static const unsigned int vmpressure_level_critical_prio = 3; + +enum vmpressure_levels { + VMPRESSURE_LOW = 0, + VMPRESSURE_MEDIUM, + VMPRESSURE_CRITICAL, + VMPRESSURE_NUM_LEVELS, +}; + +static const char *vmpressure_str_levels[] = { + [VMPRESSURE_LOW] = "low", + [VMPRESSURE_MEDIUM] = "medium", + [VMPRESSURE_CRITICAL] = "critical", +}; + +static enum vmpressure_levels vmpressure_level(unsigned int pressure) +{ + if (pressure >= vmpressure_level_critical) + return VMPRESSURE_CRITICAL; + else if (pressure >= vmpressure_level_med) + return VMPRESSURE_MEDIUM; + return VMPRESSURE_LOW; +} + +static enum vmpressure_levels vmpressure_calc_level(unsigned int scanned, + unsigned int reclaimed) +{ + unsigned long scale = scanned + reclaimed; + unsigned long pressure; + + if (!scanned) + return VMPRESSURE_LOW; + + /* + * We calculate the ratio (in percents) of how many pages were + * scanned vs. reclaimed in a given time frame (window). Note that + * time is in VM reclaimer's "ticks", i.e. number of pages + * scanned. This makes it possible to set desired reaction time + * and serves as a ratelimit. + */ + pressure = scale - (reclaimed * scale / scanned); + pressure = pressure * 100 / scale; + + pr_debug("%s: %3lu (s: %6u r: %6u)\n", __func__, pressure, + scanned, reclaimed); + + return vmpressure_level(pressure); +} + +void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, + unsigned long scanned, unsigned long reclaimed) +{ + struct vmpressure *vmpr = memcg_to_vmpr(memcg); + + /* + * So far we are only interested application memory, or, in case + * of low pressure, in FS/IO memory reclaim. We are also + * interested indirect reclaim (kswapd sets sc->gfp_mask to + * GFP_KERNEL). + */ + if (!(gfp & (__GFP_HIGHMEM | __GFP_MOVABLE | __GFP_IO | __GFP_FS))) + return; + + if (!scanned) + return; + + mutex_lock(&vmpr->sr_lock); + vmpr->scanned += scanned; + vmpr->reclaimed += reclaimed; + mutex_unlock(&vmpr->sr_lock); + + if (scanned < vmpressure_win || work_pending(&vmpr->work)) + return; + schedule_work(&vmpr->work); +} + +void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio) +{ + if (prio > vmpressure_level_critical_prio) + return; + + /* + * OK, the prio is below the threshold, updating vmpressure + * information before diving into long shrinking of long range + * vmscan. + */ + vmpressure(gfp, memcg, vmpressure_win, 0); +} + +static struct vmpressure *wk_to_vmpr(struct work_struct *wk) +{ + return container_of(wk, struct vmpressure, work); +} + +static struct vmpressure *cg_to_vmpr(struct cgroup *cg) +{ + return css_to_vmpr(cgroup_subsys_state(cg, mem_cgroup_subsys_id)); +} + +struct vmpressure_event { + struct eventfd_ctx *efd; + enum vmpressure_levels level; + struct list_head node; +}; + +static bool vmpressure_event(struct vmpressure *vmpr, + unsigned long scanned, unsigned long reclaimed) +{ + struct vmpressure_event *ev; + int level = vmpressure_calc_level(scanned, reclaimed); + bool signalled = false; + + mutex_lock(&vmpr->events_lock); + + list_for_each_entry(ev, &vmpr->events, node) { + if (level >= ev->level) { + eventfd_signal(ev->efd, 1); + signalled = true; + } + } + + mutex_unlock(&vmpr->events_lock); + + return signalled; +} + +static struct vmpressure *vmpressure_parent(struct vmpressure *vmpr) +{ + struct cgroup *cg = vmpr_to_css(vmpr)->cgroup; + struct mem_cgroup *memcg = mem_cgroup_from_cont(cg); + + memcg = parent_mem_cgroup(memcg); + if (!memcg) + return NULL; + return memcg_to_vmpr(memcg); +} + +static void vmpressure_wk_fn(struct work_struct *wk) +{ + struct vmpressure *vmpr = wk_to_vmpr(wk); + unsigned long s; + unsigned long r; + + mutex_lock(&vmpr->sr_lock); + s = vmpr->scanned; + r = vmpr->reclaimed; + vmpr->scanned = 0; + vmpr->reclaimed = 0; + mutex_unlock(&vmpr->sr_lock); + + do { + if (vmpressure_event(vmpr, s, r)) + break; + /* + * If not handled, propagate the event upward into the + * hierarchy. + */ + } while ((vmpr = vmpressure_parent(vmpr))); +} + +int vmpressure_register_event(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd, const char *args) +{ + struct vmpressure *vmpr = cg_to_vmpr(cg); + struct vmpressure_event *ev; + int lvl; + + for (lvl = 0; lvl < VMPRESSURE_NUM_LEVELS; lvl++) { + if (!strcmp(vmpressure_str_levels[lvl], args)) + break; + } + + if (lvl >= VMPRESSURE_NUM_LEVELS) + return -EINVAL; + + ev = kzalloc(sizeof(*ev), GFP_KERNEL); + if (!ev) + return -ENOMEM; + + ev->efd = eventfd; + ev->level = lvl; + + mutex_lock(&vmpr->events_lock); + list_add(&ev->node, &vmpr->events); + mutex_unlock(&vmpr->events_lock); + + return 0; +} + +void vmpressure_unregister_event(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd) +{ + struct vmpressure *vmpr = cg_to_vmpr(cg); + struct vmpressure_event *ev; + + mutex_lock(&vmpr->events_lock); + list_for_each_entry(ev, &vmpr->events, node) { + if (ev->efd != eventfd) + continue; + list_del(&ev->node); + kfree(ev); + break; + } + mutex_unlock(&vmpr->events_lock); +} + +void vmpressure_init(struct vmpressure *vmpr) +{ + mutex_init(&vmpr->sr_lock); + mutex_init(&vmpr->events_lock); + INIT_LIST_HEAD(&vmpr->events); + INIT_WORK(&vmpr->work, vmpressure_wk_fn); +} diff --git a/mm/vmscan.c b/mm/vmscan.c index 88c5fed..9530777 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -19,6 +19,7 @@ #include <linux/pagemap.h> #include <linux/init.h> #include <linux/highmem.h> +#include <linux/vmpressure.h> #include <linux/vmstat.h> #include <linux/file.h> #include <linux/writeback.h> @@ -1982,6 +1983,11 @@ static void shrink_zone(struct zone *zone, struct scan_control *sc) } memcg = mem_cgroup_iter(root, memcg, &reclaim); } while (memcg); + + vmpressure(sc->gfp_mask, sc->target_mem_cgroup, + sc->nr_scanned - nr_scanned, + sc->nr_reclaimed - nr_reclaimed); + } while (should_continue_reclaim(zone, sc->nr_reclaimed - nr_reclaimed, sc->nr_scanned - nr_scanned, sc)); } @@ -2167,6 +2173,8 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, count_vm_event(ALLOCSTALL); do { + vmpressure_prio(sc->gfp_mask, sc->target_mem_cgroup, + sc->priority); sc->nr_scanned = 0; aborted_reclaim = shrink_zones(zonelist, sc); -- 1.8.1.1

12 years, 3 months

4
6
0 0

Re: [PATCH v3 2/3] ab8500: make res_to_temp tables public

by Hongbo Zhang

On 22 February 2013 06:24, Anton Vorontsov <anton(a)enomsg.org> wrote: > On Thu, Feb 21, 2013 at 06:32:40PM +0800, Hongbo Zhang wrote: >> These NTC resistance to temperature tables should be public, so others such as >> ab8500 hwmon driver can look up these tables to convert NTC resistance to >> temperature. >> >> Signed-off-by: Hongbo Zhang <hongbo.zhang(a)linaro.org> >> --- > > For 1/3 and 2/3 patches: > > Acked-by: Anton Vorontsov <anton(a)enomsg.org> > > (Do you need EXPORT_SYMBOL()? You don't use this from modules?) Thanks, will export them. > > Thanks. > >> drivers/power/ab8500_bmdata.c | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/power/ab8500_bmdata.c b/drivers/power/ab8500_bmdata.c >> index f034ae4..53f3324 100644 >> --- a/drivers/power/ab8500_bmdata.c >> +++ b/drivers/power/ab8500_bmdata.c >> @@ -11,7 +11,7 @@ >> * Note that the res_to_temp table must be strictly sorted by falling resistance >> * values to work. >> */ >> -static struct abx500_res_to_temp temp_tbl_A_thermistor[] = { >> +struct abx500_res_to_temp temp_tbl_A_thermistor[] = { >> {-5, 53407}, >> { 0, 48594}, >> { 5, 43804}, >> @@ -29,7 +29,9 @@ static struct abx500_res_to_temp temp_tbl_A_thermistor[] = { >> {65, 12500}, >> }; >> >> -static struct abx500_res_to_temp temp_tbl_B_thermistor[] = { >> +int temp_tbl_A_size = ARRAY_SIZE(temp_tbl_A_thermistor); >> + >> +struct abx500_res_to_temp temp_tbl_B_thermistor[] = { >> {-5, 200000}, >> { 0, 159024}, >> { 5, 151921}, >> @@ -47,6 +49,8 @@ static struct abx500_res_to_temp temp_tbl_B_thermistor[] = { >> {65, 82869}, >> }; >> >> +int temp_tbl_B_size = ARRAY_SIZE(temp_tbl_B_thermistor); >> + >> static struct abx500_v_to_cap cap_tbl_A_thermistor[] = { >> {4171, 100}, >> {4114, 95}, >> -- >> 1.8.0

12 years, 3 months

1
0
0 0

What does the PG_swapbacked of page flags actually mean?

by common An

PG_swapbacked is a bit for page->flags. In kernel code, its comment is "page is backed by RAM/swap". But I couldn't understand it. 1. Does the RAM mean DRAM? How page is backed by RAM? 2. When the page is page-out to swap file, the bit PG_swapbacked will be set to demonstrate this page is backed by swap. Is it right? 3. In general, when will call SetPageSwapBacked() to set the bit? Could anybody kindly explain for me? Thanks very much.

12 years, 3 months

1
1
0 0

No section mismatch warnings for Thumb2 kernels

by Jon Medhurst (Tixy)

After some time investigating why I wasn't seeing some kernel section mismatch errors that someone else was seeing, I found the cause was that in Linaro we build Thumb2 kernels in the main, and modpost.c doesn't have support for any of the Thumb relocation types in addend_arm_rel(). I thought I would spread this knowledge, because lack of section mismatch warnings means we might miss some nasty bugs when developing code. If this is old news, then sorry for the noise. -- Tixy

12 years, 3 months

2
2
0 0

[Query]: Regmap v3.8: Compilation Warning: regmap_read_debugfs()

by Viresh Kumar

Hi Mark, I am getting compilation warning while compiling v3.8 commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 Author: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Mon Feb 18 15:58:34 2013 -0800 Linux 3.8 Warning: CC drivers/base/regmap/regmap-debugfs.o drivers/base/regmap/regmap-debugfs.c: In function ‘regmap_read_debugfs’: drivers/base/regmap/regmap-debugfs.c:180:9: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized] I am unable to understand why this warning is coming and that too on line 180 (as that doesn't use this variable). I can't see how this variable is used uninitialized. Toolchain i used: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.7-2012.12-20121214 - Linaro GCC 2012.12) 4.7.3 20121205 (prerelease) -- viresh

12 years, 3 months

2
1
0 0

[ACTIVITY] (David Long) 2013-02-11 - 2013-02-15

by David Long

=== David Long === === Travel/Time Off === * Monday February 18th (U.S. Washington's Birthday, aka President's Day) === Highlights === Coming up to speed on process. * Studied the history and content of Rabin Vincent's ARM uprobe kernel patch. It does a good job of integrating with existing kprobe instruction interpretation code. * Upleveled the uprobe patch to 3.7 (for now) and booted on 4460 Panda. I am experimenting with it to verify basic correct operation. * Sent email to Rabin on the topic of assisting in getting this patch upstreamed. === Plans === * Once basic functionality is veriried uplevel the patch to 3.8 and complete testing (especially as regards Thumb). * Determine if it is possible to work with the patch originator, or push for this patch independently. === Issues === * Eventually I will need hardware other than Panda for testing. For now Panda works well enough, and QEMU is (theoretically) an option. -dl

12 years, 3 months

2
3
0 0

[PATCH] arm: add check for global exclusive monitor

by Vladimir Murzin

Since ARMv6 new atomic instructions have been introduced: ldrex/strex. Several implementation are possible based on (1) global and local exclusive monitors and (2) local exclusive monitor and snoop unit. In case of the 2nd option exclusive store operation on uncached region may be faulty. Check for availability of the global monitor to provide some hint about possible issues. Signed-off-by: Vladimir Murzin <murzin.v(a)gmail.com> --- arch/arm/include/asm/bugs.h | 14 ++++++++++++-- arch/arm/mm/fault-armv.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/bugs.h b/arch/arm/include/asm/bugs.h index a97f1ea..230432e 100644 --- a/arch/arm/include/asm/bugs.h +++ b/arch/arm/include/asm/bugs.h @@ -13,9 +13,19 @@ #ifdef CONFIG_MMU extern void check_writebuffer_bugs(void); -#define check_bugs() check_writebuffer_bugs() +#if __LINUX_ARM_ARCH__ < 6 +static void check_gmonitor_bugs(void) {}; #else -#define check_bugs() do { } while (0) +extern void check_gmonitor_bugs(void); +#endif + +static inline void check_bugs(void) +{ + check_writebuffer_bugs(); + check_gmonitor_bugs(); +} +#else +static inline void check_bugs(void) { } #endif #endif diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c index 7599e26..c12846b 100644 --- a/arch/arm/mm/fault-armv.c +++ b/arch/arm/mm/fault-armv.c @@ -206,6 +206,49 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long addr, __flush_icache_all(); } } +#else +void __init check_gmonitor_bugs(void) +{ + struct page *page; + const char *reason; + unsigned long res = 1; + + printk(KERN_INFO "CPU: Testing for global monitor: "); + + page = alloc_page(GFP_KERNEL); + if (page) { + unsigned long *p; + pgprot_t prot = __pgprot_modify(PAGE_KERNEL, + L_PTE_MT_MASK, L_PTE_MT_UNCACHED); + + p = vmap(&page, 1, VM_IOREMAP, prot); + + if (p) { + int temp; + + __asm__ __volatile__( \ + "ldrex %1, [%2]\n" \ + "strex %0, %1, [%2]" \ + : "=&r" (res), "=&r" (temp) \ + : "r" (p) \ + : "cc", "memory"); + + reason = "n\\a (atomic ops may be faulty)"; + } else { + reason = "unable to map memory\n"; + } + + vunmap(p); + put_page(page); + } else { + reason = "unable to grab page\n"; + } + + if (res) + printk("failed, %s\n", reason); + else + printk("ok\n"); +} #endif /* __LINUX_ARM_ARCH__ < 6 */ /* -- 1.7.8.6

12 years, 3 months

2
1
0 0

[ACTIVITY] (John Stultz) Feb 11-15

by John Stultz

=== Highlights === * Lots of practice and refining of slides for ABS talk * Sent out android upstreaming subteam mail * Synced with Zach/Deepak * Mailed a bit with Zach on hotplug and volatile ranges * Submitted discussion proposal for lsf/mm-minisummit on volatile ranges (and pinged Anton to maybe do so for mempressure cg) * Pinged Arve on Serban's ashmem compat_ioctl patches * Emailed briefly with Tom and Sumit about dmabuf-fences * Pinged Erik again on my proposal to move sync driver to staging * Mailed Maarten and Daniel about dmabuf-fences. Trying to see how we can get folks talking on how to unify sync with dmabuf-fences. === Plans === * Give Android talk on Monday at ABS * Follow up on additional sync/dmabuf-fences discussion * Possibly submit sync upstream to staging * Try to refocus back on volatile ranges some === Issues === * NA

12 years, 3 months

1
0
0 0

[PATCH] memcg: Add memory.pressure_level events

by Anton Vorontsov

With this patch userland applications that want to maintain the interactivity/memory allocation cost can use the new pressure level notifications. The levels are defined like this: The "low" level means that the system is reclaiming memory for new allocations. Monitoring reclaiming activity might be useful for maintaining overall system's cache level. Upon notification, the program (typically "Activity Manager") might analyze vmstat and act in advance (i.e. prematurely shutdown unimportant services). The "medium" level means that the system is experiencing medium memory pressure, there is some mild swapping activity. Upon this event applications may decide to analyze vmstat/zoneinfo/memcg or internal memory usage statistics and free any resources that can be easily reconstructed or re-read from a disk. The "critical" level means that the system is actively thrashing, it is about to out of memory (OOM) or even the in-kernel OOM killer is on its way to trigger. Applications should do whatever they can to help the system. It might be too late to consult with vmstat or any other statistics, so it's advisable to take an immediate action. The events are propagated upward until the event is handled, i.e. the events are not pass-through. Here is what this means: for example you have three cgroups: A->B->C. Now you set up an event listener on cgroup A and cgroup B, and suppose group C experiences some pressure. In this situation, only group B will receive the notification, i.e. group A will not receive it. This is done to avoid excessive "broadcasting" of messages, which disturbs the system and which is especially bad if we are low on memory or thrashing. So, organize the cgroups wisely, or propagate the events manually (or, ask us to implement the pass-through events, explaining why would you need them.) The file mempressure.level is used to show the current memory pressure level, and cgroups event control file can be used to setup an eventfd notification with a specific memory pressure level threshold. Signed-off-by: Anton Vorontsov <anton.vorontsov(a)linaro.org> Acked-by: Kirill A. Shutemov <kirill(a)shutemov.name> --- Hi all, Here comes another iteration of the memory pressure saga. The previous version of the patch (and discussion) can be found here: http://lkml.org/lkml/2013/1/4/55 And here are changes in this revision: - Andrew Morton was concerned that the mempressure stuff was tied to memcg, which was non-issue since mempressure wasn't actually bolted into memcg at that time. But now it is. :) So now you need memcg to use mempressure. Why? It makes things easier, simpler (e.g. this ends any questions on how two different cgroups would interact, which can be complex when two are distinct entities). Plus, as I understood it, that's how cgroup folks want to see it eventually; - Only cgroups API implemented. Let's start with making memcg people happy, i.e. handling the most complex cases, and then we can start with any niche solutions; - Implemented Minchan Kim's idea of checking gfp mask. Unfortunately, it is not as simple as checking '__GFP_HIGHMEM | __GFP_MOVABLE', since we also need to account files caches and kswapd reclaim. But even so we can filter out DMA or atomic allocations, which are not interesting for userland. Plus it opens doors for other gfp tuning, so definitely a good stuff; - Per Leonid Moiseichuk's comments decreased vmpressure_level_critical to 95. I didn't look close enough, but it seems that we the minimum step is indeed ~3%, and 99% makes it actually 100%. 95% should be fine; - Per Kamezawa Hiroyuki added some words into documentation about that it's always a good idea to consult with vmstat/zoneinfo/memcg statistics before taking any action (with the exception of critical level). Also added 'TODO' wrt. automatic window adjustment; - Documented events propagation strategy; - Removed ulong/uint usage, per Andrew's comments; - Glauber Costa didn't like too short and non-descriptive mpc_ naming, suggesting mempressure_ instead. And Andrew suggested mpcg_. I went with something completely different: vmpressure_/vmpr_. :) Also renamed xxx2yyy() to xxx_to_yyy() per Glauber Costa suggestion. - _OOM level renamed to _CRITICAL. Andrew wanted _HIGH affix, but by using 'critical' I want to denote that this level is the last one (e.g. we might want to introduce _HIGH some time later, if we can find a good definition for it); - This patch does not include shrinker interface. In the last series I showed that implementing shrinker is possible, and that it actually can be useful. At the same time I explained that shrinker is not a substitution for the pressure levels. So, once we settle on the simple thing, I might continue my shrinker efforts (which, btw, QEMU guys found interesting and potentionally useful). For those who curious, the shrinker patch is here: http://lkml.org/lkml/2013/1/4/56 - Now tested with various debugging & preempt checks enabled, plus added small comments on locks usage, thanks to Andrew; - Rebased onto the current linux-next; - While the thing somewhat changed, I preserved Kirill's ack. Kirill at least liked the idea, and I desperately need Acks. :-D Thanks! Anton Documentation/cgroups/memory.txt | 66 ++++++++- init/Kconfig | 13 ++ mm/Makefile | 1 + mm/internal.h | 34 +++++ mm/memcontrol.c | 25 ++++ mm/vmpressure.c | 300 +++++++++++++++++++++++++++++++++++++++ mm/vmscan.c | 6 + 7 files changed, 444 insertions(+), 1 deletion(-) create mode 100644 mm/vmpressure.c diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index addb1f1..006ef58 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -40,6 +40,7 @@ Features: - soft limit - moving (recharging) account at moving a task is selectable. - usage threshold notifier + - memory pressure notifier - oom-killer disable knob and oom-notifier - Root cgroup has no limit controls. @@ -65,6 +66,7 @@ Brief summary of control files. memory.stat # show various statistics memory.use_hierarchy # set/show hierarchical account enabled memory.force_empty # trigger forced move charge to parent + memory.pressure_level # show the memory pressure level memory.swappiness # set/show swappiness parameter of vmscan (See sysctl's vm.swappiness) memory.move_charge_at_immigrate # set/show controls of moving charges @@ -778,7 +780,69 @@ At reading, current status of OOM is shown. under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may be stopped.) -11. TODO +11. Memory Pressure + +To maintain the interactivity/memory allocation cost, one can use the +pressure level notifications, and the levels are defined like this: + +The "low" level means that the system is reclaiming memory for new +allocations. Monitoring reclaiming activity might be useful for +maintaining overall system's cache level. Upon notification, the program +(typically "Activity Manager") might analyze vmstat and act in advance +(i.e. prematurely shutdown unimportant services). + +The "medium" level means that the system is experiencing medium memory +pressure, there is some mild swapping activity. Upon this event +applications may decide to analyze vmstat/zoneinfo/memcg or internal +memory usage statistics and free any resources that can be easily +reconstructed or re-read from a disk. + +The "critical" level means that the system is actively thrashing, it is +about to out of memory (OOM) or even the in-kernel OOM killer is on its +way to trigger. Applications should do whatever they can to help the +system. It might be too late to consult with vmstat or any other +statistics, so it's advisable to take an immediate action. + +The events are propagated upward until the event is handled, i.e. the +events are not pass-through. Here is what this means: for example you have +three cgroups: A->B->C. Now you set up an event listener on cgroup A and +cgroup B, and suppose group C experiences some pressure. In this +situation, only group B will receive the notification, i.e. group A will +not receive it. This is done to avoid excessive "broadcasting" of +messages, which disturbs the system and which is especially bad if we are +low on memory or thrashing. So, organize the cgroups wisely, or propagate +the events manually (or, ask us to implement the pass-through events, +explaining why would you need them.) + +The file mempressure.level is used to show the current memory pressure +level, and cgroups event control file can be used to setup an eventfd +notification with a specific memory pressure level threshold. + + Read: + Reads mempory presure levels: low, medium or critical. + Write: + Not implemented. + Test: + Here is a script: make a new cgroup, set up a memory limit, set up a + notification on the parent cgroup, make child cgroup experience a + critical pressure. Expected result is that the parent cgroup gets a + notification: + + (Note that we are seting up a listener on parent's cgroup, and then + creating a child cgroup, showing how event propagation works.) + + # cd /sys/fs/cgroup/memory/ + # cgroup_event_listener memory.pressure_level low & + # mkdir foo + # cd foo + # echo 8000000 > memory.limit_in_bytes + # echo $$ > tasks + # dd if=/dev/zero | read x + + (Expect a bunch of notifications, and eventually, the oom-killer will + trigger.) + +12. TODO 1. Add support for accounting huge pages (as a separate controller) 2. Make per-cgroup scanner reclaim not-shared pages first diff --git a/init/Kconfig b/init/Kconfig index ccd1ca5..6d61ef5 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -908,6 +908,19 @@ config MEMCG_DEBUG_ASYNC_DESTROY This is a developer-oriented debugging facility only, and no guarantees of interface stability will be given. +config MEMCG_PRESSURE + bool "Memory Resource Controller Pressure Monitor" + help + The memory pressure monitor provides a facility for userland + programs to watch for memory pressure on per-cgroup basis. This + is useful if you have programs that want to respond to the + pressure, possibly improving memory management. + + For more information see Memory Pressure section in + Documentation/cgroups/memory.txt. + + If unsure, say N. + config CGROUP_HUGETLB bool "HugeTLB Resource Controller for Control Groups" depends on RESOURCE_COUNTERS && HUGETLB_PAGE diff --git a/mm/Makefile b/mm/Makefile index 3a46287..51f7f52 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -51,6 +51,7 @@ obj-$(CONFIG_MIGRATION) += migrate.o obj-$(CONFIG_QUICKLIST) += quicklist.o obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o obj-$(CONFIG_MEMCG) += memcontrol.o page_cgroup.o +obj-$(CONFIG_MEMCG_PRESSURE) += vmpressure.o obj-$(CONFIG_CGROUP_HUGETLB) += hugetlb_cgroup.o obj-$(CONFIG_MEMORY_FAILURE) += memory-failure.o obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o diff --git a/mm/internal.h b/mm/internal.h index 1c0c4cc..eb50685 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -374,4 +374,38 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone, #define ALLOC_CPUSET 0x40 /* check for correct cpuset */ #define ALLOC_CMA 0x80 /* allow allocations from CMA areas */ +struct vmpressure { +#ifdef CONFIG_MEMCG_PRESSURE + unsigned int scanned; + unsigned int reclaimed; + /* The lock is used to keep the scanned/reclaimed above in sync. */ + struct mutex sr_lock; + + struct list_head events; + /* Have to grab the lock on events traversal or modifications. */ + struct mutex events_lock; + + struct work_struct work; +#endif /* CONFIG_MEMCG_PRESSURE */ +}; + +struct mem_cgroup; +#ifdef CONFIG_MEMCG_PRESSURE +extern void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, + unsigned long scanned, unsigned long reclaimed); +extern void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio); +extern void vmpressure_init(struct vmpressure *vmpr); +extern struct vmpressure *memcg_to_vmpr(struct mem_cgroup *memcg); +extern struct cgroup_subsys_state *vmpr_to_css(struct vmpressure *vmpr); +extern struct vmpressure *css_to_vmpr(struct cgroup_subsys_state *css); +extern void __init enable_pressure_cgroup(void); +#else +static inline void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, + unsigned long scanned, unsigned long reclaimed) {} +static inline void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, + int prio) {} +static inline void vmpressure_init(struct vmpressure *vmpr) {} +static inline void __init enable_pressure_cgroup(void) {} +#endif /* CONFIG_MEMCG_PRESSURE */ + #endif /* __MM_INTERNAL_H */ diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 25ac5f4..60f277a 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -370,6 +370,9 @@ struct mem_cgroup { atomic_t numainfo_events; atomic_t numainfo_updating; #endif + + struct vmpressure vmpr; + /* * Per cgroup active and inactive list, similar to the * per zone LRU lists. @@ -575,6 +578,26 @@ static inline bool mem_cgroup_is_root(struct mem_cgroup *memcg) return (memcg == root_mem_cgroup); } +/* Some nice accessors for the vmpressure. */ +#ifdef CONFIG_MEMCG_PRESSURE +struct vmpressure *memcg_to_vmpr(struct mem_cgroup *memcg) +{ + if (!memcg) + memcg = root_mem_cgroup; + return &memcg->vmpr; +} + +struct cgroup_subsys_state *vmpr_to_css(struct vmpressure *vmpr) +{ + return &container_of(vmpr, struct mem_cgroup, vmpr)->css; +} + +struct vmpressure *css_to_vmpr(struct cgroup_subsys_state *css) +{ + return &mem_cgroup_from_css(css)->vmpr; +} +#endif /* CONFIG_MEMCG_PRESSURE */ + /* Writing them here to avoid exposing memcg's inner layout */ #if defined(CONFIG_INET) && defined(CONFIG_MEMCG_KMEM) @@ -6291,6 +6314,7 @@ mem_cgroup_css_alloc(struct cgroup *cont) memcg->move_charge_at_immigrate = 0; mutex_init(&memcg->thresholds_lock); spin_lock_init(&memcg->move_lock); + vmpressure_init(&memcg->vmpr); return &memcg->css; @@ -7018,6 +7042,7 @@ static int __init mem_cgroup_init(void) { hotcpu_notifier(memcg_cpu_hotplug_callback, 0); enable_swap_cgroup(); + enable_pressure_cgroup(); mem_cgroup_soft_limit_tree_init(); memcg_stock_init(); return 0; diff --git a/mm/vmpressure.c b/mm/vmpressure.c new file mode 100644 index 0000000..7922503 --- /dev/null +++ b/mm/vmpressure.c @@ -0,0 +1,300 @@ +/* + * Linux VM pressure + * + * Copyright 2012 Linaro Ltd. + * Anton Vorontsov <anton.vorontsov(a)linaro.org> + * + * Based on ideas from Andrew Morton, David Rientjes, KOSAKI Motohiro, + * Leonid Moiseichuk, Mel Gorman, Minchan Kim and Pekka Enberg. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include <linux/cgroup.h> +#include <linux/fs.h> +#include <linux/sched.h> +#include <linux/mm.h> +#include <linux/vmstat.h> +#include <linux/eventfd.h> +#include <linux/swap.h> +#include <linux/printk.h> +#include "internal.h" + +/* + * Generic VM Pressure routines (no cgroups or any other API details) + */ + +/* + * The window size is the number of scanned pages before we try to analyze + * the scanned/reclaimed ratio (or difference). + * + * It is used as a rate-limit tunable for the "low" level notification, + * and for averaging medium/critical levels. Using small window sizes can + * cause lot of false positives, but too big window size will delay the + * notifications. + * + * TODO: Make the window size depend on machine size, as we do for vmstat + * thresholds. + */ +static const unsigned int vmpressure_win = SWAP_CLUSTER_MAX * 16; +static const unsigned int vmpressure_level_med = 60; +static const unsigned int vmpressure_level_critical = 95; +static const unsigned int vmpressure_level_critical_prio = 3; + +enum vmpressure_levels { + VMPRESSURE_LOW = 0, + VMPRESSURE_MEDIUM, + VMPRESSURE_CRITICAL, + VMPRESSURE_NUM_LEVELS, +}; + +static const char *vmpressure_str_levels[] = { + [VMPRESSURE_LOW] = "low", + [VMPRESSURE_MEDIUM] = "medium", + [VMPRESSURE_CRITICAL] = "critical", +}; + +static enum vmpressure_levels vmpressure_level(unsigned int pressure) +{ + if (pressure >= vmpressure_level_critical) + return VMPRESSURE_CRITICAL; + else if (pressure >= vmpressure_level_med) + return VMPRESSURE_MEDIUM; + return VMPRESSURE_LOW; +} + +static unsigned long vmpressure_calc_level(unsigned int win, + unsigned int s, unsigned int r) +{ + unsigned long p; + + if (!s) + return 0; + + /* + * We calculate the ratio (in percents) of how many pages were + * scanned vs. reclaimed in a given time frame (window). Note that + * time is in VM reclaimer's "ticks", i.e. number of pages + * scanned. This makes it possible to set desired reaction time + * and serves as a ratelimit. + */ + p = win - (r * win / s); + p = p * 100 / win; + + pr_debug("%s: %3lu (s: %6u r: %6u)\n", __func__, p, s, r); + + return vmpressure_level(p); +} + +void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, + unsigned long scanned, unsigned long reclaimed) +{ + struct vmpressure *vmpr = memcg_to_vmpr(memcg); + + /* + * So far we are only interested application memory, or, in case + * of low pressure, in FS/IO memory reclaim. We are also + * interested indirect reclaim (kswapd sets sc->gfp_mask to + * GFP_KERNEL). + */ + if (!(gfp & (__GFP_HIGHMEM | __GFP_MOVABLE | __GFP_IO | __GFP_FS))) + return; + + if (!scanned) + return; + + mutex_lock(&vmpr->sr_lock); + vmpr->scanned += scanned; + vmpr->reclaimed += reclaimed; + mutex_unlock(&vmpr->sr_lock); + + if (scanned < vmpressure_win || work_pending(&vmpr->work)) + return; + schedule_work(&vmpr->work); +} + +void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg, int prio) +{ + if (prio > vmpressure_level_critical_prio) + return; + + /* OK, the prio is below the threshold, we're about to oom. */ + vmpressure(gfp, memcg, vmpressure_win, 0); +} + +static struct vmpressure *wk_to_vmpr(struct work_struct *wk) +{ + return container_of(wk, struct vmpressure, work); +} + +static struct vmpressure *cg_to_vmpr(struct cgroup *cg) +{ + return css_to_vmpr(cgroup_subsys_state(cg, mem_cgroup_subsys_id)); +} + +struct vmpressure_event { + struct eventfd_ctx *efd; + enum vmpressure_levels level; + struct list_head node; +}; + +static bool vmpressure_event(struct vmpressure *vmpr, + unsigned long s, unsigned long r) +{ + struct vmpressure_event *ev; + int level = vmpressure_calc_level(vmpressure_win, s, r); + bool signalled = 0; + + mutex_lock(&vmpr->events_lock); + + list_for_each_entry(ev, &vmpr->events, node) { + if (level >= ev->level) { + eventfd_signal(ev->efd, 1); + signalled++; + } + } + + mutex_unlock(&vmpr->events_lock); + + return signalled; +} + +static struct vmpressure *vmpressure_parent(struct vmpressure *vmpr) +{ + struct cgroup *cg = vmpr_to_css(vmpr)->cgroup->parent; + + if (!cg) + return NULL; + return cg_to_vmpr(cg); +} + +static void vmpressure_wk_fn(struct work_struct *wk) +{ + struct vmpressure *vmpr = wk_to_vmpr(wk); + unsigned long s; + unsigned long r; + + mutex_lock(&vmpr->sr_lock); + s = vmpr->scanned; + r = vmpr->reclaimed; + vmpr->scanned = 0; + vmpr->reclaimed = 0; + mutex_unlock(&vmpr->sr_lock); + + do { + if (vmpressure_event(vmpr, s, r)) + break; + /* + * If not handled, propagate the event upward into the + * hierarchy. + */ + } while ((vmpr = vmpressure_parent(vmpr))); +} + +/* cgroups "frontend" for vmpressure. */ + +static ssize_t vmpressure_read_level(struct cgroup *cg, struct cftype *cft, + struct file *file, char __user *buf, + size_t sz, loff_t *ppos) +{ + struct vmpressure *vmpr = cg_to_vmpr(cg); + unsigned int level; + const char *str; + ssize_t len = 0; + + if (*ppos >= sz) + return 0; + + mutex_lock(&vmpr->sr_lock); + + level = vmpressure_calc_level(vmpressure_win, + vmpr->scanned, vmpr->reclaimed); + + mutex_unlock(&vmpr->sr_lock); + + str = vmpressure_str_levels[level]; + len += strlen(str) + 1; + if (len > sz) + return -EINVAL; + + if (copy_to_user(buf, str, len - 1)) + return -EFAULT; + if (copy_to_user(buf + len - 1, "\n", 1)) + return -EFAULT; + + *ppos += sz; + return len; +} + +static int vmpressure_register_level(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd, + const char *args) +{ + struct vmpressure *vmpr = cg_to_vmpr(cg); + struct vmpressure_event *ev; + int lvl; + + for (lvl = 0; lvl < VMPRESSURE_NUM_LEVELS; lvl++) { + if (!strcmp(vmpressure_str_levels[lvl], args)) + break; + } + + if (lvl >= VMPRESSURE_NUM_LEVELS) + return -EINVAL; + + ev = kzalloc(sizeof(*ev), GFP_KERNEL); + if (!ev) + return -ENOMEM; + + ev->efd = eventfd; + ev->level = lvl; + + mutex_lock(&vmpr->events_lock); + list_add(&ev->node, &vmpr->events); + mutex_unlock(&vmpr->events_lock); + + return 0; +} + +static void vmpressure_unregister_level(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd) +{ + struct vmpressure *vmpr = cg_to_vmpr(cg); + struct vmpressure_event *ev; + + mutex_lock(&vmpr->events_lock); + list_for_each_entry(ev, &vmpr->events, node) { + if (ev->efd != eventfd) + continue; + list_del(&ev->node); + kfree(ev); + break; + } + mutex_unlock(&vmpr->events_lock); +} + +static struct cftype vmpressure_cgroup_files[] = { + { + .name = "pressure_level", + .read = vmpressure_read_level, + .register_event = vmpressure_register_level, + .unregister_event = vmpressure_unregister_level, + }, + {}, +}; + +void vmpressure_init(struct vmpressure *vmpr) +{ + mutex_init(&vmpr->sr_lock); + mutex_init(&vmpr->events_lock); + INIT_LIST_HEAD(&vmpr->events); + INIT_WORK(&vmpr->work, vmpressure_wk_fn); +} + +void __init enable_pressure_cgroup(void) +{ + WARN_ON(cgroup_add_cftypes(&mem_cgroup_subsys, + vmpressure_cgroup_files)); +} diff --git a/mm/vmscan.c b/mm/vmscan.c index 88c5fed..34f09b9 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1982,6 +1982,10 @@ static void shrink_zone(struct zone *zone, struct scan_control *sc) } memcg = mem_cgroup_iter(root, memcg, &reclaim); } while (memcg); + + vmpressure(sc->gfp_mask, sc->target_mem_cgroup, + sc->nr_scanned - nr_scanned, nr_reclaimed); + } while (should_continue_reclaim(zone, sc->nr_reclaimed - nr_reclaimed, sc->nr_scanned - nr_scanned, sc)); } @@ -2167,6 +2171,8 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, count_vm_event(ALLOCSTALL); do { + vmpressure_prio(sc->gfp_mask, sc->target_mem_cgroup, + sc->priority); sc->nr_scanned = 0; aborted_reclaim = shrink_zones(zonelist, sc); -- 1.8.1.1

12 years, 3 months

5
7
0 0

[ACTIVITY] (Linus Walleij) 2013-02-04 - 2013-02-10

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Finalized AB8500 GPIO pathes, tested and obtained working IRQs. Merged some of these into the MFD tree, some into the pinctrl tree and some into a patch set targeted at ARM SoC. * GPIO maintenance: - Handed working tree over to Grant, who picked it and added some more. - Reviewed some of the nice GPIO descriptor rework patches, and Grant started merging some of them. * Pinctrl maintenance: - Requested Torvalds to pull in the last two pinctrl fixes. He pulled them in. - Merged the ABx500 pinctrl stuff. - Merged a bunch of lantiq patches. * Reviewed some PXA SPI DMA stuff, they are basically splitting the custom DMA API from the dmaengine API to optionally compile out the former and eventually delete it, and this is nice stuff. The PXA SPI is apparently also used by all the Intel SoC:s so this is a big win. * Cooked two fix-up patches agains the compile regression introduced in the ux500 due to the <mach/id.h> removal patches. Sent two patches fixing it up: http://marc.info/?l=linux-arm-kernel&m=136051407426331&w=2 http://marc.info/?l=linux-arm-kernel&m=136051407826332&w=2 Hopefully these can get merged. Still no clue how I managed to screw things up like this, I know for sure I compiled this branch, but maybe new support was introduced somewher in the v3.7 cycle and I missed it. * Russell merged the Versatile QEMU PCI fix. * Interviewed a potential KWG assignee on Deepak's request. * Got fed up with people not fixing the NO_IRQ business (i.e. using Linux IRQ 0), so I sent two attack-patches bumping fixed Linux IRQ offsets to 64 for mach-netx and mach-ep93xx. netx patch ACKed, merging through Russell. * Bystanding Fabio while he was root-casing an issue on the DMA40 DMA controller. He found the culprit and everyone is happy. * Debated heavy subjects: - Is virtio or dmaengine the best way forward for OMAPs odd USB acceleration. - Status of the HSI subsystem. - Deferred probe is completing after __init sections have been discarded, on the assumption nothing needing these sections will be around. That doesn't work for the console set-up calls, d'oh. Haojian has an interesting pending patch: http://marc.info/?l=linux-kernel&m=136042916203488&w=2 === Plans === * Finalize a GPIO+pinctrl presentation for the Embedded Linux Conference next week. My presentation will be first day of the conference. It's all fun! I will be travelling and hanging out at ELC the whole next week, monday 18th thru monday the 25th. * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Convert Nomadik pinctrl driver to register GPIO ranges from the gpiochip side. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Get hands dirty with regmap. === Issues === * Some stress still but feels better when thing have started working and regressions get fixed. Thanks, Linus Walleij

12 years, 3 months

1
0
0 0

[ACTIVITY] (Ulf Hansson) 2013-01-27 - 2013-02-10

by Ulf Hansson

== Ulf Hansson == === Highlights === Storage: * Monitoring patches on mmc-list. * Patches for fixing signal voltage switch procedure for SD card UHS mode ready. Acked and tested by different host driver authors. * Patch for improve dma handling for mmci host driver accepted for 3.9. * Cooperating with internal STE colleague, Johan Rudholm, with regards to rework parts of the HS200 and SDR104 support in the mmc protocol layer. * Received another eMMC -> SD card adapter with corresponding eMMC 4.5 samples, this time from Toshiba via Pär Andersson. Really great to have another vendor to test with, thanks Toshiba! Clk: * Still high focus doing internal work for STE ux500. Started to prepare a patchset for upstream this work, some dependencies to Lee Jones upstream work for mfd driver related parts which complicates it a bit. The patches will add support for abx500 clocks, update different driver's clk support and include ux500 clk optimizations. * Follow up on patchset for fixing clk_set_parent API. * Follow up on patchset for disable unsed prepared clks. === Plans === Storage: * Follow up on Idle time BKOPS patches on mmc list. Will soon send a skeleton patch which the work can be based upon, related to runtime PM. * Doing an overall analyse about the eMMC 4.5/4.6 features. Check what can be considered finished, what needs further fixing and point out the new features for which we should spend our focus on in Linaro storage team. As also stated above, rework of HS200/SDR104 support started. * Push patches for mmci host driver to support UHS cards. * Push patches for mmci host driver to further extend the power management support. * Push patches for mmci host driver to add new features like CMD23 support and more. * Push patches for mmci host driver to add support for new STE 8540 variant. Clk: * Upstreaming of internal work for ux500. === Issues === * Still need to increase focus towards storage, all work related to clks has been given give higher prio for a while now. Kind regards Ulf Hansson

12 years, 3 months

1
0
0 0

[ACTIVITY] (John Stultz) Feb 4th-8th

by John Stultz

=== Highlights === * Got my current timekeeping queue merged into -tip for 3.9 * Got my plane tickets for ABS * Got my ABS slides finished (including charts that were annoying hard to create) * Sent out android upstreaming subteam mail * Synced with Deepak * Agreed to help run the Android miniconf at LPC * Reviewed and queued patch for NTP/RTC update issue * Started looking at Android Sync driver, pinged Erik on his plans, and pinged Maarten on dmabuf-fences * Reworked Android Sync driver so it could be merged with staging (pending feedback from Erik) === Plans === * Submit ABS slides * Rehearsing for ABS talk & any last polishing of the slides * Hopefully continue discussions around dmabuf-fence/android-sync and possibly submit sync to staging. === Issues === * NA

12 years, 3 months

1
0
0 0

[ACTIVITY] (Linus Walleij) 2013-01-27 - 2013-02-03

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Working on AB8500 GPIO as it is a roadblock for the multiplatform, as it is a SPARSE_IRQ regression. https://blueprints.launchpad.net/linux-linaro/+spec/ab8500-gpio-shapeup Working on Lee Jones' cleanup and IRQ fixup series. Finally aquired a hardware that can actually fire these IRQs. * Requested Torvalds to pull in a bunch of pinctrl fixes and he pulled them in. One outstanding patch needs to be sent still :-( * GPIO maintenance: - Got PCA GPIO cleanups back from maintainer, modified and working, merged them. - Merged ACPI extensions for gpiolib from Mathias Nyman, the build robot found issues, have asked Mathias to fix them. - Finalizing tree for the merge window. * Pinctrl maintenance: - Merged a few allwinner pinctrl patches. More yet queued. - Finalizing tree for the merge window. * Arnd found a bug in the Nomadik (mach-nomadik) device tree patch set: need to select USE_OF over just OF. Made a patch and sent it. * Got an ACK for the missing <mach/id.h> removal dependency from the MFD maintainer. Send a pull request for it, and it has landed in linux-next. However I seem to have screwed up the patch set somehow and now I must fix it :-( * Fixed a regression in the Versatile QEMU PCI code. (I don't know if anyone is actually using the QEMU Versatile PCI on real hardware, or if that even really works. There are rumors that it does not.) The patch is in Russell's patch tracker: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7635/1 === Plans === * First fix the AB8500 GPIO mess. * Large pinctrl single patch set in the INBOX. * Large GPIO descriptor rework patch set in the INBOX. * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Convert Nomadik pinctrl driver to register GPIO ranges from the gpiochip side. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Get hands dirty with regmap. === Issues === * The constant overload and still a feeling of not doing progress make me do stupid mistakes like the bug in the Nomadik patch set and the <mach/id.h> removal bugs. Maybe I should drop some stuff from the merge window to avoid more stupid mistakes. Thanks, Linus Walleij

12 years, 4 months

1
0
0 0

[ACTIVITY] (John Stultz) Jan 28 - Feb 1

by John Stultz

=== Highlights === * Sent out mqueue timer/nohz performance regression fix for 2.6.32-stable * Reviewed Appala's logger test plan * Updated blueprints and held bi-weekly Android upstreaming meeting, synced with Zach, Deepak, Jakub in other meetings. * Sent Axel the alarm-dev-test, and after some feedback from him, reworked it a touch and resent it. * Reviewed Serban's new ashmem interface/compat_ioctl changes * Got on the AOSP contributers list * Submitted fix to ashmem.h inconsistent ioctl that Dmitry noticed to AOSP * Attended local portland Android lecture series, trying to learn more about Android userland details * Discussed potential license issues with unit-test development * Started generating slides for my ABS talk. * Continued working on tmpfs enablment in Minchan's patch but ran into more troubles. * Repinged tglx on 3.9 patches === Plans === * Continue tmpfs volatile anonymous range work * Continue working on ABS talk === Issues === NA

12 years, 4 months

1
0
0 0

[ACTIVITY] (John Stultz) Jan 21-25

by John Stultz

Sorry this is late! === Highlights === * Discussed possible common infrastructure for arm/x86 on using clocksource like counters for measuring suspendtime. * Contributed to discussion around HZ/clocksource/clockevent/jiffies functionality, so a common HZ value can be found for multi-arch kernels. * Discussed android-upstreaming subteam process with Jakub and Deepak * Sent git pull for 3.9 timekeeping items * Sent out weekly android upstreaming subteam status mail * Found and fixed a reported timekeeping related performance regression found in 2.6.32.60 * Took first pass at adding tmpfs support to Minchan's current patchset. Not yet fully working. === Plans === * Continue tmpfs volatile anonymous range work * Reping tglx on 3.9 patches * Start working on ABS talk === Issues === NA

12 years, 4 months

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2013-01-21 to 2013-01-25

by Rajanikanth HV

==== Activity Summary ==== * "Kernel crash-Snowball board": Rootcaused and fixed kernel crash issue on snowball board, patch has been communicated for review. * Multiplatform Support for ux500: Had a syncup with linuswalleij on MPCONFIG/ARCH_MULTIPLATFORM enablement, linusw provided pointers to blueprints and current work status through git repos. I have started to work on the same. * Weekly singlezImage meeting: analyzing static overhead for the platforms with the single ones * Task: Combined kernel config across vexpress-QEMU and i.MX: Spent some time on debugging vexpress for not booting to prompt, found that DTB file is not the culprit.Meanwhile, "peter maydell" and others have confirmed about the successful boot of VExpress-QEMU with DTB from the linaro nightly build, cross checking the reason for failure at my end. ==== Plan ==== * Continue Adding Multiplatform Config support * Combined kernel analysis ==== Issues ==== One day internal office work

12 years, 4 months

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2013-01-07 to 2013-01-11

by Rajanikanth HV

==== Activity Summary ==== * Updated runtime size "Multiplatform Config data" information for i.mx platform. * Discussed with linusw on Multiplatform Config, linusw suggested to edit u8500 driver to filter out dependency on ./mach* folder Note: Found some regressions(kernel crash) on u8500 board, details in the "issues" below. * Discussed with arnd regarding combined kernel verification, currently verifying on "VExpress-QEMU and i.MX" platform, Note: Vexpress-QEMU does not boots to prompt, found "division by zero" error, hence falling back to v3.7 for verification and backporting "i.mx multiplatform config" patches to v3.7 so that we can expect it to boot across "VExpress-QEMU and i.MX platform". During backporing i observed that commits/patches does not apply directly, needs manual merge. ==== Plan ==== * Continue Adding Multiplatform Config support * Syncup with Arnd on combined kernel verification ==== Issues ==== * Observed kernel crash(https://pastebin.linaro.org/1370/) on 3.8-rc2 version with respect to pincontrol, found to be fixed in rc3 and ab8500-DT related kernel crash(https://pastebin.linaro.org/1391/) on rc3, currently rootcausing the issue * Vexpress-QEMU: with and without "combined kernel config" 3.8-rcX kernel with DT does not boots to prompt, however, understood from tixy that kernel boots on RealHardware, found error "Division by zero in kernel" during the crash. Yet to start fixing the issue

12 years, 4 months

1
1
0 0

[ACTIVITY] (Linus Walleij) 2013-01-22 - 2013-01-26

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Working on AB8500 GPIO as it is a roadblock for the multiplatform, as it is a SPARSE_IRQ regression. https://blueprints.launchpad.net/linux-linaro/+spec/ab8500-gpio-shapeup Second iteration of the patch pushed to linux-next thru pinctrl. Next step is to merge Lee Jones' IRQ fixup patches and test. * Merged pinctrl device core grabbing patch after a final touch-up by Stephen Warren and following Greg's ACK. Now we know we will definately have this nice infrastructure in v3.9. https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-corehog * Requested Torvalds to pull in a bunch of GPIO fixes and he pulled them in. * Reviewed and stacked up a few GPIO patches. Proposed two minor cleanups to the pca driver. * Reviewed and stacked up not-so-few pinctrl patches, including some ACKing of the big SH pinctrl business going on. * Requested pull for three ux500 v3.8 fixes. * Requested pull for Nomadik (mach-nomadik) device tree patch set. * Iterated a patch form Nomadik I2C pinctrl. Wolfram merged it, after fixing my mistakes, and he wrote yet another cleanup patch as well, nice! * Iterated a patch to U-Boot enabling device tree on the Integrator. === Plans === * First fix the AB8500 GPIO mess. * Get and ACK for the missing <mach/id.h> removal dependency from the MFD maintainer. * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Convert Nomadik pinctrl driver to register GPIO ranges from the gpiochip side. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Get hands dirty with regmap. === Issues === * N/A (just overly busy as usual) Thanks, Linus Walleij

12 years, 4 months

1
0
0 0

[ACTIVITY] (Ulf Hansson) 2012-01-12 - 2013-01-26

by Ulf Hansson

== Ulf Hansson == === Highlights === Storage: * Reviewing patches on mmc-list, different stuff. * Patches on mmc-list for fixing signal voltage switch procedure for UHS mode ready. Acked and tested by different host driver authors. Still not merged yet, hopefully they will go in 3.9. * Sent updated patch for dma handling in mmci host driver. Clk: * Quite much internal work done. Needed to be able to prepare a patchset to implement abx500 clocks. Found out issues with clk_set_parent API. * Resent patchset for clk framework, to make an unsued clk unprepared at late_init. Now also includes a patch for ux500 to make use of this feature. * Send patchset for fixing clk_set_parent API. === Plans === Storage: * Follow up on Idle time BKOPS patches on mmc list. Intend to send a skeleton patch which the work can be based upon. Related to runtime PM. * Doing an overall analyse about the eMMC 4.5/4.6 features. Check what can be considered finished, what needs further fixing and point out the new features for which we should spend our focus on in Linaro storage team. * Push patches for mmci host driver to support for UHS cards. * Push patches for mmci host driver to further extend the power management support. * Push patches for mmci host driver to add new features like CMD23 support and more. Clk: * Upstream internal ux500 clock work related to abx500 clk driver. === Resolved Issues === * Major issue resolved when Micron, via Luca Porzio, sent me an eMMC -> SD card adapter for their eMMC 4.5 samples I already got from them. Now I am able to boost up focus on eMMC 4.5 features an actually do some real testing. Thanks Luca and Micron! === Issues === * The quite intensive work for the internal development track for ux500 clocks, has temporary made me drop some focus on storage. I will correct that when coming back from the one week of ski-vacation which starts tomorrow. :-) Kind regards Ulf Hansson

12 years, 4 months

1
0
0 0

Release git repositories.

by dpc＠ucore.info

Hi, I'm struggling to find a git repository in which I could checkout the kernel state used for particular release (eg. 12.11, 12.12). All I've found is: https://wiki.linaro.org/Resources/HowTo/Git/LinaroGitTrees but it's not solving my problem. I'm browsing git.linaro.org and can't find anything like this. Can anyone point me in the right direction? Regards, -- Dawid Ciężarkiewicz

12 years, 4 months

2
1
0 0

[ACTIVITY] (Linus Walleij) 2013-01-12 - 2013-01-21

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Working on AB8500 GPIO as it is a roadblock for the multiplatform, as it is a SPARSE_IRQ regression. https://blueprints.launchpad.net/linux-linaro/+spec/ab8500-gpio-shapeup * Iterated the pinctrl device core pin grabbing: https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-corehog http://marc.info/?l=linux-kernel&m=135879594515932&w=2 * Concluded that the reported errors with device tree and sparse IRQ were due to regression fixes not being merged to the MFD tree. See below on issues. * Looked over some pending GPIO and pinctrl patch queue. * Advanced Nomadik (mach-nomadik) device tree patch set. * Pushed a patch to U-Boot enabling device tree on the Integrator. === Plans === * First fix the AB8500 GPIO mess. * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Convert Nomadik pinctrl driver to register GPIO ranges from the gpiochip side. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Get hands dirty with regmap. === Issues === * Not getting response from the MTD maintainer. Filed two regressions, one of them before christmas (!) http://marc.info/?l=linux-kernel&m=135880464619562&w=2 http://marc.info/?l=linux-kernel&m=135820251519490&w=2 Don't know what to do. Shall I send the patches to Torvalds directly or what... Thanks, Linus Walleij

12 years, 4 months

1
0
0 0

[ACTIVITY] (John Stultz) Jan 14-18

by John Stultz

=== Highlights === * Build system arrived and got it setup w/ my git trees and test kvm environments * Updated linaro-android tree to address __devinit issue Tixy pointed out. * Ran bi-weekly meeting, and synced with Serban on compat_ioctl work * Android alarm-dev compat_ioctl patches were merged into GregKH's tree for 3.9 * Got harangued into presenting a Android status update at ABS * Queued some community 3.9 patches * Asked Google Android team about Dmitry's inconsistent ashmem ioctl issue, got a response on how to solve it. * Pinged Jason Wessel on FIQ KDB work (end up he's been on sabbatical) * Initial review and testing of Minchans' v8 patch. Sent feedback on a few bugs I found. === Plans === * Take a stab at tmpfs volatile anonymous ranges * Sync w/ tglx and send initial git pull for 3.9 * Merge a handful of community timekeeping patches & sync w/ tglx * Start work on my slides for my ABS talk === Issues ===

12 years, 4 months

1
0
0 0

[PATCH 0/2] Mempressure cgroup

by Anton Vorontsov

Hi all, Here is another round of the mempressure cgroup. This time I dared to remove the RFC tag. :) In this revision: - Addressed most of Kirill Shutemov's comments. I didn't bother implementing per-level lists, though. It would needlessly complicate the logic, and the gain would be only visible with lots of watchers (which we don't have for our use-cases). But it is always an option to add the feature; - I've split the pach into two: 'shrinker' and 'levels' parts. While the full-fledged userland shrinker is an interesting idea, we don't have any users ready for it, so I won't advocate for it too much. And since at least Kirill has some concerns about it, I don't want the shrinker to block the pressure levels. So, these are now separate. At some point, I'd like to both of them merged, but if anything, let's discuss them separately; - Rebased onto v3.8-rc2. RFC v2 (http://lkml.org/lkml/2012/12/10/128): - Added documentation, describes APIs and the purpose; - Implemented shrinker interface, this is based on Andrew's idea and supersedes my "balance" level idea; - The shrinker interface comes with a stress-test utility, that is what Andrew was also asking for. A simple app that we can run and see if the thing works as expected; - Added reclaimer's target_mem_cgroup handling; - As promised, added support for multiple listeners, and fixed some other comments on the previous RFC. RFC v1 (http://lkml.org/lkml/2012/11/28/109) -- Documentation/cgroups/mempressure.txt | 97 +++++ Documentation/cgroups/mempressure_test.c | 213 ++++++++++ include/linux/cgroup_subsys.h | 6 + include/linux/vmstat.h | 11 + init/Kconfig | 13 + mm/Makefile | 1 + mm/mempressure.c | 487 +++++++++++++++++++++++ mm/vmscan.c | 4 + 8 files changed, 832 insertions(+)

12 years, 4 months

11
31
0 0

[ACTIVITY] (John Stultz) Jan 7-11

by John Stultz

=== Highlights === * Pestered infrastructure and HR folks with tons of annoying questions (thanks everyone! :) * Got access to hackbox.linaro.org and as a temporary build system * Got a test environment & cross compiler working * Merged fixes from Tixy and Tushar to linaro.android branch * Talked with Jakub and Zach about tree management plans * Generated patches for alarm-dev compat_ioctl work & sent out to lkml * Booked travel to Hong Kong for Connect * Couple of community issues === Plans === * Get alarm-dev compat_ioctl work merged * Sync w/ Serban on other compat_ioctl work * Review Minchan's patches (still!) * Merge a handful of community timekeeping patches & sync w/ tglx === Issues === * Still chasing some infrastructure issues

12 years, 4 months

1
0
0 0

[ACTIVITY] (Linus Walleij) 2013-01-05 - 2013-01-11

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Handled the ux500 cpufreq and clksrc patches queued up from Ulfs and Fabios side. Pushed Rafael Wysocki and Sam Ortiz to obtain ACKs and after succeeding with that send a pull request to the ARM SoC tree, Olof pulled it in. * As explained last week working on AB8500 GPIO as it is a roadblock for the multiplatform, as it is a SPARSE_IRQ regression. https://blueprints.launchpad.net/linux-linaro/+spec/ab8500-gpio-shapeup * Backmerged a set of patches for GPIO ranges into the internal kernel tree to use as a base when preparing the new nice AB8500 driver. * Had a report on the v3.8 not booting properly using DT for some reason, maybe SPARSE_IRQ-related. Investigation ongoing. * Had a stab at the pinctrl and gpio subsystem backlog from the mailing lists. Much remains, I have some week of backlog. * Helped Lee a bit with advice & such ... the usual. Looked into the charging patches a bit, looked at other stuff floating by a bit. Both Lee & Fabio are doing great stuff at high speed for ux500. === Plans === * First fix the AB8500 mess. * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * N/A Thanks, Linus Walleij

12 years, 4 months

1
0
0 0

[ACTIVITY] (Ulf Hansson) 2012-12-17 - 2013-01-11

by Ulf Hansson

== Ulf Hansson == === Highlights === * Spend two weeks of christmas holidays has in Sweden. I should be full of energy right. :-) Storage: * Reviewing patches on mmc-list related to SDIO suspend/resume when using SDIO IRQ as wakeup. * Continue reviewing patches on mmc-list for Idle time BKOPS. * Patches on mmc-list for fixing signal voltage switch procedure for UHS mode seems ready. Acked and tested by different host driver authors. * Several patches sent for discussion for mmci host driver. Some has been merged for 3.9. Clk: * Internal work done. Needed to be able to prepare a patchset to implement abx500 clocks. * Sent patchset for clk framework, to make an unsued clk unprepared at late_init. Tested with a ux500 temporary patch. === Plans === Storage: * Follow up on Idle time BKOPS patches on mmc list. Might help out in sending a skeleton patch which the work can be based upon. Related to runtime PM. * Doing an overall analyse about the eMMC 4.5/4.6 features. Check what can be considered finished, what needs further fixing and point out the new features for which we should spend our focus on in Linaro storage team. * Push patches for mmci host driver to support for UHS cards. * Push patches for mmci host driver to further extend the power management support. * Push patches for mmci host driver to add new features like CMD23 support and more. Clk: * Add support for new clk-types in abx500 clock driver for the ux500 platform. * Send patch to let ux500 clks be unprepared at late_init. Depending on the patches on the clk framework for this. === Issues === * Been trying for several month to get a hold of eMMC 4.5 device with an SD-card adapter. Extremely important for the storage work in Linaro to fully test eMMC4.5 features. Still no luck. Kind regards Ulf Hansson

12 years, 4 months

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2012-12-31 to 2013-1-04

by Rajanikanth HV

==== Activity Summary ==== * Shawn Guo updated me on Runtime Size information for i.mx platform * Additional 2 patch of ab8500 DT has been accepted by anton * Working on MULTIPLATFORM enablement, presently looking into mach folder segregation and populating include/linux/platform_data/ folder accordingly * Discussion with ShawnGuo on MULTIPLATFORM config. ==== Plan ==== * Continue Adding Multiplatform Config support * Syncup with Linusw on Multiplatform Config ==== Issues ==== 1 Day holiday

12 years, 5 months

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2012-12-17 to 2012-12-21

by Rajanikanth HV

==== Activity Summary ==== * Completed "runtime size" data gathering across Vexpress-QEMU, i.MX and U8500 platforms * 3.7 is the kernel version verified across the said platforms * Thanks to Shawn Guo for providing statistics on i.MX platform * Google doc has been created and shared across relevant members * Looking into adding Multiplatform Config support for U8500 platform * Support for Rajagopal on Snowball board setup with tiny rootfs for his testing/verification. ==== Plan ==== * Collect inputs from linusw on MultiPlatform work done so far and continue to work ==== Issues ==== --- NA---

12 years, 5 months

1
1
0 0

[PATCH resend 0/3] ARM: KDB FIQ debugger

by Anton Vorontsov

Hello Andrew, Russell, Just resending this once again... (Also rebased onto v3.8-rc2, and since there were some irqdomain changes, I had to drop VIC changes from the series, and place the IRQ rerouting code into the board code. But that is even better, so far we don't need it anywhere else.) Short description of the KDB/FIQ debugger: The FIQ debugger is a facility that can be used to debug situations when the kernel stuck in uninterruptable sections, e.g. the kernel infinitely loops or deadlocked in an interrupt or with interrupts disabled. On some development boards there is even a special NMI button, which is very useful for debugging weird kernel hangs. And FIQ is basically an NMI, it has a higher priority than IRQs, and upon IRQ exception FIQs are not disabled. It is still possible to disable FIQs (as well as some "NMIs" on other architectures), but via special means. Old changelogs and a full rationale for these patches can be found here: v1-v5, rationale: http://lkml.org/lkml/2012/9/10/2 v6: http://lkml.org/lkml/2012/9/10/2 v7: http://lkml.org/lkml/2012/9/13/367 v8: http://lkml.org/lkml/2012/9/19/525 v9: http://lkml.org/lkml/2012/9/24/538 Thanks! Anton -- arch/arm/Kconfig | 19 ++++ arch/arm/include/asm/kgdb.h | 7 ++ arch/arm/kernel/Makefile | 1 + arch/arm/kernel/entry-armv.S | 167 +--------------------------- arch/arm/kernel/entry-header.S | 170 +++++++++++++++++++++++++++++ arch/arm/kernel/kgdb_fiq.c | 118 ++++++++++++++++++++ arch/arm/kernel/kgdb_fiq_entry.S | 87 +++++++++++++++ arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/kgdb_fiq.c | 55 ++++++++++ 9 files changed, 459 insertions(+), 166 deletions(-)

12 years, 5 months

1
3
0 0

[ACTIVITY] (John Stultz) Jan 2-4

by John Stultz

=== Highlights === * Now a Linaro Employee! * Fresh installed my client VM and personal netbook, got most of my work environment set up (still some minor tweaking to do). * Got local git trees re-generated * Generated base testing VM image * Ordered a build/test workstation for development * Talked with Ryan & emailed with Jakub about tree management plans * Generated a test branch updating the linaro.android tree to 3.8-rc2+ and sent it out for testing * Generated a new blueprint for alarm-dev compat_ioctl work === Plans === * Continue tweaking work environment config * Take a first pass swing at alarm-dev compat_ioctl work * Apply/review Minchan's latest anon volatile patch === Issues === * Having difficulty getting access to hackbox.linaro.org

12 years, 5 months

1
0
0 0

[ACTIVITY] (Linus Walleij) 2012-12-11 - 2013-01-04

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Sent pinctrl patches for v3.8 to Torvalds and he pulled them in. * Sent a first batch of updates for the -rc series for pinctrl as well and Torvalds has pulled in these too. * Grant has brough the pending GPIO patches upstream through his tree. * Inquiry into the state of CodeAurora's CoreSight patch set spurred a fruitful discussion and the author has posted a first patch set. * Working on multiplatform. So we have to take a step back: When the platform was migrated to SPARSE_IRQ all drivers should nominally have been converted to use irqdomain first. This was not the case: the AB8500 GPIO driver was missed (drivers/gpio/gpio-ab8500.c) So now it needs to be fixed. However it turns out that this driver has a number of problems, apart from being marked broken. So now I am working with Patrice Chotard and Lee Jones to reshape this driver into a proper pinctrl driver and put it into the pinctrl subsystem for v3.9. Created a blueprint for this: https://blueprints.launchpad.net/linux-linaro/+spec/ab8500-gpio-shapeup * Reviewed and back-merged a number of irqdomain and DT patches to the internel v3.4 baseline while interacting with the landing team. Now only AB8500 GPIO remains. * Reviewed and back-merged the timer-based delay patches that Fabio from the landing team has been working on. We have a pending patch series for these, which will be sent to ARM SoC ASAP. * Reviewed and back-merged Fabios sync work for the DMA40 driver. * Sent two fixes for the Nomadik post-v3.8 so it boots again. * Worked a bit on U300 cleanups. === Plans === * First fix the AB8500 mess. * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * Some internal stir and vacation has affected productivity the last month. Thanks, Linus Walleij

12 years, 5 months

1
0
0 0

Kernel compilation A15/NEON/vfpv4 etc.

by Mike Cain

Hi everyone, When building a kernel with the Linaro ARM toolchain I have two seemingly simple questions, however I have been getting some very different advice depending on who I talk to and what I read online, study in gits etc. Hardware specific optimizations are confusing and hard to test in a kernel since it such a multi-purpose conglomeration of code. I just want to make sure I am using the correct general approach before moving forward with trying things and testing. Our project is all about testing and researching ways to increase kernel/Android performance, so please don't reply with "just use an -O2 compilation and forget about it" unless you have data you can provide that suggest that this will give better performance than adding specific hardware compilation flags. Hopefully this is the right crowd to ask, wasn't sure if I should try the kernel or Android list. I posted in the NEON list, but my message is the only one from December! That leaves me with little hope there, so we'll see how it goes here. If anyone can help me with part 1 or part 2, I would be delighted! Background: * 3.4.x Android kernel * Qualcomm APQ8064 quad core CPU (Cortex A15-like SoC with NEON/vfpv4 per core support). * We are using the Linaro ARM toolchain 4.7.3 release 2012.11 on Linux (arm-linux-gnueabihf). Part 1) Which hardware and floating point compiler flags are recommended/applicable for the above mentioned SoC when building kernel itself? -mtune=cortex-a15 (is this really doing anything for us in the tool-chain's current state?) Which -mfpu flag and other associated flags should we use in the Linaro 12.11 toolchain? -mfpu=-neon-vfpv4 -mfpu=-vfpv4 -mfpu=-neon -mvectorize-with-neon-quad -funsafe-math-optimizations (is this required for -neon-vfpv4 and -vfpv4 like we would use it for plain old -neon?) Part 2) Next, which kernel Makefiles should be optimized using the hardware specific flags from Q1? From my research thus far, this is our current setup and we currently doing an -O2 build. /Makefile: KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -Werror-implicit-function-declaration \ -Wno-format-security \ -fno-delete-null-pointer-checks -mno-unaligned-access \ -march=armv7-a -mtune=cortex-a15 \ -fpredictive-commoning -fgcse-after-reload -ftree-vectorize \ -fipa-cp-clone -fsingle-precision-constant -pipe \ -funswitch-loops -floop-interchange \ -floop-strip-mine -floop-block CFLAGS_MODULE = (BLANK, but some say we should have flags here) AFLAGS_MODULE = (BLANK, but some say we should have flags here) LDFLAGS_MODULE = CFLAGS_KERNEL = (BLANK, but some say we should have flags here) AFLAGS_KERNEL = (BLANK, but some say we should have flags here) /arch/arm/Makefile arch-$(CONFIG_CPU_32v7) :=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-mtune=cortex-a15 -march=armv7-a -mfpu=neon-vfpv4 -ftree-vectorize -funsafe-math-optimizations,-march=armv7-a -Wa$(comma)-march=armv7-a) /arch/arm/vfp/Makefile KBUILD_AFLAGS :=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=neon-vfpv4 -ftree-vectorize -funsafe-math-optimizations) If you can give any advice, it would be greatly appreciated. Thanks and have a Happy New Year!

12 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel