* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.17-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2704,8 +2704,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.17/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* [PATCH 2/4] arm: dts: add support for Laird WB50N cpu module and DVK
From: Alexandre Belloni @ 2018-06-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-2-git-send-email-ben.whitten@lairdtech.com>
On 14/06/2018 09:51:55+0100, Ben Whitten wrote:
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/at91-wb50n.dts | 116 ++++++++++++++++++++++
> arch/arm/boot/dts/at91-wb50n.dtsi | 202 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 320 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/at91-wb50n.dts
> create mode 100644 arch/arm/boot/dts/at91-wb50n.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 1ee94ee..fd5f8a6 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -61,7 +61,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
> at91-sama5d4_ma5d4evk.dtb \
> at91-sama5d4_xplained.dtb \
> at91-sama5d4ek.dtb \
> - at91-vinco.dtb
> + at91-vinco.dtb \
> + at91-wb50n.dtb
I know we have been bad at this but this should be
at91-<soc>-<board>.dtb so at91-sama5d31-wb50n.dtb
> dtb-$(CONFIG_ARCH_ATLAS6) += \
> atlas6-evb.dtb
> dtb-$(CONFIG_ARCH_ATLAS7) += \
> diff --git a/arch/arm/boot/dts/at91-wb50n.dts b/arch/arm/boot/dts/at91-wb50n.dts
> new file mode 100644
> index 0000000..ee4f823
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91-wb50n.dts
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * at91-wb50n.dts - Device Tree file for wb50n evaluation board
> + *
> + * Copyright (C) 2018 Laird
> + *
> + */
> +
> +/dts-v1/;
> +#include "at91-wb50n.dtsi"
> +
> +/ {
> + model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
> + compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
> +
> + ahb {
> + apb {
> + watchdog at fffffe40 {
I don't mind if you want to have a preparation patch adding the
necessary labels in the soc dtsi so you don't have to reproduce the
ahb/apb hierarchy here.
> + ahb {
> + apb {
> + pinctrl at fffff200 {
Ditto
> + board {
> + pinctrl_mmc0_cd: mmc0_cd {
> + atmel,pins = <AT91_PIOC 26 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PC26 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_usba_vbus: usba_vbus {
> + atmel,pins = <AT91_PIOB 13 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB13 GPIO with deglitch */
> + };
> + };
> + };
> + };
> + };
> +};
> +
> +&slow_osc {
> + atmel,osc-bypass;
> +};
After the clock binding rework, this will have to be moved to the pmc
node (the rework is not posted, this is just to remind me that this will
have to be done).
> +
> +&usart1_clk {
> + atmel,clk-output-range = <0 132000000>;
> +};
The datasheet explicitly states that 66 MHz is the maximum allowed
frequency for the USART. Note that the new binding will not allow you to
do that.
However, I see the table disappeared from the latest datasheet. Maybe
Nicolas can comment on that?
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.9-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2626,8 +2626,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.9/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* [PATCH v4 0/7] add virt-dma support for imx-sdma
From: Robin Gong @ 2018-06-14 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966400.21021.26.camel@pengutronix.de>
Hi Lucas,
Could you double check again? Still can reproduce lockdep
warning on UART if change
spin_lock_lockirqsave/spinlock_unlock_irqrestore to
spin_lock/spin_unlock in sdma_int_handler as you said without patch7/7.
Would you please ask below two more questions?
1. Does your uart case pass now with my v4 patchset?
2. Do you make some code change in your local('I just gave this series
a spin')to reproduce your below issue? If yes, could you post your
change?
On ?, 2018-06-14 at 10:53 +0200, Lucas Stach wrote:
> Hi Robin,
>
> I just gave this series a spin and it seems there is even more
> locking
> fun, see the lockdep output below. After taking a short look it seems
> this is caused by using the wrong spinlock variants in
> sdma_int_handler(), those should also use the _irqsave ones. When
> fixing this you might want to reconsider patch 7/7, as it's probably
> not needed at all.
>
> Regards,
> Lucas
>
> [???20.479401]
> ========================================================
> [???20.485769] WARNING: possible irq lock inversion dependency
> detected
> [???20.492140] 4.17.0+ #1538 Not tainted
> [???20.495814] ------------------------------------------------------
> --
> [???20.502181] systemd/1 just changed the state of lock:
> [???20.507247] c0abdafc (&(&substream->self_group.lock)->rlock){-
> ...}, at: snd_pcm_stream_lock+0x54/0x60
> [???20.516523] but this lock took another, HARDIRQ-unsafe lock in the
> past:
> [???20.523234]??(fs_reclaim){+.+.}
> [???20.523253]?
> [???20.523253]?
> [???20.523253] and interrupts could create inverse lock ordering
> between them.
> [???20.523253]?
> [???20.537804]?
> [???20.537804] other info that might help us debug this:
> [???20.544344]??Possible interrupt unsafe locking scenario:
> [???20.544344]?
> [???20.551144]????????CPU0????????????????????CPU1
> [???20.555686]????????----????????????????????----
> [???20.560224]???lock(fs_reclaim);
> [???20.563386]????????????????????????????????local_irq_disable();
> [???20.569315]????????????????????????????????lock(&(&substream-
> >self_group.lock)->rlock);
> [???20.577337]????????????????????????????????lock(fs_reclaim);
> [???20.583014]???<Interrupt>
> [???20.585643]?????lock(&(&substream->self_group.lock)->rlock);
> [???20.591322]?
> [???20.591322]??*** DEADLOCK ***
> [???20.591322]?
> [???20.597260] 1 lock held by systemd/1:
> [???20.607806]??#0: ab23d11c (snd_pcm_link_rwlock){.-..}, at:
> snd_pcm_stream_lock+0x4c/0x60
> [???20.615951]?
> [???20.615951] the shortest dependencies between 2nd lock and 1st
> lock:
> [???20.623799]??-> (fs_reclaim){+.+.} ops: 248474 {
> [???20.628456]?????HARDIRQ-ON-W at:
> [???20.631716]???????????????????????lock_acquire+0x260/0x29c
> [???20.637223]???????????????????????fs_reclaim_acquire+0x48/0x58
> [???20.643075]???????????????????????kmem_cache_alloc_trace+0x3c/0x36
> 4
> [???20.649366]???????????????????????alloc_worker.constprop.15+0x28/0
> x64
> [???20.655824]???????????????????????init_rescuer.part.5+0x20/0xa4
> [???20.661764]???????????????????????workqueue_init+0x124/0x1f8
> [???20.667446]???????????????????????kernel_init_freeable+0x60/0x550
> [???20.673561]???????????????????????kernel_init+0x18/0x120
> [???20.678890]???????????????????????ret_from_fork+0x14/0x20
> [???20.684299]?????????????????????????(null)
> [???20.688408]?????SOFTIRQ-ON-W at:
> [???20.691659]???????????????????????lock_acquire+0x260/0x29c
> [???20.697158]???????????????????????fs_reclaim_acquire+0x48/0x58
> [???20.703006]???????????????????????kmem_cache_alloc_trace+0x3c/0x36
> 4
> [???20.709288]???????????????????????alloc_worker.constprop.15+0x28/0
> x64
> [???20.709301]???????????????????????init_rescuer.part.5+0x20/0xa4
> [???20.720717]???????????????????????workqueue_init+0x124/0x1f8
> [???20.720729]???????????????????????kernel_init_freeable+0x60/0x550
> [???20.720738]???????????????????????kernel_init+0x18/0x120
> [???20.720746]???????????????????????ret_from_fork+0x14/0x20
> [???20.720751]?????????????????????????(null)
> [???20.720756]?????INITIAL USE at:
> [???20.720770]??????????????????????lock_acquire+0x260/0x29c
> [???20.720782]??????????????????????fs_reclaim_acquire+0x48/0x58
> [???20.774374]??????????????????????kmem_cache_alloc_trace+0x3c/0x364
> [???20.780574]??????????????????????alloc_worker.constprop.15+0x28/0x
> 64
> [???20.786945]??????????????????????init_rescuer.part.5+0x20/0xa4
> [???20.792794]??????????????????????workqueue_init+0x124/0x1f8
> [???20.798384]??????????????????????kernel_init_freeable+0x60/0x550
> [???20.804406]??????????????????????kernel_init+0x18/0x120
> [???20.809648]??????????????????????ret_from_fork+0x14/0x20
> [???20.814971]????????????????????????(null)
> [???20.818992]???}
> [???20.820768]???... key??????at: [<80e22074>]
> __fs_reclaim_map+0x0/0x10
> [???20.827220]???... acquired at:
> [???20.830289]????fs_reclaim_acquire+0x48/0x58
> [???20.834487]????kmem_cache_alloc_trace+0x3c/0x364
> [???20.839123]????sdma_transfer_init+0x44/0x130
> [???20.843409]????sdma_prep_dma_cyclic+0x78/0x21c
> [???20.847869]????snd_dmaengine_pcm_trigger+0xdc/0x184
> [???20.852764]????soc_pcm_trigger+0x164/0x190
> [???20.856876]????snd_pcm_do_start+0x34/0x40
> [???20.860902]????snd_pcm_action_single+0x48/0x74
> [???20.865360]????snd_pcm_action+0x34/0xfc
> [???20.869213]????snd_pcm_ioctl+0x910/0x10ec
> [???20.873241]????vfs_ioctl+0x30/0x44
> [???20.876657]????do_vfs_ioctl+0xac/0x974
> [???20.880421]????ksys_ioctl+0x48/0x64
> [???20.883923]????sys_ioctl+0x18/0x1c
> [???20.887340]????ret_fast_syscall+0x0/0x28
> [???20.891277]????0x7289bcbc
> [???20.893909]?
> [???20.895410] -> (&(&substream->self_group.lock)->rlock){-...} ops:
> 59 {
> [???20.901977]????IN-HARDIRQ-W at:
> [???20.905143]?????????????????????lock_acquire+0x260/0x29c
> [???20.910473]?????????????????????_raw_spin_lock+0x48/0x58
> [???20.915801]?????????????????????snd_pcm_stream_lock+0x54/0x60
> [???20.921561]?????????????????????_snd_pcm_stream_lock_irqsave+0x40/
> 0x48
> [???20.928107]?????????????????????snd_pcm_period_elapsed+0x2c/0xa4
> [???20.934127]?????????????????????dmaengine_pcm_dma_complete+0x54/0x
> 58
> [???20.940498]?????????????????????sdma_int_handler+0x1dc/0x2a8
> [???20.946179]?????????????????????__handle_irq_event_percpu+0x1fc/0x
> 498
> [???20.952635]?????????????????????handle_irq_event_percpu+0x38/0x8c
> [???20.958742]?????????????????????handle_irq_event+0x48/0x6c
> [???20.964242]?????????????????????handle_fasteoi_irq+0xc4/0x138
> [???20.970006]?????????????????????generic_handle_irq+0x28/0x38
> [???20.975681]?????????????????????__handle_domain_irq+0xb0/0xc4
> [???20.981443]?????????????????????gic_handle_irq+0x68/0xa0
> [???20.986769]?????????????????????__irq_svc+0x70/0xb0
> [???20.991662]?????????????????????_raw_spin_unlock_irq+0x38/0x6c
> [???20.997511]?????????????????????task_work_run+0x90/0xb8
> [???21.002751]?????????????????????do_work_pending+0xc8/0xd0
> [???21.008164]?????????????????????slow_work_pending+0xc/0x20
> [???21.013661]?????????????????????0x76c77e86
> [???21.017768]????INITIAL USE at:
> [???21.020844]????????????????????lock_acquire+0x260/0x29c
> [???21.026086]????????????????????_raw_spin_lock+0x48/0x58
> [???21.031328]????????????????????snd_pcm_stream_lock+0x54/0x60
> [???21.037002]????????????????????snd_pcm_stream_lock_irq+0x38/0x3c
> [???21.043023]????????????????????snd_pcm_sync_ptr+0x214/0x260
> [???21.048609]????????????????????snd_pcm_ioctl+0xbe0/0x10ec
> [???21.054027]????????????????????vfs_ioctl+0x30/0x44
> [???21.058832]????????????????????do_vfs_ioctl+0xac/0x974
> [???21.063984]????????????????????ksys_ioctl+0x48/0x64
> [???21.068875]????????????????????sys_ioctl+0x18/0x1c
> [???21.073679]????????????????????ret_fast_syscall+0x0/0x28
> [???21.079004]????????????????????0x7e9026dc
> [???21.083023]??}
> [???21.084710]??... key??????at: [<8162a6e4>] __key.31798+0x0/0x8
> [???21.090552]??... acquired at:
> [???21.093537]????mark_lock+0x3a4/0x69c
> [???21.097128]????__lock_acquire+0x420/0x16d4
> [???21.101239]????lock_acquire+0x260/0x29c
> [???21.105091]????_raw_spin_lock+0x48/0x58
> [???21.108940]????snd_pcm_stream_lock+0x54/0x60
> [???21.113226]????_snd_pcm_stream_lock_irqsave+0x40/0x48
> [???21.118296]????snd_pcm_period_elapsed+0x2c/0xa4
> [???21.122841]????dmaengine_pcm_dma_complete+0x54/0x58
> [???21.127735]????sdma_int_handler+0x1dc/0x2a8
> [???21.131937]????__handle_irq_event_percpu+0x1fc/0x498
> [???21.136915]????handle_irq_event_percpu+0x38/0x8c
> [???21.141547]????handle_irq_event+0x48/0x6c
> [???21.145570]????handle_fasteoi_irq+0xc4/0x138
> [???21.149854]????generic_handle_irq+0x28/0x38
> [???21.154052]????__handle_domain_irq+0xb0/0xc4
> [???21.158335]????gic_handle_irq+0x68/0xa0
> [???21.162184]????__irq_svc+0x70/0xb0
> [???21.165601]????_raw_spin_unlock_irq+0x38/0x6c
> [???21.169973]????task_work_run+0x90/0xb8
> [???21.173735]????do_work_pending+0xc8/0xd0
> [???21.177670]????slow_work_pending+0xc/0x20
> [???21.181691]????0x76c77e86
> [???21.184320]?
> [???21.185821]?
> [???21.185821] stack backtrace:
> [???21.190198] CPU: 0 PID: 1 Comm: systemd Not tainted 4.17.0+ #1538
> [???21.196303] Hardware name: Freescale i.MX6 Quad/DualLite (Device
> Tree)
> [???21.202841] Backtrace:?
> [???21.205314] [<8010e318>] (dump_backtrace) from [<8010e604>]
> (show_stack+0x20/0x24)
> [???21.212900]??r7:80e9f3d0 r6:00000000 r5:60070193 r4:80e9f3d0
> [???21.218581] [<8010e5e4>] (show_stack) from [<8099b660>]
> (dump_stack+0xa4/0xd8)
> [???21.225825] [<8099b5bc>] (dump_stack) from [<8017b52c>]
> (print_irq_inversion_bug+0x15c/0x1fc)
> [???21.234368]??r9:814da818 r8:00000001 r7:ee926c00 r6:00000000
> r5:ee915bb0 r4:814da818
> [???21.242133] [<8017b3d0>] (print_irq_inversion_bug) from
> [<8017b6dc>] (check_usage_forwards+0x110/0x13c)
> [???21.251544]??r9:00000002 r8:80bfd3e2 r7:ee926c00 r6:ee927148
> r5:80e08488 r4:00000001
> [???21.259306] [<8017b5cc>] (check_usage_forwards) from [<8017c2a4>]
> (mark_lock+0x3a4/0x69c)
> [???21.267500]??r9:ee926c00 r8:80a03cd8 r7:00000101 r6:00000002
> r5:00000000 r4:ee927148
> [???21.275263] [<8017bf00>] (mark_lock) from [<8017cf68>]
> (__lock_acquire+0x420/0x16d4)
> [???21.283023]??r10:ee927148 r9:ed4620e4 r8:ee926c00 r7:00000000
> r6:00000001 r5:00000001
> [???21.290863]??r4:00000490
> [???21.293416] [<8017cb48>] (__lock_acquire) from [<8017ed58>]
> (lock_acquire+0x260/0x29c)
> [???21.301350]??r10:00000001 r9:80e084a4 r8:00000000 r7:00000000
> r6:00000000 r5:ed4620e4
> [???21.309189]??r4:00000000
> [???21.311746] [<8017eaf8>] (lock_acquire) from [<809b74f0>]
> (_raw_spin_lock+0x48/0x58)
> [???21.319506]??r10:ee0a4714 r9:ed457100 r8:ee0a46c8 r7:ee0a4714
> r6:ee0a4010 r5:807847b0
> [???21.327346]??r4:ed4620d4
> [???21.329902] [<809b74a8>] (_raw_spin_lock) from [<807847b0>]
> (snd_pcm_stream_lock+0x54/0x60)
> [???21.338265]??r5:ed462000 r4:ed462000
> [???21.341863] [<8078475c>] (snd_pcm_stream_lock) from [<80784838>]
> (_snd_pcm_stream_lock_irqsave+0x40/0x48)
> [???21.351440]??r5:ed462000 r4:60070193
> [???21.355042] [<807847f8>] (_snd_pcm_stream_lock_irqsave) from
> [<8078b044>] (snd_pcm_period_elapsed+0x2c/0xa4)
> [???21.364881]??r5:ee3ef000 r4:ed462000
> [???21.368478] [<8078b018>] (snd_pcm_period_elapsed) from
> [<8078d7b4>] (dmaengine_pcm_dma_complete+0x54/0x58)
> [???21.378148]??r7:ee0a4714 r6:ee0a4010 r5:00000007 r4:ee0a46bc
> [???21.383827] [<8078d760>] (dmaengine_pcm_dma_complete) from
> [<80504c0c>] (sdma_int_handler+0x1dc/0x2a8)
> [???21.393157] [<80504a30>] (sdma_int_handler) from [<8018cd28>]
> (__handle_irq_event_percpu+0x1fc/0x498)
> [???21.402393]??r10:00000000 r9:eeafd400 r8:80e084a4 r7:00000038
> r6:00000038 r5:80ea3c12
> [???21.410233]??r4:ee2b5d40
> [???21.412787] [<8018cb2c>] (__handle_irq_event_percpu) from
> [<8018cffc>] (handle_irq_event_percpu+0x38/0x8c)
> [???21.422457]??r10:00000000 r9:ee914000 r8:ee81d400 r7:00000038
> r6:eeafd400 r5:eeafd464
> [???21.430296]??r4:80e08488
> [???21.432852] [<8018cfc4>] (handle_irq_event_percpu) from
> [<8018d098>] (handle_irq_event+0x48/0x6c)
> [???21.441736]??r6:eeafd464 r5:eeafd464 r4:eeafd400
> [???21.446374] [<8018d050>] (handle_irq_event) from [<8019146c>]
> (handle_fasteoi_irq+0xc4/0x138)
> [???21.454912]??r7:00000038 r6:eeafd464 r5:80e10a60 r4:eeafd400
> [???21.460589] [<801913a8>] (handle_fasteoi_irq) from [<8018bd9c>]
> (generic_handle_irq+0x28/0x38)
> [???21.469214]??r7:00000038 r6:80d92ae4 r5:00000000 r4:00000000
> [???21.474893] [<8018bd74>] (generic_handle_irq) from [<8018c48c>]
> (__handle_domain_irq+0xb0/0xc4)
> [???21.483611] [<8018c3dc>] (__handle_domain_irq) from [<80102330>]
> (gic_handle_irq+0x68/0xa0)
> [???21.491978]??r9:ee914000 r8:f4001100 r7:80e5c6bc r6:ee915f00
> r5:80e08c3c r4:f4000100
> [???21.499738] [<801022c8>] (gic_handle_irq) from [<801019f0>]
> (__irq_svc+0x70/0xb0)
> [???21.507233] Exception stack(0xee915f00 to 0xee915f48)
> [???21.512303] 5f00: 00000001 00000004 00000000 ee926c00 ee9270a8
> ee926c00 ecc45e00 ee9270a8
> [???21.520498] 5f20: 80ec23b0 ee914000 00000000 ee915f64 ee915f20
> ee915f50 8017c7c0 809b78ac
> [???21.528687] 5f40: 20070013 ffffffff
> [???21.532193]??r9:ee914000 r8:80ec23b0 r7:ee915f34 r6:ffffffff
> r5:20070013 r4:809b78ac
> [???21.539959] [<809b7874>] (_raw_spin_unlock_irq) from [<8014e98c>]
> (task_work_run+0x90/0xb8)
> [???21.548321]??r5:ee926c00 r4:ecc45e00
> [???21.551913] [<8014e8fc>] (task_work_run) from [<8010da3c>]
> (do_work_pending+0xc8/0xd0)
> [???21.559848]??r9:ee914000 r8:801011c4 r7:ee915fb0 r6:ffffe000
> r5:00000004 r4:801011c4
> [???21.567608] [<8010d974>] (do_work_pending) from [<80101034>]
> (slow_work_pending+0xc/0x20)
> [???21.575797] Exception stack(0xee915fb0 to 0xee915ff8)
> [???21.580864] 5fa0:?????????????????????????????????????00000000
> 020c34e8 46059f00 00000000
> [???21.589059] 5fc0: 00000002 76f133a4 020df680 00000006 76e6e168
> 00000035 7ef81778 00000035
> [???21.597253] 5fe0: 00000006 7ef816a0 76c75d67 76c77e86 20070030
> 00000039
> [???21.603883]??r7:00000006 r6:020df680 r5:76f133a4 r4:00000002
>
> Am Donnerstag, den 14.06.2018, 22:02 +0800 schrieb Robin Gong:
> >
> > The legacy sdma driver has below limitations or drawbacks:
> > ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and
> > alloc
> > ?????one page size for one channel regardless of only few BDs
> > needed
> > ?????most time. But in few cases, the max PAGE_SIZE maybe not
> > enough.
> > ? 2. One SDMA channel can't stop immediatley once channel disabled
> > which
> > ?????means SDMA interrupt may come in after this channel
> > terminated.There
> > ?????are some patches for this corner case such as commit
> > "2746e2c389f9",
> > ?????but not cover non-cyclic.
> >
> > The common virt-dma overcomes the above limitations. It can alloc
> > bd
> > dynamically and free bd once this tx transfer done. No memory
> > wasted or
> > maximum limititation here, only depends on how many memory can be
> > requested
> > from kernel. For No.2, such issue can be workaround by checking if
> > there
> > is available descript("sdmac->desc") now once the unwanted
> > interrupt
> > coming. At last the common virt-dma is easier for sdma driver
> > maintain.
> >
> > Change from v3:
> > ? 1. add two uart patches which impacted by this patchset.
> > ? 2. unlock 'vc.lock' before cyclic dma callback and lock again
> > after
> > ?????it because some driver such as uart will call
> > dmaengine_tx_status
> > ?????which will acquire 'vc.lock' again and dead lock comes out.
> > ? 3. remove 'Revert commit' stuff since that patch is not wrong and
> > ?????combine two patch into one patch as Sascha's comment.
> >
> > Change from v2:
> > ? 1. include Sascha's patch to make the main patch easier to
> > review.
> > ?????Thanks Sacha.
> > ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
> >
> > Change from v1:
> > ? 1. split v1 patch into 5 patches.
> > ? 2. remove some unnecessary condition check.
> > ? 3. remove unnecessary 'pending' list.
> >
> > Robin Gong (6):
> > ? tty: serial: imx: correct dma cookie status
> > ? dmaengine: imx-sdma: add virt-dma support
> > ? dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in
> > 'struct
> > ????sdma_channel'
> > ? dmaengine: imx-sdma: remove the maximum limitation for bd numbers
> > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > overlap
> > ? tty: serial: imx: split all dma setup operations out of
> > 'port.lock'
> > ????protector
> >
> > Sascha Hauer (1):
> > ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> > ????sdma_channel
> >
> > ?drivers/dma/Kconfig??????|???1 +
> > ?drivers/dma/imx-sdma.c???| 394 +++++++++++++++++++++++++++------
> > --------------
> > ?drivers/tty/serial/imx.c |??99 ++++++------
> > ?3 files changed, 282 insertions(+), 212 deletions(-)
> >
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Leonard Crestez @ 2018-06-14 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Czf1bO7vJZ1UG46DyVhzApqS82GFw+NFm_HN5tjD=xoQ@mail.gmail.com>
On Thu, 2018-06-07 at 14:07 -0300, Fabio Estevam wrote:
> Hi Leonard,
>
> On Thu, Jun 7, 2018 at 2:00 PM, Leonard Crestez <leonard.crestez@nxp.com> wrote:
>
> > +
> > + isl29023 at 44 {
>
> According to Devicetree Specification v0.2 document:
>
> "The name of a node should be somewhat generic, reflecting the function
> of the device and not its precise programming model."
>
> So you could write:
>
> light-sensor at 44
Ok, will fix in v2.
Should I also assign a label, like "isl29023: light-sensor at 44"? I
couldn't find any recommendation on this.
There are no immediate uses for a label but this practice is very
common. Having labels allows creating minor board variants with reduced
churn in the base dts so it seems good.
--
Regards,
Leonard
^ permalink raw reply
* [PATCH v4 0/7] add virt-dma support for imx-sdma
From: Lucas Stach @ 2018-06-14 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528999731.10947.20.camel@nxp.com>
Am Donnerstag, den 14.06.2018, 10:09 +0000 schrieb Robin Gong:
> Hi Lucas,
> Could you double check again? Still can reproduce lockdep
> warning on UART if change
> spin_lock_lockirqsave/spinlock_unlock_irqrestore to
> spin_lock/spin_unlock in sdma_int_handler as you said without
> patch7/7.
Yes, I can reproduce the lockdep issue with _irqsave variants in the
IRQ handler and 7/7 reverted. It fixes the pcm issue though.
> Would you please ask below two more questions?
> 1. Does your uart case pass now with my v4 patchset?
It seems to work, but the change seems to impact the non-DMA serial
somehow. On several boots the system was unable to present a login
prompt, so patch 7/7 seems to break other stuff and it's a pretty
invasive change to the serial driver, which is known to be non-trivial.
I don't have the bandwidth to dig through this patch currently, but I
wonder if it couldn't be simplified with the spinlock stuff in the sdma
driver fixed.
> 2. Do you make some code change in your local('I just gave this
> series
> a spin')to reproduce your below issue? If yes, could you post your
> change?
The lockdep splat below was without any changes to your series.
Regards,
Lucas
> On ?, 2018-06-14 at 10:53 +0200, Lucas Stach wrote:
> > Hi Robin,
> >
> > I just gave this series a spin and it seems there is even more
> > locking
> > fun, see the lockdep output below. After taking a short look it
> > seems
> > this is caused by using the wrong spinlock variants in
> > sdma_int_handler(), those should also use the _irqsave ones. When
> > fixing this you might want to reconsider patch 7/7, as it's
> > probably
> > not needed at all.
> >
> > Regards,
> > Lucas
> >
> > [???20.479401]
> > ========================================================
> > [???20.485769] WARNING: possible irq lock inversion dependency
> > detected
> > [???20.492140] 4.17.0+ #1538 Not tainted
> > [???20.495814] ----------------------------------------------------
> > --
> > --
> > [???20.502181] systemd/1 just changed the state of lock:
> > [???20.507247] c0abdafc (&(&substream->self_group.lock)->rlock){-
> > ...}, at: snd_pcm_stream_lock+0x54/0x60
> > [???20.516523] but this lock took another, HARDIRQ-unsafe lock in
> > the
> > past:
> > [???20.523234]??(fs_reclaim){+.+.}
> > [???20.523253]?
> > [???20.523253]?
> > [???20.523253] and interrupts could create inverse lock ordering
> > between them.
> > [???20.523253]?
> > [???20.537804]?
> > [???20.537804] other info that might help us debug this:
> > [???20.544344]??Possible interrupt unsafe locking scenario:
> > [???20.544344]?
> > [???20.551144]????????CPU0????????????????????CPU1
> > [???20.555686]????????----????????????????????----
> > [???20.560224]???lock(fs_reclaim);
> > [???20.563386]????????????????????????????????local_irq_disable();
> > [???20.569315]????????????????????????????????lock(&(&substream-
> > > self_group.lock)->rlock);
> >
> > [???20.577337]????????????????????????????????lock(fs_reclaim);
> > [???20.583014]???<Interrupt>
> > [???20.585643]?????lock(&(&substream->self_group.lock)->rlock);
> > [???20.591322]?
> > [???20.591322]??*** DEADLOCK ***
> > [???20.591322]?
> > [???20.597260] 1 lock held by systemd/1:
> > [???20.607806]??#0: ab23d11c (snd_pcm_link_rwlock){.-..}, at:
> > snd_pcm_stream_lock+0x4c/0x60
> > [???20.615951]?
> > [???20.615951] the shortest dependencies between 2nd lock and 1st
> > lock:
> > [???20.623799]??-> (fs_reclaim){+.+.} ops: 248474 {
> > [???20.628456]?????HARDIRQ-ON-W at:
> > [???20.631716]???????????????????????lock_acquire+0x260/0x29c
> > [???20.637223]???????????????????????fs_reclaim_acquire+0x48/0x58
> > [???20.643075]???????????????????????kmem_cache_alloc_trace+0x3c/0x
> > 36
> > 4
> > [???20.649366]???????????????????????alloc_worker.constprop.15+0x28
> > /0
> > x64
> > [???20.655824]???????????????????????init_rescuer.part.5+0x20/0xa4
> > [???20.661764]???????????????????????workqueue_init+0x124/0x1f8
> > [???20.667446]???????????????????????kernel_init_freeable+0x60/0x55
> > 0
> > [???20.673561]???????????????????????kernel_init+0x18/0x120
> > [???20.678890]???????????????????????ret_from_fork+0x14/0x20
> > [???20.684299]?????????????????????????(null)
> > [???20.688408]?????SOFTIRQ-ON-W at:
> > [???20.691659]???????????????????????lock_acquire+0x260/0x29c
> > [???20.697158]???????????????????????fs_reclaim_acquire+0x48/0x58
> > [???20.703006]???????????????????????kmem_cache_alloc_trace+0x3c/0x
> > 36
> > 4
> > [???20.709288]???????????????????????alloc_worker.constprop.15+0x28
> > /0
> > x64
> > [???20.709301]???????????????????????init_rescuer.part.5+0x20/0xa4
> > [???20.720717]???????????????????????workqueue_init+0x124/0x1f8
> > [???20.720729]???????????????????????kernel_init_freeable+0x60/0x55
> > 0
> > [???20.720738]???????????????????????kernel_init+0x18/0x120
> > [???20.720746]???????????????????????ret_from_fork+0x14/0x20
> > [???20.720751]?????????????????????????(null)
> > [???20.720756]?????INITIAL USE at:
> > [???20.720770]??????????????????????lock_acquire+0x260/0x29c
> > [???20.720782]??????????????????????fs_reclaim_acquire+0x48/0x58
> > [???20.774374]??????????????????????kmem_cache_alloc_trace+0x3c/0x3
> > 64
> > [???20.780574]??????????????????????alloc_worker.constprop.15+0x28/
> > 0x
> > 64
> > [???20.786945]??????????????????????init_rescuer.part.5+0x20/0xa4
> > [???20.792794]??????????????????????workqueue_init+0x124/0x1f8
> > [???20.798384]??????????????????????kernel_init_freeable+0x60/0x550
> > [???20.804406]??????????????????????kernel_init+0x18/0x120
> > [???20.809648]??????????????????????ret_from_fork+0x14/0x20
> > [???20.814971]????????????????????????(null)
> > [???20.818992]???}
> > [???20.820768]???... key??????at: [<80e22074>]
> > __fs_reclaim_map+0x0/0x10
> > [???20.827220]???... acquired at:
> > [???20.830289]????fs_reclaim_acquire+0x48/0x58
> > [???20.834487]????kmem_cache_alloc_trace+0x3c/0x364
> > [???20.839123]????sdma_transfer_init+0x44/0x130
> > [???20.843409]????sdma_prep_dma_cyclic+0x78/0x21c
> > [???20.847869]????snd_dmaengine_pcm_trigger+0xdc/0x184
> > [???20.852764]????soc_pcm_trigger+0x164/0x190
> > [???20.856876]????snd_pcm_do_start+0x34/0x40
> > [???20.860902]????snd_pcm_action_single+0x48/0x74
> > [???20.865360]????snd_pcm_action+0x34/0xfc
> > [???20.869213]????snd_pcm_ioctl+0x910/0x10ec
> > [???20.873241]????vfs_ioctl+0x30/0x44
> > [???20.876657]????do_vfs_ioctl+0xac/0x974
> > [???20.880421]????ksys_ioctl+0x48/0x64
> > [???20.883923]????sys_ioctl+0x18/0x1c
> > [???20.887340]????ret_fast_syscall+0x0/0x28
> > [???20.891277]????0x7289bcbc
> > [???20.893909]?
> > [???20.895410] -> (&(&substream->self_group.lock)->rlock){-...}
> > ops:
> > 59 {
> > [???20.901977]????IN-HARDIRQ-W at:
> > [???20.905143]?????????????????????lock_acquire+0x260/0x29c
> > [???20.910473]?????????????????????_raw_spin_lock+0x48/0x58
> > [???20.915801]?????????????????????snd_pcm_stream_lock+0x54/0x60
> > [???20.921561]?????????????????????_snd_pcm_stream_lock_irqsave+0x4
> > 0/
> > 0x48
> > [???20.928107]?????????????????????snd_pcm_period_elapsed+0x2c/0xa4
> > [???20.934127]?????????????????????dmaengine_pcm_dma_complete+0x54/
> > 0x
> > 58
> > [???20.940498]?????????????????????sdma_int_handler+0x1dc/0x2a8
> > [???20.946179]?????????????????????__handle_irq_event_percpu+0x1fc/
> > 0x
> > 498
> > [???20.952635]?????????????????????handle_irq_event_percpu+0x38/0x8
> > c
> > [???20.958742]?????????????????????handle_irq_event+0x48/0x6c
> > [???20.964242]?????????????????????handle_fasteoi_irq+0xc4/0x138
> > [???20.970006]?????????????????????generic_handle_irq+0x28/0x38
> > [???20.975681]?????????????????????__handle_domain_irq+0xb0/0xc4
> > [???20.981443]?????????????????????gic_handle_irq+0x68/0xa0
> > [???20.986769]?????????????????????__irq_svc+0x70/0xb0
> > [???20.991662]?????????????????????_raw_spin_unlock_irq+0x38/0x6c
> > [???20.997511]?????????????????????task_work_run+0x90/0xb8
> > [???21.002751]?????????????????????do_work_pending+0xc8/0xd0
> > [???21.008164]?????????????????????slow_work_pending+0xc/0x20
> > [???21.013661]?????????????????????0x76c77e86
> > [???21.017768]????INITIAL USE at:
> > [???21.020844]????????????????????lock_acquire+0x260/0x29c
> > [???21.026086]????????????????????_raw_spin_lock+0x48/0x58
> > [???21.031328]????????????????????snd_pcm_stream_lock+0x54/0x60
> > [???21.037002]????????????????????snd_pcm_stream_lock_irq+0x38/0x3c
> > [???21.043023]????????????????????snd_pcm_sync_ptr+0x214/0x260
> > [???21.048609]????????????????????snd_pcm_ioctl+0xbe0/0x10ec
> > [???21.054027]????????????????????vfs_ioctl+0x30/0x44
> > [???21.058832]????????????????????do_vfs_ioctl+0xac/0x974
> > [???21.063984]????????????????????ksys_ioctl+0x48/0x64
> > [???21.068875]????????????????????sys_ioctl+0x18/0x1c
> > [???21.073679]????????????????????ret_fast_syscall+0x0/0x28
> > [???21.079004]????????????????????0x7e9026dc
> > [???21.083023]??}
> > [???21.084710]??... key??????at: [<8162a6e4>] __key.31798+0x0/0x8
> > [???21.090552]??... acquired at:
> > [???21.093537]????mark_lock+0x3a4/0x69c
> > [???21.097128]????__lock_acquire+0x420/0x16d4
> > [???21.101239]????lock_acquire+0x260/0x29c
> > [???21.105091]????_raw_spin_lock+0x48/0x58
> > [???21.108940]????snd_pcm_stream_lock+0x54/0x60
> > [???21.113226]????_snd_pcm_stream_lock_irqsave+0x40/0x48
> > [???21.118296]????snd_pcm_period_elapsed+0x2c/0xa4
> > [???21.122841]????dmaengine_pcm_dma_complete+0x54/0x58
> > [???21.127735]????sdma_int_handler+0x1dc/0x2a8
> > [???21.131937]????__handle_irq_event_percpu+0x1fc/0x498
> > [???21.136915]????handle_irq_event_percpu+0x38/0x8c
> > [???21.141547]????handle_irq_event+0x48/0x6c
> > [???21.145570]????handle_fasteoi_irq+0xc4/0x138
> > [???21.149854]????generic_handle_irq+0x28/0x38
> > [???21.154052]????__handle_domain_irq+0xb0/0xc4
> > [???21.158335]????gic_handle_irq+0x68/0xa0
> > [???21.162184]????__irq_svc+0x70/0xb0
> > [???21.165601]????_raw_spin_unlock_irq+0x38/0x6c
> > [???21.169973]????task_work_run+0x90/0xb8
> > [???21.173735]????do_work_pending+0xc8/0xd0
> > [???21.177670]????slow_work_pending+0xc/0x20
> > [???21.181691]????0x76c77e86
> > [???21.184320]?
> > [???21.185821]?
> > [???21.185821] stack backtrace:
> > [???21.190198] CPU: 0 PID: 1 Comm: systemd Not tainted 4.17.0+
> > #1538
> > [???21.196303] Hardware name: Freescale i.MX6 Quad/DualLite (Device
> > Tree)
> > [???21.202841] Backtrace:?
> > [???21.205314] [<8010e318>] (dump_backtrace) from [<8010e604>]
> > (show_stack+0x20/0x24)
> > [???21.212900]??r7:80e9f3d0 r6:00000000 r5:60070193 r4:80e9f3d0
> > [???21.218581] [<8010e5e4>] (show_stack) from [<8099b660>]
> > (dump_stack+0xa4/0xd8)
> > [???21.225825] [<8099b5bc>] (dump_stack) from [<8017b52c>]
> > (print_irq_inversion_bug+0x15c/0x1fc)
> > [???21.234368]??r9:814da818 r8:00000001 r7:ee926c00 r6:00000000
> > r5:ee915bb0 r4:814da818
> > [???21.242133] [<8017b3d0>] (print_irq_inversion_bug) from
> > [<8017b6dc>] (check_usage_forwards+0x110/0x13c)
> > [???21.251544]??r9:00000002 r8:80bfd3e2 r7:ee926c00 r6:ee927148
> > r5:80e08488 r4:00000001
> > [???21.259306] [<8017b5cc>] (check_usage_forwards) from
> > [<8017c2a4>]
> > (mark_lock+0x3a4/0x69c)
> > [???21.267500]??r9:ee926c00 r8:80a03cd8 r7:00000101 r6:00000002
> > r5:00000000 r4:ee927148
> > [???21.275263] [<8017bf00>] (mark_lock) from [<8017cf68>]
> > (__lock_acquire+0x420/0x16d4)
> > [???21.283023]??r10:ee927148 r9:ed4620e4 r8:ee926c00 r7:00000000
> > r6:00000001 r5:00000001
> > [???21.290863]??r4:00000490
> > [???21.293416] [<8017cb48>] (__lock_acquire) from [<8017ed58>]
> > (lock_acquire+0x260/0x29c)
> > [???21.301350]??r10:00000001 r9:80e084a4 r8:00000000 r7:00000000
> > r6:00000000 r5:ed4620e4
> > [???21.309189]??r4:00000000
> > [???21.311746] [<8017eaf8>] (lock_acquire) from [<809b74f0>]
> > (_raw_spin_lock+0x48/0x58)
> > [???21.319506]??r10:ee0a4714 r9:ed457100 r8:ee0a46c8 r7:ee0a4714
> > r6:ee0a4010 r5:807847b0
> > [???21.327346]??r4:ed4620d4
> > [???21.329902] [<809b74a8>] (_raw_spin_lock) from [<807847b0>]
> > (snd_pcm_stream_lock+0x54/0x60)
> > [???21.338265]??r5:ed462000 r4:ed462000
> > [???21.341863] [<8078475c>] (snd_pcm_stream_lock) from [<80784838>]
> > (_snd_pcm_stream_lock_irqsave+0x40/0x48)
> > [???21.351440]??r5:ed462000 r4:60070193
> > [???21.355042] [<807847f8>] (_snd_pcm_stream_lock_irqsave) from
> > [<8078b044>] (snd_pcm_period_elapsed+0x2c/0xa4)
> > [???21.364881]??r5:ee3ef000 r4:ed462000
> > [???21.368478] [<8078b018>] (snd_pcm_period_elapsed) from
> > [<8078d7b4>] (dmaengine_pcm_dma_complete+0x54/0x58)
> > [???21.378148]??r7:ee0a4714 r6:ee0a4010 r5:00000007 r4:ee0a46bc
> > [???21.383827] [<8078d760>] (dmaengine_pcm_dma_complete) from
> > [<80504c0c>] (sdma_int_handler+0x1dc/0x2a8)
> > [???21.393157] [<80504a30>] (sdma_int_handler) from [<8018cd28>]
> > (__handle_irq_event_percpu+0x1fc/0x498)
> > [???21.402393]??r10:00000000 r9:eeafd400 r8:80e084a4 r7:00000038
> > r6:00000038 r5:80ea3c12
> > [???21.410233]??r4:ee2b5d40
> > [???21.412787] [<8018cb2c>] (__handle_irq_event_percpu) from
> > [<8018cffc>] (handle_irq_event_percpu+0x38/0x8c)
> > [???21.422457]??r10:00000000 r9:ee914000 r8:ee81d400 r7:00000038
> > r6:eeafd400 r5:eeafd464
> > [???21.430296]??r4:80e08488
> > [???21.432852] [<8018cfc4>] (handle_irq_event_percpu) from
> > [<8018d098>] (handle_irq_event+0x48/0x6c)
> > [???21.441736]??r6:eeafd464 r5:eeafd464 r4:eeafd400
> > [???21.446374] [<8018d050>] (handle_irq_event) from [<8019146c>]
> > (handle_fasteoi_irq+0xc4/0x138)
> > [???21.454912]??r7:00000038 r6:eeafd464 r5:80e10a60 r4:eeafd400
> > [???21.460589] [<801913a8>] (handle_fasteoi_irq) from [<8018bd9c>]
> > (generic_handle_irq+0x28/0x38)
> > [???21.469214]??r7:00000038 r6:80d92ae4 r5:00000000 r4:00000000
> > [???21.474893] [<8018bd74>] (generic_handle_irq) from [<8018c48c>]
> > (__handle_domain_irq+0xb0/0xc4)
> > [???21.483611] [<8018c3dc>] (__handle_domain_irq) from [<80102330>]
> > (gic_handle_irq+0x68/0xa0)
> > [???21.491978]??r9:ee914000 r8:f4001100 r7:80e5c6bc r6:ee915f00
> > r5:80e08c3c r4:f4000100
> > [???21.499738] [<801022c8>] (gic_handle_irq) from [<801019f0>]
> > (__irq_svc+0x70/0xb0)
> > [???21.507233] Exception stack(0xee915f00 to 0xee915f48)
> > [???21.512303] 5f00: 00000001 00000004 00000000 ee926c00 ee9270a8
> > ee926c00 ecc45e00 ee9270a8
> > [???21.520498] 5f20: 80ec23b0 ee914000 00000000 ee915f64 ee915f20
> > ee915f50 8017c7c0 809b78ac
> > [???21.528687] 5f40: 20070013 ffffffff
> > [???21.532193]??r9:ee914000 r8:80ec23b0 r7:ee915f34 r6:ffffffff
> > r5:20070013 r4:809b78ac
> > [???21.539959] [<809b7874>] (_raw_spin_unlock_irq) from
> > [<8014e98c>]
> > (task_work_run+0x90/0xb8)
> > [???21.548321]??r5:ee926c00 r4:ecc45e00
> > [???21.551913] [<8014e8fc>] (task_work_run) from [<8010da3c>]
> > (do_work_pending+0xc8/0xd0)
> > [???21.559848]??r9:ee914000 r8:801011c4 r7:ee915fb0 r6:ffffe000
> > r5:00000004 r4:801011c4
> > [???21.567608] [<8010d974>] (do_work_pending) from [<80101034>]
> > (slow_work_pending+0xc/0x20)
> > [???21.575797] Exception stack(0xee915fb0 to 0xee915ff8)
> > [???21.580864] 5fa0:?????????????????????????????????????00000000
> > 020c34e8 46059f00 00000000
> > [???21.589059] 5fc0: 00000002 76f133a4 020df680 00000006 76e6e168
> > 00000035 7ef81778 00000035
> > [???21.597253] 5fe0: 00000006 7ef816a0 76c75d67 76c77e86 20070030
> > 00000039
> > [???21.603883]??r7:00000006 r6:020df680 r5:76f133a4 r4:00000002
> >
> > Am Donnerstag, den 14.06.2018, 22:02 +0800 schrieb Robin Gong:
> > >
> > > The legacy sdma driver has below limitations or drawbacks:
> > > ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and
> > > alloc
> > > ?????one page size for one channel regardless of only few BDs
> > > needed
> > > ?????most time. But in few cases, the max PAGE_SIZE maybe not
> > > enough.
> > > ? 2. One SDMA channel can't stop immediatley once channel
> > > disabled
> > > which
> > > ?????means SDMA interrupt may come in after this channel
> > > terminated.There
> > > ?????are some patches for this corner case such as commit
> > > "2746e2c389f9",
> > > ?????but not cover non-cyclic.
> > >
> > > The common virt-dma overcomes the above limitations. It can alloc
> > > bd
> > > dynamically and free bd once this tx transfer done. No memory
> > > wasted or
> > > maximum limititation here, only depends on how many memory can be
> > > requested
> > > from kernel. For No.2, such issue can be workaround by checking
> > > if
> > > there
> > > is available descript("sdmac->desc") now once the unwanted
> > > interrupt
> > > coming. At last the common virt-dma is easier for sdma driver
> > > maintain.
> > >
> > > Change from v3:
> > > ? 1. add two uart patches which impacted by this patchset.
> > > ? 2. unlock 'vc.lock' before cyclic dma callback and lock again
> > > after
> > > ?????it because some driver such as uart will call
> > > dmaengine_tx_status
> > > ?????which will acquire 'vc.lock' again and dead lock comes out.
> > > ? 3. remove 'Revert commit' stuff since that patch is not wrong
> > > and
> > > ?????combine two patch into one patch as Sascha's comment.
> > >
> > > Change from v2:
> > > ? 1. include Sascha's patch to make the main patch easier to
> > > review.
> > > ?????Thanks Sacha.
> > > ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
> > >
> > > Change from v1:
> > > ? 1. split v1 patch into 5 patches.
> > > ? 2. remove some unnecessary condition check.
> > > ? 3. remove unnecessary 'pending' list.
> > >
> > > Robin Gong (6):
> > > ? tty: serial: imx: correct dma cookie status
> > > ? dmaengine: imx-sdma: add virt-dma support
> > > ? dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in
> > > 'struct
> > > ????sdma_channel'
> > > ? dmaengine: imx-sdma: remove the maximum limitation for bd
> > > numbers
> > > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > > overlap
> > > ? tty: serial: imx: split all dma setup operations out of
> > > 'port.lock'
> > > ????protector
> > >
> > > Sascha Hauer (1):
> > > ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> > > ????sdma_channel
> > >
> > > ?drivers/dma/Kconfig??????|???1 +
> > > ?drivers/dma/imx-sdma.c???| 394 +++++++++++++++++++++++++++------
> > > --------------
> > > ?drivers/tty/serial/imx.c |??99 ++++++------
> > > ?3 files changed, 282 insertions(+), 212 deletions(-)
^ permalink raw reply
* [PATCH v1 4/4] mailbox: Add support for i.MX7D messaging unit
From: Oleksij Rempel @ 2018-06-14 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA+hA=RpoRXUK+jB18F4OeYE9PG73SDa_NLYeN5Q2G3B1bC-JA@mail.gmail.com>
On Wed, Jun 13, 2018 at 08:21:10PM +0800, Dong Aisheng wrote:
> Hi Oleksij,
>
> On Fri, Jun 1, 2018 at 2:58 PM, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> > The Mailbox controller is able to send messages (up to 4 32 bit words)
> > between the endpoints.
>
> Could we really be able to send up to 4 42bit words with this driver?
>
> It looks to me the current Mailbox framework is more designed for share mem
> transfer which does not fit i.MX MU well.
It is possible to set mbox_chan_txdone as soon as one of 4 regs is
written. Even more, it looks like, it should be possible to make a 8
channel mailbox on top of one MU. But i don't have any reason or use
case to implement and test it now.
> >
> > This driver was tested using the mailbox-test driver sending messages
> > between the Cortex-A7 and the Cortex-M4.
>
> Would you please provide a guide on how to test it quickly?
> I may want to give a test.
I use Linux on both side. The linux on M4 is booted over remoteproc.
Currently not all needed parts are upstream. I'll prepare a BSP to build
all components as soon as possible.
>
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > drivers/mailbox/Kconfig | 6 +
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/imx-mailbox.c | 289 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 297 insertions(+)
> > create mode 100644 drivers/mailbox/imx-mailbox.c
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> > index a2bb27446dce..e1d2738a2e4c 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,12 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config IMX_MBOX
> > + tristate "iMX Mailbox"
> > + depends on SOC_IMX7D || COMPILE_TEST
> > + help
> > + Mailbox implementation for iMX7D Messaging Unit (MU).
> > +
> > config PLATFORM_MHU
> > tristate "Platform MHU Mailbox"
> > depends on OF
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> > index cc23c3a43fcd..ba2fe1b6dd62 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> > +
> > obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
> >
> > obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
> > diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> > new file mode 100644
> > index 000000000000..2bc9f11393b1
> > --- /dev/null
> > +++ b/drivers/mailbox/imx-mailbox.c
> > @@ -0,0 +1,289 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 Pengutronix, Oleksij Rempel <o.rempel@pengutronix.de>
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/io.h>
> > +#include <linux/kernel.h>
> > +#include <linux/mailbox_controller.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +
> > +/* Transmit Register */
> > +#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> > +/* Receive Register */
> > +#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> > +/* Status Register */
> > +#define IMX_MU_xSR 0x20
> > +#define IMX_MU_xSR_TEn(x) BIT(20 + (x))
> > +#define IMX_MU_xSR_RFn(x) BIT(24 + (x))
> > +#define IMX_MU_xSR_BRDIP BIT(9)
> > +
> > +/* Control Register */
> > +#define IMX_MU_xCR 0x24
> > +/* Transmit Interrupt Enable */
> > +#define IMX_MU_xCR_TIEn(x) BIT(20 + (x))
> > +/* Receive Interrupt Enable */
> > +#define IMX_MU_xCR_RIEn(x) BIT(24 + (x))
> > +
> > +#define IMX_MU_MAX_CHANS 4u
> > +
> > +struct imx_mu_priv;
> > +
> > +struct imx_mu_cfg {
> > + unsigned int chans;
> > + void (*init_hw)(struct imx_mu_priv *priv);
> > +};
> > +
> > +struct imx_mu_con_priv {
> > + int irq;
> > + unsigned int bidx;
> > + unsigned int idx;
> > +};
> > +
> > +struct imx_mu_priv {
> > + struct device *dev;
> > + const struct imx_mu_cfg *dcfg;
> > + void __iomem *base;
> > +
> > + struct mbox_controller mbox;
> > + struct mbox_chan mbox_chans[IMX_MU_MAX_CHANS];
> > +
> > + struct imx_mu_con_priv con_priv[IMX_MU_MAX_CHANS];
> > + struct clk *clk;
> > +};
> > +
> > +static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
> > +{
> > + return container_of(mbox, struct imx_mu_priv, mbox);
> > +}
> > +
> > +static void imx_mu_write(struct imx_mu_priv *priv, u32 val, u32 offs)
> > +{
> > + iowrite32(val, priv->base + offs);
> > +}
> > +
> > +static u32 imx_mu_read(struct imx_mu_priv *priv, u32 offs)
> > +{
> > + return ioread32(priv->base + offs);
> > +}
> > +
> > +static u32 imx_mu_rmw(struct imx_mu_priv *priv, u32 offs, u32 set, u32 clr)
> > +{
> > + u32 val;
> > +
> > + val = imx_mu_read(priv, offs);
> > + val &= ~clr;
> > + val |= set;
> > + imx_mu_write(priv, val, offs);
> > +
> > + return val;
> > +}
> > +
> > +static irqreturn_t imx_mu_isr(int irq, void *p)
> > +{
> > + struct mbox_chan *chan = p;
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>
> Please do in reversed order from long to short
done
> > +
> > + u32 val, dat;
> > +
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + val &= IMX_MU_xSR_TEn(cp->bidx) | IMX_MU_xSR_RFn(cp->bidx);
> > + if (!val)
> > + return IRQ_NONE;
> > +
> > + if (val & IMX_MU_xSR_TEn(cp->bidx)) {
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0, IMX_MU_xCR_TIEn(cp->bidx));
> > + mbox_chan_txdone(chan, 0);
> > + }
> > +
> > + if (val & IMX_MU_xSR_RFn(cp->bidx)) {
> > + dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
> > + mbox_chan_received_data(chan, (void *)&dat);
> > + }
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static bool imx_mu_last_tx_done(struct mbox_chan *chan)
> > +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val;
> > +
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + /* test if transmit register is empty */
> > + return (!(val & IMX_MU_xSR_TEn(cp->bidx)));
> > +}
> > +
> > +static int imx_mu_send_data(struct mbox_chan *chan, void *data)
> > +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 *arg = data;
> > +
> > + if (imx_mu_last_tx_done(chan))
>
> return true for tx_done?
> Or maybe better imx_mu_is_busy?
I'll the name and rework the logic. For polling, if this will be ever
used.
> > + return -EBUSY;
> > +
> > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->bidx), 0);
> > +
> > + return 0;
> > +}
> > +
> > +static int imx_mu_startup(struct mbox_chan *chan)
> > +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> > +
> > + ret = request_irq(cp->irq, imx_mu_isr,
> > + IRQF_SHARED, "imx_mu_chan", chan);
>
> This looks me to a bit strange as all virtual channels interrupts
> line actually are the same. And we request that same irq line
> repeatedly here with the same irq handler.
Why not? Code is simple and performance should not be noticeable.
> > + if (ret) {
> > + dev_err(chan->mbox->dev,
> > + "Unable to acquire IRQ %d\n", cp->irq);
> > + return ret;
> > + }
> > +
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xCR_RIEn(cp->bidx), 0);
> > +
> > + return 0;
> > +}
> > +
> > +static void imx_mu_shutdown(struct mbox_chan *chan)
> > +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > +
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0,
> > + IMX_MU_xCR_TIEn(cp->bidx) | IMX_MU_xCR_RIEn(cp->bidx));
> > +
> > + free_irq(cp->irq, chan);
> > +}
> > +
> > +static const struct mbox_chan_ops imx_mu_ops = {
> > + .send_data = imx_mu_send_data,
> > + .startup = imx_mu_startup,
> > + .shutdown = imx_mu_shutdown,
> > + .last_tx_done = imx_mu_last_tx_done,
>
> Do we really need this?
> Looking at the code, it seems .last_tx_done() is only called for polling mode.
> But what you set below is:
> priv->mbox.txdone_irq = true;
>
> Or am i missed something?
no. I'll remove it for now.
>
> > +};
> > +
> > +static int imx_mu_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct resource *iomem;
> > + struct imx_mu_priv *priv;
> > + const struct imx_mu_cfg *dcfg;
> > + unsigned int i, chans;
> > + int irq, ret;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + dcfg = of_device_get_match_data(dev);
> > + if (!dcfg)
> > + return -EINVAL;
> > +
> > + priv->dcfg = dcfg;
> > + priv->dev = dev;
> > +
> > + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + priv->base = devm_ioremap_resource(&pdev->dev, iomem);
> > + if (IS_ERR(priv->base))
> > + return PTR_ERR(priv->base);
> > +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq <= 0)
> > + return irq < 0 ? irq : -EINVAL;
>
> Is it possible == 0?
no:
https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L86
or do I miss some thing?
> > +
> > + priv->clk = devm_clk_get(dev, NULL);
> > + if (IS_ERR(priv->clk)) {
> > + if (PTR_ERR(priv->clk) == -ENOENT) {
> > + priv->clk = NULL;
> > + } else {
> > + dev_err(dev, "Failed to get clock\n");
>
> The line looks not be quite meaningful as it may be defer probe.
What is your suggestion?
> > + return PTR_ERR(priv->clk);
> > + }
> > + }
> > +
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock\n");
> > + return ret;
> > + }
> > +
> > + chans = min(dcfg->chans, IMX_MU_MAX_CHANS);
> > + /* Initialize channel identifiers */
> > + for (i = 0; i < chans; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> > +
> > + cp->bidx = 3 - i;
> > + cp->idx = i;
> > + cp->irq = irq;
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> > +
> > + priv->mbox.dev = dev;
> > + priv->mbox.ops = &imx_mu_ops;
> > + priv->mbox.chans = priv->mbox_chans;
> > + priv->mbox.num_chans = chans;
> > + priv->mbox.txdone_irq = true;
> > +
> > + platform_set_drvdata(pdev, priv);
> > +
> > + if (priv->dcfg->init_hw)
> > + priv->dcfg->init_hw(priv);
> > +
> > + return mbox_controller_register(&priv->mbox);
> > +}
> > +
> > +static int imx_mu_remove(struct platform_device *pdev)
> > +{
> > + struct imx_mu_priv *priv = platform_get_drvdata(pdev);
> > +
> > + mbox_controller_unregister(&priv->mbox);
> > + clk_disable_unprepare(priv->clk);
> > +
> > + return 0;
> > +}
> > +
> > +
> > +static void imx_mu_init_imx7d_a(struct imx_mu_priv *priv)
> > +{
> > + /* Set default config */
> > + imx_mu_write(priv, 0, IMX_MU_xCR);
> > +}
> > +
> > +static const struct imx_mu_cfg imx_mu_cfg_imx7d_a = {
> > + .chans = IMX_MU_MAX_CHANS,
> > + .init_hw = imx_mu_init_imx7d_a,
> > +};
> > +
> > +static const struct imx_mu_cfg imx_mu_cfg_imx7d_b = {
> > + .chans = IMX_MU_MAX_CHANS,
> > +};
> > +
> > +static const struct of_device_id imx_mu_dt_ids[] = {
> > + { .compatible = "fsl,imx7s-mu-a", .data = &imx_mu_cfg_imx7d_a },
> > + { .compatible = "fsl,imx7s-mu-b", .data = &imx_mu_cfg_imx7d_b },
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
> > +
> > +static struct platform_driver imx_mu_driver = {
> > + .probe = imx_mu_probe,
> > + .remove = imx_mu_remove,
> > + .driver = {
> > + .name = "imx_mu",
> > + .of_match_table = imx_mu_dt_ids,
> > + },
> > +};
> > +module_platform_driver(imx_mu_driver);
> > +
> > +MODULE_AUTHOR("Oleksij Rempel <o.rempel@pengutronix.de>");
> > +MODULE_DESCRIPTION("Message Unit driver for i.MX7");
>
> s/i.MX7/i.MX
ok
> Regards
> Dong Aisheng
thank you for review.
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180614/00022757/attachment.sig>
^ permalink raw reply
* [PATCH v1] ARM: dts: imx6sx: fix irq for pcie bridge
From: Lucas Stach @ 2018-06-14 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614094527.25905-1-o.rempel@pengutronix.de>
Am Donnerstag, den 14.06.2018, 11:45 +0200 schrieb Oleksij Rempel:
> Without this patch MSI interrupts are not routed from Intel
> i350 PCIe adapter.
This has nothing to do with the attached endpoint device, so the commit
message should read something like:
Use the correct IRQ line for the MSI controller in the PCIe host
controller. Apparently a different IRQ line is used compared to other
i.MX6 variants. Without this change MSI IRQs aren't properly propagated
to the the upstream interrupt controller.
With this fixed:
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> ?arch/arm/boot/dts/imx6sx.dtsi | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 49c7205b8db8..77fdad65e2bb 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -1351,7 +1351,7 @@
> > ? ranges = <0x81000000 0 0??????????0x08f80000 0 0x00010000 /* downstream I/O */
> > ? ??0x82000000 0 0x08000000 0x08000000 0 0x00f00000>; /* non-prefetchable memory */
> > ? num-lanes = <1>;
> > - interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
> > ? interrupt-names = "msi";
> > ? #interrupt-cells = <1>;
> > ? interrupt-map-mask = <0 0 0 0x7>;
^ permalink raw reply
* [PATCH v3 0/6] thermal: tsens: Refactoring for TSENSv2 IP
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
To: linux-arm-kernel
This series is a mixed bag: Some code moves to deal with v2 of the
TSENS IP into common functions, a new qcom,tsens-v2 DT property to cover
all v2 platforms, new platform support (sdm845), a cleanup
patch and a DT change to have a common way to deal with the SROT and TM
registers despite slightly different features across the IP family and
different register offsets.
Rob, I haven't added your Ack to patch 4 because it changed a bit.
Regards,
Amit
Changes since v2:
- Based on review, moved tsens-8996.c to tsens-v2.c and changed
corresponding function names, struct names to allow for generic tsensv2
platforms
- All v2 platforms will now only need to use the qcom,tsen-v2 property
- Added a DT patch to initialize tsens driver on sdm845, now that 4.18-rc1
will contain an sdm845.dtsi
Changes since v1:
- Move get_temp() from tsens-8996 to tsens-common and rename
- Change 8996 DT entry to allow init_common() to work across sdm845 and
8996 due to different offsets
Amit Kucheria (6):
thermal: tsens: Get rid of unused fields in structure
dt: qcom: 8996: thermal: Move to DT initialisation
thermal: tsens: Rename tsens-8996 to tsens-v2 for reuse
thermal: tsens: Add support for SDM845
thermal: tsens: Check if we have valid data before reading
arm64: dts: sdm845: Add tsens nodes
.../devicetree/bindings/thermal/qcom-tsens.txt | 1 +
arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 ++++++-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 16 +++++++++
drivers/thermal/qcom/Makefile | 2 +-
drivers/thermal/qcom/{tsens-8996.c => tsens-v2.c} | 42 +++++++++++++---------
drivers/thermal/qcom/tsens.c | 3 ++
drivers/thermal/qcom/tsens.h | 7 ++--
7 files changed, 61 insertions(+), 22 deletions(-)
rename drivers/thermal/qcom/{tsens-8996.c => tsens-v2.c} (65%)
--
2.7.4
^ permalink raw reply
* [PATCH v3 2/6] dt: qcom: 8996: thermal: Move to DT initialisation
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>
We also split up the regmap address space into two, one for the TM
registers, the other for the SROT registers. This was required to deal with
different address offsets for the TM and SROT registers across different
SoC families.
Since tsens-common.c/init_common() currently only registers one address
space, the order is important (TM before SROT). This is OK since the code
doesn't really use the SROT functionality yet.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 8c7f9ca..6c8a857 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -461,7 +461,17 @@
tsens0: thermal-sensor at 4a8000 {
compatible = "qcom,msm8996-tsens";
- reg = <0x4a8000 0x2000>;
+ reg = <0x4a9000 0x1000>, /* TM */
+ <0x4a8000 0x1000>; /* SROT */
+ #qcom,sensors = <13>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: thermal-sensor at 4ac000 {
+ compatible = "qcom,msm8996-tsens";
+ reg = <0x4ad000 0x1000>, /* TM */
+ <0x4ac000 0x1000>; /* SROT */
+ #qcom,sensors = <8>;
#thermal-sensor-cells = <1>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/6] thermal: tsens: Add support for SDM845
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>
SDM845 uses the TSENS v2 IP block
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
Documentation/devicetree/bindings/thermal/qcom-tsens.txt | 1 +
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
drivers/thermal/qcom/tsens-v2.c | 9 ++++++++-
drivers/thermal/qcom/tsens.c | 3 +++
drivers/thermal/qcom/tsens.h | 5 ++++-
5 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
index 06195e8..84da3db 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
@@ -5,6 +5,7 @@ Required properties:
- "qcom,msm8916-tsens" : For 8916 Family of SoCs
- "qcom,msm8974-tsens" : For 8974 Family of SoCs
- "qcom,msm8996-tsens" : For 8996 Family of SoCs
+ - "qcom,tsens-v2" : For any SoC with v2 version of the tsens IP
- reg: Address range of the thermal registers
- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 6c8a857..28d4c08 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -460,7 +460,7 @@
};
tsens0: thermal-sensor at 4a8000 {
- compatible = "qcom,msm8996-tsens";
+ compatible = "qcom,msm8996-tsens", "qcom,tsens-v2";
reg = <0x4a9000 0x1000>, /* TM */
<0x4a8000 0x1000>; /* SROT */
#qcom,sensors = <13>;
diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
index c981a40..abc8f13 100644
--- a/drivers/thermal/qcom/tsens-v2.c
+++ b/drivers/thermal/qcom/tsens-v2.c
@@ -69,8 +69,15 @@ static const struct tsens_ops ops_v2 = {
.get_temp = get_temp_tsens_v2,
};
+const struct tsens_data data_tsens_v2 = {
+ .ops = &ops_v2,
+};
+
+/* Kept around for backward compatibility with old msm8996.dtsi.
+ * New platforms should use data_tsens_v2 if possible and define
+ * the #qcom,sensors property in DT.
+ */
const struct tsens_data data_8996 = {
.num_sensors = 13,
.ops = &ops_v2,
};
-
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index 3440166c..a2c9bfa 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -72,6 +72,9 @@ static const struct of_device_id tsens_table[] = {
}, {
.compatible = "qcom,msm8996-tsens",
.data = &data_8996,
+ }, {
+ .compatible = "qcom,tsens-v2",
+ .data = &data_tsens_v2,
},
{}
};
diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
index dc56e1e..69212cb 100644
--- a/drivers/thermal/qcom/tsens.h
+++ b/drivers/thermal/qcom/tsens.h
@@ -87,6 +87,9 @@ void compute_intercept_slope(struct tsens_device *, u32 *, u32 *, u32);
int init_common(struct tsens_device *);
int get_temp_common(struct tsens_device *, int, int *);
-extern const struct tsens_data data_8916, data_8974, data_8960, data_8996;
+/* TSENS v1 targets */
+extern const struct tsens_data data_8916, data_8974, data_8960;
+/* TSENS v2 targets */
+extern const struct tsens_data data_8996, data_tsens_v2;
#endif /* __QCOM_TSENS_H__ */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 6/6] arm64: dts: sdm845: Add tsens nodes
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>
SDM845 has two tsens blocks, one with 13 sensors and the other with 8
sensors.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cdaabeb..7dd59b4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -221,6 +221,22 @@
#interrupt-cells = <2>;
};
+ tsens0: tsens at c222000 {
+ compatible = "qcom,tsens-v2";
+ reg = <0xc263000 0x1ff>, /* TM */
+ <0xc222000 0x1ff>; /* SROT */
+ #qcom,sensors = <13>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: tsens at c223000 {
+ compatible = "qcom,tsens-v2";
+ reg = <0xc265000 0x1ff>, /* TM */
+ <0xc223000 0x1ff>; /* SROT */
+ #qcom,sensors = <8>;
+ #thermal-sensor-cells = <1>;
+ };
+
spmi_bus: spmi at c440000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0xc440000 0x1100>,
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/3] Renesas R9A06G032 SMP enabler
From: Michel Pollet @ 2018-06-14 10:58 UTC (permalink / raw)
To: linux-arm-kernel
*WARNING -- this requires the base R9A06G032 support patches
already posted
This patch series is for enabling the second CA7 of the R9A06G032.
It's based on a spin_table method, and it reuses the same binding
property as that driver.
v5:
+ Fixed a couple of typos
+ Added the Reviewed-by tags where appropriate
+ Rebased on base patch v9
+ Replaced the dts property with a 64 bits one.
+ Changed the driver to support 32 or 64 bits property.
v4:
+ Geert's comments adressed.
+ Renamed symbols to r9a06g032 to match the rest of patchset
+ Rebased on base patch v8
v3:
+ Removed mentions of rz/?n1d?
+ Rebased on base patch v7
v2:
+ Added suggestions from Florian Fainelli
+ Use __pa_symbol()
+ Simplified logic in prepare_cpu()
+ Reordered the patches
+ Rebased on RZN1 Base patch v5
Michel Pollet (3):
dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
arm: shmobile: Add the R9A06G032 SMP enabler driver
ARM: dts: Renesas R9A06G032 SMP enable method
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/boot/dts/r9a06g032.dtsi | 2 +
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 90 ++++++++++++++++++++++++++
4 files changed, 94 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
--
2.7.4
^ permalink raw reply
* [PATCH v5 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
From: Michel Pollet @ 2018-06-14 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528973943-28132-1-git-send-email-michel.pollet@bp.renesas.com>
Add a special enable method for second CA7 of the R9A06G032
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 29e1dc5..b395d107 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -219,6 +219,7 @@ described below.
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
"renesas,apmu"
+ "renesas,r9a06g032-smp"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Michel Pollet @ 2018-06-14 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528973943-28132-1-git-send-email-michel.pollet@bp.renesas.com>
The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it
requires a special enable method to get it started.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 90 ++++++++++++++++++++++++++++++++++
2 files changed, 91 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 1939f52..d7fc98f 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
+smp-$(CONFIG_ARCH_R9A06G032) += smp-r9a06g032.o
smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
# PM objects
diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c b/arch/arm/mach-shmobile/smp-r9a06g032.c
new file mode 100644
index 0000000..882a838
--- /dev/null
+++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * R9A06G032 Second CA7 enabler.
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
+ * Derived from actions,s500-smp
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/smp.h>
+
+/*
+ * The second CPU is parked in ROM at boot time. It requires waking it after
+ * writing an address into the BOOTADDR register of sysctrl.
+ *
+ * So the default value of the "cpu-release-addr" corresponds to BOOTADDR...
+ *
+ * *However* the BOOTADDR register is not available when the kernel
+ * starts in NONSEC mode.
+ *
+ * So for NONSEC mode, the bootloader re-parks the second CPU into a pen
+ * in SRAM, and changes the "cpu-release-addr" of linux's DT to a SRAM address,
+ * which is not restricted.
+ */
+
+static void __iomem *cpu_bootaddr;
+
+static DEFINE_SPINLOCK(cpu_lock);
+
+static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ if (!cpu_bootaddr)
+ return -ENODEV;
+
+ spin_lock(&cpu_lock);
+
+ writel(__pa_symbol(secondary_startup), cpu_bootaddr);
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+ spin_unlock(&cpu_lock);
+
+ return 0;
+}
+
+static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *dn;
+ int ret = -EINVAL, dns;
+ u32 bootaddr;
+
+ dn = of_get_cpu_node(1, NULL);
+ if (!dn) {
+ pr_err("CPU#1: missing device tree node\n");
+ return;
+ }
+ /*
+ * Determine the address from which the CPU is polling.
+ * The bootloader *does* change this property.
+ * Note: The property can be either 64 or 32 bits, so handle both cases
+ */
+ if (of_find_property(dn, "cpu-release-addr", &dns)) {
+ if (dns == sizeof(u64)) {
+ u64 temp;
+ ret = of_property_read_u64(dn,
+ "cpu-release-addr", &temp);
+ bootaddr = temp;
+ } else
+ ret = of_property_read_u32(dn,
+ "cpu-release-addr", &bootaddr);
+ }
+ of_node_put(dn);
+ if (ret) {
+ pr_err("CPU#1: invalid cpu-release-addr property\n");
+ return;
+ }
+ pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
+
+ cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
+}
+
+static const struct smp_operations r9a06g032_smp_ops __initconst = {
+ .smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
+ .smp_boot_secondary = r9a06g032_smp_boot_secondary,
+};
+CPU_METHOD_OF_DECLARE(r9a06g032_smp,
+ "renesas,r9a06g032-smp", &r9a06g032_smp_ops);
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/3] ARM: dts: Renesas R9A06G032 SMP enable method
From: Michel Pollet @ 2018-06-14 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528973943-28132-1-git-send-email-michel.pollet@bp.renesas.com>
Add a special enable method for the second CA7 of the R9A06G032
as well as the default value for the "cpu-release-addr" property.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r9a06g032.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 353e06f..3e45375 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -30,6 +30,8 @@
compatible = "arm,cortex-a7";
reg = <1>;
clocks = <&sysctrl R9A06G032_CLK_A7MP>;
+ enable-method = "renesas,r9a06g032-smp";
+ cpu-release-addr = <0 0x4000c204>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Alexandre Belloni @ 2018-06-14 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614090733.GV10521@piout.net>
On 14/06/2018 11:07:33+0200, Alexandre Belloni wrote:
> Hi,
>
> On 14/06/2018 09:51:54+0100, Ben Whitten wrote:
>
> This need a proper commit message. Maybe you can also add a link to the
> technical brief for the platform?
>
> > Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> > ---
> > arch/arm/boot/dts/Makefile | 3 +-
> > arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
> > arch/arm/boot/dts/at91-wb45n.dtsi | 169 ++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 237 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
> > create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 7e24249..1ee94ee 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
> > at91sam9g25ek.dtb \
> > at91sam9g35ek.dtb \
> > at91sam9x25ek.dtb \
> > - at91sam9x35ek.dtb
> > + at91sam9x35ek.dtb \
> > + at91-wb45n.dtb
>
> The proper name for the file is <soc>-board.dtb so this should be
> at91sam9g25-wb45n.dtb.
>
Nicolas tells me that the name was right, please disregard my comment
(also on the other patches).
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 0/4] arm64: dts: rockchip: add RK3399-Gru-Bob and prepare for Scarlet
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
So far the Gru series of ChromeOS devices has seen 3 public devices.
Two clamshell devices with the already supported Kevin and Bob
(aka Chromebook Flip C101PA), as well as one table-style device Scarlet.
So this series not only adds a devicetree file for Bob, but also prepares
for Scarlets arrival, in that common properties of the clamshell-devices
get moved into a rk3399-gru-chromebook.dtsi, similar to what we have on
RK3288-Veyron, as Scarlet does some things a bit differently.
Scarlet itself needs a bit more time, as its display is connected via
dual-dsi, where the patches are still pending.
Heiko Stuebner (4):
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate
file
arm64: dts: rockchip: add phandles to some nodes on rk3399-gru
arm64: dts: rockchip: move core edp from rk3399-kevin to shared
chromebook
arm64: dts: rockchip: add Google Bob
.../devicetree/bindings/arm/rockchip.txt | 9 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-gru-bob.dts | 79 ++++
.../dts/rockchip/rk3399-gru-chromebook.dtsi | 399 ++++++++++++++++++
.../boot/dts/rockchip/rk3399-gru-kevin.dts | 47 +--
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 328 +-------------
6 files changed, 496 insertions(+), 367 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
--
2.17.0
^ permalink raw reply
* [PATCH 1/4] arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614113039.29117-1-heiko@sntech.de>
Similar to rk3288-Veyron before, the Gru-series does contain Chromebook
(aka clamshell laptops) and non-Chromebook devices. And while the two
Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet-
device is quite different in its design.
Therefore move the Chromebook parts into a gru-chromebook dtsi file
to make sharing easier.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../dts/rockchip/rk3399-gru-chromebook.dtsi | 365 ++++++++++++++++++
.../boot/dts/rockchip/rk3399-gru-kevin.dts | 8 +-
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 322 ---------------
3 files changed, 366 insertions(+), 329 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
new file mode 100644
index 000000000000..32139e6910a3
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Gru-Chromebook shared properties
+ *
+ * Copyright 2018 Google, Inc
+ */
+
+#include "rk3399-gru.dtsi"
+
+/ {
+ pp900_ap: pp900-ap {
+ compatible = "regulator-fixed";
+ regulator-name = "pp900_ap";
+
+ /* EC turns on w/ pp900_ap_en; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ vin-supply = <&ppvar_sys>;
+ };
+
+ /* EC turns on w/ pp900_usb_en */
+ pp900_usb: pp900-ap {
+ };
+
+ /* EC turns on w/ pp900_pcie_en */
+ pp900_pcie: pp900-ap {
+ };
+
+ pp3000: pp3000 {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3000";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pp3000_en>;
+
+ enable-active-high;
+ gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+
+ vin-supply = <&ppvar_sys>;
+ };
+
+ ppvar_centerlogic_pwm: ppvar-centerlogic-pwm {
+ compatible = "pwm-regulator";
+ regulator-name = "ppvar_centerlogic_pwm";
+
+ pwms = <&pwm3 0 3337 0>;
+ pwm-supply = <&ppvar_sys>;
+ pwm-dutycycle-range = <100 0>;
+ pwm-dutycycle-unit = <100>;
+
+ /* EC turns on w/ ppvar_centerlogic_en; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <799434>;
+ regulator-max-microvolt = <1049925>;
+ };
+
+ ppvar_centerlogic: ppvar-centerlogic {
+ compatible = "vctrl-regulator";
+ regulator-name = "ppvar_centerlogic";
+
+ regulator-min-microvolt = <799434>;
+ regulator-max-microvolt = <1049925>;
+
+ ctrl-supply = <&ppvar_centerlogic_pwm>;
+ ctrl-voltage-range = <799434 1049925>;
+
+ regulator-settling-time-up-us = <378>;
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+ };
+
+ /* Schematics call this PPVAR even though it's fixed */
+ ppvar_logic: ppvar-logic {
+ compatible = "regulator-fixed";
+ regulator-name = "ppvar_logic";
+
+ /* EC turns on w/ ppvar_logic_en; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ vin-supply = <&ppvar_sys>;
+ };
+
+ pp1800_audio: pp1800-audio {
+ compatible = "regulator-fixed";
+ regulator-name = "pp1800_audio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pp1800_audio_en>;
+
+ enable-active-high;
+ gpio = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+
+ regulator-always-on;
+ regulator-boot-on;
+
+ vin-supply = <&pp1800>;
+ };
+
+ /* gpio is shared with pp3300_wifi_bt */
+ pp1800_pcie: pp1800-pcie {
+ compatible = "regulator-fixed";
+ regulator-name = "pp1800_pcie";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_module_pd_l>;
+
+ enable-active-high;
+ gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+
+ /*
+ * Need to wait 1ms + ramp-up time before we can power on WiFi.
+ * This has been approximated as 8ms total.
+ */
+ regulator-enable-ramp-delay = <8000>;
+
+ vin-supply = <&pp1800>;
+ };
+
+ /* Always on; plain and simple */
+ pp3000_ap: pp3000_emmc: pp3000 {
+ };
+
+ pp1500_ap_io: pp1500-ap-io {
+ compatible = "regulator-fixed";
+ regulator-name = "pp1500_ap_io";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pp1500_en>;
+
+ enable-active-high;
+ gpio = <&gpio0 10 GPIO_ACTIVE_HIGH>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+
+ vin-supply = <&pp1800>;
+ };
+
+ pp3300_disp: pp3300-disp {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_disp";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pp3300_disp_en>;
+
+ enable-active-high;
+ gpio = <&gpio4 27 GPIO_ACTIVE_HIGH>;
+
+ startup-delay-us = <2000>;
+ vin-supply = <&pp3300>;
+ };
+
+ /* EC turns on w/ pp3300_usb_en_l */
+ pp3300_usb: pp3300 {
+ };
+
+ /* gpio is shared with pp1800_pcie and pinctrl is set there */
+ pp3300_wifi_bt: pp3300-wifi-bt {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_wifi_bt";
+
+ enable-active-high;
+ gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+
+ vin-supply = <&pp3300>;
+ };
+
+ /*
+ * This is a bit of a hack. The WiFi module should be reset at least
+ * 1ms after its regulators have ramped up (max rampup time is ~7ms).
+ * With some stretching of the imagination, we can call the 1.8V
+ * regulator a supply.
+ */
+ wlan_pd_n: wlan-pd-n {
+ compatible = "regulator-fixed";
+ regulator-name = "wlan_pd_n";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_module_reset_l>;
+
+ enable-active-high;
+ gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+
+ vin-supply = <&pp1800_pcie>;
+ };
+};
+
+&ppvar_bigcpu {
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+};
+
+&ppvar_litcpu {
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+};
+
+&ppvar_gpu {
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+};
+
+&cdn_dp {
+ extcon = <&usbc_extcon0>, <&usbc_extcon1>;
+};
+
+ap_i2c_mic: &i2c1 {
+ status = "okay";
+
+ clock-frequency = <400000>;
+
+ /* These are relatively safe rise/fall times */
+ i2c-scl-falling-time-ns = <50>;
+ i2c-scl-rising-time-ns = <300>;
+
+ headsetcodec: rt5514 at 57 {
+ compatible = "realtek,rt5514";
+ reg = <0x57>;
+ realtek,dmic-init-delay-ms = <20>;
+ };
+};
+
+ap_i2c_tp: &i2c5 {
+ status = "okay";
+
+ clock-frequency = <400000>;
+
+ /* These are relatively safe rise/fall times */
+ i2c-scl-falling-time-ns = <50>;
+ i2c-scl-rising-time-ns = <300>;
+
+ /*
+ * Note strange pullup enable. Apparently this avoids leakage but
+ * still allows us to get nice 4.7K pullups for high speed i2c
+ * transfers. Basically we want the pullup on whenever the ap is
+ * alive, so the "en" pin just gets set to output high.
+ */
+ pinctrl-0 = <&i2c5_xfer &ap_i2c_tp_pu_en>;
+};
+
+&cros_ec {
+ cros_ec_pwm: ec-pwm {
+ compatible = "google,cros-ec-pwm";
+ #pwm-cells = <1>;
+ };
+
+ usbc_extcon1: extcon at 1 {
+ compatible = "google,extcon-usbc-cros-ec";
+ google,usb-port-id = <1>;
+
+ #extcon-cells = <0>;
+ };
+};
+
+&sound {
+ rockchip,codec = <&max98357a &headsetcodec
+ &codec &wacky_spi_audio &cdn_dp>;
+};
+
+&spi2 {
+ wacky_spi_audio: spi2 at 0 {
+ compatible = "realtek,rt5514";
+ reg = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mic_int>;
+ /* May run faster once verified. */
+ spi-max-frequency = <10000000>;
+ wakeup-source;
+ };
+};
+
+&pci_rootport {
+ mvl_wifi: wifi at 0,0 {
+ compatible = "pci1b4b,2b42";
+ reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
+ 0x83010000 0x0 0x00100000 0x0 0x00100000>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_host_wake_l>;
+ wakeup-source;
+ };
+};
+
+&tcphy1 {
+ status = "okay";
+ extcon = <&usbc_extcon1>;
+};
+
+&u2phy1 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usbdrd3_1 {
+ status = "okay";
+ extcon = <&usbc_extcon1>;
+};
+
+&usbdrd_dwc3_1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&pinctrl {
+ discrete-regulators {
+ pp1500_en: pp1500-en {
+ rockchip,pins = <RK_GPIO0 10 RK_FUNC_GPIO
+ &pcfg_pull_none>;
+ };
+
+ pp1800_audio_en: pp1800-audio-en {
+ rockchip,pins = <RK_GPIO0 2 RK_FUNC_GPIO
+ &pcfg_pull_down>;
+ };
+
+ pp3000_en: pp3000-en {
+ rockchip,pins = <RK_GPIO0 12 RK_FUNC_GPIO
+ &pcfg_pull_none>;
+ };
+
+ pp3300_disp_en: pp3300-disp-en {
+ rockchip,pins = <RK_GPIO4 27 RK_FUNC_GPIO
+ &pcfg_pull_none>;
+ };
+
+ wlan_module_pd_l: wlan-module-pd-l {
+ rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO
+ &pcfg_pull_down>;
+ };
+ };
+};
+
+&wifi {
+ wifi_perst_l: wifi-perst-l {
+ rockchip,pins = <2 27 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wlan_host_wake_l: wlan-host-wake-l {
+ rockchip,pins = <0 8 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 356c4d71c95b..e582ec9fbc97 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -6,7 +6,7 @@
*/
/dts-v1/;
-#include "rk3399-gru.dtsi"
+#include "rk3399-gru-chromebook.dtsi"
#include <dt-bindings/input/linux-event-codes.h>
/*
@@ -337,10 +337,4 @@ ap_i2c_dig: &i2c2 {
rockchip,pins = <0 13 RK_FUNC_GPIO &pcfg_pull_up>;
};
};
-
- wifi {
- wlan_host_wake_l: wlan-host-wake-l {
- rockchip,pins = <0 8 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index e2a60680c66c..614b4f198cc0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -45,19 +45,6 @@
regulator-boot-on;
};
- pp900_ap: pp900-ap {
- compatible = "regulator-fixed";
- regulator-name = "pp900_ap";
-
- /* EC turns on w/ pp900_ap_en; always on for AP */
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <900000>;
-
- vin-supply = <&ppvar_sys>;
- };
-
pp1200_lpddr: pp1200-lpddr {
compatible = "regulator-fixed";
regulator-name = "pp1200_lpddr";
@@ -84,23 +71,6 @@
vin-supply = <&ppvar_sys>;
};
- pp3000: pp3000 {
- compatible = "regulator-fixed";
- regulator-name = "pp3000";
- pinctrl-names = "default";
- pinctrl-0 = <&pp3000_en>;
-
- enable-active-high;
- gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
-
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
-
- vin-supply = <&ppvar_sys>;
- };
-
pp3300: pp3300 {
compatible = "regulator-fixed";
regulator-name = "pp3300";
@@ -154,8 +124,6 @@
ctrl-voltage-range = <800107 1302232>;
regulator-settling-time-up-us = <322>;
- min-slew-down-rate = <225>;
- ovp-threshold-percent = <16>;
};
ppvar_litcpu_pwm: ppvar-litcpu-pwm {
@@ -185,8 +153,6 @@
ctrl-voltage-range = <797743 1307837>;
regulator-settling-time-up-us = <384>;
- min-slew-down-rate = <225>;
- ovp-threshold-percent = <16>;
};
ppvar_gpu_pwm: ppvar-gpu-pwm {
@@ -216,63 +182,12 @@
ctrl-voltage-range = <786384 1217747>;
regulator-settling-time-up-us = <390>;
- min-slew-down-rate = <225>;
- ovp-threshold-percent = <16>;
- };
-
- ppvar_centerlogic_pwm: ppvar-centerlogic-pwm {
- compatible = "pwm-regulator";
- regulator-name = "ppvar_centerlogic_pwm";
-
- pwms = <&pwm3 0 3337 0>;
- pwm-supply = <&ppvar_sys>;
- pwm-dutycycle-range = <100 0>;
- pwm-dutycycle-unit = <100>;
-
- /* EC turns on w/ ppvar_centerlogic_en; always on for AP */
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <799434>;
- regulator-max-microvolt = <1049925>;
- };
-
- ppvar_centerlogic: ppvar-centerlogic {
- compatible = "vctrl-regulator";
- regulator-name = "ppvar_centerlogic";
-
- regulator-min-microvolt = <799434>;
- regulator-max-microvolt = <1049925>;
-
- ctrl-supply = <&ppvar_centerlogic_pwm>;
- ctrl-voltage-range = <799434 1049925>;
-
- regulator-settling-time-up-us = <378>;
- min-slew-down-rate = <225>;
- ovp-threshold-percent = <16>;
- };
-
- /* Schematics call this PPVAR even though it's fixed */
- ppvar_logic: ppvar-logic {
- compatible = "regulator-fixed";
- regulator-name = "ppvar_logic";
-
- /* EC turns on w/ ppvar_logic_en; always on for AP */
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <900000>;
-
- vin-supply = <&ppvar_sys>;
};
/* EC turns on w/ pp900_ddrpll_en */
pp900_ddrpll: pp900-ap {
};
- /* EC turns on w/ pp900_pcie_en */
- pp900_pcie: pp900-ap {
- };
-
/* EC turns on w/ pp900_pll_en */
pp900_pll: pp900-ap {
};
@@ -281,10 +196,6 @@
pp900_pmu: pp900-ap {
};
- /* EC turns on w/ pp900_usb_en */
- pp900_usb: pp900-ap {
- };
-
/* EC turns on w/ pp1800_s0_en_l */
pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: pp1800 {
};
@@ -309,79 +220,6 @@
pp1800_usb: pp1800 {
};
- pp1500_ap_io: pp1500-ap-io {
- compatible = "regulator-fixed";
- regulator-name = "pp1500_ap_io";
- pinctrl-names = "default";
- pinctrl-0 = <&pp1500_en>;
-
- enable-active-high;
- gpio = <&gpio0 10 GPIO_ACTIVE_HIGH>;
-
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <1500000>;
-
- vin-supply = <&pp1800>;
- };
-
- pp1800_audio: pp1800-audio {
- compatible = "regulator-fixed";
- regulator-name = "pp1800_audio";
- pinctrl-names = "default";
- pinctrl-0 = <&pp1800_audio_en>;
-
- enable-active-high;
- gpio = <&gpio0 2 GPIO_ACTIVE_HIGH>;
-
- regulator-always-on;
- regulator-boot-on;
-
- vin-supply = <&pp1800>;
- };
-
- /* gpio is shared with pp3300_wifi_bt */
- pp1800_pcie: pp1800-pcie {
- compatible = "regulator-fixed";
- regulator-name = "pp1800_pcie";
- pinctrl-names = "default";
- pinctrl-0 = <&wlan_module_pd_l>;
-
- enable-active-high;
- gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
-
- /*
- * Need to wait 1ms + ramp-up time before we can power on WiFi.
- * This has been approximated as 8ms total.
- */
- regulator-enable-ramp-delay = <8000>;
-
- vin-supply = <&pp1800>;
- };
-
- /*
- * This is a bit of a hack. The WiFi module should be reset at least
- * 1ms after its regulators have ramped up (max rampup time is ~7ms).
- * With some stretching of the imagination, we can call the 1.8V
- * regulator a supply.
- */
- wlan_pd_n: wlan-pd-n {
- compatible = "regulator-fixed";
- regulator-name = "wlan_pd_n";
- pinctrl-names = "default";
- pinctrl-0 = <&wlan_module_reset_l>;
-
- enable-active-high;
- gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>;
-
- vin-supply = <&pp1800_pcie>;
- };
-
- /* Always on; plain and simple */
- pp3000_ap: pp3000_emmc: pp3000 {
- };
-
pp3000_sd_slot: pp3000-sd-slot {
compatible = "regulator-fixed";
regulator-name = "pp3000_sd_slot";
@@ -420,34 +258,6 @@
pp3300_trackpad: pp3300-trackpad {
};
- /* EC turns on w/ pp3300_usb_en_l */
- pp3300_usb: pp3300 {
- };
-
- pp3300_disp: pp3300-disp {
- compatible = "regulator-fixed";
- regulator-name = "pp3300_disp";
- pinctrl-names = "default";
- pinctrl-0 = <&pp3300_disp_en>;
-
- enable-active-high;
- gpio = <&gpio4 27 GPIO_ACTIVE_HIGH>;
-
- startup-delay-us = <2000>;
- vin-supply = <&pp3300>;
- };
-
- /* gpio is shared with pp1800_pcie and pinctrl is set there */
- pp3300_wifi_bt: pp3300-wifi-bt {
- compatible = "regulator-fixed";
- regulator-name = "pp3300_wifi_bt";
-
- enable-active-high;
- gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
-
- vin-supply = <&pp3300>;
- };
-
/* EC turns on w/ usb_a_en */
pp5000_usb_a_vbus: pp5000 {
};
@@ -478,14 +288,11 @@
sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = <&i2s0 &i2s2>;
- rockchip,codec = <&max98357a &headsetcodec
- &codec &wacky_spi_audio &cdn_dp>;
};
};
&cdn_dp {
status = "okay";
- extcon = <&usbc_extcon0>, <&usbc_extcon1>;
};
/*
@@ -576,22 +383,6 @@
status = "okay";
};
-ap_i2c_mic: &i2c1 {
- status = "okay";
-
- clock-frequency = <400000>;
-
- /* These are relatively safe rise/fall times */
- i2c-scl-falling-time-ns = <50>;
- i2c-scl-rising-time-ns = <300>;
-
- headsetcodec: rt5514 at 57 {
- compatible = "realtek,rt5514";
- reg = <0x57>;
- realtek,dmic-init-delay-ms = <20>;
- };
-};
-
ap_i2c_ts: &i2c3 {
status = "okay";
@@ -602,24 +393,6 @@ ap_i2c_ts: &i2c3 {
i2c-scl-rising-time-ns = <300>;
};
-ap_i2c_tp: &i2c5 {
- status = "okay";
-
- clock-frequency = <400000>;
-
- /* These are relatively safe rise/fall times */
- i2c-scl-falling-time-ns = <50>;
- i2c-scl-rising-time-ns = <300>;
-
- /*
- * Note strange pullup enable. Apparently this avoids leakage but
- * still allows us to get nice 4.7K pullups for high speed i2c
- * transfers. Basically we want the pullup on whenever the ap is
- * alive, so the "en" pin just gets set to output high.
- */
- pinctrl-0 = <&i2c5_xfer &ap_i2c_tp_pu_en>;
-};
-
ap_i2c_audio: &i2c8 {
status = "okay";
@@ -693,17 +466,6 @@ ap_i2c_audio: &i2c8 {
#address-cells = <3>;
#size-cells = <2>;
ranges;
-
- mvl_wifi: wifi at 0,0 {
- compatible = "pci1b4b,2b42";
- reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
- 0x83010000 0x0 0x00100000 0x0 0x00100000>;
- interrupt-parent = <&gpio0>;
- interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&wlan_host_wake_l>;
- wakeup-source;
- };
};
};
@@ -793,18 +555,6 @@ ap_i2c_audio: &i2c8 {
&spi2 {
status = "okay";
-
- wacky_spi_audio: spi2 at 0 {
- compatible = "realtek,rt5514";
- reg = <0>;
- interrupt-parent = <&gpio1>;
- interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&mic_int>;
- /* May run faster once verified. */
- spi-max-frequency = <10000000>;
- wakeup-source;
- };
};
&spi5 {
@@ -826,24 +576,12 @@ ap_i2c_audio: &i2c8 {
#size-cells = <0>;
};
- cros_ec_pwm: ec-pwm {
- compatible = "google,cros-ec-pwm";
- #pwm-cells = <1>;
- };
-
usbc_extcon0: extcon at 0 {
compatible = "google,extcon-usbc-cros-ec";
google,usb-port-id = <0>;
#extcon-cells = <0>;
};
-
- usbc_extcon1: extcon at 1 {
- compatible = "google,extcon-usbc-cros-ec";
- google,usb-port-id = <1>;
-
- #extcon-cells = <0>;
- };
};
};
@@ -859,19 +597,10 @@ ap_i2c_audio: &i2c8 {
extcon = <&usbc_extcon0>;
};
-&tcphy1 {
- status = "okay";
- extcon = <&usbc_extcon1>;
-};
-
&u2phy0 {
status = "okay";
};
-&u2phy1 {
- status = "okay";
-};
-
&u2phy0_host {
status = "okay";
};
@@ -892,22 +621,10 @@ ap_i2c_audio: &i2c8 {
status = "okay";
};
-&usb_host0_ehci {
- status = "okay";
-};
-
&usb_host0_ohci {
status = "okay";
};
-&usb_host1_ehci {
- status = "okay";
-};
-
-&usb_host1_ohci {
- status = "okay";
-};
-
&usbdrd3_0 {
status = "okay";
extcon = <&usbc_extcon0>;
@@ -918,16 +635,6 @@ ap_i2c_audio: &i2c8 {
dr_mode = "host";
};
-&usbdrd3_1 {
- status = "okay";
- extcon = <&usbc_extcon1>;
-};
-
-&usbdrd_dwc3_1 {
- status = "okay";
- dr_mode = "host";
-};
-
&vopb {
status = "okay";
};
@@ -986,26 +693,6 @@ ap_i2c_audio: &i2c8 {
};
discrete-regulators {
- pp1500_en: pp1500-en {
- rockchip,pins = <RK_GPIO0 10 RK_FUNC_GPIO
- &pcfg_pull_none>;
- };
-
- pp1800_audio_en: pp1800-audio-en {
- rockchip,pins = <RK_GPIO0 2 RK_FUNC_GPIO
- &pcfg_pull_down>;
- };
-
- pp3300_disp_en: pp3300-disp-en {
- rockchip,pins = <RK_GPIO4 27 RK_FUNC_GPIO
- &pcfg_pull_none>;
- };
-
- pp3000_en: pp3000-en {
- rockchip,pins = <RK_GPIO0 12 RK_FUNC_GPIO
- &pcfg_pull_none>;
- };
-
sd_io_pwr_en: sd-io-pwr-en {
rockchip,pins = <RK_GPIO2 2 RK_FUNC_GPIO
&pcfg_pull_none>;
@@ -1020,11 +707,6 @@ ap_i2c_audio: &i2c8 {
rockchip,pins = <RK_GPIO4 29 RK_FUNC_GPIO
&pcfg_pull_none>;
};
-
- wlan_module_pd_l: wlan-module-pd-l {
- rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO
- &pcfg_pull_down>;
- };
};
codec {
@@ -1132,10 +814,6 @@ ap_i2c_audio: &i2c8 {
};
wifi {
- wifi_perst_l: wifi-perst-l {
- rockchip,pins = <2 27 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
wlan_module_reset_l: wlan-module-reset-l {
rockchip,pins = <1 11 RK_FUNC_GPIO &pcfg_pull_none>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: rockchip: add phandles to some nodes on rk3399-gru
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614113039.29117-1-heiko@sntech.de>
Some nodes will need to be refined on a per board level, so add phandles
to them to reference them later.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 614b4f198cc0..ca07f6032200 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -267,7 +267,7 @@
pinctrl-names = "default";
pinctrl-0 = <&bt_host_wake_l>;
- wake-on-bt {
+ wake_on_bt: wake-on-bt {
label = "Wake-on-Bluetooth";
gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
linux,code = <KEY_WAKEUP>;
@@ -285,7 +285,7 @@
status = "okay";
};
- sound {
+ sound: sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = <&i2s0 &i2s2>;
};
@@ -813,7 +813,7 @@ ap_i2c_audio: &i2c8 {
};
};
- wifi {
+ wifi: wifi {
wlan_module_reset_l: wlan-module-reset-l {
rockchip,pins = <1 11 RK_FUNC_GPIO &pcfg_pull_none>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: rockchip: move core edp from rk3399-kevin to shared chromebook
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614113039.29117-1-heiko@sntech.de>
Bob needs the same backlight and core edp settings, so move these node to
the shared dtsi that both will use as a base.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../dts/rockchip/rk3399-gru-chromebook.dtsi | 34 ++++++++++++++++
.../boot/dts/rockchip/rk3399-gru-kevin.dts | 39 ++-----------------
2 files changed, 38 insertions(+), 35 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
index 32139e6910a3..8cce0f59d2ea 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -191,6 +191,23 @@
vin-supply = <&pp1800_pcie>;
};
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+ 17 18 19 20 21 22 23 24 25 26 27 28 29 30
+ 31 32 33 34 35 36 37 38 39 40 41 42 43 44
+ 45 46 47 48 49 50 51 52 53 54 55 56 57 58
+ 59 60 61 62 63 64 65 66 67 68 69 70 71 72
+ 73 74 75 76 77 78 79 80 81 82 83 84 85 86
+ 87 88 89 90 91 92 93 94 95 96 97 98 99 100>;
+ default-brightness-level = <51>;
+ enable-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+ power-supply = <&pp3300_disp>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bl_en>;
+ pwm-delay-us = <10000>;
+ };
};
&ppvar_bigcpu {
@@ -212,6 +229,23 @@
extcon = <&usbc_extcon0>, <&usbc_extcon1>;
};
+&edp {
+ status = "okay";
+
+ ports {
+ edp_out: port at 1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_out_panel: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+};
+
ap_i2c_mic: &i2c1 {
status = "okay";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index e582ec9fbc97..2cc7c47d6a85 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -38,24 +38,6 @@
vin-supply = <&pp3300>;
};
- backlight: backlight {
- compatible = "pwm-backlight";
- pwms = <&cros_ec_pwm 1>;
- brightness-levels = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
- 17 18 19 20 21 22 23 24 25 26 27 28 29 30
- 31 32 33 34 35 36 37 38 39 40 41 42 43 44
- 45 46 47 48 49 50 51 52 53 54 55 56 57 58
- 59 60 61 62 63 64 65 66 67 68 69 70 71 72
- 73 74 75 76 77 78 79 80 81 82 83 84 85 86
- 87 88 89 90 91 92 93 94 95 96 97 98 99 100>;
- default-brightness-level = <51>;
- enable-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
- power-supply = <&pp3300_disp>;
- pinctrl-names = "default";
- pinctrl-0 = <&bl_en>;
- pwm-delay-us = <10000>;
- };
-
edp_panel: edp-panel {
compatible = "sharp,lq123p1jx31", "simple-panel";
backlight = <&backlight>;
@@ -87,6 +69,10 @@
};
};
+&backlight {
+ pwms = <&cros_ec_pwm 1>;
+};
+
&gpio_keys {
pinctrl-names = "default";
pinctrl-0 = <&bt_host_wake_l>, <&cpu1_pen_eject>;
@@ -243,23 +229,6 @@ ap_i2c_dig: &i2c2 {
};
};
-&edp {
- status = "okay";
-
- ports {
- edp_out: port at 1 {
- reg = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- edp_out_panel: endpoint at 0 {
- reg = <0>;
- remote-endpoint = <&panel_in_edp>;
- };
- };
- };
-};
-
&ppvar_bigcpu_pwm {
regulator-min-microvolt = <798674>;
regulator-max-microvolt = <1302172>;
--
2.17.0
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: rockchip: add Google Bob
From: Heiko Stuebner @ 2018-06-14 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614113039.29117-1-heiko@sntech.de>
After Kevin, the second chromebook-incarnation of the Gru series is Bob.
This materializes as the Asus Chromebook Flip C101PA, whose formfactor
is quite similar to Minnie from the Veyron series.
Add the devicetree file and binding update for it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../devicetree/bindings/arm/rockchip.txt | 9 +++
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-gru-bob.dts | 79 +++++++++++++++++++
3 files changed, 89 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 1c1d62d03c4f..145ab0b0a030 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -66,6 +66,15 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "geekbuying,geekbox", "rockchip,rk3368";
+- Google Bob (Asus Chromebook Flip C101PA):
+ Required root node properties:
+ compatible = "google,bob-rev13", "google,bob-rev12",
+ "google,bob-rev11", "google,bob-rev10",
+ "google,bob-rev9", "google,bob-rev8",
+ "google,bob-rev7", "google,bob-rev6",
+ "google,bob-rev5", "google,bob-rev4",
+ "google,bob", "google,gru", "rockchip,rk3399";
+
- Google Brain (dev-board):
Required root node properties:
- compatible = "google,veyron-brain-rev0", "google,veyron-brain",
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 48a83f882947..7c4311eac700 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -10,6 +10,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-bob.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts
new file mode 100644
index 000000000000..1ee0dc0d9f10
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Gru-Bob Rev 4+ board device tree source
+ *
+ * Copyright 2018 Google, Inc
+ */
+
+/dts-v1/;
+#include "rk3399-gru-chromebook.dtsi"
+
+/ {
+ model = "Google Bob";
+ compatible = "google,bob-rev13", "google,bob-rev12",
+ "google,bob-rev11", "google,bob-rev10",
+ "google,bob-rev9", "google,bob-rev8",
+ "google,bob-rev7", "google,bob-rev6",
+ "google,bob-rev5", "google,bob-rev4",
+ "google,bob", "google,gru", "rockchip,rk3399";
+
+ edp_panel: edp-panel {
+ compatible = "boe,nv101wxmn51", "simple-panel";
+ backlight = <&backlight>;
+ power-supply = <&pp3300_disp>;
+
+ ports {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&edp_out_panel>;
+ };
+ };
+ };
+};
+
+&ap_i2c_ts {
+ touchscreen: touchscreen at 10 {
+ compatible = "elan,ekth3500";
+ reg = <0x10>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&touch_int_l &touch_reset_l>;
+ reset-gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&ap_i2c_tp {
+ trackpad: trackpad at 15 {
+ compatible = "elan,ekth3000";
+ reg = <0x15>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&trackpad_int_l>;
+ wakeup-source;
+ };
+};
+
+&backlight {
+ pwms = <&cros_ec_pwm 0>;
+};
+
+&cpu_alert0 {
+ temperature = <65000>;
+};
+
+&cpu_alert1 {
+ temperature = <70000>;
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&pinctrl {
+ tpm {
+ h1_int_od_l: h1-int-od-l {
+ rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
--
2.17.0
^ permalink raw reply related
* [PATCH 0/4] KVM: arm64: FPSIMD/SVE fixes for 4.17
From: Dave Martin @ 2018-06-14 11:33 UTC (permalink / raw)
To: linux-arm-kernel
This series contains fixes for some issues observed since the KVM arm64
pull request for 4.17.
The first patch (from Mark Rutland) adds a straightforward helper to
modify particular bits in a system register conditionally. This is used
by patch 3 (though obviously it could be coded round and patch 1
dropped, if preferred).
See other patches for details of the individual fixes.
Dave Martin (3):
KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
KVM: arm64/sve: Fix SVE trap restoration for non-current tasks
KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
Mark Rutland (1):
arm64: introduce sysreg_clear_set()
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/sysreg.h | 11 ++++++++++
arch/arm64/kvm/fpsimd.c | 46 +++++++++++++++++++++++++++++----------
3 files changed, 47 insertions(+), 11 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/4] arm64: introduce sysreg_clear_set()
From: Dave Martin @ 2018-06-14 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976039-25826-1-git-send-email-Dave.Martin@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
Currently we have a couple of helpers to manipulate bits in particular
sysregs:
* config_sctlr_el1(u32 clear, u32 set)
* change_cpacr(u64 val, u64 mask)
The parameters of these differ in naming convention, order, and size,
which is unfortunate. They also differ slightly in behaviour, as
change_cpacr() skips the sysreg write if the bits are unchanged, which
is a useful optimization when sysreg writes are expensive.
Before we gain more yet another sysreg manipulation function, let's
unify these with a common helper, providing a consistent order for
clear/set operands, and the write skipping behaviour from
change_cpacr(). Code will be migrated to the new helper in subsequent
patches.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/sysreg.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 6171178..a8f8481 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -728,6 +728,17 @@ asm(
asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
} while (0)
+/*
+ * Modify bits in a sysreg. Bits in the clear mask are zeroed, then bits in the
+ * set mask are set. Other bits are left as-is.
+ */
+#define sysreg_clear_set(sysreg, clear, set) do { \
+ u64 __scs_val = read_sysreg(sysreg); \
+ u64 __scs_new = (__scs_val & ~(u64)(clear)) | (set); \
+ if (__scs_new != __scs_val) \
+ write_sysreg(__scs_new, sysreg); \
+} while (0)
+
static inline void config_sctlr_el1(u32 clear, u32 set)
{
u32 val;
--
2.1.4
^ permalink raw reply related
* [PATCH 2/4] KVM: arm64: Don't mask softirq with IRQs disabled in vcpu_put()
From: Dave Martin @ 2018-06-14 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976546-25999-1-git-send-email-Dave.Martin@arm.com>
Commit e6b673b ("KVM: arm64: Optimise FPSIMD handling to reduce
guest/host thrashing") introduces a specific helper
kvm_arch_vcpu_put_fp() for saving the vcpu FPSIMD state during
vcpu_put().
This function uses local_bh_disable()/_enable() to protect the
FPSIMD context manipulation from interruption by softirqs.
This approach is not correct, because vcpu_put() can be invoked
either from the KVM host vcpu thread (when exiting the vcpu run
loop), or via a preempt notifier. In the former case, only
preemption is disabled. In the latter case, the function is called
from inside __schedule(), which means that IRQs are disabled.
Use of local_bh_disable()/_enable() with IRQs disabled is considerd
an error, resulting in lockdep splats while running VMs if lockdep
is enabled.
It is probably possible in theory to relax this restriction on
local_bh_disable()/_enable() usage, but for now this patch takes
the simple approach of managing softirq masking only if IRQs happen
to be enabled when kvm_arch_vcpu_put_fp() is called.
Fixes: e6b673b741ea ("KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing")
Reported-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kvm/fpsimd.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index dc6ecfa..b51ff80 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -90,10 +90,8 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
* disappears and another task or vcpu appears that recycles the same
* struct fpsimd_state.
*/
-void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
+static void __kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
{
- local_bh_disable();
-
update_thread_flag(TIF_SVE,
vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
@@ -105,6 +103,16 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
/* Ensure user trap controls are correctly restored */
fpsimd_bind_task_to_cpu();
}
+}
+
- local_bh_enable();
+void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
+{
+ if (irqs_disabled())
+ __kvm_arch_vcpu_put_fp(vcpu);
+ else {
+ local_bh_disable();
+ __kvm_arch_vcpu_put_fp(vcpu);
+ local_bh_enable();
+ }
}
--
2.1.4
^ permalink raw reply related
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