* [PATCH v6 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Ding Tianhong @ 2017-01-06 3:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483594317-10732-1-git-send-email-dingtianhong@huawei.com>
Hi Marc, Will:
Please help reviewing the new version, I think it is nearly close to the final solution and it is very important to our chip or something else chip has similar erratum.
If there is any dissatisfaction, please inform me and I will fix it. :)
Thanks a lot.
Ding
On 2017/1/5 13:31, Ding Tianhong wrote:
> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
> potential to contain an erroneous value when the timer value changes".
> Accesses to TVAL (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
>
> The workaround is to reread the system count registers until the value of the second
> read is larger than the first one by less than 32, the system counter can be guaranteed
> not to return wrong value twice by back-to-back read and the error value is always larger
> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>
> v2: Introducing a new generic erratum handling mechanism for fsl,a008585 and hisilicon,161601.
> Significant rework based on feedback, including seperate the fsl erratum a008585
> to another patch, update the erratum name and remove unwanted code.
>
> v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> being globally visible. After discussion with Marc and Will, a consensus decision was
> made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> and make some generic name more specific, export timer_unstable_counter_workaround
> for module access.
>
> Significant rework based on feedback, including fix some alignment problem, make the
> #define __hisi_161601_read_reg to be private to the .c file instead of being globally
> visible, add more accurate annotation and modify a bit of logical format to enable
> arch_timer_read_ool_enabled, remove the kernel commandline parameter
> clocksource.arm_arch_timer.hisilicon-161601.
>
> Introduce a generic aquick framework for erratum in ACPI mode.
>
> v4: rename the quirk handler parameter to make it more generic, and
> avoid break loop when handling the quirk becasue it need to
> support multi quirks handler.
>
> update some data structures for acpi mode.
>
> v5: Adapt the new kernel-parameters.txt for latest kernel version.
> Set the retries of reread system counter to 50, because it is possible
> that some interrupts may lead to more than twice read errors and break the loop,
> it will trigger the warning, so we set the number of retries far beyond the number of
> iterations the loop has been observed to take.
>
> v6: The last 2 patches in the previous version about the ACPI mode will conflict witch Fuwei's
> GTDT patches, so remove the ACPI part and only support the DT base code for this patch set.
>
> We have trigger a bug when select the CONFIG_FUNCTION_GRAPH_TRACER and enable function_graph
> to /sys/kernel/debug/tracing/current_tracer, the system will stall into an endless loop, it looks
> like that the ftrace_graph_caller will be related to xxx.read_cntvct_el0 and read the system counter
> again, so mark the xxx.read_cntvct_el0 with notrace to fix the problem.
>
> Ding Tianhong (4):
> arm64: arch_timer: Add device tree binding for hisilicon-161601
> erratum
> arm64: arch_timer: Introduce a generic erratum handing mechanism for
> fsl-a008585
> arm64: arch_timer: Work around Erratum Hisilicon-161601
> arm64: arch timer: Add timer erratum property for Hip05-d02 and
> Hip06-d03
>
> Documentation/admin-guide/kernel-parameters.txt | 9 --
> Documentation/arm64/silicon-errata.txt | 1 +
> .../devicetree/bindings/arm/arch_timer.txt | 8 ++
> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
> arch/arm64/include/asm/arch_timer.h | 38 ++----
> drivers/clocksource/Kconfig | 9 ++
> drivers/clocksource/arm_arch_timer.c | 146 ++++++++++++++++-----
> 8 files changed, 143 insertions(+), 70 deletions(-)
>
^ permalink raw reply
* [PATCH 17/22] power: supply: add battery driver for AXP20X and AXP22X PMICs
From: Chen-Yu Tsai @ 2017-01-06 3:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-18-quentin.schulz@free-electrons.com>
Hi,
On Tue, Jan 3, 2017 at 12:37 AM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the battery power supply driver to get various data from
> the PMIC, such as the battery status (charging, discharging, full,
> dead), current max limit, current current, battery capacity (in
> percentage), voltage max and min limits, current voltage and battery
> capacity (in Ah).
>
> This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data
> provider.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/power/supply/Kconfig | 12 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/axp20x_battery.c | 458 ++++++++++++++++++++++++++++++++++
> 3 files changed, 471 insertions(+)
> create mode 100644 drivers/power/supply/axp20x_battery.c
>
> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> index c552b4b..48619de 100644
> --- a/drivers/power/supply/Kconfig
> +++ b/drivers/power/supply/Kconfig
> @@ -226,6 +226,18 @@ config CHARGER_AXP20X
> This driver can also be built as a module. If so, the module will be
> called axp20x_ac_power.
>
> +config BATTERY_AXP20X
> + tristate "X-Powers AXP20X battery driver"
> + depends on MFD_AXP20X
> + depends on AXP20X_ADC
> + depends on IIO
> + help
> + Say Y here to enable support for X-Powers AXP20X PMICs' battery power
> + supply.
> +
> + This driver can also be built as a module. If so, the module will be
> + called axp20x_battery.
> +
> config AXP288_CHARGER
> tristate "X-Powers AXP288 Charger"
> depends on MFD_AXP20X && EXTCON_AXP288
> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
> index 7d22417..5a217b2 100644
> --- a/drivers/power/supply/Makefile
> +++ b/drivers/power/supply/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_TEST_POWER) += test_power.o
>
> obj-$(CONFIG_BATTERY_88PM860X) += 88pm860x_battery.o
> obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o
> +obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o
> obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o
> obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
> obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o
> diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
> new file mode 100644
> index 0000000..e1d7b5f
> --- /dev/null
> +++ b/drivers/power/supply/axp20x_battery.c
> @@ -0,0 +1,458 @@
> +/*
> + * Battery power supply driver for X-Powers AXP20X and AXP22X PMICs
> + *
> + * Copyright 2016 Free Electrons NextThing Co.
> + * Quentin Schulz <quentin.schulz@free-electrons.com>
> + *
> + * This driver is based on a previous upstreaming attempt by:
> + * Bruno Pr?mont <bonbons@linux-vserver.org>
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License. See the file "COPYING" in the main directory of this
> + * archive for more details.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/power_supply.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/time.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/consumer.h>
> +#include <linux/mfd/axp20x.h>
> +
> +#define AXP20X_PWR_STATUS_BAT_CHARGING BIT(2)
> +
> +#define AXP20X_PWR_OP_BATT_PRESENT BIT(5)
> +#define AXP20X_PWR_OP_BATT_ACTIVATED BIT(3)
> +
> +#define AXP209_FG_PERCENT GENMASK(6, 0)
> +#define AXP22X_FG_VALID BIT(7)
> +
> +#define AXP20X_CHRG_CTRL1_TGT_VOLT GENMASK(6, 5)
> +#define AXP20X_CHRG_CTRL1_TGT_4_1V (0 << 5)
> +#define AXP20X_CHRG_CTRL1_TGT_4_15V BIT(5)
> +#define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5)
> +#define AXP20X_CHRG_CTRL1_TGT_4_36V (3 << 5)
> +#define AXP20X_CHRG_CTRL1_TGT_CURR GENMASK(3, 0)
> +
> +#define AXP22X_CHRG_CTRL1_TGT_4_22V BIT(5)
> +#define AXP22X_CHRG_CTRL1_TGT_4_24V (3 << 5)
> +
> +#define AXP20X_V_OFF_MASK GENMASK(2, 0)
> +
> +struct axp20x_batt_ps {
> + struct regmap *regmap;
> + struct power_supply *batt;
> + struct axp20x_dev *axp20x;
> + struct iio_channel *batt_chrg_i;
> + struct iio_channel *batt_dischrg_i;
> + struct iio_channel *batt_v;
> + u8 axp_id;
> +};
> +
> +static int axp20x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> + int *val)
> +{
> + int ret, reg;
> +
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
> + if (ret)
> + return ret;
> +
> + switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
> + case AXP20X_CHRG_CTRL1_TGT_4_1V:
> + *val = 4100000;
> + break;
> + case AXP20X_CHRG_CTRL1_TGT_4_15V:
> + *val = 4150000;
> + break;
> + case AXP20X_CHRG_CTRL1_TGT_4_2V:
> + *val = 4200000;
> + break;
> + case AXP20X_CHRG_CTRL1_TGT_4_36V:
> + *val = 4360000;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int axp22x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> + int *val)
> +{
> + int ret, reg;
> +
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
> + if (ret)
> + return ret;
> +
> + switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
> + case AXP20X_CHRG_CTRL1_TGT_4_1V:
> + *val = 4100000;
> + break;
> + case AXP20X_CHRG_CTRL1_TGT_4_2V:
> + *val = 4200000;
> + break;
> + case AXP22X_CHRG_CTRL1_TGT_4_22V:
> + *val = 4220000;
> + break;
> + case AXP22X_CHRG_CTRL1_TGT_4_24V:
> + *val = 4240000;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int axp20x_battery_get_prop(struct power_supply *psy,
> + enum power_supply_property psp,
> + union power_supply_propval *val)
> +{
> + struct axp20x_batt_ps *axp20x_batt = power_supply_get_drvdata(psy);
> + struct iio_channel *chan;
> + int ret = 0, reg, val1;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_PRESENT:
> + case POWER_SUPPLY_PROP_ONLINE:
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_OP_MODE,
> + ®);
> + if (ret)
> + return ret;
> +
> + val->intval = !!(reg & AXP20X_PWR_OP_BATT_PRESENT);
> + break;
> +
> + case POWER_SUPPLY_PROP_STATUS:
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_INPUT_STATUS,
> + ®);
> + if (ret)
> + return ret;
> +
> + if (reg & AXP20X_PWR_STATUS_BAT_CHARGING) {
> + val->intval = POWER_SUPPLY_STATUS_CHARGING;
> + return 0;
> + }
> +
> + ret = iio_read_channel_processed(axp20x_batt->batt_dischrg_i,
> + &val1);
> + if (ret)
> + return ret;
> +
> + if (val1) {
> + val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
> + return 0;
> + }
> +
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_FG_RES, &val1);
> + if (ret)
> + return ret;
> +
> + /*
> + * Fuel Gauge data takes 7 bits but the stored value seems to be
> + * directly the raw percentage without any scaling to 7 bits.
> + */
> + if ((val1 & AXP209_FG_PERCENT) == 100)
> + val->intval = POWER_SUPPLY_STATUS_FULL;
> + else
> + val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
> + break;
> +
> + case POWER_SUPPLY_PROP_HEALTH:
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_OP_MODE,
> + &val1);
> + if (ret)
> + return ret;
> +
> + if (val1 & AXP20X_PWR_OP_BATT_ACTIVATED) {
> + val->intval = POWER_SUPPLY_HEALTH_DEAD;
> + return 0;
> + }
> +
> + val->intval = POWER_SUPPLY_HEALTH_GOOD;
> + break;
> +
> + case POWER_SUPPLY_PROP_CURRENT_MAX:
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
> + if (ret)
> + return ret;
> +
> + reg &= AXP20X_CHRG_CTRL1_TGT_CURR;
> + val->intval = reg * 100000 + 300000;
> + break;
This controls the charge current. I believe the correct property to use
is CONSTANT_CHARGE_CURRENT. And you should add CONSTANT_CHARGE_CURRENT_MAX
which returns the highest possible setting.
Also letting the user control this might not always be a good idea.
IIUC, LiPo batteries can only be charged at 1C, where C is the
rated capacity (X mAh).
> +
> + case POWER_SUPPLY_PROP_CURRENT_NOW:
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_INPUT_STATUS,
> + ®);
> + if (ret)
> + return ret;
> +
> + if (reg & AXP20X_PWR_STATUS_BAT_CHARGING)
> + chan = axp20x_batt->batt_chrg_i;
> + else
> + chan = axp20x_batt->batt_dischrg_i;
> +
> + ret = iio_read_channel_processed(chan, &val->intval);
> + if (ret)
> + return ret;
> +
> + /*
> + * IIO framework gives mV but Power Supply framework gives ?V.
> + */
> + val->intval *= 1000;
> + break;
> +
> + case POWER_SUPPLY_PROP_CAPACITY:
> + /* When no battery is present, return capacity is 100% */
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_OP_MODE,
> + ®);
> + if (ret)
> + return ret;
> +
> + if (!(reg & AXP20X_PWR_OP_BATT_PRESENT)) {
> + val->intval = 100;
> + return 0;
> + }
> +
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_FG_RES, ®);
> + if (ret)
> + return ret;
> +
> + if (axp20x_batt->axp_id == AXP221_ID &&
> + !(reg & AXP22X_FG_VALID))
> + return -EINVAL;
> +
> + /*
> + * Fuel Gauge data takes 7 bits but the stored value seems to be
> + * directly the raw percentage without any scaling to 7 bits.
> + */
> + val->intval = reg & AXP209_FG_PERCENT;
> + break;
> +
> + case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
> + if (axp20x_batt->axp_id == AXP209_ID)
> + return axp20x_battery_get_max_voltage(axp20x_batt,
> + &val->intval);
> + return axp22x_battery_get_max_voltage(axp20x_batt,
> + &val->intval);
> +
> + case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_V_OFF, ®);
> + if (ret)
> + return ret;
> +
> + val->intval = 2600000 + 100000 * (reg & AXP20X_V_OFF_MASK);
> + break;
> +
> + case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> + ret = iio_read_channel_processed(axp20x_batt->batt_v,
> + &val->intval);
> + if (ret)
> + return ret;
> +
> + /*
> + * IIO framework gives mV but Power Supply framework gives ?V.
> + */
> + val->intval *= 1000;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int axp20x_battery_set_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> + int val)
> +{
> + switch (val) {
> + case 4100000:
> + return regmap_update_bits(axp20x_batt->regmap,
> + AXP20X_CHRG_CTRL1,
> + AXP20X_CHRG_CTRL1_TGT_VOLT,
> + AXP20X_CHRG_CTRL1_TGT_4_1V);
> + case 4150000:
> + if (axp20x_batt->axp_id == AXP221_ID)
> + return -EINVAL;
> +
> + return regmap_update_bits(axp20x_batt->regmap,
> + AXP20X_CHRG_CTRL1,
> + AXP20X_CHRG_CTRL1_TGT_VOLT,
> + AXP20X_CHRG_CTRL1_TGT_4_15V);
> + case 4200000:
> + return regmap_update_bits(axp20x_batt->regmap,
> + AXP20X_CHRG_CTRL1,
> + AXP20X_CHRG_CTRL1_TGT_VOLT,
> + AXP20X_CHRG_CTRL1_TGT_4_2V);
> + default:
> + /*
> + * AXP20x max voltage can be set to 4.36V and AXP22X max voltage
> + * can be set to 4.22V and 4.24V, but these voltages are too
> + * high for Lithium based batteries (AXP PMICs are supposed to
> + * be used with these kinds of battery).
> + */
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int axp20x_battery_set_prop(struct power_supply *psy,
> + enum power_supply_property psp,
> + const union power_supply_propval *val)
> +{
> + struct axp20x_batt_ps *axp20x_batt = power_supply_get_drvdata(psy);
> + int ret = 0, val1;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
> + val1 = (val->intval - 2600000) / 100000;
> + if (val1 < 0 || val1 > AXP20X_V_OFF_MASK)
> + return -EINVAL;
> +
> + return regmap_update_bits(axp20x_batt->regmap, AXP20X_V_OFF,
> + AXP20X_V_OFF_MASK, val1);
> +
> + case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
> + return axp20x_battery_set_max_voltage(axp20x_batt, val->intval);
> +
> + case POWER_SUPPLY_PROP_CURRENT_MAX:
> + if (axp20x_batt->axp_id == AXP209_ID)
> + val1 = (val->intval - 300000) / 100000;
> + else
> + val1 = (val->intval - 300000) / 150000;
> +
> + if (val1 > AXP20X_CHRG_CTRL1_TGT_CURR || val1 < 0)
> + return -EINVAL;
> +
> + return regmap_update_bits(axp20x_batt->regmap,
> + AXP20X_CHRG_CTRL1,
> + AXP20X_CHRG_CTRL1_TGT_CURR, val1);
> +
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static enum power_supply_property axp20x_battery_props[] = {
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_ONLINE,
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> + POWER_SUPPLY_PROP_CURRENT_MAX,
> + POWER_SUPPLY_PROP_HEALTH,
> + POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
> + POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
> + POWER_SUPPLY_PROP_CAPACITY,
You can also add POWER_SUPPLY_PROP_TECHNOLOGY, which would return
POWER_SUPPLY_TECHNOLOGY_LIPO.
It is also possible to do POWER_SUPPLY_PROP_CHARGE_TYPE. According
to the manual, if the battery is charging, it is in constant current
mode (POWER_SUPPLY_CHARGE_TYPE_FAST) when V_battery < V_target.
When V_battery == V_target, it is in constant voltage mode, though
I don't think this is the same as POWER_SUPPLY_CHARGE_TYPE_TRICKLE.
When it is not charging, you can return POWER_SUPPLY_CHARGE_TYPE_NONE.
Regards
ChenYu
> +};
> +
> +static int axp20x_battery_prop_writeable(struct power_supply *psy,
> + enum power_supply_property psp)
> +{
> + return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN ||
> + psp == POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN ||
> + psp == POWER_SUPPLY_PROP_CURRENT_MAX;
> +}
> +
> +static const struct power_supply_desc axp20x_batt_ps_desc = {
> + .name = "axp20x-battery",
> + .type = POWER_SUPPLY_TYPE_BATTERY,
> + .properties = axp20x_battery_props,
> + .num_properties = ARRAY_SIZE(axp20x_battery_props),
> + .property_is_writeable = axp20x_battery_prop_writeable,
> + .get_property = axp20x_battery_get_prop,
> + .set_property = axp20x_battery_set_prop,
> +};
> +
> +static const struct of_device_id axp20x_battery_ps_id[] = {
> + {
> + .compatible = "x-powers,axp209-battery-power-supply",
> + .data = (void *)AXP209_ID,
> + }, {
> + .compatible = "x-powers,axp221-battery-power-supply",
> + .data = (void *)AXP221_ID,
> + }, { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, axp20x_battery_ps_id);
> +
> +static int axp20x_power_probe(struct platform_device *pdev)
> +{
> + struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> + struct axp20x_batt_ps *axp20x_batt;
> + struct power_supply_config psy_cfg = {};
> +
> + axp20x_batt = devm_kzalloc(&pdev->dev, sizeof(*axp20x_batt),
> + GFP_KERNEL);
> + if (!axp20x_batt)
> + return -ENOMEM;
> +
> + axp20x_batt->batt_v = devm_iio_channel_get(&pdev->dev, "batt_v");
> + if (IS_ERR(axp20x_batt->batt_v)) {
> + if (PTR_ERR(axp20x_batt->batt_v) == -ENODEV)
> + return -EPROBE_DEFER;
> + return PTR_ERR(axp20x_batt->batt_v);
> + }
> +
> + axp20x_batt->batt_chrg_i = devm_iio_channel_get(&pdev->dev,
> + "batt_chrg_i");
> + if (IS_ERR(axp20x_batt->batt_chrg_i)) {
> + if (PTR_ERR(axp20x_batt->batt_chrg_i) == -ENODEV)
> + return -EPROBE_DEFER;
> + return PTR_ERR(axp20x_batt->batt_chrg_i);
> + }
> +
> + axp20x_batt->batt_dischrg_i = devm_iio_channel_get(&pdev->dev,
> + "batt_dischrg_i");
> + if (IS_ERR(axp20x_batt->batt_dischrg_i)) {
> + if (PTR_ERR(axp20x_batt->batt_dischrg_i) == -ENODEV)
> + return -EPROBE_DEFER;
> + return PTR_ERR(axp20x_batt->batt_dischrg_i);
> + }
> +
> + axp20x_batt->regmap = axp20x->regmap;
> + platform_set_drvdata(pdev, axp20x_batt);
> +
> + psy_cfg.drv_data = axp20x_batt;
> + psy_cfg.of_node = pdev->dev.of_node;
> +
> + axp20x_batt->axp_id = (int)of_device_get_match_data(&pdev->dev);
> +
> + axp20x_batt->batt = devm_power_supply_register(&pdev->dev,
> + &axp20x_batt_ps_desc,
> + &psy_cfg);
> + return PTR_ERR_OR_ZERO(axp20x_batt->batt);
> +}
> +
> +static struct platform_driver axp20x_batt_driver = {
> + .probe = axp20x_power_probe,
> + .driver = {
> + .name = "axp20x-battery-power-supply",
> + .of_match_table = axp20x_battery_ps_id,
> + },
> +};
> +
> +module_platform_driver(axp20x_batt_driver);
> +
> +MODULE_DESCRIPTION("Battery power supply driver for AXP20X and AXP22X PMICs");
> +MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
> +MODULE_LICENSE("GPL");
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH V2 0/2] kexec-tools: arm64: Enable D-cache in purgatory
From: Pratyush Anand @ 2017-01-06 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1482129830.git.panand@redhat.com>
Hi James and All,
Any feedback/review comment on it?
~Pratyush
On Monday 19 December 2016 12:43 PM, Pratyush Anand wrote:
> It takes more that 2 minutes to verify SHA in purgatory when vmlinuz image
> is around 13MB and initramfs is around 30MB. It takes more than 20 second
> even when we have -O2 optimization enabled. However, if dcache is enabled
> during purgatory execution then, it takes just a second in SHA
> verification.
>
> Therefore, these patches adds support for dcache enabling facility during
> purgatory execution.
>
> Although I have simplified the logic a bit now, however I understand that
> there are reservations for introducing this complexity for gaining few
> seconding of execution time during kexec or crash reboot. But, I believe
> if d-cache enabling code is stable enough then there should not be any
> hindrances to accept it. So, please give it a try with your platform and
> let me know if you see any issue or it does not work. I am still open to
> improve it further if needed.
>
> Changes since V1:
> - Moved page table creation logic from purgatory to kexec code.
> - Only 4K page table is supported, with 48 bit VA and 2M block size
> - if platform supports a 4K page size, then D-cache is always
> enabled now.
>
> Pratyush Anand (2):
> kexec: arm64: create identity page table to be used in purgatory
> arm64: enable d-cache support during purgatory sha verification
>
> kexec/arch/arm64/kexec-arm64.c | 152 ++++++++++++++++++
> purgatory/arch/arm64/Makefile | 1 +
> purgatory/arch/arm64/cache.S | 281 +++++++++++++++++++++++++++++++++
> purgatory/arch/arm64/purgatory-arm64.c | 5 +
> 4 files changed, 439 insertions(+)
> create mode 100644 purgatory/arch/arm64/cache.S
>
^ permalink raw reply
* [PATCH v29 0/9] arm64: add kdump support
From: Pratyush Anand @ 2017-01-06 3:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043347.27358-1-takahiro.akashi@linaro.org>
On Wednesday 28 December 2016 10:03 AM, AKASHI Takahiro wrote:
> This patch series adds kdump support on arm64.
>
> To load a crash-dump kernel to the systems, a series of patches to
> kexec-tools[1] are also needed. Please use the latest one, v4 [2].
> For your convinience, you can pick them up from:
> https://git.linaro.org/people/takahiro.akashi/linux-aarch64.git arm64/kdump
> https://git.linaro.org/people/takahiro.akashi/kexec-tools.git arm64/kdump
>
> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
> - crash utility (v7.1.7 or later) [3]
> (As of today, the very latest tree cannot handle a core image correctly
> due to the commit 7fd8329ba502 ("taint/module: Clean up global and module
> taint flags handling")
>
>
> The previous version, v27, was also:
> Tested-by: Pratyush Anand <panand@redhat.com> (mustang and seattle)
You have my "Tested-by" for this version as well :-). Patches works
great after applying them over v4.10-rc2.
I used crash-utility from below where there are few patches queued for
crash-7.1.8
https://github.com/crash-utility/crash
~Pratyush
^ permalink raw reply
* [RESEND] spi: davinci: Allow device tree devices to use DMA
From: David Lechner @ 2017-01-06 3:26 UTC (permalink / raw)
To: linux-arm-kernel
This allows SPI devices specified in a device tree to use DMA when the
master controller.
Since device tree is supposed to only describe the hardware, adding such
a configuration option to device tree would not be acceptable. So, this
is the best we can do for now to get SPI devices working with DMA.
Unfortunately, this excludes the possibility of using one SPI device with
DMA and one without on the same master.
Signed-off-by: David Lechner <david@lechnology.com>
---
When I originally submitted this patch, there was some discussion as to whether
dspi->dma_rx should be changed to return an error rather than being null.
However, I prefer it the way it is and don't see a compelling reason to change
it.
drivers/spi/spi-davinci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index d36c11b..c6cf73a 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -388,6 +388,7 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
static int davinci_spi_of_setup(struct spi_device *spi)
{
struct davinci_spi_config *spicfg = spi->controller_data;
+ struct davinci_spi *dspi = spi_master_get_devdata(spi->master);
struct device_node *np = spi->dev.of_node;
u32 prop;
@@ -400,6 +401,9 @@ static int davinci_spi_of_setup(struct spi_device *spi)
if (!of_property_read_u32(np, "ti,spi-wdelay", &prop))
spicfg->wdelay = (u8)prop;
spi->controller_data = spicfg;
+ /* Use DMA for device if master supports it */
+ if (dspi->dma_rx)
+ spicfg->io_type = SPI_IO_TYPE_DMA;
}
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 17/22] power: supply: add battery driver for AXP20X and AXP22X PMICs
From: Sebastian Reichel @ 2017-01-06 2:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAEAJfBeu7Z_JeM55Tyj4a2ZOxNWhq7qoPDwFyftoO8sCumVQw@mail.gmail.com>
Hi,
On Thu, Jan 05, 2017 at 02:34:48PM -0300, Ezequiel Garcia wrote:
> > +static int axp20x_power_probe(struct platform_device *pdev)
> > +{
> > + struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> > + struct axp20x_batt_ps *axp20x_batt;
> > + struct power_supply_config psy_cfg = {};
> > +
>
> To be consistent with the AC power supply and USB power supply,
> you might want to call of_device_is_available() here.
> Otherwise, the device probes even if "disabled" in the DTS.
I would expect that check in the mfd code. Probe should not be
called at all if the sub-device is disabled.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170106/306245c1/attachment.sig>
^ permalink raw reply
* [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Rick Chang @ 2017-01-06 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479894203.8964.29.camel@mtksdaap41>
Hi Hans,
The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
any idea about this patch series? Should we wait for [2] or we could merge
the source code and dt-binding first?
Best Regards,
Rick
On Wed, 2016-11-23 at 17:43 +0800, Rick Chang wrote:
> On Wed, 2016-11-23 at 09:54 +0800, Rick Chang wrote:
> > Hi Hans,
> >
> > On Tue, 2016-11-22 at 13:43 +0100, Hans Verkuil wrote:
> > > On 22/11/16 04:21, Rick Chang wrote:
> > > > Hi Hans,
> > > >
> > > > On Mon, 2016-11-21 at 15:51 +0100, Hans Verkuil wrote:
> > > >> On 17/11/16 04:38, Rick Chang wrote:
> > > >>> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> > > >>> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> > > >>> ---
> > > >>> This patch depends on:
> > > >>> CCF "Add clock support for Mediatek MT2701"[1]
> > > >>> iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
> > > >>>
> > > >>> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
> > > >>> [2] https://patchwork.kernel.org/patch/9164013/
> > > >>
> > > >> I assume that 1 & 2 will appear in 4.10? So this patch needs to go in
> > > >> after the
> > > >> other two are merged in 4.10?
> > > >>
> > > >> Regards,
> > > >>
> > > >> Hans
> > > >
> > > > [1] will appear in 4.10, but [2] will appear latter than 4.10.So this
> > > > patch needs to go in after [1] & [2] will be merged in 4.11.
> > >
> > > So what should I do? Merge the driver for 4.11 and wait with this patch
> > > until [2] is merged in 4.11? Does that sound reasonable?
> > >
> > > Regards,
> > >
> > > Hans
> >
> > What do you think about this? You merge the driver first and I send this
> > patch again after [1] & [2] is merged.
>
> BTW, to prevent merging conflict, the dtsi should be merged by mediatek
> SoC maintainer, Matthias.I think we can only take care on the driver
> part at this moment.
>
^ permalink raw reply
* [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433
From: Andi Shyti @ 2017-01-06 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105200807.54j2ebve6kqd5bob@kozik-lap>
Hi Krzysztof,
> Andi,
> Please fix missing Signed-off-by and resend with Linus' tags for #1 and
> #2 and with other accumulated tags.
patch #1 has already been merged in mainline:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1259feddd0f83649d5c48d730c140b4f7f3fa288
and patch #2 is in LinusW's -next branch.
does it still make sense to send them again? If you want I can
send again patch 3 and 4 as independent patches with Chanwoo's
review (the only tags).
Thanks,
Andi
^ permalink raw reply
* [PATCH v2,7/9] irqchip/ls-scfg-msi: add LS1046a MSI support
From: M.H. Lian @ 2017-01-06 1:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7cd3cc33-741a-6ab1-6444-17a626991d33@arm.com>
Hi Marc,
Thanks for your review.
Please see my comments inline.
Thanks,
Minghuan
> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> Sent: Thursday, January 05, 2017 11:19 PM
> To: M.H. Lian <minghuan.lian@nxp.com>; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>; Jason Cooper
> <jason@lakedaemon.net>; Roy Zang <roy.zang@nxp.com>; Mingkai Hu
> <mingkai.hu@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
> <leoyang.li@nxp.com>; Scott Wood <scott.wood@nxp.com>
> Subject: Re: [PATCH v2,7/9] irqchip/ls-scfg-msi: add LS1046a MSI support
>
> On 05/01/17 08:10, Minghuan Lian wrote:
> > LS1046a includes 4 MSIRs, each MSIR is assigned a dedicate GIC SPI
> > interrupt and provides 32 MSI interrupts. Compared to previous MSI,
> > LS1046a's IBS(interrupt bit select) shift is changed to 2 and total
> > MSI interrupt number is changed to 128.
> >
> > The patch adds structure 'ls_scfg_msir' to describe MSIR setting and
> > 'ibs_shift' to store the different value between the SoCs.
> >
> > Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> > ---
> > v2-v1:
> > - MSI dts node change has been merged into the patch 6/9
> >
> > drivers/irqchip/irq-ls-scfg-msi.c | 161
> > +++++++++++++++++++++++++++++---------
> > 1 file changed, 126 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-ls-scfg-msi.c
> > b/drivers/irqchip/irq-ls-scfg-msi.c
> > index cef67cc..67547bd 100644
> > --- a/drivers/irqchip/irq-ls-scfg-msi.c
> > +++ b/drivers/irqchip/irq-ls-scfg-msi.c
> > @@ -17,13 +17,24 @@
> > #include <linux/irq.h>
> > #include <linux/irqchip/chained_irq.h> #include <linux/irqdomain.h>
> > +#include <linux/of_irq.h>
> > #include <linux/of_pci.h>
> > #include <linux/of_platform.h>
> > #include <linux/spinlock.h>
> >
> > -#define MSI_MAX_IRQS 32
> > -#define MSI_IBS_SHIFT 3
> > -#define MSIR 4
> > +#define MSI_IRQS_PER_MSIR 32
> > +#define MSI_MSIR_OFFSET 4
> > +
> > +struct ls_scfg_msi_cfg {
> > + u32 ibs_shift; /* Shift of interrupt bit select */ };
> > +
> > +struct ls_scfg_msir {
> > + struct ls_scfg_msi *msi_data;
> > + unsigned int index;
> > + unsigned int gic_irq;
> > + void __iomem *reg;
> > +};
> >
> > struct ls_scfg_msi {
> > spinlock_t lock;
> > @@ -32,8 +43,11 @@ struct ls_scfg_msi {
> > struct irq_domain *msi_domain;
> > void __iomem *regs;
> > phys_addr_t msiir_addr;
> > - int irq;
> > - DECLARE_BITMAP(used, MSI_MAX_IRQS);
> > + struct ls_scfg_msi_cfg *cfg;
> > + u32 msir_num;
> > + struct ls_scfg_msir *msir;
> > + u32 irqs_num;
> > + unsigned long *used;
> > };
> >
> > static struct irq_chip ls_scfg_msi_irq_chip = { @@ -55,7 +69,7 @@
> > static void ls_scfg_msi_compose_msg(struct irq_data *data, struct
> > msi_msg *msg)
> >
> > msg->address_hi = upper_32_bits(msi_data->msiir_addr);
> > msg->address_lo = lower_32_bits(msi_data->msiir_addr);
> > - msg->data = data->hwirq << MSI_IBS_SHIFT;
> > + msg->data = data->hwirq;
> > }
> >
> > static int ls_scfg_msi_set_affinity(struct irq_data *irq_data, @@
> > -81,8 +95,8 @@ static int ls_scfg_msi_domain_irq_alloc(struct irq_domain
> *domain,
> > WARN_ON(nr_irqs != 1);
> >
> > spin_lock(&msi_data->lock);
> > - pos = find_first_zero_bit(msi_data->used, MSI_MAX_IRQS);
> > - if (pos < MSI_MAX_IRQS)
> > + pos = find_first_zero_bit(msi_data->used, msi_data->irqs_num);
> > + if (pos < msi_data->irqs_num)
> > __set_bit(pos, msi_data->used);
> > else
> > err = -ENOSPC;
> > @@ -106,7 +120,7 @@ static void ls_scfg_msi_domain_irq_free(struct
> irq_domain *domain,
> > int pos;
> >
> > pos = d->hwirq;
> > - if (pos < 0 || pos >= MSI_MAX_IRQS) {
> > + if (pos < 0 || pos >= msi_data->irqs_num) {
> > pr_err("failed to teardown msi. Invalid hwirq %d\n", pos);
> > return;
> > }
> > @@ -123,15 +137,17 @@ static void ls_scfg_msi_domain_irq_free(struct
> > irq_domain *domain,
> >
> > static void ls_scfg_msi_irq_handler(struct irq_desc *desc) {
> > - struct ls_scfg_msi *msi_data = irq_desc_get_handler_data(desc);
> > + struct ls_scfg_msir *msir = irq_desc_get_handler_data(desc);
> > + struct ls_scfg_msi *msi_data = msir->msi_data;
> > unsigned long val;
> > - int pos, virq;
> > + int pos, virq, hwirq;
> >
> > chained_irq_enter(irq_desc_get_chip(desc), desc);
> >
> > - val = ioread32be(msi_data->regs + MSIR);
> > - for_each_set_bit(pos, &val, MSI_MAX_IRQS) {
> > - virq = irq_find_mapping(msi_data->parent, (31 - pos));
> > + val = ioread32be(msir->reg);
> > + for_each_set_bit(pos, &val, MSI_IRQS_PER_MSIR) {
> > + hwirq = ((31 - pos) << msi_data->cfg->ibs_shift) | msir-
> >index;
> > + virq = irq_find_mapping(msi_data->parent, hwirq);
> > if (virq)
> > generic_handle_irq(virq);
> > }
> > @@ -143,7 +159,7 @@ static int ls_scfg_msi_domains_init(struct
> > ls_scfg_msi *msi_data) {
> > /* Initialize MSI domain parent */
> > msi_data->parent = irq_domain_add_linear(NULL,
> > - MSI_MAX_IRQS,
> > + msi_data->irqs_num,
> > &ls_scfg_msi_domain_ops,
> > msi_data);
> > if (!msi_data->parent) {
> > @@ -164,16 +180,83 @@ static int ls_scfg_msi_domains_init(struct
> ls_scfg_msi *msi_data)
> > return 0;
> > }
> >
> > +static int ls_scfg_msi_setup_hwirq(struct ls_scfg_msi *msi_data, int
> > +index) {
> > + struct ls_scfg_msir *msir;
> > + int virq, i, hwirq;
> > +
> > + virq = platform_get_irq(msi_data->pdev, index);
> > + if (virq <= 0)
> > + return -ENODEV;
> > +
> > + msir = &msi_data->msir[index];
> > + msir->index = index;
> > + msir->msi_data = msi_data;
> > + msir->gic_irq = virq;
> > + msir->reg = msi_data->regs + MSI_MSIR_OFFSET + 4 * index;
> > +
> > + irq_set_chained_handler_and_data(msir->gic_irq,
> > + ls_scfg_msi_irq_handler,
> > + msir);
> > +
> > + /* Release the hwirqs corresponding to this MSIR */
> > + for (i = 0; i < MSI_IRQS_PER_MSIR; i++) {
> > + hwirq = i << msi_data->cfg->ibs_shift | msir->index;
> > + bitmap_clear(msi_data->used, hwirq, 1);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int ls_scfg_msi_teardown_hwirq(struct ls_scfg_msir *msir) {
> > + struct ls_scfg_msi *msi_data = msir->msi_data;
> > + int i, hwirq;
> > +
> > + if (msir->gic_irq > 0)
> > + irq_set_chained_handler_and_data(msir->gic_irq, NULL,
> NULL);
> > +
> > + for (i = 0; i < MSI_IRQS_PER_MSIR; i++) {
> > + hwirq = i << msi_data->cfg->ibs_shift | msir->index;
> > + bitmap_set(msi_data->used, hwirq, 1);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static struct ls_scfg_msi_cfg ls1021_msi_cfg = {
> > + .ibs_shift = 3,
> > +};
> > +
> > +static struct ls_scfg_msi_cfg ls1046_msi_cfg = {
> > + .ibs_shift = 2,
> > +};
> > +
> > +static const struct of_device_id ls_scfg_msi_id[] = {
> > + { .compatible = "fsl,ls1021a-msi", .data = &ls1021_msi_cfg },
> > + { .compatible = "fsl,ls1043a-msi", .data = &ls1021_msi_cfg },
> > + { .compatible = "fsl,ls1046a-msi", .data = &ls1046_msi_cfg },
>
> So after 3 patches adding compatibility between the fsl,1s10 and
> fsl,ls10 names, you discard them? How does it work again with the old DTs?
>
[Minghuan Lian] ok, I will store the old compatible.
This typo makes me very uncomfortable :(
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, ls_scfg_msi_id);
> > +
> > static int ls_scfg_msi_probe(struct platform_device *pdev) {
> > + const struct of_device_id *match;
> > struct ls_scfg_msi *msi_data;
> > struct resource *res;
> > - int ret;
> > + int i, ret;
> > +
> > + match = of_match_device(ls_scfg_msi_id, &pdev->dev);
> > + if (!match)
> > + return -ENODEV;
> >
> > msi_data = devm_kzalloc(&pdev->dev, sizeof(*msi_data),
> GFP_KERNEL);
> > if (!msi_data)
> > return -ENOMEM;
> >
> > + msi_data->cfg = (struct ls_scfg_msi_cfg *) match->data;
> > +
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > msi_data->regs = devm_ioremap_resource(&pdev->dev, res);
> > if (IS_ERR(msi_data->regs)) {
> > @@ -182,23 +265,37 @@ static int ls_scfg_msi_probe(struct
> platform_device *pdev)
> > }
> > msi_data->msiir_addr = res->start;
> >
> > - msi_data->irq = platform_get_irq(pdev, 0);
> > - if (msi_data->irq <= 0) {
> > - dev_err(&pdev->dev, "failed to get MSI irq\n");
> > - return -ENODEV;
> > - }
> > -
> > msi_data->pdev = pdev;
> > spin_lock_init(&msi_data->lock);
> >
> > + msi_data->irqs_num = MSI_IRQS_PER_MSIR *
> > + (1 << msi_data->cfg->ibs_shift);
> > + msi_data->used = devm_kcalloc(&pdev->dev,
> > + BITS_TO_LONGS(msi_data->irqs_num),
> > + sizeof(*msi_data->used),
> > + GFP_KERNEL);
> > + if (!msi_data->used)
> > + return -ENOMEM;
> > + /*
> > + * Reserve all the hwirqs
> > + * The available hwirqs will be released in ls1_msi_setup_hwirq()
> > + */
> > + bitmap_set(msi_data->used, 0, msi_data->irqs_num);
> > +
> > + msi_data->msir_num = of_irq_count(pdev->dev.of_node);
> > + msi_data->msir = devm_kcalloc(&pdev->dev, msi_data->msir_num,
> > + sizeof(*msi_data->msir),
> > + GFP_KERNEL);
> > + if (!msi_data->msir)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < msi_data->msir_num; i++)
> > + ls_scfg_msi_setup_hwirq(msi_data, i);
> > +
> > ret = ls_scfg_msi_domains_init(msi_data);
> > if (ret)
> > return ret;
> >
> > - irq_set_chained_handler_and_data(msi_data->irq,
> > - ls_scfg_msi_irq_handler,
> > - msi_data);
> > -
> > platform_set_drvdata(pdev, msi_data);
> >
> > return 0;
> > @@ -207,8 +304,10 @@ static int ls_scfg_msi_probe(struct
> > platform_device *pdev) static int ls_scfg_msi_remove(struct
> > platform_device *pdev) {
> > struct ls_scfg_msi *msi_data = platform_get_drvdata(pdev);
> > + int i;
> >
> > - irq_set_chained_handler_and_data(msi_data->irq, NULL, NULL);
> > + for (i = 0; i < msi_data->msir_num; i++)
> > + ls_scfg_msi_teardown_hwirq(&msi_data->msir[i]);
> >
> > irq_domain_remove(msi_data->msi_domain);
> > irq_domain_remove(msi_data->parent);
> > @@ -218,14 +317,6 @@ static int ls_scfg_msi_remove(struct
> platform_device *pdev)
> > return 0;
> > }
> >
> > -static const struct of_device_id ls_scfg_msi_id[] = {
> > - { .compatible = "fsl,1s1021a-msi", }, /* a typo */
> > - { .compatible = "fsl,1s1043a-msi", }, /* a typo */
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^
> these entries definitely need to be restored.
>
> Also, please make sure you have a cover letter at the beginning of the series.
> I flag series to review by flagging the cover letter, and I suspect many of us
> are doing something similar. Not doing so is likely to leave your series
> unreviewed...
[Minghuan Lian] I see. I will add cover letter for this series. And I will
do this for all series of patches.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 10/19] media: Add i.MX media core driver
From: Steve Longerbeam @ 2017-01-06 1:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c04a85dc-4f62-798f-2e37-d7848657730a@mentor.com>
On 01/04/2017 05:33 AM, Vladimir Zapolskiy wrote:
> Hi Steve,
>
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> Add the core media driver for i.MX SOC.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> Documentation/devicetree/bindings/media/imx.txt | 205 +++++
> v2 was sent before getting Rob's review comments, but still they
> should be addressed in v3.
yes, those changes will be part of v3 as well.
>
> Also I would suggest to separate device tree binding documentation
> change and place it as the first patch in the series, this should
> make the following DTS changes valid.
done.
>
>> Documentation/media/v4l-drivers/imx.rst | 430 ++++++++++
>> drivers/staging/media/Kconfig | 2 +
>> drivers/staging/media/Makefile | 1 +
>> drivers/staging/media/imx/Kconfig | 8 +
>> drivers/staging/media/imx/Makefile | 6 +
>> drivers/staging/media/imx/TODO | 18 +
>> drivers/staging/media/imx/imx-media-common.c | 985 ++++++++++++++++++++++
>> drivers/staging/media/imx/imx-media-dev.c | 479 +++++++++++
>> drivers/staging/media/imx/imx-media-fim.c | 509 +++++++++++
>> drivers/staging/media/imx/imx-media-internal-sd.c | 457 ++++++++++
>> drivers/staging/media/imx/imx-media-of.c | 291 +++++++
>> drivers/staging/media/imx/imx-media-of.h | 25 +
>> drivers/staging/media/imx/imx-media.h | 299 +++++++
>> include/media/imx.h | 15 +
>> include/uapi/Kbuild | 1 +
>> include/uapi/linux/v4l2-controls.h | 4 +
>> include/uapi/media/Kbuild | 2 +
>> include/uapi/media/imx.h | 30 +
> Probably Greg should ack the UAPI changes, you may consider
> to split them into a separate patch.
I split out the one-line addition to include/uapi/Kbuild with an empty
include/uapi/media/Kbuild into a new patch "UAPI: Add media UAPI Kbuild
file".
Also added a patch "media: Add userspace header file for i.MX".
>
>
>> +
>> +struct imx_media_subdev *
>> +imx_media_find_subdev_by_sd(struct imx_media_dev *imxmd,
>> + struct v4l2_subdev *sd)
>> +{
>> + struct imx_media_subdev *imxsd;
>> + int i, ret = -ENODEV;
>> +
>> + for (i = 0; i < imxmd->num_subdevs; i++) {
>> + imxsd = &imxmd->subdev[i];
>> + if (sd == imxsd->sd) {
> This can be simplifed:
>
> ...
>
> if (sd == imxsd->sd)
> return imxsd;
> }
>
> return ERR_PTR(-ENODEV);
yep, done.
>
>> +struct imx_media_subdev *
>> +imx_media_find_subdev_by_id(struct imx_media_dev *imxmd, u32 grp_id)
>> +{
>> + struct imx_media_subdev *imxsd;
>> + int i, ret = -ENODEV;
>> +
>> + for (i = 0; i < imxmd->num_subdevs; i++) {
>> + imxsd = &imxmd->subdev[i];
>> + if (imxsd->sd && imxsd->sd->grp_id == grp_id) {
>> + ret = 0;
>> + break;
> This can be simplifed:
>
> ...
>
> if (imxsd->sd && imxsd->sd->grp_id == grp_i)
> return imxsd;
> }
>
> return ERR_PTR(-ENODEV);
done.
>
>
>> diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c
>> new file mode 100644
>> index 0000000..8d22730
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-media-dev.c
>> @@ -0,0 +1,479 @@
>> +/*
>> + * V4L2 Media Controller Driver for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2016 Mentor Graphics Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <linux/of_platform.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/v4l2-ctrls.h>
>> +#include <media/v4l2-event.h>
>> +#include <media/v4l2-mc.h>
> Please sort out the list of headers alphabetically.
done.
>> +#include <video/imx-ipu-v3.h>
>> +#include <media/imx.h>
>> +#include "imx-media.h"
>> +#include "imx-media-of.h"
>> +
>> +#define DEVICE_NAME "imx-media"
> I suppose you don't need this macro.
sure why not, removed.
>
> [snip]
>
>> + */
>> +static int imx_media_create_links(struct imx_media_dev *imxmd)
>> +{
>> + struct imx_media_subdev *local_sd;
>> + struct imx_media_subdev *remote_sd;
>> + struct v4l2_subdev *source, *sink;
>> + struct imx_media_link *link;
>> + struct imx_media_pad *pad;
>> + u16 source_pad, sink_pad;
>> + int num_pads, i, j, k;
>> + int ret = 0;
>> +
>> + for (i = 0; i < imxmd->num_subdevs; i++) {
>> + local_sd = &imxmd->subdev[i];
>> + num_pads = local_sd->num_sink_pads + local_sd->num_src_pads;
>> +
>> + for (j = 0; j < num_pads; j++) {
>> + pad = &local_sd->pad[j];
>> +
>> + for (k = 0; k < pad->num_links; k++) {
>> + link = &pad->link[k];
>> +
>> <snip>
> Indentation depth is quite terrific.
yes, it needs to iterate by subdev, pads in the subdev, then links
in the pad. But I moved the code under the innermost loop into a
function imx_media_create_link(), which creates a single media
link. So it's not so much an eye-sore now.
>
>
>> +static struct platform_driver imx_media_pdrv = {
>> + .probe = imx_media_probe,
>> + .remove = imx_media_remove,
>> + .driver = {
>> + .name = DEVICE_NAME,
>> + .owner = THIS_MODULE,
> Setting of .owner is not needed nowadays IIRC.
a quick look at struct device_driver definition didn't mention that
.owner member is deprecated or not needed, so for now I'll leave
it in place. We can revisit that later.
>
>> + .of_match_table = imx_media_dt_ids,
>> + },
>> +};
>> +
>> +module_platform_driver(imx_media_pdrv);
>> +
>> +MODULE_DESCRIPTION("i.MX5/6 v4l2 media controller driver");
>> +MODULE_AUTHOR("Steve Longerbeam <steve_longerbeam@mentor.com>");
>> +MODULE_LICENSE("GPL");
>> diff --git a/drivers/staging/media/imx/imx-media-fim.c b/drivers/staging/media/imx/imx-media-fim.c
>> new file mode 100644
>> index 0000000..52bfa8d
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-media-fim.c
>> @@ -0,0 +1,509 @@
>> +/*
>> + * Frame Interval Monitor.
>> + *
>> + * Copyright (c) 2016 Mentor Graphics Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/slab.h>
>> +#include <linux/platform_device.h>
>> +#ifdef CONFIG_IMX_GPT_ICAP
>> +#include <linux/mxc_icap.h>
>> +#endif
> This looks clumsy. Include it unconditionally, if needed
> do #ifdef's inside the header file.
The i.MX input capture patch will come later. These are just
placeholders until then, the config name could even change.
For now I just removed the above conditional include.
>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort out the list alphabetically.
done.
>> + if (IS_ENABLED(CONFIG_IMX_GPT_ICAP)) {
>> + ret = of_property_read_u32_array(fim_np,
>> + "input-capture-channel",
>> + icap, 2);
>> + if (!ret) {
>> + fim->icap_channel = icap[0];
>> + fim->icap_flags = icap[1];
>> + }
> Should you return error otherwise?
nope, it's an optional property.
>
>> diff --git a/drivers/staging/media/imx/imx-media-of.c b/drivers/staging/media/imx/imx-media-of.c
>> new file mode 100644
>> index 0000000..018d05a
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-media-of.c
>> @@ -0,0 +1,291 @@
>> +/*
>> + * Media driver for Freescale i.MX5/6 SOC
>> + *
>> + * Open Firmware parsing.
>> + *
>> + * Copyright (c) 2016 Mentor Graphics Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include <linux/of_platform.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort out the list alphabetically.
done.
>>
>> +static int of_get_port_count(const struct device_node *np)
>> +{
>> + struct device_node *child;
>> + int num = 0;
>> +
>> + /* if this node is itself a port, return 1 */
>> + if (of_node_cmp(np->name, "port") == 0)
>> + return 1;
>> +
>> + for_each_child_of_node(np, child) {
>> + if (of_node_cmp(child->name, "port") == 0)
>> + num++;
>> + }
> Unneeded bracers.
fixed.
>
>> +static struct imx_media_subdev *
>> +of_parse_subdev(struct imx_media_dev *imxmd, struct device_node *sd_np,
>> + bool is_csi_port)
>> +{
>> + struct imx_media_subdev *imxsd;
>> + int i, num_pads, ret;
>> +
>> + if (!of_device_is_available(sd_np)) {
>> + dev_dbg(imxmd->dev, "%s: %s not enabled\n", __func__,
>> + sd_np->name);
>> + return NULL;
>> + }
>> +
>> + /* register this subdev with async notifier */
>> + imxsd = imx_media_add_async_subdev(imxmd, sd_np, NULL);
>> + if (!imxsd)
>> + return NULL;
>> + if (IS_ERR(imxsd))
>> + return imxsd;
> if (IS_ERR_OR_NULL(imxsd))
> return imxsd;
yep, done.
>> +
>> + if (imxsd->num_sink_pads == 0) {
>> + /* this might be a sensor */
>> + of_parse_sensor(imxmd, imxsd, sd_np);
>> + }
> Unneeded bracers.
ok removed.
>
>> +
>> + for (i = 0; i < num_pads; i++) {
>> + struct device_node *epnode = NULL, *port, *remote_np;
>> + struct imx_media_subdev *remote_imxsd;
>> + struct imx_media_pad *pad;
>> + int remote_pad;
> Too deep indentation, may be move the cycle body into a separate function?
in this case I prefer not to, of_parse_subdev() is called recursively, and I
think it's bad form to hide that fact by moving the recursive call into a
separate function. The indentation is not that deep, only two loops deep.
>
>> +
>> + /* init this pad */
>> + pad = &imxsd->pad[i];
>> + pad->pad.flags = (i < imxsd->num_sink_pads) ?
>> + MEDIA_PAD_FL_SINK : MEDIA_PAD_FL_SOURCE;
>> +
>> + if (is_csi_port)
>> + port = (i < imxsd->num_sink_pads) ? sd_np : NULL;
>> + else
>> + port = of_graph_get_port_by_id(sd_np, i);
>> + if (!port)
>> + continue;
>> +
>> + while ((epnode = of_get_next_child(port, epnode))) {
> Please reuse for_each_child_of_node() here.
done.
>
>> + of_get_remote_pad(epnode, &remote_np, &remote_pad);
>> + if (!remote_np) {
>> + of_node_put(epnode);
> Please remove of_node_put() here, of_get_next_child() does it.
oops, good catch, fixed.
>
>> + continue;
>> + }
>> +
>> + ret = of_add_pad_link(imxmd, pad, sd_np, remote_np,
>> + i, remote_pad);
>> + if (ret) {
>> + imxsd = ERR_PTR(ret);
>> + break;
>> + }
>> +
>> + if (i < imxsd->num_sink_pads) {
>> + /* follow sink endpoints upstream */
>> + remote_imxsd = of_parse_subdev(imxmd,
>> + remote_np,
>> + false);
>> + if (IS_ERR(remote_imxsd)) {
>> + imxsd = remote_imxsd;
>> + break;
>> + }
>> + }
>> +
>> + of_node_put(remote_np);
>> + of_node_put(epnode);
also removed this put of epnode.
>>
>> +
>> +int imx_media_of_parse(struct imx_media_dev *imxmd,
>> + struct imx_media_subdev *(*csi)[4],
>> + struct device_node *np)
>> +{
>> + struct device_node *csi_np;
>> + struct imx_media_subdev *lcsi;
> Please swap two lines above to get the reverse christmas tree ordering.
done.
>
>> + u32 ipu_id, csi_id;
>> + int i, ret;
>> +
>> + for (i = 0; ; i++) {
>> + csi_np = of_parse_phandle(np, "ports", i);
>> + if (!csi_np)
>> + break;
>> +
>> + lcsi = of_parse_subdev(imxmd, csi_np, true);
>> + if (IS_ERR(lcsi)) {
>> + ret = PTR_ERR(lcsi);
>> + goto err_put;
>> + }
>> +
>> + of_property_read_u32(csi_np, "reg", &csi_id);
> Not sure if it is safe enough to ignore return value and potentially
> left csi_id uninitialized.
The CSI nodes are port nodes, and the reg property is required,
so I added a check and error return here.
>
>> + ipu_id = of_alias_get_id(csi_np->parent, "ipu");
>> +
>> + if (ipu_id > 1 || csi_id > 1) {
>> + dev_err(imxmd->dev, "%s: invalid ipu/csi id (%u/%u)\n",
>> + __func__, ipu_id, csi_id);
>> + ret = -EINVAL;
>> + goto err_put;
>> + }
>> +
>> + of_node_put(csi_np);
> You can put the node right after of_alias_get_id() call, then in case
> of error return right from the if block and remove the goto label.
done.
>
>> +
>> + (*csi)[ipu_id * 2 + csi_id] = lcsi;
>> + }
>> +
>> + return 0;
>> +err_put:
>> + of_node_put(csi_np);
>> + return ret;
>> +}
>> diff --git a/drivers/staging/media/imx/imx-media-of.h b/drivers/staging/media/imx/imx-media-of.h
>> new file mode 100644
>> index 0000000..0c61b05
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-media-of.h
>> @@ -0,0 +1,25 @@
>> +/*
>> + * V4L2 Media Controller Driver for Freescale i.MX5/6 SOC
>> + *
>> + * Open Firmware parsing.
>> + *
>> + * Copyright (c) 2016 Mentor Graphics Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#ifndef _IMX_MEDIA_OF_H
>> +#define _IMX_MEDIA_OF_H
>> +
> I do believe you should include some headers or add declarations
> of "struct imx_media_dev", "struct imx_media_subdev", "struct device_node".
actually imx-media-of.h isn't really needed, I just moved those prototypes
into imx-media.h and removed imx-media-of.h.
>> diff --git a/drivers/staging/media/imx/imx-media.h b/drivers/staging/media/imx/imx-media.h
>> new file mode 100644
>> index 0000000..6a018a9
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-media.h
>> @@ -0,0 +1,299 @@
>> +/*
>> + * V4L2 Media Controller Driver for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2016 Mentor Graphics Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#ifndef _IMX_MEDIA_H
>> +#define _IMX_MEDIA_H
> Please insert here an empty line to improve readability.
done.
>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-ctrls.h>
>> +#include <media/v4l2-of.h>
> Please sort out the list alphabetically.
done.
Steve
^ permalink raw reply
* [PATCH v2 9/9] ARM: sunxi: Convert pinctrl nodes to generic bindings
From: André Przywara @ 2017-01-06 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105153556.pzec5jjuz7pmvsmn@lukather>
On 05/01/17 15:35, Maxime Ripard wrote:
Hi Maxime,
> On Wed, Jan 04, 2017 at 02:16:23AM +0000, Andr? Przywara wrote:
>> So can I ask that we start taking this seriously and stop doing things
>> which prevent Allwinner boards from being supported properly?
>> Which would first involve dropping this very patch?
>
> The driver still supports the old binding.
Yes, a _current_ version of the driver supports both bindings, but older
versions *require* the older binding and bail out if various
allwinner,xxx properties are missing - as in those proposed new DTs:
4.9 kernel with sunxi/for-next .dtb:
sun8i-h3-pinctrl 1c20800.pinctrl: missing allwinner,function property in
node uart0
sun8i-h3-pinctrl 1c20800.pinctrl: missing allwinner,function property in
node mmc0
sunxi-mmc: probe of 1c0f000.mmc failed with error -22
>> Having done breakage in the past (with "allwinner,sun7i-a20-mmc", for
>> instance) is no excuse for doing it again.
>
> I'm not sure which breakage we introduced with a new compatible: the
> old compatible is working just like it used to, and the new one is
> working like we need it to.
But the new compatible is not recognized with older kernels, preventing
people from using the newest DT with older kernels as well.
I proposed to simply work around this by using the old compatible as a
fallback: compatible="sun7i-a20-mmc", "sun5i-a13-mmc";
Unfortunately this suggestion was not followed.
So now we can't boot a 4.8 (or earlier) kernel with a .dtb from a 4.9 or
later tree. Adding the extra string would fix this.
Actually the recommended approach to avoid this situation in the first
place is to always use compatible strings with the SoC-specific name as
the first string, followed by the compatible string the driver works
with. And this should be done upon introducing a new DT to the tree -
even if at this point the driver doesn't deal with the new string.
Unknown strings will just be skipped.
So for instance the H5 DT should read: "sun50i-h5-mmc",
"sun50i-a64-mmc", "sun5i-a13-mmc"; (with the last string possibly being
optional). The current kernel driver will not match the h5 string, so it
falls back to the a64 string and works. If we learn about a neat eMMC
5.1 feature (or any quirk the H5 can benefit from) somewhere in the
future, we can add the code together with this h5 string to the driver
and don't need to change the DT at all.
>> And especially I want to avoid this habit creeping into the arm64
>> world (thinking about the H5 here, which may be impacted by this
>> very patch, for instance).
>
> And again, if you looked at the entire serie, you would have seen that
> I took this into account.
I saw that and I appreciate that very much, but that post was not about
keeping compatibility with older DTs, but allowing older kernels to run
with the latest DT as well.
Newer DTs from your -next branch do not work with older kernels - that
is what my whole post was about. _Why_ we should care is explained there.
And please don't get me wrong: I am not asking for rewriting and bending
the whole kernel source to make this possible, it's just that we drop
this patch here, for instance, or simply not _change_ compatible names,
but instead add new strings.
Cheers,
Andre.
^ permalink raw reply
* [PATCH v3] arm64: mm: Fix NOMAP page initialization
From: Hanjun Guo @ 2017-01-06 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c74d6ec6-16ba-dccc-3b0d-a8bedcb46dc5@linaro.org>
On 2017/1/5 10:03, Hanjun Guo wrote:
> On 2017/1/4 21:56, Ard Biesheuvel wrote:
>> On 16 December 2016 at 16:54, Robert Richter <rrichter@cavium.com> wrote:
>>> On ThunderX systems with certain memory configurations we see the
>>> following BUG_ON():
>>>
>>> kernel BUG at mm/page_alloc.c:1848!
>>>
>>> This happens for some configs with 64k page size enabled. The BUG_ON()
>>> checks if start and end page of a memmap range belongs to the same
>>> zone.
>>>
>>> The BUG_ON() check fails if a memory zone contains NOMAP regions. In
>>> this case the node information of those pages is not initialized. This
>>> causes an inconsistency of the page links with wrong zone and node
>>> information for that pages. NOMAP pages from node 1 still point to the
>>> mem zone from node 0 and have the wrong nid assigned.
>>>
>>> The reason for the mis-configuration is a change in pfn_valid() which
>>> reports pages marked NOMAP as invalid:
>>>
>>> 68709f45385a arm64: only consider memblocks with NOMAP cleared for
>>> linear mapping
>>>
>>> This causes pages marked as nomap being no longer reassigned to the
>>> new zone in memmap_init_zone() by calling __init_single_pfn().
>>>
>>> Fixing this by implementing an arm64 specific early_pfn_valid(). This
>>> causes all pages of sections with memory including NOMAP ranges to be
>>> initialized by __init_single_page() and ensures consistency of page
>>> links to zone, node and section.
>>>
>>
>> I like this solution a lot better than the first one, but I am still
>> somewhat uneasy about having the kernel reason about attributes of
>> pages it should not touch in the first place. But the fact that
>> early_pfn_valid() is only used a single time in the whole kernel does
>> give some confidence that we are not simply moving the problem
>> elsewhere.
>>
>> Given that you are touching arch/arm/ as well as arch/arm64, could you
>> explain why only arm64 needs this treatment? Is it simply because we
>> don't have NUMA support there?
>>
>> Considering that Hisilicon D05 suffered from the same issue, I would
>> like to get some coverage there as well. Hanjun, is this something you
>> can arrange? Thanks
>
> Sure, we will test this patch with LTP MM stress test (which triggers
> the bug on D05), and give the feedback.
a update here, tested on 4.9,
- Applied Ard's two patches only
- Applied Robert's patch only
Both of them can work fine on D05 with NUMA enabled, which means
boot ok and LTP MM stress test is passed.
I'm not familiar with memory management, it's up to you guys to make
a decision :)
Thanks
Hanjun
^ permalink raw reply
* [RESEND 2/2] arm64: dts: Add dts files for Hisilicon Hi3660 SoC
From: Chen Feng @ 2017-01-06 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105141456.GA5710@hector.attlocal.net>
On 2017/1/5 22:14, Andy Gross wrote:
> On Mon, Dec 26, 2016 at 05:36:12PM +0800, Chen Feng wrote:
>> Add initial dtsi file to support Hisilicon Hi3660 SoC with
>> support of Octal core CPUs in two clusters(4 * A53 & 4 * A73).
>>
>> Also add dts file to support HiKey960 development board which
>> based on Hi3660 SoC.
>> The output console is earlycon "earlycon=pl011,0xfdf05000".
>> And the con_init uart5 with a fixed clock, which already
>> configured at bootloader.
>>
>> When clock is available, the uart5 will be modified.
>>
>> Tested on HiKey960 Board.
>>
>> Signed-off-by: Chen Feng <puck.chen@hisilicon.com>
>> ---
>> arch/arm64/boot/dts/hisilicon/Makefile | 1 +
>> arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 34 +++++
>> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 156 ++++++++++++++++++++++
>> 3 files changed, 191 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> create mode 100644 arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/Makefile b/arch/arm64/boot/dts/hisilicon/Makefile
>> index d5f43a0..b633b5d 100644
>> --- a/arch/arm64/boot/dts/hisilicon/Makefile
>> +++ b/arch/arm64/boot/dts/hisilicon/Makefile
>> @@ -1,4 +1,5 @@
>> dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
>> +dtb-$(CONFIG_ARCH_HISI) += hi3660-hikey960.dtb
>> dtb-$(CONFIG_ARCH_HISI) += hip05-d02.dtb
>> dtb-$(CONFIG_ARCH_HISI) += hip06-d03.dtb
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> new file mode 100644
>> index 0000000..3d7aead
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>> @@ -0,0 +1,34 @@
>> +/*
>> + * dts file for Hisilicon HiKey960 Development Board
>> + *
>> + * Copyright (C) 2016, Hisilicon Ltd.
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "hi3660.dtsi"
>> +
>> +/ {
>> + model = "HiKey960";
>> + compatible = "hisilicon,hi3660";
>> +
>> + aliases {
>> + serial5 = &uart5; /* console UART */
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial5:115200n8";
>> + };
>> +
>> + memory at 0 {
>> + device_type = "memory";
>> + reg = <0x0 0x00400000 0x0 0xBFE00000>;
>
> Use lower case letters for hex numbers. 0xbfe00000.
>
ok, thanks!
>> + };
>> +
>> + soc {
>> + uart5: uart at fdf05000 {
>> + status = "ok";
>> + };
>> + };
>> +};
>
> <snip>
>
> Regards,
>
> Andy
>
> .
>
^ permalink raw reply
* [nomadik:lis3lv02 5/6] warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_SPI_3AXIS which has unmet direct dependencies (IIO && ..)
From: kbuild test robot @ 2017-01-06 0:43 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git lis3lv02
head: e343deae8006a1fc109534497c943eab51a1c2a8
commit: 0a9710dd480b06b6fefefdedc732020f2297e247 [5/6] iio: accel: st_accel: handle deprecated bindings
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0a9710dd480b06b6fefefdedc732020f2297e247
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All warnings (new ones prefixed by >>):
warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_SPI_3AXIS which has unmet direct dependencies (IIO && !SENSORS_LIS3_SPI && IIO_ST_ACCEL_3AXIS && IIO_ST_SENSORS_SPI)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 51856 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170106/9cb0f0b3/attachment-0001.gz>
^ permalink raw reply
* [PATCHv2 2/2] arm: Adjust memory boundaries after reservations
From: Russell King - ARM Linux @ 2017-01-06 0:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483657274-11346-3-git-send-email-labbott@redhat.com>
Only comments are to do with the comments...
On Thu, Jan 05, 2017 at 03:01:14PM -0800, Laura Abbott wrote:
>
> adjust_lowmem_bounds is responsible for setting up the boundary for
> lowmem/hihgmme. This needs to be setup before memblock reservations can
highmem
> occur. At the time memblock reservations can occur, memory can also be
> removed from the system. The lowmem/highmem boundary and end of memory
> may be affected by this but it is currently not recalculated. On some
> systems this may be harmless, on o thers this may result in incorrect
others
> ranges being passed to the main memory allocator. Correct this by
> recalculating the lowmem/highmem boundary after all reservations have
> been made.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v2: Rebased for changes in sanity_check_meminfo cleanup
> ---
> arch/arm/kernel/setup.c | 8 ++++++++
> arch/arm/mm/mmu.c | 9 ++++++---
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8a8051c..4625115 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -1093,8 +1093,16 @@ void __init setup_arch(char **cmdline_p)
> setup_dma_zone(mdesc);
> xen_early_init();
> efi_init();
> + /*
> + * Make sure the calcualtion for lowmem/highmem is set appropriately
calculation
> + * before reserving/allocating any mmeory
> + */
> adjust_lowmem_bounds();
> arm_memblock_init(mdesc);
> + /*
> + * Memory may have been removed so recalculate the bounds.
> + */
Single line comments should be... /* blah */
> + adjust_lowmem_bounds();
>
> early_ioremap_reset();
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index ce5123b..7ca6910 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1157,6 +1157,7 @@ void __init adjust_lowmem_bounds(void)
> phys_addr_t memblock_limit = 0;
> u64 vmalloc_limit;
> struct memblock_region *reg;
> + phys_addr_t lowmem_limit = 0;
>
> /*
> * Let's use our own (unoptimized) equivalent of __pa() that is
> @@ -1173,14 +1174,14 @@ void __init adjust_lowmem_bounds(void)
>
>
> if (reg->base < vmalloc_limit) {
> - if (block_end > arm_lowmem_limit)
> + if (block_end > lowmem_limit)
> /*
> * Compare as u64 to ensure vmalloc_limit does
> * not get truncated. block_end should always
> * fit in phys_addr_t so there should be no
> * issue with assignment.
> */
> - arm_lowmem_limit = min_t(u64,
> + lowmem_limit = min_t(u64,
> vmalloc_limit,
> block_end);
>
> @@ -1201,12 +1202,14 @@ void __init adjust_lowmem_bounds(void)
> if (!IS_ALIGNED(block_start, PMD_SIZE))
> memblock_limit = block_start;
> else if (!IS_ALIGNED(block_end, PMD_SIZE))
> - memblock_limit = arm_lowmem_limit;
> + memblock_limit = lowmem_limit;
> }
>
> }
> }
>
> + arm_lowmem_limit = lowmem_limit;
> +
> high_memory = __va(arm_lowmem_limit - 1) + 1;
>
> /*
> --
> 2.7.4
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Russell King - ARM Linux @ 2017-01-06 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-4-f.fainelli@gmail.com>
On Thu, Jan 05, 2017 at 11:29:52AM -0800, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
> dsa: Document new binding"). The legacy binding node is kept included, but is
> marked disabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Booted here on clearfog, and tested traffic passes between two lan
ports, and a lan port and the cpu port... and generally still seems
to work as a switch. All seems well on the face of it.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
> ---
> arch/arm/boot/dts/armada-388-clearfog.dts | 65 +++++++++++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
> index 71ce201c903e..40ec6d768669 100644
> --- a/arch/arm/boot/dts/armada-388-clearfog.dts
> +++ b/arch/arm/boot/dts/armada-388-clearfog.dts
> @@ -351,6 +351,8 @@
> };
>
> dsa at 0 {
> + status = "disabled";
> +
> compatible = "marvell,dsa";
> dsa,ethernet = <ð1>;
> dsa,mii-bus = <&mdio>;
> @@ -444,3 +446,66 @@
> status = "disabled";
> };
> };
> +
> +&mdio {
> + status = "okay";
> +
> + switch at 4 {
> + compatible = "marvell,mv88e6085";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <4>;
> + pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
> + pinctrl-names = "default";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + label = "lan5";
> + };
> +
> + port at 1 {
> + reg = <1>;
> + label = "lan4";
> + };
> +
> + port at 2 {
> + reg = <2>;
> + label = "lan3";
> + };
> +
> + port at 3 {
> + reg = <3>;
> + label = "lan2";
> + };
> +
> + port at 4 {
> + reg = <4>;
> + label = "lan1";
> + };
> +
> + port at 5 {
> + reg = <5>;
> + label = "cpu";
> + ethernet = <ð1>;
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> +
> + port at 6 {
> + /* 88E1512 external phy */
> + reg = <6>;
> + label = "lan6";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> +};
> --
> 2.9.3
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 2/5] drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
From: André Przywara @ 2017-01-05 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105175746.fq6crpc3krz7tzxi@lukather>
On 05/01/17 17:57, Maxime Ripard wrote:
> Hi Rob,
>
> On Wed, Jan 04, 2017 at 08:07:50AM -0600, Rob Herring wrote:
>> On Mon, Jan 02, 2017 at 11:03:43PM +0000, Andre Przywara wrote:
>>> From: Maxime Ripard <maxime.ripard@free-electrons.com>
>>>
>>> Unlike the A64 user manual reports, the third MMC controller on the
>>> A64 (and the only one capable of 8-bit HS400 eMMC transfers) has a
>>> DMA buffer size limit of 8KB (much like the very old Allwinner SoCs).
>>> This does not affect the other two controllers, so introduce a new
>>> DT compatible string to let the driver use different settings for that
>>> particular device. This will also help to enable the high-speed transfer
>>> modes of that controller later.
>>>
>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
>>> drivers/mmc/host/sunxi-mmc.c | 7 +++++++
>>> 2 files changed, 8 insertions(+)
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> Some kind of a digression on this: we have three MMC controllers on
> this SoC. Like this patch shows, the third one is clearly different,
> and supports both more modes, a wider bus, and specific quirks. We
> need a new compatible for this one, everything's perfect.
>
> However, the other two are mostly the same, but seems to need
> different tuning parameters to get more performances out of the
> controller (but this is unclear yet). How do we usually deal with
> that?
I guess you wanted to hear Rob's opinion ;-), but "get more performance"
sounds like we add one (or more) properties to tune those values.
If I get this right, it works with default values, but is sub-optimal?
Cheers,
Andre.
^ permalink raw reply
* [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Russell King - ARM Linux @ 2017-01-05 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <049b1efc-3bad-92e0-45ef-0563dc5d81de@gmail.com>
On Mon, Nov 28, 2016 at 09:54:28AM -0800, Florian Fainelli wrote:
> If we start supporting generic "enable", "disable" type of properties
> with values that map directly to register definitions of the HW, we
> leave too much room for these properties to be utilized to implement a
> specific policy, and this is not acceptable.
Another concern with this patch is that the existing phylib "set_eee"
code is horribly buggy - it just translates the modes from userspace
into the register value and writes them directly to the register with
no validation. So it's possible to set modes in the register that the
hardware doesn't support, and have them advertised to the link partner.
I have a patch which fixes that, restricting (as we do elsewhere) the
advert according to the EEE supported capabilities retrieved from the
PCS - maybe the problem here is that the PCS doesn't support support
EEE in 1000baseT mode?
Out of interest, which PHY is used on this platform?
On the SolidRun boards, they're using AR8035, and have suffered this
occasional link drop problem. What has been found is that it seems to
be to do with the timing parameters, and it seemed to only be 1000bT
that was affected. I don't remember off hand exactly which or what
the change was they made to stabilise it though, but I can probabily
find out tomorrow.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: hw_breakpoint: blacklist Scorpion CPUs
From: Stephen Boyd @ 2017-01-05 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483637556-3974-1-git-send-email-mark.rutland@arm.com>
On 01/05, Mark Rutland wrote:
> On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
> undefined instruction trap within write_wb_reg. This is because Scorpion
> CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
> the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
> watchpoint registers are treated as undefined.
>
> It's possible to trigger similar crashes later on from userspace, by
> requesting the kernel to install a breakpoint or watchpoint, as we can
> go idle at any point between the reset of the debug registers and their
> later use. This has always been the case.
>
> Given that this has always been broken, no-one has complained until now,
> and there is no clear workaround, disable hardware breakpoints and
> watchpoints on Scorpion to avoid these issues.
I believe the workaround is to read DBGPRSR after exit from WFI?
I'm fine with the blacklisting approach though.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reported-by: Linus Walleij <linus.walleij@linaro.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: stable at vger.kernel.org
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv2 1/5] clk: mvebu: support for 98DX3236 SoC
From: Chris Packham @ 2017-01-05 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105135302.GB25333@leverpostej>
On 06/01/17 03:01, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 04:36:37PM +1300, Chris Packham wrote:
>> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
>> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
>>
>> The clock gating options are a subset of those on the Armada XP.
>>
>> The core clock divider is different to the Armada XP also.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>> Changes in v2:
>> - Update devicetree binding documentation for new compatible string
>>
>> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
>> drivers/clk/mvebu/Makefile | 2 +-
>> drivers/clk/mvebu/armada-xp.c | 42 +++++
>> drivers/clk/mvebu/clk-cpu.c | 33 +++-
>> drivers/clk/mvebu/mv98dx3236-corediv.c | 207 +++++++++++++++++++++
>> 5 files changed, 281 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/clk/mvebu/mv98dx3236-corediv.c
>
>
> It looks like you also need to update
> Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt for the
> addition of "marvell,mv98dx3236-corediv-clock".
Will do.
>
>>
>> diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
>> index 99c214660bdc..7f28506eaee7 100644
>> --- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
>> +++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
>> @@ -3,6 +3,7 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms
>> Required properties:
>> - compatible : shall be one of the following:
>> "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
>> + "marvell,mv98dx3236-cpu-clock" - cpu clocks for 98DX3236 SoC
>> - reg : Address and length of the clock complex register set, followed
>> by address and length of the PMU DFS registers
>> - #clock-cells : should be set to 1.
>
> [...]
>
>> +static void __init mv98dx3236_corediv_clk_init(struct device_node *node)
>> +{
>> + struct clk_init_data init;
>> + struct clk_corediv *corediv;
>> + struct clk **clks;
>> + void __iomem *base;
>> + const __be32 *off;
>> + const char *parent_name;
>> + const char *clk_name;
>> + int len;
>> + struct device_node *dfx_node;
>> +
>> + dfx_node = of_parse_phandle(node, "base", 0);
>> + if (WARN_ON(!dfx_node))
>
> What's going on here? The existing bingings don't mention a "base"
> phandle, and nothing was added to describe it.
>
>> + return;
>> +
>> + off = of_get_property(node, "reg", &len);
>> + if (WARN_ON(!off))
>> + return;
>
> Please don't use of_get_property directly; generally you should use the
> existing higher-level helpers like of_proeprty_read_u32().
>
>> +
>> + base = of_iomap(dfx_node, 0);
>> + if (WARN_ON(!base))
>> + return;
>> +
>> + of_node_put(dfx_node);
>> +
>> + parent_name = of_clk_get_parent_name(node, 0);
>> +
>> + clk_data.clk_num = 1;
>> +
>> + /* clks holds the clock array */
>> + clks = kcalloc(clk_data.clk_num, sizeof(struct clk *),
>> + GFP_KERNEL);
>> + if (WARN_ON(!clks))
>> + goto err_unmap;
>> + /* corediv holds the clock specific array */
>> + corediv = kcalloc(clk_data.clk_num, sizeof(struct clk_corediv),
>> + GFP_KERNEL);
>> + if (WARN_ON(!corediv))
>> + goto err_free_clks;
>> +
>> + spin_lock_init(&corediv->lock);
>> +
>> + of_property_read_string_index(node, "clock-output-names",
>> + 0, &clk_name);
>> +
>> + init.num_parents = 1;
>> + init.parent_names = &parent_name;
>> + init.name = clk_name;
>> + init.ops = &ops;
>> + init.flags = 0;
>> +
>> + corediv[0].reg = (void *)((int)base + be32_to_cpu(*off));
>
> I don't understand this, but I guess this has something to do with that
> base phandle. Is the corediv clock a sub-component of some "base" clock?
> I don't think this binding is the best way of describing that.
Actually once I've got things setup correctly via the dts I only need
some minor modification to mvebu/clk-corediv.c to handle the differences
in the bit fields used.
>
> Thanks,
> Mark.
>
^ permalink raw reply
* [PATCHv2 2/2] arm: Adjust memory boundaries after reservations
From: Laura Abbott @ 2017-01-05 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483657274-11346-1-git-send-email-labbott@redhat.com>
adjust_lowmem_bounds is responsible for setting up the boundary for
lowmem/hihgmme. This needs to be setup before memblock reservations can
occur. At the time memblock reservations can occur, memory can also be
removed from the system. The lowmem/highmem boundary and end of memory
may be affected by this but it is currently not recalculated. On some
systems this may be harmless, on o thers this may result in incorrect
ranges being passed to the main memory allocator. Correct this by
recalculating the lowmem/highmem boundary after all reservations have
been made.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v2: Rebased for changes in sanity_check_meminfo cleanup
---
arch/arm/kernel/setup.c | 8 ++++++++
arch/arm/mm/mmu.c | 9 ++++++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 8a8051c..4625115 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1093,8 +1093,16 @@ void __init setup_arch(char **cmdline_p)
setup_dma_zone(mdesc);
xen_early_init();
efi_init();
+ /*
+ * Make sure the calcualtion for lowmem/highmem is set appropriately
+ * before reserving/allocating any mmeory
+ */
adjust_lowmem_bounds();
arm_memblock_init(mdesc);
+ /*
+ * Memory may have been removed so recalculate the bounds.
+ */
+ adjust_lowmem_bounds();
early_ioremap_reset();
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index ce5123b..7ca6910 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1157,6 +1157,7 @@ void __init adjust_lowmem_bounds(void)
phys_addr_t memblock_limit = 0;
u64 vmalloc_limit;
struct memblock_region *reg;
+ phys_addr_t lowmem_limit = 0;
/*
* Let's use our own (unoptimized) equivalent of __pa() that is
@@ -1173,14 +1174,14 @@ void __init adjust_lowmem_bounds(void)
if (reg->base < vmalloc_limit) {
- if (block_end > arm_lowmem_limit)
+ if (block_end > lowmem_limit)
/*
* Compare as u64 to ensure vmalloc_limit does
* not get truncated. block_end should always
* fit in phys_addr_t so there should be no
* issue with assignment.
*/
- arm_lowmem_limit = min_t(u64,
+ lowmem_limit = min_t(u64,
vmalloc_limit,
block_end);
@@ -1201,12 +1202,14 @@ void __init adjust_lowmem_bounds(void)
if (!IS_ALIGNED(block_start, PMD_SIZE))
memblock_limit = block_start;
else if (!IS_ALIGNED(block_end, PMD_SIZE))
- memblock_limit = arm_lowmem_limit;
+ memblock_limit = lowmem_limit;
}
}
}
+ arm_lowmem_limit = lowmem_limit;
+
high_memory = __va(arm_lowmem_limit - 1) + 1;
/*
--
2.7.4
^ permalink raw reply related
* [PATCHv2 1/2] arm: Cleanup sanity_check_meminfo
From: Laura Abbott @ 2017-01-05 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483657274-11346-1-git-send-email-labbott@redhat.com>
The logic for sanity_check_meminfo has become difficult to
follow. Clean up the code so it's more obvious what the code
is actually trying to do. Additionally, meminfo is now removed
so rename the function to better describe it's purpose.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v2: Fixed code so b9a019899f61 ("ARM: 8590/1: sanity_check_meminfo():
avoid overflow on vmalloc_limit") should stay fixed. The casting and assignment
still seem ugly. Also corrected the size for memblock_remove with
!CONFIG_HIGHMEM (found by inspection, memblock was handling it properly).
---
arch/arm/kernel/setup.c | 4 +--
arch/arm/mm/mmu.c | 65 ++++++++++++++++++-------------------------------
arch/arm/mm/nommu.c | 8 +++---
3 files changed, 30 insertions(+), 47 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 34e3f3c..8a8051c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -81,7 +81,7 @@ __setup("fpe=", fpe_setup);
extern void init_default_cache_policy(unsigned long);
extern void paging_init(const struct machine_desc *desc);
extern void early_paging_init(const struct machine_desc *);
-extern void sanity_check_meminfo(void);
+extern void adjust_lowmem_bounds(void);
extern enum reboot_mode reboot_mode;
extern void setup_dma_zone(const struct machine_desc *desc);
@@ -1093,7 +1093,7 @@ void __init setup_arch(char **cmdline_p)
setup_dma_zone(mdesc);
xen_early_init();
efi_init();
- sanity_check_meminfo();
+ adjust_lowmem_bounds();
arm_memblock_init(mdesc);
early_ioremap_reset();
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4001dd1..ce5123b 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1152,13 +1152,11 @@ early_param("vmalloc", early_vmalloc);
phys_addr_t arm_lowmem_limit __initdata = 0;
-void __init sanity_check_meminfo(void)
+void __init adjust_lowmem_bounds(void)
{
phys_addr_t memblock_limit = 0;
- int highmem = 0;
u64 vmalloc_limit;
struct memblock_region *reg;
- bool should_use_highmem = false;
/*
* Let's use our own (unoptimized) equivalent of __pa() that is
@@ -1172,43 +1170,19 @@ void __init sanity_check_meminfo(void)
for_each_memblock(memory, reg) {
phys_addr_t block_start = reg->base;
phys_addr_t block_end = reg->base + reg->size;
- phys_addr_t size_limit = reg->size;
- if (reg->base >= vmalloc_limit)
- highmem = 1;
- else
- size_limit = vmalloc_limit - reg->base;
-
- if (!IS_ENABLED(CONFIG_HIGHMEM) || cache_is_vipt_aliasing()) {
-
- if (highmem) {
- pr_notice("Ignoring RAM at %pa-%pa (!CONFIG_HIGHMEM)\n",
- &block_start, &block_end);
- memblock_remove(reg->base, reg->size);
- should_use_highmem = true;
- continue;
- }
-
- if (reg->size > size_limit) {
- phys_addr_t overlap_size = reg->size - size_limit;
-
- pr_notice("Truncating RAM at %pa-%pa",
- &block_start, &block_end);
- block_end = vmalloc_limit;
- pr_cont(" to -%pa", &block_end);
- memblock_remove(vmalloc_limit, overlap_size);
- should_use_highmem = true;
- }
- }
-
- if (!highmem) {
- if (block_end > arm_lowmem_limit) {
- if (reg->size > size_limit)
- arm_lowmem_limit = vmalloc_limit;
- else
- arm_lowmem_limit = block_end;
- }
+ if (reg->base < vmalloc_limit) {
+ if (block_end > arm_lowmem_limit)
+ /*
+ * Compare as u64 to ensure vmalloc_limit does
+ * not get truncated. block_end should always
+ * fit in phys_addr_t so there should be no
+ * issue with assignment.
+ */
+ arm_lowmem_limit = min_t(u64,
+ vmalloc_limit,
+ block_end);
/*
* Find the first non-pmd-aligned page, and point
@@ -1233,9 +1207,6 @@ void __init sanity_check_meminfo(void)
}
}
- if (should_use_highmem)
- pr_notice("Consider using a HIGHMEM enabled kernel.\n");
-
high_memory = __va(arm_lowmem_limit - 1) + 1;
/*
@@ -1248,6 +1219,18 @@ void __init sanity_check_meminfo(void)
if (!memblock_limit)
memblock_limit = arm_lowmem_limit;
+ if (!IS_ENABLED(CONFIG_HIGHMEM) || cache_is_vipt_aliasing()) {
+ if (memblock_end_of_DRAM() > arm_lowmem_limit) {
+ phys_addr_t end = memblock_end_of_DRAM();
+
+ pr_notice("Ignoring RAM at %pa-%pa\n",
+ &memblock_limit, &end);
+ pr_notice("Consider using a HIGHMEM enabled kernel.\n");
+
+ memblock_remove(memblock_limit, end - memblock_limit);
+ }
+ }
+
memblock_set_current_limit(memblock_limit);
}
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967..13a25d6 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -85,7 +85,7 @@ static unsigned long irbar_read(void)
}
/* MPU initialisation functions */
-void __init sanity_check_meminfo_mpu(void)
+void __init adjust_lowmem_bounds_mpu(void)
{
phys_addr_t phys_offset = PHYS_OFFSET;
phys_addr_t aligned_region_size, specified_mem_size, rounded_mem_size;
@@ -274,7 +274,7 @@ void __init mpu_setup(void)
}
}
#else
-static void sanity_check_meminfo_mpu(void) {}
+static void adjust_lowmem_bounds_mpu(void) {}
static void __init mpu_setup(void) {}
#endif /* CONFIG_ARM_MPU */
@@ -295,10 +295,10 @@ void __init arm_mm_memblock_reserve(void)
#endif
}
-void __init sanity_check_meminfo(void)
+void __init adjust_lowmem_bounds(void)
{
phys_addr_t end;
- sanity_check_meminfo_mpu();
+ adjust_lowmem_bounds_mpu();
end = memblock_end_of_DRAM();
high_memory = __va(end - 1) + 1;
memblock_set_current_limit(end);
--
2.7.4
^ permalink raw reply related
* [PATCHv2 0/2] Memblock cleanup plus memory removal fix
From: Laura Abbott @ 2017-01-05 23:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v2 of the series to make sanity_check_meminfo (renamed in this series)
more readable and less error prone and fix an existing bug. v1 failed in that it
re-introduced a previously fixed bug. Hopefully this version does better.
As a reminder, During the course of
https://marc.info/?l=linux-arm-kernel&m=148145259511248, Grygorii Strashko
reminded me of another issue where I proposed a patch but never followed up on
it. The patch in
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/296978.html
did some cleanup and renaming of sanity_check_meminfo. I think this makes the
code more readable so I'd like to resurect it and rebase my fix
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/474060.html
on top of it.
Laura Abbott (2):
arm: Cleanup sanity_check_meminfo
arm: Adjust memory boundaries after reservations
arch/arm/kernel/setup.c | 12 ++++++++--
arch/arm/mm/mmu.c | 62 +++++++++++++++++--------------------------------
arch/arm/mm/nommu.c | 8 +++----
3 files changed, 35 insertions(+), 47 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] ARM: dts: da850: Add usb device node
From: David Lechner @ 2017-01-05 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165920.29809-2-ahaslam@baylibre.com>
Hi Sekhar,
On 11/21/2016 10:59 AM, Axel Haslam wrote:
> Add the usb1 device node for the da850 soc.
> This will allow boards to use the usb1 port
> when booting through DT.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 1bb1f6d..fbd50d6 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -406,6 +406,14 @@
> >;
> status = "disabled";
> };
> + usb1: usb at 225000 {
> + compatible = "ti,da830-ohci";
> + reg = <0x225000 0x1000>;
> + interrupts = <59>;
> + phys = <&usb_phy 1>;
> + phy-names = "usb-phy";
> + status = "disabled";
> + };
> gpio: gpio at 226000 {
> compatible = "ti,dm6441-gpio";
> gpio-controller;
>
This patch can be pickup up now. I have just tested with next-20171015 +
linux-davinci/master.
^ permalink raw reply
* next-20170105 build: 4 failures 3 warnings (next-20170105)
From: Stephen Rothwell @ 2017-01-05 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105195546.wnmjwh4hazqiyodf@sirena.org.uk>
Hi Mark,
On Thu, 5 Jan 2017 19:55:46 +0000 Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Jan 05, 2017 at 12:07:08PM +0000, Build bot for Mark Brown wrote:
>
> Since sometime over the Christmas vacation all arm64 configs have been
> failing to build due to:
>
> > ../arch/arm64/include/asm/setup.h:14:29: error: redefinition of 'kaslr_offset'
>
> (same error repeating a different number of times for each config).
> This is an interaction between Andrew's -current tree and Linus' tree.
> Andrew's tree has "arm64: setup: introduce kaslr_offset()"
> (1a339a14b1f2c7 in current -next) and Linus' tree has a commit
> 7ede8665f27cde7d with the same title but a modified version that went to
> Linus through Will. In the version in Andrew's tree kaslr_offset() is
> defined in asm/setup.h while in the version in Linus' tree it is
> instead defined in asm/memory.h so -next ends up with two definitions of
> that function causing the build errors.
>
> I guess the commit in Andrew's tree should be dropped now, reverting it
> fixes the builds for me.
OK, I have now dropped the initial part of akpm's -current tree that
was sent to Linus (including the above commit). Sorry for not noticing
earlier.
Andrew, this means that your tree in linux-next now contains:
a63a9bb7abd2 ipc/sem: add hysteresis
07be42f325e3 ipc/sem.c: avoid using spin_unlock_wait()
6d3a63124caa scripts/gdb: add lx-fdtdump command
138d8657d5ff kdump, vmcoreinfo: report actual value of phys_base
67dbc87b155b lib: Add CRC64 ECMA module
30daa67dc769 mm/vmstat.c: walk the zone in pageblock_nr_pages steps
d5419fdf6ed6 mm/page_owner: align with pageblock_nr pages
6eb902b75775 z3fold: fix locking issues
2fb167a08fa3 z3fold: fix header size related issues
c7f6417f13f6 z3fold: discourage use of pages that weren't compacted
8e40c9ecad02 z3fold: use per-page spinlock
9d759ab4feec mm/z3fold.c: extend compaction function
e22149b524d9 mm/z3fold.c: make pages_nr atomic
cb9a2fb0a835 mm/z3fold.c: limit first_num to the actual range of possible buddy indexes
1411714ceeee mm, page_alloc: avoid page_to_pfn() when merging buddies
794cc4aa50dc mm, page_alloc: don't convert pfn to idx when merging
8c0ff3c42376 mm-throttle-show_mem-from-warn_alloc-fix
e4974bce6cc7 mm: throttle show_mem() from warn_alloc()
4b2de28ffcd0 tmpfs: change shmem_mapping() to test shmem_aops
1143ed06c725 kernel-watchdog-prevent-false-hardlockup-on-overloaded-system-fix
6904a50482ee kernel/watchdog: prevent false hardlockup on overloaded system
04a26c045475 block: restore /proc/partitions to not display non-partitionable removable devices
409d7387f7be ocfs2: fix crash caused by stale lvb with fsdlm plugin
27040ecd9fbb ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix
c19202b8a963 ocfs2: old mle put and release after the function dlm_add_migration_mle called
d82c60f3a069 scripts/spelling.txt: add several more common spelling mistakes
af85e2db2cba arm: arch/arm/include/asm/page.h needs personality.h
3da3cb66bb1b mm/thp/pagecache/collapse: free the pte page table on collapse for thp page cache.
3180061bc2fd mm/thp/pagecache: only withdraw page table after a successful deposit
(merge linux-next - akpm stuff)
4453f4fde106 scripts/spelling.txt: add "followings" pattern and fix typo instances
f1c251fd2f4a scripts/spelling.txt: add "therfore" pattern and fix typo instances
09029516eb46 scripts/spelling.txt: add "overwriten" pattern and fix typo instances
a1d75390cb06 scripts/spelling.txt: add "overwritting" pattern and fix typo instances
174def646afe scripts/spelling.txt: add "deintialize(d)" pattern and fix typo instances
a3475e364975 scripts/spelling.txt: add "disassocation" pattern and fix typo instances
f8fa89870426 scripts/spelling.txt: add "omited" pattern and fix typo instances
a907cffe94c0 scripts/spelling.txt: add "explictely" pattern and fix typo instances
382a878623a8 scripts/spelling.txt: add "applys" pattern and fix typo instances
b349d54c456a scripts/spelling.txt: add "configuartion" pattern and fix typo instances
38bfb6e670f4 scripts/spelling.txt: add "overrided" pattern and fix typo instances
5453cfe4dc41 scripts/spelling.txt: add "overide" pattern and fix typo instances
4ad56706176e scripts/spelling.txt: add "disble(d)" pattern and fix typo instances
342f1c20e5c5 scripts/spelling.txt: add "comsume(r)" pattern and fix typo instances
4787ac5086e0 scripts/spelling.txt: add "intialise(d)" pattern and fix typo instances
46283934f6ae scripts/spelling.txt: add "initialiazation" pattern and fix typo instances
df8e7e0a5bc4 scripts/spelling.txt: add "intialization" pattern and fix typo instances
2f336b08f6f0 scripts/spelling.txt: add "unneded" pattern and fix typo instances
33faac7f1266 scripts/spelling.txt: add "neded" pattern and fix typo instances
c0c9925ac473 scripts/spelling.txt: add "againt" pattern and fix typo instances
f6efcac2efe0 scripts/spelling.txt: add "embeded" pattern and fix typo instances
7590c4f7f34b scripts/spelling.txt: add "varible" pattern and fix typo instances
36b857060ad7 scripts/spelling.txt: add "efective" pattern and fix typo instances
268f025aa99f scripts/spelling.txt: add "algined" pattern and fix typo instances
9fc9398d752e scripts/spelling.txt: add "aligment" pattern and fix typo instances
7b2467807cbc scripts/spelling.txt: add "partiton" pattern and fix typo instances
fea25f1f9e37 scripts/spelling.txt: add "an one" pattern and fix typo instances
84860c6996c9 scripts/spelling.txt: add "an union" pattern and fix typo instances
a9a1e595ac30 scripts/spelling.txt: add "an user" pattern and fix typo instances
4bde980b9c4a scripts/spelling.txt: add "swithc" pattern and fix typo instances
f19ed214ee17 scripts/spelling.txt: add "swith" pattern and fix typo instances
0f401b986050 reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr-checkpatch-fixes
6bfd1dd54e38 idr: support storing NULL in the IDR
9b54b6ba4a61 Reimplement IDR and IDA using the radix tree
6dde86413add fs: add i_blocksize()
--
Cheers,
Stephen Rothwell
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox