* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline
From: Shawn Guo @ 2016-12-30 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480276484-5482-1-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas F?rber wrote:
> Found while reviewing Marvell dsa bindings usage.
>
> Fixes: f283745b3caf ("arm: vf610: zii devel b: Add support for switch interrupts")
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Andreas F?rber <afaerber@suse.de>
Applied, thanks.
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Jisheng Zhang @ 2016-12-30 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGDbNAD7-TM6+x0A3FebTOPYmqQqbm1w29ZwH+9qePaAvhxTKw@mail.gmail.com>
Hi,
On Thu, 29 Dec 2016 17:38:14 +0100 Bas van Tiel wrote:
> Hi,
>
> when using a signal handler as a way to context switch between
> different usercontexts a reproducible exception occurs on my rpi3 in
> 64-bit mode. (https://gist.github.com/DanGe42/7148946)
>
> Running the context_demo program as a 32-bit ARM executable on a
> 64-bit kernel is OK, running as a 32 || 64 bit executable on an x86
> kernel is OK.
>
> In the first exception the PC doesn?t look correct, and the *pmd is 0.
> The 2nd exception happens after running the program again, the PC is 0x0.
>
> A successful function trace was not possible -> complete kernel hangup
> when enabling.
>
> Is there another way to gather more information about what is happening?
I can reproduce Segmentation fault with your program on Marvell berlin SoCs
my kernel version is 4.1, I didn't tested 4.9, 4.10-rc1 etc..
Then I increased the STACKSIZE from 4096 to 8192 in context_demo.c,
everything works fine now. Maybe arm64 need a bit larger signalstack?
Thanks,
Jisheng
>
> Linux (none) 4.10.0-rc1-v8+ #3 SMP PREEMPT Thu Dec 29 12:10:12 CET
> 2016 aarch64 GNU/Linux
>
> [ 46.350738] a.out[196]: unhandled level 2 translation fault (11) at
> 0x000000b8, esr 0x92000046
> [ 46.360516] pgd = ffffffc0392cb000
> [ 46.365377] [000000b8] *pgd=00000000392ec003
> [ 46.365381] , *pud=00000000392ec003
> [ 46.370878] , *pmd=0000000000000000
> [ 46.375907]
> [ 46.383974]
> [ 46.389107] CPU: 0 PID: 196 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
> [ 46.397949] Hardware name: Raspberry Pi 3 Model B (DT)
> [ 46.406218] task: ffffffc039ad6580 task.stack: ffffffc039bfc000
> [ 46.413892] PC is at 0x7fb4e34810
> [ 46.418230] LR is at 0x400b84
> [ 46.422956] pc : [<0000007fb4e34810>] lr : [<0000000000400b84>]
> pstate: 60000000
> [ 46.431522] sp : 0000000000413350
> [ 46.436480] x29: 0000000000413350 x28: 0000000000000016
> [ 46.443142] x27: 0000000000000000 x26: 0000000000000020
> [ 46.451908] x25: 0000007fb4f35488 x24: 0000000000415f00
> [ 46.459641] x23: 0000000000000016 x22: 0000000000400b84
> [ 46.469198] x21: 0000000000413670 x20: 0000000000417030
> [ 46.476970] x19: 0000000000001000 x18: 0000000000000000
> [ 46.484744] x17: 0000007fb4e34810 x16: 0000000000411270
> [ 46.492175] x15: 00000000000005f1 x14: 0000000000000000
> [ 46.498884] x13: 0000000000000000 x12: 0000000000000000
> [ 46.506013] x11: 0000000000000020 x10: 0101010101010101
> [ 46.517164] x9 : 0000000000413670 x8 : 00000000ffffffe0
> [ 46.525541] x7 : 0000000000413350 x6 : 0000000000413350
> [ 46.533495] x5 : 00000000ffffffe0 x4 : 0000000000413730
> [ 46.544052] x3 : 0000000000000008 x2 : 0000000000000000
> [ 46.552211] x1 : 0000000000413670 x0 : 0000000000000000
> [ 46.558668]
>
> 2nd time startup of the executable
>
> [ 262.565147] a.out[201]: unhandled level 2 translation fault (11) at
> 0x00000000, esr 0x82000006
> [ 262.575243] pgd = ffffffc03939a000
> [ 262.579948] [00000000] *pgd=000000003938f003
> [ 262.579951] , *pud=000000003938f003
> [ 262.586040] , *pmd=0000000000000000
> [ 262.590479]
> [ 262.598234]
> [ 262.601108] CPU: 0 PID: 201 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
> [ 262.609086] Hardware name: Raspberry Pi 3 Model B (DT)
> [ 262.615731] task: ffffffc03904a600 task.stack: ffffffc039bfc000
> [ 262.621768] PC is at 0x0
> [ 262.624300] LR is at 0x0
> [ 262.626835] pc : [<0000000000000000>] lr : [<0000000000000000>]
> pstate: 60000000
> [ 262.634437] sp : 00000000004159c0
> [ 262.637753] x29: 0000000000000000 x28: 0000000000000000
> [ 262.643242] x27: 0000000000000000 x26: 0000000000000000
> [ 262.648554] x25: 0000000000000000 x24: 0000000000000000
> [ 262.654033] x23: 0000000000000000 x22: 0000000000000000
> [ 262.659349] x21: 00000000004008f0 x20: 0000000000000000
> [ 262.664825] x19: 0000000000000000 x18: 0000000000000000
> [ 262.670145] x17: 0000007fb065b620 x16: 0000000000400b84
> [ 262.675622] x15: 00000000000003d1 x14: 0000000000000000
> [ 262.680938] x13: 0000000000000000 x12: 0000000000000000
> [ 262.686413] x11: 0000000000000020 x10: 0101010101010101
> [ 262.691835] x9 : 00000000004112c0 x8 : 0000000000000087
> [ 262.697159] x7 : 0000000000000000 x6 : 0000000000000000
> [ 262.702634] x5 : 0000000000000000 x4 : 0000000000000000
> [ 262.707949] x3 : 0000000000000000 x2 : 0000000000000000
> [ 262.713424] x1 : 0000000000000000 x0 : 0000000000000000
> [ 262.718739]
>
> rpi3:
> minimal kernel (64-bit, cortex-a53, little endian, 4Kb page,
> initramfs), different kernels tried 4.8/4.9/4.10.0-rc1-v8+ the same
> result occurs, also with different compilers.
>
> kernel, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
> application, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>
> The only item I found by reading through the different source-files was the
> structure definition of struct kernel_rt_sigframe
> (http://osxr.org:8080/glibc/source/ports/sysdeps/unix/sysv/linux/aarch64/kernel_rt_sigframe.h?v=glibc-2.18)
> compared to the struct rt_sigframe (linux/arch/arm64/signal.c).
>
> Any help or pointers to solve this issue are welcome,
>
> regards
> Bas
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/6] bus: add driver for the Technologic Systems NBUS
From: Linus Walleij @ 2016-12-30 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214231237.17496-5-sebastien.bourdelin@savoirfairelinux.com>
On Thu, Dec 15, 2016 at 12:12 AM, Sebastien Bourdelin
<sebastien.bourdelin@savoirfairelinux.com> wrote:
> This driver implements a GPIOs bit-banged bus, called the NBUS by
> Technologic Systems. It is used to communicate with the peripherals in
> the FPGA on the TS-4600 SoM.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
(...)
> +#include <linux/gpio.h>
Use:
#include <linux/gpio/consumer.h>
instead, and deal with the fallout.
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
Don't use this.
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +
> +static DEFINE_MUTEX(ts_nbus_lock);
> +static bool ts_nbus_ready;
Why not move this to the struct ts_nbus state container?
It seems to be per-bus not per-system.
> +#define TS_NBUS_READ_MODE 0
> +#define TS_NBUS_WRITE_MODE 1
> +#define TS_NBUS_DIRECTION_IN 0
> +#define TS_NBUS_DIRECTION_OUT 1
> +#define TS_NBUS_WRITE_ADR 0
> +#define TS_NBUS_WRITE_VAL 1
> +
> +struct ts_nbus {
> + struct pwm_device *pwm;
> + int num_data;
> + int *data;
> + int csn;
> + int txrx;
> + int strobe;
> + int ale;
> + int rdy;
> +};
> +
> +static struct ts_nbus *ts_nbus;
Nopes. No singletons please.
Use the state container pattern:
Documentation/driver-model/design-patterns.txt
> +/*
> + * request all gpios required by the bus.
> + */
> +static int ts_nbus_init(struct platform_device *pdev)
> +{
> + int err;
> + int i;
> +
> + for (i = 0; i < ts_nbus->num_data; i++) {
> + err = devm_gpio_request_one(&pdev->dev, ts_nbus->data[i],
> + GPIOF_OUT_INIT_HIGH,
> + "TS NBUS data");
> + if (err)
> + return err;
> + }
DO not use the legacy GPIO API anywhere.
Reference the device and use gpiod_get() simple, fair and square.
Store struct gpio_desc * pointers in your state container instead.
> +static int ts_nbus_get_of_pdata(struct device *dev, struct device_node *np)
> +{
> + int num_data;
> + int *data;
> + int ret;
> + int i;
> +
> + ret = of_gpio_named_count(np, "data-gpios");
> + if (ret < 0) {
> + dev_err(dev,
> + "failed to count GPIOs in DT property data-gpios\n");
> + return ret;
> + }
Do not reinvent the wheel.
Use devm_gpiod_get_array().
> + ret = of_get_named_gpio(np, "csn-gpios", 0);
And again use devm_gpiod_get(), and gpiod_* accessors.
Applies everywhere.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 5/6] ARM: dts: TS-4600: add NBUS support
From: Linus Walleij @ 2016-12-30 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214231237.17496-6-sebastien.bourdelin@savoirfairelinux.com>
On Thu, Dec 15, 2016 at 12:12 AM, Sebastien Bourdelin
<sebastien.bourdelin@savoirfairelinux.com> wrote:
> This commit enables the NBUS on the TS-4600, using the ts-nbus driver.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
> + nbus {
> + compatible = "technologic,ts-nbus", "simple-bus";
> + pinctrl-0 = <&nbus_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pwms = <&pwm 2 83>;
> + data-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH
> + &gpio0 1 GPIO_ACTIVE_HIGH
> + &gpio0 2 GPIO_ACTIVE_HIGH
> + &gpio0 3 GPIO_ACTIVE_HIGH
> + &gpio0 4 GPIO_ACTIVE_HIGH
> + &gpio0 5 GPIO_ACTIVE_HIGH
> + &gpio0 6 GPIO_ACTIVE_HIGH
> + &gpio0 7 GPIO_ACTIVE_HIGH>;
> + csn-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
> + txrx-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
> + strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
> + ale-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
> + rdy-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
devm_gpiod_get(&pdev->dev, "csn", GPIOD_OUT_HIGH); etc will get these
from the spawned
platform device.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: dts: am572x-idk: Add gpios property to control PCIE_RESETn
From: Kishon Vijay Abraham I @ 2016-12-30 8:07 UTC (permalink / raw)
To: linux-arm-kernel
Add 'gpios' property to pcie1 dt node and populate it with
GPIO3_23 in order to drive PCIE_RESETn high.
This gets PCIe cards to be detected in AM572X IDK board.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/boot/dts/am572x-idk.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am572x-idk.dts b/arch/arm/boot/dts/am572x-idk.dts
index 27d9149..1540f7a 100644
--- a/arch/arm/boot/dts/am572x-idk.dts
+++ b/arch/arm/boot/dts/am572x-idk.dts
@@ -87,3 +87,7 @@
&sn65hvs882 {
load-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
};
+
+&pcie1 {
+ gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH] pinctrl: stm32: activate strict mux mode
From: Linus Walleij @ 2016-12-30 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725456-1030-1-git-send-email-gabriel.fernandez@st.com>
On Wed, Dec 14, 2016 at 3:24 PM, <gabriel.fernandez@st.com> wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This activates strict mode muxing for the STM32 pin controllers,
> as these do not allow GPIO and functions to use the same pin
> simultaneously.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
Patch applied with Patrice's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] pinctrl: sirf: atlas7: Add missing 'of_node_put()'
From: Linus Walleij @ 2016-12-30 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220054043.25417-1-christophe.jaillet@wanadoo.fr>
On Tue, Dec 20, 2016 at 6:40 AM, Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> Reference to 'sys2pci_np' should be dropped in all cases here, not only in
> error handling path.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] pinctrl: sirf: atlas7: Improve code layout
From: Linus Walleij @ 2016-12-30 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220054122.25508-1-christophe.jaillet@wanadoo.fr>
On Tue, Dec 20, 2016 at 6:41 AM, Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> Add some tab in order to improve indentation.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Linus Walleij @ 2016-12-30 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221032717.13154-5-vz@mleia.com>
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy <vz@mleia.com> wrote:
> The change adds handling of "enable-gpios" property of panel-dpi device
> node used with an ARM CLCD controller, note that the property already has
> a description in display/panel/panel-dpi.txt documentation and it founds
> practical usage while describing some panel devices connected to other
> types of display controllers.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
So as you may have seen I already handle a RESET GPIO in the
Nomadik TPG110 panel subddriver in
drivers/video/fbdev/amba-clcd-nomadik.c
So is this all your panel needs?
I guess it is OK for simple panels.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Linus Walleij @ 2016-12-30 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221032717.13154-1-vz@mleia.com>
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy <vz@mleia.com> wrote:
> The changeset contains a number of cleanups, changed semantics of
> init_panel() callback, which allows to simplify getting of panel
> properties from panel device tree node, and a handling of optional
> "enable-gpios" panel property, the latter is described in
> display/panel/panel-dpi.txt device tree binding documentation, but
> it has been unsupported by the ARM CLCD driver.
>
> Vladimir Zapolskiy (4):
> video: ARM CLCD: sort included headers out alphabetically
> video: ARM CLCD: use panel device node for panel initialization
> video: ARM CLCD: use panel device node for getting backlight and mode
> video: ARM CLCD: add support of an optional GPIO to enable panel
As you may have seen Tomi has stepped down as FBDEV maintainer and
this subsystem is now orphaned.
I guess Andrew Morton merges patches for it in this case, he usually does.
But what we should actually do is create a new DRM driver for CLCD
in drivers/gpu/drm/arm/clcd*
It's maybe not a small undertaking :(
But in case you're interested in the job, I will pitch in and test the result
on all ARM reference designs plus Nomadik.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/6] pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers
From: Linus Walleij @ 2016-12-30 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222172501.16121-2-gregory.clement@free-electrons.com>
On Thu, Dec 22, 2016 at 6:24 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Document the device tree binding for the pin controllers found on the
> Armada 37xx SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
(...)
> +Required properties for pinctrl driver:
> +- compatible: "marvell,armada3710-sb-pinctrl" for the south bridge
> + "marvell,armada3710-nb-pinctrl" for the north bridge
> +- reg: The first set of register are for pinctrl/gpio and the second
> + set for the interrupt controller
> +- interrupts: list of the interrupt use by the gpio
While this makes sense on its own, it doesn't match the code you sent.
The code uses syscon and regmap inside a simple-mfd node, not reg.
Please clarify how this works so we can see what is going on.
The syscon part doesn't seem optional at all.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/6] pinctrl: armada-37xx: Add pin controller support for Armada 37xx
From: Linus Walleij @ 2016-12-30 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222172501.16121-3-gregory.clement@free-electrons.com>
On Thu, Dec 22, 2016 at 6:24 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoC come with 2 pin controllers: one on the south
> bridge (managing 28 pins) and one on the north bridge (managing 36 pins).
>
> At the hardware level the controller configure the pins by group and not
> pin by pin. This constraint is reflected in the design of the driver:
> only the group related functions are implemented.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Overall this looks good.
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 715ef1256838..0786e3e0f5c6 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -105,6 +105,8 @@ config ARCH_MVEBU
> select ARMADA_37XX_CLK
> select MVEBU_ODMI
> select MVEBU_PIC
> + select PINCTRL
> + select PINCTRL_ARMADA_37XX
Do you already select MFD_SYSCON? It seems to be required.
I can't merge patches to ARM SoC and prefer not to. Split this into a separate
patch for ARM SoC in the Armada/Marvell tree.
> -obj-$(CONFIG_PINCTRL_MVEBU) += mvebu/
> +obj-y += mvebu/
Just make sure everything is guarded with proper symbols.
> +config PINCTRL_ARMADA_37XX
> + bool
> + select PINMUX
> + select PINCONF
> + select GENERIC_PINCONF
Nice!
> +struct armada_37xx_pin_group {
> + const char *name;
> + unsigned int start_pin;
> + unsigned int npins;
> + u32 reg_mask;
> + unsigned int extra_pin;
> + unsigned int extra_npins;
> + const char *funcs[NB_FUNCS];
> + unsigned int *pins;
> +};
I would prefer if you add some kerneldoc to this struct.
Especially the extra_pin things are not evident so explain this
in detail here.
> +struct armada_37xx_pin_data {
> + u8 nr_pins;
> + char *name;
> + struct armada_37xx_pin_group *groups;
> + int ngroups;
> +};
> +
> +struct armada_37xx_pmx_func {
> + const char *name;
> + const char **groups;
> + unsigned int ngroups;
> +};
> +
> +struct armada_37xx_pinctrl {
> + struct regmap *regmap;
> + struct armada_37xx_pin_data *data;
> + struct device *dev;
> + struct pinctrl_desc pctl;
> + struct pinctrl_dev *pctl_dev;
> + struct armada_37xx_pin_group *groups;
> + unsigned int ngroups;
> + struct armada_37xx_pmx_func *funcs;
> + unsigned int nfuncs;
> +};
You do not need to document these. They are self-explanatory.
> +static int armada_37xx_pin_config_group_get(struct pinctrl_dev *pctldev,
> + unsigned int selector, unsigned long *config)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static int armada_37xx_pin_config_group_set(struct pinctrl_dev *pctldev,
> + unsigned int selector, unsigned long *configs,
> + unsigned int num_configs)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static struct pinconf_ops armada_37xx_pinconf_ops = {
> + .is_generic = true,
> + .pin_config_group_get = armada_37xx_pin_config_group_get,
> + .pin_config_group_set = armada_37xx_pin_config_group_set,
> +};
Don't we support just leaving group set/get uninitialized? Too bad in that case.
> +static int _add_function(struct armada_37xx_pmx_func *funcs, int *funcsize,
> + const char *name)
No _foo opaque underscore prefix please. Git this a reasonable name
like armada_37xx_add_function() or so.
Apart from that it looks good.
Yours,
Linus Walleij
^ permalink raw reply
* [BUG] ARM64: amlogic: gxbb: unhandled level 2 translation fault (11)
From: Neil Armstrong @ 2016-12-30 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <130a3716-a643-d14f-fd7c-9ad3bb67f3a7@gmx.de>
On 12/29/2016 10:18 PM, Heinrich Schuchardt wrote:
> On 12/29/2016 10:07 AM, Neil Armstrong wrote:
>> On 12/24/2016 03:00 PM, Heinrich Schuchardt wrote:
>>> When trying to run sddm on an Hardkernel Odroid C2 I invariably run into the
>>> translation fault below.
>>>
>>> The following mail thread relates this kind of problem to TLB (translation
>>> lookaside buffer) broadcasting.
>>>
>>> https://lkml.org/lkml/2014/4/15/207
>>>
>>> [ 3163.014263] sddm[1851]: unhandled level 2 translation fault (11) at 0x00000160, esr 0x82000006
>>> [ 3163.017287] pgd = ffff80007bf86000
>>> [ 3163.020589] [00000160] *pgd=000000007a8a3003
>>> [ 3163.024733] , *pud=000000007be9c003
>>> [ 3163.028095] , *pmd=0000000000000000
>>>
>>>
>>> [ 3163.033026] CPU: 1 PID: 1851 Comm: sddm Not tainted 4.9.0-next-20161212-r022-arm64 #1
>>> [ 3163.040831] Hardware name: Hardkernel ODROID-C2 (DT)
>>> [ 3163.045698] task: ffff80007bc6d780 task.stack: ffff80007c524000
>>> [ 3163.051563] PC is at 0x160
>>> [ 3163.054231] LR is at 0xffff9a9fbc98
>>> [ 3163.057686] pc : [<0000000000000160>] lr : [<0000ffff9a9fbc98>] pstate: 40000000
>>> [ 3163.065022] sp : 0000ffffd7180130
>>> [ 3163.068281] x29: 0000ffffd7180130 x28: 0000ffffd7180288
>>> [ 3163.073538] x27: 0000ffff9aa94000 x26: 0000000000000001
>>> [ 3163.078798] x25: 0000000000000000 x24: 0000ffffd7180410
>>> [ 3163.084060] x23: 000000000e0c2190 x22: 000000000e0ca5c0
>>> [ 3163.089322] x21: 0000ffff9ac35000 x20: 0000000000454fa9
>>> [ 3163.094583] x19: 0000000000454fa8 x18: 000000000e0b5938
>>> [ 3163.099843] x17: 0000ffff9a3f2988 x16: 0000ffff9ac36aa0
>>> [ 3163.105105] x15: 0000000000000000 x14: 0000000000000000
>>> [ 3163.110367] x13: 6d00640064007300 x12: 0800000005000000
>>> [ 3163.115627] x11: 0000040000000000 x10: 0000a00000000000
>>> [ 3163.120889] x9 : 00003fffffffffff x8 : 0000000000000000
>>> [ 3163.126150] x7 : 000000000e0cb520 x6 : 0000000000454fc0
>>> [ 3163.131412] x5 : 0000ffffd717ffd8 x4 : 000000000e0cb510
>>> [ 3163.136680] x3 : 0000000000000004 x2 : f2f9022b551b3900
>>> [ 3163.141935] x1 : 0000000000000160 x0 : 000000000e0ca5c0
>>>
>>> Best regards
>>>
>>> Heinrich Schuchardt
>>
>> Hi Heinrich,
>>
>> I personally never had this issue even while loading huge applications loke LibreOffice and Gnome environment.
>>
>> I will have a look and try to reproduce this issue, can you provide us your configuration and user-space complete use case ?
>>
>> Neil
>>
>
> Hello Neil,
>
> the kernel is build with
> https://github.com/xypron/kernel-odroid-c2/tree/f8d565ff755e92fd585f5ae10123ce20abe03968
>
> Especially look at the patch directory and config/config-next-20161212.
>
> The userland is Debian Stretch with this package:
> https://packages.debian.org/stretch/sddm
>
> The link
> https://www.spinics.net/lists/arm-kernel/msg550204.html
> that you mention in a separate mail just links to this very thread due
> to linux-arm-kernel at lists.infradead.org being in copy.
>
> Best regards
>
> Heinrich Schuchardt
>
Hi,
Thanks for the details, but why do you use the next-20161212 tag ? does it work with 4.10-rc1 or previous next tags ?
Neil
^ permalink raw reply
* [PATCH 3/6] pinctrl: armada-37xx: Add gpio support
From: Linus Walleij @ 2016-12-30 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222172501.16121-4-gregory.clement@free-electrons.com>
On Thu, Dec 22, 2016 at 6:24 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> GPIO management is pretty simple and is part of the same IP than the pin
> controller for the Armada 37xx SoCs. This patch adds the GPIO support to
> the pinctrl-armada-37xx.c file, it also allows sharing common functions
> between the gpiolib and the pinctrl drivers.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Some remarks:
> +static int armada_37xx_gpio_get_direction(struct gpio_chip *chip,
> + unsigned int offset)
> +{
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
> + unsigned int reg = OUTPUT_EN;
> + unsigned int val, mask;
> +
> + if (offset >= GPIO_PER_REG) {
> + offset -= GPIO_PER_REG;
> + reg += sizeof(u32);
> + }
Add a comment saying we never have more than two registers?
If there would be three registers this would fail, right?
> + mask = BIT(offset);
> +
> + regmap_read(info->regmap, reg, &val);
>
> + return (val & mask) == 0;
Use this:
return !(val & mask);
> +static int armada_37xx_gpio_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
> + unsigned int reg = INPUT_VAL;
> + unsigned int val, mask;
> +
> + if (offset >= GPIO_PER_REG) {
> + offset -= GPIO_PER_REG;
> + reg += sizeof(u32);
> + }
> + mask = BIT(offset);
This code is repeating. Break out a static (inline?) helper to do this.
> +static int armada_37xx_gpiolib_register(struct platform_device *pdev,
> + struct armada_37xx_pinctrl *info)
Nit: gpiochip_register or so is more to the point.
> + ret = gpiochip_add_pin_range(&info->gpio_chip, dev_name(dev), 0,
> + pinbase, info->data->nr_pins);
> + if (ret)
> + return ret;
Why do you do this?
Why not just put the ranges into the device tree? We already support
this in the gpiolib core and it is helpful.
See Documentation/devicetree/bindings/gpio/gpio.txt
and other DTS files for gpio-ranges.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 01/14] ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()
From: Xinwei Kong @ 2016-12-30 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-2-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Cleanup iort_match_node_callback() a little bit to reduce
> some lines of code, aslo fix the indentation in iort_scan_node().
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/acpi/arm64/iort.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index e0d2e6e..46e2d82 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -225,7 +225,7 @@ static struct acpi_iort_node *iort_scan_node(enum acpi_iort_node_type type,
>
> if (iort_node->type == type &&
> ACPI_SUCCESS(callback(iort_node, context)))
> - return iort_node;
> + return iort_node;
>
> iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> iort_node->length);
> @@ -253,17 +253,15 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
> void *context)
> {
> struct device *dev = context;
> - acpi_status status;
> + acpi_status status = AE_NOT_FOUND;
>
> if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {
> struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
> struct acpi_device *adev = to_acpi_device_node(dev->fwnode);
> struct acpi_iort_named_component *ncomp;
>
> - if (!adev) {
> - status = AE_NOT_FOUND;
> + if (!adev)
> goto out;
> - }
>
> status = acpi_get_name(adev->handle, ACPI_FULL_PATHNAME, &buf);
> if (ACPI_FAILURE(status)) {
> @@ -289,8 +287,6 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
> */
> status = pci_rc->pci_segment_number == pci_domain_nr(bus) ?
> AE_OK : AE_NOT_FOUND;
> - } else {
> - status = AE_NOT_FOUND;
> }
> out:
> return status;
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 02/14] irqchip: gic-v3-its: keep the head file include in alphabetic order
From: Xinwei Kong @ 2016-12-30 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-3-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> The head file is strictly in alphabetic order now, so let's
> be the rule breaker. As acpi_iort.h includes acpi.h so remove
> the duplidate acpi.h inclusion as well.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 69b040f..f471939 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -15,14 +15,13 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> -#include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/bitmap.h>
> #include <linux/cpu.h>
> #include <linux/delay.h>
> #include <linux/dma-iommu.h>
> #include <linux/interrupt.h>
> #include <linux/irqdomain.h>
> -#include <linux/acpi_iort.h>
> #include <linux/log2.h>
> #include <linux/mm.h>
> #include <linux/msi.h>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 03/14] ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()
From: Xinwei Kong @ 2016-12-30 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-4-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> We are missing req_id's comment for iort_dev_find_its_id(),
> add it back.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/acpi/arm64/iort.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 46e2d82..174e983 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -446,6 +446,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> /**
> * iort_dev_find_its_id() - Find the ITS identifier for a device
> * @dev: The device.
> + * @req_id: Device's Requster ID
> * @idx: Index of the ITS identifier list.
> * @its_id: ITS identifier.
> *
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 04/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-5-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Adding ACPI support for platform MSI, we need to retrieve the
> dev id in ACPI way instead of device tree, we already have
> a well formed function its_pmsi_prepare() to get the dev id
> but it's OF dependent, so collect OF related code and put them
> into a single function to make its_pmsi_prepare() more friendly
> to ACPI later.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 23 ++++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index 470b4aa..3c94278 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -24,15 +24,11 @@
> .name = "ITS-pMSI",
> };
>
> -static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> - int nvec, msi_alloc_info_t *info)
> +static int of_pmsi_get_dev_id(struct irq_domain *domain, struct device *dev,
> + u32 *dev_id)
> {
> - struct msi_domain_info *msi_info;
> - u32 dev_id;
> int ret, index = 0;
>
> - msi_info = msi_get_domain_info(domain->parent);
> -
> /* Suck the DeviceID out of the msi-parent property */
> do {
> struct of_phandle_args args;
> @@ -43,11 +39,24 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> if (args.np == irq_domain_get_of_node(domain)) {
> if (WARN_ON(args.args_count != 1))
> return -EINVAL;
> - dev_id = args.args[0];
> + *dev_id = args.args[0];
> break;
> }
> } while (!ret);
>
> + return ret;
> +}
> +
> +static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> + int nvec, msi_alloc_info_t *info)
> +{
> + struct msi_domain_info *msi_info;
> + u32 dev_id;
> + int ret;
> +
> + msi_info = msi_get_domain_info(domain->parent);
> +
> + ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> if (ret)
> return ret;
>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-6-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> For devices connecting to ITS, it needs dev id to identify
> itself, and this dev id is represented in the IORT table in
> named componant node [1] for platform devices, so in this
> patch we will scan the IORT to retrieve device's dev id.
>
> Introduce iort_pmsi_get_dev_id() with pointer dev passed
> in for that purpose.
>
> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/acpi/arm64/iort.c | 26 ++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 4 +++-
> include/linux/acpi_iort.h | 8 ++++++++
> 3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 174e983..ab7bae7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> }
>
> /**
> + * iort_pmsi_get_dev_id() - Get the device id for a device
> + * @dev: The device for which the mapping is to be done.
> + * @dev_id: The device ID found.
> + *
> + * Returns: 0 for successful find a dev id, errors otherwise
> + */
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + struct acpi_iort_node *node;
> +
> + if (!iort_table)
> + return -ENODEV;
> +
> + node = iort_find_dev_node(dev);
> + if (!node) {
> + dev_err(dev, "can't find related IORT node\n");
> + return -ENODEV;
> + }
> +
> + if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> +/**
> * iort_dev_find_its_id() - Find the ITS identifier for a device
> * @dev: The device.
> * @req_id: Device's Requster ID
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index 3c94278..16587a9 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -15,6 +15,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/acpi_iort.h>
> #include <linux/device.h>
> #include <linux/msi.h>
> #include <linux/of.h>
> @@ -56,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
>
> msi_info = msi_get_domain_info(domain->parent);
>
> - ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> + ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
> + iort_pmsi_get_dev_id(dev, &dev_id);
> if (ret)
> return ret;
>
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 77e0809..ef99fd52 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -33,6 +33,7 @@
> void acpi_iort_init(void);
> bool iort_node_match(u8 type);
> u32 iort_msi_map_rid(struct device *dev, u32 req_id);
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
> struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
> /* IOMMU interface */
> void iort_set_dma_mask(struct device *dev);
> @@ -42,9 +43,16 @@ static inline void acpi_iort_init(void) { }
> static inline bool iort_node_match(u8 type) { return false; }
> static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> { return req_id; }
> +
> static inline struct irq_domain *iort_get_device_domain(struct device *dev,
> u32 req_id)
> { return NULL; }
> +
> +static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + return -ENODEV;
> +}
> +
> /* IOMMU interface */
> static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 06/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-7-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Introduce its_pmsi_init_one() to refactor the code to isolate
> ACPI&DT common code to prepare for ACPI later.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 45 ++++++++++++++++-----------
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index 16587a9..ff72704 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -84,34 +84,43 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> {},
> };
>
> -static int __init its_pmsi_init(void)
> +static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
> + const char *name)
> {
> - struct device_node *np;
> struct irq_domain *parent;
>
> + parent = irq_find_matching_fwnode(fwnode, DOMAIN_BUS_NEXUS);
> + if (!parent || !msi_get_domain_info(parent)) {
> + pr_err("%s: unable to locate ITS domain\n", name);
> + return -ENXIO;
> + }
> +
> + if (!platform_msi_create_irq_domain(fwnode, &its_pmsi_domain_info,
> + parent)) {
> + pr_err("%s: unable to create platform domain\n", name);
> + return -ENXIO;
> + }
> +
> + pr_info("Platform MSI: %s domain created\n", name);
> + return 0;
> +}
> +
> +static void __init its_pmsi_of_init(void)
> +{
> + struct device_node *np;
> +
> for (np = of_find_matching_node(NULL, its_device_id); np;
> np = of_find_matching_node(np, its_device_id)) {
> if (!of_property_read_bool(np, "msi-controller"))
> continue;
>
> - parent = irq_find_matching_host(np, DOMAIN_BUS_NEXUS);
> - if (!parent || !msi_get_domain_info(parent)) {
> - pr_err("%s: unable to locate ITS domain\n",
> - np->full_name);
> - continue;
> - }
> -
> - if (!platform_msi_create_irq_domain(of_node_to_fwnode(np),
> - &its_pmsi_domain_info,
> - parent)) {
> - pr_err("%s: unable to create platform domain\n",
> - np->full_name);
> - continue;
> - }
> -
> - pr_info("Platform MSI: %s domain created\n", np->full_name);
> + its_pmsi_init_one(of_node_to_fwnode(np), np->full_name);
> }
> +}
>
> +static int __init its_pmsi_init(void)
> +{
> + its_pmsi_of_init();
> return 0;
> }
> early_initcall(its_pmsi_init);
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 07/14] irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-8-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the introduction of its_pmsi_init_one(), we can add some code
> on top for ACPI support of platform MSI.
>
> We are scanning the MADT table to get the ITS entry(ies), then use
> the information to create the platform msi domain for devices connect
> to it, just like the PCI MSI for ITS did.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 36 +++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index ff72704..0be0437 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -105,6 +105,41 @@ static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
> return 0;
> }
>
> +#ifdef CONFIG_ACPI
> +static int __init
> +its_pmsi_parse_madt(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_translator *its_entry;
> + struct fwnode_handle *domain_handle;
> + const char *node_name;
> + int err = -ENXIO;
> +
> + its_entry = (struct acpi_madt_generic_translator *)header;
> + node_name = kasprintf(GFP_KERNEL, "ITS at 0x%lx",
> + (long)its_entry->base_address);
> + domain_handle = iort_find_domain_token(its_entry->translation_id);
> + if (!domain_handle) {
> + pr_err("%s: Unable to locate ITS domain handle\n", node_name);
> + goto out;
> + }
> +
> + err = its_pmsi_init_one(domain_handle, node_name);
> +
> +out:
> + kfree(node_name);
> + return err;
> +}
> +
> +static void __init its_acpi_pmsi_init(void)
> +{
> + acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> + its_pmsi_parse_madt, 0);
> +}
> +#else
> +static inline void its_acpi_pmsi_init(void) { }
> +#endif
> +
> static void __init its_pmsi_of_init(void)
> {
> struct device_node *np;
> @@ -121,6 +156,7 @@ static void __init its_pmsi_of_init(void)
> static int __init its_pmsi_init(void)
> {
> its_pmsi_of_init();
> + its_acpi_pmsi_init();
> return 0;
> }
> early_initcall(its_pmsi_init);
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH 4/6] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222172501.16121-5-gregory.clement@free-electrons.com>
On Thu, Dec 22, 2016 at 6:24 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoCs can handle interrupt through GPIO. However it can
> only manage the edge ones.
>
> The way the interrupt are managed are classical so we can use the generic
> interrupt chip model.
>
> The only unusual "feature" is that many interrupts are connected to the
> parent interrupt controller. But we do not take advantage of this and use
> the chained irq with all of them.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
So this is very simple and should use GPIOLIB_IRQCHIP.
Begin with select GPIOLIB_IRQCHIP in your Kconfig and then look
at conversions such as commit 85ae9e512f437cd09bf61564bdba29ab88bab3e3
("pinctrl: bcm2835: switch to GPIOLIB_IRQCHIP")
for inspiration.
> @@ -64,6 +71,8 @@ struct armada_37xx_pinctrl {
> struct armada_37xx_pin_data *data;
> struct device *dev;
> struct gpio_chip gpio_chip;
> + struct irq_chip irq_chip;
> + struct irq_domain *domain;
You don't need a domain when using GPIOLIB_IRQCHIP
> +static int armada_37xx_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
> +
> + return irq_create_mapping(info->domain, offset);
> +}
Nor this.
The irqchip code should be pretty much the same but you need to
dereference gpio_chip from chip data and pick the irqchip from
there.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-10-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the platform msi domain created, we can set up the msi domain
> for a platform device when it's probed.
>
> In order to do that, we need to get the domain that the platform
> device connecting to, so the iort_get_platform_device_domain() is
> introduced to retrieve the domain from iort.
>
> After the domain is retrieved, we need a proper way to set the
> domain to paltform device, as some platform devices such as an
> irqchip needs the msi irqdomain to be the interrupt parent domain,
> we need to get irqdomain before platform device is probed but after
> the platform device is allocated, so introduce a callback (pre_add_cb)
> in pdevinfo to prepare firmware related information which is needed
> for device probe, then set the msi domain in that callback.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/acpi/acpi_platform.c | 11 +++++++++++
> drivers/acpi/arm64/iort.c | 43 +++++++++++++++++++++++++++++++++++++++++
> drivers/base/platform.c | 3 +++
> include/linux/acpi_iort.h | 3 +++
> include/linux/platform_device.h | 3 +++
> 5 files changed, 63 insertions(+)
>
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index b4c1a6a..5d8d61b4 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -12,6 +12,7 @@
> */
>
> #include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/device.h>
> #include <linux/err.h>
> #include <linux/kernel.h>
> @@ -48,6 +49,15 @@ static void acpi_platform_fill_resource(struct acpi_device *adev,
> }
>
> /**
> + * acpi_platform_pre_add_cb - callback before platform device is added, to
> + * prepare firmware related information which is needed for device probe
> + */
> +static void acpi_platform_pre_add_cb(struct device *dev)
> +{
> + acpi_configure_pmsi_domain(dev);
> +}
> +
> +/**
> * acpi_create_platform_device - Create platform device for ACPI device node
> * @adev: ACPI device node to create a platform device for.
> * @properties: Optional collection of build-in properties.
> @@ -109,6 +119,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
> pdevinfo.num_res = count;
> pdevinfo.fwnode = acpi_fwnode_handle(adev);
> pdevinfo.properties = properties;
> + pdevinfo.pre_add_cb = acpi_platform_pre_add_cb;
>
> if (acpi_dma_supported(adev))
> pdevinfo.dma_mask = DMA_BIT_MASK(32);
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index bc68d93..6b72fcb 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -527,6 +527,49 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
> return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
> }
>
> +/**
> + * iort_get_platform_device_domain() - Find MSI domain related to a
> + * platform device
> + * @dev: the dev pointer associated with the platform device
> + *
> + * Returns: the MSI domain for this device, NULL otherwise
> + */
> +static struct irq_domain *iort_get_platform_device_domain(struct device *dev)
> +{
> + struct acpi_iort_node *node, *msi_parent;
> + struct fwnode_handle *iort_fwnode;
> + struct acpi_iort_its_group *its;
> +
> + /* find its associated iort node */
> + node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> + iort_match_node_callback, dev);
> + if (!node)
> + return NULL;
> +
> + /* then find its msi parent node */
> + msi_parent = iort_node_get_id(node, NULL, IORT_MSI_TYPE, 0);
> + if (!msi_parent)
> + return NULL;
> +
> + /* Move to ITS specific data */
> + its = (struct acpi_iort_its_group *)msi_parent->node_data;
> +
> + iort_fwnode = iort_find_domain_token(its->identifiers[0]);
> + if (!iort_fwnode)
> + return NULL;
> +
> + return irq_find_matching_fwnode(iort_fwnode, DOMAIN_BUS_PLATFORM_MSI);
> +}
> +
> +void acpi_configure_pmsi_domain(struct device *dev)
> +{
> + struct irq_domain *msi_domain;
> +
> + msi_domain = iort_get_platform_device_domain(dev);
> + if (msi_domain)
> + dev_set_msi_domain(dev, msi_domain);
> +}
> +
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> {
> u32 *rid = data;
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index c4af003..3e68f31 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -537,6 +537,9 @@ struct platform_device *platform_device_register_full(
> goto err;
> }
>
> + if (pdevinfo->pre_add_cb)
> + pdevinfo->pre_add_cb(&pdev->dev);
> +
> ret = platform_device_add(pdev);
> if (ret) {
> err:
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index ef99fd52..33f5ac3 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -38,6 +38,7 @@
> /* IOMMU interface */
> void iort_set_dma_mask(struct device *dev);
> const struct iommu_ops *iort_iommu_configure(struct device *dev);
> +void acpi_configure_pmsi_domain(struct device *dev);
> #else
> static inline void acpi_iort_init(void) { }
> static inline bool iort_node_match(u8 type) { return false; }
> @@ -58,6 +59,8 @@ static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
> const struct iommu_ops *iort_iommu_configure(struct device *dev)
> { return NULL; }
> +
> +static inline void acpi_configure_pmsi_domain(struct device *dev) { }
> #endif
>
> #define IORT_ACPI_DECLARE(name, table_id, fn) \
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 98c2a7c..280d366fb 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -74,6 +74,9 @@ struct platform_device_info {
> u64 dma_mask;
>
> struct property_entry *properties;
> +
> + /* preparation callback before the platform device is added */
> + void (*pre_add_cb)(struct device *);
> };
> extern struct platform_device *platform_device_register_full(
> const struct platform_device_info *pdevinfo);
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 10/14] ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-11-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> iort_node_get_id() for now only support NC(named componant)->SMMU
> or NC->ITS cases, we also have other device topology such NC->
> SMMU->ITS, so rework iort_node_get_id() for those cases.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> drivers/acpi/arm64/iort.c | 59 ++++++++++++++++++++++++++---------------------
> 1 file changed, 33 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 6b72fcb..9b3f268 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -292,22 +292,28 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
> return status;
> }
>
> -static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> - u32 *rid_out)
> +static int iort_id_single_map(struct acpi_iort_id_mapping *map, u8 type,
> + u32 *rid_out)
> {
> /* Single mapping does not care for input id */
> if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - *rid_out = map->output_base;
> + if (rid_out)
> + *rid_out = map->output_base;
> return 0;
> }
>
> pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",
> map, type);
> - return -ENXIO;
> }
>
> + return -ENXIO;
> +}
> +
> +static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> + u32 *rid_out)
> +{
> if (rid_in < map->input_base ||
> (rid_in >= map->input_base + map->id_count))
> return -ENXIO;
> @@ -324,33 +330,34 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
> struct acpi_iort_node *parent;
> struct acpi_iort_id_mapping *map;
>
> - if (!node->mapping_offset || !node->mapping_count ||
> - index >= node->mapping_count)
> - return NULL;
> -
> - map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> - node->mapping_offset);
> + while (node) {
> + if (!node->mapping_offset || !node->mapping_count ||
> + index >= node->mapping_count)
> + return NULL;
>
> - /* Firmware bug! */
> - if (!map->output_reference) {
> - pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
> - node, node->type);
> - return NULL;
> - }
> + map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> + node->mapping_offset);
>
> - parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> - map->output_reference);
> + /* Firmware bug! */
> + if (!map->output_reference) {
> + pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
> + node, node->type);
> + return NULL;
> + }
>
> - if (!(IORT_TYPE_MASK(parent->type) & type_mask))
> - return NULL;
> + parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> + map->output_reference);
>
> - if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> - if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> - node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - if (id_out)
> - *id_out = map[index].output_base;
> - return parent;
> + /* go upstream to find its parent */
> + if (!(IORT_TYPE_MASK(parent->type) & type_mask)) {
> + node = parent;
> + continue;
> }
> +
> + if (iort_id_single_map(&map[index], node->type, id_out))
> + break;
> +
> + return parent;
> }
>
> return NULL;
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 11/14] msi: platform: make platform_msi_create_device_domain() ACPI aware
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-12-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the platform msi domain created for ITS, irqchip such as
> mbi-gen connecting ITS, which needs ctreate its own irqdomain.
>
> Fortunately with the platform msi support upstreamed by Marc,
> we just need to add minor code to make it run properly.
>
> platform_msi_create_device_domain() is 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.
>
> 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;
>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ 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