[PATCH] regulator: pf8x00: set ramp_delay for bucks
This patch sets ramp_delay for bucks to the max value given by the
datasheet.
Signed-off-by: Christoph Fritz
---
drivers/regulator/pf8x00-regulator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/pf8x00-regulator.c
b/drivers/regulator/pf8x00-regulator.c
index 1e5582d73405..edf5c88bf43e 100644
--- a/drivers/regulator/pf8x00-regulator.c
+++ b/drivers/regulator/pf8x00-regulator.c
@@ -351,6 +351,7 @@ static const struct regulator_ops pf8x00_vsnvs_ops = {
.type = REGULATOR_VOLTAGE, \
.id = PF8X00_BUCK ## _id, \
.owner = THIS_MODULE, \
+ .ramp_delay = 19000,\
.linear_ranges = pf8x00_sw1_to_6_voltages, \
.n_linear_ranges = \
ARRAY_SIZE(pf8x00_sw1_to_6_voltages), \
@@ -381,6 +382,7 @@ static const struct regulator_ops pf8x00_vsnvs_ops = {
.type = REGULATOR_VOLTAGE, \
.id = PF8X00_BUCK7, \
.owner = THIS_MODULE, \
+ .ramp_delay = 19000,\
.volt_table = voltages, \
.vsel_reg = (base) + SW_RUN_VOLT, \
.vsel_mask = 0xff, \
--
2.29.2
[PATCH] regulator: pf8x00: set ramp_delay for bucks
This patch sets ramp_delay for bucks to the max value given by the
datasheet.
Signed-off-by: Christoph Fritz
Reviewed-by: Adrien Grassein
---
drivers/regulator/pf8x00-regulator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/pf8x00-regulator.c
b/drivers/regulator/pf8x00-regulator.c
index 1e5582d73405..edf5c88bf43e 100644
--- a/drivers/regulator/pf8x00-regulator.c
+++ b/drivers/regulator/pf8x00-regulator.c
@@ -351,6 +351,7 @@ static const struct regulator_ops pf8x00_vsnvs_ops = {
.type = REGULATOR_VOLTAGE, \
.id = PF8X00_BUCK ## _id, \
.owner = THIS_MODULE, \
+ .ramp_delay = 19000,\
.linear_ranges = pf8x00_sw1_to_6_voltages, \
.n_linear_ranges = \
ARRAY_SIZE(pf8x00_sw1_to_6_voltages), \
@@ -381,6 +382,7 @@ static const struct regulator_ops pf8x00_vsnvs_ops = {
.type = REGULATOR_VOLTAGE, \
.id = PF8X00_BUCK7, \
.owner = THIS_MODULE, \
+ .ramp_delay = 19000,\
.volt_table = voltages, \
.vsel_reg = (base) + SW_RUN_VOLT, \
.vsel_mask = 0xff, \
--
2.29.2
Re: [PATCH] regulator: pf8x00: Add suspend support
Hello Jagan,
as your new role as Maintainer of this driver, is there a chance to get
your Feedback/Ack/Review/Signed anytime soon?
Thanks
-- Christoph
On Sun, 2021-01-17 at 21:49 +0100, Christoph Fritz wrote:
> This patch adds suspend/resume support so that it is possible to
> configure the LDOs and BUCKs as on or off during suspend phase as
> well as to configure suspend specific voltages.
>
> Signed-off-by: Christoph Fritz
> ---
> drivers/regulator/pf8x00-regulator.c | 75 ++--
> 1 file changed, 70 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/regulator/pf8x00-regulator.c
> b/drivers/regulator/pf8x00-regulator.c
> index 1e5582d73405..02892e04acce 100644
> --- a/drivers/regulator/pf8x00-regulator.c
> +++ b/drivers/regulator/pf8x00-regulator.c
> @@ -125,8 +125,12 @@ enum pf8x00_devid {
> #define PF8X00_DEVICE_FAM_MASK GENMASK(7, 4)
> #define PF8X00_DEVICE_ID_MASKGENMASK(3, 0)
>
> -struct pf8x00_regulator {
> +struct pf8x00_regulator_data {
> struct regulator_desc desc;
> + unsigned int suspend_enable_reg;
> + unsigned int suspend_enable_mask;
> + unsigned int suspend_voltage_reg;
> + unsigned int suspend_voltage_cache;
> };
>
> struct pf8x00_chip {
> @@ -276,6 +280,53 @@ static int pf8x00_of_parse_cb(struct device_node *np,
> return 0;
> }
>
> +static int pf8x00_suspend_enable(struct regulator_dev *rdev)
> +{
> + struct pf8x00_regulator_data *regl = rdev_get_drvdata(rdev);
> + struct regmap *rmap = rdev_get_regmap(rdev);
> +
> + return regmap_update_bits(rmap, regl->suspend_enable_reg,
> + regl->suspend_enable_mask,
> + regl->suspend_enable_mask);
> +}
> +
> +static int pf8x00_suspend_disable(struct regulator_dev *rdev)
> +{
> + struct pf8x00_regulator_data *regl = rdev_get_drvdata(rdev);
> + struct regmap *rmap = rdev_get_regmap(rdev);
> +
> + return regmap_update_bits(rmap, regl->suspend_enable_reg,
> + regl->suspend_enable_mask, 0);
> +}
> +
> +static int pf8x00_set_suspend_voltage(struct regulator_dev *rdev, int uV)
> +{
> + struct pf8x00_regulator_data *regl = rdev_get_drvdata(rdev);
> + int ret;
> +
> + if (regl->suspend_voltage_cache == uV)
> + return 0;
> +
> + ret = regulator_map_voltage_iterate(rdev, uV, uV);
> + if (ret < 0) {
> + dev_err(rdev_get_dev(rdev), "failed to map %i uV\n", uV);
> + return ret;
> + }
> +
> + dev_dbg(rdev_get_dev(rdev), "uV: %i, reg: 0x%x, msk: 0x%x, val: 0x%x\n",
> + uV, regl->suspend_voltage_reg, regl->desc.vsel_mask, ret);
> + ret = regmap_update_bits(rdev->regmap, regl->suspend_voltage_reg,
> + regl->desc.vsel_mask, ret);
> + if (ret < 0) {
> + dev_err(rdev_get_dev(rdev), "failed to set %i uV\n", uV);
> + return ret;
> + }
> +
> + regl->suspend_voltage_cache = uV;
> +
> + return 0;
> +}
> +
> static const struct regulator_ops pf8x00_ldo_ops = {
> .enable = regulator_enable_regmap,
> .disable = regulator_disable_regmap,
> @@ -283,6 +334,9 @@ static const struct regulator_ops pf8x00_ldo_ops = {
> .list_voltage = regulator_list_voltage_table,
> .set_voltage_sel = regulator_set_voltage_sel_regmap,
> .get_voltage_sel = regulator_get_voltage_sel_regmap,
> + .set_suspend_enable = pf8x00_suspend_enable,
> + .set_suspend_disable = pf8x00_suspend_disable,
> + .set_suspend_voltage = pf8x00_set_suspend_voltage,
> };
>
>
> @@ -295,6 +349,9 @@ static const struct regulator_ops pf8x00_buck1_6_ops = {
> .get_voltage_sel = regulator_get_voltage_sel_regmap,
> .get_current_limit = regulator_get_current_limit_regmap,
> .set_current_limit = regulator_set_current_limit_regmap,
> + .set_suspend_enable = pf8x00_suspend_enable,
> + .set_suspend_disable = pf8x00_suspend_disable,
> + .set_suspend_voltage = pf8x00_set_suspend_voltage,
> };
>
> static const struct regulator_ops pf8x00_buck7_ops = {
> @@ -306,6 +363,8 @@ static const struct regulator_ops pf8x00_buck7_ops = {
> .get_voltage_sel = regulator_get_voltage_sel_regmap,
> .get_current_limit = regulator_get_current_limit_regmap,
> .set_current_limit = regulator_set_current_limit_regmap,
> + .set_suspend_enable = pf8x00_suspend_enable,
> + .set_suspend_disable = pf8x00_suspend_disable,
> };
>
> static const struct regulator_o
[PATCH] regulator: pf8x00: Add suspend support
This patch adds suspend/resume support so that it is possible to
configure the LDOs and BUCKs as on or off during suspend phase as
well as to configure suspend specific voltages.
Signed-off-by: Christoph Fritz
---
drivers/regulator/pf8x00-regulator.c | 75 ++--
1 file changed, 70 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/pf8x00-regulator.c
b/drivers/regulator/pf8x00-regulator.c
index 1e5582d73405..02892e04acce 100644
--- a/drivers/regulator/pf8x00-regulator.c
+++ b/drivers/regulator/pf8x00-regulator.c
@@ -125,8 +125,12 @@ enum pf8x00_devid {
#define PF8X00_DEVICE_FAM_MASK GENMASK(7, 4)
#define PF8X00_DEVICE_ID_MASK GENMASK(3, 0)
-struct pf8x00_regulator {
+struct pf8x00_regulator_data {
struct regulator_desc desc;
+ unsigned int suspend_enable_reg;
+ unsigned int suspend_enable_mask;
+ unsigned int suspend_voltage_reg;
+ unsigned int suspend_voltage_cache;
};
struct pf8x00_chip {
@@ -276,6 +280,53 @@ static int pf8x00_of_parse_cb(struct device_node *np,
return 0;
}
+static int pf8x00_suspend_enable(struct regulator_dev *rdev)
+{
+ struct pf8x00_regulator_data *regl = rdev_get_drvdata(rdev);
+ struct regmap *rmap = rdev_get_regmap(rdev);
+
+ return regmap_update_bits(rmap, regl->suspend_enable_reg,
+ regl->suspend_enable_mask,
+ regl->suspend_enable_mask);
+}
+
+static int pf8x00_suspend_disable(struct regulator_dev *rdev)
+{
+ struct pf8x00_regulator_data *regl = rdev_get_drvdata(rdev);
+ struct regmap *rmap = rdev_get_regmap(rdev);
+
+ return regmap_update_bits(rmap, regl->suspend_enable_reg,
+ regl->suspend_enable_mask, 0);
+}
+
+static int pf8x00_set_suspend_voltage(struct regulator_dev *rdev, int uV)
+{
+ struct pf8x00_regulator_data *regl = rdev_get_drvdata(rdev);
+ int ret;
+
+ if (regl->suspend_voltage_cache == uV)
+ return 0;
+
+ ret = regulator_map_voltage_iterate(rdev, uV, uV);
+ if (ret < 0) {
+ dev_err(rdev_get_dev(rdev), "failed to map %i uV\n", uV);
+ return ret;
+ }
+
+ dev_dbg(rdev_get_dev(rdev), "uV: %i, reg: 0x%x, msk: 0x%x, val: 0x%x\n",
+ uV, regl->suspend_voltage_reg, regl->desc.vsel_mask, ret);
+ ret = regmap_update_bits(rdev->regmap, regl->suspend_voltage_reg,
+regl->desc.vsel_mask, ret);
+ if (ret < 0) {
+ dev_err(rdev_get_dev(rdev), "failed to set %i uV\n", uV);
+ return ret;
+ }
+
+ regl->suspend_voltage_cache = uV;
+
+ return 0;
+}
+
static const struct regulator_ops pf8x00_ldo_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
@@ -283,6 +334,9 @@ static const struct regulator_ops pf8x00_ldo_ops = {
.list_voltage = regulator_list_voltage_table,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_suspend_enable = pf8x00_suspend_enable,
+ .set_suspend_disable = pf8x00_suspend_disable,
+ .set_suspend_voltage = pf8x00_set_suspend_voltage,
};
@@ -295,6 +349,9 @@ static const struct regulator_ops pf8x00_buck1_6_ops = {
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.get_current_limit = regulator_get_current_limit_regmap,
.set_current_limit = regulator_set_current_limit_regmap,
+ .set_suspend_enable = pf8x00_suspend_enable,
+ .set_suspend_disable = pf8x00_suspend_disable,
+ .set_suspend_voltage = pf8x00_set_suspend_voltage,
};
static const struct regulator_ops pf8x00_buck7_ops = {
@@ -306,6 +363,8 @@ static const struct regulator_ops pf8x00_buck7_ops = {
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.get_current_limit = regulator_get_current_limit_regmap,
.set_current_limit = regulator_set_current_limit_regmap,
+ .set_suspend_enable = pf8x00_suspend_enable,
+ .set_suspend_disable = pf8x00_suspend_disable,
};
static const struct regulator_ops pf8x00_vsnvs_ops = {
@@ -337,6 +396,9 @@ static const struct regulator_ops pf8x00_vsnvs_ops = {
.disable_val = 0x0, \
.enable_mask = 2, \
}, \
+ .suspend_enable_reg = (base) + LDO_CONFIG2, \
+ .suspend_enable_mask = 1, \
+ .suspend_voltage_reg = (base) + LDO_STBY_VOLT, \
}
#define PF8X00BUCK(_id, _name, base, voltages) \
@@ -367,6 +429,9 @@ static const struct regulator_ops pf8x00_vsnvs_ops = {
.enable_mask
[PATCH] regulator: fan53880: Add support for COMPILE_TEST
This patch adds support for COMPILE_TEST while fixing a warning when
no support for device tree is there.
Reported-by: kernel test robot
Signed-off-by: Christoph Fritz
---
drivers/regulator/Kconfig| 2 +-
drivers/regulator/fan53880.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index d47055db999d..1cc3c93a9621 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -338,7 +338,7 @@ config REGULATOR_FAN53555
config REGULATOR_FAN53880
tristate "Fairchild FAN53880 Regulator"
- depends on I2C
+ depends on I2C && (OF || COMPILE_TEST)
select REGMAP_I2C
help
This driver supports Fairchild (ON Semiconductor) FAN53880
diff --git a/drivers/regulator/fan53880.c b/drivers/regulator/fan53880.c
index 285acc705a55..c45baf581299 100644
--- a/drivers/regulator/fan53880.c
+++ b/drivers/regulator/fan53880.c
@@ -152,11 +152,13 @@ static int fan53880_i2c_probe(struct i2c_client *i2c,
return 0;
}
+#ifdef CONFIG_OF
static const struct of_device_id fan53880_dt_ids[] = {
{ .compatible = "onnn,fan53880", },
{}
};
MODULE_DEVICE_TABLE(of, fan53880_dt_ids);
+#endif
static const struct i2c_device_id fan53880_i2c_id[] = {
{ "fan53880", },
--
2.20.1
[PATCH] regulator: fan53880: fix Kconfig dependency
Currently the fan53880 regulator driver needs a device tree to get probed, this patch provides the necessary dependency. Reported-by: kernel test robot Signed-off-by: Christoph Fritz --- drivers/regulator/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index d47055db999d..76ef4b2de2e7 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -338,7 +338,7 @@ config REGULATOR_FAN53555 config REGULATOR_FAN53880 tristate "Fairchild FAN53880 Regulator" - depends on I2C + depends on I2C && OF select REGMAP_I2C help This driver supports Fairchild (ON Semiconductor) FAN53880 -- 2.20.1
[PATCH v2 2/2] dt-bindings: regulator: Document bindings for fan53880
Add device tree binding information for fan53880 regulator driver.
Signed-off-by: Christoph Fritz
---
.../bindings/regulator/onnn,fan53880.yaml | 85 +++
1 file changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
diff --git a/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
b/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
new file mode 100644
index ..eb61e04ef852
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/onnn,fan53880.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Onsemi FAN53880 PMIC
+
+maintainers:
+ - Christoph Fritz
+
+description: |
+ The FAN53880 is an I2C porgrammable power management IC (PMIC)
+ that contains a BUCK (step-down converter), four low dropouts (LDO)
+ and one BOOST (step-up converter) output. It is designed for mobile
+ power applications.
+
+properties:
+ $nodename:
+pattern: "pmic@[0-9a-f]{1,2}"
+ compatible:
+enum:
+ - onnn,fan53880
+
+ reg:
+maxItems: 1
+
+ VIN12-supply:
+description: Input supply phandle(s) for LDO1 and LDO2
+
+ VIN3-supply:
+description: Input supply phandle(s) for LDO3
+
+ VIN4-supply:
+description: Input supply phandle(s) for LDO4
+
+ PVIN-supply:
+description: Input supply phandle(s) for BUCK and BOOST
+
+ regulators:
+type: object
+$ref: regulator.yaml#
+description: |
+ list of regulators provided by this controller, must be named
+ after their hardware counterparts LDO[1-4], BUCK and BOOST
+
+patternProperties:
+ "^LDO[1-4]$":
+type: object
+$ref: regulator.yaml#
+
+ "^BUCK|BOOST$":
+type: object
+$ref: regulator.yaml#
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+pmic@35 {
+compatible = "onnn,fan53880";
+reg = <0x35>;
+
+PVIN-supply = <_example_vcc>;
+
+regulators {
+BUCK {
+regulator-min-microvolt = <120>;
+regulator-max-microvolt = <120>;
+};
+};
+ };
+ };
+...
--
2.20.1
[PATCH v2 0/2] regulator: Add FAN53880 support
This patchset adds a regulator driver with dt-bindings documentation in the new yaml format for a power management IC from Fairchild (now ON Semiconductor) named FAN53880. The chip was found on a camera sensor board which will get a v4lsubdev driver in the future. The FAN53880 differs a lot compared to the older FAN53555 which already has driver support. Changelog v1 -> v2: - rebase to current linux-next and adapt by s/struct regulator_linear_range/struct linear_range Christoph Fritz (2): regulator: fan53880: Add initial support dt-bindings: regulator: Document bindings for fan53880 .../bindings/regulator/onnn,fan53880.yaml | 85 + drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/fan53880.c | 179 ++ 4 files changed, 275 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml create mode 100644 drivers/regulator/fan53880.c -- 2.20.1
[PATCH v2 1/2] regulator: fan53880: Add initial support
This patch adds support for ON Semiconductor FAN53880 regulator.
The FAN53880 is an I2C porgrammable power management IC (PMIC)
that contains a BUCK (step-down converter), four LDOs (low dropouts)
and one BOOST (step-up converter). It is designed for mobile power
applications.
Signed-off-by: Christoph Fritz
---
drivers/regulator/Kconfig| 10 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/fan53880.c | 179 +++
3 files changed, 190 insertions(+)
create mode 100644 drivers/regulator/fan53880.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index f60eeaae7afd..421ca13e1541 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -336,6 +336,16 @@ config REGULATOR_FAN53555
input voltage supply of 2.5V to 5.5V. The output voltage is
programmed through an I2C interface.
+config REGULATOR_FAN53880
+ tristate "Fairchild FAN53880 Regulator"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ This driver supports Fairchild (ON Semiconductor) FAN53880
+ regulator. The regulator is a programmable power management IC
+ (PMIC), it is controlled by I2C and provides one BUCK, one BOOST
+ and four LDO outputs.
+
config REGULATOR_GPIO
tristate "GPIO regulator support"
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 5ce7350398f8..9c2782ce44a2 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_REGULATOR_DA9211) += da9211-regulator.o
obj-$(CONFIG_REGULATOR_DBX500_PRCMU) += dbx500-prcmu.o
obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_FAN53555) += fan53555.o
+obj-$(CONFIG_REGULATOR_FAN53880) += fan53880.o
obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
obj-$(CONFIG_REGULATOR_HI6421V530) += hi6421v530-regulator.o
diff --git a/drivers/regulator/fan53880.c b/drivers/regulator/fan53880.c
new file mode 100644
index ..285acc705a55
--- /dev/null
+++ b/drivers/regulator/fan53880.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include
+#include
+#include
+#include
+
+enum fan53880_regulator_ids {
+ FAN53880_LDO1,
+ FAN53880_LDO2,
+ FAN53880_LDO3,
+ FAN53880_LDO4,
+ FAN53880_BUCK,
+ FAN53880_BOOST,
+};
+
+enum fan53880_registers {
+ FAN53880_PRODUCT_ID = 0x00,
+ FAN53880_SILICON_REV,
+ FAN53880_BUCKVOUT,
+ FAN53880_BOOSTVOUT,
+ FAN53880_LDO1VOUT,
+ FAN53880_LDO2VOUT,
+ FAN53880_LDO3VOUT,
+ FAN53880_LDO4VOUT,
+ FAN53880_IOUT,
+ FAN53880_ENABLE,
+ FAN53880_ENABLE_BOOST,
+};
+
+#define FAN53880_ID0x01
+
+static const struct regulator_ops fan53880_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+};
+
+#define FAN53880_LDO(_num, _supply, _default) \
+ [FAN53880_LDO ## _num] = { \
+ .name ="LDO"#_num, \
+ .of_match =of_match_ptr("LDO"#_num),\
+ .regulators_node = of_match_ptr("regulators"), \
+ .type =REGULATOR_VOLTAGE, \
+ .linear_ranges = (struct linear_range[]) {\
+ REGULATOR_LINEAR_RANGE(_default, 0x0, 0x0, 0),\
+ REGULATOR_LINEAR_RANGE(80, 0xf, 0x73, 25000), \
+ }, \
+ .n_linear_ranges = 2, \
+ .vsel_reg =FAN53880_LDO ## _num ## VOUT,\
+ .vsel_mask = 0x7f,\
+ .enable_reg = FAN53880_ENABLE, \
+ .enable_mask = BIT(_num - 1), \
+ .enable_time = 150, \
+ .supply_name = _supply, \
+ .ops = _ops, \
+ }
+
+static const struct regulator_desc fan53880_regulators[] = {
+ FAN53880_LDO(1, "VIN12", 280),
+ FAN53880_LDO(2, "VIN12", 280),
+ FAN53880_LDO(3, "VIN3", 180),
+ FAN53880_LDO(4, "VIN4", 180),
+ [FAN53880_BUCK] = {
+ .name ="B
Re: [PATCH 1/2] regulator: fan53880: Add initial support
On Wed, 2020-07-01 at 19:09 +0100, Mark Brown wrote: > /mnt/kernel/drivers/regulator/fan53880.c:63:2: note: in expansion of > macro 'FAN53880_LDO' > FAN53880_LDO(1, "VIN12", 280), > ^~~~ > /mnt/kernel/include/linux/regulator/driver.h:47:2: error: field name > not in record or union initializer > .min_sel = _min_sel, \ > ^ > > most likely due to the conversion introduced in 60ab7f4153b6af46 > (regulator: use linear_ranges helper). Please rebase against current > code. Thanks for the hint, yeah that's it. After picking up a recent linux- next and adapting it works on current too. Please let me respin the patches in a v2.
[PATCH 1/2] regulator: fan53880: Add initial support
This patch adds support for ON Semiconductor FAN53880 regulator.
The FAN53880 is an I2C porgrammable power management IC (PMIC)
that contains a BUCK (step-down converter), four LDOs (low dropouts)
and one BOOST (step-up converter). It is designed for mobile power
applications.
Signed-off-by: Christoph Fritz
---
drivers/regulator/Kconfig| 10 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/fan53880.c | 179 +++
3 files changed, 190 insertions(+)
create mode 100644 drivers/regulator/fan53880.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index edb1c4f8b496..69fcfdc50ada 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -326,6 +326,16 @@ config REGULATOR_FAN53555
input voltage supply of 2.5V to 5.5V. The output voltage is
programmed through an I2C interface.
+config REGULATOR_FAN53880
+ tristate "Fairchild FAN53880 Regulator"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ This driver supports Fairchild (ON Semiconductor) FAN53880
+ regulator. The regulator is a programmable power management IC
+ (PMIC), it is controlled by I2C and provides one BUCK, one BOOST
+ and four LDO outputs.
+
config REGULATOR_GPIO
tristate "GPIO regulator support"
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index e8f163371071..7b7d2eeb78c2 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_REGULATOR_DA9211) += da9211-regulator.o
obj-$(CONFIG_REGULATOR_DBX500_PRCMU) += dbx500-prcmu.o
obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_FAN53555) += fan53555.o
+obj-$(CONFIG_REGULATOR_FAN53880) += fan53880.o
obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
obj-$(CONFIG_REGULATOR_HI6421V530) += hi6421v530-regulator.o
diff --git a/drivers/regulator/fan53880.c b/drivers/regulator/fan53880.c
new file mode 100644
index ..114c6bd3d962
--- /dev/null
+++ b/drivers/regulator/fan53880.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include
+#include
+#include
+#include
+
+enum fan53880_regulator_ids {
+ FAN53880_LDO1,
+ FAN53880_LDO2,
+ FAN53880_LDO3,
+ FAN53880_LDO4,
+ FAN53880_BUCK,
+ FAN53880_BOOST,
+};
+
+enum fan53880_registers {
+ FAN53880_PRODUCT_ID = 0x00,
+ FAN53880_SILICON_REV,
+ FAN53880_BUCKVOUT,
+ FAN53880_BOOSTVOUT,
+ FAN53880_LDO1VOUT,
+ FAN53880_LDO2VOUT,
+ FAN53880_LDO3VOUT,
+ FAN53880_LDO4VOUT,
+ FAN53880_IOUT,
+ FAN53880_ENABLE,
+ FAN53880_ENABLE_BOOST,
+};
+
+#define FAN53880_ID0x01
+
+static const struct regulator_ops fan53880_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+};
+
+#define FAN53880_LDO(_num, _supply, _default) \
+ [FAN53880_LDO ## _num] = { \
+ .name ="LDO"#_num, \
+ .of_match =of_match_ptr("LDO"#_num),\
+ .regulators_node = of_match_ptr("regulators"), \
+ .type =REGULATOR_VOLTAGE, \
+ .linear_ranges = (struct regulator_linear_range[]) { \
+ REGULATOR_LINEAR_RANGE(_default, 0x0, 0x0, 0),\
+ REGULATOR_LINEAR_RANGE(80, 0xf, 0x73, 25000), \
+ }, \
+ .n_linear_ranges = 2, \
+ .vsel_reg =FAN53880_LDO ## _num ## VOUT,\
+ .vsel_mask = 0x7f,\
+ .enable_reg = FAN53880_ENABLE, \
+ .enable_mask = BIT(_num - 1), \
+ .enable_time = 150, \
+ .supply_name = _supply, \
+ .ops = _ops, \
+ }
+
+static const struct regulator_desc fan53880_regulators[] = {
+ FAN53880_LDO(1, "VIN12", 280),
+ FAN53880_LDO(2, "VIN12", 280),
+ FAN53880_LDO(3, "VIN3", 180),
+ FAN53880_LDO(4, "VIN4", 180),
+ [FAN53880_BUCK] = {
+ .name ="B
[PATCH 2/2] dt-bindings: regulator: Document bindings for fan53880
Add device tree binding information for fan53880 regulator driver.
Signed-off-by: Christoph Fritz
---
.../bindings/regulator/onnn,fan53880.yaml | 85 +++
1 file changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
diff --git a/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
b/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
new file mode 100644
index ..eb61e04ef852
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/onnn,fan53880.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Onsemi FAN53880 PMIC
+
+maintainers:
+ - Christoph Fritz
+
+description: |
+ The FAN53880 is an I2C porgrammable power management IC (PMIC)
+ that contains a BUCK (step-down converter), four low dropouts (LDO)
+ and one BOOST (step-up converter) output. It is designed for mobile
+ power applications.
+
+properties:
+ $nodename:
+pattern: "pmic@[0-9a-f]{1,2}"
+ compatible:
+enum:
+ - onnn,fan53880
+
+ reg:
+maxItems: 1
+
+ VIN12-supply:
+description: Input supply phandle(s) for LDO1 and LDO2
+
+ VIN3-supply:
+description: Input supply phandle(s) for LDO3
+
+ VIN4-supply:
+description: Input supply phandle(s) for LDO4
+
+ PVIN-supply:
+description: Input supply phandle(s) for BUCK and BOOST
+
+ regulators:
+type: object
+$ref: regulator.yaml#
+description: |
+ list of regulators provided by this controller, must be named
+ after their hardware counterparts LDO[1-4], BUCK and BOOST
+
+patternProperties:
+ "^LDO[1-4]$":
+type: object
+$ref: regulator.yaml#
+
+ "^BUCK|BOOST$":
+type: object
+$ref: regulator.yaml#
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+pmic@35 {
+compatible = "onnn,fan53880";
+reg = <0x35>;
+
+PVIN-supply = <_example_vcc>;
+
+regulators {
+BUCK {
+regulator-min-microvolt = <120>;
+regulator-max-microvolt = <120>;
+};
+};
+ };
+ };
+...
--
2.20.1
[PATCH 0/2] regulator: Add FAN53880 support
This patchset adds a regulator driver with dt-bindings documentation in the new yaml format for a power management IC from Fairchild (now ON Semiconductor) named FAN53880. The chip was found on a camera sensor board which will get a v4lsubdev driver in the future. The FAN53880 differs a lot compared to the older FAN53555 which already has driver support. Christoph Fritz (2): regulator: fan53880: Add initial support dt-bindings: regulator: Document bindings for fan53880 .../bindings/regulator/onnn,fan53880.yaml | 85 + drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/fan53880.c | 179 ++ 4 files changed, 275 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml create mode 100644 drivers/regulator/fan53880.c -- 2.20.1
Re: lockup when C1E and high-resolution timers enabled
Hi, the whole error (freeze under heavy IO when C1E enabled) here is referable to motherboard 'GA-970A-UD3P (rev. 1.0)', changing it to a 'Asus M5A97 PLUS' fixes my problems here. I'm not sure if this GA-970A board is just broken or has some general problems. Thanks -- chf -- 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: lockup when C1E and high-resolution timers enabled
Hi, the whole error (freeze under heavy IO when C1E enabled) here is referable to motherboard 'GA-970A-UD3P (rev. 1.0)', changing it to a 'Asus M5A97 PLUS' fixes my problems here. I'm not sure if this GA-970A board is just broken or has some general problems. Thanks -- chf -- 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: lockup when C1E and high-resolution timers enabled
On Mon, 2015-06-15 at 09:54 +0200, Borislav Petkov wrote: > Just to rule out the aspect that your issue might be fixed by microcode > but that microcode needs to be loaded early, can you enable the early > microcode loader, put the microcode in initrd as described here: > > Documentation/x86/early-microcode.txt > > and retry? I should have mentioned that, I already tested that, it doesn't fix the described lockup :-( -- 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: lockup when C1E and high-resolution timers enabled
On Mon, 2015-06-15 at 09:54 +0200, Borislav Petkov wrote: Just to rule out the aspect that your issue might be fixed by microcode but that microcode needs to be loaded early, can you enable the early microcode loader, put the microcode in initrd as described here: Documentation/x86/early-microcode.txt and retry? I should have mentioned that, I already tested that, it doesn't fix the described lockup :-( -- 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: lockup when C1E and high-resolution timers enabled
On Sun, 2015-06-14 at 23:24 +0800, Daniel J Blueman wrote: > val=0x$(setpci -s 00:18.3 0xd4.l) # read D18F3xD4 > val=$((val &~(1 << 13))) # clear bit13 (MTC1eEn) > setpci -d 1022:1603 0xd4.l=$(printf %x $val) # write back This slows down the whole system dramatically: - before: MTC1eEn set: Booting takes 11 secs - after : MTC1eEn cleared: Booting takes 53 secs -- 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: lockup when C1E and high-resolution timers enabled
> > already using latest microcode: > > > > [0.514490] microcode: CPU0: patch_level=0x06000822 > > [0.514497] microcode: CPU1: patch_level=0x06000822 > > [0.514508] microcode: CPU2: patch_level=0x06000822 > > [0.514519] microcode: CPU3: patch_level=0x06000822 > > [0.514529] microcode: CPU4: patch_level=0x06000822 > > [0.514540] microcode: CPU5: patch_level=0x06000822 > > [0.514550] microcode: CPU6: patch_level=0x06000822 > > [0.514561] microcode: CPU7: patch_level=0x06000822 > > This is not the latest microcode. > so what changed? nice catch, my bad -- forgot to post all microcode messages. $ dmesg | grep microcode: [0.514422] microcode: CPU0: patch_level=0x06000822 [0.514429] microcode: CPU1: patch_level=0x06000822 [0.514440] microcode: CPU2: patch_level=0x06000822 [0.514450] microcode: CPU3: patch_level=0x06000822 [0.514460] microcode: CPU4: patch_level=0x06000822 [0.514493] microcode: CPU5: patch_level=0x06000822 [0.514502] microcode: CPU6: patch_level=0x06000822 [0.514513] microcode: CPU7: patch_level=0x06000822 [0.514557] microcode: Microcode Update Driver: v2.00 , Peter Oruba [3.909642] microcode: CPU0: new patch_level=0x06000832 [3.940694] microcode: CPU2: new patch_level=0x06000832 [3.955187] microcode: CPU4: new patch_level=0x06000832 [3.963403] microcode: CPU6: new patch_level=0x06000832 -- 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: lockup when C1E and high-resolution timers enabled
On Sun, 2015-06-14 at 15:54 +0800, Daniel J Blueman wrote: > As a workaround, you can probably just disable message triggered C1E > (see the BKDG p399 [1]): > > val=0x$(setpci -s 00:18.4 0xd4.l) # read D18F3xD4 mhm... $(setpci -s 00:18.4 0xd4.l) returns zero, this can't be right. -- 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: lockup when C1E and high-resolution timers enabled
On Sun, 2015-06-14 at 15:54 +0800, Daniel J Blueman wrote: As a workaround, you can probably just disable message triggered C1E (see the BKDG p399 [1]): val=0x$(setpci -s 00:18.4 0xd4.l) # read D18F3xD4 mhm... $(setpci -s 00:18.4 0xd4.l) returns zero, this can't be right. -- 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: lockup when C1E and high-resolution timers enabled
already using latest microcode: [0.514490] microcode: CPU0: patch_level=0x06000822 [0.514497] microcode: CPU1: patch_level=0x06000822 [0.514508] microcode: CPU2: patch_level=0x06000822 [0.514519] microcode: CPU3: patch_level=0x06000822 [0.514529] microcode: CPU4: patch_level=0x06000822 [0.514540] microcode: CPU5: patch_level=0x06000822 [0.514550] microcode: CPU6: patch_level=0x06000822 [0.514561] microcode: CPU7: patch_level=0x06000822 This is not the latest microcode. so what changed? nice catch, my bad -- forgot to post all microcode messages. $ dmesg | grep microcode: [0.514422] microcode: CPU0: patch_level=0x06000822 [0.514429] microcode: CPU1: patch_level=0x06000822 [0.514440] microcode: CPU2: patch_level=0x06000822 [0.514450] microcode: CPU3: patch_level=0x06000822 [0.514460] microcode: CPU4: patch_level=0x06000822 [0.514493] microcode: CPU5: patch_level=0x06000822 [0.514502] microcode: CPU6: patch_level=0x06000822 [0.514513] microcode: CPU7: patch_level=0x06000822 [0.514557] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [3.909642] microcode: CPU0: new patch_level=0x06000832 [3.940694] microcode: CPU2: new patch_level=0x06000832 [3.955187] microcode: CPU4: new patch_level=0x06000832 [3.963403] microcode: CPU6: new patch_level=0x06000832 -- 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: lockup when C1E and high-resolution timers enabled
On Sun, 2015-06-14 at 23:24 +0800, Daniel J Blueman wrote: val=0x$(setpci -s 00:18.3 0xd4.l) # read D18F3xD4 val=$((val ~(1 13))) # clear bit13 (MTC1eEn) setpci -d 1022:1603 0xd4.l=$(printf %x $val) # write back This slows down the whole system dramatically: - before: MTC1eEn set: Booting takes 11 secs - after : MTC1eEn cleared: Booting takes 53 secs -- 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: lockup when C1E and high-resolution timers enabled
On Sun, 2015-06-14 at 11:13 +0800, Daniel J Blueman wrote: > On Sunday, June 14, 2015 at 4:00:06 AM UTC+8, Christoph Fritz wrote: > > Hi, > > > > on following computer configuration, I do get hard lockup under heavy > > IO-Load (using rsync): > > > > - CONFIG_HIGH_RES_TIMERS=y > > - CPU: AMD FX(tm)-8350 Eight-Core Processor (family 0x15 model 0x2) > > - Motherboard: 'GA-970A-UD3P (rev. 1.0)' AMD 970/SB950 > > - BIOS: C1E enabled (on 'GA-970A-UD3P' there is no disable option) > > - Kernels: 4.1.0-rc6, 4.0.x, 3.16.x > > > > Tests: > > - add kernel parameter "idle=halt" -> system runs fine > > - disable CONFIG_HIGH_RES_TIMERS -> system runs fine > > - change motherboard and disable C1E -> system runs fine > > - change CPU to AMD Phenom II X6 Processor -> system runs fine > [..] > > C1E disconnects HyperTransport links when all cores enter C1 (halt) > for a period of time; this is all at the platform level, so isn't due > to the kernel. The AMD AGESA code which controls the setup of this > mechanism is updated in the F2g BIOS: > http://www.gigabyte.com/products/product-page.aspx?pid=4717#bios > > Did you try both BIOS releases with defaults? Yes, rechecked both versions: Same bad behaviour. > If still issues, also try with the current family 10h microcode from > http://www.amd64.org/microcode/amd-ucode-latest.tar.bz2 Don't you mean family 15h for 'AMD FX(tm)-8350' ? already using latest microcode: [0.514490] microcode: CPU0: patch_level=0x06000822 [0.514497] microcode: CPU1: patch_level=0x06000822 [0.514508] microcode: CPU2: patch_level=0x06000822 [0.514519] microcode: CPU3: patch_level=0x06000822 [0.514529] microcode: CPU4: patch_level=0x06000822 [0.514540] microcode: CPU5: patch_level=0x06000822 [0.514550] microcode: CPU6: patch_level=0x06000822 [0.514561] microcode: CPU7: patch_level=0x06000822 -- 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: lockup when C1E and high-resolution timers enabled
On Sat, 2015-06-13 at 22:19 +0200, Heinz Diehl wrote: > On 13.06.2015, Christoph Fritz wrote: > > > - add kernel parameter "idle=halt" -> system runs fine > > - disable CONFIG_HIGH_RES_TIMERS -> system runs fine > > - change motherboard and disable C1E -> system runs fine > > - change CPU to AMD Phenom II X6 Processor -> system runs fine > > I encountered quite some C1E related problems with different Gigabyte > mainboards in the last few years. Try booting with > acpi_skip_timer_override, it fixed most of those problems for me. > Thanks for your hint, I already tried that: With kernel parameter 'acpi_skip_timer_override' kernel doesn't boot at all. -- 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/
lockup when C1E and high-resolution timers enabled
Hi, on following computer configuration, I do get hard lockup under heavy IO-Load (using rsync): - CONFIG_HIGH_RES_TIMERS=y - CPU: AMD FX(tm)-8350 Eight-Core Processor (family 0x15 model 0x2) - Motherboard: 'GA-970A-UD3P (rev. 1.0)' AMD 970/SB950 - BIOS: C1E enabled (on 'GA-970A-UD3P' there is no disable option) - Kernels: 4.1.0-rc6, 4.0.x, 3.16.x Tests: - add kernel parameter "idle=halt" -> system runs fine - disable CONFIG_HIGH_RES_TIMERS -> system runs fine - change motherboard and disable C1E -> system runs fine - change CPU to AMD Phenom II X6 Processor -> system runs fine $ cat /sys/devices/system/cpu/modalias cpu:type:x86,ven0002fam0015mod0002: feature:,,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C, 000D,000E,000F,0010,0011,0013,0017,0018,0019,001A,001C,0020,0021,0022, 0023,0024,0025,0026,0027,0028,0029,002B,002C,002D,002E,002F,0030,0031, 0034,0036,0037,0038,0039,003A,003B,003D,0064,0068,006E,0070,0071,0074, 0075,0078,007A,007C,0080,0081,0083,0089,008C,008D,0093,0094,0097,0099, 009A,009B,009C,009D,00C0,00C1,00C2,00C3,00C4,00C5,00C6,00C7,00C8,00C9, 00CA,00CB,00CC,00CD,00CF,00D0,00D1,00D3,00D5,00D6,00D7,00D8,00E1,00E2, 00E8,0105,0106,0107,0108,0109,010A,010B,010C,010D,010E,010F,0123 $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping: 0 microcode : 0x6000832 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 bugs: fxsave_leak sysret_ss_attrs bogomips: 8036.70 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro Any ideas? Thanks -- Christoph -- 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: lockup when C1E and high-resolution timers enabled
On Sun, 2015-06-14 at 11:13 +0800, Daniel J Blueman wrote: On Sunday, June 14, 2015 at 4:00:06 AM UTC+8, Christoph Fritz wrote: Hi, on following computer configuration, I do get hard lockup under heavy IO-Load (using rsync): - CONFIG_HIGH_RES_TIMERS=y - CPU: AMD FX(tm)-8350 Eight-Core Processor (family 0x15 model 0x2) - Motherboard: 'GA-970A-UD3P (rev. 1.0)' AMD 970/SB950 - BIOS: C1E enabled (on 'GA-970A-UD3P' there is no disable option) - Kernels: 4.1.0-rc6, 4.0.x, 3.16.x Tests: - add kernel parameter idle=halt - system runs fine - disable CONFIG_HIGH_RES_TIMERS - system runs fine - change motherboard and disable C1E - system runs fine - change CPU to AMD Phenom II X6 Processor - system runs fine [..] C1E disconnects HyperTransport links when all cores enter C1 (halt) for a period of time; this is all at the platform level, so isn't due to the kernel. The AMD AGESA code which controls the setup of this mechanism is updated in the F2g BIOS: http://www.gigabyte.com/products/product-page.aspx?pid=4717#bios Did you try both BIOS releases with defaults? Yes, rechecked both versions: Same bad behaviour. If still issues, also try with the current family 10h microcode from http://www.amd64.org/microcode/amd-ucode-latest.tar.bz2 Don't you mean family 15h for 'AMD FX(tm)-8350' ? already using latest microcode: [0.514490] microcode: CPU0: patch_level=0x06000822 [0.514497] microcode: CPU1: patch_level=0x06000822 [0.514508] microcode: CPU2: patch_level=0x06000822 [0.514519] microcode: CPU3: patch_level=0x06000822 [0.514529] microcode: CPU4: patch_level=0x06000822 [0.514540] microcode: CPU5: patch_level=0x06000822 [0.514550] microcode: CPU6: patch_level=0x06000822 [0.514561] microcode: CPU7: patch_level=0x06000822 -- 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/
lockup when C1E and high-resolution timers enabled
Hi, on following computer configuration, I do get hard lockup under heavy IO-Load (using rsync): - CONFIG_HIGH_RES_TIMERS=y - CPU: AMD FX(tm)-8350 Eight-Core Processor (family 0x15 model 0x2) - Motherboard: 'GA-970A-UD3P (rev. 1.0)' AMD 970/SB950 - BIOS: C1E enabled (on 'GA-970A-UD3P' there is no disable option) - Kernels: 4.1.0-rc6, 4.0.x, 3.16.x Tests: - add kernel parameter idle=halt - system runs fine - disable CONFIG_HIGH_RES_TIMERS - system runs fine - change motherboard and disable C1E - system runs fine - change CPU to AMD Phenom II X6 Processor - system runs fine $ cat /sys/devices/system/cpu/modalias cpu:type:x86,ven0002fam0015mod0002: feature:,,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C, 000D,000E,000F,0010,0011,0013,0017,0018,0019,001A,001C,0020,0021,0022, 0023,0024,0025,0026,0027,0028,0029,002B,002C,002D,002E,002F,0030,0031, 0034,0036,0037,0038,0039,003A,003B,003D,0064,0068,006E,0070,0071,0074, 0075,0078,007A,007C,0080,0081,0083,0089,008C,008D,0093,0094,0097,0099, 009A,009B,009C,009D,00C0,00C1,00C2,00C3,00C4,00C5,00C6,00C7,00C8,00C9, 00CA,00CB,00CC,00CD,00CF,00D0,00D1,00D3,00D5,00D6,00D7,00D8,00E1,00E2, 00E8,0105,0106,0107,0108,0109,010A,010B,010C,010D,010E,010F,0123 $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping: 0 microcode : 0x6000832 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1 bugs: fxsave_leak sysret_ss_attrs bogomips: 8036.70 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro snip Any ideas? Thanks -- Christoph -- 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: lockup when C1E and high-resolution timers enabled
On Sat, 2015-06-13 at 22:19 +0200, Heinz Diehl wrote: On 13.06.2015, Christoph Fritz wrote: - add kernel parameter idle=halt - system runs fine - disable CONFIG_HIGH_RES_TIMERS - system runs fine - change motherboard and disable C1E - system runs fine - change CPU to AMD Phenom II X6 Processor - system runs fine I encountered quite some C1E related problems with different Gigabyte mainboards in the last few years. Try booting with acpi_skip_timer_override, it fixed most of those problems for me. Thanks for your hint, I already tried that: With kernel parameter 'acpi_skip_timer_override' kernel doesn't boot at all. -- 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] UBI: rename_volumes: Use UBI_METAONLY
On Wed, 2014-12-17 at 14:49 -0300, Guido MartÃnez wrote: > > (for both patches) > Tested-by: Guido MartÃnez here too, Tested-by: Christoph Fritz By the way, when will this patch get merged? -- 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] UBI: rename_volumes: Use UBI_METAONLY
On Wed, 2014-12-17 at 14:49 -0300, Guido MartÃnez wrote: (for both patches) Tested-by: Guido MartÃnez gu...@vanguardiasur.com.ar here too, Tested-by: Christoph Fritz chf.fr...@googlemail.com By the way, when will this patch get merged? -- 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: OMAP: clock DT conversion issues with omap36xx
On Thu, 2014-02-13 at 12:05 +0200, Tomi Valkeinen wrote: > On 13/02/14 11:03, Tomi Valkeinen wrote: > > On 12/02/14 15:18, Tomi Valkeinen wrote: > > > >> However, I hacked together the patch below, which "fixes" the issue for > >> 96m and dss fclk. It sets the clock parents so that the x2 clocks are > >> skipped, and makes the x2 clock nodes compatible with "unused", making > >> them effectively disappear. I only verified dss fclk, so Christoph, can > >> you verify the 96m clock? > > > > Aaand the hack patch I sent is crap... We can't skip the x2 clock path, > > as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is > > present on 3630 also. > > > > I think the best and simplest way to fix this is by setting the > > multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I > > didn't think of it yesterday. > > > > I have a bunch of other patches needed to get the clocks right, so I'll > > send a series separately a bit later today. > > I just sent the "OMAP: OMAP3 DSS related clock patches" series to l-o > and arm lists, which hopefully solves issues discussed in this thread. Yes, thanks Tomi. I tested your patch series on a83x board. 96m clock and DSS-clocks are fine now. If you want, you can add my: Tested-by: Christoph Fritz to your series "OMAP: OMAP3 DSS related clock patches". The only issue left on current mainline for a83x board is that twl4030 (tps65920) doesn't set VIO as on next-20140120. Thanks -- Christoph -- 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: OMAP: clock DT conversion issues with omap36xx
On Thu, 2014-02-13 at 12:05 +0200, Tomi Valkeinen wrote: On 13/02/14 11:03, Tomi Valkeinen wrote: On 12/02/14 15:18, Tomi Valkeinen wrote: However, I hacked together the patch below, which fixes the issue for 96m and dss fclk. It sets the clock parents so that the x2 clocks are skipped, and makes the x2 clock nodes compatible with unused, making them effectively disappear. I only verified dss fclk, so Christoph, can you verify the 96m clock? Aaand the hack patch I sent is crap... We can't skip the x2 clock path, as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is present on 3630 also. I think the best and simplest way to fix this is by setting the multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I didn't think of it yesterday. I have a bunch of other patches needed to get the clocks right, so I'll send a series separately a bit later today. I just sent the OMAP: OMAP3 DSS related clock patches series to l-o and arm lists, which hopefully solves issues discussed in this thread. Yes, thanks Tomi. I tested your patch series on a83x board. 96m clock and DSS-clocks are fine now. If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com to your series OMAP: OMAP3 DSS related clock patches. The only issue left on current mainline for a83x board is that twl4030 (tps65920) doesn't set VIO as on next-20140120. Thanks -- Christoph -- 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: OMAP: clock DT conversion issues with omap36xx
On Fri, 2014-02-07 at 15:49 +0200, Tomi Valkeinen wrote: > On 07/02/14 12:12, Christoph Fritz wrote: > > > Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, > > you can add my: > > Tested-by: Christoph Fritz > > > > Below is my clock fix for dss: > > > > From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 > > From: Christoph Fritz > > Date: Fri, 7 Feb 2014 10:51:15 +0100 > > Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree > > > > OMAP36xx has different hardware implementation for the dpll4_m4_ck tree > > compared to other OMAP3 variants. Reflect this properly in the dts file. > > I rebased the DSS DT branch on top of v3.14-rc1, and I'm trying to get > beagle-xM working. Pinmuxing was wrong, but after fixing that, the > clk_set_rate for dss fclk failed. I applied Tero's and your patches, but > now when starting omapdss I see: > > [ 19.704193] omap clock: module associated with clock > dss1_alwon_fck_3430es2 didn't enable in 1000 > 00 tries > > I wonder if I'm still missing some patch? Is beagle-xM using DSI? Because here the LILLY-A83X board is not. The clock registers are all fine now as before the dt clock conversion patches. I suppose you are using current linus tree. I tested 'next' but didn't get DSS working. I guessed that it would have something to do with early DSS DT integration issues. I'll rebase my current dt board support patchset for LILLY-A83X to current linus tree and investigate DSS further. Thanks -- Christoph -- 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: OMAP: clock DT conversion issues with omap36xx
On Fri, 2014-02-07 at 15:49 +0200, Tomi Valkeinen wrote: On 07/02/14 12:12, Christoph Fritz wrote: Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com Below is my clock fix for dss: From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree OMAP36xx has different hardware implementation for the dpll4_m4_ck tree compared to other OMAP3 variants. Reflect this properly in the dts file. I rebased the DSS DT branch on top of v3.14-rc1, and I'm trying to get beagle-xM working. Pinmuxing was wrong, but after fixing that, the clk_set_rate for dss fclk failed. I applied Tero's and your patches, but now when starting omapdss I see: [ 19.704193] omap clock: module associated with clock dss1_alwon_fck_3430es2 didn't enable in 1000 00 tries I wonder if I'm still missing some patch? Is beagle-xM using DSI? Because here the LILLY-A83X board is not. The clock registers are all fine now as before the dt clock conversion patches. I suppose you are using current linus tree. I tested 'next' but didn't get DSS working. I guessed that it would have something to do with early DSS DT integration issues. I'll rebase my current dt board support patchset for LILLY-A83X to current linus tree and investigate DSS further. Thanks -- Christoph -- 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: OMAP: clock DT conversion issues with omap36xx
On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote:
> On 01/29/2014 01:21 PM, Christoph Fritz wrote:
> >> Currently I only analyzed sys_clkout2 (see attachments for full
> >> clk_summary files):
> >>
> >> clk_summary__next-20140115__works_as_expected:
> >> dpll4_m2_ck1 19600
> >> dpll4_m2x2_ck 1 19600
> >> omap_192m_alwon_fck 1 19600
> >>omap_96m_alwon_fck 1 29600
> >> per_96m_fck 0 69600
> >> mcbsp4_fck 0 19600
> >> mcbsp3_fck 0 29600
> >> mcbsp2_fck 0 29600
> >> cm_96m_fck 2 39600
> >> clkout2_src_ck 1 1
> >> 9600
> >> sys_clkout2 1 1
> >> 2400
> >>
> >> For real, on pin sys_clkout2 are correctly 24 Mhz measured.
> >>
> >> clk_summary__next-20140124__sysclkout2_dss_fails:
> >> dpll4_m2_ck1 19600
> >> dpll4_m2x2_mul_ck 1 119200
> >> dpll4_m2x2_ck 1 119200
> >>omap_192m_alwon_fck 0 0
> >> 19200
> >>omap_96m_alwon_fck 1 2
> >> 19200
> >> per_96m_fck 0 619200
> >> mcbsp4_fck 0 119200
> >> mcbsp3_fck 0 219200
> >> mcbsp2_fck 0 219200
> >> cm_96m_fck 2 319200
> >> clkout2_src_ck 1 1
> >> 19200
> >> sys_clkout2 1 1
> >> 2400
> >>
> >> For real, on pin sys_clkout2 are only ~12 Mhz measured.
>
> Hey Christoph,
>
> I had a chance to look at this in more detail, and it looks like your
> patch above was almost the correct one (except that I think you modified
> wrong property and also modified the clock node for all omap3 variants.)
> Can you give this one a shot? Can you also send me the clk-summary dump
> with this patch (with the relevant nodes)?
dpll4_m2_ck1 19600 0
dpll4_m2x2_mul_ck 1 119200 0
dpll4_m2x2_ck 1 119200 0
omap_192m_alwon_fck 0 019200 0
omap_96m_alwon_fck 1 29600 0
per_96m_fck 0 69600 0
mcbsp4_fck 0 19600 0
mcbsp3_fck 0 29600 0
mcbsp2_fck 0 29600 0
cm_96m_fck 2 39600 0
clkout2_src_ck 1 19600 0
sys_clkout2 1 12400 0
Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want,
you can add my:
Tested-by: Christoph Fritz
Below is my clock fix for dss:
>From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001
From: Christoph Fritz
Date: Fri, 7 Feb 2014 10:51:15 +0100
Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree
OMAP36xx has different hardware implementation for the dpll4_m4_ck tree
compared to other OMAP3 variants. Reflect this properly in the dts file.
before omap dt clock conversion:
dpll4_m4_ck1 15760
dpll4_m4x2_ck 1 15760
dss1_alwon_fck_3430es2 2 45760
after omap dt clock conversion:
dpll4_m4_ck0 19600 0
dpll4_m4x2_mul_ck 0 119200 0
dpll4_m4x2_ck 0 119200 0
dss1_alwon_fck_3430es2 0 4
Re: OMAP: clock DT conversion issues with omap36xx
On Tue, 2014-02-04 at 17:50 +0200, Tero Kristo wrote: On 01/29/2014 01:21 PM, Christoph Fritz wrote: Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 29600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 1 9600 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 0 19200 omap_96m_alwon_fck 1 2 19200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 1 19200 sys_clkout2 1 1 2400 For real, on pin sys_clkout2 are only ~12 Mhz measured. Hey Christoph, I had a chance to look at this in more detail, and it looks like your patch above was almost the correct one (except that I think you modified wrong property and also modified the clock node for all omap3 variants.) Can you give this one a shot? Can you also send me the clk-summary dump with this patch (with the relevant nodes)? dpll4_m2_ck1 19600 0 dpll4_m2x2_mul_ck 1 119200 0 dpll4_m2x2_ck 1 119200 0 omap_192m_alwon_fck 0 019200 0 omap_96m_alwon_fck 1 29600 0 per_96m_fck 0 69600 0 mcbsp4_fck 0 19600 0 mcbsp3_fck 0 29600 0 mcbsp2_fck 0 29600 0 cm_96m_fck 2 39600 0 clkout2_src_ck 1 19600 0 sys_clkout2 1 12400 0 Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want, you can add my: Tested-by: Christoph Fritz chf.fr...@googlemail.com Below is my clock fix for dss: From b90a62128068e1b6b0ba2a11c5cc0c8e587cf301 Mon Sep 17 00:00:00 2001 From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 7 Feb 2014 10:51:15 +0100 Subject: [PATCH] ARM: dts: omap36xx: fix dpll4_m4_ck tree OMAP36xx has different hardware implementation for the dpll4_m4_ck tree compared to other OMAP3 variants. Reflect this properly in the dts file. before omap dt clock conversion: dpll4_m4_ck1 15760 dpll4_m4x2_ck 1 15760 dss1_alwon_fck_3430es2 2 45760 after omap dt clock conversion: dpll4_m4_ck0 19600 0 dpll4_m4x2_mul_ck 0 119200 0 dpll4_m4x2_ck 0 119200 0 dss1_alwon_fck_3430es2 0 419200 0 with this patch: dpll4_m4_ck1 15760 0 dss1_alwon_fck_3430es2 2 45760 0 dpll4_m4x2_mul_ck 0 011520 0 dpll4_m4x2_ck 0 011520 0 Signed-off-by: Christoph Fritz chf.fr...@googlemail.com --- arch/arm/boot/dts/omap36xx-clocks.dtsi |8 arch/arm/boot/dts
Re: OMAP: clock DT conversion issues with omap36xx
On Sat, 2014-02-01 at 19:52 +0100, Christoph Fritz wrote: > On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote: > > To help us debug similar problems, I wrote a tool today: > > https://github.com/nmenon/ctt-dump - it is a simple memory read utility, > > Input file is CTT dump-out > > For example: 3630 CTT is here: > > http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip > > > > to give an idea - i posted a screen shot here: > > https://plus.google.com/112464029509057661457/posts/hNdee4gNfob > > > > After generating the the rd1 file from CTT, > > we pick up the registers using ctt-dump -> any tool which can do > > register reads could do, but it might be handy having this. > > Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium > > importing it back into CTT and after setting up the correct sysclk, we > > can compare clock frequencies Vs debugfs output - example: > > http://slexy.org/view/s21iQyDTct > > > > > > I mean, it is awesome having to debugfs data, but with nascent > > systems, it is always good to compare to what the hardware is really > > configured to - and CTT is the easy way to deal with it. > > Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on > this hardware here (omap3-lil-a83x). Its corresponding rd1 file, > generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware > has a 26 Mhz crystal. > > The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE > right. 0x2 is CM_96M_FCLK not CORE_CLK for example. > > > This is the diff of clk registers before and after DT clock > conversion patches: > > --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 > +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01 > @@ -22,23 +22,23 @@ > 0x48004c10 0x002f > 0x48004c30 0x023f > 0x48004c40 0x0014 > -0x48004d00 0x10370037 > +0x48004d00 0xf0371037 > 0x48004d04 0x0017 > 0x48004d40 0x09900c00 > 0x48004d44 0x0483600c > 0x48004d48 0x0009 > 0x48004d4c 0x780c > 0x48004d50 0x0001 > -0x48004d70 0x0092 > -0x48004e00 0x0001 > +0x48004d70 0x009a > +0x48004e00 0x > 0x48004e10 0x0001 > 0x48004e30 0x0001 > -0x48004e40 0x100f > +0x48004e40 0x1009 > 0x48004f00 0x > 0x48004f10 0x > 0x48004f30 0x0001 > 0x48004f40 0x0004 > -0x48005000 0x00040800 > +0x48005000 0x0800 > 0x48005010 0x00078fff > 0x48005030 0x0007 > 0x48005040 0x00ff Origin files of this diff added as attachment to this mail. DeviceName OMAP3630_ES1.x 0x48002274 0x0500 0x480022d8 0x 0x48004000 0x 0x48004004 0x0017 0x48004040 0x00081400 0x48004044 0x0001 0x48004904 0x0037 0x48004940 0x0012580c 0x48004944 0x0001 0x48004a00 0x6000 0x48004a08 0x0004 0x48004a10 0x5b3ffe42 0x48004a18 0x0004 0x48004a30 0x7ed9 0x48004a38 0x000c 0x48004a40 0x130a 0x48004b00 0x 0x48004b10 0x 0x48004b40 0x0005 0x48004c00 0x0001 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 0x48004d70 0x009a 0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff 0x48005140 0x03020a50 0x48005400 0x0003 0x48005410 0x0001 0x48005430 0x0001 0x48306ae0 0x000f0317 0x48306d70 0x 0x48307270 0x0088 0x483074e0 0x00030105 DeviceName OMAP3630_ES1.x 0x48002274 0x0500 0x480022d8 0x 0x48004000 0x 0x48004004 0x0017 0x48004040 0x00081400 0x48004044 0x0001 0x48004904 0x0037 0x48004940 0x0012580c 0x48004944 0x0001 0x48004a00 0x6000 0x48004a08 0x0004 0x48004a10 0x5b3ffe42 0x48004a18 0x0004 0x48004a30 0x7ed9 0x48004a38 0x000c 0x48004a40 0x130a 0x48004b00 0x 0x48004b10 0x 0x48004b40 0x0005 0x48004c00 0x0001 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 0x48004d00 0x10370037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 0x48004d70 0x0092 0x48004e00 0x0001 0x48004e10 0x0001 0x48004e30 0x0001 0x48004e40 0x100f 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 0x48005000 0x00040800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff 0x48005140 0x03020a50 0x48005400 0x0003 0x48005410 0x0001 0x48005430 0x0001 0x48306ae0 0x000f0317 0x48306d70 0x 0x48307270 0x0088 0x483074e0 0x00030105
Re: OMAP: clock DT conversion issues with omap36xx
On Sat, 2014-02-01 at 19:52 +0100, Christoph Fritz wrote: On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote: To help us debug similar problems, I wrote a tool today: https://github.com/nmenon/ctt-dump - it is a simple memory read utility, Input file is CTT dump-out For example: 3630 CTT is here: http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip to give an idea - i posted a screen shot here: https://plus.google.com/112464029509057661457/posts/hNdee4gNfob After generating the the rd1 file from CTT, we pick up the registers using ctt-dump - any tool which can do register reads could do, but it might be handy having this. Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium importing it back into CTT and after setting up the correct sysclk, we can compare clock frequencies Vs debugfs output - example: http://slexy.org/view/s21iQyDTct I mean, it is awesome having to debugfs data, but with nascent systems, it is always good to compare to what the hardware is really configured to - and CTT is the easy way to deal with it. Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on this hardware here (omap3-lil-a83x). Its corresponding rd1 file, generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware has a 26 Mhz crystal. The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE right. 0x2 is CM_96M_FCLK not CORE_CLK for example. This is the diff of clk registers before and after DT clock conversion patches: --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01 @@ -22,23 +22,23 @@ 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 -0x48004d00 0x10370037 +0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 -0x48004d70 0x0092 -0x48004e00 0x0001 +0x48004d70 0x009a +0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 -0x48004e40 0x100f +0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 -0x48005000 0x00040800 +0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff Origin files of this diff added as attachment to this mail. DeviceName OMAP3630_ES1.x 0x48002274 0x0500 0x480022d8 0x 0x48004000 0x 0x48004004 0x0017 0x48004040 0x00081400 0x48004044 0x0001 0x48004904 0x0037 0x48004940 0x0012580c 0x48004944 0x0001 0x48004a00 0x6000 0x48004a08 0x0004 0x48004a10 0x5b3ffe42 0x48004a18 0x0004 0x48004a30 0x7ed9 0x48004a38 0x000c 0x48004a40 0x130a 0x48004b00 0x 0x48004b10 0x 0x48004b40 0x0005 0x48004c00 0x0001 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 0x48004d70 0x009a 0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff 0x48005140 0x03020a50 0x48005400 0x0003 0x48005410 0x0001 0x48005430 0x0001 0x48306ae0 0x000f0317 0x48306d70 0x 0x48307270 0x0088 0x483074e0 0x00030105 DeviceName OMAP3630_ES1.x 0x48002274 0x0500 0x480022d8 0x 0x48004000 0x 0x48004004 0x0017 0x48004040 0x00081400 0x48004044 0x0001 0x48004904 0x0037 0x48004940 0x0012580c 0x48004944 0x0001 0x48004a00 0x6000 0x48004a08 0x0004 0x48004a10 0x5b3ffe42 0x48004a18 0x0004 0x48004a30 0x7ed9 0x48004a38 0x000c 0x48004a40 0x130a 0x48004b00 0x 0x48004b10 0x 0x48004b40 0x0005 0x48004c00 0x0001 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 0x48004d00 0x10370037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 0x48004d70 0x0092 0x48004e00 0x0001 0x48004e10 0x0001 0x48004e30 0x0001 0x48004e40 0x100f 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 0x48005000 0x00040800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff 0x48005140 0x03020a50 0x48005400 0x0003 0x48005410 0x0001 0x48005430 0x0001 0x48306ae0 0x000f0317 0x48306d70 0x 0x48307270 0x0088 0x483074e0 0x00030105
Re: OMAP: clock DT conversion issues with omap36xx
On Wed, Jan 29, 2014 at 04:57:00PM +0200, Tero Kristo wrote: > > Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding > ti,min-div = <2>; and ti,max-div = <4>; to properties of the clock > node. Hmm, doesn't change anything here. Thanks -- Christoph -- 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: OMAP: clock DT conversion issues with omap36xx
On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote: > To help us debug similar problems, I wrote a tool today: > https://github.com/nmenon/ctt-dump - it is a simple memory read utility, > Input file is CTT dump-out > For example: 3630 CTT is here: > http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip > > to give an idea - i posted a screen shot here: > https://plus.google.com/112464029509057661457/posts/hNdee4gNfob > > After generating the the rd1 file from CTT, > we pick up the registers using ctt-dump -> any tool which can do > register reads could do, but it might be handy having this. > Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium > importing it back into CTT and after setting up the correct sysclk, we > can compare clock frequencies Vs debugfs output - example: > http://slexy.org/view/s21iQyDTct > > > I mean, it is awesome having to debugfs data, but with nascent > systems, it is always good to compare to what the hardware is really > configured to - and CTT is the easy way to deal with it. Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on this hardware here (omap3-lil-a83x). Its corresponding rd1 file, generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware has a 26 Mhz crystal. The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE right. 0x2 is CM_96M_FCLK not CORE_CLK for example. This is the diff of clk registers before and after DT clock conversion patches: --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01 @@ -22,23 +22,23 @@ 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 -0x48004d00 0x10370037 +0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 -0x48004d70 0x0092 -0x48004e00 0x0001 +0x48004d70 0x009a +0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 -0x48004e40 0x100f +0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 -0x48005000 0x00040800 +0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff Thanks -- Christoph -- 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: OMAP: clock DT conversion issues with omap36xx
On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote: To help us debug similar problems, I wrote a tool today: https://github.com/nmenon/ctt-dump - it is a simple memory read utility, Input file is CTT dump-out For example: 3630 CTT is here: http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip to give an idea - i posted a screen shot here: https://plus.google.com/112464029509057661457/posts/hNdee4gNfob After generating the the rd1 file from CTT, we pick up the registers using ctt-dump - any tool which can do register reads could do, but it might be handy having this. Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium importing it back into CTT and after setting up the correct sysclk, we can compare clock frequencies Vs debugfs output - example: http://slexy.org/view/s21iQyDTct I mean, it is awesome having to debugfs data, but with nascent systems, it is always good to compare to what the hardware is really configured to - and CTT is the easy way to deal with it. Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on this hardware here (omap3-lil-a83x). Its corresponding rd1 file, generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware has a 26 Mhz crystal. The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE right. 0x2 is CM_96M_FCLK not CORE_CLK for example. This is the diff of clk registers before and after DT clock conversion patches: --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01 @@ -22,23 +22,23 @@ 0x48004c10 0x002f 0x48004c30 0x023f 0x48004c40 0x0014 -0x48004d00 0x10370037 +0x48004d00 0xf0371037 0x48004d04 0x0017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x0009 0x48004d4c 0x780c 0x48004d50 0x0001 -0x48004d70 0x0092 -0x48004e00 0x0001 +0x48004d70 0x009a +0x48004e00 0x 0x48004e10 0x0001 0x48004e30 0x0001 -0x48004e40 0x100f +0x48004e40 0x1009 0x48004f00 0x 0x48004f10 0x 0x48004f30 0x0001 0x48004f40 0x0004 -0x48005000 0x00040800 +0x48005000 0x0800 0x48005010 0x00078fff 0x48005030 0x0007 0x48005040 0x00ff Thanks -- Christoph -- 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: OMAP: clock DT conversion issues with omap36xx
On Wed, Jan 29, 2014 at 04:57:00PM +0200, Tero Kristo wrote: Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding ti,min-div = 2; and ti,max-div = 4; to properties of the clock node. Hmm, doesn't change anything here. Thanks -- Christoph -- 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/
OMAP: clock DT conversion issues with omap36xx
On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote: > On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote: > > > > >> Due to a regression since next-20140122 the following errors are present: > > >> > > >> - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch > > >> in this set, erroneously outputs only 12 Mhz. > > >> Just out of curiosity, configuring it to 48 Mhz puts out desired 24 > > >> Mhz. > > >> > > >> - omap_dss, which gets configured by the third patch in this set, fails > > >> to do 'dss_set_fck_rate(fck);' in > > >> drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads > > >> to: > > >> > > >> | omapdss_dss: probe of omapdss_dss failed with error -22 > > >> | omapdss CORE error: Failed to initialize DSS platform driver > > >> | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 > > >> > > >>Both regressions seem to have something to do with the clock > > >> framework. > > >>Could this be related to the DT clock conversion patches? > > > > > > > Yea its definitely possible, as the clock DT conversion touches pretty > > much everything. Have you tried whether this works properly with legacy > > boot? Personally I don't have access to any omap3 devices that would > > have display and have no possibility to check this out myself. Anyway, > > my initial guess is that some clock divider setup might be wrong with > > omap3, or we are missing some ti,set-rate-parent flag for some clock > > node which prevents escalating clk_set_rate properly. However, it should > > be easy to debug this by looking at the clock node in question, and its > > parent nodes to see if there are any problems. > > Currently I only analyzed sys_clkout2 (see attachments for full > clk_summary files): > > clk_summary__next-20140115__works_as_expected: > dpll4_m2_ck1 19600 > dpll4_m2x2_ck 1 19600 >omap_192m_alwon_fck 1 19600 > omap_96m_alwon_fck 1 29600 > per_96m_fck 0 69600 > mcbsp4_fck 0 19600 > mcbsp3_fck 0 29600 > mcbsp2_fck 0 29600 > cm_96m_fck 2 39600 > clkout2_src_ck 1 19600 >sys_clkout2 1 12400 > > For real, on pin sys_clkout2 are correctly 24 Mhz measured. > > clk_summary__next-20140124__sysclkout2_dss_fails: > dpll4_m2_ck1 19600 > dpll4_m2x2_mul_ck 1 119200 >dpll4_m2x2_ck 1 119200 > omap_192m_alwon_fck 0 019200 > omap_96m_alwon_fck 1 219200 > per_96m_fck 0 619200 > mcbsp4_fck 0 119200 > mcbsp3_fck 0 219200 > mcbsp2_fck 0 219200 > cm_96m_fck 2 319200 > clkout2_src_ck 1 119200 >sys_clkout2 1 12400 > > For real, on pin sys_clkout2 are only ~12 Mhz measured. > > So I added this patch: > > Subject: [PATCH] ARM: dts: fix omap3 clock multiplier for dpll4_m2x2_ck > > Before DT clock conversion, there was no multiplier for dpll4_m2x2_ck. > So to be compatible again, set dpll4_m2x2_mul_ck multiplier back to 1. > --- > arch/arm/boot/dts/omap3xxx-clocks.dtsi |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi > b/arch/arm/boot/dts/omap3xxx-clocks.dtsi > index cb04d4b..b594050 100644 > --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi > +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi > @@ -212,7 +212,7 @@ > #clock-cells = <0>; > compatible = "fixed-factor-clock"; > clocks = <_m2_ck
OMAP: clock DT conversion issues with omap36xx
On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote: On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote: Due to a regression since next-20140122 the following errors are present: - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch in this set, erroneously outputs only 12 Mhz. Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz. - omap_dss, which gets configured by the third patch in this set, fails to do 'dss_set_fck_rate(fck);' in drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to: | omapdss_dss: probe of omapdss_dss failed with error -22 | omapdss CORE error: Failed to initialize DSS platform driver | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 Both regressions seem to have something to do with the clock framework. Could this be related to the DT clock conversion patches? Yea its definitely possible, as the clock DT conversion touches pretty much everything. Have you tried whether this works properly with legacy boot? Personally I don't have access to any omap3 devices that would have display and have no possibility to check this out myself. Anyway, my initial guess is that some clock divider setup might be wrong with omap3, or we are missing some ti,set-rate-parent flag for some clock node which prevents escalating clk_set_rate properly. However, it should be easy to debug this by looking at the clock node in question, and its parent nodes to see if there are any problems. Currently I only analyzed sys_clkout2 (see attachments for full clk_summary files): clk_summary__next-20140115__works_as_expected: dpll4_m2_ck1 19600 dpll4_m2x2_ck 1 19600 omap_192m_alwon_fck 1 19600 omap_96m_alwon_fck 1 29600 per_96m_fck 0 69600 mcbsp4_fck 0 19600 mcbsp3_fck 0 29600 mcbsp2_fck 0 29600 cm_96m_fck 2 39600 clkout2_src_ck 1 19600 sys_clkout2 1 12400 For real, on pin sys_clkout2 are correctly 24 Mhz measured. clk_summary__next-20140124__sysclkout2_dss_fails: dpll4_m2_ck1 19600 dpll4_m2x2_mul_ck 1 119200 dpll4_m2x2_ck 1 119200 omap_192m_alwon_fck 0 019200 omap_96m_alwon_fck 1 219200 per_96m_fck 0 619200 mcbsp4_fck 0 119200 mcbsp3_fck 0 219200 mcbsp2_fck 0 219200 cm_96m_fck 2 319200 clkout2_src_ck 1 119200 sys_clkout2 1 12400 For real, on pin sys_clkout2 are only ~12 Mhz measured. So I added this patch: Subject: [PATCH] ARM: dts: fix omap3 clock multiplier for dpll4_m2x2_ck Before DT clock conversion, there was no multiplier for dpll4_m2x2_ck. So to be compatible again, set dpll4_m2x2_mul_ck multiplier back to 1. --- arch/arm/boot/dts/omap3xxx-clocks.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index cb04d4b..b594050 100644 --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi @@ -212,7 +212,7 @@ #clock-cells = 0; compatible = fixed-factor-clock; clocks = dpll4_m2_ck; - clock-mult = 2; + clock-mult = 1; clock-div = 1; }; And it works again. But due to the fact that sys_clkout2 was at 12 Mhz instead of 24, shouldn't it have been at 48 caused by clock-mult = 2 ? Any ideas on that? I reverted the patch above and added: From: Tero Kristo t-kri...@ti.com Date: Wed, 29 Jan 2014 11:03:46 +0200 Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck OMAP36xx has different hardware implementation for the omap96m_alwon_fck compared to other OMAP3 variants. Reflect this properly in the dts file. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/boot/dts/omap36xx
Re: [BISECTED] OMAP: DSS: clk rate mismatch
On Tue, 2014-01-28 at 11:04 +0200, Tomi Valkeinen wrote: > On 2014-01-27 20:41, Christoph Fritz wrote: > > On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote: > >> linux-next-20140124 DSS is broken on N900 - display stays black (there > >> is some noise though). I booted the kernel with qemu and it gives the > >> following warning: > >> > >> [0.623779] DSS: set fck to 17280 > >> [0.624237] [ cut here ] > >> [0.624298] WARNING: CPU: 0 PID: 1 at > >> drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c() > >> [0.624359] clk rate mismatch: 28800 != 17280 > > > > Here are also clock regressions since next-20140122 regarding > > dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a > > dm37xx100 board. Please see here: > > I presume you get a similar warning on your board? What rates does it > report? None, dss_set_fck_rate() just fails so omapdss_dss exits with error -22. To quote the cover-letter[1] of my board-support patch series here: Due to a regression since next-20140122 the following errors are present: - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch in this set, erroneously outputs only 12 Mhz. Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz. - omap_dss, which gets configured by the third patch in this set, fails to do 'dss_set_fck_rate(fck);' in drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to: | omapdss_dss: probe of omapdss_dss failed with error -22 | omapdss CORE error: Failed to initialize DSS platform driver | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 Both regressions seem to have something to do with the clock framework. Could this be related to the DT clock conversion patches? [1]: http://thread.gmane.org/gmane.linux.ports.arm.omap/110095 -- 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: [BISECTED] OMAP: DSS: clk rate mismatch
On Tue, 2014-01-28 at 11:04 +0200, Tomi Valkeinen wrote: On 2014-01-27 20:41, Christoph Fritz wrote: On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote: linux-next-20140124 DSS is broken on N900 - display stays black (there is some noise though). I booted the kernel with qemu and it gives the following warning: [0.623779] DSS: set fck to 17280 [0.624237] [ cut here ] [0.624298] WARNING: CPU: 0 PID: 1 at drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c() [0.624359] clk rate mismatch: 28800 != 17280 Here are also clock regressions since next-20140122 regarding dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a dm37xx100 board. Please see here: I presume you get a similar warning on your board? What rates does it report? None, dss_set_fck_rate() just fails so omapdss_dss exits with error -22. To quote the cover-letter[1] of my board-support patch series here: Due to a regression since next-20140122 the following errors are present: - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch in this set, erroneously outputs only 12 Mhz. Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz. - omap_dss, which gets configured by the third patch in this set, fails to do 'dss_set_fck_rate(fck);' in drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to: | omapdss_dss: probe of omapdss_dss failed with error -22 | omapdss CORE error: Failed to initialize DSS platform driver | panel-dpi panel-dpi.0: failed to find video source 'dpi.0 Both regressions seem to have something to do with the clock framework. Could this be related to the DT clock conversion patches? [1]: http://thread.gmane.org/gmane.linux.ports.arm.omap/110095 -- 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: [BISECTED] OMAP: DSS: clk rate mismatch
On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote: > linux-next-20140124 DSS is broken on N900 - display stays black (there > is some noise though). I booted the kernel with qemu and it gives the > following warning: > > [0.623779] DSS: set fck to 17280 > [0.624237] [ cut here ] > [0.624298] WARNING: CPU: 0 PID: 1 at > drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c() > [0.624359] clk rate mismatch: 28800 != 17280 Here are also clock regressions since next-20140122 regarding dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a dm37xx100 board. Please see here: [PATCH v3 0/4] ARM: add omap3 INCOstartec board support http://thread.gmane.org/gmane.linux.ports.arm.omap/110095 Thanks -- chf -- 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: [BISECTED] OMAP: DSS: clk rate mismatch
On Mon, 2014-01-27 at 19:30 +0200, Ivaylo Dimitrov wrote: linux-next-20140124 DSS is broken on N900 - display stays black (there is some noise though). I booted the kernel with qemu and it gives the following warning: [0.623779] DSS: set fck to 17280 [0.624237] [ cut here ] [0.624298] WARNING: CPU: 0 PID: 1 at drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c() [0.624359] clk rate mismatch: 28800 != 17280 Here are also clock regressions since next-20140122 regarding dss_set_fck_rate() and sys_clkout2 occuring in my current patchset for a dm37xx100 board. Please see here: [PATCH v3 0/4] ARM: add omap3 INCOstartec board support http://thread.gmane.org/gmane.linux.ports.arm.omap/110095 Thanks -- chf -- 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] ipconfig: add nameserver IPs to kernel-parameter ip=
On Fri, 2012-09-21 at 14:51 -0400, David Miller wrote: > From: Christoph Fritz > Date: Fri, 21 Sep 2012 20:31:19 +0200 > > > On small systems (e.g. embedded ones) IP addresses are often configured > > by bootloaders and get assigned to kernel via parameter "ip=". If set to > > "ip=dhcp", even nameserver entries from DHCP daemons are handled. These > > entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf. > > > > To configure nameservers for networks without DHCP, this patch adds option > > and to kernel-parameter 'ip='. > > > > Signed-off-by: Christoph Fritz > > Tested-by: Jan Weitzel > > Applied to net-next, thanks. Thanks a lot for your reviews. -- Christoph -- 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] ipconfig: add nameserver IPs to kernel-parameter ip=
On small systems (e.g. embedded ones) IP addresses are often configured
by bootloaders and get assigned to kernel via parameter "ip=". If set to
"ip=dhcp", even nameserver entries from DHCP daemons are handled. These
entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
To configure nameservers for networks without DHCP, this patch adds option
and to kernel-parameter 'ip='.
Signed-off-by: Christoph Fritz
Tested-by: Jan Weitzel
---
v2: - fix indent
v3: - fix docu: add new arguments to option "ip="
---
Documentation/filesystems/nfs/nfsroot.txt | 10 ++-
net/ipv4/ipconfig.c | 39 ++--
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt
b/Documentation/filesystems/nfs/nfsroot.txt
index ffdd9d8..2d66ed6 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -78,7 +78,8 @@ nfsroot=[:][,]
flags = hard, nointr, noposix, cto, ac
-ip=::
+ip=:::
+ :
This parameter tells the kernel how to configure IP addresses of devices
and also how to set up the IP routing table. It was originally called
@@ -158,6 +159,13 @@
ip=::
Default: any
+ IP address of first nameserver.
+ Value gets exported by /proc/net/pnp which is often linked
+ on embedded systems by /etc/resolv.conf.
+
+ IP address of secound nameserver.
+ Same as above.
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 67e8a6b..1c0e7e0 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -743,14 +743,22 @@ static void __init ic_bootp_init_ext(u8 *e)
/*
- * Initialize the DHCP/BOOTP mechanism.
+ * Predefine Nameservers
*/
-static inline void __init ic_bootp_init(void)
+static inline void __init ic_nameservers_predef(void)
{
int i;
for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
ic_nameservers[i] = NONE;
+}
+
+/*
+ * Initialize the DHCP/BOOTP mechanism.
+ */
+static inline void __init ic_bootp_init(void)
+{
+ ic_nameservers_predef();
dev_add_pack(_packet_type);
}
@@ -1379,6 +1387,7 @@ static int __init ip_auto_config(void)
int retries = CONF_OPEN_RETRIES;
#endif
int err;
+ unsigned int i;
#ifdef CONFIG_PROC_FS
proc_net_fops_create(_net, "pnp", S_IRUGO, _seq_fops);
@@ -1499,7 +1508,15 @@ static int __init ip_auto_config(void)
_servaddr, _server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(", mtu=%d", ic_dev_mtu);
- pr_cont("\n");
+ for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE) {
+ pr_info(" nameserver%u=%pI4",
+ i, _nameservers[i]);
+ break;
+ }
+ for (i++; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE)
+ pr_cont(", nameserver%u=%pI4\n", i, _nameservers[i]);
#endif /* !SILENT */
return 0;
@@ -1570,6 +1587,8 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ ic_nameservers_predef();
+
/* Parse string for static IP assignment. */
ip = addrs;
while (ip && *ip) {
@@ -1613,6 +1632,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_enable = 0;
}
break;
+ case 7:
+ if (CONF_NAMESERVERS_MAX >= 1) {
+ ic_nameservers[0] = in_aton(ip);
+ if (ic_nameservers[0] == ANY)
+ ic_nameservers[0] = NONE;
+ }
+ break;
+ case 8:
+ if (CONF_NAMESERVERS_MAX >= 2) {
+ ic_nameservers[1] = in_aton(ip);
+ if (ic_nameservers[1] == ANY)
+ ic_nameservers[1] = NONE;
+ }
+ break;
}
}
ip = cp;
--
1.7.2.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] ipconfig: add nameserver IPs to kernel-parameter ip=
On small systems (e.g. embedded ones) IP addresses are often configured
by bootloaders and get assigned to kernel via parameter ip=. If set to
ip=dhcp, even nameserver entries from DHCP daemons are handled. These
entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
To configure nameservers for networks without DHCP, this patch adds option
dns0-ip and dns1-ip to kernel-parameter 'ip='.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
Tested-by: Jan Weitzel j.weit...@phytec.de
---
v2: - fix indent
v3: - fix docu: add new arguments to option ip=
---
Documentation/filesystems/nfs/nfsroot.txt | 10 ++-
net/ipv4/ipconfig.c | 39 ++--
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt
b/Documentation/filesystems/nfs/nfsroot.txt
index ffdd9d8..2d66ed6 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -78,7 +78,8 @@ nfsroot=[server-ip:]root-dir[,nfs-options]
flags = hard, nointr, noposix, cto, ac
-ip=client-ip:server-ip:gw-ip:netmask:hostname:device:autoconf
+ip=client-ip:server-ip:gw-ip:netmask:hostname:device:autoconf:
+ dns0-ip:dns1-ip
This parameter tells the kernel how to configure IP addresses of devices
and also how to set up the IP routing table. It was originally called
@@ -158,6 +159,13 @@
ip=client-ip:server-ip:gw-ip:netmask:hostname:device:autoconf
Default: any
+ dns0-ipIP address of first nameserver.
+ Value gets exported by /proc/net/pnp which is often linked
+ on embedded systems by /etc/resolv.conf.
+
+ dns1-ipIP address of secound nameserver.
+ Same as above.
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 67e8a6b..1c0e7e0 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -743,14 +743,22 @@ static void __init ic_bootp_init_ext(u8 *e)
/*
- * Initialize the DHCP/BOOTP mechanism.
+ * Predefine Nameservers
*/
-static inline void __init ic_bootp_init(void)
+static inline void __init ic_nameservers_predef(void)
{
int i;
for (i = 0; i CONF_NAMESERVERS_MAX; i++)
ic_nameservers[i] = NONE;
+}
+
+/*
+ * Initialize the DHCP/BOOTP mechanism.
+ */
+static inline void __init ic_bootp_init(void)
+{
+ ic_nameservers_predef();
dev_add_pack(bootp_packet_type);
}
@@ -1379,6 +1387,7 @@ static int __init ip_auto_config(void)
int retries = CONF_OPEN_RETRIES;
#endif
int err;
+ unsigned int i;
#ifdef CONFIG_PROC_FS
proc_net_fops_create(init_net, pnp, S_IRUGO, pnp_seq_fops);
@@ -1499,7 +1508,15 @@ static int __init ip_auto_config(void)
ic_servaddr, root_server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(, mtu=%d, ic_dev_mtu);
- pr_cont(\n);
+ for (i = 0; i CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE) {
+ pr_info( nameserver%u=%pI4,
+ i, ic_nameservers[i]);
+ break;
+ }
+ for (i++; i CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE)
+ pr_cont(, nameserver%u=%pI4\n, i, ic_nameservers[i]);
#endif /* !SILENT */
return 0;
@@ -1570,6 +1587,8 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ ic_nameservers_predef();
+
/* Parse string for static IP assignment. */
ip = addrs;
while (ip *ip) {
@@ -1613,6 +1632,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_enable = 0;
}
break;
+ case 7:
+ if (CONF_NAMESERVERS_MAX = 1) {
+ ic_nameservers[0] = in_aton(ip);
+ if (ic_nameservers[0] == ANY)
+ ic_nameservers[0] = NONE;
+ }
+ break;
+ case 8:
+ if (CONF_NAMESERVERS_MAX = 2) {
+ ic_nameservers[1] = in_aton(ip);
+ if (ic_nameservers[1] == ANY)
+ ic_nameservers[1] = NONE;
+ }
+ break;
}
}
ip = cp;
--
1.7.2.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
Re: [PATCH v3] ipconfig: add nameserver IPs to kernel-parameter ip=
On Fri, 2012-09-21 at 14:51 -0400, David Miller wrote: From: Christoph Fritz chf.fr...@googlemail.com Date: Fri, 21 Sep 2012 20:31:19 +0200 On small systems (e.g. embedded ones) IP addresses are often configured by bootloaders and get assigned to kernel via parameter ip=. If set to ip=dhcp, even nameserver entries from DHCP daemons are handled. These entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf. To configure nameservers for networks without DHCP, this patch adds option dns0-ip and dns1-ip to kernel-parameter 'ip='. Signed-off-by: Christoph Fritz chf.fr...@googlemail.com Tested-by: Jan Weitzel j.weit...@phytec.de Applied to net-next, thanks. Thanks a lot for your reviews. -- Christoph -- 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] ipconfig: add nameserver IPs to kernel-parameter ip=
On small systems (e.g. embedded ones) IP addresses are often configured
by bootloaders and get assigned to kernel via parameter "ip=". If set to
"ip=dhcp", even nameserver entries from DHCP daemons are handled. These
entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
To configure nameservers for networks without DHCP, this patch adds option
and to kernel-parameter 'ip='.
Signed-off-by: Christoph Fritz
Tested-by: Jan Weitzel
---
v2: - fix indent
---
Documentation/filesystems/nfs/nfsroot.txt |7 +
net/ipv4/ipconfig.c | 39 ++--
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt
b/Documentation/filesystems/nfs/nfsroot.txt
index ffdd9d8..4ed7875 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -158,6 +158,13 @@
ip=::
Default: any
+ IP address of first nameserver.
+ Value gets exported by /proc/net/pnp which is often linked
+ on embedded systems by /etc/resolv.conf.
+
+ IP address of secound nameserver.
+ Same as above.
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 67e8a6b..1c0e7e0 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -743,14 +743,22 @@ static void __init ic_bootp_init_ext(u8 *e)
/*
- * Initialize the DHCP/BOOTP mechanism.
+ * Predefine Nameservers
*/
-static inline void __init ic_bootp_init(void)
+static inline void __init ic_nameservers_predef(void)
{
int i;
for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
ic_nameservers[i] = NONE;
+}
+
+/*
+ * Initialize the DHCP/BOOTP mechanism.
+ */
+static inline void __init ic_bootp_init(void)
+{
+ ic_nameservers_predef();
dev_add_pack(_packet_type);
}
@@ -1379,6 +1387,7 @@ static int __init ip_auto_config(void)
int retries = CONF_OPEN_RETRIES;
#endif
int err;
+ unsigned int i;
#ifdef CONFIG_PROC_FS
proc_net_fops_create(_net, "pnp", S_IRUGO, _seq_fops);
@@ -1499,7 +1508,15 @@ static int __init ip_auto_config(void)
_servaddr, _server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(", mtu=%d", ic_dev_mtu);
- pr_cont("\n");
+ for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE) {
+ pr_info(" nameserver%u=%pI4",
+ i, _nameservers[i]);
+ break;
+ }
+ for (i++; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE)
+ pr_cont(", nameserver%u=%pI4\n", i, _nameservers[i]);
#endif /* !SILENT */
return 0;
@@ -1570,6 +1587,8 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ ic_nameservers_predef();
+
/* Parse string for static IP assignment. */
ip = addrs;
while (ip && *ip) {
@@ -1613,6 +1632,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_enable = 0;
}
break;
+ case 7:
+ if (CONF_NAMESERVERS_MAX >= 1) {
+ ic_nameservers[0] = in_aton(ip);
+ if (ic_nameservers[0] == ANY)
+ ic_nameservers[0] = NONE;
+ }
+ break;
+ case 8:
+ if (CONF_NAMESERVERS_MAX >= 2) {
+ ic_nameservers[1] = in_aton(ip);
+ if (ic_nameservers[1] == ANY)
+ ic_nameservers[1] = NONE;
+ }
+ break;
}
}
ip = cp;
--
1.7.2.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] ipconfig: add nameserver IPs to kernel-parameter ip=
On small systems (e.g. embedded ones) IP addresses are often configured
by bootloaders and get assigned to kernel via parameter "ip=". If set to
"ip=dhcp", even nameserver entries from DHCP daemons are handled. These
entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
To configure nameservers for networks without DHCP, this patch adds option
and to kernel-parameter 'ip='.
Signed-off-by: Christoph Fritz
Tested-by: Jan Weitzel
---
Documentation/filesystems/nfs/nfsroot.txt |7 +
net/ipv4/ipconfig.c | 39 ++--
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt
b/Documentation/filesystems/nfs/nfsroot.txt
index ffdd9d8..4ed7875 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -158,6 +158,13 @@
ip=::
Default: any
+ IP address of first nameserver.
+ Value gets exported by /proc/net/pnp which is often linked
+ on embedded systems by /etc/resolv.conf.
+
+ IP address of secound nameserver.
+ Same as above.
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 67e8a6b..bfbd61e 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -743,14 +743,22 @@ static void __init ic_bootp_init_ext(u8 *e)
/*
- * Initialize the DHCP/BOOTP mechanism.
+ * Predefine Nameservers
*/
-static inline void __init ic_bootp_init(void)
+static inline void __init ic_nameservers_predef(void)
{
int i;
for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
ic_nameservers[i] = NONE;
+}
+
+/*
+ * Initialize the DHCP/BOOTP mechanism.
+ */
+static inline void __init ic_bootp_init(void)
+{
+ ic_nameservers_predef();
dev_add_pack(_packet_type);
}
@@ -1379,6 +1387,7 @@ static int __init ip_auto_config(void)
int retries = CONF_OPEN_RETRIES;
#endif
int err;
+ unsigned int i;
#ifdef CONFIG_PROC_FS
proc_net_fops_create(_net, "pnp", S_IRUGO, _seq_fops);
@@ -1499,7 +1508,15 @@ static int __init ip_auto_config(void)
_servaddr, _server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(", mtu=%d", ic_dev_mtu);
- pr_cont("\n");
+ for (i = 0; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE) {
+ pr_info(" nameserver%u=%pI4",
+ i, _nameservers[i]);
+ break;
+ }
+ for (i++; i < CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE)
+ pr_cont(", nameserver%u=%pI4\n", i, _nameservers[i]);
#endif /* !SILENT */
return 0;
@@ -1570,6 +1587,8 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ ic_nameservers_predef();
+
/* Parse string for static IP assignment. */
ip = addrs;
while (ip && *ip) {
@@ -1613,6 +1632,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_enable = 0;
}
break;
+ case 7:
+ if (CONF_NAMESERVERS_MAX >= 1) {
+ ic_nameservers[0] = in_aton(ip);
+ if (ic_nameservers[0] == ANY)
+ ic_nameservers[0] = NONE;
+ }
+ break;
+ case 8:
+ if (CONF_NAMESERVERS_MAX >= 2) {
+ ic_nameservers[1] = in_aton(ip);
+ if (ic_nameservers[1] == ANY)
+ ic_nameservers[1] = NONE;
+ }
+ break;
}
}
ip = cp;
--
1.7.2.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] ipconfig: add nameserver IPs to kernel-parameter ip=
On small systems (e.g. embedded ones) IP addresses are often configured
by bootloaders and get assigned to kernel via parameter ip=. If set to
ip=dhcp, even nameserver entries from DHCP daemons are handled. These
entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
To configure nameservers for networks without DHCP, this patch adds option
dns0-ip and dns1-ip to kernel-parameter 'ip='.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
Tested-by: Jan Weitzel j.weit...@phytec.de
---
Documentation/filesystems/nfs/nfsroot.txt |7 +
net/ipv4/ipconfig.c | 39 ++--
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt
b/Documentation/filesystems/nfs/nfsroot.txt
index ffdd9d8..4ed7875 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -158,6 +158,13 @@
ip=client-ip:server-ip:gw-ip:netmask:hostname:device:autoconf
Default: any
+ dns0-ipIP address of first nameserver.
+ Value gets exported by /proc/net/pnp which is often linked
+ on embedded systems by /etc/resolv.conf.
+
+ dns1-ipIP address of secound nameserver.
+ Same as above.
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 67e8a6b..bfbd61e 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -743,14 +743,22 @@ static void __init ic_bootp_init_ext(u8 *e)
/*
- * Initialize the DHCP/BOOTP mechanism.
+ * Predefine Nameservers
*/
-static inline void __init ic_bootp_init(void)
+static inline void __init ic_nameservers_predef(void)
{
int i;
for (i = 0; i CONF_NAMESERVERS_MAX; i++)
ic_nameservers[i] = NONE;
+}
+
+/*
+ * Initialize the DHCP/BOOTP mechanism.
+ */
+static inline void __init ic_bootp_init(void)
+{
+ ic_nameservers_predef();
dev_add_pack(bootp_packet_type);
}
@@ -1379,6 +1387,7 @@ static int __init ip_auto_config(void)
int retries = CONF_OPEN_RETRIES;
#endif
int err;
+ unsigned int i;
#ifdef CONFIG_PROC_FS
proc_net_fops_create(init_net, pnp, S_IRUGO, pnp_seq_fops);
@@ -1499,7 +1508,15 @@ static int __init ip_auto_config(void)
ic_servaddr, root_server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(, mtu=%d, ic_dev_mtu);
- pr_cont(\n);
+ for (i = 0; i CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE) {
+ pr_info( nameserver%u=%pI4,
+ i, ic_nameservers[i]);
+ break;
+ }
+ for (i++; i CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE)
+ pr_cont(, nameserver%u=%pI4\n, i, ic_nameservers[i]);
#endif /* !SILENT */
return 0;
@@ -1570,6 +1587,8 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ ic_nameservers_predef();
+
/* Parse string for static IP assignment. */
ip = addrs;
while (ip *ip) {
@@ -1613,6 +1632,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_enable = 0;
}
break;
+ case 7:
+ if (CONF_NAMESERVERS_MAX = 1) {
+ ic_nameservers[0] = in_aton(ip);
+ if (ic_nameservers[0] == ANY)
+ ic_nameservers[0] = NONE;
+ }
+ break;
+ case 8:
+ if (CONF_NAMESERVERS_MAX = 2) {
+ ic_nameservers[1] = in_aton(ip);
+ if (ic_nameservers[1] == ANY)
+ ic_nameservers[1] = NONE;
+ }
+ break;
}
}
ip = cp;
--
1.7.2.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 v2] ipconfig: add nameserver IPs to kernel-parameter ip=
On small systems (e.g. embedded ones) IP addresses are often configured
by bootloaders and get assigned to kernel via parameter ip=. If set to
ip=dhcp, even nameserver entries from DHCP daemons are handled. These
entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
To configure nameservers for networks without DHCP, this patch adds option
dns0-ip and dns1-ip to kernel-parameter 'ip='.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
Tested-by: Jan Weitzel j.weit...@phytec.de
---
v2: - fix indent
---
Documentation/filesystems/nfs/nfsroot.txt |7 +
net/ipv4/ipconfig.c | 39 ++--
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/nfs/nfsroot.txt
b/Documentation/filesystems/nfs/nfsroot.txt
index ffdd9d8..4ed7875 100644
--- a/Documentation/filesystems/nfs/nfsroot.txt
+++ b/Documentation/filesystems/nfs/nfsroot.txt
@@ -158,6 +158,13 @@
ip=client-ip:server-ip:gw-ip:netmask:hostname:device:autoconf
Default: any
+ dns0-ipIP address of first nameserver.
+ Value gets exported by /proc/net/pnp which is often linked
+ on embedded systems by /etc/resolv.conf.
+
+ dns1-ipIP address of secound nameserver.
+ Same as above.
+
nfsrootdebug
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 67e8a6b..1c0e7e0 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -743,14 +743,22 @@ static void __init ic_bootp_init_ext(u8 *e)
/*
- * Initialize the DHCP/BOOTP mechanism.
+ * Predefine Nameservers
*/
-static inline void __init ic_bootp_init(void)
+static inline void __init ic_nameservers_predef(void)
{
int i;
for (i = 0; i CONF_NAMESERVERS_MAX; i++)
ic_nameservers[i] = NONE;
+}
+
+/*
+ * Initialize the DHCP/BOOTP mechanism.
+ */
+static inline void __init ic_bootp_init(void)
+{
+ ic_nameservers_predef();
dev_add_pack(bootp_packet_type);
}
@@ -1379,6 +1387,7 @@ static int __init ip_auto_config(void)
int retries = CONF_OPEN_RETRIES;
#endif
int err;
+ unsigned int i;
#ifdef CONFIG_PROC_FS
proc_net_fops_create(init_net, pnp, S_IRUGO, pnp_seq_fops);
@@ -1499,7 +1508,15 @@ static int __init ip_auto_config(void)
ic_servaddr, root_server_addr, root_server_path);
if (ic_dev_mtu)
pr_cont(, mtu=%d, ic_dev_mtu);
- pr_cont(\n);
+ for (i = 0; i CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE) {
+ pr_info( nameserver%u=%pI4,
+ i, ic_nameservers[i]);
+ break;
+ }
+ for (i++; i CONF_NAMESERVERS_MAX; i++)
+ if (ic_nameservers[i] != NONE)
+ pr_cont(, nameserver%u=%pI4\n, i, ic_nameservers[i]);
#endif /* !SILENT */
return 0;
@@ -1570,6 +1587,8 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+ ic_nameservers_predef();
+
/* Parse string for static IP assignment. */
ip = addrs;
while (ip *ip) {
@@ -1613,6 +1632,20 @@ static int __init ip_auto_config_setup(char *addrs)
ic_enable = 0;
}
break;
+ case 7:
+ if (CONF_NAMESERVERS_MAX = 1) {
+ ic_nameservers[0] = in_aton(ip);
+ if (ic_nameservers[0] == ANY)
+ ic_nameservers[0] = NONE;
+ }
+ break;
+ case 8:
+ if (CONF_NAMESERVERS_MAX = 2) {
+ ic_nameservers[1] = in_aton(ip);
+ if (ic_nameservers[1] == ANY)
+ ic_nameservers[1] = NONE;
+ }
+ break;
}
}
ip = cp;
--
1.7.2.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/
