* [PATCH 5/5 v3] ARM: dts: Add the FOTG210 USB host to Gemini
From: kbuild test robot @ 2017-04-22 2:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421204058.6206-5-linus.walleij@linaro.org>
Hi Linus,
[auto build test ERROR on next-20170421]
[cannot apply to robh/for-next usb/usb-testing balbi-usb/next v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Linus-Walleij/usb-host-add-DT-bindings-for-faraday-fotg2/20170422-072414
config: arm-sama5_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/gemini.dtsi:161.19-20 syntax error
FATAL ERROR: Unable to parse input tree
---
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: 24300 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170422/a2a86dda/attachment-0001.gz>
^ permalink raw reply
* [PATCH 1/2] clk: mediatek: add mt2701 ethernet reset
From: Stephen Boyd @ 2017-04-22 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1485175707-58528-2-git-send-email-john@phrozen.org>
On 01/23, John Crispin wrote:
> The ethernet clock core has a reset register that is currently not exposed
> to the user. Fix this by adding the missing registration code.
>
> Signed-off-by: John Crispin <john@phrozen.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Stephen Boyd @ 2017-04-22 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419194737.GB2523@mai>
On 04/19, Daniel Lezcano wrote:
> On Wed, Apr 19, 2017 at 09:00:05AM -0700, Stephen Boyd wrote:
> > On 04/16, Daniel Lezcano wrote:
> > > On Wed, Apr 12, 2017 at 08:02:45AM -0700, Stephen Boyd wrote:
> > > > On 04/08, Daniel Lezcano wrote:
>
> [ ... ]
>
> > > > > + ret = clk_hw_register_clkdev(&hi655x_clk->clk_hw, clk_name, NULL);
> > > >
> > > > Missed this last time. Do you use this clkdev lookup? The name is
> > > > usually supposed to be based on what the device is expecting,
> > > > instead of clk_name, and we would want some device name for the
> > > > third argument here.
> > >
> > > I'm not sure to get your comment. Are you saying the clk_name should be the
> > > third argument?
> > >
> > >
> >
> > Sorry, no. I meant that con_id is typically something like "core"
> > or "ahb" or something like that, and dev_id is something like
> > "a456002.pmic_device" or whatever dev_name(pmic_dev) would return for
> > the consuming device. That way when we call clk_get(dev, "core")
> > it will find the lookup with "core" and "a456002.pmic_device" to
> > match up the clk lookup.
> >
> > If anything, the clk_name should just go into the con_id for now,
> > and then it will need to be a globally unique identifier for the
> > clk. But that is going against how clkdev is supposed to be used.
> > Hence the question if you even need to use it. If not, just don't
> > add it. I can fix up v3 of this patch to put clk_name back at
> > con_id if you like. No need to resend.
>
> Ok, I'm not very used with the CCF, so perhaps clk_name is not needed at all. I
> gave a try with the following combination:
>
> - con_id = NULL, dev_id = clk_name
> - con_id = clk_name, dev_id = NULL
> - con_id = NULL, dev_id = NULL
>
> All worked.
>
> And finally I removed the clk_hw_register_clkdev() call and it worked also.
>
> So I'm not sure about this function.
>
If you've removed it and it still works, then it means you're
using DT and you don't need clkdev at all. That's the of_clk
provider thing that you're using. So I'll go remove this clkdev
lookup because it's not used. If someone needs it they can add it
later.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.12, take 2
From: Stephen Boyd @ 2017-04-22 2:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420081749.bok3wwusmk2no5vw@lukather>
On 04/20, Maxime Ripard wrote:
> Hi Mike, Stephen,
>
> Here are the few last minor fixes that didn't go through for 4.11,
> plus two fixes for previous drivers changes found in the earlier pull
> request for 4.12.
>
Pulled into clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd
From: Stephen Boyd @ 2017-04-22 2:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492449567-31399-2-git-send-email-daniel.lezcano@linaro.org>
On 04/17, Daniel Lezcano wrote:
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++++++
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
> 2 files changed, 7 insertions(+)
>
I take it this goes through arm-soc? Not sure why I'm on To:
line.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 5/5] ARM: dts: imx7-colibri: add NAND support
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170422012338.4635-1-stefan@agner.ch>
The Colibri iMX7 modules come with 512MB on-module SLC NAND flash
populated. Make use of it by enabling the GPMI controller.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 2d87489f9105..ad4ce19d455b 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -106,6 +106,15 @@
fsl,magic-packet;
};
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ fsl,use-minimum-ecc;
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ status = "okay";
+};
+
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
--
2.12.2
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: imx7: add GPMI NAND
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170422012338.4635-1-stefan@agner.ch>
Add i.MX 7 GPMI NAND module.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7s.dtsi | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 843eb379e1ea..9645257638d4 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -995,5 +995,36 @@
status = "disabled";
};
};
+
+ dma_apbh: dma-apbh at 33000000 {
+ compatible = "fsl,imx7d-dma-apbh", "fsl,imx28-dma-apbh";
+ reg = <0x33000000 0x2000>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "gpmi0", "gpmi1", "gpmi2", "gpmi3";
+ #dma-cells = <1>;
+ dma-channels = <4>;
+ clocks = <&clks IMX7D_NAND_USDHC_BUS_ROOT_CLK>,
+ <&clks IMX7D_NAND_ROOT_CLK>;
+ clock-names = "dma_apbh_bch", "dma_apbh_io";
+ };
+
+ gpmi: gpmi-nand at 33002000{
+ compatible = "fsl,imx7d-gpmi-nand";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x33002000 0x2000>, <0x33004000 0x4000>;
+ reg-names = "gpmi-nand", "bch";
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "bch";
+ clocks = <&clks IMX7D_NAND_ROOT_CLK>,
+ <&clks IMX7D_NAND_USDHC_BUS_ROOT_CLK>;
+ clock-names = "gpmi_io", "gpmi_bch_apb";
+ dmas = <&dma_apbh 0>;
+ dma-names = "rx-tx";
+ status = "disabled";
+ };
};
};
--
2.12.2
^ permalink raw reply related
* [PATCH v2 3/5] mtd: gpmi: document current clock requirements
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170422012338.4635-1-stefan@agner.ch>
The clock requirements are completely missing, add the clocks
currently required by the driver.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Documentation/devicetree/bindings/mtd/gpmi-nand.txt | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
index d02acaff3c35..b289ef3c1b7e 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
@@ -4,7 +4,12 @@ The GPMI nand controller provides an interface to control the
NAND flash chips.
Required properties:
- - compatible : should be "fsl,<chip>-gpmi-nand"
+ - compatible : should be "fsl,<chip>-gpmi-nand", chip can be:
+ * imx23
+ * imx28
+ * imx6q
+ * imx6sx
+ * imx7d
- reg : should contain registers location and length for gpmi and bch.
- reg-names: Should contain the reg names "gpmi-nand" and "bch"
- interrupts : BCH interrupt number.
@@ -13,6 +18,13 @@ Required properties:
and GPMI DMA channel ID.
Refer to dma.txt and fsl-mxs-dma.txt for details.
- dma-names: Must be "rx-tx".
+ - clocks : clocks phandle and clock specifier corresponding to each clock
+ specified in clock-names.
+ - clock-names : The "gpmi_io" clock is always required. Which clocks are
+ exactly required depends on chip:
+ * imx23/imx28 : "gpmi_io"
+ * imx6q/sx : "gpmi_io", "gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch"
+ * imx7d : "gpmi_io", "gpmi_bch_apb"
Optional properties:
- nand-on-flash-bbt: boolean to enable on flash bbt option if not
--
2.12.2
^ permalink raw reply related
* [PATCH v2 2/5] mtd: nand: gpmi: add i.MX 7 SoC support
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170422012338.4635-1-stefan@agner.ch>
Add support for i.MX 7 SoC. The i.MX 7 has a slightly different
clock architecture requiring only two clocks to be referenced.
The IP is slightly different compared to i.MX 6, but currently none
of this differences are in use, therefore reuse GPMI_IS_MX6.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 15 +++++++++++++++
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 7 +++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index c8bbf5da2ab8..9b777be633a9 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -127,6 +127,18 @@ static const struct gpmi_devdata gpmi_devdata_imx6sx = {
.clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
};
+static const char * const gpmi_clks_for_mx7d[] = {
+ "gpmi_io", "gpmi_bch_apb",
+};
+
+static const struct gpmi_devdata gpmi_devdata_imx7d = {
+ .type = IS_MX7D,
+ .bch_max_ecc_strength = 62,
+ .max_chain_delay = 12,
+ .clks = gpmi_clks_for_mx7d,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx7d),
+};
+
static irqreturn_t bch_irq(int irq, void *cookie)
{
struct gpmi_nand_data *this = cookie;
@@ -2071,6 +2083,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
}, {
.compatible = "fsl,imx6sx-gpmi-nand",
.data = &gpmi_devdata_imx6sx,
+ }, {
+ .compatible = "fsl,imx7d-gpmi-nand",
+ .data = &gpmi_devdata_imx7d,
}, {}
};
MODULE_DEVICE_TABLE(of, gpmi_nand_id_table);
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 8879c4eff25e..e88a45a62ab6 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -123,7 +123,8 @@ enum gpmi_type {
IS_MX23,
IS_MX28,
IS_MX6Q,
- IS_MX6SX
+ IS_MX6SX,
+ IS_MX7D,
};
struct gpmi_devdata {
@@ -307,6 +308,8 @@ void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
#define GPMI_IS_MX28(x) ((x)->devdata->type == IS_MX28)
#define GPMI_IS_MX6Q(x) ((x)->devdata->type == IS_MX6Q)
#define GPMI_IS_MX6SX(x) ((x)->devdata->type == IS_MX6SX)
+#define GPMI_IS_MX7D(x) ((x)->devdata->type == IS_MX7D)
-#define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6SX(x))
+#define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6SX(x) || \
+ GPMI_IS_MX7D(x))
#endif
--
2.12.2
^ permalink raw reply related
* [PATCH v2 1/5] mtd: nand: gpmi: unify clock handling
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170422012338.4635-1-stefan@agner.ch>
Add device specific list of clocks required, and handle all clocks
in a single for loop. This avoids further code duplication when
adding i.MX 7 support.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 41 +++++++++++++++-------------------
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 2 ++
2 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index d52139635b67..c8bbf5da2ab8 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -82,6 +82,10 @@ static int gpmi_ooblayout_free(struct mtd_info *mtd, int section,
return 0;
}
+static const char * const gpmi_clks_for_mx2x[] = {
+ "gpmi_io",
+};
+
static const struct mtd_ooblayout_ops gpmi_ooblayout_ops = {
.ecc = gpmi_ooblayout_ecc,
.free = gpmi_ooblayout_free,
@@ -91,24 +95,36 @@ static const struct gpmi_devdata gpmi_devdata_imx23 = {
.type = IS_MX23,
.bch_max_ecc_strength = 20,
.max_chain_delay = 16,
+ .clks = gpmi_clks_for_mx2x,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx2x),
};
static const struct gpmi_devdata gpmi_devdata_imx28 = {
.type = IS_MX28,
.bch_max_ecc_strength = 20,
.max_chain_delay = 16,
+ .clks = gpmi_clks_for_mx2x,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx2x),
+};
+
+static const char * const gpmi_clks_for_mx6[] = {
+ "gpmi_io", "gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch",
};
static const struct gpmi_devdata gpmi_devdata_imx6q = {
.type = IS_MX6Q,
.bch_max_ecc_strength = 40,
.max_chain_delay = 12,
+ .clks = gpmi_clks_for_mx6,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
};
static const struct gpmi_devdata gpmi_devdata_imx6sx = {
.type = IS_MX6SX,
.bch_max_ecc_strength = 62,
.max_chain_delay = 12,
+ .clks = gpmi_clks_for_mx6,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
};
static irqreturn_t bch_irq(int irq, void *cookie)
@@ -599,35 +615,14 @@ static int acquire_dma_channels(struct gpmi_nand_data *this)
return -EINVAL;
}
-static char *extra_clks_for_mx6q[GPMI_CLK_MAX] = {
- "gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch",
-};
-
static int gpmi_get_clks(struct gpmi_nand_data *this)
{
struct resources *r = &this->resources;
- char **extra_clks = NULL;
struct clk *clk;
int err, i;
- /* The main clock is stored in the first. */
- r->clock[0] = devm_clk_get(this->dev, "gpmi_io");
- if (IS_ERR(r->clock[0])) {
- err = PTR_ERR(r->clock[0]);
- goto err_clock;
- }
-
- /* Get extra clocks */
- if (GPMI_IS_MX6(this))
- extra_clks = extra_clks_for_mx6q;
- if (!extra_clks)
- return 0;
-
- for (i = 1; i < GPMI_CLK_MAX; i++) {
- if (extra_clks[i - 1] == NULL)
- break;
-
- clk = devm_clk_get(this->dev, extra_clks[i - 1]);
+ for (i = 0; i < this->devdata->clks_count; i++) {
+ clk = devm_clk_get(this->dev, this->devdata->clks[i]);
if (IS_ERR(clk)) {
err = PTR_ERR(clk);
goto err_clock;
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 4e49a1f5fa27..8879c4eff25e 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -130,6 +130,8 @@ struct gpmi_devdata {
enum gpmi_type type;
int bch_max_ecc_strength;
int max_chain_delay; /* See the async EDO mode */
+ const char * const *clks;
+ const int clks_count;
};
struct gpmi_nand_data {
--
2.12.2
^ permalink raw reply related
* [PATCH v2 0/5] mtd: nand: gpmi: add i.MX 7 support
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for i.MX 7 SoC for the GPMI NAND controller.
There have been similar patchsets already:
https://lkml.org/lkml/2016/2/23/912
However, this patchset does not make use of any of the new features.
The current feature set seems to work fine, I successfully run the MTD
tests on a Colibri iMX7.
--
Stefan
Changes since v1:
- Make clks_count const
- Introduce IS_IMX7D for i.MX 7 SoC's and make it part of GPMI_IS_MX6
Stefan Agner (5):
mtd: nand: gpmi: unify clock handling
mtd: nand: gpmi: add i.MX 7 SoC support
mtd: gpmi: document current clock requirements
ARM: dts: imx7: add GPMI NAND
ARM: dts: imx7-colibri: add NAND support
.../devicetree/bindings/mtd/gpmi-nand.txt | 14 +++++-
arch/arm/boot/dts/imx7-colibri.dtsi | 9 ++++
arch/arm/boot/dts/imx7s.dtsi | 31 ++++++++++++
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 56 +++++++++++++---------
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 9 +++-
5 files changed, 93 insertions(+), 26 deletions(-)
--
2.12.2
^ permalink raw reply
* [PATCH v3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd
From: Alexander Graf @ 2017-04-22 0:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28bece63-9917-5f00-ccdf-fe663def500f@arm.com>
On 04.04.17 12:35, Suzuki K Poulose wrote:
> Hi Christoffer,
>
> On 04/04/17 11:13, Christoffer Dall wrote:
>> Hi Suzuki,
>>
>> On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote:
>>> In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
>>> unmap_stage2_range() on the entire memory range for the guest. This
>>> could
>>> cause problems with other callers (e.g, munmap on a memslot) trying to
>>> unmap a range. And since we have to unmap the entire Guest memory range
>>> holding a spinlock, make sure we yield the lock if necessary, after we
>>> unmap each PUD range.
>>>
>>> Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")
>>> Cc: stable at vger.kernel.org # v3.10+
>>> Cc: Paolo Bonzini <pbonzin@redhat.com>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Christoffer Dall <christoffer.dall@linaro.org>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>> [ Avoid vCPU starvation and lockup detector warnings ]
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>
>>
>> This unfortunately fails to build on 32-bit ARM, and I also think we
>> intended to check against S2_PGDIR_SIZE, not S2_PUD_SIZE.
>
> Sorry about that, I didn't test the patch with arm32. I am fine the
> patch below. And I agree that the name change does make things more
> readable. See below for a hunk that I posted to the kbuild report.
>
>>
>> How about adding this to your patch (which includes a rename of
>> S2_PGD_SIZE which is horribly confusing as it indicates the size of the
>> first level stage-2 table itself, where S2_PGDIR_SIZE indicates the size
>> of address space mapped by a single entry in the same table):
>>
>> diff --git a/arch/arm/include/asm/stage2_pgtable.h
>> b/arch/arm/include/asm/stage2_pgtable.h
>> index 460d616..c997f2d 100644
>> --- a/arch/arm/include/asm/stage2_pgtable.h
>> +++ b/arch/arm/include/asm/stage2_pgtable.h
>> @@ -35,10 +35,13 @@
>>
>> #define stage2_pud_huge(pud) pud_huge(pud)
>>
>> +#define S2_PGDIR_SIZE PGDIR_SIZE
>> +#define S2_PGDIR_MASK PGDIR_MASK
>> +
>> /* Open coded p*d_addr_end that can deal with 64bit addresses */
>> static inline phys_addr_t stage2_pgd_addr_end(phys_addr_t addr,
>> phys_addr_t end)
>> {
>> - phys_addr_t boundary = (addr + PGDIR_SIZE) & PGDIR_MASK;
>> + phys_addr_t boundary = (addr + S2_PGDIR_SIZE) & S2_PGDIR_MASK;
>>
>> return (boundary - 1 < end - 1) ? boundary : end;
>> }
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index db94f3a..6e79a4c 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -41,7 +41,7 @@ static unsigned long hyp_idmap_start;
>> static unsigned long hyp_idmap_end;
>> static phys_addr_t hyp_idmap_vector;
>>
>> -#define S2_PGD_SIZE (PTRS_PER_S2_PGD * sizeof(pgd_t))
>> +#define S2_PGD_TABLE_SIZE (PTRS_PER_S2_PGD * sizeof(pgd_t))
>> #define hyp_pgd_order get_order(PTRS_PER_PGD * sizeof(pgd_t))
>>
>> #define KVM_S2PTE_FLAG_IS_IOMAP (1UL << 0)
>> @@ -299,7 +299,7 @@ static void unmap_stage2_range(struct kvm *kvm,
>> phys_addr_t start, u64 size)
>> * If the range is too large, release the kvm->mmu_lock
>> * to prevent starvation and lockup detector warnings.
>> */
>> - if (size > S2_PUD_SIZE)
>> + if (size > S2_PGDIR_SIZE)
>> cond_resched_lock(&kvm->mmu_lock);
>> next = stage2_pgd_addr_end(addr, end);
>> if (!stage2_pgd_none(*pgd))
>> @@ -747,7 +747,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
>> }
>>
>> /* Allocate the HW PGD, making sure that each page gets its own
>> refcount */
>> - pgd = alloc_pages_exact(S2_PGD_SIZE, GFP_KERNEL | __GFP_ZERO);
>> + pgd = alloc_pages_exact(S2_PGD_TABLE_SIZE, GFP_KERNEL | __GFP_ZERO);
>> if (!pgd)
>> return -ENOMEM;
>>
>> @@ -843,7 +843,7 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
>> spin_unlock(&kvm->mmu_lock);
>>
>> /* Free the HW pgd, one page at a time */
>> - free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
>> + free_pages_exact(kvm->arch.pgd, S2_PGD_TABLE_SIZE);
>> kvm->arch.pgd = NULL;
>> }
>>
>
> Btw, I have a different hunk to solve the problem, posted to the kbuild
> report. I will post it here for the sake of capturing the discussion in
> one place. The following hunk on top of the patch, changes the lock
> release after we process one PGDIR entry. As for the first time
> we enter the loop we haven't done much with the lock held, hence it may
> make
> sense to do it after the first round and we have more work to do.
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index db94f3a..582a972 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -295,15 +295,15 @@ static void unmap_stage2_range(struct kvm *kvm,
> phys_addr_t start, u64 size)
> assert_spin_locked(&kvm->mmu_lock);
> pgd = kvm->arch.pgd + stage2_pgd_index(addr);
> do {
> + next = stage2_pgd_addr_end(addr, end);
> + if (!stage2_pgd_none(*pgd))
Just as heads up, I had this version applied to my tree by accident
(commit 8b3405e345b5a098101b0c31b264c812bba045d9 from Christoffer's
queue) and ran into a NULL pointer dereference:
[223090.242280] Unable to handle kernel NULL pointer dereference at
virtual address 00000040
[223090.262330] PC is at unmap_stage2_range+0x8c/0x428
[223090.262332] LR is at kvm_unmap_hva_handler+0x2c/0x3c
[223090.262531] Call trace:
[223090.262533] [<ffff0000080adb78>] unmap_stage2_range+0x8c/0x428
[223090.262535] [<ffff0000080adf40>] kvm_unmap_hva_handler+0x2c/0x3c
[223090.262537] [<ffff0000080ace2c>] handle_hva_to_gpa+0xb0/0x104
[223090.262539] [<ffff0000080af988>] kvm_unmap_hva+0x5c/0xbc
[223090.262543] [<ffff0000080a2478>]
kvm_mmu_notifier_invalidate_page+0x50/0x8c
[223090.262547] [<ffff0000082274f8>]
__mmu_notifier_invalidate_page+0x5c/0x84
[223090.262551] [<ffff00000820b700>] try_to_unmap_one+0x1d0/0x4a0
[223090.262553] [<ffff00000820c5c8>] rmap_walk+0x1cc/0x2e0
[223090.262555] [<ffff00000820c90c>] try_to_unmap+0x74/0xa4
[223090.262557] [<ffff000008230ce4>] migrate_pages+0x31c/0x5ac
[223090.262561] [<ffff0000081f869c>] compact_zone+0x3fc/0x7ac
[223090.262563] [<ffff0000081f8ae0>] compact_zone_order+0x94/0xb0
[223090.262564] [<ffff0000081f91c0>] try_to_compact_pages+0x108/0x290
[223090.262569] [<ffff0000081d5108>] __alloc_pages_direct_compact+0x70/0x1ac
[223090.262571] [<ffff0000081d64a0>] __alloc_pages_nodemask+0x434/0x9f4
[223090.262572] [<ffff0000082256f0>] alloc_pages_vma+0x230/0x254
[223090.262574] [<ffff000008235e5c>] do_huge_pmd_anonymous_page+0x114/0x538
[223090.262576] [<ffff000008201bec>] handle_mm_fault+0xd40/0x17a4
[223090.262577] [<ffff0000081fb324>] __get_user_pages+0x12c/0x36c
[223090.262578] [<ffff0000081fb804>] get_user_pages_unlocked+0xa4/0x1b8
[223090.262579] [<ffff0000080a3ce8>] __gfn_to_pfn_memslot+0x280/0x31c
[223090.262580] [<ffff0000080a3dd0>] gfn_to_pfn_prot+0x4c/0x5c
[223090.262582] [<ffff0000080af3f8>] kvm_handle_guest_abort+0x240/0x774
[223090.262584] [<ffff0000080b2bac>] handle_exit+0x11c/0x1ac
[223090.262586] [<ffff0000080ab99c>] kvm_arch_vcpu_ioctl_run+0x31c/0x648
[223090.262587] [<ffff0000080a1d78>] kvm_vcpu_ioctl+0x378/0x768
[223090.262590] [<ffff00000825df5c>] do_vfs_ioctl+0x324/0x5a4
[223090.262591] [<ffff00000825e26c>] SyS_ioctl+0x90/0xa4
[223090.262595] [<ffff000008085d84>] el0_svc_naked+0x38/0x3c
0xffff0000080adb78 is in unmap_stage2_range (../arch/arm/kvm/mmu.c:260).
255 pud_t *pud, *start_pud;
256
257 start_pud = pud = stage2_pud_offset(pgd, addr);
258 do {
259 next = stage2_pud_addr_end(addr, end);
260 if (!stage2_pud_none(*pud)) {
261 if (stage2_pud_huge(*pud)) {
262 pud_t old_pud = *pud;
263
264 stage2_pud_clear(pud);
So please beware that for some reason pud may become invalid after
rescheduling.
Alex
^ permalink raw reply
* linux-next: build failure after merge of the arm tree
From: Russell King - ARM Linux @ 2017-04-21 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421181230.05dcf937@canb.auug.org.au>
On Fri, Apr 21, 2017 at 06:12:30PM +1000, Stephen Rothwell wrote:
> Hi Mason,
>
> On Fri, 21 Apr 2017 09:58:58 +0200 Mason <slash.tmp@free.fr> wrote:
> >
> > Anyway, the fix is trivial.
> >
> > The "pchans_used" field is an unsigned long array.
> > for_each_clear_bit_from() expects an unsigned long pointer,
> > not an array address.
> >
> > I'll send a patch to the drivers/dma maintainers.
>
> The fix really needs to go into the arm tree (as well?) since that is
> the tree that has the patch that causes the build to break (even if the
> actual bug was preexisting).
Or I drop the offending patch (done) and we get the DMA subsystem fixed
first. Given how long it's been this way, I doubt there's any hurry to
get this change in for the next merge window.
--
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
* ARM lockup during Kexec operation
From: Russell King - ARM Linux @ 2017-04-21 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f094f2a481994c31bff01ef7579f1d3c@LPHQEX2013.litepoint.internal>
On Fri, Apr 21, 2017 at 11:04:19PM +0000, Rudici Cazeao wrote:
> The issue is localized to linux-3.0.51/arch\arm/mach-transcede/hotplug.c.
>
> cpu_enter_lowpower();
> platform_do_lowpower(cpu, &spurious);
> cpu_leave_lowpower(). / * bring this CPU back into the world of cache coherency, and then restore interrupts */
>
>
> static inline void platform_do_lowpower(unsigned int cpu, int *spurious) {
> for (;;) { / * there is no power-control hardware on this platform, so all we can do is put the core into WFI; this is safe as the calling code will have already disabled interrupts */
> wfe();
> if (pen_release == cpu) {
> break; / * OK, proper wakeup, we're done */
> }
>
> (*spurious)++; / * Getting here, means that we have come out of WFI without having been woken up - Just note it happening - when we're woken, we can report its occurrence.
> }
> }
Sorry, but with the above, the platform can't support suspend/resume or
kexec reliably. It needs a proper implementation - iow, one which
actually takes the CPU offline such that it resumes as it does the very
first time we boot.
This also doesn't seem to be mainline kernel related - and searching
google for "arm/mach-transcede" brings up no relevant results,
certainly not on the first page.
--
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
* [v4.9-rt PATCH v2] ARM: mm: remove tasklist locking from update_sections_early()
From: Kees Cook @ 2017-04-21 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <46862ce1-77d2-8e82-8820-64ec47957844@redhat.com>
On Wed, Apr 19, 2017 at 5:36 PM, Laura Abbott <labbott@redhat.com> wrote:
> On 04/19/2017 01:10 PM, Grygorii Strashko wrote:
>>
>> The below backtrace can be observed on -rt kernel with CONFIG_DEBUG_RODATA
>> option enabled:
>>
>> BUG: sleeping function called from invalid context at
>> kernel/locking/rtmutex.c:993
>> in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
>> 1 lock held by migration/0/14:
>> #0: (tasklist_lock){+.+...}, at: [<c01183e8>]
>> update_sections_early+0x24/0xdc
>> irq event stamp: 38
>> hardirqs last enabled at (37): [<c08f6f7c>]
>> _raw_spin_unlock_irq+0x24/0x68
>> hardirqs last disabled at (38): [<c01fdfe8>] multi_cpu_stop+0xd8/0x138
>> softirqs last enabled at (0): [<c01303ec>]
>> copy_process.part.5+0x238/0x1b64
>> softirqs last disabled at (0): [< (null)>] (null)
>> Preemption disabled at: [<c01fe244>] cpu_stopper_thread+0x80/0x10c
>> CPU: 0 PID: 14 Comm: migration/0 Not tainted 4.9.21-rt16-02220-g49e319c
>> #15
>> Hardware name: Generic DRA74X (Flattened Device Tree)
>> [<c0112014>] (unwind_backtrace) from [<c010d370>] (show_stack+0x10/0x14)
>> [<c010d370>] (show_stack) from [<c049beb8>] (dump_stack+0xa8/0xd4)
>> [<c049beb8>] (dump_stack) from [<c01631a0>] (___might_sleep+0x1bc/0x2ac)
>> [<c01631a0>] (___might_sleep) from [<c08f7244>]
>> (__rt_spin_lock+0x1c/0x30)
>> [<c08f7244>] (__rt_spin_lock) from [<c08f77a4>] (rt_read_lock+0x54/0x68)
>> [<c08f77a4>] (rt_read_lock) from [<c01183e8>]
>> (update_sections_early+0x24/0xdc)
>> [<c01183e8>] (update_sections_early) from [<c01184b0>]
>> (__fix_kernmem_perms+0x10/0x1c)
>> [<c01184b0>] (__fix_kernmem_perms) from [<c01fe010>]
>> (multi_cpu_stop+0x100/0x138)
>> [<c01fe010>] (multi_cpu_stop) from [<c01fe24c>]
>> (cpu_stopper_thread+0x88/0x10c)
>> [<c01fe24c>] (cpu_stopper_thread) from [<c015edc4>]
>> (smpboot_thread_fn+0x174/0x31c)
>> [<c015edc4>] (smpboot_thread_fn) from [<c015a988>] (kthread+0xf0/0x108)
>> [<c015a988>] (kthread) from [<c0108818>] (ret_from_fork+0x14/0x3c)
>> Freeing unused kernel memory: 1024K (c0d00000 - c0e00000)
>>
>> The stop_machine() is called with cpus = NULL from fix_kernmem_perms() and
>> mark_rodata_ro() which means only one CPU will execute
>> update_sections_early() while all other CPUs will spin and wait. Hence,
>> it's safe to remove tasklist locking from update_sections_early(). As part
>> of this change also mark functions which are local to this module as
>> static
>
> Acked-by: Laura Abbott <labbott@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Please throw this at the ARM patch tracker (with our Acks).
http://www.arm.linux.org.uk/developer/patches/info.php
Thanks!
-Kees
>
>
>>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: Laura Abbott <labbott@redhat.com>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
>> As I've checked it also can be applied to LKML as is.
>>
>> Changes in v2:
>> - added comment to update_sections_early()
>>
>> v1: https://patchwork.kernel.org/patch/9686289/
>>
>> arch/arm/mm/init.c | 13 ++++++++-----
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index 370581a..838f6b35 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -689,34 +689,37 @@ void set_section_perms(struct section_perm *perms,
>> int n, bool set,
>> }
>> +/**
>> + * update_sections_early intended to be called only through stop_machine
>> + * framework and executed by only one CPU while all other CPUs will spin
>> and
>> + * wait, so no locking is required in this function.
>> + */
>> static void update_sections_early(struct section_perm perms[], int n)
>> {
>> struct task_struct *t, *s;
>> - read_lock(&tasklist_lock);
>> for_each_process(t) {
>> if (t->flags & PF_KTHREAD)
>> continue;
>> for_each_thread(t, s)
>> set_section_perms(perms, n, true, s->mm);
>> }
>> - read_unlock(&tasklist_lock);
>> set_section_perms(perms, n, true, current->active_mm);
>> set_section_perms(perms, n, true, &init_mm);
>> }
>> -int __fix_kernmem_perms(void *unused)
>> +static int __fix_kernmem_perms(void *unused)
>> {
>> update_sections_early(nx_perms, ARRAY_SIZE(nx_perms));
>> return 0;
>> }
>> -void fix_kernmem_perms(void)
>> +static void fix_kernmem_perms(void)
>> {
>> stop_machine(__fix_kernmem_perms, NULL, NULL);
>> }
>> -int __mark_rodata_ro(void *unused)
>> +static int __mark_rodata_ro(void *unused)
>> {
>> update_sections_early(ro_perms, ARRAY_SIZE(ro_perms));
>> return 0;
>>
>
--
Kees Cook
Pixel Security
^ permalink raw reply
* ARM lockup during Kexec operation
From: Rudici Cazeao @ 2017-04-21 23:04 UTC (permalink / raw)
To: linux-arm-kernel
Using kexec on a dual-core arm processor (arm7), the non-boot CPU (CPU1) appears to be locking up during kexec.
The SoC is mach-transcede
The kernel version is 3.0.51-rt75
The issue is localized to linux-3.0.51/arch\arm/mach-transcede/hotplug.c.
cpu_enter_lowpower();
platform_do_lowpower(cpu, &spurious);
cpu_leave_lowpower(). / * bring this CPU back into the world of cache coherency, and then restore interrupts */
static inline void platform_do_lowpower(unsigned int cpu, int *spurious) {
for (;;) { / * there is no power-control hardware on this platform, so all we can do is put the core into WFI; this is safe as the calling code will have already disabled interrupts */
wfe();
if (pen_release == cpu) {
break; / * OK, proper wakeup, we're done */
}
(*spurious)++; / * Getting here, means that we have come out of WFI without having been woken up - Just note it happening - when we're woken, we can report its occurrence.
}
}
When the issue occurs the non-boot CPU (ie CPU 1) is entering the platform_do_lowpower sequence where it should wait until pren_release is set to 1 by CPU1
Please note that This failure is random. It usually happens somewhere between 300 and 5000 kexec loops.
^ permalink raw reply
* [PATCH] ARM: omap2+: make omap4_get_cpu1_ns_pa_addr declaration usable
From: Tony Lindgren @ 2017-04-21 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421215556.2244576-1-arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [170421 14:59]:
> When CONFIG_PM is disabled, we get a build error:
>
> arch/arm/mach-omap2/omap-smp.c: In function 'omap4_smp_maybe_reset_cpu1':
> arch/arm/mach-omap2/omap-smp.c:309:20: error: implicit declaration of function 'omap4_get_cpu1_ns_pa_addr'; did you mean 'omap4_get_scu_base'? [-Werror=implicit-function-declaration]
>
> We need to fix this in multiple files, to ensure the declaration is visible,
> to actually build the function without CONFIG_PM, and to only call it
> when OMAP4 and/or OMAP5 are enabled.
>
> Fixes: 351b7c490700 ("ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot")
Oops, sorry about that. Looks like I never hit that with my
randconfig builds earlier probably as we have at least CPU_IDLE and
ARCH_OMAP2PLUS_TYPICAL select PM. Thanks for fixing it:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v3 6/7] ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
From: Arnd Bergmann @ 2017-04-21 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7eb9a87f-9b61-1367-311c-bc37430291e5@arm.com>
On Wed, Apr 19, 2017 at 4:10 PM, Vladimir Murzin
<vladimir.murzin@arm.com> wrote:
> On 19/04/17 11:02, Arnd Bergmann wrote:
>> Can you either modify the description to explain why we now need this on
>> all ARMv7M, or add a '|| CPU_V7M' for the 'bool' line to make it optional?
>>
>> Would it be better to leave the default as disabled on CPU_V7M and
>> require users to enable it manually? That way we don't regress the
>> performance of readl/writel on platforms that don't need this.
>>
>
> It is architectural vs implementation differences. Even though existing
> implementations rarely need this sticking with architecture (it permits memory
> re-ordering to happen in many cases) makes code more robust and save some
> debugging time when more sophisticated implementations go wild (see, for
> instance, 8e02676ffa69 "ARM: 8610/1: V7M: Add dsb before jumping in handler
> mode"). We can consider making it user selectable if performance regressions
> are reported.
I would expect the performance difference to be noticeable, even though
MMIO tends to be a rather slow operation, having tons of barriers in drivers
that don't do DMA but transfer data through a series of writel() can be
significant.
Arnd
^ permalink raw reply
* [PATCH v4 14/21] PCI: designware: update PCI config space remap function
From: Jingoo Han @ 2017-04-21 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419164913.19674-15-lorenzo.pieralisi@arm.com>
On Wednesday, April 19, 2017 12:49 PM, Lorenzo Pieralisi wrote:
>
> PCI configuration space should be mapped with a memory region type that
> generates on the CPU host bus non-posted write transations. Update the
> driver to use the devm_pci_remap_cfg* interface to make sure the correct
> memory mappings for PCI configuration space are used.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Jingoo Han <jingoohan1@gmail.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
> Cc: Joao Pinto <Joao.Pinto@synopsys.com>
> ---
> drivers/pci/dwc/pcie-designware-host.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware-host.c
> b/drivers/pci/dwc/pcie-designware-host.c
> index 5ba3349..2b789af 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -338,8 +338,9 @@ int dw_pcie_host_init(struct pcie_port *pp)
> }
>
> if (!pci->dbi_base) {
> - pci->dbi_base = devm_ioremap(dev, pp->cfg->start,
> - resource_size(pp->cfg));
> + pci->dbi_base = devm_pci_remap_cfgspace(dev,
> + pp->cfg->start,
> + resource_size(pp->cfg));
> if (!pci->dbi_base) {
> dev_err(dev, "error with ioremap\n");
> ret = -ENOMEM;
> @@ -350,8 +351,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> pp->mem_base = pp->mem->start;
>
> if (!pp->va_cfg0_base) {
> - pp->va_cfg0_base = devm_ioremap(dev, pp->cfg0_base,
> - pp->cfg0_size);
> + pp->va_cfg0_base = devm_pci_remap_cfgspace(dev,
> + pp->cfg0_base, pp->cfg0_size);
> if (!pp->va_cfg0_base) {
> dev_err(dev, "error with ioremap in function\n");
> ret = -ENOMEM;
> @@ -360,7 +361,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> }
>
> if (!pp->va_cfg1_base) {
> - pp->va_cfg1_base = devm_ioremap(dev, pp->cfg1_base,
> + pp->va_cfg1_base = devm_pci_remap_cfgspace(dev,
> + pp->cfg1_base,
> pp->cfg1_size);
> if (!pp->va_cfg1_base) {
> dev_err(dev, "error with ioremap\n");
> --
> 2.10.0
^ permalink raw reply
* [PATCH] ARM: omap2+: make omap4_get_cpu1_ns_pa_addr declaration usable
From: Arnd Bergmann @ 2017-04-21 21:55 UTC (permalink / raw)
To: linux-arm-kernel
When CONFIG_PM is disabled, we get a build error:
arch/arm/mach-omap2/omap-smp.c: In function 'omap4_smp_maybe_reset_cpu1':
arch/arm/mach-omap2/omap-smp.c:309:20: error: implicit declaration of function 'omap4_get_cpu1_ns_pa_addr'; did you mean 'omap4_get_scu_base'? [-Werror=implicit-function-declaration]
We need to fix this in multiple files, to ensure the declaration is visible,
to actually build the function without CONFIG_PM, and to only call it
when OMAP4 and/or OMAP5 are enabled.
Fixes: 351b7c490700 ("ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-omap2/common.h | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 10 +++++-----
arch/arm/mach-omap2/omap-smp.c | 11 +++++++----
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 3089d3bfa19b..8cc6338fcb12 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -266,11 +266,12 @@ extern int omap4_cpu_kill(unsigned int cpu);
extern const struct smp_operations omap4_smp_ops;
#endif
+extern u32 omap4_get_cpu1_ns_pa_addr(void);
+
#if defined(CONFIG_SMP) && defined(CONFIG_PM)
extern int omap4_mpuss_init(void);
extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
-extern u32 omap4_get_cpu1_ns_pa_addr(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 03ec6d307c82..4cfc4f9b2c69 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -213,11 +213,6 @@ static void __init save_l2x0_context(void)
{}
#endif
-u32 omap4_get_cpu1_ns_pa_addr(void)
-{
- return old_cpu1_ns_pa_addr;
-}
-
/**
* omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
* The purpose of this function is to manage low power programming
@@ -457,6 +452,11 @@ int __init omap4_mpuss_init(void)
#endif
+u32 omap4_get_cpu1_ns_pa_addr(void)
+{
+ return old_cpu1_ns_pa_addr;
+}
+
/*
* For kexec, we must set CPU1_WAKEUP_NS_PA_ADDR to point to
* current kernel's secondary_startup() early before
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 3faf454ba487..33e4953c61a8 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -306,7 +306,6 @@ static void __init omap4_smp_maybe_reset_cpu1(struct omap_smp_config *c)
cpu1_startup_pa = readl_relaxed(cfg.wakeupgen_base +
OMAP_AUX_CORE_BOOT_1);
- cpu1_ns_pa_addr = omap4_get_cpu1_ns_pa_addr();
/* Did the configured secondary_startup() get overwritten? */
if (!omap4_smp_cpu1_startup_valid(cpu1_startup_pa))
@@ -316,9 +315,13 @@ static void __init omap4_smp_maybe_reset_cpu1(struct omap_smp_config *c)
* If omap4 or 5 has NS_PA_ADDR configured, CPU1 may be in a
* deeper idle state in WFI and will wake to an invalid address.
*/
- if ((soc_is_omap44xx() || soc_is_omap54xx()) &&
- !omap4_smp_cpu1_startup_valid(cpu1_ns_pa_addr))
- needs_reset = true;
+ if ((soc_is_omap44xx() || soc_is_omap54xx())) {
+ cpu1_ns_pa_addr = omap4_get_cpu1_ns_pa_addr();
+ if (!omap4_smp_cpu1_startup_valid(cpu1_ns_pa_addr))
+ needs_reset = true;
+ } else {
+ cpu1_ns_pa_addr = 0;
+ }
if (!needs_reset || !c->cpu1_rstctrl_va)
return;
--
2.9.0
^ permalink raw reply related
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Santosh Shilimkar @ 2017-04-21 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1mPgM4XmS398DPsSbyCyD=12xQfUrF_HRqyd52_21o7Q@mail.gmail.com>
+Dave,
On 4/21/2017 2:44 PM, Arnd Bergmann wrote:
> On Fri, Apr 21, 2017 at 11:02 PM, santosh.shilimkar at oracle.com
> <santosh.shilimkar@oracle.com> wrote:
>> On 4/21/17 2:31 AM, Arnd Bergmann wrote:
[...]
>>> arm-soc/next/drivers:
>>> ae3874cc931b ARM: keystone: Drop PM domain support for k2g
>>> 52835d59fc6c soc: ti: Add ti_sci_pm_domains driver
>>> 7cc119f29b19 dt-bindings: Add TI SCI PM Domains
>>> 213ec7fed302 PM / Domains: Do not check if simple providers have phandle
>>> cells
>>> a5ea7a0fcbd7 PM / Domains: Add generic data pointer to genpd data struct
>>>
>> Above are the correct git object for which I sent pull request for.
>
> Ok, good, thanks for checking! They are however the commits that
> contain the silly https://urldefense.proofpoint.com URLs. Can you
> send a follow-up patch to fix these and use the regular https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ti.org&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=XBn1JQGPwR8CsE7xpP3wPlG6DQU7qw8ym65xieNZ4hY&m=vFHOEb7p2FxbH00YRQq4WnRiu2BKHADn0gl6e6DoNFQ&s=7mfiIp2Ywy9_ppWKjEGlrswiKRndv8_I7zGVF9uyT0w&e=
> URL that is in linux-next?
>
Dave,
Any reason you changed these URLs in last version ?
Can you please fixup these URLs to along with DT defines.
Regards,
Santosh
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Santosh Shilimkar @ 2017-04-21 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1721375.qoxY63CZOC@aspire.rjw.lan>
On 4/21/2017 2:31 PM, Rafael J. Wysocki wrote:
> On Friday, April 21, 2017 02:02:35 PM santosh.shilimkar at oracle.com wrote:
>>
>> On 4/21/17 2:31 AM, Arnd Bergmann wrote:
>>> On Fri, Apr 21, 2017 at 8:39 AM, santosh.shilimkar at oracle.com
[...]
>>> I still see two conflicting trees in linux-next as of today, neither of
>>> them is your keystone tree:
>>>
>> In the list it was agreed that the patchset goes via arm-soc tree.
>
> OK, I missed that when I looked at it again a couple of days ago, sorry.
>
NP.
> I'll drop it from the pm-domains branch.
>
Thanks for clarification.
Regards,
Santosh
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Arnd Bergmann @ 2017-04-21 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e2f9efab-291f-1436-2176-0fff3f2aae3f@oracle.com>
On Fri, Apr 21, 2017 at 11:02 PM, santosh.shilimkar at oracle.com
<santosh.shilimkar@oracle.com> wrote:
> On 4/21/17 2:31 AM, Arnd Bergmann wrote:
>>
>> On Fri, Apr 21, 2017 at 8:39 AM, santosh.shilimkar at oracle.com
>> <santosh.shilimkar@oracle.com> wrote:
>>>
>>> On 4/20/17 10:53 PM, Arnd Bergmann wrote:
>>>>
>>>>
>>>> On Fri, Apr 21, 2017 at 2:54 AM, Stephen Rothwell <sfr@canb.auug.org.au>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Today's linux-next merge of the pm tree got a conflict in:
>>>>>
>>>>> include/dt-bindings/genpd/k2g.h
>>>>>
>>>>> between commit:
>>>>>
>>>>> 7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains")
>>>>>
>>>>> from the arm-soc tree and commit:
>>>>>
>>>>> 45da8edd1741 ("dt-bindings: Add TI SCI PM Domains")
>>>>>
>>>>> from the pm tree.
>>>>>
>>>>> I fixed it up (I just used the pm tree version) and can carry the fix
>>>>> as
>>>>> necessary. This is now fixed as far as linux-next is concerned, but any
>>>>> non trivial conflicts should be mentioned to your upstream maintainer
>>>>> when your tree is submitted for merging. You may also want to consider
>>>>> cooperating with the maintainer of the conflicting tree to minimise any
>>>>> particularly complex conflicts.
>>>>
>>>>
>>>>
>>>> Dave, Santosh,
>>>>
>>>> any idea what happened here? It seems that we picked up the wrong
>>>> version of the tree, do we need to drop this from arm-soc?
>>>>
>>> Nope. Its because this series was in my 'next' branch for a week or
>>> so and now it made it via arm-soc tree next as well.
>>>
>>> I just cleaned up my next head so it linux-next next tag should have
>>> only arm-soc copy.
>>
>>
>> I still see two conflicting trees in linux-next as of today, neither of
>> them is your keystone tree:
>>
> In the list it was agreed that the patchset goes via arm-soc tree.
>
> ae3874c ARM: keystone: Drop PM domain support for k2g
> 52835d5 soc: ti: Add ti_sci_pm_domains driver
> 7cc119f dt-bindings: Add TI SCI PM Domains
> 213ec7f PM / Domains: Do not check if simple providers have phandle cells
> a5ea7a0 PM / Domains: Add generic data pointer to genpd data struct
>
>> arm-soc/next/drivers:
>> ae3874cc931b ARM: keystone: Drop PM domain support for k2g
>> 52835d59fc6c soc: ti: Add ti_sci_pm_domains driver
>> 7cc119f29b19 dt-bindings: Add TI SCI PM Domains
>> 213ec7fed302 PM / Domains: Do not check if simple providers have phandle
>> cells
>> a5ea7a0fcbd7 PM / Domains: Add generic data pointer to genpd data struct
>>
> Above are the correct git object for which I sent pull request for.
Ok, good, thanks for checking! They are however the commits that
contain the silly https://urldefense.proofpoint.com URLs. Can you
send a follow-up patch to fix these and use the regular http://www.ti.org
URL that is in linux-next?
Arnd
^ permalink raw reply
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Fabio Estevam @ 2017-04-21 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1998934.0RuxqCUAOW@aspire.rjw.lan>
On Fri, Apr 21, 2017 at 6:28 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Friday, April 21, 2017 01:11:52 PM Fabio Estevam wrote:
>> Hi,
>>
>> Running 4.11-rc7 on a imx6q-sabresd board I notice that egalax
>> touchscreen stops generating evtest events after a random period of
>> time.
>>
>> This problem can be avoided if I unselect CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND:
>>
>> --- a/arch/arm/configs/imx_v6_v7_defconfig
>> +++ b/arch/arm/configs/imx_v6_v7_defconfig
>> @@ -54,7 +54,6 @@ CONFIG_CMA=y
>> CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
>> CONFIG_KEXEC=y
>> CONFIG_CPU_FREQ=y
>> -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
>> CONFIG_ARM_IMX6Q_CPUFREQ=y
>> CONFIG_CPU_IDLE=y
>> CONFIG_VFP=y
>>
>> With this change evtest always capture all touchscreen events. No
>> single failure is seen.
>>
>> I could see the same behavior with all mainline kernels I tested (4.9 and 4.10).
>>
>> Any ideas as to how fix this bug when CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y?
>
> And which governor is the default otherwise?
When CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y is removed then the
'performance' governor is the default.
Thanks
^ permalink raw reply
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Rafael J. Wysocki @ 2017-04-21 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C776E3AqnhPPJSTF=atuOHi5Mok7F7yocBhRsJ6Ror2A@mail.gmail.com>
On Friday, April 21, 2017 06:37:31 PM Fabio Estevam wrote:
> On Fri, Apr 21, 2017 at 6:28 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Friday, April 21, 2017 01:11:52 PM Fabio Estevam wrote:
> >> Hi,
> >>
> >> Running 4.11-rc7 on a imx6q-sabresd board I notice that egalax
> >> touchscreen stops generating evtest events after a random period of
> >> time.
> >>
> >> This problem can be avoided if I unselect CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND:
> >>
> >> --- a/arch/arm/configs/imx_v6_v7_defconfig
> >> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> >> @@ -54,7 +54,6 @@ CONFIG_CMA=y
> >> CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
> >> CONFIG_KEXEC=y
> >> CONFIG_CPU_FREQ=y
> >> -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> >> CONFIG_ARM_IMX6Q_CPUFREQ=y
> >> CONFIG_CPU_IDLE=y
> >> CONFIG_VFP=y
> >>
> >> With this change evtest always capture all touchscreen events. No
> >> single failure is seen.
> >>
> >> I could see the same behavior with all mainline kernels I tested (4.9 and 4.10).
> >>
> >> Any ideas as to how fix this bug when CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y?
> >
> > And which governor is the default otherwise?
>
> When CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y is removed then the
> 'performance' governor is the default.
There you go. Apparently, using frequencies below the max causes problems to
happen in the SoC.
Thanks,
Rafael
^ 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