* [PATCH RFC 0/5] mvebu cleanups and preparation for Armada 7k/8k
From: Russell King - ARM Linux @ 2017-01-13 11:02 UTC (permalink / raw)
To: linux-arm-kernel
(Resend including linux-arm-kernel)
This patch series cleans up the mvebu pin controller implementation
such that we can support multiple pin controllers as found in Armada
7k and 8k SoCs.
Currently, in order to do that, we would have to have static variables
and multiple implementations of functions whose only purpose is to
read from the correct static variable. This is caused by a lack of
driver private data passed into the mvebu pin controller's methods.
Most mvebu pin controllers methods are performing exactly the same
action, so it makes sense to generalise the methods, which in turn
lets us come up with a fairly standardised set of methods.
Another important side effect of these changes is that the structures
with function pointers are now marked const - as they should be in
today's security concious kernel programming environment.
I've included everything except the 7k and 8k drivers, which, before
Thomas went away, he suggested changes to these, so they aren't ready
for submission yet. However, the rest of the ground work is, and I'd
like users of this code to test it - I don't have all these platforms!
I'm aware of other mvebu SoC support, so I think it's probably a good
idea to get these patches out there and known about, so folk can
consider how they'd like to order merging the changes - obviously new
SoCs with new pinctrl files will need updates somewhere...
The cleanup side of these patches (without the last adding the regmap
support) shows a reduction in code size:
drivers/pinctrl/mvebu/pinctrl-armada-370.c | 24 +-------
drivers/pinctrl/mvebu/pinctrl-armada-375.c | 24 +-------
drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 24 +-------
drivers/pinctrl/mvebu/pinctrl-armada-39x.c | 24 +-------
drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 35 +++--------
drivers/pinctrl/mvebu/pinctrl-dove.c | 96 +++++++++++++++++-------------
drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 32 +++-------
drivers/pinctrl/mvebu/pinctrl-mvebu.c | 77 +++++++++++++++++++++---
drivers/pinctrl/mvebu/pinctrl-mvebu.h | 51 +++++++---------
drivers/pinctrl/mvebu/pinctrl-orion.c | 8 ++-
10 files changed, 183 insertions(+), 212 deletions(-)
Adding regmap support increases the code size again:
drivers/pinctrl/mvebu/pinctrl-armada-370.c | 24 +----
drivers/pinctrl/mvebu/pinctrl-armada-375.c | 24 +----
drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 24 +----
drivers/pinctrl/mvebu/pinctrl-armada-39x.c | 24 +----
drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 35 ++------
drivers/pinctrl/mvebu/pinctrl-dove.c | 96 +++++++++++---------
drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 32 ++-----
drivers/pinctrl/mvebu/pinctrl-mvebu.c | 137 +++++++++++++++++++++++++++--
drivers/pinctrl/mvebu/pinctrl-mvebu.h | 65 ++++++++------
drivers/pinctrl/mvebu/pinctrl-orion.c | 8 +-
10 files changed, 257 insertions(+), 212 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH net-next v2 05/10] drivers: base: Add device_find_class()
From: David Laight @ 2017-01-13 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81f5965c-3484-92d9-5c04-94c5b73735d0@gmail.com>
From: Florian Fainelli
> Sent: 12 January 2017 22:51
> On 01/12/2017 01:21 PM, David Miller wrote:
> > From: Florian Fainelli <f.fainelli@gmail.com>
> > Date: Wed, 11 Jan 2017 19:41:16 -0800
> >
> >> Add a helper function to lookup a device reference given a class name.
> >> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
> >> make it more generic.
...
> >> +static int dev_is_class(struct device *dev, void *class)
> >
> > I know you are just moving code, but this class argumnet is a string
> > and thus should be "char *" or even "const char *".
>
> Well, this is really so that we don't need to cast the arguments passed
> to device_find_child(), which takes a void *data as well. If we made
> that a const char *class, we'd get warnings that look like these:
>
> drivers/base/core.c: In function 'device_find_class':
> drivers/base/core.c:2083:2: warning: passing argument 2 of
> 'device_find_child' discards 'const' qualifier from pointer target type
> [enabled by default]
> return device_find_child(parent, class, dev_is_class);
> ^
> drivers/base/core.c:2050:16: note: expected 'void *' but argument is of
> type 'const char *'
> struct device *device_find_child(struct device *parent, void *data,
> ^
...
Maybe device_find_child() needs changing to take 'const void *' ?
David
^ permalink raw reply
* [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704
From: Robin Murphy @ 2017-01-13 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1c3253d8-bcaa-e507-cddf-dec952362104@semihalf.com>
On 13/01/17 10:43, Tomasz Nowicki wrote:
> On 12.01.2017 07:41, Tomasz Nowicki wrote:
>> On 11.01.2017 13:19, Robin Murphy wrote:
>>> On 11/01/17 11:51, Tomasz Nowicki wrote:
>>>> The goal of erratum #27704 workaround was to make sure that ASIDs and
>>>> VMIDs
>>>> are unique across all SMMU instances on affected Cavium systems.
>>>>
>>>> Currently, the workaround code partitions ASIDs and VMIDs by increasing
>>>> global cavium_smmu_context_count which in turn becomes the base ASID
>>>> and VMID
>>>> value for the given SMMU instance upon the context bank initialization.
>>>>
>>>> For systems with multiple SMMU instances this approach implies the risk
>>>> of crossing 8-bit ASID, like for CN88xx capable of 4 SMMUv2, 128
>>>> context bank each:
>>>> SMMU_0 (0-127 ASID RANGE)
>>>> SMMU_1 (127-255 ASID RANGE)
>>>> SMMU_2 (256-383 ASID RANGE) <--- crossing 8-bit ASID
>>>> SMMU_3 (384-511 ASID RANGE) <--- crossing 8-bit ASID
>>>
>>> I could swear that at some point in the original discussion it was said
>>> that the TLBs were only shared between pairs of SMMUs, so in fact 0/1
>>> and 2/3 are independent of each other
>>
>> Indeed TLBs are only shared between pairs of SMMUs but the workaround
>> makes sure ASIDs are unique across all SMMU instances so we do not have
>> to bother about SMMUs probe order.
>>
>> - out of interest, have you
>>> managed to hit an actual problem in practice or is this patch just by
>>> inspection?
>>
>> Except SMMU0/1 devices all other devices under other SMMUs will fail on
>> guest power off/on. Since we try to invalidate tlb with 16bit ASID but
>> we actually have 8 bit zero padded 16 bit entry.
>>
>>>
>>> Of course, depending on the SMMUs to probe in the right order isn't
>>> particularly robust, so it's still probably a worthwhile change.
>>>
>>>> Since we use 8-bit ASID now we effectively misconfigure ASID[15:8]
>>>> bits for
>>>> SMMU_CBn_TTBRm register. Also, we still use non-zero ASID[15:8] bits
>>>> upon context invalidation. This patch adds 16-bit ASID support for
>>>> stage-1
>>>> AArch64 contexts for Cavium SMMUv2 model so that we use ASIDs
>>>> consistently.
>>>>
>>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>>> ---
>>>> drivers/iommu/arm-smmu.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>>> index a60cded..ae8f059 100644
>>>> --- a/drivers/iommu/arm-smmu.c
>>>> +++ b/drivers/iommu/arm-smmu.c
>>>> @@ -260,6 +260,7 @@ enum arm_smmu_s2cr_privcfg {
>>>>
>>>> #define TTBCR2_SEP_SHIFT 15
>>>> #define TTBCR2_SEP_UPSTREAM (0x7 << TTBCR2_SEP_SHIFT)
>>>> +#define TTBCR2_AS (1 << 4)
>>>>
>>>> #define TTBRn_ASID_SHIFT 48
>>>>
>>>> @@ -778,6 +779,9 @@ static void arm_smmu_init_context_bank(struct
>>>> arm_smmu_domain *smmu_domain,
>>>> reg = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
>>>> reg2 = pgtbl_cfg->arm_lpae_s1_cfg.tcr >> 32;
>>>> reg2 |= TTBCR2_SEP_UPSTREAM;
>>>> + if (smmu->model == CAVIUM_SMMUV2 &&
>>>
>>> I'd be inclined to say "smmu->version == ARM_SMMU_V2" there, rather than
>>> make it Cavium-specific - we enable 16-bit VMID unconditionally where
>>> supported, so I don't see any reason not to handle 16-bit ASIDs in the
>>> same manner.
>>
>> I agree, I will enable 16-bit ASID for ARM_SMMU_V2.
>>
>
> Actually, the ARM_SMMU_CTX_FMT_AARCH64 context check is all we need here:
>
> + if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH64)
> + reg2 |= TTBCR2_AS;
Ah, clever! The horrible SMMUv1 64KB supplement supports AArch64
contexts without being SMMUv2, but of course doesn't have stage 1 :)
Robin.
>
> Thanks,
> Tomasz
^ permalink raw reply
* [PATCH v4 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family
From: Baoyou Xie @ 2017-01-13 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484304418-17489-1-git-send-email-baoyou.xie@linaro.org>
This patch adds thermal driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/thermal/Kconfig | 6 +
drivers/thermal/Makefile | 1 +
drivers/thermal/zx2967_thermal.c | 253 +++++++++++++++++++++++++++++++++++++++
3 files changed, 260 insertions(+)
create mode 100644 drivers/thermal/zx2967_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 18f2de6..0dd597e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -445,3 +445,9 @@ config BCM2835_THERMAL
Support for thermal sensors on Broadcom bcm2835 SoCs.
endif
+
+config ZX2967_THERMAL
+ tristate "Thermal sensors on zx2967 SoC"
+ depends on ARCH_ZX
+ help
+ Support for thermal sensors on ZTE zx2967 SoCs.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 677c6d9..c00c05e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
+obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
diff --git a/drivers/thermal/zx2967_thermal.c b/drivers/thermal/zx2967_thermal.c
new file mode 100644
index 0000000..e77d07c
--- /dev/null
+++ b/drivers/thermal/zx2967_thermal.c
@@ -0,0 +1,253 @@
+/*
+ * ZTE's zx2967 family thermal sensor driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+/* Power Mode: 0->low 1->high */
+#define ZX2967_THERMAL_POWER_MODE 0
+
+/* DCF Control Register */
+#define ZX2967_THERMAL_DCF 0x4
+
+/* Selection Register */
+#define ZX2967_THERMAL_SEL 0x8
+
+/* Control Register */
+#define ZX2967_THERMAL_CTRL 0x10
+
+#define ZX2967_THERMAL_READY 0x1000
+#define ZX2967_THERMAL_TEMP_MASK 0xfff
+#define ZX2967_THERMAL_ID_MASK 0x18
+#define ZX2967_THERMAL_ID0 0x8
+#define ZX2967_THERMAL_ID1 0x10
+
+struct zx2967_thermal_sensor {
+ struct zx2967_thermal_priv *priv;
+ struct thermal_zone_device *tzd;
+ int id;
+};
+
+#define NUM_SENSORS 1
+
+struct zx2967_thermal_priv {
+ struct zx2967_thermal_sensor sensors[NUM_SENSORS];
+ struct mutex lock;
+ struct clk *clk_gate;
+ struct clk *pclk;
+ void __iomem *regs;
+ struct device *dev;
+};
+
+static int zx2967_thermal_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+
+ if (priv && priv->pclk)
+ clk_disable_unprepare(priv->pclk);
+
+ if (priv && priv->clk_gate)
+ clk_disable_unprepare(priv->clk_gate);
+
+ return 0;
+}
+
+static int zx2967_thermal_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+ int error;
+
+ error = clk_prepare_enable(priv->clk_gate);
+ if (error)
+ return error;
+
+ error = clk_prepare_enable(priv->pclk);
+ if (error) {
+ clk_disable_unprepare(priv->clk_gate);
+ return error;
+ }
+
+ return 0;
+}
+
+static int zx2967_thermal_get_temp(void *data, int *temp)
+{
+ void __iomem *regs;
+ struct zx2967_thermal_sensor *sensor = data;
+ struct zx2967_thermal_priv *priv = sensor->priv;
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 val, sel_id;
+
+ regs = priv->regs;
+ mutex_lock(&priv->lock);
+
+ writel_relaxed(0, regs + ZX2967_THERMAL_POWER_MODE);
+ writel_relaxed(2, regs + ZX2967_THERMAL_DCF);
+
+ val = readl_relaxed(regs + ZX2967_THERMAL_SEL);
+ val &= ~ZX2967_THERMAL_ID_MASK;
+ sel_id = sensor->id ? ZX2967_THERMAL_ID0 : ZX2967_THERMAL_ID1;
+ val |= sel_id;
+ writel_relaxed(val, regs + ZX2967_THERMAL_SEL);
+
+ usleep_range(100, 300);
+ val = readl_relaxed(regs + ZX2967_THERMAL_CTRL);
+ while (!(val & ZX2967_THERMAL_READY)) {
+ if (time_after(jiffies, timeout)) {
+ dev_err(priv->dev, "Thermal sensor %d data timeout\n",
+ sensor->id);
+ mutex_unlock(&priv->lock);
+ return -ETIMEDOUT;
+ }
+ val = readl_relaxed(regs + ZX2967_THERMAL_CTRL);
+ }
+
+ writel_relaxed(3, regs + ZX2967_THERMAL_DCF);
+ val = readl_relaxed(regs + ZX2967_THERMAL_CTRL)
+ & ZX2967_THERMAL_TEMP_MASK;
+ writel_relaxed(1, regs + ZX2967_THERMAL_POWER_MODE);
+
+ /*
+ * Calculate temperature
+ * 922 initial value of calibration cure
+ * 1.951 slope of calibration cure
+ */
+ *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);
+
+ mutex_unlock(&priv->lock);
+
+ return 0;
+}
+
+static struct thermal_zone_of_device_ops zx2967_of_thermal_ops = {
+ .get_temp = zx2967_thermal_get_temp,
+};
+
+static int zx2967_thermal_probe(struct platform_device *pdev)
+{
+ struct zx2967_thermal_priv *priv;
+ struct resource *res;
+ int ret, i;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->regs))
+ return PTR_ERR(priv->regs);
+
+ priv->clk_gate = devm_clk_get(&pdev->dev, "gate");
+ if (IS_ERR(priv->clk_gate)) {
+ ret = PTR_ERR(priv->clk_gate);
+ dev_err(&pdev->dev, "failed to get clock gate: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(priv->clk_gate);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to enable converter clock: %d\n",
+ ret);
+ return ret;
+ }
+
+ priv->pclk = devm_clk_get(&pdev->dev, "pclk");
+ if (IS_ERR(priv->pclk)) {
+ ret = PTR_ERR(priv->pclk);
+ dev_err(&pdev->dev, "failed to get apb clock: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(priv->pclk);
+ if (ret) {
+ clk_disable_unprepare(priv->clk_gate);
+ dev_err(&pdev->dev, "failed to enable converter clock: %d\n",
+ ret);
+ return ret;
+ }
+
+ mutex_init(&priv->lock);
+ for (i = 0; i < NUM_SENSORS; i++) {
+ struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
+
+ sensor->priv = priv;
+ sensor->id = i;
+ sensor->tzd = thermal_zone_of_sensor_register(&pdev->dev,
+ i, sensor, &zx2967_of_thermal_ops);
+ if (IS_ERR(sensor->tzd)) {
+ ret = PTR_ERR(sensor->tzd);
+ dev_err(&pdev->dev, "failed to register sensor %d: %d\n",
+ i, ret);
+ goto remove_ts;
+ }
+ }
+ priv->dev = &pdev->dev;
+ platform_set_drvdata(pdev, priv);
+
+ return 0;
+
+remove_ts:
+ clk_disable_unprepare(priv->clk_gate);
+ clk_disable_unprepare(priv->pclk);
+ for (i--; i >= 0; i--)
+ thermal_zone_of_sensor_unregister(&pdev->dev,
+ priv->sensors[i].tzd);
+
+ return ret;
+}
+
+static int zx2967_thermal_exit(struct platform_device *pdev)
+{
+ struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i < NUM_SENSORS; i++) {
+ struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
+
+ thermal_zone_of_sensor_unregister(&pdev->dev, sensor->tzd);
+ }
+ clk_disable_unprepare(priv->pclk);
+ clk_disable_unprepare(priv->clk_gate);
+
+ return 0;
+}
+
+static const struct of_device_id zx2967_thermal_id_table[] = {
+ { .compatible = "zte,zx296718-thermal" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, zx2967_thermal_id_table);
+
+static SIMPLE_DEV_PM_OPS(zx2967_thermal_pm_ops,
+ zx2967_thermal_suspend, zx2967_thermal_resume);
+
+static struct platform_driver zx2967_thermal_driver = {
+ .probe = zx2967_thermal_probe,
+ .remove = zx2967_thermal_exit,
+ .driver = {
+ .name = "zx2967_thermal",
+ .of_match_table = zx2967_thermal_id_table,
+ .pm = &zx2967_thermal_pm_ops,
+ },
+};
+module_platform_driver(zx2967_thermal_driver);
+
+MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
+MODULE_DESCRIPTION("ZTE zx2967 thermal driver");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-13 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484304418-17489-1-git-send-email-baoyou.xie@linaro.org>
Add the zx2967 thermal drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 64f04df..2793808 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1981,9 +1981,11 @@ S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
F: drivers/soc/zte/
+F: drivers/thermal/zx*
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
F: Documentation/devicetree/bindings/soc/zte/
+F: Documentation/devicetree/bindings/thermal/zx*
F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/3] dt: bindings: add documentation for zx2967 family thermal sensor
From: Baoyou Xie @ 2017-01-13 10:46 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds dt-binding documentation for zx2967 family thermal sensor.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
---
.../devicetree/bindings/thermal/zx2967-thermal.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
new file mode 100644
index 0000000..86f941c
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
@@ -0,0 +1,21 @@
+* ZTE zx2967 family Thermal
+
+Required Properties:
+- compatible: should be one of the following.
+ * zte,zx296718-thermal
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- clock-names: "gate" for the topcrm clock.
+ "pclk" for the apb clock.
+- #thermal-sensor-cells: must be 0.
+
+Example:
+
+ tempsensor: tempsensor at 148a000 {
+ compatible = "zte,zx296718-thermal";
+ reg = <0x0148a000 0x20>;
+ clocks = <&topcrm TEMPSENSOR_GATE>, <&audiocrm AUDIO_TS_PCLK>;
+ clock-names = "gate", "pclk";
+ #thermal-sensor-cells = <0>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v7 12/15] msi: platform: make platform_msi_create_device_domain() ACPI aware
From: Lorenzo Pieralisi @ 2017-01-13 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484147199-4267-13-git-send-email-hanjun.guo@linaro.org>
On Wed, Jan 11, 2017 at 11:06:36PM +0800, Hanjun Guo wrote:
> platform_msi_create_device_domain() is used to ctreate
> irqdomain for the device such as irqchip mbigen generating
> the MSIs, it's almost ready for ACPI use except
> of_node_to_fwnode() is for dt only, make it ACPI aware then
> things will work in both DTS and ACPI.
"The irqdomain creation carried out in:
platform_msi_create_device_domain()
relies on the fwnode_handle interrupt controller token to associate the
interrupt controller with a specific irqdomain. Current code relies on
the OF layer to retrieve a fwnode_handle for the device representing the
interrupt controller from its device->of_node pointer. This makes
platform_msi_create_device_domain() DT specific whilst it really is not
because after the merge of commit f94277af03ea ("of/platform: Initialise
dev->fwnode appropriately") the fwnode_handle can easily be retrieved
from the dev->fwnode pointer in a firmware agnostic way.
Update platform_msi_create_device_domain() to retrieve the interrupt
controller fwnode_handle from the dev->fwnode pointer so that it can
be used seamlessly in ACPI and DT systems".
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> ---
> drivers/base/platform-msi.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
> index be6a599..035ca3b 100644
> --- a/drivers/base/platform-msi.c
> +++ b/drivers/base/platform-msi.c
> @@ -345,8 +345,7 @@ struct irq_domain *
>
> data->host_data = host_data;
> domain = irq_domain_create_hierarchy(dev->msi_domain, 0, nvec,
> - of_node_to_fwnode(dev->of_node),
> - ops, data);
> + dev->fwnode, ops, data);
> if (!domain)
> goto free_priv;
>
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704
From: Tomasz Nowicki @ 2017-01-13 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0eb1127-182e-63e3-6dd4-c3b40228b909@semihalf.com>
On 12.01.2017 07:41, Tomasz Nowicki wrote:
> On 11.01.2017 13:19, Robin Murphy wrote:
>> On 11/01/17 11:51, Tomasz Nowicki wrote:
>>> The goal of erratum #27704 workaround was to make sure that ASIDs and
>>> VMIDs
>>> are unique across all SMMU instances on affected Cavium systems.
>>>
>>> Currently, the workaround code partitions ASIDs and VMIDs by increasing
>>> global cavium_smmu_context_count which in turn becomes the base ASID
>>> and VMID
>>> value for the given SMMU instance upon the context bank initialization.
>>>
>>> For systems with multiple SMMU instances this approach implies the risk
>>> of crossing 8-bit ASID, like for CN88xx capable of 4 SMMUv2, 128
>>> context bank each:
>>> SMMU_0 (0-127 ASID RANGE)
>>> SMMU_1 (127-255 ASID RANGE)
>>> SMMU_2 (256-383 ASID RANGE) <--- crossing 8-bit ASID
>>> SMMU_3 (384-511 ASID RANGE) <--- crossing 8-bit ASID
>>
>> I could swear that at some point in the original discussion it was said
>> that the TLBs were only shared between pairs of SMMUs, so in fact 0/1
>> and 2/3 are independent of each other
>
> Indeed TLBs are only shared between pairs of SMMUs but the workaround
> makes sure ASIDs are unique across all SMMU instances so we do not have
> to bother about SMMUs probe order.
>
> - out of interest, have you
>> managed to hit an actual problem in practice or is this patch just by
>> inspection?
>
> Except SMMU0/1 devices all other devices under other SMMUs will fail on
> guest power off/on. Since we try to invalidate tlb with 16bit ASID but
> we actually have 8 bit zero padded 16 bit entry.
>
>>
>> Of course, depending on the SMMUs to probe in the right order isn't
>> particularly robust, so it's still probably a worthwhile change.
>>
>>> Since we use 8-bit ASID now we effectively misconfigure ASID[15:8]
>>> bits for
>>> SMMU_CBn_TTBRm register. Also, we still use non-zero ASID[15:8] bits
>>> upon context invalidation. This patch adds 16-bit ASID support for
>>> stage-1
>>> AArch64 contexts for Cavium SMMUv2 model so that we use ASIDs
>>> consistently.
>>>
>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>> ---
>>> drivers/iommu/arm-smmu.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>> index a60cded..ae8f059 100644
>>> --- a/drivers/iommu/arm-smmu.c
>>> +++ b/drivers/iommu/arm-smmu.c
>>> @@ -260,6 +260,7 @@ enum arm_smmu_s2cr_privcfg {
>>>
>>> #define TTBCR2_SEP_SHIFT 15
>>> #define TTBCR2_SEP_UPSTREAM (0x7 << TTBCR2_SEP_SHIFT)
>>> +#define TTBCR2_AS (1 << 4)
>>>
>>> #define TTBRn_ASID_SHIFT 48
>>>
>>> @@ -778,6 +779,9 @@ static void arm_smmu_init_context_bank(struct
>>> arm_smmu_domain *smmu_domain,
>>> reg = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
>>> reg2 = pgtbl_cfg->arm_lpae_s1_cfg.tcr >> 32;
>>> reg2 |= TTBCR2_SEP_UPSTREAM;
>>> + if (smmu->model == CAVIUM_SMMUV2 &&
>>
>> I'd be inclined to say "smmu->version == ARM_SMMU_V2" there, rather than
>> make it Cavium-specific - we enable 16-bit VMID unconditionally where
>> supported, so I don't see any reason not to handle 16-bit ASIDs in the
>> same manner.
>
> I agree, I will enable 16-bit ASID for ARM_SMMU_V2.
>
Actually, the ARM_SMMU_CTX_FMT_AARCH64 context check is all we need here:
+ if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH64)
+ reg2 |= TTBCR2_AS;
Thanks,
Tomasz
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: kbuild test robot @ 2017-01-13 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484159512-28515-2-git-send-email-nikita.yoush@cogentembedded.com>
Hi Nikita,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc3 next-20170112]
[cannot apply to arm64/for-next/core]
[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/Nikita-Yushchenko/dma-mapping-let-arch-know-origin-of-dma-range-passed-to-arch_setup_dma_ops/20170113-152733
config: x86_64-randconfig-u0-01131618 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/acpi/scan.c: In function 'acpi_dma_configure':
>> drivers/acpi/scan.c:1388:2: error: too many arguments to function 'arch_setup_dma_ops'
arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, false, iommu,
^~~~~~~~~~~~~~~~~~
In file included from drivers/acpi/scan.c:15:0:
include/linux/dma-mapping.h:611:20: note: declared here
static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base,
^~~~~~~~~~~~~~~~~~
vim +/arch_setup_dma_ops +1388 drivers/acpi/scan.c
1382 iommu = iort_iommu_configure(dev);
1383
1384 /*
1385 * Assume dma valid range starts at 0 and covers the whole
1386 * coherent_dma_mask.
1387 */
> 1388 arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, false, iommu,
1389 attr == DEV_DMA_COHERENT);
1390 }
1391 EXPORT_SYMBOL_GPL(acpi_dma_configure);
---
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: 25665 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170113/7e91dc43/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11
From: Herbert Xu @ 2017-01-13 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9a5ZsWtT0XYczPBf54L7d5Whu5gG1eUOt8T-wms0orbg@mail.gmail.com>
On Thu, Jan 12, 2017 at 04:48:08PM +0000, Ard Biesheuvel wrote:
>
> Actually, patch #6 was the huge one not #7, and I don't see it in your tree yet.
>
> https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/commit/?h=crypto-arm-v4.11&id=cbf03b255f7c
>
> The order does not matter, though, so could you please put it on top? Thanks.
OK I've applied it now and will push out soon.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v7 00/15] ACPI platform MSI support and its example mbigen
From: Ming Lei @ 2017-01-13 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484147199-4267-1-git-send-email-hanjun.guo@linaro.org>
On Wed, Jan 11, 2017 at 11:06 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> With platform msi support landed in the kernel, and the introduction
> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
> is ready, this patch set add few patches to enable the ACPI platform
> msi support.
>
> For platform device connecting to ITS on arm platform, we have IORT
> table with the named componant node to describe the mappings of paltform
> device and ITS, so we can retrieve the dev id and find its parent
> irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
>
> v6 -> v7:
> - Introduce iort_node_map_platform_id() to retrieve the
> dev id for both NC (named component) -> ITS/SMMU and
> NC -> SMMU -> ITS cases, suggested by Lorenzo;
>
> - Reorder the patches and rewrite some commit message;
>
> - Remove the test tags because it has major changes
> to retrieve the dev id, Sinan, Majun, Xinwei, could
> you please test them again on your platform?
>
> - rebased on top of 4.10-rc3 and Lorenzo's patch
> https://patchwork.kernel.org/patch/9507041/
>
> - Tested against Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
> Add IRQ combiner driver"
Looks v7 works fine on D05, together with Lorenzo's
fix([v2] ACPI/IORT: Fix iort_node_get_id() mapping entries indexing) and
Agustin's patchset of "v9 irqchip: qcom: Add IRQ combiner driver".
Tested-by: Ming Lei <ming.lei@canonical.com>
>
> v5 -> v6:
> - Call acpi_configure_pmsi_domain() for platform devices in
> acpi_platform_notify() as it's cleaner (suggested by Rafael)
> - Remove the "u8 type" for iort_id_map() because it's unused
> - Rebase on top of 4.10-rc2
> - Collect test and review tags
>
> v4 -> v5:
> - Add mbigen support back with tested on with Agustin's patchset,
> and it's a good example of how ACPI platform MSI works
> - rebased on top of lastest Linus tree (commit 52bce91 splice: reinstate SIGPIPE/EPIPE handling)
>
> v3 -> v4:
> - Drop mbi-gen patches to just submit platform msi support because
> will rebase mbi-gen patches on top of Agustin's patchset, and discusion
> is going there.
> - Add a patch to support device topology such as NC(named componant, paltform device)
> ->SMMU->ITS which suggested by Lorenzo;
> - rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
> - rebased on top of 4.9-rc7
>
> v2 -> v3:
> - Drop RFC tag
> - Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU support [1]
> - Add 3 cleanup patches (patch 1, 2, 3)
> - Drop arch_init call patch from last version
> - Introduce a callback for platform device to set msi domain
> - Introduce a new API to get paltform device's domain instead of
> reusing the PCI one in previous version
> - Add a patch to rework iort_node_get_id()
>
> [1]: http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1251993.html
>
> v1 -> v2:
> - Fix the bug of if multi Interrupt() resoures in single _PRS,
> we need to calculate all the irq numbers (I missed it in previous
> version);
> - Rebased on Marc's irq/irqchip-4.9 branch and Lorenzo's v5
> SMMU patches (also Robin's SMMu patches)
> - Add patch irqchip: mbigen: promote mbigen init.
>
>
> Hanjun Guo (13):
> ACPI: IORT: fix the indentation in iort_scan_node()
> ACPI: IORT: add missing comment for iort_dev_find_its_id()
> ACPI: IORT: minor cleanup for iort_match_node_callback()
> irqchip: gic-v3-its: keep the head file include in alphabetic order
> irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
> irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare
> for ACPI
> irqchip: gicv3-its: platform-msi: scan MADT to create platform msi
> domain
> ACPI: IORT: rename iort_node_map_rid() to make it generic
> ACPI: platform-msi: retrieve dev id from IORT
> ACPI: IORT: move over to iort_node_map_platform_id()
> ACPI: platform: setup MSI domain for ACPI based platform device
> msi: platform: make platform_msi_create_device_domain() ACPI aware
> irqchip: mbigen: Add ACPI support
>
> Kefeng Wang (2):
> irqchip: mbigen: drop module owner
> irqchip: mbigen: introduce mbigen_of_create_domain()
>
> drivers/acpi/arm64/iort.c | 161 +++++++++++++++++++++-----
> drivers/acpi/glue.c | 6 +
> drivers/base/platform-msi.c | 3 +-
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++++++++++++----
> drivers/irqchip/irq-gic-v3-its.c | 3 +-
> drivers/irqchip/irq-mbigen.c | 109 ++++++++++++++---
> include/linux/acpi_iort.h | 11 ++
> 7 files changed, 322 insertions(+), 77 deletions(-)
>
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Ming Lei
^ permalink raw reply
* [PATCH v7 15/15] irqchip: mbigen: Add ACPI support
From: Lorenzo Pieralisi @ 2017-01-13 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484147199-4267-16-git-send-email-hanjun.guo@linaro.org>
On Wed, Jan 11, 2017 at 11:06:39PM +0800, Hanjun Guo wrote:
> With the preparation of platform msi support and interrupt producer
> in DSDT, we can add mbigen ACPI support now.
>
> We are using _PRS methd to indicate number of irq pins instead
> of num_pins in DT to avoid _DSD usage in this case.
>
> For mbi-gen,
> Device(MBI0) {
> Name(_HID, "HISI0152")
> Name(_UID, Zero)
> Name(_CRS, ResourceTemplate() {
> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
> })
>
> Name (_PRS, ResourceTemplate() {
> Interrupt(ResourceProducer,...) {12,14,....}
I still do not understand why you are using _PRS for this, I think
the MBIgen configuration is static and if it is so the Interrupt
resource should be part of the _CRS unless there is something I am
missing here.
Lorenzo
> })
> }
>
> For devices,
>
> Device(COM0) {
> Name(_HID, "ACPIIDxx")
> Name(_UID, Zero)
> Name(_CRS, ResourceTemplate() {
> Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
> Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
> })
> }
>
> With the helpe of platform msi and interrupt producer, then devices
> will get the virq from mbi-gen's irqdomain.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Reviewed-by: Ma Jun <majun258@huawei.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-mbigen.c | 70 ++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 67 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 4e11da5..17d35fa 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -16,6 +16,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/acpi.h>
> #include <linux/interrupt.h>
> #include <linux/irqchip.h>
> #include <linux/module.h>
> @@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
> unsigned long *hwirq,
> unsigned int *type)
> {
> - if (is_of_node(fwspec->fwnode)) {
> + if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
> if (fwspec->param_count != 2)
> return -EINVAL;
>
> @@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,
> return 0;
> }
>
> +#ifdef CONFIG_ACPI
> +static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
> + void *context)
> +{
> + struct acpi_resource_extended_irq *ext_irq;
> + u32 *num_irqs = context;
> +
> + switch (ares->type) {
> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + ext_irq = &ares->data.extended_irq;
> + *num_irqs += ext_irq->interrupt_count;
> + break;
> + default:
> + break;
> + }
> +
> + return AE_OK;
> +}
> +
> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
> + struct mbigen_device *mgn_chip)
> +{
> + struct irq_domain *domain;
> + u32 num_msis = 0;
> + acpi_status status;
> +
> + status = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), METHOD_NAME__PRS,
> + mbigen_acpi_process_resource, &num_msis);
> + if (ACPI_FAILURE(status) || num_msis == 0)
> + return -EINVAL;
> +
> + domain = platform_msi_create_device_domain(&pdev->dev, num_msis,
> + mbigen_write_msg,
> + &mbigen_domain_ops,
> + mgn_chip);
> + if (!domain)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +#else
> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
> + struct mbigen_device *mgn_chip)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> static int mbigen_device_probe(struct platform_device *pdev)
> {
> struct mbigen_device *mgn_chip;
> @@ -288,9 +337,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
> if (IS_ERR(mgn_chip->base))
> return PTR_ERR(mgn_chip->base);
>
> - err = mbigen_of_create_domain(pdev, mgn_chip);
> - if (err)
> + if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
> + err = mbigen_of_create_domain(pdev, mgn_chip);
> + else if (ACPI_COMPANION(&pdev->dev))
> + err = mbigen_acpi_create_domain(pdev, mgn_chip);
> + else
> + err = -EINVAL;
> +
> + if (err) {
> + dev_err(&pdev->dev, "Failed to create mbi-gen@%p irqdomain", mgn_chip->base);
> return err;
> + }
>
> platform_set_drvdata(pdev, mgn_chip);
> return 0;
> @@ -302,10 +359,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
> };
> MODULE_DEVICE_TABLE(of, mbigen_of_match);
>
> +static const struct acpi_device_id mbigen_acpi_match[] = {
> + { "HISI0152", 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
> +
> static struct platform_driver mbigen_platform_driver = {
> .driver = {
> .name = "Hisilicon MBIGEN-V2",
> .of_match_table = mbigen_of_match,
> + .acpi_match_table = ACPI_PTR(mbigen_acpi_match),
> },
> .probe = mbigen_device_probe,
> };
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 1/2] mmc: mediatek: Use data tune for CMD line tune
From: Yong Mao @ 2017-01-13 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFq0_WpCAAmUDfaKApq7=tdpjNqL896FC=QPfGgE9JaEHA@mail.gmail.com>
On Thu, 2017-01-12 at 11:39 +0100, Ulf Hansson wrote:
> On 12 January 2017 at 11:04, Yong Mao <yong.mao@mediatek.com> wrote:
> > From: yong mao <yong.mao@mediatek.com>
> >
> > CMD response CRC error may cause cannot boot up
> > Change to use data tune for CMD line
> > Separate cmd internal delay for HS200/HS400 mode
>
> Please try to work a little bit on improving the change log. Moreover
> as this is a fix for a regression (it seems like so?), please try to
> make that clear.
This change can fix CMD respose CRC issue in our platform.
I will try to make it clear in next version.
>
> >
> > Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> > Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
> > ---
> > arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +
>
> Changes to the DTS files should be a separate change. Please split it
> into its own patch.
>
> > drivers/mmc/host/mtk-sd.c | 169 +++++++++++++++++++++++----
> > 2 files changed, 149 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > index 0ecaad4..29c3100 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > @@ -134,6 +134,9 @@
> > bus-width = <8>;
> > max-frequency = <50000000>;
> > cap-mmc-highspeed;
> > + hs200-cmd-int-delay = <26>;
> > + hs400-cmd-int-delay = <14>;
> > + cmd-resp-sel = <0>; /* 0: rising, 1: falling */
> > vmmc-supply = <&mt6397_vemc_3v3_reg>;
> > vqmmc-supply = <&mt6397_vio18_reg>;
> > non-removable;
> > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> > index 80ba034..93eb395 100644
> > --- a/drivers/mmc/host/mtk-sd.c
> > +++ b/drivers/mmc/host/mtk-sd.c
> > @@ -75,6 +75,7 @@
> > #define MSDC_PATCH_BIT1 0xb4
> > #define MSDC_PAD_TUNE 0xec
> > #define PAD_DS_TUNE 0x188
> > +#define PAD_CMD_TUNE 0x18c
> > #define EMMC50_CFG0 0x208
> >
> > /*--------------------------------------------------------------------------*/
> > @@ -210,12 +211,17 @@
> > #define MSDC_PATCH_BIT_SPCPUSH (0x1 << 29) /* RW */
> > #define MSDC_PATCH_BIT_DECRCTMO (0x1 << 30) /* RW */
> >
> > -#define MSDC_PAD_TUNE_DATRRDLY (0x1f << 8) /* RW */
> > -#define MSDC_PAD_TUNE_CMDRDLY (0x1f << 16) /* RW */
> > +#define MSDC_PAD_TUNE_DATWRDLY (0x1f << 0) /* RW */
> > +#define MSDC_PAD_TUNE_DATRRDLY (0x1f << 8) /* RW */
> > +#define MSDC_PAD_TUNE_CMDRDLY (0x1f << 16) /* RW */
> > +#define MSDC_PAD_TUNE_CMDRRDLY (0x1f << 22) /* RW */
>
> Is there a white space change somewhere here? I don't see any changes
> to MSDC_PAD_TUNE_DATRRDLY and MSDC_PAD_TUNE_CMDRDLY.
>
Sorry. I will fix in next version.
> > +#define MSDC_PAD_TUNE_CLKTDLY (0x1f << 27) /* RW */
> >
> > -#define PAD_DS_TUNE_DLY1 (0x1f << 2) /* RW */
> > -#define PAD_DS_TUNE_DLY2 (0x1f << 7) /* RW */
> > -#define PAD_DS_TUNE_DLY3 (0x1f << 12) /* RW */
> > +#define PAD_DS_TUNE_DLY1 (0x1f << 2) /* RW */
> > +#define PAD_DS_TUNE_DLY2 (0x1f << 7) /* RW */
> > +#define PAD_DS_TUNE_DLY3 (0x1f << 12) /* RW */
> > +
>
> Ditto.
Ditto.
>
> > +#define PAD_CMD_TUNE_RX_DLY3 (0x1f << 1) /* RW */
> >
> > #define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0) /* RW */
> > #define EMMC50_CFG_CRCSTS_EDGE (0x1 << 3) /* RW */
> > @@ -236,7 +242,9 @@
> > #define CMD_TIMEOUT (HZ/10 * 5) /* 100ms x5 */
> > #define DAT_TIMEOUT (HZ * 5) /* 1000ms x5 */
> >
> > -#define PAD_DELAY_MAX 32 /* PAD delay cells */
> > +#define PAD_DELAY_MAX 32 /* PAD delay cells */
>
> Ditto.
>
Ditto.
> > +#define ENOUGH_MARGIN_MIN 12 /* Enough Margin */
> > +#define PREFER_START_POS_MAX 4 /* Prefer start position */
> > /*--------------------------------------------------------------------------*/
> > /* Descriptor Structure */
> > /*--------------------------------------------------------------------------*/
> > @@ -284,12 +292,14 @@ struct msdc_save_para {
> > u32 patch_bit0;
> > u32 patch_bit1;
> > u32 pad_ds_tune;
> > + u32 pad_cmd_tune;
> > u32 emmc50_cfg0;
> > };
> >
> > struct msdc_tune_para {
> > u32 iocon;
> > u32 pad_tune;
> > + u32 pad_cmd_tune;
> > };
> >
> > struct msdc_delay_phase {
> > @@ -331,6 +341,9 @@ struct msdc_host {
> > unsigned char timing;
> > bool vqmmc_enabled;
> > u32 hs400_ds_delay;
> > + u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
> > + u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
> > + u32 hs200_cmd_resp_sel; /* cmd response sample selection */
> > bool hs400_mode; /* current eMMC will run at hs400 mode */
> > struct msdc_save_para save_para; /* used when gate HCLK */
> > struct msdc_tune_para def_tune_para; /* default tune setting */
> > @@ -596,12 +609,21 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned char timing, u32 hz)
> > */
> > if (host->sclk <= 52000000) {
> > writel(host->def_tune_para.iocon, host->base + MSDC_IOCON);
> > - writel(host->def_tune_para.pad_tune, host->base + MSDC_PAD_TUNE);
> > + writel(host->def_tune_para.pad_tune,
> > + host->base + MSDC_PAD_TUNE);
>
> Please don't change code just because you feel like doing it. This is
> a completely unessarry change and it makes it harder for me to review.
>
> Can you go thorugh the complete patch and make sure to undo all
> similar changes, there are more of them.
>
Sorry. I will fix in next version.
> > } else {
> > - writel(host->saved_tune_para.iocon, host->base + MSDC_IOCON);
> > - writel(host->saved_tune_para.pad_tune, host->base + MSDC_PAD_TUNE);
> > + writel(host->saved_tune_para.iocon,
> > + host->base + MSDC_IOCON);
> > + writel(host->saved_tune_para.pad_tune,
> > + host->base + MSDC_PAD_TUNE);
> > + writel(host->saved_tune_para.pad_cmd_tune,
> > + host->base + PAD_CMD_TUNE);
> > }
> >
> > + if (timing == MMC_TIMING_MMC_HS400)
> > + sdr_set_field(host->base + PAD_CMD_TUNE,
> > + MSDC_PAD_TUNE_CMDRRDLY,
> > + host->hs400_cmd_int_delay);
> > dev_dbg(host->dev, "sclk: %d, timing: %d\n", host->sclk, timing);
> > }
> >
> > @@ -1302,7 +1324,8 @@ static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u32 delay)
> > len_final = len;
> > }
> > start += len ? len : 1;
> > - if (len >= 8 && start_final < 4)
> > + if (len >= ENOUGH_MARGIN_MIN &&
> > + start_final < PREFER_START_POS_MAX)
> > break;
> > }
> >
> > @@ -1325,48 +1348,128 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
> > struct msdc_host *host = mmc_priv(mmc);
> > u32 rise_delay = 0, fall_delay = 0;
> > struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
> > + struct msdc_delay_phase internal_delay_phase;
> > u8 final_delay, final_maxlen;
> > + u32 internal_delay = 0;
> > int cmd_err;
> > - int i;
> > + int i, j;
> >
> > + if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
> > + mmc->ios.timing == MMC_TIMING_UHS_SDR104)
> > + sdr_set_field(host->base + MSDC_PAD_TUNE,
> > + MSDC_PAD_TUNE_CMDRRDLY,
> > + host->hs200_cmd_int_delay);
> > sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
> > for (i = 0 ; i < PAD_DELAY_MAX; i++) {
> > sdr_set_field(host->base + MSDC_PAD_TUNE,
> > MSDC_PAD_TUNE_CMDRDLY, i);
> > - mmc_send_tuning(mmc, opcode, &cmd_err);
> > - if (!cmd_err)
> > - rise_delay |= (1 << i);
> > + for (j = 0; j < 3; j++) {
>
> Any reason to why looping three times makes sense? Maybe add a comment?
>
Using the same parameters, it may sometimes pass the test,
but sometimes it may fail. To make sure the parameters is
more stable, we test 3 times for on set of parameters.
Anyway, I will add comment here in next version.
> > + mmc_send_tuning(mmc, opcode, &cmd_err);
> > + if (!cmd_err) {
> > + rise_delay |= (1 << i);
> > + } else {
> > + rise_delay &= ~(1 << i);
> > + break;
> > + }
> > + }
> > }
> > final_rise_delay = get_best_delay(host, rise_delay);
> > /* if rising edge has enough margin, then do not scan falling edge */
> > - if (final_rise_delay.maxlen >= 10 ||
> > - (final_rise_delay.start == 0 && final_rise_delay.maxlen >= 4))
> > + if (final_rise_delay.maxlen >= ENOUGH_MARGIN_MIN &&
> > + final_rise_delay.start < PREFER_START_POS_MAX)
>
> This looks like clean-ups, as you are converting from magic numbers to
> defines. Please make this kind of changes separately.
I will drop this change in next version.
>
> > goto skip_fall;
> >
> > sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
> > for (i = 0; i < PAD_DELAY_MAX; i++) {
> > sdr_set_field(host->base + MSDC_PAD_TUNE,
> > MSDC_PAD_TUNE_CMDRDLY, i);
> > - mmc_send_tuning(mmc, opcode, &cmd_err);
> > - if (!cmd_err)
> > - fall_delay |= (1 << i);
> > + for (j = 0; j < 3; j++) {
>
> 3?
>
> > + mmc_send_tuning(mmc, opcode, &cmd_err);
> > + if (!cmd_err) {
> > + fall_delay |= (1 << i);
> > + } else {
> > + fall_delay &= ~(1 << i);
> > + break;
> > + };
> > + }
> > }
> > final_fall_delay = get_best_delay(host, fall_delay);
> >
> > skip_fall:
> > final_maxlen = max(final_rise_delay.maxlen, final_fall_delay.maxlen);
> > + if (final_fall_delay.maxlen >= ENOUGH_MARGIN_MIN &&
> > + final_fall_delay.start < PREFER_START_POS_MAX)
> > + final_maxlen = final_fall_delay.maxlen;
> > if (final_maxlen == final_rise_delay.maxlen) {
> > sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
> > - sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRDLY,
> > + sdr_set_field(host->base + MSDC_PAD_TUNE,
> > + MSDC_PAD_TUNE_CMDRDLY,
> > final_rise_delay.final_phase);
> > final_delay = final_rise_delay.final_phase;
> > } else {
> > sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
> > - sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRDLY,
> > + sdr_set_field(host->base + MSDC_PAD_TUNE,
> > + MSDC_PAD_TUNE_CMDRDLY,
> > final_fall_delay.final_phase);
> > final_delay = final_fall_delay.final_phase;
> > }
> > + if (host->hs200_cmd_int_delay)
> > + goto skip_internal;
> >
> > + for (i = 0; i < PAD_DELAY_MAX; i++) {
> > + sdr_set_field(host->base + MSDC_PAD_TUNE,
> > + MSDC_PAD_TUNE_CMDRRDLY, i);
> > + mmc_send_tuning(mmc, opcode, &cmd_err);
> > + if (!cmd_err)
> > + internal_delay |= (1 << i);
> > + }
> > + dev_info(host->dev, "Final internal delay: 0x%x\n", internal_delay);
>
> I don't think dev_info() is what you want, right? Perhaps dev_dbg(),
> anything at all.
>
Yes. We should use dev_dbg() here. Will be fixed in next version.
> > + internal_delay_phase = get_best_delay(host, internal_delay);
> > + sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRRDLY,
> > + internal_delay_phase.final_phase);
> > +skip_internal:
> > + dev_info(host->dev, "Final cmd pad delay: %x\n", final_delay);
>
> I don't think dev_info() is what you want, right? Perhaps dev_dbg(),
> anything at all.
>
Yes. We should use dev_dbg() here. Will be fixed in next version.
> > + return final_delay == 0xff ? -EIO : 0;
> > +}
> > +
> > +static int hs400_tune_response(struct mmc_host *mmc, u32 opcode)
> > +{
> > + struct msdc_host *host = mmc_priv(mmc);
> > + u32 cmd_delay = 0;
> > + struct msdc_delay_phase final_cmd_delay = { 0,};
> > + u8 final_delay;
> > + int cmd_err;
> > + int i, j;
> > +
> > + /* select EMMC50 PAD CMD tune */
> > + sdr_set_bits(host->base + PAD_CMD_TUNE, BIT(0));
> > +
> > + if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
> > + mmc->ios.timing == MMC_TIMING_UHS_SDR104)
> > + sdr_set_field(host->base + MSDC_PAD_TUNE,
> > + MSDC_PAD_TUNE_CMDRRDLY,
> > + host->hs200_cmd_int_delay);
> > + sdr_set_field(host->base + MSDC_IOCON, MSDC_IOCON_RSPL,
> > + host->hs200_cmd_resp_sel);
> > + for (i = 0 ; i < PAD_DELAY_MAX; i++) {
> > + sdr_set_field(host->base + PAD_CMD_TUNE,
> > + PAD_CMD_TUNE_RX_DLY3, i);
> > + for (j = 0; j < 3; j++) {
>
> 3?
>
> > + mmc_send_tuning(mmc, opcode, &cmd_err);
> > + if (!cmd_err) {
> > + cmd_delay |= (1 << i);
> > + } else {
> > + cmd_delay &= ~(1 << i);
> > + break;
> > + }
> > + }
> > + }
> > + final_cmd_delay = get_best_delay(host, cmd_delay);
> > + sdr_set_field(host->base + PAD_CMD_TUNE, PAD_CMD_TUNE_RX_DLY3,
> > + final_cmd_delay.final_phase);
> > + final_delay = final_cmd_delay.final_phase;
> > +
> > + dev_info(host->dev, "Final cmd pad delay: %x\n", final_delay);
>
> dev_info() -> dev_dbg() or remove it.
We will use dev_dbg() instead of dev_info(). Will be fixed in next
version.
>
> > return final_delay == 0xff ? -EIO : 0;
> > }
> >
> > @@ -1389,7 +1492,7 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
> > }
> > final_rise_delay = get_best_delay(host, rise_delay);
> > /* if rising edge has enough margin, then do not scan falling edge */
> > - if (final_rise_delay.maxlen >= 10 ||
> > + if (final_rise_delay.maxlen >= ENOUGH_MARGIN_MIN ||
>
> Clean up. Move to separate change.
>
Will drop it in current change.
> > (final_rise_delay.start == 0 && final_rise_delay.maxlen >= 4))
> > goto skip_fall;
> >
> > @@ -1422,6 +1525,7 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
> > final_delay = final_fall_delay.final_phase;
> > }
> >
> > + dev_info(host->dev, "Final data pad delay: %x\n", final_delay);
>
> dev_info() -> dev_dbg() or remove it.
>
We will use dev_dbg() instead of dev_info(). Will be fixed in next
version.
> > return final_delay == 0xff ? -EIO : 0;
> > }
> >
> > @@ -1430,10 +1534,13 @@ static int msdc_execute_tuning(struct mmc_host *mmc, u32 opcode)
> > struct msdc_host *host = mmc_priv(mmc);
> > int ret;
> >
> > + if (host->hs400_mode)
> > + ret = hs400_tune_response(mmc, opcode);
> > + else
> > ret = msdc_tune_response(mmc, opcode);
>
> Because of the new else clause, seems like above needs an intendation.
>
Sorry. Will be fixed in next version.
> > if (ret == -EIO) {
> > dev_err(host->dev, "Tune response fail!\n");
> > - return ret;
> > + goto out;
>
> Not needed, remove the label and this change.
>
Will drop it in this change.
> > }
> > if (host->hs400_mode == false) {
> > ret = msdc_tune_data(mmc, opcode);
> > @@ -1443,6 +1550,8 @@ static int msdc_execute_tuning(struct mmc_host *mmc, u32 opcode)
> >
> > host->saved_tune_para.iocon = readl(host->base + MSDC_IOCON);
> > host->saved_tune_para.pad_tune = readl(host->base + MSDC_PAD_TUNE);
> > + host->saved_tune_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
> > +out:
> > return ret;
> > }
> >
> > @@ -1553,6 +1662,18 @@ static int msdc_drv_probe(struct platform_device *pdev)
> > dev_dbg(&pdev->dev, "hs400-ds-delay: %x\n",
> > host->hs400_ds_delay);
> >
> > + if (!of_property_read_u32(pdev->dev.of_node, "hs200-cmd-int-delay",
> > + &host->hs200_cmd_int_delay))
> > + dev_dbg(&pdev->dev, "host->hs200-cmd-int-delay: %x\n",
> > + host->hs200_cmd_int_delay);
> > + if (!of_property_read_u32(pdev->dev.of_node, "hs400-cmd-int-delay",
> > + &host->hs400_cmd_int_delay))
> > + dev_dbg(&pdev->dev, "host->hs400-cmd-int-delay: %x\n",
> > + host->hs400_cmd_int_delay);
> > + if (!of_property_read_u32(pdev->dev.of_node, "cmd-resp-sel",
> > + &host->hs200_cmd_resp_sel))
> > + dev_dbg(&pdev->dev, "host->hs200_cmd-resp-sel: %x\n",
> > + host->hs200_cmd_resp_sel);
>
> I suggest you take the oppotunity to move the MTK DTS parsing into its
> own function, include the existing parsing of the "hs400-ds-delay".
> This improve the readablitity of the code.
>
Thanks. We will move all of MTK DTS parsing into msdc_of_property_parse
function.
> > host->dev = &pdev->dev;
> > host->mmc = mmc;
> > host->src_clk_freq = clk_get_rate(host->src_clk);
> > @@ -1663,6 +1784,7 @@ static void msdc_save_reg(struct msdc_host *host)
> > host->save_para.patch_bit0 = readl(host->base + MSDC_PATCH_BIT);
> > host->save_para.patch_bit1 = readl(host->base + MSDC_PATCH_BIT1);
> > host->save_para.pad_ds_tune = readl(host->base + PAD_DS_TUNE);
> > + host->save_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
> > host->save_para.emmc50_cfg0 = readl(host->base + EMMC50_CFG0);
> > }
> >
> > @@ -1675,6 +1797,7 @@ static void msdc_restore_reg(struct msdc_host *host)
> > writel(host->save_para.patch_bit0, host->base + MSDC_PATCH_BIT);
> > writel(host->save_para.patch_bit1, host->base + MSDC_PATCH_BIT1);
> > writel(host->save_para.pad_ds_tune, host->base + PAD_DS_TUNE);
> > + writel(host->save_para.pad_cmd_tune, host->base + PAD_CMD_TUNE);
> > writel(host->save_para.emmc50_cfg0, host->base + EMMC50_CFG0);
> > }
> >
> > --
> > 1.7.9.5
> >
>
> Kind regards
> Uffe
Best Regards,
Yong Mao.
^ permalink raw reply
* [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports
From: kbuild test robot @ 2017-01-13 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484159512-28515-3-git-send-email-nikita.yoush@cogentembedded.com>
Hi Nikita,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc3 next-20170112]
[cannot apply to arm64/for-next/core]
[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/Nikita-Yushchenko/dma-mapping-let-arch-know-origin-of-dma-range-passed-to-arch_setup_dma_ops/20170113-152733
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
arch/arm64/mm/dma-mapping.c: In function 'dma_set_mask':
>> arch/arm64/mm/dma-mapping.c:210:6: error: 'mask' undeclared (first use in this function)
if (mask > dev->archdata.parent_dma_mask)
^~~~
arch/arm64/mm/dma-mapping.c:210:6: note: each undeclared identifier is reported only once for each function it appears in
vim +/mask +210 arch/arm64/mm/dma-mapping.c
204 }
205
206 int dma_set_mask(struct device *dev, u64 dma_mask)
207 {
208 const struct dma_map_ops *ops = get_dma_ops(dev);
209
> 210 if (mask > dev->archdata.parent_dma_mask)
211 mask = dev->archdata.parent_dma_mask;
212
213 if (ops->set_dma_mask)
---
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: 33713 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170113/4aebcaaa/attachment-0001.gz>
^ permalink raw reply
* [PATCH RESEND 2/2] ARM: da850: add the nand dev_id to the clock lookup table
From: Bartosz Golaszewski @ 2017-01-13 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484301626-30345-1-git-send-email-bgolaszewski@baylibre.com>
The aemif driver can now access struct of_dev_auxdata (using platform
data).
Add the device id to the clock lookup table for the nand clock and
create a separate lookup table for aemif subnodes.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 10 +---------
arch/arm/mach-davinci/da8xx-dt.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 55f6e11..7475f02 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -557,15 +557,7 @@ static struct clk_lookup da850_clks[] = {
CLK("da830-mmc.0", NULL, &mmcsd0_clk),
CLK("da830-mmc.1", NULL, &mmcsd1_clk),
CLK("ti-aemif", NULL, &aemif_clk),
- /*
- * The only user of this clock is davinci_nand and it get's it through
- * con_id. The nand node itself is created from within the aemif
- * driver to guarantee that it's probed after the aemif timing
- * parameters are configured. of_dev_auxdata is not accessible from
- * the aemif driver and can't be passed to of_platform_populate(). For
- * that reason we're leaving the dev_id here as NULL.
- */
- CLK(NULL, "aemif", &aemif_nand_clk),
+ CLK("davinci-nand.0", "aemif", &aemif_nand_clk),
CLK("ohci-da8xx", "usb11", &usb11_clk),
CLK("musb-da8xx", "usb20", &usb20_clk),
CLK("spi_davinci.0", NULL, &spi0_clk),
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da..06205fe 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -11,6 +11,7 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/irqdomain.h>
+#include <linux/platform_data/ti-aemif.h>
#include <asm/mach/arch.h>
@@ -18,6 +19,15 @@
#include "cp_intc.h"
#include <mach/da8xx.h>
+static struct of_dev_auxdata da850_aemif_auxdata_lookup[] = {
+ OF_DEV_AUXDATA("ti,davinci-nand", 0x62000000, "davinci-nand.0", NULL),
+ {}
+};
+
+static struct aemif_platform_data aemif_data = {
+ .dev_lookup = da850_aemif_auxdata_lookup,
+};
+
static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL),
@@ -37,7 +47,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
NULL),
OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
- OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
+ OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", &aemif_data),
OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
--
2.9.3
^ permalink raw reply related
* [PATCH RESEND 1/2] memory: aemif: allow passing device lookup table as platform data
From: Bartosz Golaszewski @ 2017-01-13 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484301626-30345-1-git-send-email-bgolaszewski@baylibre.com>
TI aemif driver creates its own subnodes of the device tree in order
to guarantee that all child devices are probed after the AEMIF timing
parameters are configured.
Some devices (e.g. da850) use struct of_dev_auxdata for clock lookup
but nodes created from within the aemif driver can't access the lookup
table.
Create a platform data structure that holds a pointer to
of_dev_auxdata so that we can use it with of_platform_populate().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
---
drivers/memory/ti-aemif.c | 8 +++++++-
include/linux/platform_data/ti-aemif.h | 23 +++++++++++++++++++++++
2 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 include/linux/platform_data/ti-aemif.h
diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index a579a0f..22c1aee 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -20,6 +20,7 @@
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/platform_data/ti-aemif.h>
#define TA_SHIFT 2
#define RHOLD_SHIFT 4
@@ -335,6 +336,8 @@ static int aemif_probe(struct platform_device *pdev)
struct device_node *np = dev->of_node;
struct device_node *child_np;
struct aemif_device *aemif;
+ struct aemif_platform_data *pdata;
+ struct of_dev_auxdata *dev_lookup;
if (np == NULL)
return 0;
@@ -343,6 +346,9 @@ static int aemif_probe(struct platform_device *pdev)
if (!aemif)
return -ENOMEM;
+ pdata = dev_get_platdata(&pdev->dev);
+ dev_lookup = pdata ? pdata->dev_lookup : NULL;
+
platform_set_drvdata(pdev, aemif);
aemif->clk = devm_clk_get(dev, NULL);
@@ -390,7 +396,7 @@ static int aemif_probe(struct platform_device *pdev)
* parameters are set.
*/
for_each_available_child_of_node(np, child_np) {
- ret = of_platform_populate(child_np, NULL, NULL, dev);
+ ret = of_platform_populate(child_np, NULL, dev_lookup, dev);
if (ret < 0)
goto error;
}
diff --git a/include/linux/platform_data/ti-aemif.h b/include/linux/platform_data/ti-aemif.h
new file mode 100644
index 0000000..ac72e11
--- /dev/null
+++ b/include/linux/platform_data/ti-aemif.h
@@ -0,0 +1,23 @@
+/*
+ * TI DaVinci AEMIF platform glue.
+ *
+ * Copyright (C) 2017 BayLibre SAS
+ *
+ * Author:
+ * Bartosz Golaszewski <bgolaszewski@baylibre.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.
+ */
+
+#ifndef __TI_DAVINCI_AEMIF_DATA_H__
+#define __TI_DAVINCI_AEMIF_DATA_H__
+
+#include <linux/of_platform.h>
+
+struct aemif_platform_data {
+ struct of_dev_auxdata *dev_lookup;
+};
+
+#endif /* __TI_DAVINCI_AEMIF_DATA_H__ */
--
2.9.3
^ permalink raw reply related
* [PATCH RESEND 0/2] ARM: davinci: improve the nand clock lookup
From: Bartosz Golaszewski @ 2017-01-13 10:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Greg,
Santosh acked patch 1/2, but suggested that it go through your tree.
Can you pick it up for 4.11?
Sekhar, will you pick up patch 2/2 for the davinci tree or should it
go together with 1/2?
---------
This is a follow-up to the series fixing the da850 clocks.
Instead of having a half-measure of leaving out the dev_id from the
clock lookup table, make the aemif driver capable of accessing it
over platform data.
Tested with da850-lcdk.
Bartosz Golaszewski (2):
memory: aemif: allow passing device lookup table as platform data
ARM: da850: add the nand dev_id to the clock lookup table
arch/arm/mach-davinci/da850.c | 10 +---------
arch/arm/mach-davinci/da8xx-dt.c | 12 +++++++++++-
drivers/memory/ti-aemif.c | 8 +++++++-
include/linux/platform_data/ti-aemif.h | 23 +++++++++++++++++++++++
4 files changed, 42 insertions(+), 11 deletions(-)
create mode 100644 include/linux/platform_data/ti-aemif.h
--
2.9.3
^ permalink raw reply
* [RFC] Kernel panic down to swiotlb when doing insmod a simple driver
From: Shawn Lin @ 2017-01-13 10:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Sorry for sending this RFC for help as I couldn't find some useful hint
to slove my issue by git-log the swiotlb commit from kernel v4.4 to
v4.9 and I'm also not familar with these stuff. So could you kindly
point me to the right direction to debug it? Thanks. :)
--------------------------------------
We just have a very simple wifi driver *built as ko module* which only
have a probe function to do the basic init work and call SDIO API to
transfer some bytes.
Env: kernel 4.4 stable tree, ARM64(rk3399)
Two cases are included:
The crash case:
u8 __aligned(32) buf[PAGE_SIZE]; //global here in ko driver file
static int wifi_probe(struct sdio_func *func, const struct
sdio_device_id *id)
{
// prepare some SDIO work before
printk("wifi_probe: buf = 0x%x\n", buf);
sdio_memcpy_toio(func, 0, buf, 200);
}
The workable case:
static int wifi_probe(struct sdio_func *func, const struct
sdio_device_id *id)
{
u8 __aligned(32) buf[PAGE_SIZE]; //move inside the probe function
// prepare some SDIO work before
printk("wifi_probe: buf = 0x%x\n", buf);
sdio_memcpy_toio(func, 0, buf, 200);
}
-------------
How to repro it:
insmod the KO module, then kernel panic when trying to bounce a buffer
in swiotlb but the workable case I didn't see kernel did that memcpy
by adding some log, strange?
parsing vmlinux, it locates to arch/arm64/lib/copy_template.S:167
165 .Lcpy_body_large:
166 /* pre-get 64 bytes data. */
167 ldp1 A_l, A_h, src, #16
168 ldp1 B_l, B_h, src, #16
169 ldp1 C_l, C_h, src, #16
170 ldp1 D_l, D_h, src, #16
--------------------------------------------------------------
The full crash log looks like
[ 236.748210] wifi_probe: buf = 0xffffff8000a40b80
[ 236.748258] swiotlb_tbl_map_single: orig_addr = 0xfffffffff8c40b80,
tlb_addr = 0xf7eae000 //I added log here
[ 236.748276] Unable to handle kernel paging request at virtual address
fffffffff8c40b80
[ 236.776486] pgd = ffffffc0b3417000
[ 236.776789] [fffffffff8c40b80] *pgd=00000000b3427003,
*pud=00000000b3427003, *pmd=0000000000000000
[ 236.777601] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 236.778093] Modules linked in: drvtst(O+)
[ 236.778463] CPU: 0 PID: 1918 Comm: insmod Tainted: G O
4.4.36 #25
[ 236.779096] Hardware name: Rockchip RK3399 Evaluation Board v3 edp
(Android) (DT)
[ 236.779753] task: ffffffc0e3db0c40 ti: ffffffc0b342c000 task.ti:
ffffffc0b342c000
[ 236.780418] PC is at __memcpy+0x100/0x180
[ 236.780777] LR is at swiotlb_tbl_map_single+0x254/0x274
[ 236.781237] pc : [<ffffff80083579c0>] lr : [<ffffff800837cf70>]
pstate: 20000145
[ 236.781885] sp : ffffffc0b342f530
[ 236.782178] x29: ffffffc0b342f530 x28: 0000000000000001
[ 236.782653] x27: 0000000000200000 x26: ffffffc0e8874810
[ 236.783127] x25: 0000000000000001 x24: 00000000000000c8
[ 236.783601] x23: fffffffff8c40b80 x22: ffffff8009158480
[ 236.784075] x21: 00000000f7eae000 x20: ffffff8009158000
[ 236.784550] x19: 00000000f7eae000 x18: 00000000004ff888
[ 236.785023] x17: 0000000000000000 x16: ffffff80081bbc74
[ 236.785498] x15: 0b030f0000000000 x14: 3034633866666666
[ 236.785972] x13: 6666666666783020 x12: 3d20726464615f67
[ 236.786446] x11: 69726f20656c676e x10: 69735f70616d5f6c
[ 236.786919] x9 : 62745f626c746f69 x8 : ffffff80082e8c1c
[ 236.787392] x7 : 0000000000000000 x6 : ffffffc0f7eae000
[ 236.787866] x5 : 0000000000000001 x4 : 0000000000000000
[ 236.788340] x3 : 0000000000000007 x2 : 0000000000000048
[ 236.788815] x1 : fffffffff8c40b80 x0 : ffffffc0f7eae000
[ 236.789291]
[ 236.789291] PC: 0xffffff8008357940:
[ 236.789728] 7940 36180062 f8408423 f80084c3 36100062 b8404423
b80044c3 36080062 78402423
[ 236.790484] 7960 780024c3 36000562 38401423 380014c3 14000028
f1020042 5400024a a8c12027
[ 236.791236] 7980 a88120c7 a8c12829 a8c1302b a88128c9 a88130cb
a8c1382d a88138cd f240145f
[ 236.791988] 79a0 54fffba1 1400001b d503201f d503201f d503201f
d503201f d503201f d503201f
[ 236.792739] 79c0 a8c12027 a8c12829 a8c1302b a8c1382d a88120c7
a8c12027 a88128c9 a8c12829
[ 236.793490] 79e0 a88130cb a8c1302b a88138cd a8c1382d f1010042
54fffeea a88120c7 a88128c9
[ 236.794243] 7a00 a88130cb a88138cd f240145f 54fff841 d65f03c0
d503201f d503201f d503201f
[ 236.794995] 7a20 d503201f d503201f d503201f d503201f d503201f
d503201f d503201f d503201f
[ 236.795748]
[ 236.795748] LR: 0xffffff800837cef0:
[ 236.796186] cef0 d0004f81 aa1a03e0 912ad821 aa1803e2 9404fda9
1400001b 6b19001f 540000e2
[ 236.796939] cf10 0b130003 53155001 11000400 8b21c2e1 f8237841
17fffff9 d0004f80 b0003821
[ 236.797694] cf30 912b7800 91344021 aa1703e2 aa1503e3 aa1503f3
97f784ba 7100079f 54000128
[ 236.798445] cf50 d0005fc0 aa1803e2 f9453c01 cb0102a0 cb0102e1
b25a6400 b25a6421 97ff6a55
[ 236.799197] cf70 aa1303e0 a94153f3 a9425bf5 a94363f7 a9446bf9
a94573fb a8c77bfd d65f03c0
[ 236.799949] cf90 d4210000 90006ee5 911200a5 a9bf7bfd 910003fd
f94018a0 f9401ca5 cb000020
[ 236.800703] cfb0 934ba800 f86078a5 b10004bf 540003e0 92402820
8b0000a5 34000084 7100049f
[ 236.801455] cfd0 54000180 14000018 721e787f 540000c1 d0005fc0
f9453c03 cb0300a0 cb030021
[ 236.802209]
[ 236.802209] SP: 0xffffffc0b342f4b0:
[ 236.802647] f4b0 09158480 ffffff80 f8c40b80 ffffffff 000000c8
00000000 00000001 00000000
[ 236.803400] f4d0 e8874810 ffffffc0 00200000 00000000 00000001
00000000 b342f530 ffffffc0
[ 236.804152] f4f0 0837cf70 ffffff80 b342f530 ffffffc0 083579c0
ffffff80 20000145 00000000
[ 236.804903] f510 ffffffff 00000000 00000140 00000000 00000000
00000080 00000000 00000000
[ 236.805654] f530 b342f5a0 ffffffc0 0837dc18 ffffff80 00000001
00000000 b342f890 ffffffc0
[ 236.806405] f550 00000001 00000000 00000000 00000000 00000000
00000000 09158000 ffffff80
[ 236.807157] f570 08f76000 ffffff80 09158000 ffffff80 b342f890
ffffffc0 e8874810 ffffffc0
[ 236.807909] f590 00000140 00000000 001efd5c 00000000 b342f600
ffffffc0 0809359c ffffff80
[ 236.808662]
[ 236.808662] X0: 0xffffffc0f7eadf80:
[ 236.809099] df80 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.809852] dfa0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.810603] dfc0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.811355] dfe0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.812106] e000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.812858] e020 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.813608] e040 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.814360] e060 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.815114]
[ 236.815114] X1: 0xfffffffff8c40b00:
[ 236.815552] 0b00 ******** ******** ******** ******** ********
******** ******** ********
[ 236.816309] 0b20 ******** ******** ******** ******** ********
******** ******** ********
[ 236.817065] 0b40 ******** ******** ******** ******** ********
******** ******** ********
[ 236.817820] 0b60 ******** ******** ******** ******** ********
******** ******** ********
[ 236.818575] 0b80 ******** ******** ******** ******** ********
******** ******** ********
[ 236.819328] 0ba0 ******** ******** ******** ******** ********
******** ******** ********
[ 236.820082] 0bc0 ******** ******** ******** ******** ********
******** ******** ********
[ 236.820836] 0be0 ******** ******** ******** ******** ********
******** ******** ********
[ 236.821595]
[ 236.821595] X6: 0xffffffc0f7eadf80:
[ 236.822032] df80 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.822785] dfa0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.823537] dfc0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.824289] dfe0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.825040] e000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.825792] e020 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.826543] e040 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.827295] e060 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.828049]
[ 236.828049] X8: 0xffffff80082e8b9c:
[ 236.828487] 8b9c 14000006 f9400453 14000004 f9400853 14000002
f9400c53 aa1303e0 94000529
[ 236.829239] 8bbc aa1303e0 94000532 52800000 14000002 128002a0
f9400bf3 a8c27bfd d65f03c0
[ 236.829993] 8bdc a9bf7bfd 71001c1f aa0403e1 910003fd 128002a3
54000101 f94048e0 12800163
[ 236.830746] 8bfc f9400c00 b4000080 2a0603e2 9400049e 2a0003e3
2a0303e0 a8c17bfd d65f03c0
[ 236.831497] 8c1c a9b97bfd 7100081f 910003fd a90363f7 d0006477
f90023f9 a9025bf5 a90153f3
[ 236.832249] 8c3c f9452ae2 aa0403f6 f90037a2 53001cb4 aa0603f5
f94048f3 54000061 f9400660
[ 236.833002] 8c5c 14000008 71000c1f 54000061 f9400a60 14000004
71001c1f 54000101 f9400e60
[ 236.833754] 8c7c 12800167 b40008a0 aa1603e1 2a1503e2 94000426
14000040 128002a7 350007e0
[ 236.834510]
[ 236.834510] X16: 0xffffff80081bbbf4:
[ 236.834955] bbf4 2a1503e1 97fffec4 3100101f 54000261 d5384100
f9400800 90000002 912c4042
[ 236.835708] bc14 91102003 f9020402 f9000476 b9001075 37f80114
f9401fa0 f9000c60 f94023a0
[ 236.836460] bc34 f9001060 52800020 b9001460 14000002 b900147f
12804060 f94027a2 93407c00
[ 236.837212] bc54 f9452a61 eb01005f 54000040 97fb80af a94153f3
a9425bf5 a8c57bfd d65f03c0
[ 236.837964] bc74 a9b67bfd 910003fd a9025bf5 f0006dd6 f90023f9
a90363f7 aa0003f8 aa0103f7
[ 236.838716] bc94 f9452ac0 aa0403f9 a90153f3 f9004fa0 aa0203f3
aa0303f4 b4000302 d5384100
[ 236.839466] bcb4 f9400400 aa0203e3 b1004063 fa403062 9a9f87e1
9101e3a0 b40000c1 aa0203e1
[ 236.840218] bcd4 d2800202 94066c4a b4000080 1400001d a9007c1f
1400001b f9403fa1 910223a0
[ 236.840973]
[ 236.840973] X20: 0xffffff8009157f80:
[ 236.841418] 7f80 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.842169] 7fa0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.842920] 7fc0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.843672] 7fe0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.844422] 8000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.845174] 8020 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.845925] 8040 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.846677] 8060 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.847431]
[ 236.847431] X22: 0xffffff8009158400:
[ 236.847876] 8400 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.848628] 8420 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.849379] 8440 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.850130] 8460 00000000 00000000 00000000 00000000 00030003
00000000 00f100f1 00000000
[ 236.850882] 8480 00000080 00000000 f7ea6000 00000000 f7eee000
00000000 00000000 00000000
[ 236.851633] 84a0 00010001 00000001 f7f75000 ffffffc0 f7eae000
00000000 f7ea5000 ffffffc0
[ 236.852388] 84c0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.853139] 84e0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.853892]
[ 236.853892] X23: 0xfffffffff8c40b00:
[ 236.854338] 0b00 ******** ******** ******** ******** ********
******** ******** ********
[ 236.855093] 0b20 ******** ******** ******** ******** ********
******** ******** ********
[ 236.855846] 0b40 ******** ******** ******** ******** ********
******** ******** ********
[ 236.856601] 0b60 ******** ******** ******** ******** ********
******** ******** ********
[ 236.857356] 0b80 ******** ******** ******** ******** ********
******** ******** ********
[ 236.858109] 0ba0 ******** ******** ******** ******** ********
******** ******** ********
[ 236.858864] 0bc0 ******** ******** ******** ******** ********
******** ******** ********
[ 236.859620] 0be0 ******** ******** ******** ******** ********
******** ******** ********
[ 236.860377]
[ 236.860377] X26: 0xffffffc0e8874790:
[ 236.860822] 4790 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.861573] 47b0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.862324] 47d0 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 236.863075] 47f0 00000000 00000000 00000000 00000000 e885d140
ffffffc0 ffffffff 00000000
[ 236.863828] 4810 08fefcc0 ffffff80 e933b480 ffffffc0 e885d140
ffffffc0 e5b7c020 ffffffc0
[ 236.864581] 4830 e5b24430 ffffffc0 08fefcd0 ffffff80 e929d480
ffffffc0 08fef9d0 ffffff80
[ 236.865335] 4850 e88999d8 ffffffc0 00000005 00000007 00000000
00000000 00000000 00000000
[ 236.866087] 4870 00000001 00000000 e8874878 ffffffc0 e8874878
ffffffc0 00000000 00000000
[ 236.866843]
[ 236.866843] X29: 0xffffffc0b342f4b0:
[ 236.867288] f4b0 09158480 ffffff80 f8c40b80 ffffffff 000000c8
00000000 00000001 00000000
[ 236.868041] f4d0 e8874810 ffffffc0 00200000 00000000 00000001
00000000 b342f530 ffffffc0
[ 236.868794] f4f0 0837cf70 ffffff80 b342f530 ffffffc0 083579c0
ffffff80 20000145 00000000
[ 236.869547] f510 ffffffff 00000000 00000140 00000000 00000000
00000080 00000000 00000000
[ 236.870297] f530 b342f5a0 ffffffc0 0837dc18 ffffff80 00000001
00000000 b342f890 ffffffc0
[ 236.871049] f550 00000001 00000000 00000000 00000000 00000000
00000000 09158000 ffffff80
[ 236.871800] f570 08f76000 ffffff80 09158000 ffffff80 b342f890
ffffffc0 e8874810 ffffffc0
[ 236.872552] f590 00000140 00000000 001efd5c 00000000 b342f600
ffffffc0 0809359c ffffff80
[ 236.873304]
[ 236.873442] Process insmod (pid: 1918, stack limit = 0xffffffc0b342c020)
[ 236.874031] Stack: (0xffffffc0b342f530 to 0xffffffc0b3430000)
[ 236.874539] f520: ffffffc0b342f5a0
ffffff800837dc18
[ 236.875226] f540: 0000000000000001 ffffffc0b342f890 0000000000000001
0000000000000000
[ 236.875915] f560: 0000000000000000 ffffff8009158000 ffffff8008f76000
ffffff8009158000
[ 236.876605] f580: ffffffc0b342f890 ffffffc0e8874810 0000000000000140
00000000001efd5c
[ 236.877293] f5a0: ffffffc0b342f600 ffffff800809359c ffffffc0b342f890
ffffffc0e8874810
[ 236.877981] f5c0: 0000000000000000 0000000000000001 0000000000000001
ffffffc0b342f938
[ 236.878670] f5e0: ffffffc0b342f8f0 ffffffc0e5b7c738 0000000000001000
0000000000000000
[ 236.879358] f600: ffffffc0b342f640 ffffff800871113c ffffffc0b342f8f0
ffffff8008f88b60
[ 236.880047] f620: 0000000000000000 ffffffc0e8874810 0000000000000001
ffffff8000a40b80
[ 236.880735] f640: ffffffc0b342f6a0 ffffff80087129cc ffffffc0e5b45018
ffffffc0b342f8b0
[ 236.881423] f660: ffffff8008f76000 0000000020002775 ffffffc0e5b7c700
ffffffc0b342f8b0
[ 236.882112] f680: ffffff8008f76000 0000000000000001 ffffffc0b342f890
0000000000000001
[ 236.882800] f6a0: ffffffc0b342f730 ffffff80087132e0 ffffffc0e5b45018
ffffffc0e5b7c000
[ 236.883489] f6c0: ffffffc0e5b7c700 ffffff8000a40b80 ffffff8008f76000
ffffffc0b342f8b0
[ 236.884178] f6e0: ffffffc0b342f938 ffffffc0b342f8f0 0000000000001000
ffffff800871325c
[ 236.884867] f700: ffffffc0e5b45018 ffffffc0e5b7c000 ffffffc0e5b7c700
ffffff8000a40b80
[ 236.885555] f720: ffffff8008f76000 cb88537fdc8ba624 ffffffc0b342f770
ffffff80086f8b44
[ 236.886243] f740: ffffffc0e5b7c000 00000000000001f4 00000000ffffff85
ffffff80086f8ac0
[ 236.886931] f760: ffffffc0e5b7c000 ffffffc0b342f938 ffffffc0b342f7a0
ffffff80087ae0e8
[ 236.887619] f780: ffffffc0b342f938 ffffffc0e5b7c000 00000000ffffff85
ffffffc0b342f938
[ 236.888308] f7a0: ffffffc0b342f7c0 ffffff80086f9c74 ffffffc0e5b7c000
ffffffc0b342f938
[ 236.888996] f7c0: ffffffc0b342f800 ffffff800870421c 00000000000000c8
0000000000000001
[ 236.889685] f7e0: ffffffc0e5b7c800 ffffff8000a40b80 ffffff8008f76000
ffffffc0b342f8b0
[ 236.890372] f800: ffffffc0b342f9a0 ffffff8008705800 00000000000000c8
0000000000000000
[ 236.891061] f820: ffffff8000a40b80 0000000000000001 ffffff8008dfdc48
ffffff8008dfdc81
[ 236.891748] f840: ffffff8008dfdcdb 0000000000000001 ffffffc0e5b44c00
00000000000000c8
[ 236.892436] f860: ffffffc0e5b44c00 00000000000000c8 000000000000002a
ffffff800911d000
[ 236.893125] f880: 0000000000000140 ffffff8000000000 03ffffbdbfe31002
000000c800000b80
[ 236.893813] f8a0: 0000000000000000 0000000000000000 940000c800000035
0000000000000000
[ 236.894501] f8c0: 0000000000000000 00000000000001b5 00000000ffffff8d
0000000000000000
[ 236.895190] f8e0: ffffffc0b342f8f0 ffffffc0b342f938 000000003b9aca00
00000001000000c8
[ 236.895878] f900: 00000100ffffff8d 0000000000000000 0000000000000000
ffffffc0b342f938
[ 236.896566] f920: 0000000000000001 ffffffc0b342f890 0000000000000000
0000000000000000
[ 236.897254] f940: ffffffc0b342f8b0 ffffffc0b342f8f0 0000000000000000
0000000000000000
[ 236.897942] f960: 0000000000000000 ffffffc0b342f968 ffffffc0b342f968
ffffff80086f8b98
[ 236.898630] f980: 0000000000000000 0000000000000000 0000000000000000
cb88537fdc8ba624
[ 236.899319] f9a0: ffffffc0b342fa00 ffffff8008705954 ffffffc0e5b44c00
00000000000000c8
[ 236.900007] f9c0: ffffff8000a40b80 ffffff8000a410a0 ffffff8000a407d8
0000000000000029
[ 236.900695] f9e0: 0000000000000000 ffffffc0e926a480 0000000000000001
0000000000000038
[ 236.901384] fa00: ffffffc0b342fa10 ffffff8000a40108 ffffffc0b342fa60
ffffff8008704734
[ 236.902072] fa20: ffffffc0e5b44c08 0000000000000000 ffffffc0e5b44c00
ffffff8000a40410
[ 236.902760] fa40: ffffff8000a407d8 0000000000000029 0000000000000000
ffffff8008704704
[ 236.903447] fa60: ffffffc0b342faa0 ffffff80084bfd6c ffffffc0e5b44c08
0000000000000000
[ 236.904136] fa80: ffffff800915d000 ffffff8008fef000 ffffff8000a407d8
0000000000000000
[ 236.904824] faa0: ffffffc0b342faf0 ffffff80084bff68 ffffffc0e5b44c08
ffffffc0e5b44c68
[ 236.905512] fac0: ffffff8000a407d8 ffffff80084bff04 ffffff8009028a38
0000000000000000
[ 236.906201] fae0: 0000000000000000 ffffff80084bff40 ffffffc0b342fb20
ffffff80084bee18
[ 236.906889] fb00: 0000000000000000 ffffff8008f76000 ffffff8000a407d8
ffffff80084bff04
[ 236.907577] fb20: ffffffc0b342fb70 ffffff80084bf8ac ffffff8000a407d8
0000000000000000
[ 236.908265] fb40: ffffffc0f6e996c0 ffffff8008fef000 ffffffc0b342fb60
ffffffc0e8b8f4a8
[ 236.908953] fb60: ffffffc0e5486ea8 cb88537fdc8ba624 ffffffc0b342fb80
ffffff80084bf45c
[ 236.909641] fb80: ffffffc0b342fbc0 ffffff80084c0afc ffffff8000a407d8
ffffff8008f84b20
[ 236.910329] fba0: 0000000000000000 ffffff8008f76000 ffffff8008f84b20
cb88537fdc8ba624
[ 236.911017] fbc0: ffffffc0b342fbf0 ffffff8008704580 ffffff8000a44000
ffffff8008f84b20
[ 236.911706] fbe0: ffffffc0f6dda1c0 ffffff8008f76000 ffffffc0b342fc00
ffffff8000a40228
[ 236.912394] fc00: ffffffc0b342fc10 ffffff8000a4400c ffffffc0b342fc20
ffffff8008082ba4
[ 236.913082] fc20: ffffffc0b342fcb0 ffffff800815e564 ffffff8000a40880
ffffff8008f96000
[ 236.913770] fc40: 0000000000000001 ffffffc0d58a1e40 ffffff8008a4a2d0
0000000000000000
[ 236.914458] fc60: 0000000000000001 ffffff8008f96000 ffffff8008a4a2d0
0000000000000000
[ 236.915146] fc80: 0000000000000000 ffffffc0e926a480 0000000000000001
ffffffc0b342fe50
[ 236.915835] fca0: 0000000000000001 cb88537fdc8ba624 ffffffc0b342fce0
ffffff80081150f0
[ 236.916523] fcc0: ffffff8000a40880 ffffffc0b342fe50 0000000000000001
ffffff8008f96000
[ 236.917212] fce0: ffffffc0b342fe00 ffffff800811562c 00000000000014d8
ffffff800ca364d8
[ 236.917900] fd00: 0000007f922804e8 0000000000000000 ffffff8008f76000
000000555bb25d20
[ 236.918588] fd20: 0000000000010000 ffffffc0b342c000 ffffff8008a42000
ffffffc0b342c000
[ 236.919275] fd40: 0000000000000077 0000000000000076 0000000000000064
0000000000000072
[ 236.919963] fd60: 000000000000006e 0000000000000018 0000000000000040
0000000000000040
[ 236.920652] fd80: ffffff8000a42500 ffffff8008f76000 0000000000000124
ffffff8008112064
[ 236.921340] fda0: ffffff8008f76000 000000555bb25d20 000000000000011d
0000000000000069
[ 236.922028] fdc0: ffffffc0b342fe00 0000000000000000 0000000000000000
0000000000000000
[ 236.922716] fde0: 0000007f00000000 0000000000000000 ffffffc000000000
cb88537fdc8ba624
[ 236.923405] fe00: 0000000000000000 ffffff80080826f0 0000000000000000
0000007f9223f010
[ 236.924092] fe20: ffffffffffffffff 0000007f9235e904 0000000060000000
0000000000000015
[ 236.924780] fe40: 000000000000011d 0000000000000069 ffffff800c9f5000
00000000000414d8
[ 236.925469] fe60: ffffff800ca35bd8 ffffff800ca1711f ffffff800ca17d08
0000000000002500
[ 236.926157] fe80: 0000000000002b00 0000000000000000 0000000000000000
0000000000000dd8
[ 236.926844] fea0: 0000002300000022 000000000000000d 0000000000000009
cb88537fdc8ba624
[ 236.927532] fec0: 0000007f9223f010 00000000000414d8 000000555bb25d20
0000000000000000
[ 236.928220] fee0: 0000000000000001 0000000000000000 0000000000000000
0000007f9223f000
[ 236.928909] ff00: 0000000000000069 0000007f9223f010 0000000000042000
0000000000000001
[ 236.929597] ff20: 0000007f92280fe0 0000007f92281000 0000007f923f4a70
0000000000002000
[ 236.930285] ff40: 000000555bb23ae0 0000007f9235e8e4 0000000000000f00
00000000000414d8
[ 236.930972] ff60: 0000007f9223f010 0000000000000003 00000000000414d8
0000000000000000
[ 236.931660] ff80: 0000000000000000 000000555bb26d20 0000000000000010
0000000000000000
[ 236.932348] ffa0: 0000000000000000 0000007fe750e100 000000555bade83c
0000007fe750e0b0
[ 236.933036] ffc0: 0000007f9235e904 0000000060000000 0000007f9223f010
0000000000000069
[ 236.933725] ffe0: 0000000000000000 0000000000000000 3420320216190109
7375020101333632
[ 236.934409] Call trace:
[ 236.934632] Exception stack(0xffffffc0b342f340 to 0xffffffc0b342f470)
[ 236.935200] f340: 00000000f7eae000 0000008000000000 ffffffc0b342f530
ffffff80083579c0
[ 236.935888] f360: 0000000020000145 0000000000000053 ffffff8008f93688
000000000007e7b8
[ 236.936577] f380: 0000000000000002 ffffff8008f93688 0000000000000063
000000000909b7e8
[ 236.937266] f3a0: ffffffc0b342f440 ffffff80080e8d08 ffffff8008f76000
ffffff80080e8cd4
[ 236.937953] f3c0: 00000000f7eae000 ffffff8009158480 fffffffff8c40b80
00000000000000c8
[ 236.938641] f3e0: 0000000000000001 ffffffc0e8874810 0000000000200000
cb88537fdc8ba624
[ 236.939329] f400: ffffffc0f7eae000 fffffffff8c40b80 0000000000000048
0000000000000007
[ 236.940017] f420: 0000000000000000 0000000000000001 ffffffc0f7eae000
0000000000000000
[ 236.940705] f440: ffffff80082e8c1c 62745f626c746f69 69735f70616d5f6c
69726f20656c676e
[ 236.941392] f460: 3d20726464615f67 6666666666783020
[ 236.941826] [<ffffff80083579c0>] __memcpy+0x100/0x180
[ 236.942274] [<ffffff800837dc18>] swiotlb_map_sg_attrs+0xa8/0x170
[ 236.942810] [<ffffff800809359c>] __swiotlb_map_sg_attrs+0x24/0x8c
[ 236.943353] [<ffffff800871113c>]
dw_mci_pre_dma_transfer.isra.16+0xf0/0x11c
[ 236.943967] [<ffffff80087129cc>] __dw_mci_start_request+0x17c/0x4d0
[ 236.944520] [<ffffff80087132e0>] dw_mci_request+0xb8/0xf0
[ 236.945002] [<ffffff80086f8b44>] __mmc_start_request+0x9c/0xc0
[ 236.945520] [<ffffff80087ae0e8>] mmc_start_request.part.17+0x100/0x11c
[ 236.946097] [<ffffff80086f9c74>] mmc_wait_for_req+0x78/0x1a8
[ 236.946600] [<ffffff800870421c>] mmc_io_rw_extended+0x27c/0x2fc
[ 236.947124] [<ffffff8008705800>] sdio_io_rw_ext_helper+0x1e4/0x238
[ 236.947670] [<ffffff8008705954>] sdio_memcpy_toio+0x24/0x2c
[ 236.948169] [<ffffff8000a40108>] wifi_probe+0xa8/0x198 [drvtst]
[ 236.948708] [<ffffff8008704734>] sdio_bus_probe+0xb0/0x140
[ 236.949195] [<ffffff80084bfd6c>] driver_probe_device+0x118/0x2b0
[ 236.949724] [<ffffff80084bff68>] __driver_attach+0x64/0x90
[ 236.950212] [<ffffff80084bee18>] bus_for_each_dev+0x80/0xb0
[ 236.950706] [<ffffff80084bf8ac>] driver_attach+0x20/0x28
[ 236.951176] [<ffffff80084bf45c>] bus_add_driver+0xe8/0x1ec
[ 236.951661] [<ffffff80084c0afc>] driver_register+0x98/0xe4
[ 236.952147] [<ffffff8008704580>] sdio_register_driver+0x24/0x2c
[ 236.952675] [<ffffff8000a40228>] wifi_sdio_init+0x30/0x68 [drvtst]
[ 236.953241] [<ffffff8000a4400c>] wifi_drv_init+0xc/0x38 [drvtst]
[ 236.953789] [<ffffff8008082ba4>] do_one_initcall+0x17c/0x198
[ 236.954293] [<ffffff800815e564>] do_init_module+0x60/0x1b8
[ 236.954779] [<ffffff80081150f0>] load_module+0x1660/0x1a50
[ 236.955264] [<ffffff800811562c>] SyS_init_module+0x14c/0x180
[ 236.955765] [<ffffff80080826f0>] el0_svc_naked+0x24/0x28
[ 236.956237] Code: d503201f d503201f d503201f d503201f (a8c12027)
[ 236.956794] ---[ end trace 2030cf6e7c948d05 ]---
[ 236.984113] Kernel panic - not syncing: Fatal exception in interrupt
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage
From: Jerome Brunet @ 2017-01-13 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2r3476atl.fsf@baylibre.com>
On Thu, 2017-01-12 at 16:52 -0800, Kevin Hilman wrote:
> Jerome Brunet <jbrunet@baylibre.com> writes:
>
> >
> > OdroidC2 GbE link breaks under heavy tx transfer. This happens even
> > if the
> > MAC does not enable Energy Efficient Ethernet (No Low Power state
> > Idle on
> > the Tx path). The problem seems to come from the phy Rx path,
> > entering the
> > LPI state.
> >
> > Disabling EEE advertisement on the phy prevent this feature to be
> > negociated with the link partner and solve the issue.
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > ---
> >
> > This patch is based on Linus recent master branch [0]
> > This patch depends on the series [1] which has been merged in this
> > branch.
> >
> > 0: ba6d973f78eb ("Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> > 1: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrun
> > et at baylibre.com
> > ???Fix integration of eee-broken-modes
> > ???
> > ?arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 12
> > ++++++++++++
> > ?1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > index 238fbeacd330..d8933e9e9a5a 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > @@ -147,6 +147,18 @@
> > ? status = "okay";
> > ? pinctrl-0 = <ð_rgmii_pins>;
> > ? pinctrl-names = "default";
> > + phy-handle = <ð_phy0>;
> > +
> > + mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + eth_phy0: ethernet-phy at 0 {
> > + reg = <0>;
> > + eee-broken-1000t;
> > + };
> > + };
>
> There's already an MDIO node in the meson-gx.dtsi (using the same
> compatible), shouldn't you just override that and add the new
> properties?
Hum, yeah in the changes queued from 4.11, right ?
But not in the latest rc from Linus. Since this is a fix, it was
actually target for this branch.
I guess you'd prefer to avoid merge conflicts when the 4.10 is tagged.
How do you want to handle this ?
>
> What would make things easier is if the names were like Martin used
> in
> his reset patch, so that when I merge them together it's not a major
> conflict.
Sure, no problem. I'll change it to match what has been done by Martin.
>
> Thanks,
>
> Kevin
>
> [1] https://patchwork.kernel.org/patch/9459409/
^ permalink raw reply
* [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Sebastian Hesselbarth @ 2017-01-13 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113091222.7132-4-chris.packham@alliedtelesis.co.nz>
On 13.01.2017 10:12, Chris Packham wrote:
> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>
> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
> from Marvell.
>
> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
>
> Notes:
> Changes in v2:
> - include sdio support for the 98DX4251
> Changes in v3:
> - None
> Changes in v4:
> - Correct some discrepencies between binding and driver.
Well, unfortunately I still see differences between the "gpio" in
the binding and "gpo" in the driver.
Please go back to that list I sent you yesterday and fix them all.
[...]
> diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
> new file mode 100644
> index 000000000000..b5bd23992fdf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
> @@ -0,0 +1,46 @@
[...]
> +mpp6 6 gpio, sd0(clk), dev(a2)
e.g. this is "gpio" ...
[...]
> diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
> index e4ea71a9d985..9601d662c7f5 100644
> --- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
> +++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
> @@ -49,6 +49,10 @@ enum armada_xp_variant {
[...]
> + MPP_MODE(6,
> + MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
... but here it is "gpo".
Sebastian
^ permalink raw reply
* [RFC 01/13] KVM: arm/arm64: Add vITS save/restore API documentation
From: Marc Zyngier @ 2017-01-13 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e58a566d-e100-d31a-fb26-a15a793d3623@redhat.com>
On 13/01/17 09:07, Auger Eric wrote:
> Hi Marc,
>
> On 12/01/2017 17:52, Marc Zyngier wrote:
>> Hi Eric,
>>
>> On 12/01/17 15:56, Eric Auger wrote:
>>> Add description for how to access vITS registers and how to flush/restore
>>> vITS tables into/from memory
>>>
>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>> ---
>>> Documentation/virtual/kvm/devices/arm-vgic-its.txt | 70 ++++++++++++++++++++++
>>> 1 file changed, 70 insertions(+)
>>>
>>> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
>>> index 6081a5b..bd74613 100644
>>> --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt
>>> +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
>>> @@ -36,3 +36,73 @@ Groups:
>>> -ENXIO: ITS not properly configured as required prior to setting
>>> this attribute
>>> -ENOMEM: Memory shortage when allocating ITS internal data
>>> +
>>> + KVM_DEV_ARM_VGIC_GRP_ITS_REGS
>>> + Attributes:
>>> + The attr field of kvm_device_attr encodes the offset of the
>>> + ITS register, relative to the ITS control frame base address
>>> + (ITS_base).
>>> +
>>> + kvm_device_attr.addr points to a __u64 value whatever the width
>>> + of the addressed register (32/64 bits).
>>> +
>>> + Writes to read-only registers are ignored by the kernel except
>>> + for a single register, GITS_READR. Normally this register is RO
>>> + but it needs to be restored otherwise commands in the queue will
>>> + be re-executed after CWRITER setting.
>>> +
>>> + For other registers, Getting or setting a register has the same
>>> + effect as reading/writing the register on real hardware.
>>> + Errors:
>>> + -ENXIO: Offset does not correspond to any supported register
>>> + -EFAULT: Invalid user pointer for attr->addr
>>> + -EINVAL: Offset is not 64-bit aligned
>>> +
>>> + KVM_DEV_ARM_VGIC_GRP_ITS_TABLES
>>> + Attributes
>>> + The attr field of kvm_device_attr is not used.
>>> +
>>> + request the flush-save/restore of the ITS tables, namely
>>> + the device table, the collection table, all the ITT tables,
>>> + the LPI pending tables. On save, the tables are flushed
>>> + into guest memory at the location provisionned by the guest
>>
>> provisioned
>>
>>> + in GITS_BASER (device and collection tables), on MAPD command
>>> + (ITT_addr), GICR_PENDBASERs (pending tables).
>>> +
>>> + This means the GIC should be restored before the ITS and all
>>> + ITS registers but the GITS_CTRL must be restored before
>>> + restoring the ITS tables.
>>> +
>>> + Note the LPI configuration table is read-only for the
>>> + in-kernel ITS and its save/restore goes through the standard
>>> + RAM save/restore.
>>> +
>>> + The layout of the tables in guest memory defines an ABI.
>>> + The entries are laid out in memory as follows;
>>> +
>>> + Device Table Entry (DTE) layout: entry size = 16 bytes
>>> +
>>> + bits: | 63 ... 32 | 31 ... 6 | 5 | 4 ... 0 |
>>> + values: | DeviceID | Resv | V | Size |
>>> +
>>> + bits: | 63 ... 44 | 43 ... 0 |
>>> + values: | Resv | ITT_addr |
>>
>> While I appreciate this layout represents the absolute maximum an ITS
>> could implement, I'm a bit concerned about the amount of memory we may
>> end-up requiring here. All the ITSs implementations I know of seem to
>> get away with 8 bytes per entry. Maybe I'm just too worried.
>
> OK so I would propose a 16b DeviceId and 16b eventid
>
> bits: | 63 ... 48 | 47 ... 4 | 3 ... 0 |
> values: | DeviceID | ITT_addr | Size |
>
> I can use the size field as a validity indicator
Note that you are allowed to use a 0 size field. It means 1 bit of
EventID (2 possible interrupts). So maybe using a particular address as
a valid flag?
>
>>
>> Also, please mention that ITT_addr is actually ITT_addr[51:8], as we're
>> guaranteed to have an ITT that is 256 byte aligned.
> sure
>>
>>> +
>>> + Collection Table Entry (CTE) layout: entry size = 8 bytes
>>> +
>>> + bits: | 63| 62 .. 52 | 51 ... 16 | 15 ... 0 |
>>> + values: | V | RES0 | RDBase | ICID |
>>> +
>>> + Interrupt Translation Table Entry (ITTE) layout: entry size = 16 bytes
>>
>> The actual name is Interrupt Translation Entry (ITE). I have a patch
>> renaming this all over the vgic-its.c file...
> ok
>>
>>> +
>>> + bits: | 63 ... 32 | 31 ... 17 | 16 | 15 ... 0 |
>>> + values: | DeviceID | RES0 | V | ICID |
>>> +
>>> + bits: | 63 ... 32 | 31 ... 0 |
>>> + values: | pINTID | EventID |
>>
>> Same concern here. 32bit DevID, EventID and INTID seem a bit over the
>> top. But maybe we shouldn't be concerned about memory... ;-)
> So I would suggest encoding
> 16b DeviceId
> 16b eventid
> 16b collection ID
> 16b pINTID
>
> bits: | 63 ... 48 | 47 ... 32 | 31 ... 15 | 15 ... 0 |
> values: | DeviceID | pINTID | EventId | ICID |
>
> a null pINTID would meen the ITE is invalid.
>
> Does that make sense or should I instead reduce the number of bits
> allocated to collections and keep the pINTID bit number larger?
16bit worth of collections is quite a lot (64k CPUs?). I'd be perfectly
fine with a smaller number, but let's see what people think.
>
>
>>
>>> +
>>> + LPI Pending Table layout:
>>> +
>>> + As specified in the ARM Generic Interrupt Controller Architecture
>>> + Specification GIC Architecture version 3.0 and version 4. The first
>>> + 1kB contains only zeros.
>>>
>>
>> You definitely want to relax this. An ITS implementation is allowed (and
>> actually encouraged) to maintain a coarse map in the first kB, and use
>> this to quickly scan the table, which would be very useful on restore.
> Maybe I miss something here. Currently I restore the ITEs before the
> pending tables. So considering all the ITEs I know which LPI are defined
> and which pending bits need to be restored. Why would I need to use a
> coarse map for?
You could, instead of testing all the bits for which you can generate an
LPI, look at the coarse map, which usually uses one bit to represent
something like 64 bits of pending table, and find out what is currently
pending. That's what HW does, but maybe there is no need to do this for
the SW implementation, specially if we have very few LPIs.
> I understand the CPU cannot write the pending tables in our back, spec
> says behavior would be unpredictable, right?
Absolutely. Only the ITS can touch that memory.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-13 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrXYwp4BJbwFo4P1hEvubyDh1mN+W4L-tQVYjh3e7F-Q9A@mail.gmail.com>
On Wed, Jan 11, 2017 at 10:12:36AM -0800, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 2:01 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote:
> >> On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote:
> >> > From: Will Deacon <will.deacon@arm.com>
> >> >
> >> > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> >> > in an unexpected I/O page fault from the legacy virtio-blk PCI device:
> >> >
> >> > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> >> > [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> >> > [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> >> > [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> >> > [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> >> > [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> >> > [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> >> > [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> >> > [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> >> > [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> >> >
> >> > <system hangs failing to read partition table>
> >> >
> >> > This is because the virtio-blk is behind an SMMU, so we have consequently
> >> > swizzled its DMA ops and configured the SMMU to translate accesses. This
> >> > then requires the vring code to use the DMA API to establish translations,
> >> > otherwise all transactions will result in fatal faults and termination.
> >> >
> >> > Given that ARM-based systems only see an SMMU if one is really present
> >> > (the topology is all described by firmware tables such as device-tree or
> >> > IORT), then we can safely use the DMA API for all virtio devices.
> >> >
> >> > Cc: Andy Lutomirski <luto@kernel.org>
> >> > Cc: Michael S. Tsirkin <mst@redhat.com>
> >> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> >>
> >> I'd like to better understand then need for this one.
> >> Can't the device in question just set VIRTIO_F_IOMMU_PLATFORM ?
> >>
> >> I'd rather we avoided need for more hacks and just
> >> have everyone switch to that.
> >
> > There are a couple of problems with VIRTIO_F_IOMMU_PLATFORM:
> >
> > 1. It doesn't exist for legacy devices, which are all we have on the
> > platform in question.
> >
> > 2. It's not documented in the virtio sp^H^HSTOP PRESS. I see you applied
> > my patch ;). Thanks.
> >
> > In which case, for non-legacy devices we should definitely be using
> > VIRTIO_F_IOMMU_PLATFORM, but since this platform hasn't yet moved to the
> > world of flying cars, could we unconditionally set the DMA ops on ARM
> > for legacy devices? The alternative is disabling the SMMU altogether,
> > but that's less than ideal because there are non-virtio devices on the
> > same PCI bus.
>
> Also, on ARM, using the DMA API appears to *always* be the correct
> approach. Why not do it all the time, then? The non-DMA-API path is
> a legacy thing that is needed because a few platforms incorrectly
> enumerate their IOMMUs. ARM gets it right, so I don't see why ARM
> should be subject to the legacy mess.
That's what my patch does, but since modern virtio has the
VIRTIO_F_IOMMU_PLATFORM flag (and the spec says if it's not present then
the driver must pass physical addresses), it feels to me like we should
just honour that so that different architectures all have the same
behaviour. For legacy devices, the horse has bolted and we need
arch-specific behaviours to keep things working.
Will
^ permalink raw reply
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-13 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113084513.wvuxkanrlmgz3ang@pengutronix.de>
Ok so I am going to send the v9 asap.
Thanks
2017-01-13 9:45 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> On Fri, Jan 13, 2017 at 09:29:03AM +0100, Wolfram Sang wrote:
>>
>> > (But note that this is irrelevant for the patch as the driver doesn't
>> > claim to support this kind of transfer.)
>>
>> Yes, I wanted to mention that, too.
>>
>> I'd think the series is good to go in?
>
> AFAICT there are some unaddressed comments that Cedrics claimed to fix
> before our discussion was dominated by block transfers.
>
> Best regards
> Uwe
>
>
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 2/2] arm64: cacheinfo: add support to override cache levels via device tree
From: Sudeep Holla @ 2017-01-13 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58789899.3080909@huawei.com>
On 13/01/17 09:06, Tan Xiaojun wrote:
> On 2017/1/13 2:29, Sudeep Holla wrote:
>> The cache hierarchy can be identified through Cache Level ID(CLIDR)
>> architected system register. However in some cases it will provide
>> only the number of cache levels that are integrated into the processor
>> itself. In other words, it can't provide any information about the
>> caches that are external and/or transparent.
>>
>> Some platforms require to export the information about all such external
>> caches to the userspace applications via the sysfs interface.
>>
>> This patch adds support to override the cache levels using device tree
>> to take such external non-architected caches into account.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
> Tested-by: Tan Xiaojun <tanxiaojun@huawei.com>
>
Thanks for testing.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-13 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112232931-mutt-send-email-mst@kernel.org>
On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 11, 2017 at 10:01:39AM +0000, Will Deacon wrote:
> > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote:
> > > > From: Will Deacon <will.deacon@arm.com>
> > > >
> > > > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> > > > in an unexpected I/O page fault from the legacy virtio-blk PCI device:
> > > >
> > > > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> > > > [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> > > > [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > >
> > > > <system hangs failing to read partition table>
> > > >
> > > > This is because the virtio-blk is behind an SMMU, so we have consequently
> > > > swizzled its DMA ops and configured the SMMU to translate accesses. This
> > > > then requires the vring code to use the DMA API to establish translations,
> > > > otherwise all transactions will result in fatal faults and termination.
> > > >
> > > > Given that ARM-based systems only see an SMMU if one is really present
> > > > (the topology is all described by firmware tables such as device-tree or
> > > > IORT), then we can safely use the DMA API for all virtio devices.
> > > >
> > > > Cc: Andy Lutomirski <luto@kernel.org>
> > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > >
> > > I'd like to better understand then need for this one.
> > > Can't the device in question just set VIRTIO_F_IOMMU_PLATFORM ?
> > >
> > > I'd rather we avoided need for more hacks and just
> > > have everyone switch to that.
> >
> > There are a couple of problems with VIRTIO_F_IOMMU_PLATFORM:
> >
> > 1. It doesn't exist for legacy devices, which are all we have on the
> > platform in question.
> >
> > 2. It's not documented in the virtio sp^H^HSTOP PRESS. I see you applied
> > my patch ;). Thanks.
> >
> > In which case, for non-legacy devices we should definitely be using
> > VIRTIO_F_IOMMU_PLATFORM, but since this platform hasn't yet moved to the
> > world of flying cars, could we unconditionally set the DMA ops on ARM
> > for legacy devices? The alternative is disabling the SMMU altogether,
> > but that's less than ideal because there are non-virtio devices on the
> > same PCI bus.
> >
>
> I'd rather people didn't use SMMU with legacy devices.
I'm afraid we've been doing that for two years and the model already
exists in a mature state, being actively used for development and
validation by ARM and our partners. One of the big things its used for
is to develop SMMU and GIC (our interrupt controller) code with PCI, so
dropping the SMMU from the picture isn't an option.
> Can't you guys just code up the virtio 1 layout in QEMU?
> I took a look and it's not a big deal now that two other
> transports converted, except mmio code in QEMU doesn't
> use linux header to it's a bit messy.
> I'll send a patch to clean that up.
If the model ever changes in this area (which isn't planned atm), the
right thing to do would be to move to modern virtio. However, we're stuck
with what we have for the forseeable future and it works just fine if we
use the DMA API. If we don't use it, Linux no longer boots because it
installs the SMMU-backed DMA ops for the virtio devices and everything
faults.
I really don't understand why this is controversial.
Will
^ 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