* [PATCH v2 4/4] ARM64: dts: TM2: comply to the samsung pinctrl naming convention
From: Chanwoo Choi @ 2016-12-30 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230041421.24448-5-andi.shyti@samsung.com>
Hi Andi,
Looks good to me. I tested these patches for booting on TM2 board.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Regards,
Chanwoo Choi
On 2016? 12? 30? 13:14, Andi Shyti wrote:
> Change the PIN() macro definition so that it can use the macros
> from pinctrl/samsung.h header file.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 25 +-
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 254 ++++++++++-----------
> 2 files changed, 133 insertions(+), 146 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> index 2af854b11644..d49879bd34bb 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> @@ -14,25 +14,12 @@
>
> #include <dt-bindings/pinctrl/samsung.h>
>
> -#define PIN_PULL_NONE 0
> -#define PIN_PULL_DOWN 1
> -#define PIN_PULL_UP 3
> -
> -#define PIN_DRV_LV1 0
> -#define PIN_DRV_LV2 2
> -#define PIN_DRV_LV3 1
> -#define PIN_DRV_LV4 3
> -
> -#define PIN_IN 0
> -#define PIN_OUT 1
> -#define PIN_FUNC1 2
> -
> -#define PIN(_func, _pin, _pull, _drv) \
> - _pin { \
> - samsung,pins = #_pin; \
> - samsung,pin-function = <PIN_ ##_func>; \
> - samsung,pin-pud = <PIN_PULL_ ##_pull>; \
> - samsung,pin-drv = <PIN_DRV_ ##_drv>; \
> +#define PIN(_func, _pin, _pull, _drv) \
> + _pin { \
> + samsung,pins = #_pin; \
> + samsung,pin-function = <EXYNOS_PIN_FUNC_ ##_func>; \
> + samsung,pin-pud = <EXYNOS_PIN_PULL_ ##_pull>; \
> + samsung,pin-drv = <EXYNOS5433_PIN_DRV_ ##_drv>; \
> }
>
> &pinctrl_alive {
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index f21bdc2ff834..66c4d5959881 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -742,77 +742,77 @@
> pinctrl-0 = <&initial_alive>;
>
> initial_alive: initial-state {
> - PIN(IN, gpa0-0, DOWN, LV1);
> - PIN(IN, gpa0-1, NONE, LV1);
> - PIN(IN, gpa0-2, DOWN, LV1);
> - PIN(IN, gpa0-3, NONE, LV1);
> - PIN(IN, gpa0-4, NONE, LV1);
> - PIN(IN, gpa0-5, DOWN, LV1);
> - PIN(IN, gpa0-6, NONE, LV1);
> - PIN(IN, gpa0-7, NONE, LV1);
> -
> - PIN(IN, gpa1-0, UP, LV1);
> - PIN(IN, gpa1-1, NONE, LV1);
> - PIN(IN, gpa1-2, NONE, LV1);
> - PIN(IN, gpa1-3, DOWN, LV1);
> - PIN(IN, gpa1-4, DOWN, LV1);
> - PIN(IN, gpa1-5, NONE, LV1);
> - PIN(IN, gpa1-6, NONE, LV1);
> - PIN(IN, gpa1-7, NONE, LV1);
> -
> - PIN(IN, gpa2-0, NONE, LV1);
> - PIN(IN, gpa2-1, NONE, LV1);
> - PIN(IN, gpa2-2, NONE, LV1);
> - PIN(IN, gpa2-3, DOWN, LV1);
> - PIN(IN, gpa2-4, NONE, LV1);
> - PIN(IN, gpa2-5, DOWN, LV1);
> - PIN(IN, gpa2-6, DOWN, LV1);
> - PIN(IN, gpa2-7, NONE, LV1);
> -
> - PIN(IN, gpa3-0, DOWN, LV1);
> - PIN(IN, gpa3-1, DOWN, LV1);
> - PIN(IN, gpa3-2, NONE, LV1);
> - PIN(IN, gpa3-3, DOWN, LV1);
> - PIN(IN, gpa3-4, NONE, LV1);
> - PIN(IN, gpa3-5, DOWN, LV1);
> - PIN(IN, gpa3-6, DOWN, LV1);
> - PIN(IN, gpa3-7, DOWN, LV1);
> -
> - PIN(IN, gpf1-0, NONE, LV1);
> - PIN(IN, gpf1-1, NONE, LV1);
> - PIN(IN, gpf1-2, DOWN, LV1);
> - PIN(IN, gpf1-4, UP, LV1);
> - PIN(OUT, gpf1-5, NONE, LV1);
> - PIN(IN, gpf1-6, DOWN, LV1);
> - PIN(IN, gpf1-7, DOWN, LV1);
> -
> - PIN(IN, gpf2-0, DOWN, LV1);
> - PIN(IN, gpf2-1, DOWN, LV1);
> - PIN(IN, gpf2-2, DOWN, LV1);
> - PIN(IN, gpf2-3, DOWN, LV1);
> -
> - PIN(IN, gpf3-0, DOWN, LV1);
> - PIN(IN, gpf3-1, DOWN, LV1);
> - PIN(IN, gpf3-2, NONE, LV1);
> - PIN(IN, gpf3-3, DOWN, LV1);
> -
> - PIN(IN, gpf4-0, DOWN, LV1);
> - PIN(IN, gpf4-1, DOWN, LV1);
> - PIN(IN, gpf4-2, DOWN, LV1);
> - PIN(IN, gpf4-3, DOWN, LV1);
> - PIN(IN, gpf4-4, DOWN, LV1);
> - PIN(IN, gpf4-5, DOWN, LV1);
> - PIN(IN, gpf4-6, DOWN, LV1);
> - PIN(IN, gpf4-7, DOWN, LV1);
> -
> - PIN(IN, gpf5-0, DOWN, LV1);
> - PIN(IN, gpf5-1, DOWN, LV1);
> - PIN(IN, gpf5-2, DOWN, LV1);
> - PIN(IN, gpf5-3, DOWN, LV1);
> - PIN(OUT, gpf5-4, NONE, LV1);
> - PIN(IN, gpf5-5, DOWN, LV1);
> - PIN(IN, gpf5-6, DOWN, LV1);
> - PIN(IN, gpf5-7, DOWN, LV1);
> + PIN(INPUT, gpa0-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpa0-1, NONE, FAST_SR1);
> + PIN(INPUT, gpa0-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpa0-3, NONE, FAST_SR1);
> + PIN(INPUT, gpa0-4, NONE, FAST_SR1);
> + PIN(INPUT, gpa0-5, DOWN, FAST_SR1);
> + PIN(INPUT, gpa0-6, NONE, FAST_SR1);
> + PIN(INPUT, gpa0-7, NONE, FAST_SR1);
> +
> + PIN(INPUT, gpa1-0, UP, FAST_SR1);
> + PIN(INPUT, gpa1-1, NONE, FAST_SR1);
> + PIN(INPUT, gpa1-2, NONE, FAST_SR1);
> + PIN(INPUT, gpa1-3, DOWN, FAST_SR1);
> + PIN(INPUT, gpa1-4, DOWN, FAST_SR1);
> + PIN(INPUT, gpa1-5, NONE, FAST_SR1);
> + PIN(INPUT, gpa1-6, NONE, FAST_SR1);
> + PIN(INPUT, gpa1-7, NONE, FAST_SR1);
> +
> + PIN(INPUT, gpa2-0, NONE, FAST_SR1);
> + PIN(INPUT, gpa2-1, NONE, FAST_SR1);
> + PIN(INPUT, gpa2-2, NONE, FAST_SR1);
> + PIN(INPUT, gpa2-3, DOWN, FAST_SR1);
> + PIN(INPUT, gpa2-4, NONE, FAST_SR1);
> + PIN(INPUT, gpa2-5, DOWN, FAST_SR1);
> + PIN(INPUT, gpa2-6, DOWN, FAST_SR1);
> + PIN(INPUT, gpa2-7, NONE, FAST_SR1);
> +
> + PIN(INPUT, gpa3-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpa3-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpa3-2, NONE, FAST_SR1);
> + PIN(INPUT, gpa3-3, DOWN, FAST_SR1);
> + PIN(INPUT, gpa3-4, NONE, FAST_SR1);
> + PIN(INPUT, gpa3-5, DOWN, FAST_SR1);
> + PIN(INPUT, gpa3-6, DOWN, FAST_SR1);
> + PIN(INPUT, gpa3-7, DOWN, FAST_SR1);
> +
> + PIN(INPUT, gpf1-0, NONE, FAST_SR1);
> + PIN(INPUT, gpf1-1, NONE, FAST_SR1);
> + PIN(INPUT, gpf1-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpf1-4, UP, FAST_SR1);
> + PIN(OUTPUT, gpf1-5, NONE, FAST_SR1);
> + PIN(INPUT, gpf1-6, DOWN, FAST_SR1);
> + PIN(INPUT, gpf1-7, DOWN, FAST_SR1);
> +
> + PIN(INPUT, gpf2-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpf2-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpf2-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpf2-3, DOWN, FAST_SR1);
> +
> + PIN(INPUT, gpf3-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpf3-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpf3-2, NONE, FAST_SR1);
> + PIN(INPUT, gpf3-3, DOWN, FAST_SR1);
> +
> + PIN(INPUT, gpf4-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpf4-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpf4-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpf4-3, DOWN, FAST_SR1);
> + PIN(INPUT, gpf4-4, DOWN, FAST_SR1);
> + PIN(INPUT, gpf4-5, DOWN, FAST_SR1);
> + PIN(INPUT, gpf4-6, DOWN, FAST_SR1);
> + PIN(INPUT, gpf4-7, DOWN, FAST_SR1);
> +
> + PIN(INPUT, gpf5-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpf5-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpf5-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpf5-3, DOWN, FAST_SR1);
> + PIN(OUTPUT, gpf5-4, NONE, FAST_SR1);
> + PIN(INPUT, gpf5-5, DOWN, FAST_SR1);
> + PIN(INPUT, gpf5-6, DOWN, FAST_SR1);
> + PIN(INPUT, gpf5-7, DOWN, FAST_SR1);
> };
>
> te_irq: te_irq {
> @@ -826,8 +826,8 @@
> pinctrl-0 = <&initial_cpif>;
>
> initial_cpif: initial-state {
> - PIN(IN, gpv6-0, DOWN, LV1);
> - PIN(IN, gpv6-1, DOWN, LV1);
> + PIN(INPUT, gpv6-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpv6-1, DOWN, FAST_SR1);
> };
> };
>
> @@ -836,9 +836,9 @@
> pinctrl-0 = <&initial_ese>;
>
> initial_ese: initial-state {
> - PIN(IN, gpj2-0, DOWN, LV1);
> - PIN(IN, gpj2-1, DOWN, LV1);
> - PIN(IN, gpj2-2, DOWN, LV1);
> + PIN(INPUT, gpj2-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpj2-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpj2-2, DOWN, FAST_SR1);
> };
> };
>
> @@ -847,11 +847,11 @@
> pinctrl-0 = <&initial_fsys>;
>
> initial_fsys: initial-state {
> - PIN(IN, gpr3-0, NONE, LV1);
> - PIN(IN, gpr3-1, DOWN, LV1);
> - PIN(IN, gpr3-2, DOWN, LV1);
> - PIN(IN, gpr3-3, DOWN, LV1);
> - PIN(IN, gpr3-7, NONE, LV1);
> + PIN(INPUT, gpr3-0, NONE, FAST_SR1);
> + PIN(INPUT, gpr3-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpr3-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpr3-3, DOWN, FAST_SR1);
> + PIN(INPUT, gpr3-7, NONE, FAST_SR1);
> };
> };
>
> @@ -860,14 +860,14 @@
> pinctrl-0 = <&initial_imem>;
>
> initial_imem: initial-state {
> - PIN(IN, gpf0-0, UP, LV1);
> - PIN(IN, gpf0-1, UP, LV1);
> - PIN(IN, gpf0-2, DOWN, LV1);
> - PIN(IN, gpf0-3, UP, LV1);
> - PIN(IN, gpf0-4, DOWN, LV1);
> - PIN(IN, gpf0-5, NONE, LV1);
> - PIN(IN, gpf0-6, DOWN, LV1);
> - PIN(IN, gpf0-7, UP, LV1);
> + PIN(INPUT, gpf0-0, UP, FAST_SR1);
> + PIN(INPUT, gpf0-1, UP, FAST_SR1);
> + PIN(INPUT, gpf0-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpf0-3, UP, FAST_SR1);
> + PIN(INPUT, gpf0-4, DOWN, FAST_SR1);
> + PIN(INPUT, gpf0-5, NONE, FAST_SR1);
> + PIN(INPUT, gpf0-6, DOWN, FAST_SR1);
> + PIN(INPUT, gpf0-7, UP, FAST_SR1);
> };
> };
>
> @@ -876,7 +876,7 @@
> pinctrl-0 = <&initial_nfc>;
>
> initial_nfc: initial-state {
> - PIN(IN, gpj0-2, DOWN, LV1);
> + PIN(INPUT, gpj0-2, DOWN, FAST_SR1);
> };
> };
>
> @@ -885,54 +885,54 @@
> pinctrl-0 = <&initial_peric>;
>
> initial_peric: initial-state {
> - PIN(IN, gpv7-0, DOWN, LV1);
> - PIN(IN, gpv7-1, DOWN, LV1);
> - PIN(IN, gpv7-2, NONE, LV1);
> - PIN(IN, gpv7-3, DOWN, LV1);
> - PIN(IN, gpv7-4, DOWN, LV1);
> - PIN(IN, gpv7-5, DOWN, LV1);
> + PIN(INPUT, gpv7-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpv7-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpv7-2, NONE, FAST_SR1);
> + PIN(INPUT, gpv7-3, DOWN, FAST_SR1);
> + PIN(INPUT, gpv7-4, DOWN, FAST_SR1);
> + PIN(INPUT, gpv7-5, DOWN, FAST_SR1);
>
> - PIN(IN, gpb0-4, DOWN, LV1);
> + PIN(INPUT, gpb0-4, DOWN, FAST_SR1);
>
> - PIN(IN, gpc0-2, DOWN, LV1);
> - PIN(IN, gpc0-5, DOWN, LV1);
> - PIN(IN, gpc0-7, DOWN, LV1);
> + PIN(INPUT, gpc0-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpc0-5, DOWN, FAST_SR1);
> + PIN(INPUT, gpc0-7, DOWN, FAST_SR1);
>
> - PIN(IN, gpc1-1, DOWN, LV1);
> + PIN(INPUT, gpc1-1, DOWN, FAST_SR1);
>
> - PIN(IN, gpc3-4, NONE, LV1);
> - PIN(IN, gpc3-5, NONE, LV1);
> - PIN(IN, gpc3-6, NONE, LV1);
> - PIN(IN, gpc3-7, NONE, LV1);
> + PIN(INPUT, gpc3-4, NONE, FAST_SR1);
> + PIN(INPUT, gpc3-5, NONE, FAST_SR1);
> + PIN(INPUT, gpc3-6, NONE, FAST_SR1);
> + PIN(INPUT, gpc3-7, NONE, FAST_SR1);
>
> - PIN(OUT, gpg0-0, NONE, LV1);
> - PIN(FUNC1, gpg0-1, DOWN, LV1);
> + PIN(OUTPUT, gpg0-0, NONE, FAST_SR1);
> + PIN(2, gpg0-1, DOWN, FAST_SR1);
>
> - PIN(IN, gpd2-5, DOWN, LV1);
> + PIN(INPUT, gpd2-5, DOWN, FAST_SR1);
>
> - PIN(IN, gpd4-0, NONE, LV1);
> - PIN(IN, gpd4-1, DOWN, LV1);
> - PIN(IN, gpd4-2, DOWN, LV1);
> - PIN(IN, gpd4-3, DOWN, LV1);
> - PIN(IN, gpd4-4, DOWN, LV1);
> + PIN(INPUT, gpd4-0, NONE, FAST_SR1);
> + PIN(INPUT, gpd4-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpd4-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpd4-3, DOWN, FAST_SR1);
> + PIN(INPUT, gpd4-4, DOWN, FAST_SR1);
>
> - PIN(IN, gpd6-3, DOWN, LV1);
> + PIN(INPUT, gpd6-3, DOWN, FAST_SR1);
>
> - PIN(IN, gpd8-1, UP, LV1);
> + PIN(INPUT, gpd8-1, UP, FAST_SR1);
>
> - PIN(IN, gpg1-0, DOWN, LV1);
> - PIN(IN, gpg1-1, DOWN, LV1);
> - PIN(IN, gpg1-2, DOWN, LV1);
> - PIN(IN, gpg1-3, DOWN, LV1);
> - PIN(IN, gpg1-4, DOWN, LV1);
> + PIN(INPUT, gpg1-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpg1-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpg1-2, DOWN, FAST_SR1);
> + PIN(INPUT, gpg1-3, DOWN, FAST_SR1);
> + PIN(INPUT, gpg1-4, DOWN, FAST_SR1);
>
> - PIN(IN, gpg2-0, DOWN, LV1);
> - PIN(IN, gpg2-1, DOWN, LV1);
> + PIN(INPUT, gpg2-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpg2-1, DOWN, FAST_SR1);
>
> - PIN(IN, gpg3-0, DOWN, LV1);
> - PIN(IN, gpg3-1, DOWN, LV1);
> - PIN(IN, gpg3-5, DOWN, LV1);
> - PIN(IN, gpg3-7, DOWN, LV1);
> + PIN(INPUT, gpg3-0, DOWN, FAST_SR1);
> + PIN(INPUT, gpg3-1, DOWN, FAST_SR1);
> + PIN(INPUT, gpg3-5, DOWN, FAST_SR1);
> + PIN(INPUT, gpg3-7, DOWN, FAST_SR1);
> };
> };
>
> @@ -941,7 +941,7 @@
> pinctrl-0 = <&initial_touch>;
>
> initial_touch: initial-state {
> - PIN(IN, gpj1-2, DOWN, LV1);
> + PIN(INPUT, gpj1-2, DOWN, FAST_SR1);
> };
> };
>
>
^ permalink raw reply
* [PATCH 06/12] usb: dwc3: omap: Replace the extcon API
From: Chanwoo Choi @ 2016-12-30 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5865CA76.1020001@samsung.com>
Hi Felipe,
On 2016? 12? 30? 11:46, Chanwoo Choi wrote:
> Hi Felipe,
>
> On 2016? 12? 02? 18:03, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Chanwoo Choi <cw00.choi@samsung.com> writes:
>>> Hi Felipe,
>>>
>>> On 2016? 11? 30? 19:36, Felipe Balbi wrote:
>>>>
>>>> Hi,
>>>>
>>>> Chanwoo Choi <cw00.choi@samsung.com> writes:
>>>>> This patch uses the resource-managed extcon API for extcon_register_notifier()
>>>>> and replaces the deprecated extcon API as following:
>>>>> - extcon_get_cable_state_() -> extcon_get_state()
>>>>>
>>>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>
>>>> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>>>>
>>>
>>> Thanks for your review.
>>>
>>> Each patch has no any dependency among patches.
>>> So, If possible, could you pick the patch6/8/9/10/11/12 on your tree?
>>
>> my tree is closed for v4.10, I can pick it up for v4.11
>
> Could you please pick up these patches(patch6/8/9/10/11/12)?
> These patches were already reviewed by you.
>
I sent v2 patchset.
[1] https://www.spinics.net/lists/kernel/msg2410950.html
- "[PATCH v2 0/6] usb: Replace the deprecated extcon API"
--
Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v2] bus: imx-weim: Fix the "fsl, weim-cs-gpr" lookup method
From: Shawn Guo @ 2016-12-30 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480089861-28025-1-git-send-email-festevam@gmail.com>
On Fri, Nov 25, 2016 at 02:04:21PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Commit 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to
> dtsi's") causes the following probe error when the weim node is not
> present on the board dts (such as imx6q-sabresd):
>
> imx-weim 21b8000.weim: Invalid 'ranges' configuration
> imx-weim: probe of 21b8000.weim failed with error -22
>
> As the "fsl,weim-cs-gpr" property changed the location from the individual
> board dts "&weim" node to the common dtsi node we can no longer reach it
> via syscon_regmap_lookup_by_phandle(), so use
> syscon_regmap_lookup_by_compatible() instead, which will successfully
> find the "fsl,weim-cs-gpr" property.
>
> Fixes: 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to dtsi's")
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
NACK.
> ---
> Changes since v1:
> - Fix copy and paste error of the error message
> - Add Fixes tag
>
> drivers/bus/imx-weim.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index 4bd361d..9824c58 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -76,7 +76,7 @@ static int __init imx_weim_gpr_setup(struct platform_device *pdev)
> int cs = 0;
> int i = 0;
>
> - gpr = syscon_regmap_lookup_by_phandle(np, "fsl,weim-cs-gpr");
> + gpr = syscon_regmap_lookup_by_compatible("fsl,weim-cs-gpr");
"fsl,weim-cs-gpr" is *not* a compatible string, while
what syscon_regmap_lookup_by_compatible() does is to find a syscon node
by its compatible string.
Your understanding about how the error message comes and the fix to it
are completely wrong.
Shawn
> if (IS_ERR(gpr)) {
> dev_dbg(&pdev->dev, "failed to find weim-cs-gpr\n");
> return 0;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 10/20] gpio: pca953x: Add optional reset gpio control
From: Lothar Waßmann @ 2016-12-30 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-11-git-send-email-steve_longerbeam@mentor.com>
Hi,
On Thu, 29 Dec 2016 14:27:25 -0800 Steve Longerbeam wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
>
> ---
>
> v2:
> - documented optional reset-gpios property in
> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt.
> ---
> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
> drivers/gpio/gpio-pca953x.c | 17 +++++++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> index 08dd15f..da54f4c 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> @@ -29,6 +29,10 @@ Required properties:
> onsemi,pca9654
> exar,xra1202
>
> +Optional properties:
> + - reset-gpios: GPIO specification for the RESET input
> +
> +
> Example:
>
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index d5d72d8..d1c0bd5 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -22,6 +22,7 @@
> #include <linux/of_platform.h>
> #include <linux/acpi.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/gpio/consumer.h>
>
> #define PCA953X_INPUT 0
> #define PCA953X_OUTPUT 1
> @@ -133,6 +134,7 @@ struct pca953x_chip {
> const char *const *names;
> unsigned long driver_data;
> struct regulator *regulator;
> + struct gpio_desc *reset_gpio;
>
> const struct pca953x_reg_config *regs;
>
> @@ -756,6 +758,21 @@ static int pca953x_probe(struct i2c_client *client,
> } else {
> chip->gpio_start = -1;
> irq_base = 0;
> +
> + /* see if we need to de-assert a reset pin */
> + chip->reset_gpio = devm_gpiod_get_optional(&client->dev,
> + "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(chip->reset_gpio)) {
> + dev_err(&client->dev, "request for reset pin failed\n");
> + return PTR_ERR(chip->reset_gpio);
> + }
> +
> + if (chip->reset_gpio) {
> + /* bring chip out of reset */
> + dev_info(&client->dev, "releasing reset\n");
> + gpiod_set_value(chip->reset_gpio, 0);
>
The pin is already initialized to the inactive state thru the
GPIOD_OUT_LOW flag in devm_gpiod_get_optional(), so this call to
gpiod_set_value() is useless.
Lothar Wa?mann
^ permalink raw reply
* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline
From: Shawn Guo @ 2016-12-30 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161127213516.GF13318@lunn.ch>
On Sun, Nov 27, 2016 at 10:35:16PM +0100, Andrew Lunn wrote:
> On Sun, Nov 27, 2016 at 10:30:54PM +0100, Andreas F?rber wrote:
> > Hi,
> >
> > Am 27.11.2016 um 22:17 schrieb Andrew Lunn:
> > > On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas F?rber wrote:
> > >> Found while reviewing Marvell dsa bindings usage.
> > >
> > > Hi Andreas
> > >
> > > It is good practice to put the maintainer you expect to accept the
> > > patch on the To: line. You have at least two different maintainers on
> > > Cc: so it is currently ambiguous. And these lists can be high volume,
> > > so without a copy in the maintainers inbox, patches can be overlooked.
> >
> > As a vf610 DT patch with LAKML in To I am expecting it to be handled by
> > Shawn or anyone from the NXP/ARM side.
>
> So please have Shawn as To:
>
> The patch you are fixing went through Dave Miller, who is also on Cc:,
> hence the ambiguity.
The good practice was broken from the beginning when patch "arm: vf610:
zii devel b: Add support for switch interrupts") went through net tree,
even without me on copy.
Shawn
^ permalink raw reply
* [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
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