* [PATCH 5/5] ARM: dts: imx7-colibri: add NAND support
From: Stefan Agner @ 2017-04-21 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421010755.18025-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 4/5] ARM: dts: imx7: add GPMI NAND
From: Stefan Agner @ 2017-04-21 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421010755.18025-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 3/5] mtd: gpmi: document current clock requirements
From: Stefan Agner @ 2017-04-21 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421010755.18025-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 2/5] mtd: nand: gpmi: add i.MX 7 SoC support
From: Stefan Agner @ 2017-04-21 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421010755.18025-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 6SoloX, but currently
none of this differences are in use so there is no detection needed
and the driver can reuse IS_MX6SX.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index c8bbf5da2ab8..4a45d37ddc80 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_MX6SX,
+ .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);
--
2.12.2
^ permalink raw reply related
* [PATCH 1/5] mtd: nand: gpmi: unify clock handling
From: Stefan Agner @ 2017-04-21 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421010755.18025-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>
---
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..2e584e18d980 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;
+ int clks_count;
};
struct gpmi_nand_data {
--
2.12.2
^ permalink raw reply related
* [PATCH 0/5] mtd: nand: gpmi: add i.MX 7 support
From: Stefan Agner @ 2017-04-21 1:07 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
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 | 2 +
5 files changed, 88 insertions(+), 24 deletions(-)
--
2.12.2
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Stephen Rothwell @ 2017-04-21 0:54 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Stephen Rothwell @ 2017-04-21 0:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in:
drivers/soc/ti/ti_sci_pm_domains.c
between commit:
52835d59fc6c ("soc: ti: Add ti_sci_pm_domains driver")
from the arm-soc tree and commit:
112572283742 ("soc: ti: Add ti_sci_pm_domains driver")
from the pm tree.
I fixed it up (I used the pm tree version, but it was an arbitrary
choice as the only difference is the URL in the Copyright line) 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.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH 1/4] mmc: pxamci: Use the right flags for DMA callback init
From: Petr Cvek @ 2017-04-21 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fbc663e3-4de5-7370-afa8-0f8747f50ca7@tul.cz>
Dne 19.4.2017 v 01:16 Petr Cvek napsal(a):
> The MMC_DATA_READ and the MMC_DATA_WRITE flags for the mmc request are not
> mutually exclusive (two different bits). Change the callback initialization
> code to use the proper one.
>
> Signed-off-by: Petr Cvek <petr.cvek@tul.cz>
It seems I forgot to patch a code in the pxamci_setup_data():
config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
config.src_addr = host->res->start + MMC_RXFIFO;
config.dst_addr = host->res->start + MMC_TXFIFO;
config.src_maxburst = 32;
config.dst_maxburst = 32;
if (data->flags & MMC_DATA_READ) {
host->dma_dir = DMA_FROM_DEVICE;
direction = DMA_DEV_TO_MEM;
chan = host->dma_chan_rx;
} else {
host->dma_dir = DMA_TO_DEVICE;
direction = DMA_MEM_TO_DEV;
chan = host->dma_chan_tx;
}
I will add it in v2 series.
Just curious: why does the MMC_DATA_READ/MMC_DATA_WRITE flag occupies two bits anyway is there a hardware which can do both request at the same time?
BTW that config.* block should be IMO split and moved into that if(){} too (as the PXA27x do only one DMA direction at the time).
Petr
^ permalink raw reply
* [PATCH 3/4] mmc: pxamci: Disable DATA_TRAN_DONE interrupt sooner
From: Petr Cvek @ 2017-04-20 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k26g6whu.fsf@belgarion.home>
Dne 19.4.2017 v 21:14 Robert Jarzmik napsal(a):
> Petr Cvek <petr.cvek@tul.cz> writes:
>
>> Disable the DATA_TRAN_DONE interrupt as soon as possible in the handler.
> Yeah, but why, please explain.
> If that's only to "reduce" the race occurrence, then I'd rather have this patch
> dropped. Otherwise if there is a compelling reason let's see ...
>
I created it during researching where put the IRQ enable in the callback and then I left it that way the data done interrupt will be disabled if there was an error at the beginning of the pxamci_data_done().
I dropped the patch and re-tested and it works (in the case the tests at the start of the pxamci_data_done() fail there will be probably some irq hell though :-D).
> Cheers.
>
^ permalink raw reply
* [PATCH v4 02/11] clk: sunxi-ng: add support for DE2 CCU
From: Rob Herring @ 2017-04-20 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420143617.v6yemhjamqufbqwj@lukather>
On Thu, Apr 20, 2017 at 9:36 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Rob,
>
> On Thu, Apr 20, 2017 at 09:02:53AM -0500, Rob Herring wrote:
>> On Sun, Apr 16, 2017 at 08:08:40PM +0800, Icenowy Zheng wrote:
>> > diff --git a/include/dt-bindings/clock/sun8i-de2.h b/include/dt-bindings/clock/sun8i-de2.h
>> > new file mode 100644
>> > index 000000000000..982c6d18c75b
>> > --- /dev/null
>> > +++ b/include/dt-bindings/clock/sun8i-de2.h
>> > @@ -0,0 +1,54 @@
>> > +/*
>> > + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.io>
>> > + *
>> > + * This file is dual-licensed: you can use it either under the terms
>> > + * of the GPL or the X11 license, at your option. Note that this dual
>> > + * licensing only applies to this file, and not this project as a
>> > + * whole.
>> > + *
>> > + * a) This file 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.
>> > + *
>> > + * This file 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.
>> > + *
>> > + * Or, alternatively,
>> > + *
>> > + * b) Permission is hereby granted, free of charge, to any person
>> > + * obtaining a copy of this software and associated documentation
>> > + * files (the "Software"), to deal in the Software without
>> > + * restriction, including without limitation the rights to use,
>> > + * copy, modify, merge, publish, distribute, sublicense, and/or
>> > + * sell copies of the Software, and to permit persons to whom the
>> > + * Software is furnished to do so, subject to the following
>> > + * conditions:
>> > + *
>> > + * The above copyright notice and this permission notice shall be
>> > + * included in all copies or substantial portions of the Software.
>> > + *
>> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> > + * OTHER DEALINGS IN THE SOFTWARE.
>> > + */
>>
>> You can use SPDX tag here:
>>
>> SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> I don't think you ever addressed Russell's comment about what would
> happen to the license if and when the SPDX doc is changed or goes
> offline?
Frankly, it's a copyright holders decision what they want to use. SPDX
is already used in the kernel. Look in the USB subsystem. SPDX is not
going anywhere and is endorsed by companies with well known legal
depts. If people want to argue about it still, then I've got better
things to do.
Rob
^ permalink raw reply
* [PATCH 2/2] ARM: dts: mvebu: disable the rtc on 98dx3236 SoC
From: Chris Packham @ 2017-04-20 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420215814.6817-1-chris.packham@alliedtelesis.co.nz>
There is no rtc for the 98dx3236 and derivative SoCs. Disable the rtc
node inherited from the armada-370-xp base.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index 84cc232a29e9..be22ec5236ac 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -311,6 +311,10 @@
reg = <0x20a00 0x2d0>, <0x21070 0x58>;
};
+&rtc {
+ status = "disabled";
+};
+
&timer {
compatible = "marvell,armada-xp-timer";
clocks = <&coreclk 2>, <&refclk>;
--
2.11.0.24.ge6920cf
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: mvebu: add missing interrupt to 98dx4251 switch
From: Chris Packham @ 2017-04-20 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420215814.6817-1-chris.packham@alliedtelesis.co.nz>
The 98dx4251 has 4 interrupts for the packet processor whereas the
98dx3236 and 98dx3336 only have 3.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
index 51de91b31a9d..bc9f824020eb 100644
--- a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
@@ -87,4 +87,5 @@
&pp0 {
compatible = "marvell,prestera-98dx4251";
+ interrupts = <33>, <34>, <35>, <36>;
};
--
2.11.0.24.ge6920cf
^ permalink raw reply related
* [PATCH 0/2] ARM: dts: mvebu: dts updates for 98dx3236/98dx4251
From: Chris Packham @ 2017-04-20 21:58 UTC (permalink / raw)
To: linux-arm-kernel
A couple of minor updates for the 98dx3236 and 98dx4251.
Chris Packham (2):
ARM: dts: mvebu: add missing interrupt to 98dx4251 switch
ARM: dts: mvebu: disable the rtc on 98dx3236 SoC
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 4 ++++
arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 1 +
2 files changed, 5 insertions(+)
--
2.11.0.24.ge6920cf
^ permalink raw reply
* [PATCH] ARM: dts: bcm-cygnus: Add 911360's V3D device.
From: Scott Branden @ 2017-04-20 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418233234.13374-1-eric@anholt.net>
Looks good - thanks for getting the V3D open source code going on this SoC!
On 17-04-18 04:32 PM, Eric Anholt wrote:
> This loads the VC4 driver on the 911360_entphn platform (with the
> corresponding series sent to dri-devel), which is supported by master
> of the Mesa tree.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Scott Branden <scott.branden@broadcom.com>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 13 +++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 ++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index f52750c6d3ed..907a5e843364 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -406,6 +406,19 @@
> status = "disabled";
> };
>
> + v3d: v3d at 180a2000 {
> + compatible = "brcm,cygnus-v3d";
> + reg = <0x180a2000 0x1000>;
> + clocks = <&mipipll BCM_CYGNUS_MIPIPLL_CH2_V3D>;
> + clock-names = "v3d_clk";
> + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + vc4: gpu {
> + compatible = "brcm,cygnus-vc4";
> + };
> +
> adc: adc at 180a6000 {
> compatible = "brcm,iproc-static-adc";
> #io-channel-cells = <1>;
> diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts b/arch/arm/boot/dts/bcm911360_entphn.dts
> index 8b3800f46288..037621c13290 100644
> --- a/arch/arm/boot/dts/bcm911360_entphn.dts
> +++ b/arch/arm/boot/dts/bcm911360_entphn.dts
> @@ -57,6 +57,14 @@
> };
> };
>
> +&v3d {
> + assigned-clocks =
> + <&mipipll BCM_CYGNUS_MIPIPLL>,
> + <&mipipll BCM_CYGNUS_MIPIPLL_CH2_V3D>;
> + assigned-clock-rates = <525000000>, <300000000>;
> + status = "okay";
> +};
> +
> &uart3 {
> status = "okay";
> };
>
^ permalink raw reply
* [Bug] VCHIQ functional test broken
From: Eric Anholt @ 2017-04-20 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420195822.GA22677@laptop>
Rabin Vincent <rabin@rab.in> writes:
> On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
>> I'm confused by what you're saying here. The driver has already been
>> converted to not use dmac_map_area (commit
>> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
>> matching the radeon driver you give as a model as far as I can see.
>> That commit is in v4.11-rc6 from Stefan's regression report.
>
> Right. Sorry. I must have had an old tag checked out when I looked at
> the driver earlier. The DMA API usage in the driver in v4.11-rc6 and
> current master looks fine, except for one thing:
>
> The flush in flush_dcache_page() (from get_user_pages()) was done with a
> v6_flush_kern_dcache_page() which always did a clean+invalidate while
> the DMA API only does what is required by the direction, which is only a
> invalidate for DMA_FROM_DEVICE. Since the driver calls dma_from_sg() on
> the entire page, even if userspace sent in an offset into the page,
> unrelated data in userspace may be thrown away.
>
> Does changing the dma API calls to always use DMA_BIDIRECTIONAL make the
> test pass?
Oh, that's a neat explanation for what might be wrong, and there seem to
be tests trying to poke at that within the functional test code.
Hopefully Stefan can try that out.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170420/c55cf587/attachment-0001.sig>
^ permalink raw reply
* [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO
From: dann frazier @ 2017-04-20 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1490887619-61732-6-git-send-email-yuanzhichang@hisilicon.com>
On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan
<yuanzhichang@hisilicon.com> wrote:
> On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O
> with some special host-local I/O ports known on x86. To access the I/O
> peripherals, an indirect-IO mechanism is introduced to mapped the host-local
> I/O to system logical/fake PIO similar the PCI MMIO on architectures where no
> separate I/O space exists. Just as PCI MMIO, the host I/O range should be
> registered before probing the downstream devices and set up the I/O mapping.
> But current ACPI bus probing doesn't support these indirect-IO hosts/devices.
>
> This patch introdueces a new ACPI handler for this device category. Through the
> handler attach callback, the indirect-IO hosts I/O registration is done and
> all peripherals' I/O resources are translated into logic/fake PIO before
> starting the enumeration.
>
> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> ---
> drivers/acpi/Makefile | 1 +
> drivers/acpi/acpi_indirectio.c | 344 +++++++++++++++++++++++++++++++++++++++++
> drivers/acpi/internal.h | 5 +
> drivers/acpi/scan.c | 1 +
> 4 files changed, 351 insertions(+)
> create mode 100644 drivers/acpi/acpi_indirectio.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index a391bbc..10e5f2b 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> acpi-y += acpi_lpat.o
> acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
> +acpi-$(CONFIG_INDIRECT_PIO) += acpi_indirectio.o
>
> # These are (potentially) separate modules
>
> diff --git a/drivers/acpi/acpi_indirectio.c b/drivers/acpi/acpi_indirectio.c
> new file mode 100644
> index 0000000..c8c80b5
> --- /dev/null
> +++ b/drivers/acpi/acpi_indirectio.c
> @@ -0,0 +1,344 @@
> +/*
> + * ACPI support for indirect-IO bus.
> + *
> + * Copyright (C) 2017 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/platform_device.h>
> +#include <linux/logic_pio.h>
> +
> +#include "internal.h"
> +
> +ACPI_MODULE_NAME("indirect IO");
> +
> +#define INDIRECT_IO_INFO(desc) ((unsigned long)&desc)
> +
> +struct lpc_private_data {
> + resource_size_t io_size;
> + resource_size_t io_start;
> +};
> +
> +struct indirectio_device_desc {
> + void *pdata; /* device relevant info data */
> + int (*pre_setup)(struct acpi_device *adev, void *pdata);
> +};
> +
> +static struct lpc_private_data lpc_data = {
> + .io_size = LPC_BUS_IO_SIZE,
> + .io_start = LPC_MIN_BUS_RANGE,
> +};
> +
> +static inline bool acpi_logicio_supported_resource(struct acpi_resource *res)
> +{
> + switch (res->type) {
> + case ACPI_RESOURCE_TYPE_ADDRESS32:
> + case ACPI_RESOURCE_TYPE_ADDRESS64:
> + return true;
> + }
> + return false;
> +}
> +
> +static acpi_status acpi_count_logiciores(struct acpi_resource *res,
> + void *data)
> +{
> + int *res_cnt = data;
> +
> + if (acpi_logicio_supported_resource(res) &&
> + !acpi_dev_filter_resource_type(res, IORESOURCE_IO))
> + (*res_cnt)++;
> +
> + return AE_OK;
> +}
> +
> +static acpi_status acpi_read_one_logiciores(struct acpi_resource *res,
> + void *data)
> +{
> + struct acpi_resource **resource = data;
> +
> + if (acpi_logicio_supported_resource(res) &&
> + !acpi_dev_filter_resource_type(res, IORESOURCE_IO)) {
> + memcpy((*resource), res, sizeof(struct acpi_resource));
> + (*resource)->length = sizeof(struct acpi_resource);
> + (*resource)->type = res->type;
> + (*resource)++;
> + }
> +
> + return AE_OK;
> +}
> +
> +static acpi_status
> +acpi_build_logiciores_template(struct acpi_device *adev,
> + struct acpi_buffer *buffer)
> +{
> + acpi_handle handle = adev->handle;
> + struct acpi_resource *resource;
> + acpi_status status;
> + int res_cnt = 0;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_count_logiciores, &res_cnt);
> + if (ACPI_FAILURE(status) || !res_cnt) {
> + dev_err(&adev->dev, "can't evaluate _CRS: %d\n", status);
> + return -EINVAL;
> + }
> +
> + buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
> + buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);
(Seth Forshee noticed this issue, just passing it on)
Should this just allocate the full buffer->length? That would keep the
length attribute accurate (possibly avoiding an off-by-1 error later).
It's not clear what the trailing byte is needed for, but other drivers
allocate it as well (drivers/acpi/pci_link.c and
drivers/platform/x86/sony-laptop.c).
-dann
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Doug Anderson @ 2017-04-20 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a87a97io.fsf@eliezer.anholt.net>
Hi,
On Thu, Apr 20, 2017 at 12:57 PM, Eric Anholt <eric@anholt.net> wrote:
> Doug Anderson <dianders@chromium.org> writes:
>
>> Hi,
>>
>> On Thu, Apr 20, 2017 at 11:54 AM, Eric Anholt <eric@anholt.net> wrote:
>>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>>
>>>> Hi,
>>>>
>>>>> Doug Anderson <dianders@chromium.org> hat am 18. April 2017 um 22:41 geschrieben:
>>>>>
>>>>>
>>>>> It's hard to know for sure that all of this time is really in
>>>>> urb_enqueue(). Possible we could have task switched out and been
>>>>> blocked elsewhere. Using ftrace to get more fine-grained timings
>>>>> would be useful. ktime_get(), ktime_sub(), and ktime_to_us() are your
>>>>> friends here if you want to use trace_printk.
>>>>
>>>> i'm a newbie to ftrace, so i hope this would be helpful.
>>>>
>>>> # connect PL2303 to the onboard hub
>>>> # echo 0 > options/sleep-time
>>>> # echo 0 > function_profile_enabled
>>>> # echo 1 > function_profile_enabled
>>>> # ./usb_test
>>>> # Waiting for at least 20 seconds and then disconnect PL2303
>>>> # echo 0 > function_profile_enabled
>>>> # cat trace_stat/function0
>>>>
>>>> Function Hit Time Avg s^2
>>>> -------- --- ---- --- ---
>>>> bcm2835_handle_irq 361347 219567633 us 607.636 us 1485199 us
>>>> __handle_domain_irq 1082482 212639551 us 196.437 us 3642030 us
>>>> generic_handle_irq 1082482 100592051 us 92.927 us 50511334 us
>>>> irq_exit 1082482 98197771 us 90.715 us 29649040 us
>>>> handle_level_irq 1082482 95812379 us 88.511 us 51910093 us
>>>
>>> If I'm reading this output right, we're spending half of our interrupt
>>> processing time in irq_exit(), so even if dwc2's interrupt was free (the
>>> generic_handle_irq() chain), we'd be eating about half the CPU getting
>>> back out of the interrupt handler, right?
>>>
>>> I don't really know anything about DWC2 or USB, but is there any way we
>>> could mitigate the interrupt frequency with this hardware? If nothing
>>> else, could we loop reading gintsts until it reads back 0?
>>
>> Take ftrace with a little bit of a grain of salt, especially on older
>> / slower ARMs (without the arch timer). Whenever ftrace takes a log
>> it grabs a timestamp. This can be an expensive (ish) operation. Even
>> on newer CPUs it's still not free if you call it as much as ftrace,
>> but on older CPUs it's extra expensive.
>
> If per-function timestamp cost was the problem, shouldn't I expect to
> see a bunch of irq_exit()'s children each taking a bit of time? We have
> a long callchain with the functions each taking a bit of time in the
> dwc2 interrupt handler, but irq_exit() seems to be a monolithic cost.
Maybe. I remember some of the timestamp code being a might bit odd.
Specifically there might have been cases where the timestamp code
predictable slower in some cases, but that slowness would be blamed on
the wrong function. I think this might have to do with some of the
the fact that a memory mapped read could block until other outstanding
memory mapped operations finished.
-Doug
^ permalink raw reply
* [PATCH V5 4/7] ARM: pxa: Use - instead of @ for DT OPP entries
From: Robert Jarzmik @ 2017-04-20 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <741bc9af28d6968e6a9409f94681066db5d1228b.1492685450.git.viresh.kumar@linaro.org>
Viresh Kumar <viresh.kumar@linaro.org> writes:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v4)
From: Eric Anholt @ 2017-04-20 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c076a1e-267a-1a66-7cc0-9dd5bf59c5a8@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> writes:
> On 03/29/2017 05:26 PM, Eric Anholt wrote:
>> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
>> now, so it's useful to be able to test that mode on an upstream
>> kernel. It's also been useful for me to use the same board for 32-bit
>> and 64-bit development.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>
>> v1: Gerd's patch that put the ../../../arm64/... link in the Makefile
>> v2: Michael's patch that #included from ../../../arm64/... in a new
>> bcm2837-rpi-3-b.dts.
>> v3: Mine, using symlinks to make sure that we don't break the split DT
>> tree.
>> v4: Rely on the new include/arm64 symlink.
>>
>> Assuming positive review feedback, I assume it would be acceptable to
>> merge the shared/dt-symlinks branch in a PR of my own for the 32-bit
>> DT branch?
>
> Either that, or I can take it directly through devicetree/next whichever
> you prefer. We have not gotten feedback on whether this looks acceptable
> or not though...
I would love if you could pull this patch, but it does require
shared/dt-symlinks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170420/ece011ff/attachment.sig>
^ permalink raw reply
* stmmac still supporting spear600 ?
From: Thomas Petazzoni @ 2017-04-20 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412150558.57c865e5@free-electrons.com>
Viresh, Shiraz,
As the SPEAr600 platform maintainers, have you tested Ethernet in
recent times, especially with a MII PHY ? I'm still struggling to get
it working. Quick summary:
- The same kernel works fine on another SPEAr600 platform that has a
GMII PHY
- The SPEAr600 platform with a MII PHY has Ethernet working fine under
U-Boot (TFTP works), so the HW is known to be working.
- I've compared the values of the MAC registers between U-Boot and
Linux, and traced all the PHY registers read/write over the MDIO
bus, and compared the traces between U-Boot and Linux. Found a few
differences, but solving them didn't change the problem.
I'm suspecting the problem is not directly in the MAC/PHY
configuration. Would you have some hints like clock configuration, or
other system-level configuration that could affect this? Especially the
TXCLK from the PHY is not coming in through the same pin when in GMII
and MII mode it seems. Does this needs some special configuration?
Any hint/idea would definitely be welcome.
Thanks a lot!
Thomas
On Wed, 12 Apr 2017 15:05:58 +0200, Thomas Petazzoni wrote:
> Hello,
>
> Thanks again for your answer, sorry for the delay, I was away from the
> spear600 board for a while.
>
> On Mon, 3 Apr 2017 08:16:50 +0200, Giuseppe CAVALLARO wrote:
>
> > I tested the SMSC on other platform (+ stmmac), not on SPEAr.
>
> OK. But I believe there might be a SPEAr specific issue here, which
> might explain why you don't reproduce the problem.
>
> > ok for reset, keep the radar on clock. Hmm, can you attach a piece of
> > log file to see the failure?
>
> During the boot, nothing bad:
>
> libphy: Fixed MDIO Bus: probed
> stmmaceth e0800000.ethernet: no reset control found
> stmmac - user ID: 0x10, Synopsys ID: 0x32
> Ring mode enabled
> DMA HW capability register supported Normal descriptors
> libphy: stmmac: probed
> eth0: PHY ID 0007c0c4 at 31 IRQ POLL (stmmac-0:1f) active
>
> Then, when upping the interface:
>
> # ifconfig eth0 up
> eth0: device MAC address 00:30:d3:21:22:60
> stmmaceth e0800000.ethernet: Failed to reset the dma
> stmmac_hw_setup: DMA engine initialization failed
> stmmac_open: Hw setup failed
> SIOCSIFFLAGS: Device or resource busy
>
> As I said earlier, the "Failed to reset the dma" is because
> dwmac_dma_reset() returns -EBUSY because the DMA reset bit never
> clears. Again, we see the same behavior in U-Boot (DMA reset bit never
> clears), but Ethernet does work in U-Boot.
>
> Best regards,
>
> Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2 1/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver
From: Priit Laes @ 2017-04-20 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170407133805.aiythp3hdvuyhcrc@lukather>
On Fri, Apr 07, 2017 at 03:38:05PM +0200, Maxime Ripard wrote:
> Hi Priit,
>
> On Tue, Apr 04, 2017 at 08:09:19PM +0000, Priit Laes wrote:
> > > > +/* Not documented on A10 */
> > > > +static SUNXI_CCU_GATE(pll_periph_sata_clk, "pll-periph-sata", "pll-periph",
> > > > + 0x028, BIT(14), 0);
> > >
> > > The rate doesn't come from pll-periph directly, does it?
> >
> > So it uses hosc (24MHz parent clock) instead of pll-periph?
>
> I never looked too much at this, but it looks more like the input is
> pll-periph-sata itself.
OK, I think I have now fixed most of the issues thanks to Maxime and Chen-Yu
and I'm almost ready to send out V3.
>From my side there is only single issue remaining - how to create "sata-ext"
clock?
[snip]
static struct ccu_div pll_periph_sata_clk = {
.enable = BIT(14),
.div = _SUNXI_CCU_DIV(0, 2),
.common = {
.prediv = 6,
.reg = 0x028,
.features = CCU_FEATURE_ALL_PREDIV,
.hw.init = CLK_HW_INIT("pll-periph-sata",
"pll-periph-base",
&ccu_nk_ops, 0),
},
};
static const char* const sata_parents[] = {"pll-periph-sata", "sata-ext"};
static SUNXI_CCU_MUX_WITH_GATE(sata_clk, "sata", sata_parents,
0x0c8, 24, 1, BIT(31), 0);
[/snip]
Should I create a fixed-clock node in the dtsi:
sata-ext: clk at 0 {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <200000000>;
clock-output-names = "sata-ext";
};
And would it also need pio definition?
P?ikest,
Priit :)
^ permalink raw reply
* [Bug] VCHIQ functional test broken
From: Rabin Vincent @ 2017-04-20 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87pog7x7c5.fsf@eliezer.anholt.net>
On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
> I'm confused by what you're saying here. The driver has already been
> converted to not use dmac_map_area (commit
> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
> matching the radeon driver you give as a model as far as I can see.
> That commit is in v4.11-rc6 from Stefan's regression report.
Right. Sorry. I must have had an old tag checked out when I looked at
the driver earlier. The DMA API usage in the driver in v4.11-rc6 and
current master looks fine, except for one thing:
The flush in flush_dcache_page() (from get_user_pages()) was done with a
v6_flush_kern_dcache_page() which always did a clean+invalidate while
the DMA API only does what is required by the direction, which is only a
invalidate for DMA_FROM_DEVICE. Since the driver calls dma_from_sg() on
the entire page, even if userspace sent in an offset into the page,
unrelated data in userspace may be thrown away.
Does changing the dma API calls to always use DMA_BIDIRECTIONAL make the
test pass?
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Eric Anholt @ 2017-04-20 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=XKkKr5ZeU098Co4JDRfa-Sv6dvZ-kt-c8Ui9_SfHjRkQ@mail.gmail.com>
Doug Anderson <dianders@chromium.org> writes:
> Hi,
>
> On Thu, Apr 20, 2017 at 11:54 AM, Eric Anholt <eric@anholt.net> wrote:
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>>> Hi,
>>>
>>>> Doug Anderson <dianders@chromium.org> hat am 18. April 2017 um 22:41 geschrieben:
>>>>
>>>>
>>>> It's hard to know for sure that all of this time is really in
>>>> urb_enqueue(). Possible we could have task switched out and been
>>>> blocked elsewhere. Using ftrace to get more fine-grained timings
>>>> would be useful. ktime_get(), ktime_sub(), and ktime_to_us() are your
>>>> friends here if you want to use trace_printk.
>>>
>>> i'm a newbie to ftrace, so i hope this would be helpful.
>>>
>>> # connect PL2303 to the onboard hub
>>> # echo 0 > options/sleep-time
>>> # echo 0 > function_profile_enabled
>>> # echo 1 > function_profile_enabled
>>> # ./usb_test
>>> # Waiting for at least 20 seconds and then disconnect PL2303
>>> # echo 0 > function_profile_enabled
>>> # cat trace_stat/function0
>>>
>>> Function Hit Time Avg s^2
>>> -------- --- ---- --- ---
>>> bcm2835_handle_irq 361347 219567633 us 607.636 us 1485199 us
>>> __handle_domain_irq 1082482 212639551 us 196.437 us 3642030 us
>>> generic_handle_irq 1082482 100592051 us 92.927 us 50511334 us
>>> irq_exit 1082482 98197771 us 90.715 us 29649040 us
>>> handle_level_irq 1082482 95812379 us 88.511 us 51910093 us
>>
>> If I'm reading this output right, we're spending half of our interrupt
>> processing time in irq_exit(), so even if dwc2's interrupt was free (the
>> generic_handle_irq() chain), we'd be eating about half the CPU getting
>> back out of the interrupt handler, right?
>>
>> I don't really know anything about DWC2 or USB, but is there any way we
>> could mitigate the interrupt frequency with this hardware? If nothing
>> else, could we loop reading gintsts until it reads back 0?
>
> Take ftrace with a little bit of a grain of salt, especially on older
> / slower ARMs (without the arch timer). Whenever ftrace takes a log
> it grabs a timestamp. This can be an expensive (ish) operation. Even
> on newer CPUs it's still not free if you call it as much as ftrace,
> but on older CPUs it's extra expensive.
If per-function timestamp cost was the problem, shouldn't I expect to
see a bunch of irq_exit()'s children each taking a bit of time? We have
a long callchain with the functions each taking a bit of time in the
dwc2 interrupt handler, but irq_exit() seems to be a monolithic cost.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170420/7d2ce091/attachment.sig>
^ permalink raw reply
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Kees Cook @ 2017-04-20 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2C2WhWjzF=HrzU15Ncg0juR+nstZukBEpqCrVNW5pnDA@mail.gmail.com>
On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook <keescook@chromium.org> wrote:
>>>> The original gcc-4.3 release was in early 2008. If we decide to still
>>>> support that, we probably want the first 10 quirks in this series,
>>>> while gcc-4.6 (released in 2011) requires none of them.
>>
>> I'd be in support of raising the minimum to gcc 4.6. (I'd actually
>> prefer 4.7, just to avoid some 4.6 packaging issues, and for better
>> gcc plugin support.)
>>
>> I'm curious what gcc 4.6 binaries are common in the wild besides
>> old-stable Debian (unsupported in maybe a year from now?) and 12.04
>> Ubuntu (going fully unsupported in 2 weeks). It looks like 4.6 was
>> used only in Fedora 15 and 16 (both EOL).
>
> I think we are better off defining two versions: One that we know
> a lot of people care about, and we actively try to make that work
> well in all configurations (e.g. 4.6, 4.7 or 4.8), fixing all warnings
> we run into, and an older version that we try not to break
> intentionally (e.g. 3.4, 4.1 or 4.3) but that we only fix when
> someone actually runs into a problem they can't work around
> by upgrading to a more modern compiler.
For "working well everywhere" I feel like 4.8 is the better of those
three (I'd prefer 4.9). I think we should avoid 4.6 -- it seems not
widely used.
For an old compiler... yikes. 3.4 sounds insane to me. :)
-Kees
--
Kees Cook
Pixel Security
^ 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