* Re: [PATCH] KVM: PPC: Book3S HV: Treat TM-related invalid form instructions on P9 like the valid ones
From: Leonardo Bras @ 2020-02-20 17:51 UTC (permalink / raw)
To: Gustavo Romero, kvm-ppc, paulus; +Cc: mikey, linuxppc-dev
In-Reply-To: <20200218211324.23045-1-gromero@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]
Hello Gustavo, comments inline:
On Tue, 2020-02-18 at 16:13 -0500, Gustavo Romero wrote:
<SNIP>
> diff --git a/arch/powerpc/kvm/book3s_hv_tm.c b/arch/powerpc/kvm/book3s_hv_tm.c
> index 0db937497169..cc90b8b82329 100644
> --- a/arch/powerpc/kvm/book3s_hv_tm.c
> +++ b/arch/powerpc/kvm/book3s_hv_tm.c
> @@ -3,6 +3,8 @@
> * Copyright 2017 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
Could not see where is this used.
> #include <linux/kvm_host.h>
>
> #include <asm/kvm_ppc.h>
> @@ -44,7 +46,18 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
> u64 newmsr, bescr;
> int ra, rs;
>
> - switch (instr & 0xfc0007ff) {
> + /*
> + * rfid, rfebb, and mtmsrd encode bit 31 = 0 since it's a reserved bit
> + * in these instructions, so masking bit 31 out doesn't change these
> + * instructions. For treclaim., tsr., and trechkpt. instructions if bit
> + * 31 = 0 then they are per ISA invalid forms, however P9 UM, in section
> + * 4.6.10 Book II Invalid Forms, informs specifically that ignoring bit
> + * 31 is an acceptable way to handle these invalid forms that have
> + * bit 31 = 0. Moreover, for emulation purposes both forms (w/ and wo/
> + * bit 31 set) can generate a softpatch interrupt. Hence both forms
> + * are handled below for these instructions so they behave the same way.
> + */
> + switch (instr & PO_XOP_OPCODE_MASK) {
>
<SNIP>
> - case PPC_INST_TRECHKPT:
> + /* ignore bit 31, see comment above */
> + case (PPC_INST_TRECHKPT & PO_XOP_OPCODE_MASK):
> /* XXX do we need to check for PR=0 here? */
> /* check for TM disabled in the HFSCR or MSR */
> if (!(vcpu->arch.hfscr & HFSCR_TM)) {
> @@ -208,6 +224,8 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
> }
>
Seems good, using the same flag to mask out bit 31 of these macros.
They are used only in a few places, and I think removing the macro bit
would be ok, but I think your way is better to keep it documented.
I just noticed that there is a similar function that uses PPC_INST_TSR:
kvmhv_p9_tm_emulation_early @ arch/powerpc/kvm/book3s_hv_tm_builtin.c.
Wouldn't it need to be changed as well?
> /* What should we do here? We didn't recognize the instruction */
> - WARN_ON_ONCE(1);
> + kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
> + pr_warn_ratelimited("Unrecognized TM-related instruction %#x for emulation", instr);
> +
> return RESUME_GUEST;
> }
I suppose this is the right thing to do, but I think it would be better
to give this change it's own patch.
What do you think?
Best regards,
Leonardo Bras
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 5/7] tty: serial: fsl_lpuart: add LS1028A support
From: Michael Walle @ 2020-02-20 17:43 UTC (permalink / raw)
To: linux-serial, devicetree, linux-kernel, linux-arm-kernel
Cc: Mark Rutland, Peng Fan, Greg Kroah-Hartman, Li Yang,
Michael Walle, Rob Herring, Yuan Yao, Vabhav Sharma, Jiri Slaby,
Shawn Guo
In-Reply-To: <20200220174334.23322-1-michael@walle.cc>
The LS1028A uses little endian register access and has a different FIFO
size encoding.
Signed-off-by: Michael Walle <michael@walle.cc>
---
drivers/tty/serial/fsl_lpuart.c | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index fd9f60d0817a..6953eea166dc 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -234,6 +234,7 @@ static DEFINE_IDA(fsl_lpuart_ida);
enum lpuart_type {
VF610_LPUART,
LS1021A_LPUART,
+ LS1028A_LPUART,
IMX7ULP_LPUART,
IMX8QXP_LPUART,
};
@@ -278,11 +279,16 @@ static const struct lpuart_soc_data vf_data = {
.iotype = UPIO_MEM,
};
-static const struct lpuart_soc_data ls_data = {
+static const struct lpuart_soc_data ls1021a_data = {
.devtype = LS1021A_LPUART,
.iotype = UPIO_MEM32BE,
};
+static const struct lpuart_soc_data ls1028a_data = {
+ .devtype = LS1028A_LPUART,
+ .iotype = UPIO_MEM32,
+};
+
static struct lpuart_soc_data imx7ulp_data = {
.devtype = IMX7ULP_LPUART,
.iotype = UPIO_MEM32,
@@ -297,7 +303,8 @@ static struct lpuart_soc_data imx8qxp_data = {
static const struct of_device_id lpuart_dt_ids[] = {
{ .compatible = "fsl,vf610-lpuart", .data = &vf_data, },
- { .compatible = "fsl,ls1021a-lpuart", .data = &ls_data, },
+ { .compatible = "fsl,ls1021a-lpuart", .data = &ls1021a_data, },
+ { .compatible = "fsl,ls1028a-lpuart", .data = &ls1028a_data, },
{ .compatible = "fsl,imx7ulp-lpuart", .data = &imx7ulp_data, },
{ .compatible = "fsl,imx8qxp-lpuart", .data = &imx8qxp_data, },
{ /* sentinel */ }
@@ -307,6 +314,11 @@ MODULE_DEVICE_TABLE(of, lpuart_dt_ids);
/* Forward declare this for the dma callbacks*/
static void lpuart_dma_tx_complete(void *arg);
+static inline bool is_ls1028a_lpuart(struct lpuart_port *sport)
+{
+ return sport->devtype == LS1028A_LPUART;
+}
+
static inline bool is_imx8qxp_lpuart(struct lpuart_port *sport)
{
return sport->devtype == IMX8QXP_LPUART;
@@ -1589,6 +1601,17 @@ static int lpuart32_startup(struct uart_port *port)
spin_lock_irqsave(&sport->port.lock, flags);
+ /*
+ * The LS1028A has a fixed length of 16 words. Although it supports the
+ * RX/TXSIZE fields their encoding is different. Eg the reference manual
+ * states 0b101 is 16 words.
+ */
+ if (is_ls1028a_lpuart(sport)) {
+ sport->rxfifo_size = 16;
+ sport->txfifo_size = 16;
+ sport->port.fifosize = sport->txfifo_size;
+ }
+
lpuart32_setup_watermark_enable(sport);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 7/7] arm64: dts: ls1028a: add missing LPUART nodes
From: Michael Walle @ 2020-02-20 17:43 UTC (permalink / raw)
To: linux-serial, devicetree, linux-kernel, linux-arm-kernel
Cc: Mark Rutland, Peng Fan, Greg Kroah-Hartman, Li Yang,
Michael Walle, Rob Herring, Yuan Yao, Vabhav Sharma, Jiri Slaby,
Shawn Guo
In-Reply-To: <20200220174334.23322-1-michael@walle.cc>
The LS1028A has six LPUART controllers. Add the nodes.
This was tested on a custom board.
Signed-off-by: Michael Walle <michael@walle.cc>
---
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 55 +++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 40d82c49b174..f30ffc46063d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -390,6 +390,61 @@
status = "disabled";
};
+
+ lpuart0: serial@2260000 {
+ compatible = "fsl,ls1028a-lpuart";
+ reg = <0x0 0x2260000 0x0 0x1000>;
+ interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart1: serial@2270000 {
+ compatible = "fsl,ls1028a-lpuart";
+ reg = <0x0 0x2270000 0x0 0x1000>;
+ interrupts = <GIC_SPI 233 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart2: serial@2280000 {
+ compatible = "fsl,ls1028a-lpuart";
+ reg = <0x0 0x2280000 0x0 0x1000>;
+ interrupts = <GIC_SPI 234 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart3: serial@2290000 {
+ compatible = "fsl,ls1028a-lpuart";
+ reg = <0x0 0x2290000 0x0 0x1000>;
+ interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart4: serial@22a0000 {
+ compatible = "fsl,ls1028a-lpuart";
+ reg = <0x0 0x22a0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 236 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
+ lpuart5: serial@22b0000 {
+ compatible = "fsl,ls1028a-lpuart";
+ reg = <0x0 0x22b0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>;
+ clock-names = "ipg";
+ status = "disabled";
+ };
+
edma0: dma-controller@22c0000 {
#dma-cells = <2>;
compatible = "fsl,ls1028a-edma";
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v7 00/23] Change readahead API
From: David Sterba @ 2020-02-20 17:54 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <20200219210103.32400-1-willy@infradead.org>
On Wed, Feb 19, 2020 at 01:00:39PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> This series adds a readahead address_space operation to eventually
> replace the readpages operation. The key difference is that
> pages are added to the page cache as they are allocated (and
> then looked up by the filesystem) instead of passing them on a
> list to the readpages operation and having the filesystem add
> them to the page cache. It's a net reduction in code for each
> implementation, more efficient than walking a list, and solves
> the direct-write vs buffered-read problem reported by yu kuai at
> https://lore.kernel.org/linux-fsdevel/20200116063601.39201-1-yukuai3@huawei.com/
>
> The only unconverted filesystems are those which use fscache.
> Their conversion is pending Dave Howells' rewrite which will make the
> conversion substantially easier.
>
> I want to thank the reviewers; Dave Chinner, John Hubbard and Christoph
> Hellwig have done a marvellous job of providing constructive criticism.
> Eric Biggers pointed out how I'd broken ext4 (which led to a substantial
> change). I've tried to take it all on board, but I may have missed
> something simply because you've done such a thorough job.
>
> This series can also be found at
> http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/tags/readahead_v7
> (I also pushed the readahead_v6 tag there in case anyone wants to diff, and
> they're both based on 5.6-rc2 so they're easy to diff)
>
> v7:
> - Now passes an xfstests run on ext4!
On btrfs it still chokes on the first test btrfs/001, with the following
warning, the test is stuck there.
[ 21.100922] WARNING: suspicious RCU usage
[ 21.103107] 5.6.0-rc2-default+ #996 Not tainted
[ 21.105133] -----------------------------
[ 21.106864] include/linux/xarray.h:1164 suspicious rcu_dereference_check() usage!
[ 21.109948]
[ 21.109948] other info that might help us debug this:
[ 21.109948]
[ 21.113373]
[ 21.113373] rcu_scheduler_active = 2, debug_locks = 1
[ 21.115801] 4 locks held by umount/793:
[ 21.117135] #0: ffff964a736890e8 (&type->s_umount_key#26){+.+.}, at: deactivate_super+0x2f/0x40
[ 21.120188] #1: ffff964a7347ba68 (&delayed_node->mutex){+.+.}, at: __btrfs_commit_inode_delayed_items+0x44c/0x4e0 [btrfs]
[ 21.123042] #2: ffff964a612fe5c8 (&space_info->groups_sem){++++}, at: find_free_extent+0x27d/0xf00 [btrfs]
[ 21.126068] #3: ffff964a60b93280 (&caching_ctl->mutex){+.+.}, at: btrfs_cache_block_group+0x1f0/0x500 [btrfs]
[ 21.129655]
[ 21.129655] stack backtrace:
[ 21.131943] CPU: 1 PID: 793 Comm: umount Not tainted 5.6.0-rc2-default+ #996
[ 21.134164] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
[ 21.138076] Call Trace:
[ 21.139441] dump_stack+0x71/0xa0
[ 21.140954] xas_start+0x1a4/0x240
[ 21.142473] xas_load+0xa/0x50
[ 21.143874] xas_find+0x226/0x280
[ 21.145298] extent_readahead+0xcb/0x4f0 [btrfs]
[ 21.146934] ? mem_cgroup_commit_charge+0x56/0x400
[ 21.148654] ? rcu_read_lock_sched_held+0x5d/0x90
[ 21.150382] ? __add_to_page_cache_locked+0x327/0x380
[ 21.152155] read_pages+0x80/0x1f0
[ 21.153531] page_cache_readahead_unbounded+0x1b7/0x210
[ 21.155196] __load_free_space_cache+0x1c1/0x730 [btrfs]
[ 21.157014] load_free_space_cache+0xb9/0x190 [btrfs]
[ 21.158222] btrfs_cache_block_group+0x1f8/0x500 [btrfs]
[ 21.159717] ? finish_wait+0x90/0x90
[ 21.160723] find_free_extent+0xa17/0xf00 [btrfs]
[ 21.161798] ? kvm_sched_clock_read+0x14/0x30
[ 21.163022] ? sched_clock_cpu+0x10/0x120
[ 21.164361] btrfs_reserve_extent+0x9b/0x180 [btrfs]
[ 21.165952] btrfs_alloc_tree_block+0xc1/0x350 [btrfs]
[ 21.167680] ? __lock_acquire+0x272/0x1320
[ 21.169353] alloc_tree_block_no_bg_flush+0x4a/0x60 [btrfs]
[ 21.171313] __btrfs_cow_block+0x143/0x7a0 [btrfs]
[ 21.173080] btrfs_cow_block+0x15f/0x310 [btrfs]
[ 21.174487] btrfs_search_slot+0x93b/0xf70 [btrfs]
[ 21.175940] btrfs_lookup_inode+0x3a/0xc0 [btrfs]
[ 21.177419] ? __btrfs_commit_inode_delayed_items+0x417/0x4e0 [btrfs]
[ 21.179032] ? __btrfs_commit_inode_delayed_items+0x44c/0x4e0 [btrfs]
[ 21.180787] __btrfs_update_delayed_inode+0x73/0x260 [btrfs]
[ 21.182174] __btrfs_commit_inode_delayed_items+0x46c/0x4e0 [btrfs]
[ 21.183907] ? btrfs_first_delayed_node+0x4c/0x90 [btrfs]
[ 21.185204] __btrfs_run_delayed_items+0x8e/0x140 [btrfs]
[ 21.186521] btrfs_commit_transaction+0x312/0xae0 [btrfs]
[ 21.188142] ? btrfs_attach_transaction_barrier+0x1f/0x50 [btrfs]
[ 21.189684] sync_filesystem+0x6e/0x90
[ 21.190878] generic_shutdown_super+0x22/0x100
[ 21.192693] kill_anon_super+0x14/0x30
[ 21.194389] btrfs_kill_super+0x12/0x20 [btrfs]
[ 21.196078] deactivate_locked_super+0x2c/0x70
[ 21.197732] cleanup_mnt+0x100/0x160
[ 21.199033] task_work_run+0x90/0xc0
[ 21.200331] exit_to_usermode_loop+0x96/0xa0
[ 21.201744] do_syscall_64+0x1df/0x210
[ 21.203187] entry_SYSCALL_64_after_hwframe+0x49/0xbe
^ permalink raw reply
* Re: [PATCH v7 00/23] Change readahead API
From: David Sterba @ 2020-02-20 17:54 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-xfs, linux-kernel, linux-f2fs-devel, cluster-devel,
linux-mm, ocfs2-devel, linux-fsdevel, linux-ext4, linux-erofs,
linux-btrfs
In-Reply-To: <20200219210103.32400-1-willy@infradead.org>
On Wed, Feb 19, 2020 at 01:00:39PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> This series adds a readahead address_space operation to eventually
> replace the readpages operation. The key difference is that
> pages are added to the page cache as they are allocated (and
> then looked up by the filesystem) instead of passing them on a
> list to the readpages operation and having the filesystem add
> them to the page cache. It's a net reduction in code for each
> implementation, more efficient than walking a list, and solves
> the direct-write vs buffered-read problem reported by yu kuai at
> https://lore.kernel.org/linux-fsdevel/20200116063601.39201-1-yukuai3@huawei.com/
>
> The only unconverted filesystems are those which use fscache.
> Their conversion is pending Dave Howells' rewrite which will make the
> conversion substantially easier.
>
> I want to thank the reviewers; Dave Chinner, John Hubbard and Christoph
> Hellwig have done a marvellous job of providing constructive criticism.
> Eric Biggers pointed out how I'd broken ext4 (which led to a substantial
> change). I've tried to take it all on board, but I may have missed
> something simply because you've done such a thorough job.
>
> This series can also be found at
> http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/tags/readahead_v7
> (I also pushed the readahead_v6 tag there in case anyone wants to diff, and
> they're both based on 5.6-rc2 so they're easy to diff)
>
> v7:
> - Now passes an xfstests run on ext4!
On btrfs it still chokes on the first test btrfs/001, with the following
warning, the test is stuck there.
[ 21.100922] WARNING: suspicious RCU usage
[ 21.103107] 5.6.0-rc2-default+ #996 Not tainted
[ 21.105133] -----------------------------
[ 21.106864] include/linux/xarray.h:1164 suspicious rcu_dereference_check() usage!
[ 21.109948]
[ 21.109948] other info that might help us debug this:
[ 21.109948]
[ 21.113373]
[ 21.113373] rcu_scheduler_active = 2, debug_locks = 1
[ 21.115801] 4 locks held by umount/793:
[ 21.117135] #0: ffff964a736890e8 (&type->s_umount_key#26){+.+.}, at: deactivate_super+0x2f/0x40
[ 21.120188] #1: ffff964a7347ba68 (&delayed_node->mutex){+.+.}, at: __btrfs_commit_inode_delayed_items+0x44c/0x4e0 [btrfs]
[ 21.123042] #2: ffff964a612fe5c8 (&space_info->groups_sem){++++}, at: find_free_extent+0x27d/0xf00 [btrfs]
[ 21.126068] #3: ffff964a60b93280 (&caching_ctl->mutex){+.+.}, at: btrfs_cache_block_group+0x1f0/0x500 [btrfs]
[ 21.129655]
[ 21.129655] stack backtrace:
[ 21.131943] CPU: 1 PID: 793 Comm: umount Not tainted 5.6.0-rc2-default+ #996
[ 21.134164] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
[ 21.138076] Call Trace:
[ 21.139441] dump_stack+0x71/0xa0
[ 21.140954] xas_start+0x1a4/0x240
[ 21.142473] xas_load+0xa/0x50
[ 21.143874] xas_find+0x226/0x280
[ 21.145298] extent_readahead+0xcb/0x4f0 [btrfs]
[ 21.146934] ? mem_cgroup_commit_charge+0x56/0x400
[ 21.148654] ? rcu_read_lock_sched_held+0x5d/0x90
[ 21.150382] ? __add_to_page_cache_locked+0x327/0x380
[ 21.152155] read_pages+0x80/0x1f0
[ 21.153531] page_cache_readahead_unbounded+0x1b7/0x210
[ 21.155196] __load_free_space_cache+0x1c1/0x730 [btrfs]
[ 21.157014] load_free_space_cache+0xb9/0x190 [btrfs]
[ 21.158222] btrfs_cache_block_group+0x1f8/0x500 [btrfs]
[ 21.159717] ? finish_wait+0x90/0x90
[ 21.160723] find_free_extent+0xa17/0xf00 [btrfs]
[ 21.161798] ? kvm_sched_clock_read+0x14/0x30
[ 21.163022] ? sched_clock_cpu+0x10/0x120
[ 21.164361] btrfs_reserve_extent+0x9b/0x180 [btrfs]
[ 21.165952] btrfs_alloc_tree_block+0xc1/0x350 [btrfs]
[ 21.167680] ? __lock_acquire+0x272/0x1320
[ 21.169353] alloc_tree_block_no_bg_flush+0x4a/0x60 [btrfs]
[ 21.171313] __btrfs_cow_block+0x143/0x7a0 [btrfs]
[ 21.173080] btrfs_cow_block+0x15f/0x310 [btrfs]
[ 21.174487] btrfs_search_slot+0x93b/0xf70 [btrfs]
[ 21.175940] btrfs_lookup_inode+0x3a/0xc0 [btrfs]
[ 21.177419] ? __btrfs_commit_inode_delayed_items+0x417/0x4e0 [btrfs]
[ 21.179032] ? __btrfs_commit_inode_delayed_items+0x44c/0x4e0 [btrfs]
[ 21.180787] __btrfs_update_delayed_inode+0x73/0x260 [btrfs]
[ 21.182174] __btrfs_commit_inode_delayed_items+0x46c/0x4e0 [btrfs]
[ 21.183907] ? btrfs_first_delayed_node+0x4c/0x90 [btrfs]
[ 21.185204] __btrfs_run_delayed_items+0x8e/0x140 [btrfs]
[ 21.186521] btrfs_commit_transaction+0x312/0xae0 [btrfs]
[ 21.188142] ? btrfs_attach_transaction_barrier+0x1f/0x50 [btrfs]
[ 21.189684] sync_filesystem+0x6e/0x90
[ 21.190878] generic_shutdown_super+0x22/0x100
[ 21.192693] kill_anon_super+0x14/0x30
[ 21.194389] btrfs_kill_super+0x12/0x20 [btrfs]
[ 21.196078] deactivate_locked_super+0x2c/0x70
[ 21.197732] cleanup_mnt+0x100/0x160
[ 21.199033] task_work_run+0x90/0xc0
[ 21.200331] exit_to_usermode_loop+0x96/0xa0
[ 21.201744] do_syscall_64+0x1df/0x210
[ 21.203187] entry_SYSCALL_64_after_hwframe+0x49/0xbe
^ permalink raw reply
* [PATCH 4/7] dt-bindings: serial: lpuart: add ls1028a compatibility
From: Michael Walle @ 2020-02-20 17:43 UTC (permalink / raw)
To: linux-serial, devicetree, linux-kernel, linux-arm-kernel
Cc: Mark Rutland, Peng Fan, Greg Kroah-Hartman, Li Yang,
Michael Walle, Rob Herring, Yuan Yao, Vabhav Sharma, Jiri Slaby,
Shawn Guo
In-Reply-To: <20200220174334.23322-1-michael@walle.cc>
Signed-off-by: Michael Walle <michael@walle.cc>
---
.../devicetree/bindings/serial/fsl-lpuart.txt | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
index c904e2e68332..e7448b92dd9d 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
@@ -6,6 +6,8 @@ Required properties:
on Vybrid vf610 SoC with 8-bit register organization
- "fsl,ls1021a-lpuart" for lpuart compatible with the one integrated
on LS1021A SoC with 32-bit big-endian register organization
+ - "fsl,ls1028a-lpuart" for lpuart compatible with the one integrated
+ on LS1028A SoC with 32-bit little-endian register organization
- "fsl,imx7ulp-lpuart" for lpuart compatible with the one integrated
on i.MX7ULP SoC with 32-bit little-endian register organization
- "fsl,imx8qxp-lpuart" for lpuart compatible with the one integrated
@@ -15,10 +17,10 @@ Required properties:
- reg : Address and length of the register set for the device
- interrupts : Should contain uart interrupt
- clocks : phandle + clock specifier pairs, one for each entry in clock-names
-- clock-names : For vf610/ls1021a/imx7ulp, "ipg" clock is for uart bus/baud
- clock. For imx8qxp lpuart, "ipg" clock is bus clock that is used to access
- lpuart controller registers, it also requires "baud" clock for module to
- receive/transmit data.
+- clock-names : For vf610/ls1021a/ls1028a/imx7ulp, "ipg" clock is for uart
+ bus/baud clock. For imx8qxp lpuart, "ipg" clock is bus clock that is used
+ to access lpuart controller registers, it also requires "baud" clock for
+ module to receive/transmit data.
Optional properties:
- dmas: A list of two dma specifiers, one for each entry in dma-names.
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: LKFT: arm x15: mmc1: cache flush error -110
From: Naresh Kamboju @ 2020-02-20 17:54 UTC (permalink / raw)
To: Ulf Hansson
Cc: Jens Axboe, Alexei Starovoitov, linux-block, lkft-triage,
open list, linux-mmc@vger.kernel.org, Arnd Bergmann, John Stultz
In-Reply-To: <CAPDyKFqqhxC-pmV_j8PLY-D=AbqCAbiipAAHXLpJ4N_BiYYOFw@mail.gmail.com>
On Wed, 19 Feb 2020 at 21:54, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Thu, 13 Feb 2020 at 16:43, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
>
> Try to restore the value for the cache flush timeout, by updating the
> define MMC_CACHE_FLUSH_TIMEOUT_MS to 10 * 60 * 1000".
I have increased the timeout to 10 minutes but it did not help.
Same error found.
[ 608.679353] mmc1: Card stuck being busy! mmc_poll_for_busy
[ 608.684964] mmc1: cache flush error -110
[ 608.689005] blk_update_request: I/O error, dev mmcblk1, sector
4302400 op 0x1:(WRITE) flags 0x20800 phys_seg 1 prio class 0
OTOH, What best i could do for my own experiment to revert all three patches and
now the reported error gone and device mount successfully [1].
List of patches reverted,
mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
mmc: block: Use generic_cmd6_time when modifying
INAND_CMD38_ARG_EXT_CSD
mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch()
[1] https://lkft.validation.linaro.org/scheduler/job/1238275#L4346
- Naresh
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu-v3: Add SMMUv3.2 range invalidation support
From: Rob Herring @ 2020-02-20 17:54 UTC (permalink / raw)
To: Robin Murphy
Cc: Jean-Philippe Brucker, Linux IOMMU, Will Deacon,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <d49b62f2-74f4-c3e0-ad97-a4fedd169b27@arm.com>
On Mon, Feb 17, 2020 at 1:17 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 13/02/2020 9:49 pm, Rob Herring wrote:
> > On Thu, Jan 30, 2020 at 11:34 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >>
> >> On 30/01/2020 3:06 pm, Auger Eric wrote:
> >>> Hi Rob,
> >>> On 1/17/20 10:16 PM, Rob Herring wrote:
> >>>> Arm SMMUv3.2 adds support for TLB range invalidate operations.
> >>>> Support for range invalidate is determined by the RIL bit in the IDR3
> >>>> register.
> >>>>
> >>>> The range invalidate is in units of the leaf page size and operates on
> >>>> 1-32 chunks of a power of 2 multiple pages. First, we determine from the
> >>>> size what power of 2 multiple we can use. Then we calculate how many
> >>>> chunks (1-31) of the power of 2 size for the range on the iteration. On
> >>>> each iteration, we move up in size by at least 5 bits.
> >>>>
> >>>> Cc: Eric Auger <eric.auger@redhat.com>
> >>>> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
> >>>> Cc: Will Deacon <will@kernel.org>
> >>>> Cc: Robin Murphy <robin.murphy@arm.com>
> >>>> Cc: Joerg Roedel <joro@8bytes.org>
> >>>> Signed-off-by: Rob Herring <robh@kernel.org>
> >
> >
> >>>> @@ -2003,7 +2024,7 @@ static void arm_smmu_tlb_inv_range(unsigned long iova, size_t size,
> >>>> {
> >>>> u64 cmds[CMDQ_BATCH_ENTRIES * CMDQ_ENT_DWORDS];
> >>>> struct arm_smmu_device *smmu = smmu_domain->smmu;
> >>>> - unsigned long start = iova, end = iova + size;
> >>>> + unsigned long start = iova, end = iova + size, num_pages = 0, tg = 0;
> >>>> int i = 0;
> >>>> struct arm_smmu_cmdq_ent cmd = {
> >>>> .tlbi = {
> >>>> @@ -2022,12 +2043,50 @@ static void arm_smmu_tlb_inv_range(unsigned long iova, size_t size,
> >>>> cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid;
> >>>> }
> >>>>
> >>>> + if (smmu->features & ARM_SMMU_FEAT_RANGE_INV) {
> >>>> + /* Get the leaf page size */
> >>>> + tg = __ffs(smmu_domain->domain.pgsize_bitmap);
> >>>> +
> >>>> + /* Convert page size of 12,14,16 (log2) to 1,2,3 */
> >>>> + cmd.tlbi.tg = ((tg - ilog2(SZ_4K)) / 2) + 1;
> >>
> >> Given the comment, I think "(tg - 10) / 2" would suffice ;)
> >
> > Well, duh...
> >
> >>
> >>>> +
> >>>> + /* Determine what level the granule is at */
> >>>> + cmd.tlbi.ttl = 4 - ((ilog2(granule) - 3) / (tg - 3));
> >>
> >> Is it possible to rephrase that with logs and shifts to avoid the division?
> >
> > Well, with a loop is the only other way I came up with:
> >
> > bpl = tg - 3;
> > ttl = 3;
> > mask = BIT(bpl) - 1;
> > while ((granule & (mask << ((4 - ttl) * bpl + 3))) == 0)
> > ttl--;
> >
> > Doesn't seem like much improvement to me given we have h/w divide...
>
> Sure, it doesn't take too many extra instructions to start matching
> typical IDIV latency, so there's no point being silly if there really
> isn't a clean alternative.
>
> Some quick scribbling suggests "4 - ilog2(granule) / 10" might actually
> be close enough, but perhaps that's a bit too cheeky.
How does divide by 10 save a divide?
> >>>> + num_pages = size / (1UL << tg);
> >>
> >> Similarly, in my experience GCC has always seemed too cautious to elide
> >> non-constant division even in a seemingly-obvious case like this, so
> >> explicit "size >> tg" might be preferable.
> >
> > My experience has been gcc is smart enough. I checked and there's only
> > one divide and it is the prior one. But I'll change it anyways.
>
> Now that I think about it, the case that frustrated me may have had the
> shift and divide in separate statements - that's probably a lot harder
> to analyse than a single expression. Either way, the simple right shift
> is easier to read IMO.
>
> >>>> + }
> >>>> +
> >>>> while (iova < end) {
> >>>> if (i == CMDQ_BATCH_ENTRIES) {
> >>>> arm_smmu_cmdq_issue_cmdlist(smmu, cmds, i, false);
> >>>> i = 0;
> >>>> }
> >>>>
> >>>> + if (smmu->features & ARM_SMMU_FEAT_RANGE_INV) {
> >>>> + /*
> >>>> + * On each iteration of the loop, the range is 5 bits
> >>>> + * worth of the aligned size remaining.
> >>>> + * The range in pages is:
> >>>> + *
> >>>> + * range = (num_pages & (0x1f << __ffs(num_pages)))
> >>>> + */
> >>>> + unsigned long scale, num;
> >>>> +
> >>>> + /* Determine the power of 2 multiple number of pages */
> >>>> + scale = __ffs(num_pages);
> >>>> + cmd.tlbi.scale = scale;
> >>>> +
> >>>> + /* Determine how many chunks of 2^scale size we have */
> >>>> + num = (num_pages >> scale) & CMDQ_TLBI_RANGE_NUM_MAX;
> >>>> + cmd.tlbi.num = num - 1;
> >>>> +
> >>>> + /* range is num * 2^scale * pgsize */
> >>>> + granule = num << (scale + tg);
> >>>> +
> >>>> + /* Clear out the lower order bits for the next iteration */
> >>>> + num_pages -= num << scale;
> >>> Regarding the 2 options given in
> >>> https://lore.kernel.org/linux-arm-kernel/CAL_JsqKABoE+0crGwyZdNogNgEoG=MOOpf6deQgH6s73c0UNdA@mail.gmail.com/raw,
> >>>
> >>> I understand you implemented 2) but I still do not understand why you
> >>> preferred that one against 1).
> >>>
> >>> In your case of 1023*4k pages this will invalidate by 31 32*2^0*4K +
> >>> 31*2^0*4K pages
> >>> whereas you could achieve that with 10 invalidations with the 1st algo.
> >>> I did not get the case where it is more efficient. Please can you detail.
> >>
> >> I guess essentially we want to solve for two variables to get a range as
> >> close to size as possible. There might be a more elegant numerical
> >> method, but for the numbers involved brute force is probably good enough
> >> for the real world. 5 minutes alone with the architecture spec and a
> >> blank editor begat this pseudo-implementation:
> >>
> >> size_t npages = size >> pgshift;
> >> while (npages) {
> >> unsigned long range;
> >> unsigned int delta, best = UINT_MAX;
> >> int num, scale = min(31, __ffs(npages));
> >>
> >> while (scale) {
> >> num = min(32, npages >> scale);
> >> if (num == 32)
> >> break;
> >>
> >> delta = npages & ((1 << scale) - 1);
> >> if (!delta || delta > best)
> >> break;
> >>
> >> best = delta;
> >> scale--;
> >> }
> >>
> >> //invalidate
> >>
> >> range = num << scale;
> >> npages -= range;
> >> iova += (range) << pgshift;
> >> }
> >>
> >> Modulo any obvious thinkos, what do you reckon?
> >
> > I don't think this is an improvement. See my other reply.
>
> Indeed, I hadn't quite got my head round your algorithm at first, so
> deriving this was as much to help me get a better feel for the problem
> as anything. Now I see that "minimise the remainder" really boils down
> to "remove up to 5 high-order bits each time", which in turn is
> essentially the same thing just done in the other direction (and in a
> slightly more cumbersome manner). Now that I do get it, your algorithm
> is in fact really neat, sorry for doubting :)
>
> FWIW it might be a little more efficient to maintain scale outside the
> loop, such that num_pages can simply be shifted right to lose the
> low-order bits each iteration, but other than that I think it's pretty
> much as good as it can get.
I think I understand what you're getting at. We'd need to have the
total running 'scale' and the incremental 'scale' for each loop
iteration. We could do that by using cmd.tlbi.scale to keep the
running total. So something like this (untested)?:
if (smmu->features & ARM_SMMU_FEAT_RANGE_INV) {
unsigned long scale, num;
/* Determine the power of 2 multiple number of pages */
scale = __ffs(num_pages);
cmd.tlbi.scale += scale;
/* Determine how many chunks of 2^scale size we have */
num = (num_pages >> scale) & CMDQ_TLBI_RANGE_NUM_MAX;
cmd.tlbi.num = num - 1;
/* range is num * 2^scale * pgsize */
granule = num << (cmd.tlbi.scale + tg);
/* Clear out the lower order bits for the next iteration */
num_pages >>= 5 + scale;
}
That's actually worse by 1 add and probably a memory (re)load of
cmd.tlbi.scale AFAICT.
Rob
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [PATCH 6/7] tty: serial: fsl_lpuart: add LS1028A earlycon support
From: Michael Walle @ 2020-02-20 17:43 UTC (permalink / raw)
To: linux-serial, devicetree, linux-kernel, linux-arm-kernel
Cc: Mark Rutland, Peng Fan, Greg Kroah-Hartman, Li Yang,
Michael Walle, Rob Herring, Yuan Yao, Vabhav Sharma, Jiri Slaby,
Shawn Guo
In-Reply-To: <20200220174334.23322-1-michael@walle.cc>
Add a early_console_setup() for the LS1028A SoC with 32bit, little
endian access. If the bootloader does a fixup of the clock-frequency
node the baudrate divisor register will automatically be set.
Signed-off-by: Michael Walle <michael@walle.cc>
---
drivers/tty/serial/fsl_lpuart.c | 51 +++++++++++++++++++++++++++------
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 6953eea166dc..4386ffdfe275 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1834,11 +1834,12 @@ lpuart_set_termios(struct uart_port *port, struct ktermios *termios,
spin_unlock_irqrestore(&sport->port.lock, flags);
}
-static void
-lpuart32_serial_setbrg(struct lpuart_port *sport, unsigned int baudrate)
+static void __lpuart32_serial_setbrg(struct uart_port *port,
+ unsigned int baudrate, bool use_rx_dma,
+ bool use_tx_dma)
{
u32 sbr, osr, baud_diff, tmp_osr, tmp_sbr, tmp_diff, tmp;
- u32 clk = sport->port.uartclk;
+ u32 clk = port->uartclk;
/*
* The idea is to use the best OSR (over-sampling rate) possible.
@@ -1884,10 +1885,10 @@ lpuart32_serial_setbrg(struct lpuart_port *sport, unsigned int baudrate)
/* handle buadrate outside acceptable rate */
if (baud_diff > ((baudrate / 100) * 3))
- dev_warn(sport->port.dev,
+ dev_warn(port->dev,
"unacceptable baud rate difference of more than 3%%\n");
- tmp = lpuart32_read(&sport->port, UARTBAUD);
+ tmp = lpuart32_read(port, UARTBAUD);
if ((osr > 3) && (osr < 8))
tmp |= UARTBAUD_BOTHEDGE;
@@ -1898,14 +1899,23 @@ lpuart32_serial_setbrg(struct lpuart_port *sport, unsigned int baudrate)
tmp &= ~UARTBAUD_SBR_MASK;
tmp |= sbr & UARTBAUD_SBR_MASK;
- if (!sport->lpuart_dma_rx_use)
+ if (!use_rx_dma)
tmp &= ~UARTBAUD_RDMAE;
- if (!sport->lpuart_dma_tx_use)
+ if (!use_tx_dma)
tmp &= ~UARTBAUD_TDMAE;
- lpuart32_write(&sport->port, tmp, UARTBAUD);
+ lpuart32_write(port, tmp, UARTBAUD);
+}
+
+static void lpuart32_serial_setbrg(struct lpuart_port *sport,
+ unsigned int baudrate)
+{
+ __lpuart32_serial_setbrg(&sport->port, baudrate,
+ sport->lpuart_dma_rx_use,
+ sport->lpuart_dma_tx_use);
}
+
static void
lpuart32_set_termios(struct uart_port *port, struct ktermios *termios,
struct ktermios *old)
@@ -2399,6 +2409,30 @@ static int __init lpuart32_early_console_setup(struct earlycon_device *device,
return 0;
}
+static int __init ls1028a_early_console_setup(struct earlycon_device *device,
+ const char *opt)
+{
+ u32 cr;
+
+ if (!device->port.membase)
+ return -ENODEV;
+
+ device->port.iotype = UPIO_MEM32;
+ device->con->write = lpuart32_early_write;
+
+ /* set the baudrate */
+ if (device->port.uartclk && device->baud)
+ __lpuart32_serial_setbrg(&device->port, device->baud,
+ false, false);
+
+ /* enable transmitter */
+ cr = lpuart32_read(&device->port, UARTCTRL);
+ cr |= UARTCTRL_TE;
+ lpuart32_write(&device->port, cr, UARTCTRL);
+
+ return 0;
+}
+
static int __init lpuart32_imx_early_console_setup(struct earlycon_device *device,
const char *opt)
{
@@ -2413,6 +2447,7 @@ static int __init lpuart32_imx_early_console_setup(struct earlycon_device *devic
}
OF_EARLYCON_DECLARE(lpuart, "fsl,vf610-lpuart", lpuart_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,ls1021a-lpuart", lpuart32_early_console_setup);
+OF_EARLYCON_DECLARE(lpuart32, "fsl,ls1028a-lpuart", ls1028a_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,imx7ulp-lpuart", lpuart32_imx_early_console_setup);
EARLYCON_DECLARE(lpuart, lpuart_early_console_setup);
EARLYCON_DECLARE(lpuart32, lpuart32_early_console_setup);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
From: Ang, Chee Hong @ 2020-02-20 17:54 UTC (permalink / raw)
To: u-boot
In-Reply-To: <ecb82a50-6043-05b9-12b4-b17be4f2e80b@denx.de>
> On 2/20/20 3:02 AM, Ang, Chee Hong wrote:
> [...]
> >>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
> >>> +u32 socfpga_secure_reg_read32(phys_addr_t reg_addr); void
> >>> +socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr); void
> >>> +socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32
> >>> +val); #else
> >>> +#define socfpga_secure_reg_read32 readl
> >>> +#define socfpga_secure_reg_write32 writel
> >>> +#define socfpga_secure_reg_update32 clrsetbits_le32
> >>> +#endif
> >>
> >> I think I don't understand how this is supposed to work. Would every
> >> place in U- Boot have to be patched to call these functions now ?
> >
> > Not every register access need this. Only those accessing registers in
> > secure zone such as 'System Manager' registers need to call this. It's
> > basically determine whether the driver should issue SMC/PSCI call if
> > it's running in EL2 (non-secure) or access the registers directly by simply using
> readl/writel and etc if it's running in EL3 (secure).
> > Accessing those registers in secure zone in non-secure mode (EL2) will cause
> SError exception.
> > So we can determine this behaviour in compile time:
> > SPL always running in EL3. So it just simply fallback to use
> readl/writel/clrsetbits_le32.
> >
> > For U-Boot proper (SSBL), there are 2 scenarios:
> > 1) If CONFIG_SPL_ATF is defined, it means ATF is supported. It implies
> > that U-Boot proper will be running in EL2 (non-secure), then it will use
> SMC/PSCI calls to access the secure registers.
> >
> > 2) CONFIG_SPL_ATF is not defined, no ATF support. U-Boot proper will
> > be running in EL3 which will fall back to simply using the direct access functions
> (readl/writel and etc).
>
> I would expect the standard IO accessors would or should handle this stuff ?
Standard IO accessors are just general memory read/write functions designed to be
compatible with general hardware platforms. Not all platforms have secure/non-secure
hardware zones. I don't think they should handle this.
If it's running in EL3 (secure mode) the standard I/O accessors will work just fine because
EL3 can access to all secure/non-secure zones. In the header file, you can see the secure
I/O accessors will be replaced by the standard I/O accessors if it's built for SPL and U-Boot
proper without ATF. Because both are running in EL3 (secure).
If ATF is enabled, SPL will be still running in EL3 but U-Boot proper will be running in
EL2 (non-secure). If any code accessing those secure zones without going through ATF
(making SMC/PSCI calls to EL3), it will trigger 'SError' exceptions and crash the U-Boot.
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu-v3: Add SMMUv3.2 range invalidation support
From: Rob Herring @ 2020-02-20 17:54 UTC (permalink / raw)
To: Robin Murphy
Cc: Jean-Philippe Brucker, Joerg Roedel, Auger Eric, Linux IOMMU,
Will Deacon,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <d49b62f2-74f4-c3e0-ad97-a4fedd169b27@arm.com>
On Mon, Feb 17, 2020 at 1:17 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 13/02/2020 9:49 pm, Rob Herring wrote:
> > On Thu, Jan 30, 2020 at 11:34 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >>
> >> On 30/01/2020 3:06 pm, Auger Eric wrote:
> >>> Hi Rob,
> >>> On 1/17/20 10:16 PM, Rob Herring wrote:
> >>>> Arm SMMUv3.2 adds support for TLB range invalidate operations.
> >>>> Support for range invalidate is determined by the RIL bit in the IDR3
> >>>> register.
> >>>>
> >>>> The range invalidate is in units of the leaf page size and operates on
> >>>> 1-32 chunks of a power of 2 multiple pages. First, we determine from the
> >>>> size what power of 2 multiple we can use. Then we calculate how many
> >>>> chunks (1-31) of the power of 2 size for the range on the iteration. On
> >>>> each iteration, we move up in size by at least 5 bits.
> >>>>
> >>>> Cc: Eric Auger <eric.auger@redhat.com>
> >>>> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
> >>>> Cc: Will Deacon <will@kernel.org>
> >>>> Cc: Robin Murphy <robin.murphy@arm.com>
> >>>> Cc: Joerg Roedel <joro@8bytes.org>
> >>>> Signed-off-by: Rob Herring <robh@kernel.org>
> >
> >
> >>>> @@ -2003,7 +2024,7 @@ static void arm_smmu_tlb_inv_range(unsigned long iova, size_t size,
> >>>> {
> >>>> u64 cmds[CMDQ_BATCH_ENTRIES * CMDQ_ENT_DWORDS];
> >>>> struct arm_smmu_device *smmu = smmu_domain->smmu;
> >>>> - unsigned long start = iova, end = iova + size;
> >>>> + unsigned long start = iova, end = iova + size, num_pages = 0, tg = 0;
> >>>> int i = 0;
> >>>> struct arm_smmu_cmdq_ent cmd = {
> >>>> .tlbi = {
> >>>> @@ -2022,12 +2043,50 @@ static void arm_smmu_tlb_inv_range(unsigned long iova, size_t size,
> >>>> cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid;
> >>>> }
> >>>>
> >>>> + if (smmu->features & ARM_SMMU_FEAT_RANGE_INV) {
> >>>> + /* Get the leaf page size */
> >>>> + tg = __ffs(smmu_domain->domain.pgsize_bitmap);
> >>>> +
> >>>> + /* Convert page size of 12,14,16 (log2) to 1,2,3 */
> >>>> + cmd.tlbi.tg = ((tg - ilog2(SZ_4K)) / 2) + 1;
> >>
> >> Given the comment, I think "(tg - 10) / 2" would suffice ;)
> >
> > Well, duh...
> >
> >>
> >>>> +
> >>>> + /* Determine what level the granule is at */
> >>>> + cmd.tlbi.ttl = 4 - ((ilog2(granule) - 3) / (tg - 3));
> >>
> >> Is it possible to rephrase that with logs and shifts to avoid the division?
> >
> > Well, with a loop is the only other way I came up with:
> >
> > bpl = tg - 3;
> > ttl = 3;
> > mask = BIT(bpl) - 1;
> > while ((granule & (mask << ((4 - ttl) * bpl + 3))) == 0)
> > ttl--;
> >
> > Doesn't seem like much improvement to me given we have h/w divide...
>
> Sure, it doesn't take too many extra instructions to start matching
> typical IDIV latency, so there's no point being silly if there really
> isn't a clean alternative.
>
> Some quick scribbling suggests "4 - ilog2(granule) / 10" might actually
> be close enough, but perhaps that's a bit too cheeky.
How does divide by 10 save a divide?
> >>>> + num_pages = size / (1UL << tg);
> >>
> >> Similarly, in my experience GCC has always seemed too cautious to elide
> >> non-constant division even in a seemingly-obvious case like this, so
> >> explicit "size >> tg" might be preferable.
> >
> > My experience has been gcc is smart enough. I checked and there's only
> > one divide and it is the prior one. But I'll change it anyways.
>
> Now that I think about it, the case that frustrated me may have had the
> shift and divide in separate statements - that's probably a lot harder
> to analyse than a single expression. Either way, the simple right shift
> is easier to read IMO.
>
> >>>> + }
> >>>> +
> >>>> while (iova < end) {
> >>>> if (i == CMDQ_BATCH_ENTRIES) {
> >>>> arm_smmu_cmdq_issue_cmdlist(smmu, cmds, i, false);
> >>>> i = 0;
> >>>> }
> >>>>
> >>>> + if (smmu->features & ARM_SMMU_FEAT_RANGE_INV) {
> >>>> + /*
> >>>> + * On each iteration of the loop, the range is 5 bits
> >>>> + * worth of the aligned size remaining.
> >>>> + * The range in pages is:
> >>>> + *
> >>>> + * range = (num_pages & (0x1f << __ffs(num_pages)))
> >>>> + */
> >>>> + unsigned long scale, num;
> >>>> +
> >>>> + /* Determine the power of 2 multiple number of pages */
> >>>> + scale = __ffs(num_pages);
> >>>> + cmd.tlbi.scale = scale;
> >>>> +
> >>>> + /* Determine how many chunks of 2^scale size we have */
> >>>> + num = (num_pages >> scale) & CMDQ_TLBI_RANGE_NUM_MAX;
> >>>> + cmd.tlbi.num = num - 1;
> >>>> +
> >>>> + /* range is num * 2^scale * pgsize */
> >>>> + granule = num << (scale + tg);
> >>>> +
> >>>> + /* Clear out the lower order bits for the next iteration */
> >>>> + num_pages -= num << scale;
> >>> Regarding the 2 options given in
> >>> https://lore.kernel.org/linux-arm-kernel/CAL_JsqKABoE+0crGwyZdNogNgEoG=MOOpf6deQgH6s73c0UNdA@mail.gmail.com/raw,
> >>>
> >>> I understand you implemented 2) but I still do not understand why you
> >>> preferred that one against 1).
> >>>
> >>> In your case of 1023*4k pages this will invalidate by 31 32*2^0*4K +
> >>> 31*2^0*4K pages
> >>> whereas you could achieve that with 10 invalidations with the 1st algo.
> >>> I did not get the case where it is more efficient. Please can you detail.
> >>
> >> I guess essentially we want to solve for two variables to get a range as
> >> close to size as possible. There might be a more elegant numerical
> >> method, but for the numbers involved brute force is probably good enough
> >> for the real world. 5 minutes alone with the architecture spec and a
> >> blank editor begat this pseudo-implementation:
> >>
> >> size_t npages = size >> pgshift;
> >> while (npages) {
> >> unsigned long range;
> >> unsigned int delta, best = UINT_MAX;
> >> int num, scale = min(31, __ffs(npages));
> >>
> >> while (scale) {
> >> num = min(32, npages >> scale);
> >> if (num == 32)
> >> break;
> >>
> >> delta = npages & ((1 << scale) - 1);
> >> if (!delta || delta > best)
> >> break;
> >>
> >> best = delta;
> >> scale--;
> >> }
> >>
> >> //invalidate
> >>
> >> range = num << scale;
> >> npages -= range;
> >> iova += (range) << pgshift;
> >> }
> >>
> >> Modulo any obvious thinkos, what do you reckon?
> >
> > I don't think this is an improvement. See my other reply.
>
> Indeed, I hadn't quite got my head round your algorithm at first, so
> deriving this was as much to help me get a better feel for the problem
> as anything. Now I see that "minimise the remainder" really boils down
> to "remove up to 5 high-order bits each time", which in turn is
> essentially the same thing just done in the other direction (and in a
> slightly more cumbersome manner). Now that I do get it, your algorithm
> is in fact really neat, sorry for doubting :)
>
> FWIW it might be a little more efficient to maintain scale outside the
> loop, such that num_pages can simply be shifted right to lose the
> low-order bits each iteration, but other than that I think it's pretty
> much as good as it can get.
I think I understand what you're getting at. We'd need to have the
total running 'scale' and the incremental 'scale' for each loop
iteration. We could do that by using cmd.tlbi.scale to keep the
running total. So something like this (untested)?:
if (smmu->features & ARM_SMMU_FEAT_RANGE_INV) {
unsigned long scale, num;
/* Determine the power of 2 multiple number of pages */
scale = __ffs(num_pages);
cmd.tlbi.scale += scale;
/* Determine how many chunks of 2^scale size we have */
num = (num_pages >> scale) & CMDQ_TLBI_RANGE_NUM_MAX;
cmd.tlbi.num = num - 1;
/* range is num * 2^scale * pgsize */
granule = num << (cmd.tlbi.scale + tg);
/* Clear out the lower order bits for the next iteration */
num_pages >>= 5 + scale;
}
That's actually worse by 1 add and probably a memory (re)load of
cmd.tlbi.scale AFAICT.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v7 00/23] Change readahead API
From: David Sterba @ 2020-02-20 17:54 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-xfs, linux-kernel, linux-f2fs-devel, cluster-devel,
linux-mm, ocfs2-devel, linux-fsdevel, linux-ext4, linux-erofs,
linux-btrfs
In-Reply-To: <20200219210103.32400-1-willy@infradead.org>
On Wed, Feb 19, 2020 at 01:00:39PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> This series adds a readahead address_space operation to eventually
> replace the readpages operation. The key difference is that
> pages are added to the page cache as they are allocated (and
> then looked up by the filesystem) instead of passing them on a
> list to the readpages operation and having the filesystem add
> them to the page cache. It's a net reduction in code for each
> implementation, more efficient than walking a list, and solves
> the direct-write vs buffered-read problem reported by yu kuai at
> https://lore.kernel.org/linux-fsdevel/20200116063601.39201-1-yukuai3@huawei.com/
>
> The only unconverted filesystems are those which use fscache.
> Their conversion is pending Dave Howells' rewrite which will make the
> conversion substantially easier.
>
> I want to thank the reviewers; Dave Chinner, John Hubbard and Christoph
> Hellwig have done a marvellous job of providing constructive criticism.
> Eric Biggers pointed out how I'd broken ext4 (which led to a substantial
> change). I've tried to take it all on board, but I may have missed
> something simply because you've done such a thorough job.
>
> This series can also be found at
> http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/tags/readahead_v7
> (I also pushed the readahead_v6 tag there in case anyone wants to diff, and
> they're both based on 5.6-rc2 so they're easy to diff)
>
> v7:
> - Now passes an xfstests run on ext4!
On btrfs it still chokes on the first test btrfs/001, with the following
warning, the test is stuck there.
[ 21.100922] WARNING: suspicious RCU usage
[ 21.103107] 5.6.0-rc2-default+ #996 Not tainted
[ 21.105133] -----------------------------
[ 21.106864] include/linux/xarray.h:1164 suspicious rcu_dereference_check() usage!
[ 21.109948]
[ 21.109948] other info that might help us debug this:
[ 21.109948]
[ 21.113373]
[ 21.113373] rcu_scheduler_active = 2, debug_locks = 1
[ 21.115801] 4 locks held by umount/793:
[ 21.117135] #0: ffff964a736890e8 (&type->s_umount_key#26){+.+.}, at: deactivate_super+0x2f/0x40
[ 21.120188] #1: ffff964a7347ba68 (&delayed_node->mutex){+.+.}, at: __btrfs_commit_inode_delayed_items+0x44c/0x4e0 [btrfs]
[ 21.123042] #2: ffff964a612fe5c8 (&space_info->groups_sem){++++}, at: find_free_extent+0x27d/0xf00 [btrfs]
[ 21.126068] #3: ffff964a60b93280 (&caching_ctl->mutex){+.+.}, at: btrfs_cache_block_group+0x1f0/0x500 [btrfs]
[ 21.129655]
[ 21.129655] stack backtrace:
[ 21.131943] CPU: 1 PID: 793 Comm: umount Not tainted 5.6.0-rc2-default+ #996
[ 21.134164] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
[ 21.138076] Call Trace:
[ 21.139441] dump_stack+0x71/0xa0
[ 21.140954] xas_start+0x1a4/0x240
[ 21.142473] xas_load+0xa/0x50
[ 21.143874] xas_find+0x226/0x280
[ 21.145298] extent_readahead+0xcb/0x4f0 [btrfs]
[ 21.146934] ? mem_cgroup_commit_charge+0x56/0x400
[ 21.148654] ? rcu_read_lock_sched_held+0x5d/0x90
[ 21.150382] ? __add_to_page_cache_locked+0x327/0x380
[ 21.152155] read_pages+0x80/0x1f0
[ 21.153531] page_cache_readahead_unbounded+0x1b7/0x210
[ 21.155196] __load_free_space_cache+0x1c1/0x730 [btrfs]
[ 21.157014] load_free_space_cache+0xb9/0x190 [btrfs]
[ 21.158222] btrfs_cache_block_group+0x1f8/0x500 [btrfs]
[ 21.159717] ? finish_wait+0x90/0x90
[ 21.160723] find_free_extent+0xa17/0xf00 [btrfs]
[ 21.161798] ? kvm_sched_clock_read+0x14/0x30
[ 21.163022] ? sched_clock_cpu+0x10/0x120
[ 21.164361] btrfs_reserve_extent+0x9b/0x180 [btrfs]
[ 21.165952] btrfs_alloc_tree_block+0xc1/0x350 [btrfs]
[ 21.167680] ? __lock_acquire+0x272/0x1320
[ 21.169353] alloc_tree_block_no_bg_flush+0x4a/0x60 [btrfs]
[ 21.171313] __btrfs_cow_block+0x143/0x7a0 [btrfs]
[ 21.173080] btrfs_cow_block+0x15f/0x310 [btrfs]
[ 21.174487] btrfs_search_slot+0x93b/0xf70 [btrfs]
[ 21.175940] btrfs_lookup_inode+0x3a/0xc0 [btrfs]
[ 21.177419] ? __btrfs_commit_inode_delayed_items+0x417/0x4e0 [btrfs]
[ 21.179032] ? __btrfs_commit_inode_delayed_items+0x44c/0x4e0 [btrfs]
[ 21.180787] __btrfs_update_delayed_inode+0x73/0x260 [btrfs]
[ 21.182174] __btrfs_commit_inode_delayed_items+0x46c/0x4e0 [btrfs]
[ 21.183907] ? btrfs_first_delayed_node+0x4c/0x90 [btrfs]
[ 21.185204] __btrfs_run_delayed_items+0x8e/0x140 [btrfs]
[ 21.186521] btrfs_commit_transaction+0x312/0xae0 [btrfs]
[ 21.188142] ? btrfs_attach_transaction_barrier+0x1f/0x50 [btrfs]
[ 21.189684] sync_filesystem+0x6e/0x90
[ 21.190878] generic_shutdown_super+0x22/0x100
[ 21.192693] kill_anon_super+0x14/0x30
[ 21.194389] btrfs_kill_super+0x12/0x20 [btrfs]
[ 21.196078] deactivate_locked_super+0x2c/0x70
[ 21.197732] cleanup_mnt+0x100/0x160
[ 21.199033] task_work_run+0x90/0xc0
[ 21.200331] exit_to_usermode_loop+0x96/0xa0
[ 21.201744] do_syscall_64+0x1df/0x210
[ 21.203187] entry_SYSCALL_64_after_hwframe+0x49/0xbe
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v2] drm/i915/ehl: Donot reuse icl get and put dplls
From: Lucas De Marchi @ 2020-02-20 17:55 UTC (permalink / raw)
To: Radhakrishna Sripada; +Cc: intel-gfx
In-Reply-To: <20200220003250.23248-1-radhakrishna.sripada@intel.com>
On Wed, Feb 19, 2020 at 04:32:50PM -0800, Radhakrishna Sripada wrote:
>Elkhartlake does not have as many PLL combinations as Icelake.
>Use a simpler get pll function and reuse intel_put_pll for ehl.
>
>v2: Fix the build error
>
>Suggested-by: Matt Roper <matthew.d.roper@intel.com>
>Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>---
> drivers/gpu/drm/i915/display/intel_display.c | 11 +++-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 57 +++++++++++++++----
> 2 files changed, 54 insertions(+), 14 deletions(-)
but is it changing the pll assigments? is it fixing anything? That's
what important to know in the commit message. By the
insertion/deletions, doesn't really look simpler if previous code was
working.
>
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
>index ee7d54ccd3e6..9bb6ccb5b3ea 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -10763,10 +10763,15 @@ static void icl_get_ddi_pll(struct drm_i915_private *dev_priv, enum port port,
> return;
> }
>
>- pipe_config->icl_port_dplls[port_dpll_id].pll =
>- intel_get_shared_dpll_by_id(dev_priv, id);
>+ if (!IS_ELKHARTLAKE(dev_priv)) {
>+ pipe_config->icl_port_dplls[port_dpll_id].pll =
>+ intel_get_shared_dpll_by_id(dev_priv, id);
>
>- icl_set_active_port_dpll(pipe_config, port_dpll_id);
>+ icl_set_active_port_dpll(pipe_config, port_dpll_id);
>+ } else {
>+ pipe_config->shared_dpll =
>+ intel_get_shared_dpll_by_id(dev_priv, id);
isn't this change independent and the real change ?
Lucas De Marchi
>+ }
> }
>
> static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
>diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>index e5bfe5245276..6092abc2b875 100644
>--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>@@ -3016,8 +3016,7 @@ static bool icl_get_combo_phy_dpll(struct intel_atomic_state *state,
> intel_atomic_get_new_crtc_state(state, crtc);
> struct icl_port_dpll *port_dpll =
> &crtc_state->icl_port_dplls[ICL_PORT_DPLL_DEFAULT];
>- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>- enum port port = encoder->port;
>+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> unsigned long dpll_mask;
>
> if (!icl_calc_dpll_state(crtc_state, encoder, &port_dpll->hw_state)) {
>@@ -3027,13 +3026,7 @@ static bool icl_get_combo_phy_dpll(struct intel_atomic_state *state,
> return false;
> }
>
>- if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
>- dpll_mask =
>- BIT(DPLL_ID_EHL_DPLL4) |
>- BIT(DPLL_ID_ICL_DPLL1) |
>- BIT(DPLL_ID_ICL_DPLL0);
>- else
>- dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
>+ dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
>
> port_dpll->pll = intel_find_shared_dpll(state, crtc,
> &port_dpll->hw_state,
>@@ -3154,6 +3147,48 @@ static void icl_put_dplls(struct intel_atomic_state *state,
> }
> }
>
>+static bool ehl_get_dpll(struct intel_atomic_state *state,
>+ struct intel_crtc *crtc,
>+ struct intel_encoder *encoder)
>+{
>+ struct intel_crtc_state *crtc_state =
>+ intel_atomic_get_new_crtc_state(state, crtc);
>+ struct intel_shared_dpll *pll;
>+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>+ enum port port = encoder->port;
>+ unsigned long dpll_mask;
>+
>+
>+ if (!icl_calc_dpll_state(crtc_state, encoder, &crtc_state->dpll_hw_state)) {
>+ DRM_DEBUG_KMS("Could not calculate combo PHY PLL state.\n");
>+
>+ return false;
>+ }
>+
>+ if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
>+ dpll_mask =
>+ BIT(DPLL_ID_EHL_DPLL4) |
>+ BIT(DPLL_ID_ICL_DPLL1) |
>+ BIT(DPLL_ID_ICL_DPLL0);
>+ else
>+ dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
>+
>+ pll = intel_find_shared_dpll(state, crtc,
>+ &crtc_state->dpll_hw_state,
>+ dpll_mask);
>+ if (!pll) {
>+ DRM_DEBUG_KMS("No PLL selected\n");
>+ return false;
>+ }
>+
>+ intel_reference_shared_dpll(state, crtc,
>+ pll, &crtc_state->dpll_hw_state);
>+
>+ crtc_state->shared_dpll = pll;
>+
>+ return true;
>+}
>+
> static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll,
> struct intel_dpll_hw_state *hw_state)
>@@ -3751,8 +3786,8 @@ static const struct dpll_info ehl_plls[] = {
>
> static const struct intel_dpll_mgr ehl_pll_mgr = {
> .dpll_info = ehl_plls,
>- .get_dplls = icl_get_dplls,
>- .put_dplls = icl_put_dplls,
>+ .get_dplls = ehl_get_dpll,
>+ .put_dplls = intel_put_dpll,
> .dump_hw_state = icl_dump_hw_state,
> };
>
>--
>2.20.1
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 11/19] target/arm: Replace ARM_FEATURE_VFP4 with isar_feature_aa32_simdfmac
From: Richard Henderson @ 2020-02-20 17:55 UTC (permalink / raw)
To: Peter Maydell; +Cc: QEMU Developers
In-Reply-To: <CAFEAcA-fDx8HAFcgx57FhnpHPY6GnC1PxRRW=sLRY=5dDysfiQ@mail.gmail.com>
On 2/20/20 8:37 AM, Peter Maydell wrote:
> This is tricky, because the SIMDFMAC register
> field indicates "do we have fused-multiply-accumulate
> for either VFP or Neon", so in a VFP-no-Neon core or
> a Neon-no-VFP core it will be 1 but can't be used on its
> own as a gate on "should this insn be present".
>
> Currently in the part of arm_cpu_realize() which handles
> the user having selected vfp=off and/or neon=off we
> do allow (for AArch32 cores) both of those combinations.
>
> trans_VFM_dp already tests aa32_fpdp_v2, so I think the
> main thing we need to do is add a test on aa32_fpsp_v2 to
> trans_VFM_sp.
>
> We clear the SIMDFMAC field to 0 in the !has_neon condition,
> and I think that should actually be in the !neon && !vfp part.
>
> I propose to squash in the following and beef up the commit message:
Good catch. Makes sense.
r~
^ permalink raw reply
* Re: [PATCH v2 2/2] hw: move timer_new from init() into realize() to avoid memleaks
From: Peter Maydell @ 2020-02-20 17:56 UTC (permalink / raw)
To: Pan Nengyuan
Cc: zhanghailiang, Philippe Mathieu-Daudé, Alistair Francis,
QEMU Developers, mav2-rk.cave-ayland, qemu-arm, qemu-ppc,
Euler Robot, andrzej zaborowski, David Gibson
In-Reply-To: <20200217032127.46508-3-pannengyuan@huawei.com>
On Mon, 17 Feb 2020 at 03:22, <pannengyuan@huawei.com> wrote:
>
> From: Pan Nengyuan <pannengyuan@huawei.com>
>
> There are some memleaks when we call 'device_list_properties'. This patch move timer_new from init into realize to fix it.
> Meanwhile, do the null check in mos6522_reset() to avoid null deref if we move timer_new into realize().
>
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
> index 19e154b870..980eda7599 100644
> --- a/hw/misc/mos6522.c
> +++ b/hw/misc/mos6522.c
> @@ -465,11 +465,15 @@ static void mos6522_reset(DeviceState *dev)
> s->timers[0].frequency = s->frequency;
> s->timers[0].latch = 0xffff;
> set_counter(s, &s->timers[0], 0xffff);
> - timer_del(s->timers[0].timer);
> + if (s->timers[0].timer) {
> + timer_del(s->timers[0].timer);
> + }
>
> s->timers[1].frequency = s->frequency;
> s->timers[1].latch = 0xffff;
> - timer_del(s->timers[1].timer);
> + if (s->timers[1].timer) {
> + timer_del(s->timers[1].timer);
> + }
> }
What code path calls a device 'reset' method on a device
that has not yet been realized ? I wasn't expecting that
to be valid...
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: panel: lvds: Add properties for clock and data polarities
From: Maxime Ripard @ 2020-02-20 17:57 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Chen-Yu Tsai, dri-devel, Maarten Lankhorst, Sean Paul,
Daniel Vetter, David Airlie, devicetree, Mark Rutland,
Rob Herring, Frank Rowand, Thierry Reding, linux-arm-kernel
In-Reply-To: <20200214161156.GA18287@ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 2740 bytes --]
On Fri, Feb 14, 2020 at 05:11:56PM +0100, Sam Ravnborg wrote:
> Hi Maxime.
>
> On Fri, Feb 14, 2020 at 01:24:39PM +0100, Maxime Ripard wrote:
> > Some LVDS encoders can support multiple polarities on the data and
> > clock lanes, and similarly some panels require a given polarity on
> > their inputs. Add a property on the panel to configure the encoder
> > properly.
> >
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>
> Not a fan of this binding...
> In display-timing.txt we have a specification/description of
> the panel-timing node.
>
> The panel-timing node already include information such as:
> - hsync-active:
> - vsync-active:
> - de-active:
> - pixelclk-active:
> - syncclk-active:
>
> But clock-active-low and data-active-low refer to the bus
> more than an individual timing.
> So maybe OK not to have it in a panel-timing node.
> But then it would IMO be better to include
> this in the display-timing node - so we make
> this available and standard for all users of the
> display-timing node.
>
> I will dig up my patchset to make proper bindings for panel-timing and
> display-timing this weeked and resend them.
> Then we can discuss if this goes on top or this is specific for the
> lvds binding.
That makes sense, I'll wait for them to be merged then :)
>
> > ---
> > Documentation/devicetree/bindings/display/panel/lvds.yaml | 10 ++++++++-
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > index d0083301acbe..4a1111a1ab38 100644
> > --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > @@ -90,6 +90,16 @@ properties:
> > CTL2: Data Enable
> > CTL3: 0
> >
> > + clock-active-low:
> > + type: boolean
> > + description: >
>
> Should this be "|" and not ">"?
> Did this pass dt_binding_check?
Yes. > means that this is a multi-line string that will drop the \n
between each line, while | will keep it
For a string like this, I believe it makes more sense to let whatever
is using to handle the wrapping, but I don't really have a strong
opinion :)
>
> > + If set, reverse the clock polarity on the clock lane.
> This text could be a bit more specific. If this is set then
> what?
> And it seems strange that a clock is active low.
> For a clock we often talk about raising or falling edge.
>
> > +
> > + data-active-low:
> > + type: boolean
> > + description: >
> Same comment with ">"
>
> > + If set, reverse the bit polarity on all data lanes.
> Same comment about a more explicit description.
I'll try to come up with something better. Thanks!
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] hw: move timer_new from init() into realize() to avoid memleaks
From: Peter Maydell @ 2020-02-20 17:56 UTC (permalink / raw)
To: Pan Nengyuan
Cc: zhanghailiang, Philippe Mathieu-Daudé, Alistair Francis,
QEMU Developers, mav2-rk.cave-ayland, qemu-arm, qemu-ppc,
Euler Robot, Edgar E. Iglesias, David Gibson
In-Reply-To: <20200217032127.46508-3-pannengyuan@huawei.com>
On Mon, 17 Feb 2020 at 03:22, <pannengyuan@huawei.com> wrote:
>
> From: Pan Nengyuan <pannengyuan@huawei.com>
>
> There are some memleaks when we call 'device_list_properties'. This patch move timer_new from init into realize to fix it.
> Meanwhile, do the null check in mos6522_reset() to avoid null deref if we move timer_new into realize().
>
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
> index 19e154b870..980eda7599 100644
> --- a/hw/misc/mos6522.c
> +++ b/hw/misc/mos6522.c
> @@ -465,11 +465,15 @@ static void mos6522_reset(DeviceState *dev)
> s->timers[0].frequency = s->frequency;
> s->timers[0].latch = 0xffff;
> set_counter(s, &s->timers[0], 0xffff);
> - timer_del(s->timers[0].timer);
> + if (s->timers[0].timer) {
> + timer_del(s->timers[0].timer);
> + }
>
> s->timers[1].frequency = s->frequency;
> s->timers[1].latch = 0xffff;
> - timer_del(s->timers[1].timer);
> + if (s->timers[1].timer) {
> + timer_del(s->timers[1].timer);
> + }
> }
What code path calls a device 'reset' method on a device
that has not yet been realized ? I wasn't expecting that
to be valid...
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: panel: lvds: Add properties for clock and data polarities
From: Maxime Ripard @ 2020-02-20 17:57 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Mark Rutland, devicetree, David Airlie, Maarten Lankhorst,
dri-devel, Chen-Yu Tsai, Rob Herring, Sean Paul, Thierry Reding,
Daniel Vetter, Frank Rowand, linux-arm-kernel
In-Reply-To: <20200214161156.GA18287@ravnborg.org>
[-- Attachment #1.1: Type: text/plain, Size: 2740 bytes --]
On Fri, Feb 14, 2020 at 05:11:56PM +0100, Sam Ravnborg wrote:
> Hi Maxime.
>
> On Fri, Feb 14, 2020 at 01:24:39PM +0100, Maxime Ripard wrote:
> > Some LVDS encoders can support multiple polarities on the data and
> > clock lanes, and similarly some panels require a given polarity on
> > their inputs. Add a property on the panel to configure the encoder
> > properly.
> >
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>
> Not a fan of this binding...
> In display-timing.txt we have a specification/description of
> the panel-timing node.
>
> The panel-timing node already include information such as:
> - hsync-active:
> - vsync-active:
> - de-active:
> - pixelclk-active:
> - syncclk-active:
>
> But clock-active-low and data-active-low refer to the bus
> more than an individual timing.
> So maybe OK not to have it in a panel-timing node.
> But then it would IMO be better to include
> this in the display-timing node - so we make
> this available and standard for all users of the
> display-timing node.
>
> I will dig up my patchset to make proper bindings for panel-timing and
> display-timing this weeked and resend them.
> Then we can discuss if this goes on top or this is specific for the
> lvds binding.
That makes sense, I'll wait for them to be merged then :)
>
> > ---
> > Documentation/devicetree/bindings/display/panel/lvds.yaml | 10 ++++++++-
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > index d0083301acbe..4a1111a1ab38 100644
> > --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > @@ -90,6 +90,16 @@ properties:
> > CTL2: Data Enable
> > CTL3: 0
> >
> > + clock-active-low:
> > + type: boolean
> > + description: >
>
> Should this be "|" and not ">"?
> Did this pass dt_binding_check?
Yes. > means that this is a multi-line string that will drop the \n
between each line, while | will keep it
For a string like this, I believe it makes more sense to let whatever
is using to handle the wrapping, but I don't really have a strong
opinion :)
>
> > + If set, reverse the clock polarity on the clock lane.
> This text could be a bit more specific. If this is set then
> what?
> And it seems strange that a clock is active low.
> For a clock we often talk about raising or falling edge.
>
> > +
> > + data-active-low:
> > + type: boolean
> > + description: >
> Same comment with ">"
>
> > + If set, reverse the bit polarity on all data lanes.
> Same comment about a more explicit description.
I'll try to come up with something better. Thanks!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Tony Lindgren @ 2020-02-20 17:57 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <281e895b-720d-5bab-63cf-8b3e389dc767@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3728 bytes --]
* Andrew F. Davis <afd@ti.com> [200220 17:39]:
> On 2/20/20 12:13 PM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [200220 16:37]:
> >> * Andrew F. Davis <afd@ti.com> [200220 16:24]:
> >>> On 2/20/20 11:20 AM, Tony Lindgren wrote:
> >>>> * Andrew F. Davis <afd@ti.com> [200220 16:04]:
> >>>>> On 2/20/20 10:54 AM, Tony Lindgren wrote:
> >>>>>> Andrew,
> >>>>>>
> >>>>>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
> >>>>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>>>>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
> >>>>>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
> >>>>>>> date: 3 weeks ago
> >>>>>>> config: arm-randconfig-a001-20200213 (attached as .config)
> >>>>>>> compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
> >>>>>>> reproduce:
> >>>>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >>>>>>> chmod +x ~/bin/make.cross
> >>>>>>> git checkout c37baa06f8a970e4a533d41f7d33e5e57de5ad25
> >>>>>>> # save the attached .config to linux build tree
> >>>>>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
> >>>>>>>
> >>>>>>> If you fix the issue, kindly add following tag
> >>>>>>> Reported-by: kbuild test robot <lkp@intel.com>
> >>>>>>>
> >>>>>>> All errors (new ones prefixed by >>):
> >>>>>>>
> >>>>>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
> >>>>>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
> >>>>>>
> >>>>>> Have you looked at this one? Looks like there's still an unhandled
> >>>>>> randconfig build case.
> >>>>>>
> >>>>>
> >>>>>
> >>>>> I've had a quick look, all the ARM config does:
> >>>>>
> >>>>> select HAVE_ARM_SMCCC if CPU_V7
> >>>>>
> >>>>> so I don't think this will happen in any real config, but if we want to
> >>>>> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
> >>>>> on it.
> >>>>
> >>>> Seems to happen at least with omap2 only config where we don't have
> >>>> CPU_V7. Something like below seems to fix it.
> >>>>
> >>>> If that looks OK to you, I'll send out a proper fix.
> >>>>
> >>>
> >>>
> >>> This looks fine to me.
> >>>
> >>> A better later fix might be to later stub out the actual __arm_smccc_smc
> >>> in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
> >>> get the fix.
> >>
> >> Yeah seems that might be better. Adding Aaro and Marc to Cc.
> >
> > But if we can in theory have some arm11 machine with smccc, then this
> > local ifdef below is probably the way to go.
> >
>
> If the machine has SMCCC then it will also have the
> CONFIG_HAVE_ARM_SMCCC set and so nothing would change.
Hmm yeah good point.
Regards,
Tony
> >>>> 8< -----------------------
> >>>> diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> >>>> --- a/arch/arm/mach-omap2/omap-secure.c
> >>>> +++ b/arch/arm/mach-omap2/omap-secure.c
> >>>> @@ -77,6 +77,7 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
> >>>> return ret;
> >>>> }
> >>>>
> >>>> +#ifdef CONFIG_HAVE_ARM_SMCCC
> >>>> void omap_smccc_smc(u32 fn, u32 arg)
> >>>> {
> >>>> struct arm_smccc_res res;
> >>>> @@ -85,6 +86,11 @@ void omap_smccc_smc(u32 fn, u32 arg)
> >>>> 0, 0, 0, 0, 0, 0, &res);
> >>>> WARN(res.a0, "Secure function call 0x%08x failed\n", fn);
> >>>> }
> >>>> +#else
> >>>> +void omap_smccc_smc(u32 fn, u32 arg)
> >>>> +{
> >>>> +}
> >>>> +#endif
> >>>>
> >>>> void omap_smc1(u32 fn, u32 arg)
> >>>> {
> >>>>
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Tony Lindgren @ 2020-02-20 17:57 UTC (permalink / raw)
To: Andrew F. Davis
Cc: kbuild-all, linux-kernel, kbuild test robot, linux-omap,
Aaro Koskinen, Marc Zyngier, linux-arm-kernel
In-Reply-To: <281e895b-720d-5bab-63cf-8b3e389dc767@ti.com>
* Andrew F. Davis <afd@ti.com> [200220 17:39]:
> On 2/20/20 12:13 PM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [200220 16:37]:
> >> * Andrew F. Davis <afd@ti.com> [200220 16:24]:
> >>> On 2/20/20 11:20 AM, Tony Lindgren wrote:
> >>>> * Andrew F. Davis <afd@ti.com> [200220 16:04]:
> >>>>> On 2/20/20 10:54 AM, Tony Lindgren wrote:
> >>>>>> Andrew,
> >>>>>>
> >>>>>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
> >>>>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>>>>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
> >>>>>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
> >>>>>>> date: 3 weeks ago
> >>>>>>> config: arm-randconfig-a001-20200213 (attached as .config)
> >>>>>>> compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
> >>>>>>> reproduce:
> >>>>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >>>>>>> chmod +x ~/bin/make.cross
> >>>>>>> git checkout c37baa06f8a970e4a533d41f7d33e5e57de5ad25
> >>>>>>> # save the attached .config to linux build tree
> >>>>>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
> >>>>>>>
> >>>>>>> If you fix the issue, kindly add following tag
> >>>>>>> Reported-by: kbuild test robot <lkp@intel.com>
> >>>>>>>
> >>>>>>> All errors (new ones prefixed by >>):
> >>>>>>>
> >>>>>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
> >>>>>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
> >>>>>>
> >>>>>> Have you looked at this one? Looks like there's still an unhandled
> >>>>>> randconfig build case.
> >>>>>>
> >>>>>
> >>>>>
> >>>>> I've had a quick look, all the ARM config does:
> >>>>>
> >>>>> select HAVE_ARM_SMCCC if CPU_V7
> >>>>>
> >>>>> so I don't think this will happen in any real config, but if we want to
> >>>>> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
> >>>>> on it.
> >>>>
> >>>> Seems to happen at least with omap2 only config where we don't have
> >>>> CPU_V7. Something like below seems to fix it.
> >>>>
> >>>> If that looks OK to you, I'll send out a proper fix.
> >>>>
> >>>
> >>>
> >>> This looks fine to me.
> >>>
> >>> A better later fix might be to later stub out the actual __arm_smccc_smc
> >>> in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
> >>> get the fix.
> >>
> >> Yeah seems that might be better. Adding Aaro and Marc to Cc.
> >
> > But if we can in theory have some arm11 machine with smccc, then this
> > local ifdef below is probably the way to go.
> >
>
> If the machine has SMCCC then it will also have the
> CONFIG_HAVE_ARM_SMCCC set and so nothing would change.
Hmm yeah good point.
Regards,
Tony
> >>>> 8< -----------------------
> >>>> diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> >>>> --- a/arch/arm/mach-omap2/omap-secure.c
> >>>> +++ b/arch/arm/mach-omap2/omap-secure.c
> >>>> @@ -77,6 +77,7 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
> >>>> return ret;
> >>>> }
> >>>>
> >>>> +#ifdef CONFIG_HAVE_ARM_SMCCC
> >>>> void omap_smccc_smc(u32 fn, u32 arg)
> >>>> {
> >>>> struct arm_smccc_res res;
> >>>> @@ -85,6 +86,11 @@ void omap_smccc_smc(u32 fn, u32 arg)
> >>>> 0, 0, 0, 0, 0, 0, &res);
> >>>> WARN(res.a0, "Secure function call 0x%08x failed\n", fn);
> >>>> }
> >>>> +#else
> >>>> +void omap_smccc_smc(u32 fn, u32 arg)
> >>>> +{
> >>>> +}
> >>>> +#endif
> >>>>
> >>>> void omap_smc1(u32 fn, u32 arg)
> >>>> {
> >>>>
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Tony Lindgren @ 2020-02-20 17:57 UTC (permalink / raw)
To: Andrew F. Davis
Cc: kbuild-all, kbuild test robot, Aaro Koskinen, Marc Zyngier,
linux-kernel, linux-omap, linux-arm-kernel
In-Reply-To: <281e895b-720d-5bab-63cf-8b3e389dc767@ti.com>
* Andrew F. Davis <afd@ti.com> [200220 17:39]:
> On 2/20/20 12:13 PM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [200220 16:37]:
> >> * Andrew F. Davis <afd@ti.com> [200220 16:24]:
> >>> On 2/20/20 11:20 AM, Tony Lindgren wrote:
> >>>> * Andrew F. Davis <afd@ti.com> [200220 16:04]:
> >>>>> On 2/20/20 10:54 AM, Tony Lindgren wrote:
> >>>>>> Andrew,
> >>>>>>
> >>>>>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
> >>>>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>>>>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
> >>>>>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
> >>>>>>> date: 3 weeks ago
> >>>>>>> config: arm-randconfig-a001-20200213 (attached as .config)
> >>>>>>> compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
> >>>>>>> reproduce:
> >>>>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >>>>>>> chmod +x ~/bin/make.cross
> >>>>>>> git checkout c37baa06f8a970e4a533d41f7d33e5e57de5ad25
> >>>>>>> # save the attached .config to linux build tree
> >>>>>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
> >>>>>>>
> >>>>>>> If you fix the issue, kindly add following tag
> >>>>>>> Reported-by: kbuild test robot <lkp@intel.com>
> >>>>>>>
> >>>>>>> All errors (new ones prefixed by >>):
> >>>>>>>
> >>>>>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
> >>>>>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
> >>>>>>
> >>>>>> Have you looked at this one? Looks like there's still an unhandled
> >>>>>> randconfig build case.
> >>>>>>
> >>>>>
> >>>>>
> >>>>> I've had a quick look, all the ARM config does:
> >>>>>
> >>>>> select HAVE_ARM_SMCCC if CPU_V7
> >>>>>
> >>>>> so I don't think this will happen in any real config, but if we want to
> >>>>> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
> >>>>> on it.
> >>>>
> >>>> Seems to happen at least with omap2 only config where we don't have
> >>>> CPU_V7. Something like below seems to fix it.
> >>>>
> >>>> If that looks OK to you, I'll send out a proper fix.
> >>>>
> >>>
> >>>
> >>> This looks fine to me.
> >>>
> >>> A better later fix might be to later stub out the actual __arm_smccc_smc
> >>> in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
> >>> get the fix.
> >>
> >> Yeah seems that might be better. Adding Aaro and Marc to Cc.
> >
> > But if we can in theory have some arm11 machine with smccc, then this
> > local ifdef below is probably the way to go.
> >
>
> If the machine has SMCCC then it will also have the
> CONFIG_HAVE_ARM_SMCCC set and so nothing would change.
Hmm yeah good point.
Regards,
Tony
> >>>> 8< -----------------------
> >>>> diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> >>>> --- a/arch/arm/mach-omap2/omap-secure.c
> >>>> +++ b/arch/arm/mach-omap2/omap-secure.c
> >>>> @@ -77,6 +77,7 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
> >>>> return ret;
> >>>> }
> >>>>
> >>>> +#ifdef CONFIG_HAVE_ARM_SMCCC
> >>>> void omap_smccc_smc(u32 fn, u32 arg)
> >>>> {
> >>>> struct arm_smccc_res res;
> >>>> @@ -85,6 +86,11 @@ void omap_smccc_smc(u32 fn, u32 arg)
> >>>> 0, 0, 0, 0, 0, 0, &res);
> >>>> WARN(res.a0, "Secure function call 0x%08x failed\n", fn);
> >>>> }
> >>>> +#else
> >>>> +void omap_smccc_smc(u32 fn, u32 arg)
> >>>> +{
> >>>> +}
> >>>> +#endif
> >>>>
> >>>> void omap_smc1(u32 fn, u32 arg)
> >>>> {
> >>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [meta-freescale] gstreamer allocation error on imx6dl-sabresd
From: Clay Montgomery @ 2020-02-20 17:35 UTC (permalink / raw)
To: Mauro Ziliani, meta-freescale@yoctoproject.org
In-Reply-To: <aa89da76-2694-9809-37d1-608b17fff76b@faresoftware.it>
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
Hi Mauro,
I would first determine if this problem could be caused by a problem
with gstreamer.
One way to do that would be to run the camera with the
mxc_v4l2_capture.out app that is provided by NXP in their unit tests.
It has some basic support for uvcvideo and runs without gstreamer.
Then you will know if it could really be a kernel problem.
Another approach, would be to try gstreamer on a newer kernel.
Regards, Clay
On 2/6/2020 3:50 AM, Mauro Ziliani wrote:
>
> Hi all.
>
> I'm working on a imx6dl-sabresd derived board, gstreamer, uvcvideo
> webcam, Yocto Freescale i.MX Release Distro 4.1.15-2.0.1 FXMZ /dev/ttymxc0
>
> the pipeline is
>
> gst-launch-1.0 \
> imxv4l2src device=/dev/video1 \
> ! capsfilter caps="video/x-raw, width=640, height=480" \
> ! imxvideoconvert_g2d rotation=4 \
> ! imxv4l2sink overlay-width=800 overlay-height=600
> overlay-left=235 overlay-top=65 enable-last-sample=true name=sink
>
>
> Sometime the webcam freeze. After the first freeze the video stream is
> black and gstream GST_DEBUG=1 show the following message
>
> WARN default gstallocatorphymem.c:259:gst_buffer_is_phymem:
> physical address in memory block is invalid
>
>
> There is some explanation/patch for this behavior?
>
>
> gstreamer 1.8.1
>
> gstreamer-plugin-imx 0.12.2
>
>
> Thanks for your help
>
> MZ
>
>
>
[-- Attachment #2: Type: text/html, Size: 2779 bytes --]
^ permalink raw reply
* Re: [yocto] [psplash][PATCH 1/1] psplash-fb: Avoid racing issues on reading fb0
From: Andrei Gherzan @ 2020-02-20 17:58 UTC (permalink / raw)
To: Khem Raj; +Cc: yocto
In-Reply-To: <6f979b87-756e-207f-0500-a83c6afa07f6@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]
Hi,
On Fri, Feb 14, 2020 at 7:32 AM Khem Raj <raj.khem@gmail.com> wrote:
> On 2/13/20 2:30 AM, Andrei Gherzan wrote:
> > When starting psplash as early as possible in the boot process, the fb
> > device node might not be ready. This patch adds a loop on reading the
> > fb0 device with a timeout of 5 seconds.
> >
> > Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
> > ---
> > psplash-fb.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/psplash-fb.c b/psplash-fb.c
> > index 6603572..6700a3b 100644
> > --- a/psplash-fb.c
> > +++ b/psplash-fb.c
> > @@ -137,6 +137,7 @@ psplash_fb_new (int angle, int fbdev_id)
> > struct fb_fix_screeninfo fb_fix;
> > int off;
> > char fbdev[9] = "/dev/fb0";
> > + int retries = 0;
> >
> > PSplashFB *fb = NULL;
> >
> > @@ -156,7 +157,9 @@ psplash_fb_new (int angle, int fbdev_id)
> >
> > fb->fd = -1;
> >
> > - if ((fb->fd = open (fbdev, O_RDWR)) < 0)
> > + while ((fb->fd = open(fbdev, O_RDWR)) < 0 && retries++ <= 100)
> > + usleep(50000);
> > + if (fb->fd < 0)
>
> i wonder if there should be a different way to ensure this dependency
> perhaps sd_notify for systemd or udev notification maybe ..
>
That makes sense. The only issue is that in my use-case, initramfs doesn't
have systemd. And usually, you will be wanting to run a splash way before
any init system. What is your proposal with udev notifications? Can you
expand that?
Regards,
Andrei
[-- Attachment #2: Type: text/html, Size: 2220 bytes --]
^ permalink raw reply
* [PATCH 0/2] sunxi: clean up defconfig files
From: Maxime Ripard @ 2020-02-20 17:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200220175115.76632-1-andre.przywara@arm.com>
On Thu, Feb 20, 2020 at 05:51:13PM +0000, Andre Przywara wrote:
> With some recent additions and some old cruft, there are some config
> options that were defined in *almost* every board defconfig file for
> Allwinner SoCs.
> This "almost" seems to point to bugs, either those options were missed by
> mistake or failed to properly synchronise (when a new board defconfig
> comes into the tree and just missed some automatic update).
>
> This series defines those common symbols in their respective Kconfig
> files or in the ARCH_SUNXI definition, then removes them from all the
> defconfigs.
>
> This fixes those boards that suffered from a missing definition, also
> cleans up all board defconfigs by moving not-board-specific options out
> of there.
>
> Rationale for why those options are generic are given in the commit
> message of 1/2.
defconfig handling really is a pain, thanks for taking care of this
Acked-by: Maxime Ripard <mripard@kernel.org>
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200220/9106e6e5/attachment.sig>
^ permalink raw reply
* Re: [PATCH 4/8] libxfs: enable tools to check that metadata updates have been committed
From: Brian Foster @ 2020-02-20 17:58 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: sandeen, linux-xfs
In-Reply-To: <20200220164638.GW9506@magnolia>
On Thu, Feb 20, 2020 at 08:46:38AM -0800, Darrick J. Wong wrote:
> On Thu, Feb 20, 2020 at 09:06:12AM -0500, Brian Foster wrote:
> > On Wed, Feb 19, 2020 at 05:42:06PM -0800, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <darrick.wong@oracle.com>
> > >
> > > Add a new function that will ensure that everything we changed has
> > > landed on stable media, and report the results. Subsequent commits will
> > > teach the individual programs to report when things go wrong.
> > >
> > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > > ---
> > > include/xfs_mount.h | 3 +++
> > > libxfs/init.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> > > libxfs/libxfs_io.h | 2 ++
> > > libxfs/rdwr.c | 27 +++++++++++++++++++++++++--
> > > 4 files changed, 73 insertions(+), 2 deletions(-)
> > >
> > >
> > > diff --git a/include/xfs_mount.h b/include/xfs_mount.h
> > > index 29b3cc1b..c80aaf69 100644
> > > --- a/include/xfs_mount.h
> > > +++ b/include/xfs_mount.h
> > > @@ -187,4 +187,7 @@ extern xfs_mount_t *libxfs_mount (xfs_mount_t *, xfs_sb_t *,
> > > extern void libxfs_umount (xfs_mount_t *);
> > > extern void libxfs_rtmount_destroy (xfs_mount_t *);
> > >
> > > +void libxfs_flush_devices(struct xfs_mount *mp, int *datadev, int *logdev,
> > > + int *rtdev);
> > > +
> > > #endif /* __XFS_MOUNT_H__ */
> > > diff --git a/libxfs/init.c b/libxfs/init.c
> > > index a0d4b7f4..d1d3f4df 100644
> > > --- a/libxfs/init.c
> > > +++ b/libxfs/init.c
> > > @@ -569,6 +569,8 @@ libxfs_buftarg_alloc(
> > > }
> > > btp->bt_mount = mp;
> > > btp->dev = dev;
> > > + btp->lost_writes = false;
> > > +
> > > return btp;
> > > }
> > >
> > > @@ -791,6 +793,47 @@ libxfs_rtmount_destroy(xfs_mount_t *mp)
> > > mp->m_rsumip = mp->m_rbmip = NULL;
> > > }
> > >
> > > +static inline int
> > > +libxfs_flush_buftarg(
> > > + struct xfs_buftarg *btp)
> > > +{
> > > + if (btp->lost_writes)
> > > + return -ENOTRECOVERABLE;
> >
> > I'm curious why we'd want to skip the flush just because some writes
> > happened to fail..? I suppose the fs might be borked, but it seems a
> > little strange to at least not try the flush, particularly since we
> > might still flush any of the other two possible devices.
>
> My thinking here was that if the write verifiers (or the pwrite() calls
> themselves) failed then there's no point in telling the disk to flush
> its write cache since we already know it's not in sync with the buffer
> cache.
>
I suppose, but it seems there is some value in flushing what we did
write.. That's effectively historical behavior (since we ignored
errors), right?
> > > +
> > > + return libxfs_blkdev_issue_flush(btp);
> > > +}
> > > +
> > > +/*
> > > + * Purge the buffer cache to write all dirty buffers to disk and free all
> > > + * incore buffers. Buffers that cannot be written will cause the lost_writes
> > > + * flag to be set in the buftarg. If there were no lost writes, flush the
> > > + * device to make sure the writes made it to stable storage.
> > > + *
> > > + * For each device, the return code will be set to -ENOTRECOVERABLE if we
> > > + * couldn't write something to disk; or the results of the block device flush
> > > + * operation.
> >
> > Why not -EIO?
>
> Originally I thought it might be useful to be able to distinguish
> between "dirty buffers never even made it out of the buffer cache" vs.
> "dirty buffers were sent to the disk but the disk sent back media
> errors", though in the end the userspace tools don't make any
> distinction.
>
> That said, looking at this again, maybe I should track write verifier
> failure separately so that we can return EFSCORRUPTED for that?
>
It's not clear to me that anything application level would care much
about verifier failure vs. I/O failure, but I've no objection to doing
something like that either.
Brian
> --D
>
> >
> > Brian
> >
> > > + */
> > > +void
> > > +libxfs_flush_devices(
> > > + struct xfs_mount *mp,
> > > + int *datadev,
> > > + int *logdev,
> > > + int *rtdev)
> > > +{
> > > + *datadev = *logdev = *rtdev = 0;
> > > +
> > > + libxfs_bcache_purge();
> > > +
> > > + if (mp->m_ddev_targp)
> > > + *datadev = libxfs_flush_buftarg(mp->m_ddev_targp);
> > > +
> > > + if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp)
> > > + *logdev = libxfs_flush_buftarg(mp->m_logdev_targp);
> > > +
> > > + if (mp->m_rtdev_targp)
> > > + *rtdev = libxfs_flush_buftarg(mp->m_rtdev_targp);
> > > +}
> > > +
> > > /*
> > > * Release any resource obtained during a mount.
> > > */
> > > diff --git a/libxfs/libxfs_io.h b/libxfs/libxfs_io.h
> > > index 579df52b..fc0fd060 100644
> > > --- a/libxfs/libxfs_io.h
> > > +++ b/libxfs/libxfs_io.h
> > > @@ -23,10 +23,12 @@ struct xfs_perag;
> > > struct xfs_buftarg {
> > > struct xfs_mount *bt_mount;
> > > dev_t dev;
> > > + bool lost_writes;
> > > };
> > >
> > > extern void libxfs_buftarg_init(struct xfs_mount *mp, dev_t ddev,
> > > dev_t logdev, dev_t rtdev);
> > > +int libxfs_blkdev_issue_flush(struct xfs_buftarg *btp);
> > >
> > > #define LIBXFS_BBTOOFF64(bbs) (((xfs_off_t)(bbs)) << BBSHIFT)
> > >
> > > diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c
> > > index 8b47d438..92e497f9 100644
> > > --- a/libxfs/rdwr.c
> > > +++ b/libxfs/rdwr.c
> > > @@ -17,6 +17,7 @@
> > > #include "xfs_inode_fork.h"
> > > #include "xfs_inode.h"
> > > #include "xfs_trans.h"
> > > +#include "libfrog/platform.h"
> > >
> > > #include "libxfs.h" /* for LIBXFS_EXIT_ON_FAILURE */
> > >
> > > @@ -1227,9 +1228,11 @@ libxfs_brelse(
> > >
> > > if (!bp)
> > > return;
> > > - if (bp->b_flags & LIBXFS_B_DIRTY)
> > > + if (bp->b_flags & LIBXFS_B_DIRTY) {
> > > fprintf(stderr,
> > > "releasing dirty buffer to free list!\n");
> > > + bp->b_target->lost_writes = true;
> > > + }
> > >
> > > pthread_mutex_lock(&xfs_buf_freelist.cm_mutex);
> > > list_add(&bp->b_node.cn_mru, &xfs_buf_freelist.cm_list);
> > > @@ -1248,9 +1251,11 @@ libxfs_bulkrelse(
> > > return 0 ;
> > >
> > > list_for_each_entry(bp, list, b_node.cn_mru) {
> > > - if (bp->b_flags & LIBXFS_B_DIRTY)
> > > + if (bp->b_flags & LIBXFS_B_DIRTY) {
> > > fprintf(stderr,
> > > "releasing dirty buffer (bulk) to free list!\n");
> > > + bp->b_target->lost_writes = true;
> > > + }
> > > count++;
> > > }
> > >
> > > @@ -1479,6 +1484,24 @@ libxfs_irele(
> > > kmem_cache_free(xfs_inode_zone, ip);
> > > }
> > >
> > > +/*
> > > + * Flush everything dirty in the kernel and disk write caches to stable media.
> > > + * Returns 0 for success or a negative error code.
> > > + */
> > > +int
> > > +libxfs_blkdev_issue_flush(
> > > + struct xfs_buftarg *btp)
> > > +{
> > > + int fd, ret;
> > > +
> > > + if (btp->dev == 0)
> > > + return 0;
> > > +
> > > + fd = libxfs_device_to_fd(btp->dev);
> > > + ret = platform_flush_device(fd, btp->dev);
> > > + return ret ? -errno : 0;
> > > +}
> > > +
> > > /*
> > > * Write out a buffer list synchronously.
> > > *
> > >
> >
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.