[PATCH 1/1] staging: speakup: main.c - use time_after()
From: Anil Belur
- this patch fixes jiffies comparision with a safer function to prevent
any overflows
Signed-off-by: Anil Belur
---
drivers/staging/speakup/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 7de79d5..0cd3cdb 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2067,7 +2067,7 @@ speakup_key(struct vc_data *vc, int shift_state, int
keycode, u_short keysym,
if (up_flag)
goto out;
if (last_keycode == keycode &&
- last_spk_jiffy + MAX_DELAY > jiffies) {
+ time_after(last_spk_jiffy + MAX_DELAY, jiffies)) {
spk_close_press = 1;
offset = spk_shift_table[shift_info + 32];
/* double press? */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 4/5] power: max17040: Add ID for MAX77836 Fuel Gauge block
MAX77836 has the same Fuel Gauge as MAX17040/17048. The max17040 driver
can be safely re-used. The patch adds MAX77836 ID to array of
i2c_device_id.
Signed-off-by: Krzysztof Kozlowski
Cc: Kyungmin Park
Cc: Anton Vorontsov
Cc: Dmitry Eremin-Solenikov
Cc: David Woodhouse
---
drivers/power/max17040_battery.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/max17040_battery.c b/drivers/power/max17040_battery.c
index 0fbac861080d..165ffe381803 100644
--- a/drivers/power/max17040_battery.c
+++ b/drivers/power/max17040_battery.c
@@ -278,6 +278,7 @@ static SIMPLE_DEV_PM_OPS(max17040_pm_ops, max17040_suspend,
max17040_resume);
static const struct i2c_device_id max17040_id[] = {
{ "max17040", 0 },
+ { "max77836-battery", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, max17040_id);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 1/5] charger: max14577: Add support for MAX77836 charger
Add support for MAX77836 charger to the max14577 driver. The MAX77836
charger is almost the same as 14577 model except:
- No dead-battery detection;
- Support for special charger (like in MAX77693);
- Support for DX over-voltage protection (like in MAX77693);
- Lower values of charging current (two times lower current for
slow/fast charge, much lower EOC current);
- Slightly different values in ChgTyp field of STATUS2 register. On
MAX14577 0x6 is reserved and 0x7 dead battery. On the MAX77836 the
0x6 means special charger and 0x7 is reserved. Regardless of these
differences the driver maps them to one enum max14577_muic_charger_type.
Signed-off-by: Krzysztof Kozlowski
Cc: Kyungmin Park
Cc: Anton Vorontsov
Cc: Dmitry Eremin-Solenikov
Cc: David Woodhouse
Acked-by: Lee Jones
---
drivers/power/Kconfig| 4 +-
drivers/power/max14577_charger.c | 77 +---
include/linux/mfd/max14577-private.h | 54 ++---
3 files changed, 104 insertions(+), 31 deletions(-)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index ba6975123071..94086a5238c6 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -318,11 +318,11 @@ config CHARGER_MANAGER
with help of suspend_again support.
config CHARGER_MAX14577
- tristate "Maxim MAX14577 MUIC battery charger driver"
+ tristate "Maxim MAX14577/77836 battery charger driver"
depends on MFD_MAX14577
help
Say Y to enable support for the battery charger control sysfs and
- platform data of MAX14577 MUICs.
+ platform data of MAX14577/77836 MUICs.
config CHARGER_MAX8997
tristate "Maxim MAX8997/MAX8966 PMIC battery charger driver"
diff --git a/drivers/power/max14577_charger.c b/drivers/power/max14577_charger.c
index fad2a75b3604..19c8f42abf24 100644
--- a/drivers/power/max14577_charger.c
+++ b/drivers/power/max14577_charger.c
@@ -1,7 +1,7 @@
/*
- * Battery charger driver for the Maxim 14577
+ * max14577_charger.c - Battery charger driver for the Maxim 14577/77836
*
- * Copyright (C) 2013 Samsung Electronics
+ * Copyright (C) 2013,2014 Samsung Electronics
* Krzysztof Kozlowski
*
* This program is free software; you can redistribute it and/or modify
@@ -25,10 +25,35 @@ struct max14577_charger {
struct max14577 *max14577;
struct power_supply charger;
- unsigned intcharging_state;
- unsigned intbattery_state;
+ unsigned intcharging_state;
+ unsigned intbattery_state;
};
+/*
+ * Helper function for mapping values of STATUS2/CHGTYP register on max14577
+ * and max77836 chipsets to enum maxim_muic_charger_type.
+ */
+static enum max14577_muic_charger_type maxim_get_charger_type(
+ enum maxim_device_type dev_type, u8 val) {
+ switch (val) {
+ case MAX14577_CHARGER_TYPE_NONE:
+ case MAX14577_CHARGER_TYPE_USB:
+ case MAX14577_CHARGER_TYPE_DOWNSTREAM_PORT:
+ case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
+ case MAX14577_CHARGER_TYPE_SPECIAL_500MA:
+ case MAX14577_CHARGER_TYPE_SPECIAL_1A:
+ return val;
+ case MAX14577_CHARGER_TYPE_DEAD_BATTERY:
+ case MAX14577_CHARGER_TYPE_RESERVED:
+ if (dev_type == MAXIM_DEVICE_TYPE_MAX77836)
+ val |= 0x8;
+ return val;
+ default:
+ WARN_ONCE(1, "max14577: Unsupported chgtyp register value
0x%02x", val);
+ return val;
+ }
+}
+
static int max14577_get_charger_state(struct max14577_charger *chg)
{
struct regmap *rmap = chg->max14577->regmap;
@@ -89,19 +114,23 @@ static int max14577_get_online(struct max14577_charger
*chg)
{
struct regmap *rmap = chg->max14577->regmap;
u8 reg_data;
+ enum max14577_muic_charger_type chg_type;
max14577_read_reg(rmap, MAX14577_MUIC_REG_STATUS2, ®_data);
reg_data = ((reg_data & STATUS2_CHGTYP_MASK) >> STATUS2_CHGTYP_SHIFT);
- switch (reg_data) {
+ chg_type = maxim_get_charger_type(chg->max14577->dev_type, reg_data);
+ switch (chg_type) {
case MAX14577_CHARGER_TYPE_USB:
case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
case MAX14577_CHARGER_TYPE_SPECIAL_500MA:
case MAX14577_CHARGER_TYPE_SPECIAL_1A:
case MAX14577_CHARGER_TYPE_DEAD_BATTERY:
+ case MAX77836_CHARGER_TYPE_SPECIAL_BIAS:
return 1;
case MAX14577_CHARGER_TYPE_NONE:
case MAX14577_CHARGER_TYPE_DOWNSTREAM_PORT:
case MAX14577_CHARGER_TYPE_RESERVED:
+ case MAX77836_CHARGER_TYPE_RESERVED:
default:
return 0;
}
@@ -118,10 +147,12 @@ static int max14577_get_battery_health(struct
max14577_charger *chg)
struct regmap *rmap = chg->max14577->regmap;
int state = POWER_SUPPLY_HEALTH_GOOD;
u8 reg_data;
+ enum max14577_muic_charger_type chg_ty
[RESEND PATCH 2/5] regulator/mfd: max14577: Export symbols for calculating charger current
This patch prepares for changing the max14577 charger driver to allow
configuring battery-dependent settings from DTS.
The patch moves from regulator driver to MFD core driver and exports:
- function for calculating register value for charger's current;
- table of limits for chargers (MAX14577, MAX77836).
Previously they were used only by the max14577 regulator driver. In next
patch the charger driver will use them as well. Exporting them will
reduce unnecessary code duplication.
Signed-off-by: Krzysztof Kozlowski
Cc: Kyungmin Park
Acked-by: Mark Brown
Acked-by: Lee Jones
---
drivers/mfd/max14577.c | 95
drivers/regulator/max14577.c | 80 ++
include/linux/mfd/max14577-private.h | 22 -
include/linux/mfd/max14577.h | 23 +
4 files changed, 133 insertions(+), 87 deletions(-)
diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
index 4a5e885383f8..e6f25aa0ded8 100644
--- a/drivers/mfd/max14577.c
+++ b/drivers/mfd/max14577.c
@@ -26,6 +26,87 @@
#include
#include
+/*
+ * Table of valid charger currents for different Maxim chipsets.
+ * It is placed here because it is used by both charger and regulator driver.
+ */
+const struct maxim_charger_current maxim_charger_currents[] = {
+ [MAXIM_DEVICE_TYPE_UNKNOWN] = { 0, 0, 0, 0 },
+ [MAXIM_DEVICE_TYPE_MAX14577] = {
+ .min= MAX14577_CHARGER_CURRENT_LIMIT_MIN,
+ .high_start = MAX14577_CHARGER_CURRENT_LIMIT_HIGH_START,
+ .high_step = MAX14577_CHARGER_CURRENT_LIMIT_HIGH_STEP,
+ .max= MAX14577_CHARGER_CURRENT_LIMIT_MAX,
+ },
+ [MAXIM_DEVICE_TYPE_MAX77836] = {
+ .min= MAX77836_CHARGER_CURRENT_LIMIT_MIN,
+ .high_start = MAX77836_CHARGER_CURRENT_LIMIT_HIGH_START,
+ .high_step = MAX77836_CHARGER_CURRENT_LIMIT_HIGH_STEP,
+ .max= MAX77836_CHARGER_CURRENT_LIMIT_MAX,
+ },
+};
+EXPORT_SYMBOL_GPL(maxim_charger_currents);
+
+/*
+ * maxim_charger_calc_reg_current - Calculate register value for current
+ * @limits:constraints for charger, matching the MBCICHWRC register
+ * @min_ua:minimal requested current, micro Amps
+ * @max_ua:maximum requested current, micro Amps
+ * @dst: destination to store calculated register value
+ *
+ * Calculates the value of MBCICHWRC (Fast Battery Charge Current) register
+ * for given current and stores it under pointed 'dst'. The stored value
+ * combines low bit (MBCICHWRCL) and high bits (MBCICHWRCH). It is also
+ * properly shifted.
+ *
+ * The calculated register value matches the current which:
+ * - is always between ;
+ * - is always less or equal to max_ua;
+ * - is the highest possible value;
+ * - may be lower than min_ua.
+ *
+ * On success returns 0. On error returns -EINVAL (requested min/max current
+ * is outside of given charger limits) and 'dst' is not set.
+ */
+int maxim_charger_calc_reg_current(const struct maxim_charger_current *limits,
+ unsigned int min_ua, unsigned int max_ua, u8 *dst)
+{
+ unsigned int current_bits = 0xf;
+
+ if (min_ua > max_ua)
+ return -EINVAL;
+
+ if (min_ua > limits->max || max_ua < limits->min)
+ return -EINVAL;
+
+ if (max_ua < limits->high_start) {
+ /*
+* Less than high_start, so set the minimal current
+* (turn Low Bit off, 0 as high bits).
+*/
+ *dst = 0x0;
+ return 0;
+ }
+
+ /* max_ua is in range: , cut it to limits.max */
+ max_ua = min(limits->max, max_ua);
+ max_ua -= limits->high_start;
+ /*
+* There is no risk of overflow 'max_ua' here because:
+* - max_ua >= limits.high_start
+* - BUILD_BUG checks that 'limits' are: max >= high_start + high_step
+*/
+ current_bits = max_ua / limits->high_step;
+
+ /* Turn Low Bit on (use range ) ... */
+ *dst = 0x1 << CHGCTRL4_MBCICHWRCL_SHIFT;
+ /* and set proper High Bits */
+ *dst |= current_bits << CHGCTRL4_MBCICHWRCH_SHIFT;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(maxim_charger_calc_reg_current);
+
static const struct mfd_cell max14577_devs[] = {
{
.name = "max14577-muic",
@@ -463,6 +544,20 @@ static int __init max14577_i2c_init(void)
BUILD_BUG_ON(ARRAY_SIZE(max14577_i2c_id) != MAXIM_DEVICE_TYPE_NUM);
BUILD_BUG_ON(ARRAY_SIZE(max14577_dt_match) != MAXIM_DEVICE_TYPE_NUM);
+ /* Valid charger current values must be provided for each chipset */
+ BUILD_BUG_ON(ARRAY_SIZE(maxim_charger_currents) !=
MAXIM_DEVICE_TYPE_NUM);
+
+ /* Check for valid values for charger */
+ BUILD_BUG_ON(MAX14577_CHARGER_CURRENT_LIMIT_HIGH_START +
+ MAX14577_CHARGER_CURRENT_LIMIT_HIGH_STEP *
[RESEND PATCH 5/5] devicetree: mfd: max14577: Add device tree bindings document
Add document describing device tree bindings for MAX14577 MFD
drivers: MFD core, extcon, regulator and charger.
Both MAX14577 and MAX77836 chipsets are documented.
Signed-off-by: Krzysztof Kozlowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Reviewed-by: Tomasz Figa
---
Documentation/devicetree/bindings/mfd/max14577.txt | 152 +
1 file changed, 152 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max14577.txt
diff --git a/Documentation/devicetree/bindings/mfd/max14577.txt
b/Documentation/devicetree/bindings/mfd/max14577.txt
new file mode 100644
index ..b235250a7b41
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max14577.txt
@@ -0,0 +1,152 @@
+Maxim MAX14577/77836 Multi-Function Device
+
+MAX14577 is a Multi-Function Device with Micro-USB Interface Circuit, Li+
+Battery Charger and SFOUT LDO output for powering USB devices. It is
+interfaced to host controller using I2C.
+
+MAX77836 additionally contains PMIC (with two LDO regulators) and Fuel Gauge.
+
+
+Required properties:
+- compatible : Must be "maxim,max14577" or "maxim,max77836".
+- reg : I2C slave address for the max14577 chip (0x25 for max14577/max77836)
+- interrupts : IRQ line for the chip.
+- interrupt-parent : The parent interrupt controller.
+
+
+Required nodes:
+ - charger :
+ Node for configuring the charger driver.
+ Required properties:
+ - compatible : "maxim,max14577-charger"
+ or "maxim,max77836-charger"
+ - maxim,fast-charge-timer : Timer in hours to trigger the
+ INT3/MBCCHGERR interrupt; Valid values:
+ - 5, 6 or 7 (hours),
+ - 0 to disable.
+ - maxim,fast-charge-uamp : Current in uA for Fast Charge;
+ Valid values:
+ - for max14577: 9 - 95;
+ - for max77836: 45000 - 475000;
+ - maxim,eoc-uamp : Current in uA for End-Of-Charge mode;
+ Valid values:
+ - for max14577: 5 - 20;
+ - for max77836: 5000 - 10;
+ - maxim,ovp-uvolt : OverVoltage Protection Threshold in uV;
+ In an overvoltage condition, INT asserts and charging
+ stops. Valid values:
+ - 600, 650, 700, 750;
+ - maxim,constant-uvolt : Battery Constant Voltage in uV;
+ Valid values:
+ - 400 - 428 (step by 2);
+ - 435;
+
+
+Optional nodes:
+- max14577-muic/max77836-muic :
+ Node used only by extcon consumers.
+ Required properties:
+ - compatible : "maxim,max14577-muic" or "maxim,max77836-muic"
+
+- regulators :
+ Required properties:
+ - compatible : "maxim,max14577-regulator"
+ or "maxim,max77836-regulator"
+
+ May contain a sub-node per regulator from the list below. Each
+ sub-node should contain the constraints and initialization information
+ for that regulator. See regulator.txt for a description of standard
+ properties for these sub-nodes.
+
+ List of valid regulator names:
+ - for max14577: CHARGER, SAFEOUT.
+ - for max77836: CHARGER, SAFEOUT, LDO1, LDO2.
+
+ The SAFEOUT is a fixed voltage regulator so there is no need to specify
+ voltages for it.
+
+
+Example:
+
+#include
+
+max14577@25 {
+ compatible = "maxim,max14577";
+ reg = <0x25>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <5 IRQ_TYPE_NONE>;
+
+ muic: max14577-muic {
+ compatible = "maxim,max14577-muic";
+ };
+
+ regulators {
+ compatible = "maxim,max14577-regulator";
+
+ SAFEOUT {
+ regulator-name = "SAFEOUT";
+ };
+ CHARGER {
+ regulator-name = "CHARGER";
+ regulator-min-microamp = <9>;
+ regulator-max-microamp = <95>;
+ regulator-boot-on;
+ };
+ };
+
+ charger {
+ compatible = "maxim,max14577-charger";
+
+ maxim,fast-charge-timer = <6>;
+ maxim,constant-uvolt = <435>;
+ maxim,fast-charge-uamp = <45>;
+ maxim,eoc-uamp = <5>;
+ maxim,ovp-uvolt = <650>;
+ };
+};
+
+
+max77836@25 {
+ compatible = "maxim,max77836";
+ reg = <0x25>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <5 IRQ_TYPE_NONE>;
+
+ muic: max77836-muic {
+ compatible = "maxim,max77836-muic";
+ };
+
+ regulators {
+ compatible = "maxi
[RESEND PATCH 0/5] charger/mfd: max14577: Add support for MAX77836
Hi, This is resend of second part of patches adding support for MAX77836 device to the max14577 drivers. The first part (main MFD, extcon and regulator drivers) was merged already. The patches 1, 2 and 3 depends on each other so they should be pulled at once. Patches 4 and 5 can be applied independently. This patchset was already reviewed by some of the maintainers in during previous submissions. I only need acks from power tree (patches: 1, 3, 4). Changelog from previous submissions [1][2]: Changes since v4 1. Updated Kconfig entries mentioning MAX77836. 2. Added patch 5/6 (regulator: max14577: Implement SUSPEND mode for MAX77836 LDO-s) 3. Charger: Require a charger subnode in DTS with charger settings. Previously the charger driver didn't use any properties from DTS. Now it needs a subnode with settings because it supports different devices with different charging characteristics. 4. Rebased on 3.15-rc2. Changes since v3 1. Applied minor fixes (pointed by Lee Jones). 2. Added one ACK (Lee Jones) and Review-by (Tomasz Figa). 3. Patch 14/charger: Minor change in parsing EOC value from DTS. 4. Rebased on next-20140224. Changes since v2 1. Added ACK-s. 2. Applied minor checkpatch fixes (pointed by Lee Jones). 3. Rebased on next-20140217. Changes since v1 1. Added ACK-s, reviews and tested-by tags. 2. Removed applied patches (they were merged to the linux-next tree). 3. Applied comments from review (Lee Jones) to 5/15 (detection of device type) and 8/15 (add max77836 support to max14577). 4. Rebased on next tree. 5. Added patch 13 and 14 (pointed by Jenny Tc): - regulator/mfd: max14577: Export symbols for calculating charger current - charger: max14577: Configure battery-dependent settings from DTS 6. Updated bindings documentation with new charger bindings. References == [1] http://thread.gmane.org/gmane.linux.kernel/1689130 [2] http://thread.gmane.org/gmane.linux.kernel/1682503 Best regards, Krzysztof Kozlowski Krzysztof Kozlowski (5): charger: max14577: Add support for MAX77836 charger regulator/mfd: max14577: Export symbols for calculating charger current charger: max14577: Configure battery-dependent settings from DTS power: max17040: Add ID for MAX77836 Fuel Gauge block devicetree: mfd: max14577: Add device tree bindings document Documentation/devicetree/bindings/mfd/max14577.txt | 152 +++ drivers/mfd/max14577.c | 100 ++- drivers/power/Kconfig | 4 +- drivers/power/max14577_charger.c | 291 ++--- drivers/power/max17040_battery.c | 1 + drivers/regulator/max14577.c | 80 +- include/linux/mfd/max14577-private.h | 92 +-- include/linux/mfd/max14577.h | 31 +++ 8 files changed, 614 insertions(+), 137 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/max14577.txt -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 3/5] charger: max14577: Configure battery-dependent settings from DTS
Remove hard-coded values for:
- Fast Charge current,
- End Of Charge current,
- Fast Charge timer,
- Overvoltage Protection Threshold,
- Battery Constant Voltage,
and use DTS to configure them. This allows using the max14577 charger
driver with different batteries.
Now the charger driver requires valid configuration data from DTS. In
case of wrong configuration data it fails during probe. Patch adds
of_compatible to the charger mfd cell in MFD driver core.
Signed-off-by: Krzysztof Kozlowski
Cc: Kyungmin Park
Cc: Dmitry Eremin-Solenikov
Cc: David Woodhouse
Cc: Jenny Tc
Acked-by: Lee Jones
---
drivers/mfd/max14577.c | 5 +-
drivers/power/max14577_charger.c | 232 +++
include/linux/mfd/max14577-private.h | 16 +++
include/linux/mfd/max14577.h | 8 ++
4 files changed, 233 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
index e6f25aa0ded8..b8af263be594 100644
--- a/drivers/mfd/max14577.c
+++ b/drivers/mfd/max14577.c
@@ -116,7 +116,10 @@ static const struct mfd_cell max14577_devs[] = {
.name = "max14577-regulator",
.of_compatible = "maxim,max14577-regulator",
},
- { .name = "max14577-charger", },
+ {
+ .name = "max14577-charger",
+ .of_compatible = "maxim,max14577-charger",
+ },
};
static const struct mfd_cell max77836_devs[] = {
diff --git a/drivers/power/max14577_charger.c b/drivers/power/max14577_charger.c
index 19c8f42abf24..f32f94a9a144 100644
--- a/drivers/power/max14577_charger.c
+++ b/drivers/power/max14577_charger.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
struct max14577_charger {
struct device *dev;
@@ -27,6 +28,8 @@ struct max14577_charger {
unsigned intcharging_state;
unsigned intbattery_state;
+
+ struct max14577_charger_platform_data *pdata;
};
/*
@@ -178,15 +181,107 @@ static int max14577_get_present(struct max14577_charger
*chg)
return 1;
}
+static inline int max14577_init_constant_voltage(struct max14577_charger *chg,
+ unsigned int uvolt)
+{
+ u8 reg_data;
+
+ if (uvolt < MAXIM_CHARGER_CONSTANT_VOLTAGE_MIN ||
+ uvolt > MAXIM_CHARGER_CONSTANT_VOLTAGE_MAX)
+ return -EINVAL;
+
+ if (uvolt == 420)
+ reg_data = 0x0;
+ else if (uvolt == MAXIM_CHARGER_CONSTANT_VOLTAGE_MAX)
+ reg_data = 0x1f;
+ else if (uvolt <= 428) {
+ unsigned int val = uvolt;
+
+ val -= MAXIM_CHARGER_CONSTANT_VOLTAGE_MIN;
+ val /= MAXIM_CHARGER_CONSTANT_VOLTAGE_STEP;
+ if (uvolt <= 418)
+ reg_data = 0x1 + val;
+ else
+ reg_data = val; /* Fix for gap between 4.18V and 4.22V
*/
+ } else
+ return -EINVAL;
+
+ reg_data <<= CHGCTRL3_MBCCVWRC_SHIFT;
+
+ return max14577_write_reg(chg->max14577->regmap,
+ MAX14577_CHG_REG_CHG_CTRL3, reg_data);
+}
+
+static inline int max14577_init_eoc(struct max14577_charger *chg,
+ unsigned int uamp)
+{
+ unsigned int current_bits = 0xf;
+ u8 reg_data;
+
+ switch (chg->max14577->dev_type) {
+ case MAXIM_DEVICE_TYPE_MAX77836:
+ if (uamp < 5000)
+ return -EINVAL; /* Requested current is too low */
+
+ if (uamp >= 7500 && uamp < 1)
+ current_bits = 0x0;
+ else if (uamp <= 5) {
+ /* <5000, 7499> and <1, 5> */
+ current_bits = uamp / 5000;
+ } else {
+ uamp = min(uamp, 10U) - 5U;
+ current_bits = 0xa + uamp / 1;
+ }
+ break;
+
+ case MAXIM_DEVICE_TYPE_MAX14577:
+ default:
+ if (uamp < MAX14577_CHARGER_EOC_CURRENT_LIMIT_MIN)
+ return -EINVAL; /* Requested current is too low */
+
+ uamp = min(uamp, MAX14577_CHARGER_EOC_CURRENT_LIMIT_MAX);
+ uamp -= MAX14577_CHARGER_EOC_CURRENT_LIMIT_MIN;
+ current_bits = uamp / MAX14577_CHARGER_EOC_CURRENT_LIMIT_STEP;
+ break;
+ }
+
+ reg_data = current_bits << CHGCTRL5_EOCS_SHIFT;
+
+ return max14577_update_reg(chg->max14577->regmap,
+ MAX14577_CHG_REG_CHG_CTRL5, CHGCTRL5_EOCS_MASK,
+ reg_data);
+}
+
+static inline int max14577_init_fast_charge(struct max14577_charger *chg,
+ unsigned int uamp)
+{
+ u8 reg_data;
+ int ret;
+ const struct maxim_charger_current *limits =
+ &maxim_charger_currents[chg->max14577->dev_type];
+
+ ret = maxim_charger_calc_reg_current(limits, uamp, uamp, ®_data);
+ if
Re: [PATCH] pinctrl: pinctrl-imx27.c: Cleaning up remove a struct that is unused
On Sat, Jun 28, 2014 at 11:48:40PM +0200, Rickard Strandqvist wrote:
> Removal of a struct that is never used
>
> This was found using a static code analysis program called cppcheck
>
> Signed-off-by: Rickard Strandqvist
It wasn't even used on the initial commit introducing it.
Acked-by: Sascha Hauer
Sascha
> ---
> drivers/pinctrl/pinctrl-imx27.c |6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-imx27.c b/drivers/pinctrl/pinctrl-imx27.c
> index 417c992..27ae7ce 100644
> --- a/drivers/pinctrl/pinctrl-imx27.c
> +++ b/drivers/pinctrl/pinctrl-imx27.c
> @@ -440,12 +440,6 @@ static struct of_device_id imx27_pinctrl_of_match[] = {
> { /* sentinel */ }
> };
>
> -struct imx27_pinctrl_private {
> - int num_gpio_childs;
> - struct platform_device **gpio_dev;
> - struct mxc_gpio_platform_data *gpio_pdata;
> -};
> -
> static int imx27_pinctrl_probe(struct platform_device *pdev)
> {
> return imx1_pinctrl_core_probe(pdev, &imx27_pinctrl_info);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 RESEND] staging: lirc: fix checkpath errors: blank lines
This patch fix checkpath "WARNING: Missing a blank line after declarations"
Signed-off-by: Raphaël Poggi
---
drivers/staging/media/lirc/lirc_imon.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
index a5b62ee..f8c3375 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -189,6 +189,7 @@ MODULE_PARM_DESC(debug, "Debug messages: 0=no,
1=yes(default: no)");
static void free_imon_context(struct imon_context *context)
{
struct device *dev = context->driver->dev;
+
usb_free_urb(context->tx_urb);
usb_free_urb(context->rx_urb);
lirc_buffer_free(context->driver->rbuf);
@@ -656,6 +657,7 @@ static void imon_incoming_packet(struct imon_context
*context,
mask = 0x80;
for (bit = 0; bit < 8; ++bit) {
int curr_bit = !(buf[octet] & mask);
+
if (curr_bit != context->rx.prev_bit) {
if (context->rx.count) {
submit_data(context);
@@ -775,6 +777,7 @@ static int imon_probe(struct usb_interface *interface,
struct usb_endpoint_descriptor *ep;
int ep_dir;
int ep_type;
+
ep = &iface_desc->endpoint[i].desc;
ep_dir = ep->bEndpointAddress & USB_ENDPOINT_DIR_MASK;
ep_type = ep->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2 RESEND] staging: lirc: remove return void function
This patch fix checkpath "WARNING: void function return statements are not generally useful". The removed return were useless in that case. Signed-off-by: Raphaël Poggi --- drivers/staging/media/lirc/lirc_imon.c |6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_imon.c b/drivers/staging/media/lirc/lirc_imon.c index f8c3375..96c76b3 100644 --- a/drivers/staging/media/lirc/lirc_imon.c +++ b/drivers/staging/media/lirc/lirc_imon.c @@ -482,8 +482,6 @@ static void usb_tx_callback(struct urb *urb) /* notify waiters that write has finished */ atomic_set(&context->tx.busy, 0); complete(&context->tx.finished); - - return; } /** @@ -548,7 +546,6 @@ static void ir_close(void *data) } mutex_unlock(&context->ctx_lock); - return; } /** @@ -573,7 +570,6 @@ static void submit_data(struct imon_context *context) lirc_buffer_write(context->driver->rbuf, buf); wake_up(&context->driver->rbuf->wait_poll); - return; } static inline int tv2int(const struct timeval *a, const struct timeval *b) @@ -709,8 +705,6 @@ static void usb_rx_callback(struct urb *urb) } usb_submit_urb(context->rx_urb, GFP_ATOMIC); - - return; } /** -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1] PCI: enable ASPM configuration in PCIE POWERSAVE mode
commit 1a680b7c moved pcie_aspm_powersave_config_link() out of
pci_raw_set_power_state() to pci_set_power_state() which would enable
ASPM. But, with commit db288c9c, which re-introduced the following check
./drivers/pci/pci.c: pci_set_power_state()
+ /* Check if we're already there */
+ if (dev->current_state == state)
+ return 0;
in pci_set_power_state(), call to pcie_aspm_powersave_config_link() is never
made leaving ASPM broken.
Fix it by not returning from when the above condition is true, rather, jump to
ASPM configuration code and exit from there eventually.
Signed-off-by: Vidya Sagar
---
drivers/pci/pci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 1c8592b..ded24c4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -804,7 +804,7 @@ EXPORT_SYMBOL_GPL(__pci_complete_power_transition);
*/
int pci_set_power_state(struct pci_dev *dev, pci_power_t state)
{
- int error;
+ int error = 0;
/* bound the state we're entering */
if (state > PCI_D3cold)
@@ -821,7 +821,7 @@ int pci_set_power_state(struct pci_dev *dev, pci_power_t
state)
/* Check if we're already there */
if (dev->current_state == state)
- return 0;
+ goto config_aspm;
__pci_start_power_transition(dev, state);
@@ -839,6 +839,8 @@ int pci_set_power_state(struct pci_dev *dev, pci_power_t
state)
if (!__pci_complete_power_transition(dev, state))
error = 0;
+
+config_aspm:
/*
* When aspm_policy is "powersave" this call ensures
* that ASPM is configured.
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] clk: Introduce 'clk_find_nearest_rate()'
On Tue, 1 Jul 2014 08:32:14 +0200
Boris BREZILLON wrote:
> Hi Sören,
>
> On Mon, 30 Jun 2014 17:12:23 -0700
> Sören Brinkmann wrote:
>
> > Hi Boris,
> >
> > On Mon, 2014-06-30 at 09:27PM +0200, Boris BREZILLON wrote:
> > > Hello Soren,
> > >
> > > On Mon, 30 Jun 2014 09:56:33 -0700
> > > Soren Brinkmann wrote:
> > >
> > > > Introduce a new API function to find the rate a clock can
> > > > provide which is closest to a given rate.
> > > >
> > > > clk_round_rate() leaves it to the clock driver how rounding is
> > > > done. Commonly implementations round down due to use-cases that
> > > > have a certain frequency maximum that must not be exceeded.
> > >
> > > I had the same concern (how could a driver decide whether it
> > > should round up, down or to the closest value), but had a slightly
> > > different approach in mind.
> > >
> > > AFAIU, you're assuming the clock is always a power of two (which
> > > is true most of the time, but some clock implementation might
> > > differ, i.e. a PLL accept any kind of multiplier not necessarily
> > > a power of 2).
> >
> > No, the idea is to always work. There should not be any such
> > limitation. Where do you see that?
>
> My bad, I should have read the code more carefully.
> BTW, it could help readers if you add some comments to explain how you
> are finding the nearest rate.
>
> My main concern with this approach is that you can spend some time
> iterating to find the nearest rate where a clk driver would find it
> quite quickly (because it knows exactly how the clk works and what are
> the possible clk muxing and clk modifiers options).
>
> >
> > >
> > > How about improving the clk_ops interface instead by adding a new
> > > method
> > >
> > > long (*round_rate_with_constraint)(struct clk_hw *hw,
> > > unsigned long
> > > requested_rate, unsigned long *parent_rate,
> > > enum clk_round_type
> > > type);
> > >
> > > with
> > >
> > > enum clk_round_type {
> > > CLK_ROUND_DOWN,
> > > CLK_ROUND_UP,
> > > CLK_ROUND_CLOSEST,
> > > };
> >
> > I thought about that, but the find_nearest() did already exist more
> > or less and in the end it is not much of a difference, IMHO. If it
> > turns out that the others are needed as well and somebody
> > implements it, they could be added as another convenience function
> > like I did, and/or it could be wrapped in the function you propose
> > here.
> >
> > >
> > > or just adding these 3 methods:
> > >
> > > long (*round_rate_up)(struct clk_hw *hw,
> > > unsigned long requested_rate,
> > > unsigned long *parent_rate);
> > >
> > > long (*round_rate_down)(struct clk_hw *hw,
> > > unsigned long requested_rate,
> > > unsigned long *parent_rate);
> > >
> > > long (*round_rate_closest)(struct clk_hw *hw,
> > > unsigned long requested_rate,
> > > unsigned long *parent_rate);
> >
> > That would be quite a change for clock drivers. So far, there are
> > not many restrictions on round_rate. I think there has already been
> > a discussion in this direction that went nowhere.
> > https://lkml.org/lkml/2010/7/14/260
> >
>
> Not if we keep these (or this, depending on the solution you chose)
> functions optional, and return -ENOTSUP, if they're not implemented.
Or even better: fall back to your implementation.
>
> > >
> > > and let the round_rate method implement the default behaviour.
> >
> > There is no real default. Rounding is not specified for the current
> > API.
>
> What I meant by default behavior is the behavior already implemented
> by the clock driver (either round up, down or closest).
> This way you do not introduce regressions with existing users, and can
> use new methods in new use cases.
>
> >
> > >
> > > This way you could add 3 functions to the API:
> > >
> > > clk_round_closest (or clk_find_nearest_rate as you called it),
> > > clk_round_up and clk_round_down, and let the clk driver
> > > implementation return the appropriate rate.
> >
> > I'd say the current patch set does kind of align with that, doesn't
> > it? We can add the find_nearest_rate() (there was a discussion on
> > the name, ane we decided against round_closest in favor of the
> > current proposal) now and the other functions could be added later
> > if people find them to be useful. And if they all get added we can
> > think about consolidating them if it made sense.
>
> Yes sure.
>
> Best Regards,
>
> Boris
>
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC net-next 00/14] BPF syscall, maps, verifier, samples
On 07/01/2014 01:09 AM, Kees Cook wrote: On Fri, Jun 27, 2014 at 5:05 PM, Alexei Starovoitov wrote: Hi All, this patch set demonstrates the potential of eBPF. First patch "net: filter: split filter.c into two files" splits eBPF interpreter out of networking into kernel/bpf/. The goal for BPF subsystem is to be usable in NET-less configuration. Though the whole set is marked is RFC, the 1st patch is good to go. Similar version of the patch that was posted few weeks ago, but was deferred. I'm assuming due to lack of forward visibility. I hope that this patch set shows what eBPF is capable of and where it's heading. Other patches expose eBPF instruction set to user space and introduce concepts of maps and programs accessible via syscall. 'maps' is a generic storage of different types for sharing data between kernel and userspace. Maps are referrenced by global id. Root can create multiple maps of different types where key/value are opaque bytes of data. It's up to user space and eBPF program to decide what they store in the maps. eBPF programs are similar to kernel modules. They live in global space and have unique prog_id. Each program is a safe run-to-completion set of instructions. eBPF verifier statically determines that the program terminates and safe to execute. During verification the program takes a hold of maps that it intends to use, so selected maps cannot be removed until program is unloaded. The program can be attached to different events. These events can be packets, tracepoint events and other types in the future. New event triggers execution of the program which may store information about the event in the maps. Beyond storing data the programs may call into in-kernel helper functions which may, for example, dump stack, do trace_printk or other forms of live kernel debugging. Same program can be attached to multiple events. Different programs can access the same map: tracepoint tracepoint tracepointsk_buffsk_buff event A event B event C on eth0on eth1 | | || | | | || | --> tracing <-- tracing socket socket prog_1 prog_2 prog_3 prog_4 | | || |--- -| |---| map_3 map_1 map_2 User space (via syscall) and eBPF programs access maps concurrently. Last two patches are sample code. 1st demonstrates stateful packet inspection. It counts tcp and udp packets on eth0. Should be easy to see how this eBPF framework can be used for network analytics. 2nd sample does simple 'drop monitor'. It attaches to kfree_skb tracepoint event and counts number of packet drops at particular $pc location. User space periodically summarizes what eBPF programs recorded. In these two samples the eBPF programs are tiny and written in 'assembler' with macroses. More complex programs can be written C (llvm backend is not part of this diff to reduce 'huge' perception). Since eBPF is fully JITed on x64, the cost of running eBPF program is very small even for high frequency events. Here are the numbers comparing flow_dissector in C vs eBPF: x86_64 skb_flow_dissect() same skb (all cached) - 42 nsec per call x86_64 skb_flow_dissect() different skbs (cache misses) - 141 nsec per call eBPF+jit skb_flow_dissect() same skb (all cached) - 51 nsec per call eBPF+jit skb_flow_dissect() different skbs (cache misses) - 135 nsec per call Detailed explanation on eBPF verifier and safety is in patch 08/14 This is very exciting! Thanks for working on it. :) Between the new eBPF syscall and the new seccomp syscall, I'm really looking forward to using lookup tables for seccomp filters. Under certain types of filters, we'll likely see some non-trivial performance improvements. Well, if I read this correctly, the eBPF syscall lets you set up maps, etc, but the only way to attach eBPF is via setsockopt for network filters right now (and via tracing). Seccomp will still make use of classic BPF, so you won't be able to use it there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] USB: ehci-pci: USB host controller support for Intel Quark X1000
From: Bryan O'Donoghue
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host controller, and the default value is 0x20 dwords. The in/out threshold
can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
but only when isochronous/interrupt transactions are not initiated by the USB
host controller. This patch is to reconfigure the packet buffer in/out
threshold as maximal as possible to maximize the performance, and 0x7F dwords
(508 Bytes) should be used because the USB host controller initiates
isochronous/interrupt transactions.
Signed-off-by: Bryan O'Donoghue
Signed-off-by: Alvin (Weike) Chen
---
changelog v4:
* Just define the maximum threshold value, and clarify it in the comments.
* Improve the comments.
drivers/usb/host/ehci-pci.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 3e86bf4..429434d 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -35,6 +35,21 @@ static const char hcd_name[] = "ehci-pci";
#define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
/*-*/
+#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
+static inline bool is_intel_quark_x1000(struct pci_dev *pdev)
+{
+ return pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
+}
+
+/*
+ * 0x84 is the offset of in/out threshold register,
+ * and it is the same offset as the register of 'hostpc'.
+ */
+#defineintel_quark_x1000_insnreg01 hostpc
+
+/* Maximum usable threshold value is 0x7f dwords for both IN and OUT */
+#define INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD 0x007f007f
/* called after powerup, by probe or system-pm "wakeup" */
static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
@@ -50,6 +65,16 @@ static int ehci_pci_reinit(struct ehci_hcd *ehci, struct
pci_dev *pdev)
if (!retval)
ehci_dbg(ehci, "MWI active\n");
+ /* Reset the threshold limit */
+ if (is_intel_quark_x1000(pdev)) {
+ /*
+* For the Intel QUARK X1000, raise the I/O threshold to the
+* maximum usable value in order to improve performance.
+*/
+ ehci_writel(ehci, INTEL_QUARK_X1000_EHCI_MAX_THRESHOLD,
+ ehci->regs->intel_quark_x1000_insnreg01);
+ }
+
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] USB: ehci-pci: Add support for Intel Quark X1000 USB
From: "Alvin (Weike) Chen" Hi, Intel Quark X1000 consists of one USB host controller which can be PCI enumerated. And the exsiting EHCI-PCI framework supports it with the default packet buffer in/out threshold. We reconfigure the in/out threshold as maximal as possible to maximize the performance. Bryan O'Donoghue (1): USB: ehci-pci: USB host controller support for Intel Quark X1000 drivers/usb/host/ehci-pci.c | 25 +++ 1 file changed, 25 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] staging: rtl8723au: Another case of unnecessary null test before kfree
Fabian Frederick writes: > Fix checkpatch warning: > WARNING: kfree(NULL) is safe this check is probably not required > > Cc: Larry Finger > Cc: Jes Sorensen > Cc: linux-wirel...@vger.kernel.org > Signed-off-by: Fabian Frederick > --- > drivers/staging/rtl8723au/core/rtw_ap.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c > b/drivers/staging/rtl8723au/core/rtw_ap.c > index c8700b3..8714ae3 100644 > --- a/drivers/staging/rtl8723au/core/rtw_ap.c > +++ b/drivers/staging/rtl8723au/core/rtw_ap.c > @@ -1270,8 +1270,7 @@ static void update_bcn_wps_ie(struct rtw_adapter > *padapter) > pnetwork->IELength = wps_offset + (wps_ielen+2) + > remainder_ielen; > } > > - if (pbackup_remainder_ie) > - kfree(pbackup_remainder_ie); > + kfree(pbackup_remainder_ie); > } > > static void update_bcn_p2p_ie(struct rtw_adapter *padapter) This one is no longer an issue due to other changes in my tree. Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] staging: rtl8723au: Remove unnecessary null test before kfree
Fabian Frederick writes:
> Fix checkpatch warning:
> WARNING: kfree(NULL) is safe this check is probably not required
>
> Cc: Larry Finger
> Cc: Jes Sorensen
> Cc: linux-wirel...@vger.kernel.org
> Signed-off-by: Fabian Frederick
> ---
> drivers/staging/rtl8723au/core/rtw_cmd.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
> b/drivers/staging/rtl8723au/core/rtw_cmd.c
> index 1696cb8..6af2b4a 100644
> --- a/drivers/staging/rtl8723au/core/rtw_cmd.c
> +++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
> @@ -516,9 +516,7 @@ int rtw_joinbss_cmd23a(struct rtw_adapter *padapter,
>
> psecnetwork = &psecuritypriv->sec_bss;
> if (!psecnetwork) {
> - if (pcmd)
> - kfree(pcmd);
> -
> + kfree(pcmd);
> res = _FAIL;
>
> RT_TRACE(_module_rtl871x_cmd_c_, _drv_err_,
Thanks, I applied this one to the rtl8723au tree.
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware loader: inform direct failure when udev loader is disabled
On Tue, Jul 1, 2014 at 1:30 AM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> Now that the udev firmware loader is optional request_firmware()
> will not provide any information on the kernel ring buffer if
> direct firmware loading failed and udev firmware loading is disabled.
> If no information is needed request_firmware_direct() should be used
> for optional firmware, at which point drivers can take on the onus
> over informing of any failures, if udev firmware loading is disabled
> though we should at the very least provide some sort of information
> as when the udev loader was enabled by default back in the days.
>
> With this change with a simple firmware load test module [0]:
>
> Example output without FW_LOADER_USER_HELPER_FALLBACK
>
> platform fake-dev.0: Direct firmware load for fake.bin failed with error -2
>
> Example without FW_LOADER_USER_HELPER_FALLBACK
This ^^ should be "Example output with [...]" ?
Otherwise looks good, so:
Reviewed-by: Tom Gundersen
> platform fake-dev.0: Direct firmware load for fake.bin failed with error -2
> platform fake-dev.0: Falling back to user helper
>
> Without this change without FW_LOADER_USER_HELPER_FALLBACK we get no output
> logged upon failure.
>
> [0] https://github.com/mcgrof/fake-firmware-test.git
>
> Cc: Tom Gundersen
> Cc: Ming Lei
> Cc: Greg Kroah-Hartman
> Cc: Abhay Salunke
> Cc: Stefan Roese
> Cc: Arnd Bergmann
> Cc: Kay Sievers
> Cc: Takashi Iwai
> Signed-off-by: Luis R. Rodriguez
> ---
>
> drivers/base/firmware_class.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 46ea5f4..23274d8 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -101,8 +101,10 @@ static inline long firmware_loading_timeout(void)
> #define FW_OPT_NOWAIT (1U << 1)
> #ifdef CONFIG_FW_LOADER_USER_HELPER
> #define FW_OPT_USERHELPER (1U << 2)
> +#define FW_OPT_FAIL_WARN 0
> #else
> #define FW_OPT_USERHELPER 0
> +#define FW_OPT_FAIL_WARN (1U << 3)
> #endif
> #ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
> #define FW_OPT_FALLBACKFW_OPT_USERHELPER
> @@ -1116,10 +1118,11 @@ _request_firmware(const struct firmware **firmware_p,
> const char *name,
>
> ret = fw_get_filesystem_firmware(device, fw->priv);
> if (ret) {
> - if (opt_flags & FW_OPT_USERHELPER) {
> + if (opt_flags & (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER))
> dev_warn(device,
> -"Direct firmware load failed with error
> %d\n",
> -ret);
> +"Direct firmware load for %s failed with
> error %d\n",
> +name, ret);
> + if (opt_flags & FW_OPT_USERHELPER) {
> dev_warn(device, "Falling back to user helper\n");
> ret = fw_load_from_user_helper(fw, name, device,
>opt_flags, timeout);
> @@ -1170,7 +1173,8 @@ request_firmware(const struct firmware **firmware_p,
> const char *name,
> /* Need to pin this module until return */
> __module_get(THIS_MODULE);
> ret = _request_firmware(firmware_p, name, device,
> - FW_OPT_UEVENT | FW_OPT_FALLBACK);
> + FW_OPT_UEVENT | FW_OPT_FALLBACK |
> + FW_OPT_FAIL_WARN);
> module_put(THIS_MODULE);
> return ret;
> }
> --
> 2.0.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/12] usb: chipidea: add a generic driver
Peter,
On Tue, Jul 01, 2014 at 08:21:14AM +0800, Peter Chen wrote:
> On Mon, Jun 30, 2014 at 03:33:13PM +0200, Antoine Ténart wrote:
> > On Fri, Jun 27, 2014 at 11:25:07AM +0800, Peter Chen wrote:
> > > On Tue, Jun 24, 2014 at 12:35:16PM +0200, Antoine Ténart wrote:
> > > >
> > > > ifneq ($(CONFIG_OF),)
> > > > obj-$(CONFIG_USB_CHIPIDEA) += usbmisc_imx.o ci_hdrc_imx.o
> > > > + obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_generic.o
> > > > endif
> > >
> > > As a generic driver, you may need to support both dt and non-dt
> > > solution.
> >
> > Since the dt is now the best practice and since there is no need (yet)
> > for a non-dt usage of this driver shouldn't we let anyone needing it
> > implement it when the time comes?
> >
>
> No, at least your code structure should support both dt and non-dt,
> and let the compile pass for non-dt platform if you don't have one.
> Then, someone with non-dt platform can change few to support it.
> A good example is: drivers/usb/host/ehci-platform.c
Ok. I'll isolate dt-specific code in the probe, and remove the CONFIG_OF
dependency.
>
> > > > +static int ci_hdrc_generic_probe(struct platform_device *pdev)
> > > > +{
> > > > + struct device *dev = &pdev->dev;
> > > > + struct ci_hdrc_generic_priv *priv;
> > > > + struct ci_hdrc_platform_data ci_pdata = {
> > > > + .name = "ci_hdrc",
> > >
> > > How about this using dev_name(&pdev->dev) for name?
> >
> > Yes, why not. I don't have a strong preference.
> >
> > > > +
> > > > +clk_err:
> > > > + clk_disable_unprepare(priv->clk);
> > >
> > > You may need to add "if (!IS_ERR(priv->clk))"
> >
> > Right! I'll update this.
> >
> > > > +
> > > > +static const struct of_device_id ci_hdrc_generic_of_match[] = {
> > > > + { .compatible = "chipidea-usb" },
> > > > + { }
> > > > +};
> > >
> > > Even as a generic driver, you can also use your own compatible string.
> >
> > Well, there is nothing specific about the Berlin CI. Some subsystems
> > use the 'generic' keyword in these cases. Do you see a particular reason
> > I should use some Berlin related compatible here?
> >
>
> Not must, one suggestion is: can you change the compatible string
> to "chipidea-usb-generic"?
Sounds good, I'll update.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 2/2] dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller
On Mon, Jun 30, 2014 at 04:33:05PM +0100, Mark Rutland wrote:
> On Mon, Jun 30, 2014 at 04:19:06PM +0100, Maxime Ripard wrote:
> > On Mon, Jun 30, 2014 at 03:20:54PM +0100, Mark Rutland wrote:
> > > Hi Maxime,
> > >
> > > On Mon, Jun 30, 2014 at 02:20:54PM +0100, Maxime Ripard wrote:
> > > > The Allwinner A31 has a 16 channels DMA controller that it shares with
> > > > the
> > > > newer A23. Although sharing some similarities with the DMA controller
> > > > of the
> > > > older Allwinner SoCs, it's significantly different, I don't expect it
> > > > to be
> > > > possible to share the driver for these two.
> > > >
> > > > The A31 Controller is able to memory-to-memory or memory-to-device
> > > > transfers on
> > > > the 16 channels in parallel.
> > > >
> > > > Signed-off-by: Maxime Ripard
> > > > Acked-by: Arnd Bergmann
> > > > ---
> > > > drivers/dma/Kconfig |8 +
> > > > drivers/dma/Makefile|1 +
> > > > drivers/dma/sun6i-dma.c | 1058
> > > > +++
> > > > 3 files changed, 1067 insertions(+)
> > > > create mode 100644 drivers/dma/sun6i-dma.c
> > >
> > > [...]
> > >
> > > > + sdc->clk = devm_clk_get(&pdev->dev, NULL);
> > > > + if (IS_ERR(sdc->clk)) {
> > > > + dev_err(&pdev->dev, "No clock specified\n");
> > > > + return PTR_ERR(sdc->clk);
> > > > + }
> > > > +
> > > > + mux = clk_get(NULL, "ahb1_mux");
> > > > + if (IS_ERR(mux)) {
> > > > + dev_err(&pdev->dev, "Couldn't get AHB1 Mux\n");
> > > > + return PTR_ERR(mux);
> > > > + }
> > > > +
> > > > + pll6 = clk_get(NULL, "pll6");
> > > > + if (IS_ERR(pll6)) {
> > > > + dev_err(&pdev->dev, "Couldn't get PLL6\n");
> > > > + clk_put(mux);
> > > > + return PTR_ERR(pll6);
> > > > + }
> > >
> > > I'm slightly confused. The binding listed a single unnamed clock (the
> > > AHB clock). What is going on here?
> >
> > The device itself needs only a single clock to work...
> >
> > >
> > > > + ret = clk_set_parent(mux, pll6);
> > > > + clk_put(pll6);
> > > > + clk_put(mux);
> > > > +
> > > > + if (ret) {
> > > > + dev_err(&pdev->dev, "Couldn't reparent AHB1 on PLL6\n");
> > > > + return ret;
> > > > + }
> > >
> > > Why do we need to reparent the mux?
> >
> > ... but will function only if this clock is derived from PLL6.
>
> Ok, but _why_ is that the case? Could we at least have a comment for
> that?
I have no idea, sorry.
> Where does the driver get the named clocks from if they aren't provided
> on the device node? Is there a clock-ranges somewhere?
No, it just looks up the global clock name.
> It feels a little fragile to rely on the organisation of the clock tree
> and the naming thereof. If the IP block is ever reused on an SoC with a
> different clock tree layout then we have to handle things differently.
What do you suggest then?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points
Inline.
On 01/07/14 00:08, Stephen Warren wrote:
On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
This adds support for hardware-tracked trip points to the device tree
thermal sensor framework.
The framework supports an arbitrary number of trip points. Whenever
the current temperature is updated, the trip points immediately
below and above the current temperature are found. A sensor driver
callback `set_trips' is then called with the temperatures.
If there is no trip point above or below the current temperature,
the passed trip temperature will be LONG_MAX or LONG_MIN respectively.
In this callback, the driver should program the hardware such that
it is notified when either of these trip points are triggered.
When a trip point is triggered, the driver should call
`thermal_zone_device_update' for the respective thermal zone. This
will cause the trip points to be updated again.
If the `set_trips' callback is not implemented (is NULL), the framework
behaves as before.
Is there no "core thermal" code? I would have expected this new feature
to be implemented in "core" code rather than of/dt "support" code.
Perhaps there would also be some additions to the of/dt code, but I'd
still expect the bulk of the feature to be complete independant of
of/dt. Systems still using board files or ACPI or ... would surely
benefit from this too?
The thermal core only supports a fixed number of trip points for each
driver and the core informs the driver of any changes to those, so
drivers using the core framework can already have hardware trip points,
but just a fixed number of them.
The way of-thermal works, is it reads all the trip points from the
device tree, registers a new thermal_zone_device with that number of
trip points and then handles the trip points completely independently.
Of course, if we're just polling, this is fine, since the thermal core
also knows about those trip points and will trigger cooling when polling
the each zone. However, the driver doesn't, so it cannot setup any
interrupts to call thermal_zone_device_update.
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
+static int of_thermal_set_trips(struct thermal_zone_device *tz, long temp)
s/tz/tzd/ or s/tz/tzdev/ ? Since "tz" says "thermal zone" to me, but
it's actually a "thermal zone device".
I followed the existing convention; "tz" is the name used most often by
both the core and the of-thermal framework.
+ struct __thermal_zone *data = tz->devdata;
s/data/tz/ ? "data" is a rather generic term, and "tz" seems like a good
abbreviation for a __thermal_zone.
Same, though here both "data" and "tz" seem to be used..
+ for (i = 0; i < data->ntrips; ++i) {
+ struct __thermal_trip *trip = data->trips + i;
+ long trip_low = trip->temperature - trip->hysteresis;
+
+ if (trip_low < temp && trip_low > low)
+ low = trip_low;
+
+ if (trip->temperature > temp && trip->temperature < high)
+ high = trip->temperature;
+ }
That seems to always apply hysteresis to the low end of a trip object.
Don't you need to apply the hysteresis to either the low or high end of
the range, depending on whether the temperature is currently below/above
the range, and hence which direction the edge will be crossed?
I believe applying only to the low end is correct. Say that we have a
trip point at 40C and hysteresis of 2C. When we exceed 40C cooling will
start immediately, but it will only be stopped when we cool down to 38C.
At that point there is again a 2C gap between the current temperature
and the trip point. It would seem that this is the interpretation used
by our downstream kernel and also some people on the Internet (however
trustworthy they may be..)
If you don't feel this is right, please elaborate.
Similar comments elsewhere. Perhaps the patch is consistent with some
existing confusing naming style though?
+static int of_thermal_update_trips(struct thermal_zone_device *tz)
+{
+ long temp;
+ int err;
+
+ err = of_thermal_get_temp(tz, &temp);
+ if (err)
+ return err;
+
+ err = of_thermal_set_trips(tz, temp);
Doesn't this patch modify of_thermal_get_temp() to call
of_thermal_set_trips() itself?
You're right. I suppose this function is unneeded.
@@ -384,7 +467,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
void *data, int (*get_temp)(void *, long *),
- int (*get_trend)(void *, long *))
+ int (*get_trend)(void *, long *),
+ int (*set_trips)(void *, long, long))
Passing in a struct containing fields for all the ops seem better than
forever extending this function with more and more function pointers.
Re: [Linux-parport] [PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc.
+#ifdef CONFIG_PARPORT_1284 +MODULE_PARM_DESC(force_epp, "Do not disable EPP when it is detected to be broken (default is false)"); I think this needs some more explanation - how about "Disable check for broken Intel EPP hardware that gives false positives on 2002 and newer hardware" I would like to keep force_epp option reusable, then description should be hardware-agnostic. Maybe: "Force EPP enabling when buggy hardware found by the module checks." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/6] arm64: Support restart through restart notifier call chain
On Mon, Jun 30, 2014 at 12:11:35PM -0700, Guenter Roeck wrote: > The kernel core now supports a notifier call chain to restart the system. > > Signed-off-by: Guenter Roeck > --- > arch/arm64/kernel/process.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index 43b7c34..9dd2abd 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -43,6 +43,7 @@ > #include > #include > #include > +#include I don't think you need this include, or shouldn't it be reboot.h instead? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
On 2014-07-01 04:15, Hui Wang wrote:
> On 06/30/2014 02:45 PM, Jan Kiszka wrote:
>> On 2014-06-30 04:04, Hui Wang wrote:
>>> On 06/29/2014 07:33 PM, Jan Kiszka wrote:
On 2013-11-27 07:47, Hui Wang wrote:
> Most Thinkpad Edge series laptops use conexant codec, so far although
> the codecs have different minor Vendor Id and minor Subsystem Id,
> they all belong to the cxt5066 family, this change can make the
> mute/mic-mute LEDs support more generic among cxt_5066 family.
>
> This design refers to the similar solution for the realtek codec
> ALC269 family in the patch_realtek.c.
>
> Cc: Alex Hung
> Cc: David Henningsson
> Signed-off-by: Hui Wang
> ---
>sound/pci/hda/patch_conexant.c | 23 +++
>1 file changed, 23 insertions(+)
>
> diff --git a/sound/pci/hda/patch_conexant.c
> b/sound/pci/hda/patch_conexant.c
> index c205bb1..1f2717f 100644
> --- a/sound/pci/hda/patch_conexant.c
> +++ b/sound/pci/hda/patch_conexant.c
> @@ -3244,9 +3244,29 @@ enum {
>#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
> #include
> +#include
> static int (*led_set_func)(int, bool);
>+static acpi_status acpi_check_cb(acpi_handle handle, u32 lvl, void
> *context,
> + void **rv)
> +{
> +bool *found = context;
> +*found = true;
> +return AE_OK;
> +}
> +
> +static bool is_thinkpad(struct hda_codec *codec)
> +{
> +bool found = false;
> +if (codec->subsystem_id >> 16 != 0x17aa)
> +return false;
> +if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb,
> &found, NULL)) && found)
> +return true;
> +found = false;
> +return ACPI_SUCCESS(acpi_get_devices("IBM0068", acpi_check_cb,
> &found, NULL)) && found;
> +}
> +
>static void update_tpacpi_mute_led(void *private_data, int enabled)
>{
>struct hda_codec *codec = private_data;
> @@ -3279,6 +3299,8 @@ static void cxt_fixup_thinkpad_acpi(struct
> hda_codec *codec,
>bool removefunc = false;
> if (action == HDA_FIXUP_ACT_PROBE) {
> +if (!is_thinkpad(codec))
> +return;
>if (!led_set_func)
>led_set_func = symbol_request(tpacpi_led_set);
>if (!led_set_func) {
> @@ -3494,6 +3516,7 @@ static const struct snd_pci_quirk
> cxt5066_fixups[] = {
>SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s",
> CXT_FIXUP_STEREO_DMIC),
>SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310",
> CXT_FIXUP_STEREO_DMIC),
>SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205",
> CXT_FIXUP_STEREO_DMIC),
> +SND_PCI_QUIRK_VENDOR(0x17aa, "Thinkpad",
> CXT_FIXUP_THINKPAD_ACPI),
>SND_PCI_QUIRK(0x1c06, 0x2011, "Lemote A1004",
> CXT_PINCFG_LEMOTE_A1004),
>SND_PCI_QUIRK(0x1c06, 0x2012, "Lemote A1205",
> CXT_PINCFG_LEMOTE_A1205),
>{}
>
Starting with this patch, my Lenovo Thinkpad X121e netbook (it's
without
any mute LEDs, BTW, there is only a power LED) considers the power
button as hard reset. I have to exclude my machine from that ACPI fixup
(this is on top of current Linus master):
>>> It seems more like a firmware issue, in the acpi code, the "SSMS" is for
>>> mute led, and the "MMTS" is for micmute led, I don't know why your
>>> machine can pass "SSMS" or "MMTS" scanning even without mute LEDs.
>>>
>> Is there anything I can debug or any information I can collect from my
>> box to examine this?
> What is the linux distribution on your machine? And use showkey to catch
> the keycode of that button.
I'm running OpenSUSE 13.1. The reported keycode of the power button is 116.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [RESEND PATCH 0/5] charger/mfd: max14577: Add support for MAX77836
On Tue, 01 Jul 2014, Krzysztof Kozlowski wrote: > This is resend of second part of patches adding support for MAX77836 > device to the max14577 drivers. The first part (main MFD, extcon > and regulator drivers) was merged already. > > The patches 1, 2 and 3 depends on each other so they should be > pulled at once. Patches 4 and 5 can be applied independently. I'm happy to take this set through the MFD tree and provide an IB for everyone to pull from if that makes it any easier for the other maintainers? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/6] regulator: palmas: Rename reg_info to palmas_reg_info
On Mon, 30 Jun 2014, Nishanth Menon wrote:
> reg_info is a generic term which might cause conflict at a later point
> in time. To prevent such a thing from occuring in future, rename to
> palmas_reg_info.
>
> Signed-off-by: Nishanth Menon
> ---
> drivers/regulator/palmas-regulator.c |4 ++--
> include/linux/mfd/palmas.h |4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Lee Jones
> diff --git a/drivers/regulator/palmas-regulator.c
> b/drivers/regulator/palmas-regulator.c
> index 91f60fa..05f11b9 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -41,7 +41,7 @@ static const struct regulator_linear_range
> smps_high_ranges[] = {
> REGULATOR_LINEAR_RANGE(330, 0x7A, 0x7f, 0),
> };
>
> -static struct regs_info palmas_regs_info[] = {
> +static struct palmas_regs_info palmas_regs_info[] = {
> {
> .name = "SMPS12",
> .sname = "smps1-in",
> @@ -227,7 +227,7 @@ static struct regs_info palmas_regs_info[] = {
> },
> };
>
> -static struct regs_info tps65917_regs_info[] = {
> +static struct palmas_regs_info tps65917_regs_info[] = {
> {
> .name = "SMPS1",
> .sname = "smps1-in",
> diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
> index 1a045ba..fb0390a 100644
> --- a/include/linux/mfd/palmas.h
> +++ b/include/linux/mfd/palmas.h
> @@ -102,7 +102,7 @@ struct palmas_sleep_requestor_info {
> int bit_pos;
> };
>
> -struct regs_info {
> +struct palmas_regs_info {
> char*name;
> char*sname;
> u8 vsel_addr;
> @@ -117,7 +117,7 @@ struct palmas_pmic_driver_data {
> int ldo_begin;
> int ldo_end;
> int max_reg;
> - struct regs_info *palmas_regs_info;
> + struct palmas_regs_info *palmas_regs_info;
> struct of_regulator_match *palmas_matches;
> struct palmas_sleep_requestor_info *sleep_req_info;
> int (*smps_register)(struct palmas_pmic *pmic,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] usb: gadget: serial: replace hardcoded ttyGS with PREFIX
On Mon, 30 Jun 2014 07:45:43 -0700 Greg Kroah-Hartman wrote: > > > > > From: Of Richard Leitner > > > > > > Replaces all hardcoded ttyGS strings with the PREFIX macro. > > > > > > Due to the fact the strings are spread over different source files > > > > > > the > > > > > > PREFIX definition is moved to u_serial.h > > > > > > > > > > Lots of changes like: > > > > > > - DBG(cdev, "acm ttyGS%d completion, err %d\n", > > > > > > - acm->port_num, req->status); > > > > > > + DBG(cdev, "acm %s%d completion, err %d\n", > > > > > > + PREFIX, acm->port_num, req->status); > > > > > > > Use the "proper" debug macros that the kernel provides you (i.e. > dev_dbg() and family) and then you don't need to put the string in there > at all, the kernel will do it automatically for you, in the correct > format, so that all userspace tools can properly track what is going on. > > So please remove the horrid DBG() macro entirely. > It may be a clumsy question, but where do I get the device struct for the ttyGS from? (acm->port.ioport->port_tty ?!?) The one for the USB gadget is cdev->gadget->dev if I've seen it correctly? Thank you for your help! regards, richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1] ARM:sa1100: Remove a redundant spin lock
From: Yang Wei
The pair read/write of accessing pci confiuration space function
has already protected by pci_lock. so remove nano_lock.
Signed-off-by: Yang Wei
---
arch/arm/mach-sa1100/pci-nanoengine.c |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-sa1100/pci-nanoengine.c
b/arch/arm/mach-sa1100/pci-nanoengine.c
index ff02e2d..b944c99 100644
--- a/arch/arm/mach-sa1100/pci-nanoengine.c
+++ b/arch/arm/mach-sa1100/pci-nanoengine.c
@@ -30,7 +30,6 @@
#include
#include
-static DEFINE_SPINLOCK(nano_lock);
static int nanoengine_get_pci_address(struct pci_bus *bus,
unsigned int devfn, int where, unsigned long *address)
@@ -52,7 +51,6 @@ static int nanoengine_read_config(struct pci_bus *bus,
unsigned int devfn, int w
{
int ret;
unsigned long address;
- unsigned long flags;
u32 v;
/* nanoEngine PCI bridge does not return -1 for a non-existing
@@ -64,15 +62,12 @@ static int nanoengine_read_config(struct pci_bus *bus,
unsigned int devfn, int w
goto exit_function;
}
- spin_lock_irqsave(&nano_lock, flags);
ret = nanoengine_get_pci_address(bus, devfn, where, &address);
if (ret != PCIBIOS_SUCCESSFUL)
return ret;
v = __raw_readl(address);
- spin_unlock_irqrestore(&nano_lock, flags);
-
v >>= ((where & 3) * 8);
v &= (unsigned long)(-1) >> ((4 - size) * 8);
@@ -86,13 +81,11 @@ static int nanoengine_write_config(struct pci_bus *bus,
unsigned int devfn, int
{
int ret;
unsigned long address;
- unsigned long flags;
unsigned shift;
u32 v;
shift = (where & 3) * 8;
- spin_lock_irqsave(&nano_lock, flags);
ret = nanoengine_get_pci_address(bus, devfn, where, &address);
if (ret != PCIBIOS_SUCCESSFUL)
@@ -113,8 +106,6 @@ static int nanoengine_write_config(struct pci_bus *bus,
unsigned int devfn, int
}
__raw_writel(v, address);
- spin_unlock_irqrestore(&nano_lock, flags);
-
return PCIBIOS_SUCCESSFUL;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ARM: Centralize the access to the SCU register
On Fri, Jun 27, 2014 at 01:01:03AM +0200, Gregory CLEMENT wrote: > >> The last patch removed a direct access to the SCU register by an > >> access through the new scu_standby_enable() function. For this one I > >> have just checked that the kernel can be built using the > >> imx_v6_v7_defconfig config, but I didn't test it on an imx6 hardware. > > > > Why would we not just turn on these 2 features unconditionally? If we > > You mean in scu_enbale() ? > > > don't know of any platform where they are broken, then we should just > > At least on some imx6 SCU standby is broken according to the code and > the comments. Hi Gregory, What's broken on particular revisions of some i.MX6 SoC is WAIT mode support, not SCU standby. I think the SCU standby can just be unconditionally enabled in scu_enbale(). Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm v3 8/8] slab: do not keep free objects/slabs on dead memcg caches
On Mon, Jun 30, 2014 at 10:49:03AM -0500, Christoph Lameter wrote: > On Fri, 27 Jun 2014, Joonsoo Kim wrote: > > > Christoph, > > Is it tolerable result for large scale system? Or do we need to find > > another solution? > > > The overhead is pretty intense but then this is a rare event I guess? Yes, provided cgroups are created/destroyed rarely. > It seems that it is much easier on the code and much faster to do the > periodic reaping. Why not simply go with that? A bad thing about the periodic reaping is that the time it may take isn't predictable, because the number of dead caches is, in fact, only limited by the amount of RAM. We can have hundreds, if not thousands, copies of dcaches/icaches left from cgroups destroyed some time ago. The dead caches will hang around until memory pressure evicts all the objects they host, which may take quite long on systems with a lot of memory. With periodic reaping, we will have to iterate over all dead caches trying to drain per cpu/node arrays each time, which might therefore result in slowing down the whole system unexpectedly. I'm not quite sure if such slowdowns are really a threat though. Actually, cache_reap will only do something (take locks, drain arrays/lists) only if there are free objects on the cache. Otherwise it will, in fact, only check cpu_cache->avail, alien->avail, shared->avail, and node->free_list, which shouldn't take much time, should it? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree
Inline.
On 30/06/14 23:48, Stephen Warren wrote:
On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
This adds the soctherm thermal sensing and management unit to the
Tegra124 device tree along with the four thermal zones it exports.
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
+ thermal-zones {
+ cpu {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
I think we should still define a polling delay so that if there's SW
that doesn't support HW trip points/interrupts, it still knows how often
it should reasonably check the sensor.
Perhaps a delay of 0 is used to determine whether to use HW trip points
vs polling (I haven't read patch 1 yet)? If so, I'd prefer not to do
that. Rather, the driver should advertize its ability to provide HW trip
points, and it would be up to the core to then make use of them. The DT
should just describe the HW, not assume it can influence SW's choice of
whether to use HW trip points.
Yes, a delay of 0 disables polling in the thermal core. (The hw trip
code doesn't do anything with it) One way to fix this would be to export
a rate changing function in the thermal core and have of-thermal set the
polling rate to 0 or the value from device tree depending on if hw trip
point programming succeeded or not. This would also be good for error
handling, since if hw trip poing programming failed for whatever reason,
we could still fall back to polling.
+ soctherm: soctherm@0,700e2000 {
...
+ reset-names = "soctherm";
+
+ #thermal-sensor-cells = <1>;
I don't see any real need for that blank line. If there was, there would
probably be more blank lines in the big list of properties above.
The reasoning was that #thermal-sensor-cells as a cells-property is a
bit different from the rest, so separate them. But I can remove the
blank line just as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 13/13] ARM64 / ACPI: Enable ARM64 in Kconfig
On 2014-6-30 18:46, Catalin Marinas wrote: > On Fri, Jun 27, 2014 at 04:49:36AM +0100, Hanjun Guo wrote: >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >> index 7de5e3f..33d6dbb 100644 >> --- a/drivers/acpi/Kconfig >> +++ b/drivers/acpi/Kconfig >> @@ -8,10 +8,10 @@ config ACPI_SCAN_BIOS_NOT_EFI >> menuconfig ACPI >> bool "ACPI (Advanced Configuration and Power Interface) Support" >> depends on !IA64_HP_SIM >> -depends on IA64 || X86 >> +depends on IA64 || X86 || ARM64 > > I still don't understand what the point of enabling ACPI for arm64 > during this series is. Do you get any working arm64 functionality > (on hardware or model) without subsequent patches? If it's just for > compilation reasons, the best we could do is depending on (ARM64 && > COMPILE_TEST) but even though I would not merge this patch until we have > most of the arm64 required features in place (some of which are > introduced by the upcoming ACPI version). it is ok to me to merge all the patches together, but if Rafael is happy with the clean up patches (patch 1~3) for ACPI core, they can be merged first. > >> depends on PCI >> select PNP >> -default y >> +default y if !ARM64 > > For the benefit of single Image, I think you can default to y here. It ok to me. if we default to y here, devicetree will not be unflattened in default, is it ok to you? you can refer to "[PATCH 12/13] ARM64 / ACPI: if we chose to boot from acpi then disable FDT". Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] fs.h: Remove unnecessary extern prototypes
On Mon, Jun 30, 2014 at 04:39:09PM -0700, Andrew Morton wrote: > > I can fix it and resubmit if you like. > > OK. How about we wait for -rc6 or thereabouts? That should minimise > the pain profile. Or just drop it. This is the perfect example for a patch having absolutely no real benefit and introducing a lot of churn. People need to learn that randomly fixing style in code they don't maintain or change in a major way is abosolutely poinless. Help with reviewing newly added code so that it has good style instead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Build regressions/improvements in v3.16-rc3
Below is the list of build error/warning regressions/improvements in v3.16-rc3[1] compared to v3.15-rc8[2]. Summarized: - build errors: +19/-3 - build warnings: +89/-68 JFYI, when comparing v3.16-rc3[1] to v3.16-rc2[3], the summaries are: - build errors: +5/-63 - build warnings: +35/-38 As I haven't mastered kup yet, there's no verbose summary at http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v3.16-rc3.summary.gz Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/7619/ (all 119 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/7532/ (all 119 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/7595/ (all 119 configs) *** ERRORS *** 19 regressions: + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add' [-Werror=implicit-function-declaration]: => 176:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add_negative' [-Werror=implicit-function-declaration]: => 211:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add_return' [-Werror=implicit-function-declaration]: => 218:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec' [-Werror=implicit-function-declaration]: => 169:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec_and_test' [-Werror=implicit-function-declaration]: => 197:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec_return' [-Werror=implicit-function-declaration]: => 239:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_inc' [-Werror=implicit-function-declaration]: => 162:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_inc_and_test' [-Werror=implicit-function-declaration]: => 204:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_inc_return' [-Werror=implicit-function-declaration]: => 232:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_set' [-Werror=implicit-function-declaration]: => 155:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_sub' [-Werror=implicit-function-declaration]: => 183:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_sub_and_test' [-Werror=implicit-function-declaration]: => 190:2 + /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_sub_return' [-Werror=implicit-function-declaration]: => 225:2 + /scratch/kisskb/src/include/linux/atomic.h: error: implicit declaration of function '__atomic_add_unless' [-Werror=implicit-function-declaration]: => 53:2 + /scratch/kisskb/src/include/linux/atomic.h: error: implicit declaration of function 'atomic_cmpxchg' [-Werror=implicit-function-declaration]: => 89:3 + /scratch/kisskb/src/include/linux/atomic.h: error: implicit declaration of function 'atomic_read' [-Werror=implicit-function-declaration]: => 136:2 + /scratch/kisskb/src/scripts/mod/devicetable-offsets.c: error: -mcall-aixdesc must be big endianmake[3]: : => 1:0 + error: filter.c: undefined reference to `__fpscr_values': => .text+0x31c8c), .text+0x3156c), .text+0x323b0), .text+0x31760), .text+0x31f00) + error: misc.c: undefined reference to `ftrace_likely_update': => .text+0x22c), .text+0x898) 3 improvements: - /scratch/kisskb/src/arch/powerpc/platforms/powernv/setup.c: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]: 179:4 => - /scratch/kisskb/src/scripts/mod/devicetable-offsets.c: error: -mcall-aixdesc must be big endian: 1:0 => - error: "flush_cache_page" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined!: N/A => *** WARNINGS *** 89 regressions: + /scratch/kisskb/src/arch/mips/include/asm/page.h: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]: => 206:2 + /scratch/kisskb/src/arch/powerpc/boot/addnote.c: warning: right shift count >= width of type [enabled by default]: => 211:3, 188:3, 183:3, 206:3 + /scratch/kisskb/src/arch/powerpc/net/bpf_jit_comp.c: warning: the frame size of 2160 bytes is larger than 2048 bytes [-Wframe-larger-than=]: => 566:1 + /scratch/kisskb/src/arch/sh/kernel/cpu/sh3/../../entry-common.S: Warning: overflow in branch to syscall_call; converted into longer instruction sequence: => 208 + /scratch/kisskb/src/arch/sh/kernel/cpu/sh3/../../entry-common.S: Warning: overflow in branch to syscall_trace_entr
Re: [PATCH V4 00/16] irqchip: crossbar: Driver fixes
* Jason Cooper [140630 12:30]: > > Whole series applied to irqchip/crossbar, I'll give it a day or two in > -next, then I'll merge it into irqchip/core. > > Tony: Right now, it's immutable unless you tell me I applied something > incorrectly. Once it goes into irqchip/core, it's immutable no matter > what you say. ;-) Thanks, looks good to me. Sricharan and Nishant, can you please check that we can now apply the related .dts changes on top of Jason's branch at: git://git.infradead.org/users/jcooper/linux.git irqchip/crossbar Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build regressions/improvements in v3.16-rc3
On Tue, Jul 1, 2014 at 9:58 AM, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.16-rc3[1] to v3.16-rc2[3], the summaries are:
> - build errors: +5/-63
+ /scratch/kisskb/src/kernel/bounds.c: error: -mcall-aixdesc must be
big endian: => 1:0
+ /scratch/kisskb/src/scripts/mod/devicetable-offsets.c: error:
-mcall-aixdesc must be big endianmake[3]: : => 1:0
+ /scratch/kisskb/src/scripts/mod/empty.c: error: -mcall-aixdesc
must be big endian: => 1:0
+ : error: -mcall-aixdesc must be big endian: => 1:0
powerpc-randconfig
+ error: misc.c: undefined reference to `ftrace_likely_update': =>
.text+0x22c), .text+0x898)
sh-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/7619/ (all 119 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/7595/ (all 119 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] mm: page_alloc: Reduce cost of the fair zone allocation policy
On Mon, Jun 30, 2014 at 03:09:14PM -0700, Andrew Morton wrote: > On Mon, 30 Jun 2014 22:51:21 +0100 Mel Gorman wrote: > > > > That's a large change in system time. Does this all include kswapd > > > activity? > > > > > > > I don't have a profile to quantify that exactly. It takes 7 hours to > > complete a test on that machine in this configuration > > That's nuts. Why should measuring this require more than a few minutes? That's how long the full test takes to complete for each part of the IO test. Profiling a subsection of it will miss some parts with no guarantee the sampled subset is representative. Profiling for smaller amounts of IO so the test completes quickly does not guarantee that the sample is representative. Reducing the size of memory of the machine using any tricks is also not representative etc. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC net-next 08/14] bpf: add eBPF verifier
On 06/28/2014 02:06 AM, Alexei Starovoitov wrote:
Safety of eBPF programs is statically determined by the verifier, which detects:
- loops
- out of range jumps
- unreachable instructions
- invalid instructions
- uninitialized register access
- uninitialized stack access
- misaligned stack access
- out of range stack access
- invalid calling convention
...
More details in Documentation/networking/filter.txt
Signed-off-by: Alexei Starovoitov
---
...
kernel/bpf/verifier.c | 1431 +++
Looking at classic BPF verifier which checks safety of BPF
user space programs, it's roughly 200 loc. :-/
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
new file mode 100644
...
+#define _(OP) ({ int ret = OP; if (ret < 0) return ret; })
...
+ _(get_map_info(env, map_id, &map));
...
+ _(size = bpf_size_to_bytes(bpf_size));
Nit: such macros should be removed, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2] Implement Batched (group) ticket lock
On Sat, Jun 28, 2014 at 02:47:04PM +0530, Raghavendra K T wrote: > In virtualized environment there are mainly three problems > related to spinlocks that affects performance. > 1. LHP (lock holder preemption) > 2. Lock Waiter Preemption (LWP) > 3. Starvation/fairness > > Though Ticketlocks solve fairness problem it worsens LWP, LHP problems. Though > pv-ticketlocks tried to address these problems we can further improve at the > cost of relaxed fairness. The following patch tries to achieve that by > grouping > (batched) ticketlocks. And here I stop reading and ignore this patch, right? Why should I look at this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver
Inline.
On 01/07/14 00:23, Stephen Warren wrote:
On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
This adds support for the Tegra SOCTHERM thermal sensing and management
system found in the Tegra124 system-on-chip. This initial driver supports
the four thermal zones with hardware-tracked trip points.
diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c
+static struct tegra_tsensor t124_tsensors[] = {
+ {
+ .base = 0xc0,
+ .name = "cpu0",
+ .config = &t124_tsensor_config,
+ .calib_fuse_offset = 0x098,
+ .fuse_corr_alpha = 1135400,
+ .fuse_corr_beta = -6266900,
+ },
I wonder why some of those fields are named "fuse_xxx" when the values
are hard-coded in these tables rather than read from fuses? These values
don't seem to be used to adjust values read from fuses.
They are used to when calculating the thermal calibration in
calculate_tsensor_calibration, which is based on the value read from the
fuse. Downstream calls them fuse correction values, so I kept that. (I
guess the meaning of corr might not be obvious..) On downstream there is
another set of these correction values used depending on the fuse
revision, but I believe the older revision is only found internally.
+static int tegra_thermctl_get_temp(void *data, long *out_temp)
+ switch (zone->sensor) {
+ case 0:
+ val = readl(zone->tegra->regs + SENSOR_TEMP1)
+ >> SENSOR_TEMP1_CPU_TEMP_SHIFT;
Can't the register offset and shift be stored in *zone, so that this
whole switch can be replaced with something generic:
val = readl(zone->tegra->regs + zone->reg_offset) >> zone->value_shift;
Yes, certainly doable.
+static int tegra_soctherm_probe(struct platform_device *pdev)
+ irq = platform_get_irq(pdev, 0);
+ if (irq <= 0) {
+ dev_err(&pdev->dev, "can't get interrupt\n");
+ return -EINVAL;
+ }
irq is assigned once here ... (see later)
+ for (i = 0; i < 4; ++i) {
Why "4"? Should the loop count be the ARRAY_SIZE(some array)? At the
very least, a named constant that describes the value would be useful...
The thermctl sensors have been unchanged for a few chip generations, so
I was thinking that just hardcoding this wouldn't be so bad. But I guess
an array would look nicer here. Will fix.
+ err = devm_request_threaded_irq(&pdev->dev, irq, soctherm_isr,
+ soctherm_isr_thread,
+ IRQF_SHARED, "tegra_soctherm",
+ zone);
Why request the same IRQ 4 times here. Rather, shouldn't the IRQ be
requested once, and the ISR simply loop over the status register (or
whatever there are 4 of)?
I had that variant as well, but since we need to pass the list of
tripped sensors to soctherm_isr_thread somehow, I guess some kind of
locking or atomic is needed. This version doesn't need that, so I went
with it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] block: virtio-blk: support multi vq per virtio-blk
On Mon, Jun 30, 2014 at 09:01:07PM -0600, Jens Axboe wrote: > >I appreciate very much that one of you may queue these two > >patches into your tree so that userspace work can be kicked off, > >since Michael has acked both patches and all comments have > >been addressed already. > > Given that Michael also acked it and Rusty is on his sabbatical, I'll queue > it up for 3.17. So Rusty is offline? Who is taking care of module/moduleparam patches in the meantime? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] perf/x86/intel: ignore CondChgd bit to avoid false NMI handling
On Mon, Jun 30, 2014 at 03:22:24PM -0700, Andi Kleen wrote: > > > > I'm also interested in the behaviour of CondChgd bit on Ivy Bridge > > processors. > > The intended meaning of CondChgd is that a hardware debugger has taken over > the > PMU. It shouldn't really be set in other circumstances. The SDM utterly and totally fails to mention this, please fix that. > I think right now for perf it would be best to just ignore it. > > In theory could stop using the PMU, but if some BIOS set it it would > completely disable perf there. So better to just ignore it. The even better option would be to kill off SMM mode, all that ever does is create problems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/1] proc: constify seq_operations
On Mon, Jun 30, 2014 at 01:39:39PM -0700, Andrew Morton wrote: > On Mon, 30 Jun 2014 21:03:17 +0200 Fabian Frederick wrote: > > > proc_uid_seq_operations, proc_gid_seq_operations and > > proc_projid_seq_operations > > are only called in proc_id_map_open with seq_open as > > const struct seq_operations so we can constify the 3 structures and update > > proc_id_map_open prototype. > > There are an absolutely enormous number of places where we could > constify things. For sheer sanity's sake I'm not inclined to churn the > code in this way unless a patch provides some sort of runtime benefit. > And this particular patch doesn't appear to change the generated code > at all. Unlike a lot of the cleanup patches which provide no benefit at all constifying op vectors moves them from .text to .data which is not marked executable and thus reduce the attack vector for kernel exploits. So I defintively like to see these much more than a lot of the other things filling up the lists. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: make copy_pte_range static again
Commit 71e3aac (thp: transparent hugepage core) adds copy_pte_range
prototype to huge_mm.h. I'm not sure why (or if) this function have
been used outside of memory.c, but it currently isn't.
This patch makes copy_pte_range() static again.
Signed-off-by: Jerome Marchand
---
include/linux/huge_mm.h | 4
mm/memory.c | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index b826239..63579cb 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -93,10 +93,6 @@ extern bool is_vma_temporary_stack(struct vm_area_struct
*vma);
#endif /* CONFIG_DEBUG_VM */
extern unsigned long transparent_hugepage_flags;
-extern int copy_pte_range(struct mm_struct *dst_mm, struct mm_struct *src_mm,
- pmd_t *dst_pmd, pmd_t *src_pmd,
- struct vm_area_struct *vma,
- unsigned long addr, unsigned long end);
extern int split_huge_page_to_list(struct page *page, struct list_head *list);
static inline int split_huge_page(struct page *page)
{
diff --git a/mm/memory.c b/mm/memory.c
index 09e2cd0..13141ae 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -884,7 +884,7 @@ out_set_pte:
return 0;
}
-int copy_pte_range(struct mm_struct *dst_mm, struct mm_struct *src_mm,
+static int copy_pte_range(struct mm_struct *dst_mm, struct mm_struct *src_mm,
pmd_t *dst_pmd, pmd_t *src_pmd, struct vm_area_struct *vma,
unsigned long addr, unsigned long end)
{
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance
On Tue, Jun 24, 2014 at 11:34:54AM +0800, Michael wang wrote: > On 06/23/2014 05:42 PM, Peter Zijlstra wrote: > [snip] > >> +} > > > > Still completely hate this, it doesn't make sense conceptual sense what > > so ever. > > Yeah... and now I agree your opinion that this could not address all the > cases after all the testing these days... > > Just wondering could we make this another scheduler feature? No; sched_feat() is for debugging, BIG CLUE: its guarded by CONFIG_SCHED_DEBUG, anybody using it in production or anywhere else is broken. If people are using it, I should remove or at least randomize the interface. pgpvCn1ZRDfKg.pgp Description: PGP signature
Re: [PATCH v4 13/13] ARM64 / ACPI: Enable ARM64 in Kconfig
>> >>> depends on PCI >>> select PNP >>> - default y >>> + default y if !ARM64 >> >> For the benefit of single Image, I think you can default to y here. > > It ok to me. if we default to y here, devicetree will not be unflattened > in default, is it ok to you? you can refer to "[PATCH 12/13] ARM64 / ACPI: if > we chose to boot from acpi then disable FDT". Ah, sorry I didn't describe it clearly. since there is no shipping board with ACPI tables, so ACPI will disabled in the very early stage and FDT still have chance to be unflattened, so will not break DT booting in this patchset. Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/9] slab: move up code to get kmem_cache_node in free_block()
node isn't changed, so we don't need to retreive this structure
everytime we move the object. Maybe compiler do this optimization,
but making it explicitly is better.
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
mm/slab.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index f8a0ed1..19e2136 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3417,7 +3417,7 @@ static void free_block(struct kmem_cache *cachep, void
**objpp, int nr_objects,
int node)
{
int i;
- struct kmem_cache_node *n;
+ struct kmem_cache_node *n = get_node(cachep, node);
for (i = 0; i < nr_objects; i++) {
void *objp;
@@ -3427,7 +3427,6 @@ static void free_block(struct kmem_cache *cachep, void
**objpp, int nr_objects,
objp = objpp[i];
page = virt_to_head_page(objp);
- n = get_node(cachep, node);
list_del(&page->lru);
check_spinlock_acquired_node(cachep, node);
slab_put_obj(cachep, page, objp, node);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/9] slab: factor out initialization of arracy cache
Factor out initialization of array cache to use it in following patch.
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
mm/slab.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 59b9a4c..00b6bbc 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -791,13 +791,8 @@ static void start_cpu_timer(int cpu)
}
}
-static struct array_cache *alloc_arraycache(int node, int entries,
- int batchcount, gfp_t gfp)
+static void init_arraycache(struct array_cache *ac, int limit, int batch)
{
- int memsize = sizeof(void *) * entries + sizeof(struct array_cache);
- struct array_cache *nc = NULL;
-
- nc = kmalloc_node(memsize, gfp, node);
/*
* The array_cache structures contain pointers to free object.
* However, when such objects are allocated or transferred to another
@@ -805,15 +800,25 @@ static struct array_cache *alloc_arraycache(int node, int
entries,
* valid references during a kmemleak scan. Therefore, kmemleak must
* not scan such objects.
*/
- kmemleak_no_scan(nc);
- if (nc) {
- nc->avail = 0;
- nc->limit = entries;
- nc->batchcount = batchcount;
- nc->touched = 0;
- spin_lock_init(&nc->lock);
+ kmemleak_no_scan(ac);
+ if (ac) {
+ ac->avail = 0;
+ ac->limit = limit;
+ ac->batchcount = batch;
+ ac->touched = 0;
+ spin_lock_init(&ac->lock);
}
- return nc;
+}
+
+static struct array_cache *alloc_arraycache(int node, int entries,
+ int batchcount, gfp_t gfp)
+{
+ int memsize = sizeof(void *) * entries + sizeof(struct array_cache);
+ struct array_cache *ac = NULL;
+
+ ac = kmalloc_node(memsize, gfp, node);
+ init_arraycache(ac, entries, batchcount);
+ return ac;
}
static inline bool is_slab_pfmemalloc(struct page *page)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] clk: Introduce 'clk_find_nearest_rate()'
On Mon, Jun 30, 2014 at 09:56:33AM -0700, Soren Brinkmann wrote:
> Introduce a new API function to find the rate a clock can provide which
> is closest to a given rate.
>
> clk_round_rate() leaves it to the clock driver how rounding is done.
> Commonly implementations round down due to use-cases that have a certain
> frequency maximum that must not be exceeded.
>
> The new API call enables use-cases where accuracy is preferred. E.g.
> Ethernet clocks.
>
> Signed-off-by: Soren Brinkmann
> ---
>
> drivers/clk/clk.c | 57
> +
> include/linux/clk.h | 9 +
> 2 files changed, 66 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 8b73edef151d..fce1165cd879 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1030,6 +1030,63 @@ long clk_round_rate(struct clk *clk, unsigned long
> rate)
> EXPORT_SYMBOL_GPL(clk_round_rate);
>
> /**
> + * clk_find_nearest_rate - round the given rate for a clk
> + * @clk: the clk for which we are rounding a rate
> + * @rate: the rate which is to be rounded
> + *
> + * Takes in a rate as input and finds the closest rate that the clk
> + * can actually use which is then returned.
> + * Note: This function relies on the clock's clk_round_rate() implementation.
> + * For cases clk_round_rate() rounds up, not the closest but the rounded up
> + * rate is found.
> + */
> +long clk_find_nearest_rate(struct clk *clk, unsigned long rate)
> +{
> + long ret, lower, upper;
> + unsigned long tmp;
> +
> + clk_prepare_lock();
> +
> + lower = __clk_round_rate(clk, rate);
> + if (lower >= rate || lower < 0) {
> + ret = lower;
> + goto unlock;
> + }
> +
> + tmp = rate + (rate - lower) - 1;
> + if (tmp > LONG_MAX)
> + upper = LONG_MAX;
> + else
> + upper = tmp;
Consider rate = 0xf000, lower = 0x7fff (= LONG_MAX). Then tmp =
(unsigned long)0x16000 = 0x6000. In this case you pick upper =
0x6000 while you should use upper = LONG_MAX.
I think you need
- if (tmp > LONG_MAX)
+ if (tmp > LONG_MAX || tmp < rate)
(and a comment)
> +
> + upper = __clk_round_rate(clk, upper);
> + if (upper <= lower || upper < 0) {
Is it an idea to do something like:
if (IS_ENABLED(CONFIG_CLK_SANITY_CHECKS))
WARN_ON(upper < lower && upper >= 0);
here?
> + ret = lower;
> + goto unlock;
> + }
> +
> + lower = rate + 1;
> + while (lower < upper) {
> + long rounded, mid;
> +
> + mid = lower + ((upper - lower) >> 1);
> + rounded = __clk_round_rate(clk, mid);
> + if (rounded < lower)
> + lower = mid + 1;
> + else
> + upper = rounded;
> + }
This is broken if you don't assume that __clk_round_rate rounds down.
Consider an implementation that already does round_nearest and clk can
assume the values 0x6 and 0x85000 (and nothing in between), and rate
= 0x7. This results in
lower = 0x6;
tmp = 0x7;
upper = __clk_round_rate(clk, 0x7) = 0x85000
before the loop and the loop then doesn't even terminate.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 9/9] slab: remove BAD_ALIEN_MAGIC
BAD_ALIEN_MAGIC value isn't used anymore. So remove it.
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
mm/slab.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 7820a45..60c9e11 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -470,8 +470,6 @@ static struct kmem_cache kmem_cache_boot = {
.name = "kmem_cache",
};
-#define BAD_ALIEN_MAGIC 0x01020304ul
-
static DEFINE_PER_CPU(struct delayed_work, slab_reap_work);
static inline struct array_cache *cpu_cache_get(struct kmem_cache *cachep)
@@ -838,7 +836,7 @@ static int transfer_objects(struct array_cache *to,
static inline struct alien_cache **alloc_alien_cache(int node,
int limit, gfp_t gfp)
{
- return (struct alien_cache **)BAD_ALIEN_MAGIC;
+ return NULL;
}
static inline void free_alien_cache(struct alien_cache **ac_ptr)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/9] slab: add unlikely macro to help compiler
slab_should_failslab() is called on every allocation, so to optimize it
is reasonable. We normally don't allocate from kmem_cache. It is just
used when new kmem_cache is created, so it's very rare case. Therefore,
add unlikely macro to help compiler optimization.
Acked-by: David Rientjes
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
mm/slab.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slab.c b/mm/slab.c
index 179272f..f8a0ed1 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3067,7 +3067,7 @@ static void *cache_alloc_debugcheck_after(struct
kmem_cache *cachep,
static bool slab_should_failslab(struct kmem_cache *cachep, gfp_t flags)
{
- if (cachep == kmem_cache)
+ if (unlikely(cachep == kmem_cache))
return false;
return should_failslab(cachep->object_size, flags, cachep->flags);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/9] irqchip: GIC: Convert to EOImode == 1
Hi Stefano,
On 30/06/14 20:09, Stefano Stabellini wrote:
> On Wed, 25 Jun 2014, Anup Patel wrote:
>> Hi Marc,
>>
>> On Wed, Jun 25, 2014 at 2:58 PM, Marc Zyngier wrote:
>>> So far, GICv2 has been used in with EOImode == 0. The effect of this
>>> mode is to perform the priority drop and the deactivation of the
>>> interrupt at the same time.
>>>
>>> While this works perfectly for Linux (we only have a single priority),
>>> it causes issues when an interrupt is forwarded to a guest, and when
>>> we want the guest to perform the EOI itself.
>>>
>>> For this case, the GIC architecture provides EOImode == 1, where:
>>> - A write to the EOI register drops the priority of the interrupt and leaves
>>> it active. Other interrupts at the same priority level can now be taken,
>>> but the active interrupt cannot be taken again
>>> - A write to the DIR marks the interrupt as inactive, meaning it can
>>> now be taken again.
>>>
>>> We only enable this feature when booted in HYP mode. Also, as most device
>>> trees are broken (they report the CPU interface size to be 4kB, while
>>> the GICv2 CPU interface size is 8kB), output a warning if we're booted
>>> in HYP mode, and disable the feature.
>>>
>>> Signed-off-by: Marc Zyngier
>>> ---
>>> drivers/irqchip/irq-gic.c | 61
>>> +
>>> include/linux/irqchip/arm-gic.h | 4 +++
>>> 2 files changed, 59 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>>> index 508b815..9295bf2 100644
>>> --- a/drivers/irqchip/irq-gic.c
>>> +++ b/drivers/irqchip/irq-gic.c
>>> @@ -45,6 +45,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "irq-gic-common.h"
>>> #include "irqchip.h"
>>> @@ -94,6 +95,10 @@ struct irq_chip gic_arch_extn = {
>>> .irq_set_wake = NULL,
>>> };
>>>
>>> +static struct irq_chip *gic_chip;
>>> +
>>> +static bool supports_deactivate = false;
>>> +
>>> #ifndef MAX_GIC_NR
>>> #define MAX_GIC_NR 1
>>> #endif
>>> @@ -185,6 +190,12 @@ static void gic_eoi_irq(struct irq_data *d)
>>> writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
>>> }
>>>
>>> +static void gic_eoi_dir_irq(struct irq_data *d)
>>> +{
>>> + gic_eoi_irq(d);
>>> + writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_DEACTIVATE);
>>> +}
>
> Would it be better if you moved the gic_eoi_irq call earlier? Maybe
> somewhere in gic_handle_irq?
I'm not sure I see what we'd gain by doing so. Can you elaborate?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/9] slab: defer slab_destroy in free_block()
In free_block(), if freeing object makes new free slab and number of
free_objects exceeds free_limit, we start to destroy this new free slab
with holding the kmem_cache node lock. Holding the lock is useless and,
generally, holding a lock as least as possible is good thing. I never
measure performance effect of this, but we'd be better not to hold the lock
as much as possible.
Commented by Christoph:
This is also good because kmem_cache_free is no longer called while
holding the node lock. So we avoid one case of recursion.
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
mm/slab.c | 63 +
1 file changed, 43 insertions(+), 20 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 19e2136..59b9a4c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -242,7 +242,8 @@ static struct kmem_cache_node __initdata
init_kmem_cache_node[NUM_INIT_LISTS];
static int drain_freelist(struct kmem_cache *cache,
struct kmem_cache_node *n, int tofree);
static void free_block(struct kmem_cache *cachep, void **objpp, int len,
- int node);
+ int node, struct list_head *list);
+static void slabs_destroy(struct kmem_cache *cachep, struct list_head *list);
static int enable_cpucache(struct kmem_cache *cachep, gfp_t gfp);
static void cache_reap(struct work_struct *unused);
@@ -1030,6 +1031,7 @@ static void __drain_alien_cache(struct kmem_cache *cachep,
struct array_cache *ac, int node)
{
struct kmem_cache_node *n = get_node(cachep, node);
+ LIST_HEAD(list);
if (ac->avail) {
spin_lock(&n->list_lock);
@@ -1041,9 +1043,10 @@ static void __drain_alien_cache(struct kmem_cache
*cachep,
if (n->shared)
transfer_objects(n->shared, ac, ac->limit);
- free_block(cachep, ac->entry, ac->avail, node);
+ free_block(cachep, ac->entry, ac->avail, node, &list);
ac->avail = 0;
spin_unlock(&n->list_lock);
+ slabs_destroy(cachep, &list);
}
}
@@ -1087,6 +1090,7 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
struct kmem_cache_node *n;
struct array_cache *alien = NULL;
int node;
+ LIST_HEAD(list);
node = numa_mem_id();
@@ -,8 +1115,9 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
} else {
n = get_node(cachep, nodeid);
spin_lock(&n->list_lock);
- free_block(cachep, &objp, 1, nodeid);
+ free_block(cachep, &objp, 1, nodeid, &list);
spin_unlock(&n->list_lock);
+ slabs_destroy(cachep, &list);
}
return 1;
}
@@ -1184,6 +1189,7 @@ static void cpuup_canceled(long cpu)
struct array_cache *nc;
struct array_cache *shared;
struct array_cache **alien;
+ LIST_HEAD(list);
/* cpu is dead; no one can alloc from it. */
nc = cachep->array[cpu];
@@ -1199,7 +1205,7 @@ static void cpuup_canceled(long cpu)
if (!memcg_cache_dead(cachep))
n->free_limit -= cachep->batchcount;
if (nc)
- free_block(cachep, nc->entry, nc->avail, node);
+ free_block(cachep, nc->entry, nc->avail, node, &list);
if (!cpumask_empty(mask)) {
spin_unlock_irq(&n->list_lock);
@@ -1209,7 +1215,7 @@ static void cpuup_canceled(long cpu)
shared = n->shared;
if (shared) {
free_block(cachep, shared->entry,
- shared->avail, node);
+ shared->avail, node, &list);
n->shared = NULL;
}
@@ -1224,6 +1230,7 @@ static void cpuup_canceled(long cpu)
free_alien_cache(alien);
}
free_array_cache:
+ slabs_destroy(cachep, &list);
kfree(nc);
}
/*
@@ -2062,6 +2069,16 @@ static void slab_destroy(struct kmem_cache *cachep,
struct page *page)
kmem_cache_free(cachep->freelist_cache, freelist);
}
+static void slabs_destroy(struct kmem_cache *cachep, struct list_head *list)
+{
+ struct page *page, *n;
+
+ list_for_each_entry_safe(page, n, list, lru) {
+ list_del(&page->lru);
+ slab_destroy(cachep, page);
+ }
+}
+
/**
* calculate_slab_order - calculate size (page order) of slabs
* @cachep: pointer to the cache that is being created
@@ -2465,6 +2482,7 @@ static void do_drain(void *arg)
struct array_cache *ac;
int node = numa_mem_id();
struct kmem_cache_node *n;
+ LIST_HEAD(list);
check_irq_off();
[PATCH v3 0/9] clean-up and remove lockdep annotation in SLAB
This patchset does some clean-up and tries to remove lockdep annotation. Patches 1~2 are just for really really minor improvement. Patches 3~9 are for clean-up and removing lockdep annotation. There are two cases that lockdep annotation is needed in SLAB. 1) holding two node locks 2) holding two array cache(alien cache) locks I looked at the code and found that we can avoid these cases without any negative effect. 1) occurs if freeing object makes new free slab and we decide to destroy it. Although we don't need to hold the lock during destroying a slab, current code do that. Destroying a slab without holding the lock would help the reduction of the lock contention. To do it, I change the implementation that new free slab is destroyed after releasing the lock. 2) occurs on similar situation. When we free object from non-local node, we put this object to alien cache with holding the alien cache lock. If alien cache is full, we try to flush alien cache to proper node cache, and, in this time, new free slab could be made. Destroying it would be started and we will free metadata object which comes from another node. In this case, we need another node's alien cache lock to free object. This forces us to hold two array cache locks and then we need lockdep annotation although they are always different locks and deadlock cannot be possible. To prevent this situation, I use same way as 1). In this way, we can avoid 1) and 2) cases, and then, can remove lockdep annotation. As short stat noted, this makes SLAB code much simpler. All patches of this series got Ack from Christoph Lamter on previous iteration, and there is no big change from previous iteration. Just one clean-up patch is dropped, because it seems not good clean-up. Others are just rebased on current linux-next. Thanks. Joonsoo Kim (9): slab: add unlikely macro to help compiler slab: move up code to get kmem_cache_node in free_block() slab: defer slab_destroy in free_block() slab: factor out initialization of arracy cache slab: introduce alien_cache slab: use the lock on alien_cache, instead of the lock on array_cache slab: destroy a slab without holding any alien cache lock slab: remove a useless lockdep annotation slab: remove BAD_ALIEN_MAGIC mm/slab.c | 377 ++--- mm/slab.h |2 +- 2 files changed, 137 insertions(+), 242 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/9] slab: use the lock on alien_cache, instead of the lock on array_cache
Now, we have separate alien_cache structure, so it'd be better to hold
the lock on alien_cache while manipulating alien_cache. After that,
we don't need the lock on array_cache, so remove it.
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
mm/slab.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index e1a473d..1c319ad 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -191,7 +191,6 @@ struct array_cache {
unsigned int limit;
unsigned int batchcount;
unsigned int touched;
- spinlock_t lock;
void *entry[]; /*
* Must have this definition in here for the proper
* alignment of array_cache. Also simplifies accessing
@@ -512,7 +511,7 @@ static void slab_set_lock_classes(struct kmem_cache *cachep,
return;
for_each_node(r) {
if (alc[r])
- lockdep_set_class(&(alc[r]->ac.lock), alc_key);
+ lockdep_set_class(&(alc[r]->lock), alc_key);
}
}
@@ -811,7 +810,6 @@ static void init_arraycache(struct array_cache *ac, int
limit, int batch)
ac->limit = limit;
ac->batchcount = batch;
ac->touched = 0;
- spin_lock_init(&ac->lock);
}
}
@@ -1010,6 +1008,7 @@ static struct alien_cache *__alloc_alien_cache(int node,
int entries,
alc = kmalloc_node(memsize, gfp, node);
init_arraycache(&alc->ac, entries, batch);
+ spin_lock_init(&alc->lock);
return alc;
}
@@ -1086,9 +1085,9 @@ static void reap_alien(struct kmem_cache *cachep, struct
kmem_cache_node *n)
if (alc) {
ac = &alc->ac;
- if (ac->avail && spin_trylock_irq(&ac->lock)) {
+ if (ac->avail && spin_trylock_irq(&alc->lock)) {
__drain_alien_cache(cachep, ac, node);
- spin_unlock_irq(&ac->lock);
+ spin_unlock_irq(&alc->lock);
}
}
}
@@ -1106,9 +1105,9 @@ static void drain_alien_cache(struct kmem_cache *cachep,
alc = alien[i];
if (alc) {
ac = &alc->ac;
- spin_lock_irqsave(&ac->lock, flags);
+ spin_lock_irqsave(&alc->lock, flags);
__drain_alien_cache(cachep, ac, i);
- spin_unlock_irqrestore(&ac->lock, flags);
+ spin_unlock_irqrestore(&alc->lock, flags);
}
}
}
@@ -1136,13 +1135,13 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
if (n->alien && n->alien[nodeid]) {
alien = n->alien[nodeid];
ac = &alien->ac;
- spin_lock(&ac->lock);
+ spin_lock(&alien->lock);
if (unlikely(ac->avail == ac->limit)) {
STATS_INC_ACOVERFLOW(cachep);
__drain_alien_cache(cachep, ac, nodeid);
}
ac_put_obj(cachep, ac, objp);
- spin_unlock(&ac->lock);
+ spin_unlock(&alien->lock);
} else {
n = get_node(cachep, nodeid);
spin_lock(&n->list_lock);
@@ -1619,10 +1618,6 @@ void __init kmem_cache_init(void)
memcpy(ptr, cpu_cache_get(kmem_cache),
sizeof(struct arraycache_init));
- /*
-* Do not assume that spinlocks can be initialized via memcpy:
-*/
- spin_lock_init(&ptr->lock);
kmem_cache->array[smp_processor_id()] = ptr;
@@ -1632,10 +1627,6 @@ void __init kmem_cache_init(void)
!= &initarray_generic.cache);
memcpy(ptr, cpu_cache_get(kmalloc_caches[INDEX_AC]),
sizeof(struct arraycache_init));
- /*
-* Do not assume that spinlocks can be initialized via memcpy:
-*/
- spin_lock_init(&ptr->lock);
kmalloc_caches[INDEX_AC]->array[smp_processor_id()] = ptr;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/9] slab: introduce alien_cache
Currently, we use array_cache for alien_cache. Although they are mostly
similar, there is one difference, that is, need for spinlock.
We don't need spinlock for array_cache itself, but to use array_cache for
alien_cache, array_cache structure should have spinlock. This is needless
overhead, so removing it would be better. This patch prepare it by
introducing alien_cache and using it. In the following patch,
we remove spinlock in array_cache.
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
mm/slab.c | 108 ++---
mm/slab.h |2 +-
2 files changed, 68 insertions(+), 42 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 00b6bbc..e1a473d 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -203,6 +203,11 @@ struct array_cache {
*/
};
+struct alien_cache {
+ spinlock_t lock;
+ struct array_cache ac;
+};
+
#define SLAB_OBJ_PFMEMALLOC1
static inline bool is_obj_pfmemalloc(void *objp)
{
@@ -491,7 +496,7 @@ static void slab_set_lock_classes(struct kmem_cache *cachep,
struct lock_class_key *l3_key, struct lock_class_key *alc_key,
struct kmem_cache_node *n)
{
- struct array_cache **alc;
+ struct alien_cache **alc;
int r;
lockdep_set_class(&n->list_lock, l3_key);
@@ -507,7 +512,7 @@ static void slab_set_lock_classes(struct kmem_cache *cachep,
return;
for_each_node(r) {
if (alc[r])
- lockdep_set_class(&alc[r]->lock, alc_key);
+ lockdep_set_class(&(alc[r]->ac.lock), alc_key);
}
}
@@ -965,12 +970,13 @@ static int transfer_objects(struct array_cache *to,
#define drain_alien_cache(cachep, alien) do { } while (0)
#define reap_alien(cachep, n) do { } while (0)
-static inline struct array_cache **alloc_alien_cache(int node, int limit,
gfp_t gfp)
+static inline struct alien_cache **alloc_alien_cache(int node,
+ int limit, gfp_t gfp)
{
- return (struct array_cache **)BAD_ALIEN_MAGIC;
+ return (struct alien_cache **)BAD_ALIEN_MAGIC;
}
-static inline void free_alien_cache(struct array_cache **ac_ptr)
+static inline void free_alien_cache(struct alien_cache **ac_ptr)
{
}
@@ -996,40 +1002,52 @@ static inline void *cache_alloc_node(struct
kmem_cache *cachep,
static void *cache_alloc_node(struct kmem_cache *, gfp_t, int);
static void *alternate_node_alloc(struct kmem_cache *, gfp_t);
-static struct array_cache **alloc_alien_cache(int node, int limit, gfp_t gfp)
+static struct alien_cache *__alloc_alien_cache(int node, int entries,
+ int batch, gfp_t gfp)
+{
+ int memsize = sizeof(void *) * entries + sizeof(struct alien_cache);
+ struct alien_cache *alc = NULL;
+
+ alc = kmalloc_node(memsize, gfp, node);
+ init_arraycache(&alc->ac, entries, batch);
+ return alc;
+}
+
+static struct alien_cache **alloc_alien_cache(int node, int limit, gfp_t gfp)
{
- struct array_cache **ac_ptr;
+ struct alien_cache **alc_ptr;
int memsize = sizeof(void *) * nr_node_ids;
int i;
if (limit > 1)
limit = 12;
- ac_ptr = kzalloc_node(memsize, gfp, node);
- if (ac_ptr) {
- for_each_node(i) {
- if (i == node || !node_online(i))
- continue;
- ac_ptr[i] = alloc_arraycache(node, limit, 0xbaadf00d,
gfp);
- if (!ac_ptr[i]) {
- for (i--; i >= 0; i--)
- kfree(ac_ptr[i]);
- kfree(ac_ptr);
- return NULL;
- }
+ alc_ptr = kzalloc_node(memsize, gfp, node);
+ if (!alc_ptr)
+ return NULL;
+
+ for_each_node(i) {
+ if (i == node || !node_online(i))
+ continue;
+ alc_ptr[i] = __alloc_alien_cache(node, limit, 0xbaadf00d, gfp);
+ if (!alc_ptr[i]) {
+ for (i--; i >= 0; i--)
+ kfree(alc_ptr[i]);
+ kfree(alc_ptr);
+ return NULL;
}
}
- return ac_ptr;
+ return alc_ptr;
}
-static void free_alien_cache(struct array_cache **ac_ptr)
+static void free_alien_cache(struct alien_cache **alc_ptr)
{
int i;
- if (!ac_ptr)
+ if (!alc_ptr)
return;
for_each_node(i)
- kfree(ac_ptr[i]);
- kfree(ac_ptr);
+ kfree(alc_ptr[i]);
+ kfree(alc_ptr);
}
static void __drain_alien_cache(struct kmem_cache *cachep,
@@ -1063,25 +1081,31 @@ static void reap_alien(struct kmem_cache *cachep,
struct kmem_cache_node *n)
int node = __this_cpu_read(slab_reap_nod
[PATCH v3 8/9] slab: remove a useless lockdep annotation
Now, there is no code to hold two lock simultaneously, since
we don't call slab_destroy() with holding any lock. So, lockdep
annotation is useless now. Remove it.
v2: don't remove BAD_ALIEN_MAGIC in this patch. It will be removed
in the following patch.
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
mm/slab.c | 153 -
1 file changed, 153 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 854dfa0..7820a45 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -472,139 +472,6 @@ static struct kmem_cache kmem_cache_boot = {
#define BAD_ALIEN_MAGIC 0x01020304ul
-#ifdef CONFIG_LOCKDEP
-
-/*
- * Slab sometimes uses the kmalloc slabs to store the slab headers
- * for other slabs "off slab".
- * The locking for this is tricky in that it nests within the locks
- * of all other slabs in a few places; to deal with this special
- * locking we put on-slab caches into a separate lock-class.
- *
- * We set lock class for alien array caches which are up during init.
- * The lock annotation will be lost if all cpus of a node goes down and
- * then comes back up during hotplug
- */
-static struct lock_class_key on_slab_l3_key;
-static struct lock_class_key on_slab_alc_key;
-
-static struct lock_class_key debugobj_l3_key;
-static struct lock_class_key debugobj_alc_key;
-
-static void slab_set_lock_classes(struct kmem_cache *cachep,
- struct lock_class_key *l3_key, struct lock_class_key *alc_key,
- struct kmem_cache_node *n)
-{
- struct alien_cache **alc;
- int r;
-
- lockdep_set_class(&n->list_lock, l3_key);
- alc = n->alien;
- /*
-* FIXME: This check for BAD_ALIEN_MAGIC
-* should go away when common slab code is taught to
-* work even without alien caches.
-* Currently, non NUMA code returns BAD_ALIEN_MAGIC
-* for alloc_alien_cache,
-*/
- if (!alc || (unsigned long)alc == BAD_ALIEN_MAGIC)
- return;
- for_each_node(r) {
- if (alc[r])
- lockdep_set_class(&(alc[r]->lock), alc_key);
- }
-}
-
-static void slab_set_debugobj_lock_classes_node(struct kmem_cache *cachep,
- struct kmem_cache_node *n)
-{
- slab_set_lock_classes(cachep, &debugobj_l3_key, &debugobj_alc_key, n);
-}
-
-static void slab_set_debugobj_lock_classes(struct kmem_cache *cachep)
-{
- int node;
- struct kmem_cache_node *n;
-
- for_each_kmem_cache_node(cachep, node, n)
- slab_set_debugobj_lock_classes_node(cachep, n);
-}
-
-static void init_node_lock_keys(int q)
-{
- int i;
-
- if (slab_state < UP)
- return;
-
- for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) {
- struct kmem_cache_node *n;
- struct kmem_cache *cache = kmalloc_caches[i];
-
- if (!cache)
- continue;
-
- n = get_node(cache, q);
- if (!n || OFF_SLAB(cache))
- continue;
-
- slab_set_lock_classes(cache, &on_slab_l3_key,
- &on_slab_alc_key, n);
- }
-}
-
-static void on_slab_lock_classes_node(struct kmem_cache *cachep,
- struct kmem_cache_node *n)
-{
- slab_set_lock_classes(cachep, &on_slab_l3_key,
- &on_slab_alc_key, n);
-}
-
-static inline void on_slab_lock_classes(struct kmem_cache *cachep)
-{
- int node;
- struct kmem_cache_node *n;
-
- VM_BUG_ON(OFF_SLAB(cachep));
- for_each_kmem_cache_node(cachep, node, n)
- on_slab_lock_classes_node(cachep, n);
-}
-
-static inline void __init init_lock_keys(void)
-{
- int node;
-
- for_each_node(node)
- init_node_lock_keys(node);
-}
-#else
-static void __init init_node_lock_keys(int q)
-{
-}
-
-static inline void init_lock_keys(void)
-{
-}
-
-static inline void on_slab_lock_classes(struct kmem_cache *cachep)
-{
-}
-
-static inline void on_slab_lock_classes_node(struct kmem_cache *cachep,
- struct kmem_cache_node *n)
-{
-}
-
-static void slab_set_debugobj_lock_classes_node(struct kmem_cache *cachep,
- struct kmem_cache_node *n)
-{
-}
-
-static void slab_set_debugobj_lock_classes(struct kmem_cache *cachep)
-{
-}
-#endif
-
static DEFINE_PER_CPU(struct delayed_work, slab_reap_work);
static inline struct array_cache *cpu_cache_get(struct kmem_cache *cachep)
@@ -1354,13 +1221,7 @@ static int cpuup_prepare(long cpu)
spin_unlock_irq(&n->list_lock);
kfree(shared);
free_alien_cache(alien);
- if (cachep->flags & SLAB_DEBUG_OBJECTS)
- slab_set_debugobj_lock_classes_node(cachep, n);
- else if (!OFF_SLAB(cachep) &&
-!(cachep->flags & SLAB_DESTROY_BY_RCU))
- on_slab_lock_classes_node(cachep, n);
}
- init_node_lock_keys(node);
r
[PATCH v3 7/9] slab: destroy a slab without holding any alien cache lock
I haven't heard that this alien cache lock is contended, but to reduce
chance of contention would be better generally. And with this change,
we can simplify complex lockdep annotation in slab code.
In the following patch, it will be implemented.
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
mm/slab.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 1c319ad..854dfa0 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1050,10 +1050,10 @@ static void free_alien_cache(struct alien_cache
**alc_ptr)
}
static void __drain_alien_cache(struct kmem_cache *cachep,
- struct array_cache *ac, int node)
+ struct array_cache *ac, int node,
+ struct list_head *list)
{
struct kmem_cache_node *n = get_node(cachep, node);
- LIST_HEAD(list);
if (ac->avail) {
spin_lock(&n->list_lock);
@@ -1065,10 +1065,9 @@ static void __drain_alien_cache(struct kmem_cache
*cachep,
if (n->shared)
transfer_objects(n->shared, ac, ac->limit);
- free_block(cachep, ac->entry, ac->avail, node, &list);
+ free_block(cachep, ac->entry, ac->avail, node, list);
ac->avail = 0;
spin_unlock(&n->list_lock);
- slabs_destroy(cachep, &list);
}
}
@@ -1086,8 +1085,11 @@ static void reap_alien(struct kmem_cache *cachep, struct
kmem_cache_node *n)
if (alc) {
ac = &alc->ac;
if (ac->avail && spin_trylock_irq(&alc->lock)) {
- __drain_alien_cache(cachep, ac, node);
+ LIST_HEAD(list);
+
+ __drain_alien_cache(cachep, ac, node, &list);
spin_unlock_irq(&alc->lock);
+ slabs_destroy(cachep, &list);
}
}
}
@@ -1104,10 +1106,13 @@ static void drain_alien_cache(struct kmem_cache *cachep,
for_each_online_node(i) {
alc = alien[i];
if (alc) {
+ LIST_HEAD(list);
+
ac = &alc->ac;
spin_lock_irqsave(&alc->lock, flags);
- __drain_alien_cache(cachep, ac, i);
+ __drain_alien_cache(cachep, ac, i, &list);
spin_unlock_irqrestore(&alc->lock, flags);
+ slabs_destroy(cachep, &list);
}
}
}
@@ -1138,10 +1143,11 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
spin_lock(&alien->lock);
if (unlikely(ac->avail == ac->limit)) {
STATS_INC_ACOVERFLOW(cachep);
- __drain_alien_cache(cachep, ac, nodeid);
+ __drain_alien_cache(cachep, ac, nodeid, &list);
}
ac_put_obj(cachep, ac, objp);
spin_unlock(&alien->lock);
+ slabs_destroy(cachep, &list);
} else {
n = get_node(cachep, nodeid);
spin_lock(&n->list_lock);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC net-next 11/14] tracing: allow eBPF programs to be attached to events
On 06/28/2014 02:06 AM, Alexei Starovoitov wrote: User interface: cat bpf_123 > /sys/kernel/debug/tracing/__event__/filter where 123 is an id of the eBPF program priorly loaded. __event__ is static tracepoint event. (kprobe events will be supported in the future patches) eBPF programs can call in-kernel helper functions to: - lookup/update/delete elements in maps - memcmp - trace_printk - load_pointer - dump_stack Are there plans to let eBPF replace the generic event filtering framework in tracing? Signed-off-by: Alexei Starovoitov --- include/linux/ftrace_event.h |5 + include/trace/bpf_trace.h | 29 + include/trace/ftrace.h | 10 ++ include/uapi/linux/bpf.h |5 + kernel/trace/Kconfig |1 + kernel/trace/Makefile |1 + kernel/trace/bpf_trace.c | 217 kernel/trace/trace.h |3 + kernel/trace/trace_events.c|7 ++ kernel/trace/trace_events_filter.c | 72 +++- 10 files changed, 349 insertions(+), 1 deletion(-) create mode 100644 include/trace/bpf_trace.h create mode 100644 kernel/trace/bpf_trace.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ASoC: tas2552: Support TI TAS2552 Amplifier
On Mon, Jun 30, 2014 at 10:43:42PM +0100, Mark Brown wrote: > On Mon, Jun 30, 2014 at 06:21:15PM +0100, Mark Rutland wrote: > > On Mon, Jun 30, 2014 at 06:10:59PM +0100, Dan Murphy wrote: > > > > +Optional properties: > > > > +- power-gpio - gpio pin to enable/disable the device > > > The code below seems to look for "enable-gpio". Searching for > > "power-gpio" only hits in the line above and the example below. I assume > > the code is in error? > > It depends what this is for - if it's for an external regulator it > should be a regulator binding. Also all GPIO properties > are supposed to be called -gpios because DT conventions. Sure. I was commenting on the mismatch between "enable" in the code and "power" in the documentation rather than the appropriateness of either "power-gpios" or "enable-gpios". Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance
On 07/01/2014 04:20 PM, Peter Zijlstra wrote: [snip] >> >> Just wondering could we make this another scheduler feature? > > No; sched_feat() is for debugging, BIG CLUE: its guarded by > CONFIG_SCHED_DEBUG, anybody using it in production or anywhere else is > broken. > > If people are using it, I should remove or at least randomize the > interface. Fair enough... but is there any suggestions on how to handle this issue? Currently when dbench running with stress, it could only gain one CPU, and cpu-cgroup cpu.shares is meaningless, is there any good methods to address that? Regards, Michael Wang > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/exynos: Fix NULL pointer exception when suspending without components
On 2014년 06월 30일 22:25, Krzysztof Kozlowski wrote: > Fix a NULL pointer exception when main exynos drm driver was probed > successfully but no components were added (e.g. by incomplete DTS). In > such case the exynos_drm_load() is never called and drvdata is NULL. > Right, it's good report. Applied. Thanks, Inki Dae > The NULL pointer exception may theoretically also happen as a effect of race > between > adding components and main driver: if suspend of the driver happens > before adding components. > > Trace: > [1.190295] [drm] Initialized drm 1.1.0 20060810 > [1.195209] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully. > (...) > [ 24.001743] PM: Syncing filesystems ... done. > [ 24.002177] Freezing user space processes ... (elapsed 0.000 seconds) done. > [ 24.007403] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) > done. > [ 24.032559] Unable to handle kernel NULL pointer dereference at virtual > address 0134 > [ 24.035007] pgd = dedd8000 > [ 24.037734] [0134] *pgd=5ee13831, *pte=, *ppte= > [ 24.043953] Internal error: Oops: 17 [#1] PREEMPT SMP ARM > [ 24.049329] Modules linked in: > [ 24.052371] CPU: 0 PID: 1 Comm: sh Not tainted > 3.16.0-rc3-00035-geba20bbdde04-dirty #51 > [ 24.060354] task: df478000 ti: df48 task.ti: df48 > [ 24.065743] PC is at mutex_lock+0x10/0x50 > [ 24.069733] LR is at drm_modeset_lock_all+0x30/0xbc > [ 24.074590] pc : []lr : []psr: a013 > [ 24.074590] sp : df481db8 ip : fp : c05e524c > [ 24.086045] r10: 0002 r9 : c02c1fe4 r8 : deca5e44 > [ 24.091253] r7 : r6 : r5 : 014c r4 : 0134 > [ 24.097763] r3 : r2 : r1 : r0 : 0134 > [ 24.104275] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > user > [ 24.111391] Control: 10c53c7d Table: 5edd806a DAC: 0015 > [ 24.117120] Process sh (pid: 1, stack limit = 0xdf480240) > [ 24.122502] Stack: (0xdf481db8 to 0xdf482000) > [ 24.126843] 1da0: > dee01d80 c02a14b4 > [ 24.135004] 1dc0: c07aff98 c02aec7c 0002 > c07aff98 > [ 24.143164] 1de0: deca5e10 c02aecf4 c02aecd4 c02c2010 c02c9470 > > [ 24.151322] 1e00: deca5e10 deca5e10 c07aff98 > 0002 deca5e44 > [ 24.159482] 1e20: c06d8f78 c06fb800 deca5e78 c02ca660 df7baf00 007b0aa0 > deca5e10 c06fb7c8 > [ 24.167641] 1e40: c07aff98 0002 c02cbe18 9757aec5 0005 > 9757aec5 0005 > [ 24.175801] 1e60: ded1d380 0003 0003 c05c74d8 ded1d380 c07209d4 > c05c7514 c07105d8 > [ 24.183960] 1e80: 01e2a738 c0068a74 c05c7514 ded1d380 c071c6e0 > 0004 c07105d8 > [ 24.192119] 1ea0: 01e2a738 c047f1e0 c0600cc0 df481ec4 0003 > 0003 c05c74d8 > [ 24.200278] 1ec0: ded1d380 c071c6e0 c05c7514 c07105d8 01e2a738 c0069444 > c06d905c 0003 > [ 24.208438] 1ee0: 0003 ded1d380 c06d9064 0004 c05c3fc0 c0067d4c > df535ab0 ded1d380 > [ 24.216596] 1f00: df481f80 ded1d380 0004 ded1d1cc ded1d1c0 c0221724 > 0004 c016ca6c > [ 24.224756] 1f20: c016ca28 c016c1d4 > b6f37000 df481f80 > [ 24.232915] 1f40: decedd80 0004 df48 df48 b6f37000 c0110920 > df47839c 6013 > [ 24.241074] 1f60: decedd80 decedd80 0004 df48 > b6f37000 c0110da8 > [ 24.249233] 1f80: 0004 b6edf5d8 0004 b6f37000 > 0004 c000f2a8 > [ 24.257393] 1fa0: 1000 c000f0e0 b6edf5d8 0004 0001 b6f37000 > 0004 > [ 24.265551] 1fc0: b6edf5d8 0004 b6f37000 0004 0004 0001 > 01e2a738 > [ 24.273711] 1fe0: beba0a20 b6e1f4f0 b6e7022c 6010 0001 > > [ 24.281885] [] (mutex_lock) from [] > (drm_modeset_lock_all+0x30/0xbc) > [ 24.289950] [] (drm_modeset_lock_all) from [] > (exynos_drm_suspend+0xc/0x64) > [ 24.298627] [] (exynos_drm_suspend) from [] > (exynos_drm_sys_suspend+0x20/0x34) > [ 24.307568] [] (exynos_drm_sys_suspend) from [] > (platform_pm_suspend+0x2c/0x54) > [ 24.316597] [] (platform_pm_suspend) from [] > (dpm_run_callback+0x48/0x170) > [ 24.325188] [] (dpm_run_callback) from [] > (__device_suspend+0x128/0x39c) > [ 24.333606] [] (__device_suspend) from [] > (dpm_suspend+0x5c/0x314) > [ 24.341506] [] (dpm_suspend) from [] > (suspend_devices_and_enter+0x8c/0x598) > [ 24.350185] [] (suspend_devices_and_enter) from [] > (pm_suspend+0x4c4/0x5d0) > [ 24.358862] [] (pm_suspend) from [] > (state_store+0x70/0xd4) > [ 24.366156] [] (state_store) from [] > (kobj_attr_store+0x14/0x20) > [ 24.373885] [] (kobj_attr_store) from [] > (sysfs_kf_write+0x44/0x48) > [ 24.381867] [] (sysfs_kf_write) from [] > (kernfs_fop_write+0xc0/0x17c) > [ 24.390027] [] (kernfs_fop_write) from [] > (vfs
Re: [RFC 1/1] proc: constify seq_operations
On Tue, Jul 1, 2014 at 10:17 AM, Christoph Hellwig wrote: > On Mon, Jun 30, 2014 at 01:39:39PM -0700, Andrew Morton wrote: >> On Mon, 30 Jun 2014 21:03:17 +0200 Fabian Frederick wrote: >> >> > proc_uid_seq_operations, proc_gid_seq_operations and >> > proc_projid_seq_operations >> > are only called in proc_id_map_open with seq_open as >> > const struct seq_operations so we can constify the 3 structures and update >> > proc_id_map_open prototype. >> >> There are an absolutely enormous number of places where we could >> constify things. For sheer sanity's sake I'm not inclined to churn the >> code in this way unless a patch provides some sort of runtime benefit. >> And this particular patch doesn't appear to change the generated code >> at all. > > Unlike a lot of the cleanup patches which provide no benefit at all > constifying op vectors moves them from .text to .data which is not > marked executable and thus reduce the attack vector for kernel exploits. > > So I defintively like to see these much more than a lot of the other > things filling up the lists. BTW: Daniel Walter and I are currently working with grsec's constify gcc plugin. This plugin automatically makes structs const which contain only function pointers. Our goal is to bring it mainline. We cannot enable it by default as many gcc toolchains have plugin support disabled. But at least as tool in tools/ it would be handy to create constify patches automatically... -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipv4: icmp: Fix pMTU handling for rare case
On Tue, 1 Jul 2014, David Miller wrote: From: Edward Allcutt Date: Mon, 30 Jun 2014 16:16:02 +0100 This is explicitly described as an eventuality that hosts must deal with by the standard (RFC 1191) since older standards specified that those bits must be zero. ... One example I have seen is an OpenBSD router terminating IPSec tunnels. Why doesn't OpenBSD implement RFC 1191? Why do you think I know? :) However the standard says that you should interoperate with older implementations, and I can't see any downside to doing so. I really don't want to allow for zero values. Why? I have had a look through all the higher level protocols and they seem to handle this fine, if they are allowed to see the signal at all. Most of them fall back to the minimum packet size, which isn't ideal but it's much better than just stalling indefinitely. If it helps any, I've been running several production machines with this patch for just about a year now (mostly running 3.10 stable series). -- Edward Allcutt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] add rockchip i2s driver
From: Jianqun Xu This patch is to add driver for I2S controller in RK3xxx SoCs. Jianqun Xu (2): ASoC: dt-bindings: add rockchip i2s bindings ASoC: add driver for Rockchip RK3xxx I2S controller .../devicetree/bindings/sound/rockchip-i2s.txt | 45 ++ sound/soc/Kconfig |1 + sound/soc/Makefile |1 + sound/soc/rockchip/Kconfig | 16 + sound/soc/rockchip/Makefile|6 + sound/soc/rockchip/i2s.h | 222 +++ sound/soc/rockchip/pcm.h | 14 + sound/soc/rockchip/rockchip_i2s.c | 622 sound/soc/rockchip/rockchip_pcm.c | 64 ++ 9 files changed, 991 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/rockchip-i2s.txt create mode 100644 sound/soc/rockchip/Kconfig create mode 100644 sound/soc/rockchip/Makefile create mode 100644 sound/soc/rockchip/i2s.h create mode 100644 sound/soc/rockchip/pcm.h create mode 100644 sound/soc/rockchip/rockchip_i2s.c create mode 100644 sound/soc/rockchip/rockchip_pcm.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ASoC: dt-bindings: add rockchip i2s bindings
From: Jianqun Xu
Add devicetree bindings for i2s controller found on rk3066, rk3188 and rk3288
processors from rockchip.
Signed-off-by: Jianqun Xu
---
.../devicetree/bindings/sound/rockchip-i2s.txt | 45
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/rockchip-i2s.txt
diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
new file mode 100644
index 000..e9ab122
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
@@ -0,0 +1,45 @@
+* Rockchip I2S controller
+
+The I2S bus (Inter-IC sound bus) is a serial link for digital audio data
transfer
+between devices in the system and be invented by Philips Semiconductor.
+
+Required properties:
+
+- compatible : should be one of the following.
+ "rockchip,rk3066-i2s": for rk3066
+ "rockchip,rk3188-i2s", "rockchip,rk3066-i2s" for rk3188
+ "rockchip,rk3288-i2s", "rockchip,rk3066-i2s" for rk3288
+- reg : physical base address of the controller and length of memory mapped
+ region.
+- interrupts : The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller.
+- #address-cells : should be 1.
+- #size-cells : should be 0.
+- dmas : list of DMA controller phandle and DMA request line ordered pairs.
+- dma-names : identifier string for each DMA request line in the dmas property.
+ These strings correspond 1:1 with the ordered pairs in dmas.
+ Must include the following entries:
+ - rx:
+ - tx:
+- clocks : Handle to internal work clock and master clock output to IO.
+- clock-names :
+ - "i2s_hclk": support AHB bus interface
+ - "i2s_clk": work clock for i2s controller
+
+Example:
+
+aliases {
+ i2s0 = &i2s0;
+}
+
+i2s0: i2s@ff89 {
+ compatible = "rockchip,rk3066-i2s";
+ reg = <0xff89 0x1>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dmas = <&pdma1 0>, <&pdma1 1>;
+ dma-names = "rx", "tx";
+ clock-names = "i2s_hclk", "i2s_clk";
+ clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 v2] HID: leds: Use attribute-groups in MSI GT683R driver
On Mon, Jun 30, 2014 at 04:17:10PM -0700, Bryan Wu wrote:
> On Mon, Jun 30, 2014 at 4:33 AM, Jiri Kosina wrote:
> > On Mon, 30 Jun 2014, Johan Hovold wrote:
> >
> >> > I think the better place is HID/input tree, since this patch depends
> >> > on the initial one which is not in my tree.
> >> > I'm going to merge Johan's whole patchset and this patch probably
> >> > depends Johan's work too.
> >>
> >> Dmitry has ACKed the input-patch and Bryan has applied that one and the
> >> leds-patches to his tree (of which the first one is a dependency of this
> >> patch).
> >>
> >> Jiri, are you saying that the gt683r-driver should go in through his
> >> tree as well, that is all three patches including the first that you
> >> have already applied? I just assumed your for-next branch was immutable,
> >> but perhaps I was mistaken.
> >
> > Well, for-next branch is a collection of all the topic branches I am
> > queuing for the following merge window.
> >
> > I am never really rebasing it, but I can definitely not include
> > 'for-3.17/hid-gt683r' topic branch in the pile I will be sending to Linus
> > (all the scheduled branches are getting merged into 'for-linus' only when
> > merge window open). So the only potential conflict between hid.git and
> > Bryan's tree would be in linux-next (and probably there will be none, git
> > can handle duplicate patches nicely).
> >
> > So once Bryan confirms he's queued it (please preserve my Signoff from my
> > tree), then I will just not include for-3.17/hid-gt683r branch in pull
> > request to Linus and all is fine.
> >
>
> I'm OK to merge Janne's first patch for HID GT683R through my tree
> with you guys' SOB.
> I'm also OK to merge this incremental patchset here. Please confirm it
> if I didn't misunderstand here.
That's correct. But the incremental patch set might need one more spin
before it is ready to be applied.
> Also Janne or someone, can you post the original first patch to me or
> point me where is it?
You could cherry-pick it from Jiri's for-3.17/hid-gt683r branch at
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
commit 4e3ed79670e0 ("HID: add support for MSI GT683R led panels").
Otherwise, the patch is here:
http://marc.info/?l=linux-usb&m=140310755911256&w=2
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ASoC: add driver for Rockchip RK3xxx I2S controller
From: Jianqun Xu Add driver for I2S controller in Rockchip RK3xxx SoCs. This driver patch has been tested on the RK3288 SDK board. Signed-off-by: Jianqun Xu --- sound/soc/Kconfig |1 + sound/soc/Makefile|1 + sound/soc/rockchip/Kconfig| 16 + sound/soc/rockchip/Makefile |6 + sound/soc/rockchip/i2s.h | 222 + sound/soc/rockchip/pcm.h | 14 + sound/soc/rockchip/rockchip_i2s.c | 622 + sound/soc/rockchip/rockchip_pcm.c | 64 8 files changed, 946 insertions(+) create mode 100644 sound/soc/rockchip/Kconfig create mode 100644 sound/soc/rockchip/Makefile create mode 100644 sound/soc/rockchip/i2s.h create mode 100644 sound/soc/rockchip/pcm.h create mode 100644 sound/soc/rockchip/rockchip_i2s.c create mode 100644 sound/soc/rockchip/rockchip_pcm.c diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig index 0060b31..0e96233 100644 --- a/sound/soc/Kconfig +++ b/sound/soc/Kconfig @@ -47,6 +47,7 @@ source "sound/soc/kirkwood/Kconfig" source "sound/soc/intel/Kconfig" source "sound/soc/mxs/Kconfig" source "sound/soc/pxa/Kconfig" +source "sound/soc/rockchip/Kconfig" source "sound/soc/samsung/Kconfig" source "sound/soc/s6000/Kconfig" source "sound/soc/sh/Kconfig" diff --git a/sound/soc/Makefile b/sound/soc/Makefile index 5f1df02..534714a 100644 --- a/sound/soc/Makefile +++ b/sound/soc/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_SND_SOC) += nuc900/ obj-$(CONFIG_SND_SOC) += omap/ obj-$(CONFIG_SND_SOC) += kirkwood/ obj-$(CONFIG_SND_SOC) += pxa/ +obj-$(CONFIG_SND_SOC) += rockchip/ obj-$(CONFIG_SND_SOC) += samsung/ obj-$(CONFIG_SND_SOC) += s6000/ obj-$(CONFIG_SND_SOC) += sh/ diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig new file mode 100644 index 000..946b60c --- /dev/null +++ b/sound/soc/rockchip/Kconfig @@ -0,0 +1,16 @@ +config SND_SOC_ROCKCHIP + tristate "ASoC support for Rockchip" + depends on SND_SOC && ARCH_ROCKCHIP + select SND_SOC_GENERIC_DMAENGINE_PCM + select SND_ROCKCHIP_PCM + select SND_ROCKCHIP_I2S + help + Say Y or M if you want to add support for codecs attached to + the Rockchip SoCs' Audio interfaces. You will also need to + select the audio interfaces to support below. + +config SND_ROCKCHIP_I2S + tristate + +config SND_ROCKCHIP_PCM + tristate diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile new file mode 100644 index 000..0b5d47e --- /dev/null +++ b/sound/soc/rockchip/Makefile @@ -0,0 +1,6 @@ +# ROCKCHIP Platform Support +snd-soc-i2s-objs := rockchip_i2s.o +snd-soc-pcm-objs := rockchip_pcm.o + +obj-$(CONFIG_SND_ROCKCHIP_I2S) += snd-soc-i2s.o +obj-$(CONFIG_SND_ROCKCHIP_PCM) += snd-soc-pcm.o diff --git a/sound/soc/rockchip/i2s.h b/sound/soc/rockchip/i2s.h new file mode 100644 index 000..54a5a67 --- /dev/null +++ b/sound/soc/rockchip/i2s.h @@ -0,0 +1,222 @@ +/* + * i2s.h - ALSA IIS interface for the rockchip SoC + * + * Driver for rockchip iis audio + * + * 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 + +#ifndef _ROCKCHIP_IIS_H +#define _ROCKCHIP_IIS_H + +/* + * TXCR + * transmit operation control register +*/ +#define I2S_TXCR_RCNT_SHIFT17 +#define I2S_TXCR_RCNT_MASK (0x3f << I2S_TXCR_RCNT_SHIFT) +#define I2S_TXCR_CSR_SHIFT 15 +#define I2S_TXCR_CSR(x)(x << I2S_TXCR_CSR_SHIFT) +#define I2S_TXCR_CSR_MASK (3 << I2S_TXCR_CSR_SHIFT) +#define I2S_TXCR_HWT BIT(14) +#define I2S_TXCR_SJM_SHIFT 12 +#define I2S_TXCR_SJM_R (0 << I2S_TXCR_SJM_SHIFT) +#define I2S_TXCR_SJM_L (1 << I2S_TXCR_SJM_SHIFT) +#define I2S_TXCR_FBM_SHIFT 11 +#define I2S_TXCR_FBM_MSB (0 << I2S_TXCR_FBM_SHIFT) +#define I2S_TXCR_FBM_LSB (1 << I2S_TXCR_FBM_SHIFT) +#define I2S_TXCR_IBM_SHIFT 9 +#define I2S_TXCR_IBM_NORMAL(0 << I2S_TXCR_IBM_SHIFT) +#define I2S_TXCR_IBM_LSJM (1 << I2S_TXCR_IBM_SHIFT) +#define I2S_TXCR_IBM_RSJM (2 << I2S_TXCR_IBM_SHIFT) +#define I2S_TXCR_IBM_MASK (3 << I2S_TXCR_IBM_SHIFT) +#define I2S_TXCR_PBM_SHIFT 7 +#define I2S_TXCR_PBM_MODE(x) (x << I2S_TXCR_PBM_SHIFT) +#define I2S_TXCR_PBM_MASK (3 << I2S_TXCR_PBM_SHIFT) +#define I2S_TXCR_TFS_SHIFT 5 +#define I2S_TXCR_TFS_I2S (0 << I2S_TXCR_TFS_SHIFT) +#define I2S_TXCR_TFS_PCM (1 << I2S_TXCR_TFS_SHIFT) +#define I2S_TXCR_VDW_SHIFT 0 +#define I2S_TXCR_VDW(x)((x - 1) << I2S_TXCR_VDW_SHIFT) +#define I2S_TXCR_VDW_MASK (0x1f << I2S_TXCR_VDW_SHIFT) + +/* + * RXCR + * receive operation control register +*/ +#define I2S_RXCR_HWT BIT(14) +#define I2S_RXCR_SJM_SHIFT 12 +#define I2S_RXCR_SJM_R (0 << I2S_RXCR_SJM_SHIFT) +#define I2S_RXCR_SJM_L (1 << I2S_RXCR_SJM_SHIFT) +#define I2
[PATCH 2/2] ASoC: add driver for Rockchip RK3xxx I2S controller
From: Jianqun Xu Add driver for I2S controller in Rockchip RK3xxx SoCs. This driver patch has been tested on the RK3288 SDK board. Signed-off-by: Jianqun Xu --- sound/soc/Kconfig |1 + sound/soc/Makefile|1 + sound/soc/rockchip/Kconfig| 16 + sound/soc/rockchip/Makefile |6 + sound/soc/rockchip/i2s.h | 222 + sound/soc/rockchip/pcm.h | 14 + sound/soc/rockchip/rockchip_i2s.c | 622 + sound/soc/rockchip/rockchip_pcm.c | 64 8 files changed, 946 insertions(+) create mode 100644 sound/soc/rockchip/Kconfig create mode 100644 sound/soc/rockchip/Makefile create mode 100644 sound/soc/rockchip/i2s.h create mode 100644 sound/soc/rockchip/pcm.h create mode 100644 sound/soc/rockchip/rockchip_i2s.c create mode 100644 sound/soc/rockchip/rockchip_pcm.c diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig index 0060b31..0e96233 100644 --- a/sound/soc/Kconfig +++ b/sound/soc/Kconfig @@ -47,6 +47,7 @@ source "sound/soc/kirkwood/Kconfig" source "sound/soc/intel/Kconfig" source "sound/soc/mxs/Kconfig" source "sound/soc/pxa/Kconfig" +source "sound/soc/rockchip/Kconfig" source "sound/soc/samsung/Kconfig" source "sound/soc/s6000/Kconfig" source "sound/soc/sh/Kconfig" diff --git a/sound/soc/Makefile b/sound/soc/Makefile index 5f1df02..534714a 100644 --- a/sound/soc/Makefile +++ b/sound/soc/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_SND_SOC) += nuc900/ obj-$(CONFIG_SND_SOC) += omap/ obj-$(CONFIG_SND_SOC) += kirkwood/ obj-$(CONFIG_SND_SOC) += pxa/ +obj-$(CONFIG_SND_SOC) += rockchip/ obj-$(CONFIG_SND_SOC) += samsung/ obj-$(CONFIG_SND_SOC) += s6000/ obj-$(CONFIG_SND_SOC) += sh/ diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig new file mode 100644 index 000..946b60c --- /dev/null +++ b/sound/soc/rockchip/Kconfig @@ -0,0 +1,16 @@ +config SND_SOC_ROCKCHIP + tristate "ASoC support for Rockchip" + depends on SND_SOC && ARCH_ROCKCHIP + select SND_SOC_GENERIC_DMAENGINE_PCM + select SND_ROCKCHIP_PCM + select SND_ROCKCHIP_I2S + help + Say Y or M if you want to add support for codecs attached to + the Rockchip SoCs' Audio interfaces. You will also need to + select the audio interfaces to support below. + +config SND_ROCKCHIP_I2S + tristate + +config SND_ROCKCHIP_PCM + tristate diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile new file mode 100644 index 000..0b5d47e --- /dev/null +++ b/sound/soc/rockchip/Makefile @@ -0,0 +1,6 @@ +# ROCKCHIP Platform Support +snd-soc-i2s-objs := rockchip_i2s.o +snd-soc-pcm-objs := rockchip_pcm.o + +obj-$(CONFIG_SND_ROCKCHIP_I2S) += snd-soc-i2s.o +obj-$(CONFIG_SND_ROCKCHIP_PCM) += snd-soc-pcm.o diff --git a/sound/soc/rockchip/i2s.h b/sound/soc/rockchip/i2s.h new file mode 100644 index 000..54a5a67 --- /dev/null +++ b/sound/soc/rockchip/i2s.h @@ -0,0 +1,222 @@ +/* + * i2s.h - ALSA IIS interface for the rockchip SoC + * + * Driver for rockchip iis audio + * + * 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 + +#ifndef _ROCKCHIP_IIS_H +#define _ROCKCHIP_IIS_H + +/* + * TXCR + * transmit operation control register +*/ +#define I2S_TXCR_RCNT_SHIFT17 +#define I2S_TXCR_RCNT_MASK (0x3f << I2S_TXCR_RCNT_SHIFT) +#define I2S_TXCR_CSR_SHIFT 15 +#define I2S_TXCR_CSR(x)(x << I2S_TXCR_CSR_SHIFT) +#define I2S_TXCR_CSR_MASK (3 << I2S_TXCR_CSR_SHIFT) +#define I2S_TXCR_HWT BIT(14) +#define I2S_TXCR_SJM_SHIFT 12 +#define I2S_TXCR_SJM_R (0 << I2S_TXCR_SJM_SHIFT) +#define I2S_TXCR_SJM_L (1 << I2S_TXCR_SJM_SHIFT) +#define I2S_TXCR_FBM_SHIFT 11 +#define I2S_TXCR_FBM_MSB (0 << I2S_TXCR_FBM_SHIFT) +#define I2S_TXCR_FBM_LSB (1 << I2S_TXCR_FBM_SHIFT) +#define I2S_TXCR_IBM_SHIFT 9 +#define I2S_TXCR_IBM_NORMAL(0 << I2S_TXCR_IBM_SHIFT) +#define I2S_TXCR_IBM_LSJM (1 << I2S_TXCR_IBM_SHIFT) +#define I2S_TXCR_IBM_RSJM (2 << I2S_TXCR_IBM_SHIFT) +#define I2S_TXCR_IBM_MASK (3 << I2S_TXCR_IBM_SHIFT) +#define I2S_TXCR_PBM_SHIFT 7 +#define I2S_TXCR_PBM_MODE(x) (x << I2S_TXCR_PBM_SHIFT) +#define I2S_TXCR_PBM_MASK (3 << I2S_TXCR_PBM_SHIFT) +#define I2S_TXCR_TFS_SHIFT 5 +#define I2S_TXCR_TFS_I2S (0 << I2S_TXCR_TFS_SHIFT) +#define I2S_TXCR_TFS_PCM (1 << I2S_TXCR_TFS_SHIFT) +#define I2S_TXCR_VDW_SHIFT 0 +#define I2S_TXCR_VDW(x)((x - 1) << I2S_TXCR_VDW_SHIFT) +#define I2S_TXCR_VDW_MASK (0x1f << I2S_TXCR_VDW_SHIFT) + +/* + * RXCR + * receive operation control register +*/ +#define I2S_RXCR_HWT BIT(14) +#define I2S_RXCR_SJM_SHIFT 12 +#define I2S_RXCR_SJM_R (0 << I2S_RXCR_SJM_SHIFT) +#define I2S_RXCR_SJM_L (1 << I2S_RXCR_SJM_SHIFT) +#define I2
Re: [PATCH 1/2] ASoC: dt-bindings: add rockchip i2s bindings
On Tue, Jul 01, 2014 at 09:37:39AM +0100, jianqun wrote:
> From: Jianqun Xu
>
> Add devicetree bindings for i2s controller found on rk3066, rk3188 and rk3288
> processors from rockchip.
>
> Signed-off-by: Jianqun Xu
> ---
> .../devicetree/bindings/sound/rockchip-i2s.txt | 45
>
> 1 file changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/rockchip-i2s.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
> b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
> new file mode 100644
> index 000..e9ab122
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
> @@ -0,0 +1,45 @@
> +* Rockchip I2S controller
> +
> +The I2S bus (Inter-IC sound bus) is a serial link for digital audio data
> transfer
> +between devices in the system and be invented by Philips Semiconductor.
> +
> +Required properties:
> +
> +- compatible : should be one of the following.
> + "rockchip,rk3066-i2s": for rk3066
> + "rockchip,rk3188-i2s", "rockchip,rk3066-i2s" for rk3188
> + "rockchip,rk3288-i2s", "rockchip,rk3066-i2s" for rk3288
> +- reg : physical base address of the controller and length of memory mapped
> + region.
> +- interrupts : The interrupt number to the cpu. The interrupt specifier
> format
> + depends on the interrupt controller.
> +- #address-cells : should be 1.
> +- #size-cells : should be 0.
> +- dmas : list of DMA controller phandle and DMA request line ordered pairs.
> +- dma-names : identifier string for each DMA request line in the dmas
> property.
> + These strings correspond 1:1 with the ordered pairs in dmas.
> + Must include the following entries:
> + - rx:
> + - tx:
Can these be quoted for consistency with clock-names below?
> +- clocks : Handle to internal work clock and master clock output to IO.
Can this be written in terms of clock-names, e.g.
- clocks: a list of phandle + clock-specifer pairs, one for each entry
in clock-names.
Cheers,
Mark.
> +- clock-names :
> + - "i2s_hclk": support AHB bus interface
> + - "i2s_clk": work clock for i2s controller
> +
> +Example:
> +
> +aliases {
> + i2s0 = &i2s0;
> +}
> +
> +i2s0: i2s@ff89 {
> + compatible = "rockchip,rk3066-i2s";
> + reg = <0xff89 0x1>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dmas = <&pdma1 0>, <&pdma1 1>;
> + dma-names = "rx", "tx";
> + clock-names = "i2s_hclk", "i2s_clk";
> + clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>;
> +};
> --
> 1.7.9.5
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/12] usb: chipidea: add a generic driver
On 07/01/2014 02:21 AM, Peter Chen wrote:
On Mon, Jun 30, 2014 at 03:33:13PM +0200, Antoine Ténart wrote:
On Fri, Jun 27, 2014 at 11:25:07AM +0800, Peter Chen wrote:
On Tue, Jun 24, 2014 at 12:35:16PM +0200, Antoine Ténart wrote:
+
+static const struct of_device_id ci_hdrc_generic_of_match[] = {
+ { .compatible = "chipidea-usb" },
+ { }
+};
Even as a generic driver, you can also use your own compatible string.
Well, there is nothing specific about the Berlin CI. Some subsystems
use the 'generic' keyword in these cases. Do you see a particular reason
I should use some Berlin related compatible here?
Not must, one suggestion is: can you change the compatible string
to "chipidea-usb-generic"?
I don't know about ChipIdea/ARC/DW's product portfolio but I guess
the compatible should also carry '2.0' or 'usb2' in it. Or we just
use some version number like 'chipidea,ci13000' or 'chipidea,ci13xxx'.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance
On Tue, Jul 01, 2014 at 04:38:58PM +0800, Michael wang wrote: > On 07/01/2014 04:20 PM, Peter Zijlstra wrote: > [snip] > >> > >> Just wondering could we make this another scheduler feature? > > > > No; sched_feat() is for debugging, BIG CLUE: its guarded by > > CONFIG_SCHED_DEBUG, anybody using it in production or anywhere else is > > broken. > > > > If people are using it, I should remove or at least randomize the > > interface. > > Fair enough... but is there any suggestions on how to handle this issue? > > Currently when dbench running with stress, it could only gain one CPU, > and cpu-cgroup cpu.shares is meaningless, is there any good methods to > address that? So as far as I understood this is because of 'other' tasks; these other tasks have never been fully qualified, but I suspect they're workqueue thingies. One solution would be to have work run in the same cgroup as the task creating it. The thing is, this is not a scheduler problem, so we should not fix it in the scheduler. pgpNVpAS4bMxz.pgp Description: PGP signature
Re: [PATCH 2/2] ASoC: add driver for Rockchip RK3xxx I2S controller
On Tue, Jul 01, 2014 at 09:47:38AM +0100, jianqun wrote:
> From: Jianqun Xu
>
> Add driver for I2S controller in Rockchip RK3xxx SoCs.
>
> This driver patch has been tested on the RK3288 SDK board.
>
> Signed-off-by: Jianqun Xu
> ---
> sound/soc/Kconfig |1 +
> sound/soc/Makefile|1 +
> sound/soc/rockchip/Kconfig| 16 +
> sound/soc/rockchip/Makefile |6 +
> sound/soc/rockchip/i2s.h | 222 +
> sound/soc/rockchip/pcm.h | 14 +
> sound/soc/rockchip/rockchip_i2s.c | 622
> +
> sound/soc/rockchip/rockchip_pcm.c | 64
> 8 files changed, 946 insertions(+)
> create mode 100644 sound/soc/rockchip/Kconfig
> create mode 100644 sound/soc/rockchip/Makefile
> create mode 100644 sound/soc/rockchip/i2s.h
> create mode 100644 sound/soc/rockchip/pcm.h
> create mode 100644 sound/soc/rockchip/rockchip_i2s.c
> create mode 100644 sound/soc/rockchip/rockchip_pcm.c
[...]
> +static int rockchip_i2s_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct rk_i2s_dev *i2s;
> + struct resource *res;
> + int ret;
> +
> + i2s = devm_kzalloc(&pdev->dev, sizeof(struct rk_i2s_dev),
> + GFP_KERNEL);
You can use sizeof(*i2s) here.
[...]
> + /* Try to set the I2S Channel id from dt */
> + pdev->id = of_alias_get_id(np, "i2s");
> + dev_set_name(&pdev->dev, "%s.%d",
> + pdev->dev.driver->name,
> + pdev->id);
This wasn't mentioned in the binding.
Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend v2 0/3] mfd-core: Don't register supplies from add_device, add register_supply_aliases()
> I already send this series before (in time for 3.16) and AFAIK we agreed > on going with this series instead of the incomplete fix for the related oops > which now has been merged as commit d137be00ee017bc40e6027cb66d667a2e0b450fd > > I still believe that this series is the more correct fix, as platform > devices must simply not be used at all before they have been added. We were waiting for Mark's comments. Which we still have to do. As they never appeared the temporary fix went in instead. Moving forward, should that fix be reverted, or it is okay just to apply this set on top? > This series changes the probe messages for the axp209 pmic regulators from: > > [1.386371] Adding alias for supply acin,(null) -> acin,0-0034 > [1.392205] Adding alias for supply vin2,(null) -> vin2,0-0034 > [1.398112] Adding alias for supply vin3,(null) -> vin3,0-0034 > [1.403995] Adding alias for supply ldo24in,(null) -> ldo24in,0-0034 > [1.410344] Adding alias for supply ldo3in,(null) -> ldo3in,0-0034 > [1.416551] Adding alias for supply ldo5in,(null) -> ldo5in,0-0034 > > To: > > [1.410545] Adding alias for supply acin,axp20x-regulator -> acin,0-0034 > [1.417288] Adding alias for supply vin2,axp20x-regulator -> vin2,0-0034 > [1.424002] Adding alias for supply vin3,axp20x-regulator -> vin3,0-0034 > [1.430695] Adding alias for supply ldo24in,axp20x-regulator -> > ldo24in,0-003 > 4 > [1.437922] Adding alias for supply ldo3in,axp20x-regulator -> > ldo3in,0-0034 > [1.444973] Adding alias for supply ldo5in,axp20x-regulator -> > ldo5in,0-0034 > > Notice how all the "(null)" bits are gone. > > No need to rush this into 3.16, but I would still like to see this merged > into 3.17 . > > Changes since v1: > -Rebased on top of 3.16-rc1 / commit d137be00ee017bc40e6027cb66d667a2e0b450fd > > Thanks & Regards, > > Hans -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend v2 0/3] mfd-core: Don't register supplies from add_device, add register_supply_aliases()
Hi, On 07/01/2014 11:05 AM, Lee Jones wrote: >> I already send this series before (in time for 3.16) and AFAIK we agreed >> on going with this series instead of the incomplete fix for the related oops >> which now has been merged as commit d137be00ee017bc40e6027cb66d667a2e0b450fd >> >> I still believe that this series is the more correct fix, as platform >> devices must simply not be used at all before they have been added. > > We were waiting for Mark's comments. Which we still have to do. > > As they never appeared the temporary fix went in instead. > > Moving forward, should that fix be reverted, or it is okay just to > apply this set on top? The resend has been rebased on top of the fix, so it should be applied on top. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: next-20140640 - fatal crash at boot time in sound drivers...
At Mon, 30 Jun 2014 12:45:54 -0400, Valdis Kletnieks wrote: > > Seeing this on a Dell Latitude E6530 - kernel lives for just a few > seconds before committing hari-kiri trying to initialize the sound chipset. The bug has been fixed yesterday, so today's next tree should work. Let me know if you still see the issue. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
On Mon, 30 Jun 2014, Paul Bolle wrote: > Kernels v3.16-rc2 and v3.16-rc3 trigger a new (for me) warning. (I never > booted v3.16-rc1). Machine is a, rather outdated, ThinkPad X41 (ie, > single core i686). > > WARNING: CPU: 0 PID: 221 at drivers/gpu/drm/i915/intel_display.c:1274 > assert_planes_disabled+0xf9/0x100 [i915]() > plane B assertion failure, should be off on pipe B but is still active > Modules linked in: tg3 i915(+) i2c_algo_bit drm_kms_helper ptp drm > ata_generic pata_acpi yenta_socket i2c_core pps_core video > CPU: 0 PID: 221 Comm: systemd-udevd Not tainted > 3.16.0-0.rc3.1.local0.fc20.i686 #1 > Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET64WW (2.09 ) 12/14/2006 > c0c87907 add7c490 f652b9ac c09fdab7 f652b9ec f652b9dc c045008e > f830c6cc f652ba0c 00dd f830c634 04fa f82b4d59 f82b4d59 f6728000 > 0001 f65a8c00 f652b9f8 c04500ee 0009 f652b9ec f830c6cc f652ba0c > Call Trace: > [] dump_stack+0x41/0x52 > [] warn_slowpath_common+0x7e/0xa0 > [] ? assert_planes_disabled+0xf9/0x100 [i915] > [] ? assert_planes_disabled+0xf9/0x100 [i915] > [] warn_slowpath_fmt+0x3e/0x60 > [] assert_planes_disabled+0xf9/0x100 [i915] > [] intel_disable_pipe+0x26/0xb0 [i915] > [] ? gen4_read8+0xc0/0xc0 [i915] > [] i9xx_crtc_disable+0x93/0x3d0 [i915] > [] intel_modeset_setup_hw_state+0x7ac/0xbc0 [i915] > [] ? gen4_read8+0xc0/0xc0 [i915] > [] ? drm_modeset_lock_all_crtcs+0x3c/0x50 [drm] > [] intel_modeset_init+0x734/0x1220 [i915] > [] ? i915_enable_pipestat+0xab/0x120 [i915] > [] ? i915_irq_postinstall+0x104/0x110 [i915] > [] ? drm_irq_install+0xa9/0x170 [drm] > [] i915_driver_load+0xa76/0xe70 [i915] > [] ? i915_switcheroo_set_state+0x90/0x90 [i915] > [] ? cleanup_uevent_env+0x10/0x10 > [] ? sysfs_add_file+0x23/0x30 > [] ? get_device+0x14/0x30 > [] ? klist_class_dev_get+0x12/0x20 > [] ? klist_node_init+0x2e/0x50 > [] ? klist_add_tail+0x27/0x30 > [] ? device_add+0x1d6/0x5a0 > [] ? drm_sysfs_device_add+0xba/0x100 [drm] > [] drm_dev_register+0x8e/0xe0 [drm] > [] drm_get_pci_dev+0x79/0x1c0 [drm] > [] i915_pci_probe+0x35/0x60 [i915] > [] pci_device_probe+0x6f/0xc0 > [] ? sysfs_create_link+0x25/0x40 > [] driver_probe_device+0x93/0x3a0 > [] ? sysfs_create_dir_ns+0x37/0x80 > [] ? pci_match_device+0xc1/0xe0 > [] __driver_attach+0x71/0x80 > [] ? __device_attach+0x40/0x40 > [] bus_for_each_dev+0x57/0xa0 > [] driver_attach+0x1e/0x20 > [] ? __device_attach+0x40/0x40 > [] bus_add_driver+0x157/0x230 > [] ? 0xf7fc7fff > [] ? 0xf7fc7fff > [] driver_register+0x59/0xe0 > [] ? __kmalloc_track_caller+0x46/0x1f0 > [] __pci_register_driver+0x32/0x40 > [] drm_pci_init+0xe5/0x110 [drm] > [] ? 0xf7fc7fff > [] i915_init+0x88/0x8a [i915] > [] ? 0xf7fc7fff > [] do_one_initcall+0xc2/0x1f0 > [] ? 0xf7fc7fff > [] ? kfree+0xdd/0x120 > [] ? __vunmap+0x8f/0xe0 > [] ? __vunmap+0x8f/0xe0 > [] ? __vunmap+0x8f/0xe0 > [] load_module+0x1a92/0x23b0 > [] ? copy_module_from_fd.isra.46+0x109/0x1a0 > [] SyS_finit_module+0x8d/0xd0 > [] ? vm_mmap_pgoff+0x93/0xb0 > [] sysenter_do_call+0x12/0x16 > > Feel free to prod me for further details. This does not ring any bells to me (but that doesn't prove anything). A bisect result would be awesome. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] man-pages: cap_rights_get: retrieve Capsicum fd rights
On Mon, Jun 30, 2014 at 03:28:14PM -0700, Andy Lutomirski wrote: > On Mon, Jun 30, 2014 at 3:28 AM, David Drysdale wrote: > > Signed-off-by: David Drysdale > > --- > > man2/cap_rights_get.2 | 126 > > ++ > > 1 file changed, 126 insertions(+) > > create mode 100644 man2/cap_rights_get.2 > > > > diff --git a/man2/cap_rights_get.2 b/man2/cap_rights_get.2 > > new file mode 100644 > > index ..966c0ed7e336 > > --- /dev/null > > +++ b/man2/cap_rights_get.2 > > @@ -0,0 +1,126 @@ > > +.\" > > +.\" Copyright (c) 2008-2010 Robert N. M. Watson > > +.\" Copyright (c) 2012-2013 The FreeBSD Foundation > > +.\" Copyright (c) 2013-2014 Google, Inc. > > +.\" All rights reserved. > > +.\" > > +.\" %%%LICENSE_START(BSD_2_CLAUSE) > > +.\" Redistribution and use in source and binary forms, with or without > > +.\" modification, are permitted provided that the following conditions > > +.\" are met: > > +.\" 1. Redistributions of source code must retain the above copyright > > +.\"notice, this list of conditions and the following disclaimer. > > +.\" 2. Redistributions in binary form must reproduce the above copyright > > +.\"notice, this list of conditions and the following disclaimer in the > > +.\"documentation and/or other materials provided with the distribution. > > +.\" > > +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > > +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > > +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > > PURPOSE > > +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > > +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > > CONSEQUENTIAL > > +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > > +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > > +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > > STRICT > > +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY > > WAY > > +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > > +.\" SUCH DAMAGE. > > +.\" %%%LICENSE_END > > +.\" > > +.TH CAP_RIGHTS_GET 2 2014-05-07 "Linux" "Linux Programmer's Manual" > > +.SH NAME > > +cap_rights_get \- retrieve Capsicum capability rights > > +.SH SYNOPSIS > > +.nf > > +.B #include > > +.sp > > +.BI "int cap_rights_get(int " fd ", struct cap_rights *" rights , > > +.BI " unsigned int *" fcntls , > > +.BI " int *" nioctls ", unsigned int *" ioctls ); > > +.SH DESCRIPTION > > +Obtain the current Capsicum capability rights for a file descriptor. > > +.PP > > +The function will fill the > > +.I rights > > +argument (if non-NULL) with the primary capability rights of the > > +.I fd > > +descriptor. The result can be examined with the > > +.BR cap_rights_is_set (3) > > +family of functions. The complete list of primary rights can be found in > > the > > +.BR rights (7) > > +manual page. > > +.PP > > +If the > > +.I fcntls > > +argument is non-NULL, it will be filled in with a bitmask of allowed > > +.BR fcntl (2) > > +commands; see > > +.BR cap_rights_limit (2) > > +for values. If the file descriptor does not have the > > +.B CAP_FCNTL > > +primary right, the returned > > +.I fcntls > > +value will be zero. > > +.PP > > +If the > > +.I nioctls > > +argument is non-NULL, it will be filled in with the number of allowed > > +.BR ioctl (2) > > +commands, or with the value CAP_IOCTLS_ALL to indicate that all > > +.BR ioctl (2) > > +commands are allowed. If the file descriptor does not have the > > +.B CAP_IOCTL > > +primary right, the returned > > +.I nioctls > > +value will be zero. > > +.PP > > +The > > +.I ioctls > > +argument (if non-NULL) should point at memory that can hold up to > > +.I nioctls > > +values. > > +The system call populates the provided buffer with up to > > +.I nioctls > > +elements, but always returns the total number of > > I assume you mean "up to the initial value of *nioctls elements" or > something. Can you clarify? > > --Andy Yeah, that's what I meant. Is this clearer? If the ioctls argument is non-NULL, the caller should specify the size of the provided buffer as the initial value of the nioctls argument (as a count of the number of ioctl(2) command values the buffer can hold). On successful completion of the system call, the ioctls buffer is filled with the ioctl(2) com‐ mand values, up to maximum of the initial value of nioctls. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9 v2] coresight: adding basic support for Vexpress TC2
On 27.06.2014 20:04, mathieu.poir...@linaro.org wrote:
From: Mathieu Poirier
Support for the 2 PTMs, 3 ETMs, funnel, TPIU and replicator
connected to the ETB are included. Proper handling of the
ITM and the replicator linked to it along with the CTIs
and SWO are not included.
Signed-off-by: Mathieu Poirier
---
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 174 +
1 file changed, 174 insertions(+)
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 15f98cb..390f2bb 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
...
+ funnel {
+ compatible = "arm,coresight-funnel", "arm,primecell";
...
+* repicator but configured as par of the funnel.
Two typos here?
repicator -> replicator
as par -> as part
Best regards
Dirk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 13/13] ARM64 / ACPI: Enable ARM64 in Kconfig
On Tue, Jul 01, 2014 at 09:20:20AM +0100, Hanjun Guo wrote: > >>> depends on PCI > >>> select PNP > >>> - default y > >>> + default y if !ARM64 > >> > >> For the benefit of single Image, I think you can default to y here. > > > > It ok to me. if we default to y here, devicetree will not be unflattened > > in default, is it ok to you? you can refer to "[PATCH 12/13] ARM64 / ACPI: > > if > > we chose to boot from acpi then disable FDT". > > Ah, sorry I didn't describe it clearly. since there is no shipping board > with ACPI tables, so ACPI will disabled in the very early stage and FDT > still have chance to be unflattened, so will not break DT booting in > this patchset. That's what I thought. So leaving it as a default y is fine by me. But I would not merge this patch now until we get some useful functionality for arm64. The x86-related cleanup patches can be merged separately via the corresponding trees (it's up to the ACPI and x86 maintainers). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clk: ppc-corenet: Fix Section mismatch warning
WARNING: drivers/built-in.o(.data+0x10258):
Section mismatch in reference from the variable ppc_corenet_clk_driver
to the (unknown reference) .init.rodata:(unknown)
The variable ppc_corenet_clk_driver references
the (unknown reference) __initconst (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Jingchang Lu
---
drivers/clk/clk-ppc-corenet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
index 8b284be..8e58edf 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-ppc-corenet.c
@@ -291,7 +291,7 @@ static const struct of_device_id ppc_clk_ids[] __initconst
= {
{}
};
-static struct platform_driver ppc_corenet_clk_driver = {
+static struct platform_driver ppc_corenet_clk_driver __initdata = {
.driver = {
.name = "ppc_corenet_clock",
.owner = THIS_MODULE,
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware loader: inform direct failure when udev loader is disabled
At Tue, 1 Jul 2014 11:54:24 +0800,
Ming Lei wrote:
>
> On Tue, Jul 1, 2014 at 7:30 AM, Luis R. Rodriguez
> wrote:
> > From: "Luis R. Rodriguez"
> >
> > Now that the udev firmware loader is optional request_firmware()
> > will not provide any information on the kernel ring buffer if
> > direct firmware loading failed and udev firmware loading is disabled.
> > If no information is needed request_firmware_direct() should be used
> > for optional firmware, at which point drivers can take on the onus
> > over informing of any failures, if udev firmware loading is disabled
> > though we should at the very least provide some sort of information
> > as when the udev loader was enabled by default back in the days.
> >
> > With this change with a simple firmware load test module [0]:
> >
> > Example output without FW_LOADER_USER_HELPER_FALLBACK
> >
> > platform fake-dev.0: Direct firmware load for fake.bin failed with error -2
> >
> > Example without FW_LOADER_USER_HELPER_FALLBACK
> >
> > platform fake-dev.0: Direct firmware load for fake.bin failed with error -2
> > platform fake-dev.0: Falling back to user helper
> >
> > Without this change without FW_LOADER_USER_HELPER_FALLBACK we get no output
> > logged upon failure.
> >
> > [0] https://github.com/mcgrof/fake-firmware-test.git
> >
> > Cc: Tom Gundersen
> > Cc: Ming Lei
> > Cc: Greg Kroah-Hartman
> > Cc: Abhay Salunke
> > Cc: Stefan Roese
> > Cc: Arnd Bergmann
> > Cc: Kay Sievers
> > Cc: Takashi Iwai
> > Signed-off-by: Luis R. Rodriguez
> > ---
> >
> > drivers/base/firmware_class.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index 46ea5f4..23274d8 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -101,8 +101,10 @@ static inline long firmware_loading_timeout(void)
> > #define FW_OPT_NOWAIT (1U << 1)
> > #ifdef CONFIG_FW_LOADER_USER_HELPER
> > #define FW_OPT_USERHELPER (1U << 2)
> > +#define FW_OPT_FAIL_WARN 0
> > #else
> > #define FW_OPT_USERHELPER 0
> > +#define FW_OPT_FAIL_WARN (1U << 3)
> > #endif
> > #ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
> > #define FW_OPT_FALLBACKFW_OPT_USERHELPER
> > @@ -1116,10 +1118,11 @@ _request_firmware(const struct firmware
> > **firmware_p, const char *name,
> >
> > ret = fw_get_filesystem_firmware(device, fw->priv);
> > if (ret) {
> > - if (opt_flags & FW_OPT_USERHELPER) {
> > + if (opt_flags & (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER))
> > dev_warn(device,
> > -"Direct firmware load failed with error
> > %d\n",
> > -ret);
> > +"Direct firmware load for %s failed with
> > error %d\n",
> > +name, ret);
>
> Maybe the warning can be always printed out since
> (FW_OPT_FAIL_WARN | FW_OPT_USERHELPER) should be
> always true.
Yes, it'd be simpler. Let's reduce lines! :)
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend v2 1/3] mfd-core: Don't register supplies from add_device, add register_supply_aliases()
On Mon, 30 Jun 2014, Hans de Goede wrote:
> We cannot register supply alias in mfd_add_device before calling
> platform_add_device because platform-dev's name must be set before registering
> the aliases which happens from platform_add_device.
>
> So stop registering supply aliases from mfd_add_device, and add a
> mfd_register_supply_aliases helper functions for the cell's plaform driver
> probe method to use.
>
> Signed-off-by: Hans de Goede
Didn't I already Ack this?
> ---
> drivers/mfd/mfd-core.c | 37 +
> include/linux/mfd/core.h | 6 +-
> 2 files changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 892d343..03f6fee 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -102,13 +102,6 @@ static int mfd_add_device(struct device *parent, int id,
> pdev->dev.dma_mask = parent->dma_mask;
> pdev->dev.dma_parms = parent->dma_parms;
>
> - ret = regulator_bulk_register_supply_alias(
> - &pdev->dev, cell->parent_supplies,
> - parent, cell->parent_supplies,
> - cell->num_parent_supplies);
> - if (ret < 0)
> - goto fail_res;
> -
> if (parent->of_node && cell->of_compatible) {
> for_each_child_of_node(parent->of_node, np) {
> if (of_device_is_compatible(np, cell->of_compatible)) {
> @@ -122,12 +115,12 @@ static int mfd_add_device(struct device *parent, int id,
> ret = platform_device_add_data(pdev,
> cell->platform_data, cell->pdata_size);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
> }
>
> ret = mfd_platform_add_cell(pdev, cell, usage_count);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
>
> for (r = 0; r < cell->num_resources; r++) {
> res[r].name = cell->resources[r].name;
> @@ -162,17 +155,17 @@ static int mfd_add_device(struct device *parent, int id,
> if (!cell->ignore_resource_conflicts) {
> ret = acpi_check_resource_conflict(&res[r]);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
> }
> }
>
> ret = platform_device_add_resources(pdev, res, cell->num_resources);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
>
> ret = platform_device_add(pdev);
> if (ret)
> - goto fail_alias;
> + goto fail_res;
>
> if (cell->pm_runtime_no_callbacks)
> pm_runtime_no_callbacks(&pdev->dev);
> @@ -181,10 +174,6 @@ static int mfd_add_device(struct device *parent, int id,
>
> return 0;
>
> -fail_alias:
> - regulator_bulk_unregister_supply_alias(&pdev->dev,
> -cell->parent_supplies,
> -cell->num_parent_supplies);
> fail_res:
> kfree(res);
> fail_device:
> @@ -289,5 +278,21 @@ int mfd_clone_cell(const char *cell, const char
> **clones, size_t n_clones)
> }
> EXPORT_SYMBOL(mfd_clone_cell);
>
> +int mfd_register_supply_aliases(struct platform_device *pdev)
> +{
> + const struct mfd_cell *cell;
> +
> + if (pdev->dev.type != &mfd_dev_type)
> + return -EINVAL;
> +
> + cell = mfd_get_cell(pdev);
> +
> + return devm_regulator_bulk_register_supply_alias(
> + &pdev->dev, cell->parent_supplies,
> + pdev->dev.parent, cell->parent_supplies,
> + cell->num_parent_supplies);
> +}
> +EXPORT_SYMBOL(mfd_register_supply_aliases);
> +
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Ian Molton, Dmitry Baryshkov");
> diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> index f543de9..f05488e 100644
> --- a/include/linux/mfd/core.h
> +++ b/include/linux/mfd/core.h
> @@ -61,7 +61,9 @@ struct mfd_cell {
> boolpm_runtime_no_callbacks;
>
> /* A list of regulator supplies that should be mapped to the MFD
> - * device rather than the child device when requested
> + * device rather than the child device when requested.
> + * Drivers using this must call mfd_register_supply_aliases()
> + * from their probe method.
>*/
> const char * const *parent_supplies;
> int num_parent_supplies;
> @@ -110,4 +112,6 @@ extern int mfd_add_devices(struct device *parent, int id,
>
> extern void mfd_remove_devices(struct device *parent);
>
> +extern int mfd_register_supply_aliases(struct platform_device *pdev);
> +
> #endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from
Re: [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
On 07/01/2014 03:38 PM, Jan Kiszka wrote:
On 2014-07-01 04:15, Hui Wang wrote:
On 06/30/2014 02:45 PM, Jan Kiszka wrote:
On 2014-06-30 04:04, Hui Wang wrote:
On 06/29/2014 07:33 PM, Jan Kiszka wrote:
On 2013-11-27 07:47, Hui Wang wrote:
Most Thinkpad Edge series laptops use conexant codec, so far although
Is there anything I can debug or any information I can collect from my
box to examine this?
What is the linux distribution on your machine? And use showkey to catch
the keycode of that button.
I'm running OpenSUSE 13.1. The reported keycode of the power button is 116.
It seems the keycode is correct, it is power keycode rather the mute
keycode.
Could you please do some debug, let us find which line of code is the
root cause for this problem. for example:
after running the line, the problem shows up:
1. if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb,
&found, NULL)) && found) // in the sound/pci/hda/thinkpad_helper.c,
is_thinkpad()
2. return ACPI_SUCCESS(acpi_get_devices("IBM0068", acpi_check_cb,
&found, NULL)) && found; // same as above
3. if (led_set_func(TPACPI_LED_MUTE, false) >= 0) { //in the
sound/pci/hda/thinkpad_helper.c, hda_fixup_thinkpad_acpi()
4. if (led_set_func(TPACPI_LED_MICMUTE, false) >= 0) { // same as above
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: add driver for Rockchip RK3xxx I2S controller
On 07/01/2014 02:09 PM, jianqun wrote:
From: Jianqun Xu
[...]
+
+static int rockchip_i2s_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params, struct snd_soc_dai *dai)
Proper indentation for function arguments, otherwise checkpatch.pl will give
warning.
+{
+ struct rk_i2s_dev *i2s = to_info(dai);
+ unsigned long flags;
+ u32 tx_ctl, rx_ctl;
+ u32 dmacr;
+
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ dai->playback_dma_data = &i2s->playback_dma_data;
+ else
+ dai->capture_dma_data = &i2s->capture_dma_data;
+
+ spin_lock_irqsave(&i2s->lock, flags);
+
+ tx_ctl = i2s_readl(i2s, I2S_TXCR);
+ tx_ctl &= ~I2S_TXCR_VDW_MASK;
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S8:
+ tx_ctl |= I2S_TXCR_VDW(8);
+ break;
+ case SNDRV_PCM_FORMAT_S16_LE:
+ tx_ctl |= I2S_TXCR_VDW(16);
+ break;
+ case SNDRV_PCM_FORMAT_S20_3LE:
+ tx_ctl |= I2S_TXCR_VDW(20);
+ break;
+ case SNDRV_PCM_FORMAT_S24_LE:
+ tx_ctl |= I2S_TXCR_VDW(24);
+ break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ tx_ctl |= I2S_TXCR_VDW(32);
+ break;
+ }
+
+ i2s_writel(i2s, tx_ctl, I2S_TXCR);
+
+ rx_ctl = i2s_readl(i2s, I2S_TXCR);
+ rx_ctl &= ~I2S_TXCR_VDW_MASK;
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S8:
+ rx_ctl |= I2S_TXCR_VDW(8);
+ break;
+ case SNDRV_PCM_FORMAT_S16_LE:
+ rx_ctl |= I2S_TXCR_VDW(16);
+ break;
+ case SNDRV_PCM_FORMAT_S20_3LE:
+ rx_ctl |= I2S_TXCR_VDW(20);
+ break;
+ case SNDRV_PCM_FORMAT_S24_LE:
+ rx_ctl |= I2S_TXCR_VDW(24);
+ break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ rx_ctl |= I2S_TXCR_VDW(32);
+ break;
+ }
+
+ i2s_writel(i2s, rx_ctl, I2S_RXCR);
+
+ dmacr = i2s_readl(i2s, I2S_DMACR);
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ dmacr = ((dmacr & ~I2S_DMACR_TDL_MASK) |
+ I2S_DMACR_TDL(1) |
+ I2S_DMACR_TDE_ENABLE);
+ else
+ dmacr = ((dmacr & ~I2S_DMACR_RDL_MASK) |
+ I2S_DMACR_RDL(1) |
+ I2S_DMACR_RDE_ENABLE);
+
+ i2s_writel(i2s, dmacr, I2S_DMACR);
+
+ spin_unlock_irqrestore(&i2s->lock, flags);
+
+ return 0;
+}
+
+static int rockchip_i2s_trigger(struct snd_pcm_substream *substream,
+ int cmd, struct snd_soc_dai *dai)
same..
+{
+ struct rk_i2s_dev *i2s = to_info(dai);
+ int ret = 0;
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ if (substream->stream == SNDRV_PCM_STREAM_CAPTURE)
+ rockchip_snd_rxctrl(i2s, 1);
+ else
+ rockchip_snd_txctrl(i2s, 1);
+ break;
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ if (substream->stream == SNDRV_PCM_STREAM_CAPTURE)
+ rockchip_snd_rxctrl(i2s, 0);
+ else
+ rockchip_snd_txctrl(i2s, 0);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
+static int rockchip_i2s_set_sysclk(struct snd_soc_dai *cpu_dai,
+ int clk_id, unsigned int freq, int dir)
same
+{
+ struct rk_i2s_dev *i2s = to_info(cpu_dai);
+
+ clk_set_rate(i2s->clk, freq);
+
+ return 0;
+}
+
+static int rockchip_i2s_set_clkdiv(struct snd_soc_dai *cpu_dai,
+ int div_id, int div)
same
+{
+ struct rk_i2s_dev *i2s = to_info(cpu_dai);
+ unsigned long flags;
+ u32 reg;
+ int ret;
+
+ spin_lock_irqsave(&i2s->lock, flags);
+
+ reg = i2s_readl(i2s, I2S_CKR);
+ switch (div_id) {
+ case ROCKCHIP_DIV_BCLK:
+ reg &= ~I2S_CKR_TSD_MASK;
+ reg |= I2S_CKR_TSD(div);
+ reg &= ~I2S_CKR_RSD_MASK;
+ reg |= I2S_CKR_RSD(div);
+ break;
+ case ROCKCHIP_DIV_MCLK:
+ reg &= ~I2S_CKR_MDIV_MASK;
+ reg |= I2S_CKR_MDIV(div);
+ break;
+ default:
+ ret = -EINVAL;
+ goto exit;
+ }
+
+ i2s_writel(i2s, reg, I2S_CKR);
+
+exit:
+ spin_unlock_irqrestore(&i2s->lock, flags);
+
+ return ret;
+}
+
+static struct snd_soc_dai_ops rockchip_i2s_dai_ops = {
+ .trigger = rockchip_i2s_trigger,
+ .hw_params = rockchip_i2s_hw_params,
+ .set_fmt = rockchip_i2s_set_fmt,
+ .set_cl
Re: [patch] x86, perf: avoid spamming kernel log for bts buffer failure
On Mon, Jun 30, 2014 at 04:04:08PM -0700, David Rientjes wrote: > It's unnecessary to excessively spam the kernel log anytime the BTS buffer > cannot be allocated, so make this allocation __GFP_NOWARN. > > The user probably will want to at least find some artifact that the > allocation has failed in the past, probably due to fragmentation because > of its large size, when it's not allocated at bootstrap. Thus, add a > WARN_ONCE() so something is left behind for them to understand why perf > commnads that require PEBS is not working properly. Can you elaborate a bit under which conditions this triggered? Typically we should be doing fairly well allocating such buffers with GFP_KERNEL, that should allow things like compaction to run and create higher order pages. And the BTS (branch trace store) isn't _that_ large. That said, the patch is reasonable; although arguably we should maybe do the same to alloc_pebs_buffer(). pgp4yIkxiRkaK.pgp Description: PGP signature
[PATCH v2 06/14] AT91: dt: Remove init_time definitions
The current AT91 DT boards have a completely generic init_time definition.
Remove them from the machine declaration.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-at91/board-dt-sam9.c | 11 ---
arch/arm/mach-at91/board-dt-sama5.c | 10 --
2 files changed, 21 deletions(-)
diff --git a/arch/arm/mach-at91/board-dt-sam9.c
b/arch/arm/mach-at91/board-dt-sam9.c
index a9fcdadfd929..3f80ceb3f444 100644
--- a/arch/arm/mach-at91/board-dt-sam9.c
+++ b/arch/arm/mach-at91/board-dt-sam9.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
@@ -26,15 +25,6 @@
#include "board.h"
#include "generic.h"
-
-static void __init sam9_dt_timer_init(void)
-{
-#if defined(CONFIG_COMMON_CLK)
- of_clk_init(NULL);
-#endif
- clocksource_of_init();
-}
-
static const struct of_device_id irq_of_match[] __initconst = {
{ .compatible = "atmel,at91rm9200-aic", .data = at91_aic_of_init },
@@ -53,7 +43,6 @@ static const char *at91_dt_board_compat[] __initdata = {
DT_MACHINE_START(at91sam_dt, "Atmel AT91SAM (Device Tree)")
/* Maintainer: Atmel */
- .init_time = sam9_dt_timer_init,
.map_io = at91_map_io,
.handle_irq = at91_aic_handle_irq,
.init_early = at91_dt_initialize,
diff --git a/arch/arm/mach-at91/board-dt-sama5.c
b/arch/arm/mach-at91/board-dt-sama5.c
index c07dd2395f36..030f4b65f449 100644
--- a/arch/arm/mach-at91/board-dt-sama5.c
+++ b/arch/arm/mach-at91/board-dt-sama5.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
@@ -28,14 +27,6 @@
#include "at91_aic.h"
#include "generic.h"
-static void __init sama5_dt_timer_init(void)
-{
-#if defined(CONFIG_COMMON_CLK)
- of_clk_init(NULL);
-#endif
- clocksource_of_init();
-}
-
static const struct of_device_id irq_of_match[] __initconst = {
{ .compatible = "atmel,sama5d3-aic", .data = at91_aic5_of_init },
@@ -81,7 +72,6 @@ static const char *sama5_dt_board_compat[] __initdata = {
DT_MACHINE_START(sama5_dt, "Atmel SAMA5 (Device Tree)")
/* Maintainer: Atmel */
- .init_time = sama5_dt_timer_init,
.map_io = at91_map_io,
.handle_irq = at91_aic5_handle_irq,
.init_early = at91_dt_initialize,
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 09/14] AT91: PIT: use request_irq instead of setup_irq
We can use the generic request_irq now to register a timer interrupt handler,
instead of the more complex setup_irq.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-at91/at91sam926x_time.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam926x_time.c
b/arch/arm/mach-at91/at91sam926x_time.c
index 0abdcb36c555..e476474cb05e 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -173,16 +173,10 @@ static irqreturn_t at91sam926x_pit_interrupt(int irq,
void *dev_id)
return IRQ_NONE;
}
-static struct irqaction at91sam926x_pit_irq = {
- .name = "at91_tick",
- .flags = IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
- .handler= at91sam926x_pit_interrupt,
-};
-
/*
* Set up both clocksource and clockevent support.
*/
-static void __init at91sam926x_pit_common_init(void)
+static void __init at91sam926x_pit_common_init(unsigned int pit_irq)
{
unsigned long pit_rate;
unsignedbits;
@@ -208,7 +202,9 @@ static void __init at91sam926x_pit_common_init(void)
clocksource_register_hz(&pit_clk, pit_rate);
/* Set up irq handler */
- ret = setup_irq(at91sam926x_pit_irq.irq, &at91sam926x_pit_irq);
+ ret = request_irq(pit_irq, at91sam926x_pit_interrupt,
+ IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
+ "at91_tick", pit_base_addr);
if (ret)
panic(pr_fmt("Unable to setup IRQ\n"));
@@ -239,9 +235,7 @@ static void __init at91sam926x_pit_dt_init(struct
device_node *node)
if (!irq)
panic(pr_fmt("Unable to get IRQ from DT\n"));
- at91sam926x_pit_irq.irq = irq;
-
- at91sam926x_pit_common_init();
+ at91sam926x_pit_common_init(irq);
}
CLOCKSOURCE_OF_DECLARE(at91sam926x_pit, "atmel,at91sam9260-pit",
at91sam926x_pit_dt_init);
@@ -252,9 +246,7 @@ void __init at91sam926x_pit_init(void)
if (IS_ERR(mck))
panic(pr_fmt("Unable to get mck clk\n"));
- at91sam926x_pit_irq.irq = NR_IRQS_LEGACY + AT91_ID_SYS;
-
- at91sam926x_pit_common_init();
+ at91sam926x_pit_common_init(NR_IRQS_LEGACY + AT91_ID_SYS);
}
void __init at91sam926x_ioremap_pit(u32 addr)
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/14] AT91: PIT: Use pr_fmt
All the panic messages hardcode the same prefix. Define the pr_fmt macro to
unify its definition.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-at91/at91sam926x_time.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam926x_time.c
b/arch/arm/mach-at91/at91sam926x_time.c
index 641e860e83e7..0abdcb36c555 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -10,6 +10,8 @@
* published by the Free Software Foundation.
*/
+#define pr_fmt(fmt)"AT91: PIT: " fmt
+
#include
#include
#include
@@ -208,7 +210,7 @@ static void __init at91sam926x_pit_common_init(void)
/* Set up irq handler */
ret = setup_irq(at91sam926x_pit_irq.irq, &at91sam926x_pit_irq);
if (ret)
- panic("AT91: PIT: Unable to setup IRQ\n");
+ panic(pr_fmt("Unable to setup IRQ\n"));
/* Set up and register clockevents */
pit_clkevt.mult = div_sc(pit_rate, NSEC_PER_SEC, pit_clkevt.shift);
@@ -222,7 +224,7 @@ static void __init at91sam926x_pit_dt_init(struct
device_node *node)
pit_base_addr = of_iomap(node, 0);
if (!pit_base_addr)
- panic("AT91: PIT: Could not map PIT address\n");
+ panic(pr_fmt("Could not map PIT address\n"));
mck = of_clk_get(node, 0);
if (IS_ERR(mck))
@@ -230,12 +232,12 @@ static void __init at91sam926x_pit_dt_init(struct
device_node *node)
mck = clk_get(NULL, "mck");
if (IS_ERR(mck))
- panic("AT91: PIT: Unable to get mck clk\n");
+ panic(pr_fmt("Unable to get mck clk\n"));
/* Get the interrupts property */
irq = irq_of_parse_and_map(node, 0);
if (!irq)
- panic("AT91: PIT: Unable to get IRQ from DT\n");
+ panic(pr_fmt("Unable to get IRQ from DT\n"));
at91sam926x_pit_irq.irq = irq;
@@ -248,7 +250,7 @@ void __init at91sam926x_pit_init(void)
{
mck = clk_get(NULL, "mck");
if (IS_ERR(mck))
- panic("AT91: PIT: Unable to get mck clk\n");
+ panic(pr_fmt("Unable to get mck clk\n"));
at91sam926x_pit_irq.irq = NR_IRQS_LEGACY + AT91_ID_SYS;
@@ -263,5 +265,5 @@ void __init at91sam926x_ioremap_pit(u32 addr)
pit_base_addr = ioremap(addr, 16);
if (!pit_base_addr)
- panic("Impossible to ioremap PIT\n");
+ panic(pr_fmt("Impossible to ioremap PIT\n"));
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 14/14] AT91: PIT: Move the driver to drivers/clocksource
Now that we don't depend on anyting in the mach-at91 directory, we can just move the driver to where it belongs. Signed-off-by: Maxime Ripard --- arch/arm/mach-at91/Kconfig | 6 -- arch/arm/mach-at91/Makefile | 1 - drivers/clocksource/Kconfig | 4 drivers/clocksource/Makefile| 1 + .../at91sam926x_time.c => drivers/clocksource/timer-atmel-pit.c | 0 5 files changed, 5 insertions(+), 7 deletions(-) rename arch/arm/mach-at91/at91sam926x_time.c => drivers/clocksource/timer-atmel-pit.c (100%) diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index a64412a020d3..1cd2a269ebbf 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -36,16 +36,11 @@ config AT91_SAM9G45_RESET bool default !ARCH_AT91X40 -config AT91_SAM9_TIME - select CLKSRC_OF if OF - bool - config HAVE_AT91_SMD bool config SOC_AT91SAM9 bool - select AT91_SAM9_TIME select CPU_ARM926T select GENERIC_CLOCKEVENTS select MULTI_IRQ_HANDLER @@ -53,7 +48,6 @@ config SOC_AT91SAM9 config SOC_SAMA5 bool - select AT91_SAM9_TIME select CPU_V7 select GENERIC_CLOCKEVENTS select MULTI_IRQ_HANDLER diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile index 78e9cec282f4..1a916ececbfd 100644 --- a/arch/arm/mach-at91/Makefile +++ b/arch/arm/mach-at91/Makefile @@ -10,7 +10,6 @@ obj- := obj-$(CONFIG_OLD_CLK_AT91) += clock.o obj-$(CONFIG_AT91_SAM9_ALT_RESET) += at91sam9_alt_reset.o obj-$(CONFIG_AT91_SAM9G45_RESET) += at91sam9g45_reset.o -obj-$(CONFIG_AT91_SAM9_TIME) += at91sam926x_time.o obj-$(CONFIG_SOC_AT91SAM9) += sam9_smc.o # CPU-specific support diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index 065131cbfcc0..3e6fbfe7af5b 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -118,6 +118,10 @@ config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK help Use ARM global timer clock source as sched_clock +config ATMEL_PIT + select CLKSRC_OF if OF + def_bool SOC_AT91SAM9 || SOC_SAMA5 + config CLKSRC_METAG_GENERIC def_bool y if METAG help diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile index 800b1303c236..98cf44e4b55a 100644 --- a/drivers/clocksource/Makefile +++ b/drivers/clocksource/Makefile @@ -1,4 +1,5 @@ obj-$(CONFIG_CLKSRC_OF)+= clksrc-of.o +obj-$(CONFIG_ATMEL_PIT)+= timer-atmel-pit.o obj-$(CONFIG_ATMEL_TCB_CLKSRC) += tcb_clksrc.o obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o obj-$(CONFIG_SCx200HR_TIMER) += scx200_hrt.o diff --git a/arch/arm/mach-at91/at91sam926x_time.c b/drivers/clocksource/timer-atmel-pit.c similarity index 100% rename from arch/arm/mach-at91/at91sam926x_time.c rename to drivers/clocksource/timer-atmel-pit.c -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/14] AT91: PIT: Use consistent exit path in probe
The current probe code is, whenever it fails to retrieve a resource, either
panicing, silently returning, or returning and displaying an error.
Make the code consistent by always panicing whenever it fails to grab any
resource.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-at91/at91sam926x_time.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam926x_time.c
b/arch/arm/mach-at91/at91sam926x_time.c
index f6c44539af6e..641e860e83e7 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -208,7 +208,7 @@ static void __init at91sam926x_pit_common_init(void)
/* Set up irq handler */
ret = setup_irq(at91sam926x_pit_irq.irq, &at91sam926x_pit_irq);
if (ret)
- pr_crit("AT91: PIT: Unable to setup IRQ\n");
+ panic("AT91: PIT: Unable to setup IRQ\n");
/* Set up and register clockevents */
pit_clkevt.mult = div_sc(pit_rate, NSEC_PER_SEC, pit_clkevt.shift);
@@ -222,7 +222,7 @@ static void __init at91sam926x_pit_dt_init(struct
device_node *node)
pit_base_addr = of_iomap(node, 0);
if (!pit_base_addr)
- return;
+ panic("AT91: PIT: Could not map PIT address\n");
mck = of_clk_get(node, 0);
if (IS_ERR(mck))
@@ -234,18 +234,12 @@ static void __init at91sam926x_pit_dt_init(struct
device_node *node)
/* Get the interrupts property */
irq = irq_of_parse_and_map(node, 0);
- if (!irq) {
- pr_crit("AT91: PIT: Unable to get IRQ from DT\n");
- goto clk_err;
- }
+ if (!irq)
+ panic("AT91: PIT: Unable to get IRQ from DT\n");
at91sam926x_pit_irq.irq = irq;
at91sam926x_pit_common_init();
-
-clk_err:
- clk_put(mck);
- iounmap(pit_base_addr);
}
CLOCKSOURCE_OF_DECLARE(at91sam926x_pit, "atmel,at91sam9260-pit",
at91sam926x_pit_dt_init);
@@ -256,7 +250,7 @@ void __init at91sam926x_pit_init(void)
if (IS_ERR(mck))
panic("AT91: PIT: Unable to get mck clk\n");
- at91sam926x_pit_irq.irq = NR_IRQS_LEGACY + AT91_ID_SYS,
+ at91sam926x_pit_irq.irq = NR_IRQS_LEGACY + AT91_ID_SYS;
at91sam926x_pit_common_init();
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 04/14] AT91: PIT: Use of_have_populated_dt instead of CONFIG_OF
Until now, the machines, even when CONFIG_OF was enabled, were calling
at91sam926x_ioremap_pit to try to map the PIT address using the defined
physical address.
Obviously, with DT, it's not appropriate anymore, and some code was added to
the function to deal with this case.
Unfortunately, this code was conditionned on CONFIG_OF, which can be enabled,
even though no DT was actually used, which would result in such a case, to this
code being executed, without any reason.
Moreover, the logic that was here before to bail out of the function just check
in the DT to see if the PIT node is there, which is the case in all our DTSI.
All this can be made much more straightforward just by using
of_have_populated_dt to bail out.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-at91/at91sam926x_time.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam926x_time.c
b/arch/arm/mach-at91/at91sam926x_time.c
index 2e6f1a37ab90..b87a12f05540 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -279,15 +279,9 @@ void __init at91sam926x_pit_init(void)
void __init at91sam926x_ioremap_pit(u32 addr)
{
-#if defined(CONFIG_OF)
- struct device_node *np =
- of_find_matching_node(NULL, pit_timer_ids);
-
- if (np) {
- of_node_put(np);
+ if (of_have_populated_dt())
return;
- }
-#endif
+
pit_base_addr = ioremap(addr, 16);
if (!pit_base_addr)
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/14] AT91: PIT: Cleanups and move to drivers/clocksource
Hi everyone, This series cleans up the PIT driver in order for it to not depend on anything in mach-at91 anymore, and in the end move it out of mach-at91. Along the way, these patches also do a bit of cleanup. This has been tested on a G45-EK without DT and an Xplained with DT. Thanks, Maxime Changes from v1: - Changed Kconfig option to ATMEL_PIT - Used DIV_ROUND_CLOSEST to compute the pit rate Maxime Ripard (14): AT91: PIT: Follow the general coding rules AT91: generic.h: Add include safe guards AT91: PIT: Use DIV_ROUND_CLOSEST to compute the cycles AT91: PIT: Use of_have_populated_dt instead of CONFIG_OF AT91: PIT: Rework probe functions AT91: dt: Remove init_time definitions AT91: PIT: Use consistent exit path in probe AT91: PIT: Use pr_fmt AT91: PIT: use request_irq instead of setup_irq AT91: PIT: (Almost) remove the global variables AT91: soc: Add init_time callback AT91: Convert the boards to the init_time callback AT91: PIT: Convert to an early_platform_device AT91: PIT: Move the driver to drivers/clocksource arch/arm/mach-at91/Kconfig | 5 - arch/arm/mach-at91/Makefile | 1 - arch/arm/mach-at91/at91sam9260.c| 34 +++- arch/arm/mach-at91/at91sam9261.c| 34 +++- arch/arm/mach-at91/at91sam9263.c| 34 +++- arch/arm/mach-at91/at91sam926x_time.c | 294 -- arch/arm/mach-at91/at91sam9g45.c| 35 +++- arch/arm/mach-at91/at91sam9rl.c | 34 +++- arch/arm/mach-at91/board-afeb-9260v1.c | 2 +- arch/arm/mach-at91/board-cam60.c| 2 +- arch/arm/mach-at91/board-cpu9krea.c | 2 +- arch/arm/mach-at91/board-dt-sam9.c | 10 -- arch/arm/mach-at91/board-dt-sama5.c | 9 - arch/arm/mach-at91/board-flexibity.c| 2 +- arch/arm/mach-at91/board-foxg20.c | 2 +- arch/arm/mach-at91/board-gsia18s.c | 2 +- arch/arm/mach-at91/board-pcontrol-g20.c | 2 +- arch/arm/mach-at91/board-sam9-l9260.c | 2 +- arch/arm/mach-at91/board-sam9260ek.c| 2 +- arch/arm/mach-at91/board-sam9261ek.c| 4 +- arch/arm/mach-at91/board-sam9263ek.c| 2 +- arch/arm/mach-at91/board-sam9g20ek.c| 4 +- arch/arm/mach-at91/board-sam9m10g45ek.c | 2 +- arch/arm/mach-at91/board-sam9rlek.c | 2 +- arch/arm/mach-at91/board-snapper9260.c | 2 +- arch/arm/mach-at91/board-stamp9g20.c| 4 +- arch/arm/mach-at91/generic.h| 8 +- arch/arm/mach-at91/setup.c | 5 + arch/arm/mach-at91/soc.h| 1 + drivers/clocksource/Kconfig | 4 + drivers/clocksource/Makefile| 1 + drivers/clocksource/timer-atmel-pit.c | 304 32 files changed, 506 insertions(+), 345 deletions(-) delete mode 100644 arch/arm/mach-at91/at91sam926x_time.c create mode 100644 drivers/clocksource/timer-atmel-pit.c -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 13/14] AT91: PIT: Convert to an early_platform_device
Convert the legacy probing mechanism to the early_platform_driver probe.
This will allow a clear separation between the driver and the machine setup
code, which will in turn ease the move out of mach-at91.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-at91/at91sam9260.c | 30 --
arch/arm/mach-at91/at91sam9261.c | 30 --
arch/arm/mach-at91/at91sam9263.c | 30 --
arch/arm/mach-at91/at91sam926x_time.c | 40 ---
arch/arm/mach-at91/at91sam9g45.c | 31 +--
arch/arm/mach-at91/at91sam9rl.c | 30 --
arch/arm/mach-at91/generic.h | 2 --
7 files changed, 164 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index d5141af1947c..a64ecaf905c0 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -341,7 +341,6 @@ static void __init at91sam9260_ioremap_registers(void)
at91_ioremap_shdwc(AT91SAM9260_BASE_SHDWC);
at91_ioremap_rstc(AT91SAM9260_BASE_RSTC);
at91_ioremap_ramc(0, AT91SAM9260_BASE_SDRAMC, 512);
- at91sam926x_ioremap_pit(AT91SAM9260_BASE_PIT);
at91sam9_ioremap_smc(0, AT91SAM9260_BASE_SMC);
at91_ioremap_matrix(AT91SAM9260_BASE_MATRIX);
at91_pm_set_standby(at91sam9_sdram_standby);
@@ -400,9 +399,36 @@ static unsigned int
at91sam9260_default_irq_priority[NR_AIC_IRQS] __initdata = {
0, /* Advanced Interrupt Controller */
};
+static struct resource pit_resources[] = {
+ [0] = {
+ .start = AT91SAM9260_BASE_PIT,
+ .end= AT91SAM9260_BASE_PIT + SZ_16 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = NR_IRQS_LEGACY + AT91_ID_SYS,
+ .end= NR_IRQS_LEGACY + AT91_ID_SYS,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device pit_device = {
+ .name = "at91_pit",
+ .resource = pit_resources,
+ .num_resources = ARRAY_SIZE(pit_resources),
+};
+
+static struct platform_device *at91sam9260_early_devices[] __initdata = {
+ &pit_device,
+};
+
static void __init at91sam9260_init_time(void)
{
- at91sam926x_pit_init();
+ early_platform_add_devices(at91sam9260_early_devices,
+ ARRAY_SIZE(at91sam9260_early_devices));
+
+ early_platform_driver_register_all("earlytimer");
+ early_platform_driver_probe("earlytimer", 1, 0);
}
AT91_SOC_START(at91sam9260)
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index 5416fe4d5a0b..c8f85ace7f33 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -304,7 +304,6 @@ static void __init at91sam9261_ioremap_registers(void)
at91_ioremap_shdwc(AT91SAM9261_BASE_SHDWC);
at91_ioremap_rstc(AT91SAM9261_BASE_RSTC);
at91_ioremap_ramc(0, AT91SAM9261_BASE_SDRAMC, 512);
- at91sam926x_ioremap_pit(AT91SAM9261_BASE_PIT);
at91sam9_ioremap_smc(0, AT91SAM9261_BASE_SMC);
at91_ioremap_matrix(AT91SAM9261_BASE_MATRIX);
at91_pm_set_standby(at91sam9_sdram_standby);
@@ -363,9 +362,36 @@ static unsigned int
at91sam9261_default_irq_priority[NR_AIC_IRQS] __initdata = {
0, /* Advanced Interrupt Controller */
};
+static struct resource pit_resources[] = {
+ [0] = {
+ .start = AT91SAM9261_BASE_PIT,
+ .end= AT91SAM9261_BASE_PIT + SZ_16 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = NR_IRQS_LEGACY + AT91_ID_SYS,
+ .end= NR_IRQS_LEGACY + AT91_ID_SYS,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device pit_device = {
+ .name = "at91_pit",
+ .resource = pit_resources,
+ .num_resources = ARRAY_SIZE(pit_resources),
+};
+
+static struct platform_device *at91sam9261_early_devices[] __initdata = {
+ &pit_device,
+};
+
static void __init at91sam9261_init_time(void)
{
- at91sam926x_pit_init();
+ early_platform_add_devices(at91sam9261_early_devices,
+ ARRAY_SIZE(at91sam9261_early_devices));
+
+ early_platform_driver_register_all("earlytimer");
+ early_platform_driver_probe("earlytimer", 1, 0);
}
AT91_SOC_START(at91sam9261)
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index 20b46118338c..b4bdfc20e0df 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -320,7 +320,6 @@ static void __init at91sam9263_ioremap_registers(void)
at91_ioremap_rstc(AT91SAM9263_BASE_RSTC);
at91_ioremap_ramc(0, AT91SAM9263_BASE_SDRAMC0, 512);
at91_ioremap_ramc(1, AT91SAM9263_BASE_SDRAMC1, 512);
- at91sam9
[PATCH v2 05/14] AT91: PIT: Rework probe functions
The PIT timer driver until now had a single probe function, disregarding wether
it was probed through DT or in the old-style way. This code later on was
calling some DT function to retrieve the proper values for its base address,
interrupts and clocks.
While this was working, it was preventing the usage of CLOCKSOURCE_OF_DECLARE,
and the two different probe path were not as clearly separated as they could
be.
Rework the probe path to take this into account, and switch to
CLOCKSOURCE_OF_DECLARE.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-at91/Kconfig| 1 +
arch/arm/mach-at91/at91sam926x_time.c | 108 +++---
arch/arm/mach-at91/board-dt-sam9.c| 3 +-
arch/arm/mach-at91/board-dt-sama5.c | 3 +-
4 files changed, 51 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 45b55e0f0db6..a64412a020d3 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -37,6 +37,7 @@ config AT91_SAM9G45_RESET
default !ARCH_AT91X40
config AT91_SAM9_TIME
+ select CLKSRC_OF if OF
bool
config HAVE_AT91_SMD
diff --git a/arch/arm/mach-at91/at91sam926x_time.c
b/arch/arm/mach-at91/at91sam926x_time.c
index b87a12f05540..f6c44539af6e 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -19,7 +19,6 @@
#include
#include
-#include
#include
#define AT91_PIT_MR0x00/* Mode Register */
@@ -176,81 +175,21 @@ static struct irqaction at91sam926x_pit_irq = {
.name = "at91_tick",
.flags = IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
.handler= at91sam926x_pit_interrupt,
- .irq= NR_IRQS_LEGACY + AT91_ID_SYS,
};
-#ifdef CONFIG_OF
-static struct of_device_id pit_timer_ids[] = {
- { .compatible = "atmel,at91sam9260-pit" },
- { /* sentinel */ }
-};
-
-static int __init of_at91sam926x_pit_init(void)
-{
- struct device_node *np;
- int ret;
-
- np = of_find_matching_node(NULL, pit_timer_ids);
- if (!np)
- goto err;
-
- pit_base_addr = of_iomap(np, 0);
- if (!pit_base_addr)
- goto node_err;
-
- mck = of_clk_get(np, 0);
-
- /* Get the interrupts property */
- ret = irq_of_parse_and_map(np, 0);
- if (!ret) {
- pr_crit("AT91: PIT: Unable to get IRQ from DT\n");
- if (!IS_ERR(mck))
- clk_put(mck);
- goto ioremap_err;
- }
- at91sam926x_pit_irq.irq = ret;
-
- of_node_put(np);
-
- return 0;
-
-ioremap_err:
- iounmap(pit_base_addr);
-node_err:
- of_node_put(np);
-err:
- return -EINVAL;
-}
-#else
-static int __init of_at91sam926x_pit_init(void)
-{
- return -EINVAL;
-}
-#endif
-
/*
* Set up both clocksource and clockevent support.
*/
-void __init at91sam926x_pit_init(void)
+static void __init at91sam926x_pit_common_init(void)
{
unsigned long pit_rate;
unsignedbits;
int ret;
- mck = ERR_PTR(-ENOENT);
-
- /* For device tree enabled device: initialize here */
- of_at91sam926x_pit_init();
-
/*
* Use our actual MCK to figure out how many MCK/16 ticks per
* 1/HZ period (instead of a compile-time constant LATCH).
*/
- if (IS_ERR(mck))
- mck = clk_get(NULL, "mck");
-
- if (IS_ERR(mck))
- panic("AT91: PIT: Unable to get mck clk\n");
pit_rate = clk_get_rate(mck) / 16;
pit_cycle = DIV_ROUND_CLOSEST(pit_rate, HZ);
WARN_ON(((pit_cycle - 1) & ~AT91_PIT_PIV) != 0);
@@ -277,6 +216,51 @@ void __init at91sam926x_pit_init(void)
clockevents_register_device(&pit_clkevt);
}
+static void __init at91sam926x_pit_dt_init(struct device_node *node)
+{
+ unsigned int irq;
+
+ pit_base_addr = of_iomap(node, 0);
+ if (!pit_base_addr)
+ return;
+
+ mck = of_clk_get(node, 0);
+ if (IS_ERR(mck))
+ /* Fallback on clkdev for !CCF-based boards */
+ mck = clk_get(NULL, "mck");
+
+ if (IS_ERR(mck))
+ panic("AT91: PIT: Unable to get mck clk\n");
+
+ /* Get the interrupts property */
+ irq = irq_of_parse_and_map(node, 0);
+ if (!irq) {
+ pr_crit("AT91: PIT: Unable to get IRQ from DT\n");
+ goto clk_err;
+ }
+
+ at91sam926x_pit_irq.irq = irq;
+
+ at91sam926x_pit_common_init();
+
+clk_err:
+ clk_put(mck);
+ iounmap(pit_base_addr);
+}
+CLOCKSOURCE_OF_DECLARE(at91sam926x_pit, "atmel,at91sam9260-pit",
+ at91sam926x_pit_dt_init);
+
+void __init at91sam926x_pit_init(void)
+{
+ mck = clk_get(NULL, "mck");
+ if (IS_ERR(mck))
+ panic("AT91: PIT: Unable to get mck clk\n");
+
+ at91
[PATCH v2 02/14] AT91: generic.h: Add include safe guards
The generic.h header file doesn't have any safe guards against multiple inclusion. It only worked so far because all the symbols defined in it were extern, but this is a rather fragile assumption. Signed-off-by: Maxime Ripard --- arch/arm/mach-at91/generic.h | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h index 631fa3b8c16d..77d4daeee66a 100644 --- a/arch/arm/mach-at91/generic.h +++ b/arch/arm/mach-at91/generic.h @@ -8,6 +8,9 @@ * published by the Free Software Foundation. */ +#ifndef _AT91_GENERIC_H +#define _AT91_GENERIC_H + #include #include #include @@ -90,3 +93,5 @@ extern int __init at91_gpio_of_irq_setup(struct device_node *node, struct device_node *parent); extern u32 at91_get_extern_irq(void); + +#endif /* _AT91_GENERIC_H */ -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/14] AT91: PIT: Use DIV_ROUND_CLOSEST to compute the cycles
Until now, the pit_cycle computation was dividing the rate by HZ, rounding to
the closest integer, but without using the appropriate macro.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-at91/at91sam926x_time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/at91sam926x_time.c
b/arch/arm/mach-at91/at91sam926x_time.c
index fd3170b65fbb..2e6f1a37ab90 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -252,7 +252,7 @@ void __init at91sam926x_pit_init(void)
if (IS_ERR(mck))
panic("AT91: PIT: Unable to get mck clk\n");
pit_rate = clk_get_rate(mck) / 16;
- pit_cycle = (pit_rate + HZ/2) / HZ;
+ pit_cycle = DIV_ROUND_CLOSEST(pit_rate, HZ);
WARN_ON(((pit_cycle - 1) & ~AT91_PIT_PIV) != 0);
/* Initialize and enable the timer */
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 01/14] AT91: PIT: Follow the general coding rules
Replace all masks and bits definitions by matching calls to BIT and GENMASK. While we're at it, also fix a few style issues. Signed-off-by: Maxime Ripard --- arch/arm/mach-at91/at91sam926x_time.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-at91/at91sam926x_time.c b/arch/arm/mach-at91/at91sam926x_time.c index 0a9e2fc8f796..fd3170b65fbb 100644 --- a/arch/arm/mach-at91/at91sam926x_time.c +++ b/arch/arm/mach-at91/at91sam926x_time.c @@ -9,11 +9,12 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ + +#include +#include #include #include #include -#include -#include #include #include #include @@ -22,17 +23,17 @@ #include #define AT91_PIT_MR0x00/* Mode Register */ -#defineAT91_PIT_PITIEN (1 << 25) /* Timer Interrupt Enable */ -#defineAT91_PIT_PITEN (1 << 24) /* Timer Enabled */ -#defineAT91_PIT_PIV(0xf) /* Periodic Interval Value */ +#define AT91_PIT_PITIENBIT(25) /* Timer Interrupt Enable */ +#define AT91_PIT_PITEN BIT(24) /* Timer Enabled */ +#define AT91_PIT_PIV GENMASK(19, 0) /* Periodic Interval Value */ #define AT91_PIT_SR0x04/* Status Register */ -#defineAT91_PIT_PITS (1 << 0)/* Timer Status */ +#define AT91_PIT_PITS BIT(0) /* Timer Status */ #define AT91_PIT_PIVR 0x08/* Periodic Interval Value Register */ #define AT91_PIT_PIIR 0x0c/* Periodic Interval Image Register */ -#defineAT91_PIT_PICNT (0xfff << 20) /* Interval Counter */ -#defineAT91_PIT_CPIV (0xf) /* Inverval Value */ +#define AT91_PIT_PICNT GENMASK(31, 20) /* Interval Counter */ +#define AT91_PIT_CPIV GENMASK(19, 0) /* Inverval Value */ #define PIT_CPIV(x)((x) & AT91_PIT_CPIV) #define PIT_PICNT(x) (((x) & AT91_PIT_PICNT) >> 20) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend v2 1/3] mfd-core: Don't register supplies from add_device, add register_supply_aliases()
Hi, On 07/01/2014 11:22 AM, Lee Jones wrote: > On Mon, 30 Jun 2014, Hans de Goede wrote: > >> We cannot register supply alias in mfd_add_device before calling >> platform_add_device because platform-dev's name must be set before >> registering >> the aliases which happens from platform_add_device. >> >> So stop registering supply aliases from mfd_add_device, and add a >> mfd_register_supply_aliases helper functions for the cell's plaform driver >> probe method to use. >> >> Signed-off-by: Hans de Goede > > Didn't I already Ack this? Ah yes you did, but back then I expected the series to get picked up immediately, so I did not add the ack to my local copy of it. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 10/14] AT91: PIT: (Almost) remove the global variables
The timer driver is using some global variables to define some variables it has
to use in most of its functions, like the base address.
Use some container_of calls to have a single dynamic (and local) variable to
hold this content.
The only exception is in the !DT case, where the call chain to
at91sam926x_ioremap_pit and then at91sam926x_pit_init as init_time makes it
hard for the moment to pass the physical address of the timer.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-at91/at91sam926x_time.c | 179 --
1 file changed, 108 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam926x_time.c
b/arch/arm/mach-at91/at91sam926x_time.c
index e476474cb05e..9abb289dce72 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
@@ -39,19 +40,35 @@
#define PIT_CPIV(x)((x) & AT91_PIT_CPIV)
#define PIT_PICNT(x) (((x) & AT91_PIT_PICNT) >> 20)
-static u32 pit_cycle; /* write-once */
-static u32 pit_cnt;/* access only w/system irq blocked */
-static void __iomem *pit_base_addr __read_mostly;
-static struct clk *mck;
+struct pit_data {
+ struct clock_event_device clkevt;
+ struct clocksource clksrc;
-static inline unsigned int pit_read(unsigned int reg_offset)
+ void __iomem*base;
+ u32 cycle;
+ u32 cnt;
+ unsigned intirq;
+ struct clk *mck;
+};
+
+static inline struct pit_data *clksrc_to_pit_data(struct clocksource *clksrc)
{
- return __raw_readl(pit_base_addr + reg_offset);
+ return container_of(clksrc, struct pit_data, clksrc);
}
-static inline void pit_write(unsigned int reg_offset, unsigned long value)
+static inline struct pit_data *clkevt_to_pit_data(struct clock_event_device
*clkevt)
{
- __raw_writel(value, pit_base_addr + reg_offset);
+ return container_of(clkevt, struct pit_data, clkevt);
+}
+
+static inline unsigned int pit_read(void __iomem *base, unsigned int
reg_offset)
+{
+ return __raw_readl(base + reg_offset);
+}
+
+static inline void pit_write(void __iomem *base, unsigned int reg_offset,
unsigned long value)
+{
+ __raw_writel(value, base + reg_offset);
}
/*
@@ -60,40 +77,35 @@ static inline void pit_write(unsigned int reg_offset,
unsigned long value)
*/
static cycle_t read_pit_clk(struct clocksource *cs)
{
+ struct pit_data *data = clksrc_to_pit_data(cs);
unsigned long flags;
u32 elapsed;
u32 t;
raw_local_irq_save(flags);
- elapsed = pit_cnt;
- t = pit_read(AT91_PIT_PIIR);
+ elapsed = data->cnt;
+ t = pit_read(data->base, AT91_PIT_PIIR);
raw_local_irq_restore(flags);
- elapsed += PIT_PICNT(t) * pit_cycle;
+ elapsed += PIT_PICNT(t) * data->cycle;
elapsed += PIT_CPIV(t);
return elapsed;
}
-static struct clocksource pit_clk = {
- .name = "pit",
- .rating = 175,
- .read = read_pit_clk,
- .flags = CLOCK_SOURCE_IS_CONTINUOUS,
-};
-
-
/*
* Clockevent device: interrupts every 1/HZ (== pit_cycles * MCK/16)
*/
static void
pit_clkevt_mode(enum clock_event_mode mode, struct clock_event_device *dev)
{
+ struct pit_data *data = clkevt_to_pit_data(dev);
+
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
/* update clocksource counter */
- pit_cnt += pit_cycle * PIT_PICNT(pit_read(AT91_PIT_PIVR));
- pit_write(AT91_PIT_MR, (pit_cycle - 1) | AT91_PIT_PITEN
- | AT91_PIT_PITIEN);
+ data->cnt += data->cycle * PIT_PICNT(pit_read(data->base,
AT91_PIT_PIVR));
+ pit_write(data->base, AT91_PIT_MR,
+ (data->cycle - 1) | AT91_PIT_PITEN | AT91_PIT_PITIEN);
break;
case CLOCK_EVT_MODE_ONESHOT:
BUG();
@@ -101,7 +113,8 @@ pit_clkevt_mode(enum clock_event_mode mode, struct
clock_event_device *dev)
case CLOCK_EVT_MODE_SHUTDOWN:
case CLOCK_EVT_MODE_UNUSED:
/* disable irq, leaving the clocksource active */
- pit_write(AT91_PIT_MR, (pit_cycle - 1) | AT91_PIT_PITEN);
+ pit_write(data->base, AT91_PIT_MR,
+ (data->cycle - 1) | AT91_PIT_PITEN);
break;
case CLOCK_EVT_MODE_RESUME:
break;
@@ -110,44 +123,40 @@ pit_clkevt_mode(enum clock_event_mode mode, struct
clock_event_device *dev)
static void at91sam926x_pit_suspend(struct clock_event_device *cedev)
{
+ struct pit_data *data = clkevt_to_pit_data(cedev);
+
/* Disable timer */
- pit_write(AT91_PIT_MR, 0);
+ pit_write(data->base, AT91_PIT_MR, 0);
}
-static void at91sam926x_pit_reset(void)
+static void at91sam926x_pit_reset(struct pit_data
