Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
On 2021/3/17 13:48, Christophe Leroy wrote: Le 17/03/2021 à 02:52, Kefeng Wang a écrit : mem_init_print_info() is called in mem_init() on each architecture, and pass NULL argument, so using void argument and move it into mm_init(). Acked-by: Dave Hansen Signed-off-by: Kefeng Wang --- v2: - Cleanup 'str' line suggested by Christophe and ACK arch/alpha/mm/init.c | 1 - arch/arc/mm/init.c | 1 - arch/arm/mm/init.c | 2 -- arch/arm64/mm/init.c | 2 -- arch/csky/mm/init.c | 1 - arch/h8300/mm/init.c | 2 -- arch/hexagon/mm/init.c | 1 - arch/ia64/mm/init.c | 1 - arch/m68k/mm/init.c | 1 - arch/microblaze/mm/init.c | 1 - arch/mips/loongson64/numa.c | 1 - arch/mips/mm/init.c | 1 - arch/mips/sgi-ip27/ip27-memory.c | 1 - arch/nds32/mm/init.c | 1 - arch/nios2/mm/init.c | 1 - arch/openrisc/mm/init.c | 2 -- arch/parisc/mm/init.c | 2 -- arch/powerpc/mm/mem.c | 1 - arch/riscv/mm/init.c | 1 - arch/s390/mm/init.c | 2 -- arch/sh/mm/init.c | 1 - arch/sparc/mm/init_32.c | 2 -- arch/sparc/mm/init_64.c | 1 - arch/um/kernel/mem.c | 1 - arch/x86/mm/init_32.c | 2 -- arch/x86/mm/init_64.c | 2 -- arch/xtensa/mm/init.c | 1 - include/linux/mm.h | 2 +- init/main.c | 1 + mm/page_alloc.c | 10 +- 30 files changed, 7 insertions(+), 42 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 89314651dd62..c2e0b3495c5a 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2373,7 +2373,7 @@ extern unsigned long free_reserved_area(void *start, void *end, int poison, const char *s); extern void adjust_managed_page_count(struct page *page, long count); -extern void mem_init_print_info(const char *str); +extern void mem_init_print_info(void); Sorry I didn't see that in previous patch. 'extern' keyword is pointless for function prototypes and is deprecated, you should remove it. That said, Reviewed-by: Christophe Leroy # focussed on powerpc Thanks, let's wait for more feedback from other architectures, if necessary, will send a new one. extern void reserve_bootmem_region(phys_addr_t start, phys_addr_t end); .
RE: [PATCH v3] ASoC: amd: add support for rt5682 codec in machine driver
> On 3/16/21 8:37 AM, Mukunda,Vijendar wrote:
> >
> >
> > On 15/03/21 9:30 pm, Pierre-Louis Bossart wrote:
> >>
> >>> +static int rt5682_clk_enable(struct snd_pcm_substream *substream) {
> >>> + int ret;
> >>> + struct snd_soc_pcm_runtime *rtd =
> >>> +asoc_substream_to_rtd(substream);
> >>> +
> >>> + /*
> >>> + * Set wclk to 48000 because the rate constraint of this driver
> >>> +is
> >>> + * 48000. ADAU7002 spec: "The ADAU7002 requires a BCLK rate
> >>> +that is
> >>> + * minimum of 64x the LRCLK sample rate." RT5682 is the only
> >>> +clk
> >>> + * source so for all codecs we have to limit bclk to 64X lrclk.
> >>> + */
> >>> + clk_set_rate(rt5682_dai_wclk, 48000);
> >>> + clk_set_rate(rt5682_dai_bclk, 48000 * 64);
> >>> + ret = clk_prepare_enable(rt5682_dai_bclk);
> >>> + if (ret < 0) {
> >>> + dev_err(rtd->dev, "can't enable master clock %d\n", ret);
> >>> + return ret;
> >>> + }
> >>> + return ret;
> >>> +}
> >>
> >> Out of curiosity, is there a reason why you use clk_prepare_enable()
> >> for the bclk but not for the wclk?These changes were shared by codec
> >> vendor as an initial patch.
> > We should use clk_prepare_enable() for wclk not for bclk.
> > We will update and share the new patch.
>
> Well the question remains: if you have two clocks and only enable one, why do
> you need to get two clocks.
>
> Also this patch was modeled after the da7219 case, where the same open
> applies.
The RT5682 could set the wclk and bclk separately.
The bclk could set the different ratios (32/64/128/256).
However, only the wclk of DAI clock has the .prepare callback function to
enable the related power.
The next patch should update the clk_prepare_enable() for wclk.
> --Please consider the environment before printing this e-mail.
Re: [PATCH] dt-bindings: Clean-up undocumented compatible strings
On 17/03/21 1:19 am, Rob Herring wrote:
> Adding checks for undocumented compatible strings reveals a bunch of
> warnings in the DT binding examples. Fix the cases which are typos, just
> a mismatch between the schema and the example, or aren't documented at all.
> In a couple of cases, fixing the compatible revealed some schema errors
> which are fixed.
>
> There's a bunch of others remaining after this which have bindings, but
> those aren't converted to schema yet.
>
> Cc: Stephen Boyd
> Cc: Maxime Ripard
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc: Vinod Koul
> Cc: Alexandre Belloni
> Cc: Jonathan Cameron
> Cc: Pavel Machek
> Cc: Kishon Vijay Abraham I
> Cc: Sebastian Reichel
> Cc: Mark Brown
> Cc: Greg Kroah-Hartman
> Cc: linux-...@vger.kernel.org
> Cc: dmaeng...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-l...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring
Acked-by: Kishon Vijay Abraham I
> ---
> .../clock/allwinner,sun4i-a10-pll1-clk.yaml | 2 +-
> .../bindings/clock/milbeaut-clock.yaml| 12 +
> .../bindings/display/brcm,bcm2835-dsi0.yaml | 6 -
> .../bindings/display/panel/panel-dpi.yaml | 2 +-
> .../devicetree/bindings/dma/qcom,gpi.yaml | 2 +-
> .../devicetree/bindings/i3c/i3c.yaml | 7 ++---
> .../iio/adc/brcm,iproc-static-adc.yaml| 5
> .../iio/gyroscope/nxp,fxas21002c.yaml | 2 +-
> .../bindings/iio/light/upisemi,us5182.yaml| 4 +--
> .../interrupt-controller/loongson,htpic.yaml | 2 +-
> .../devicetree/bindings/leds/leds-lgm.yaml| 26 ---
> .../bindings/phy/ti,phy-j721e-wiz.yaml| 2 +-
> .../bindings/power/supply/cw2015_battery.yaml | 2 +-
> .../bindings/power/supply/power-supply.yaml | 22
> .../devicetree/bindings/serial/serial.yaml| 2 +-
> .../bindings/spi/amlogic,meson-gx-spicc.yaml | 4 +--
> .../bindings/spi/spi-controller.yaml | 21 ---
> .../devicetree/bindings/spi/spi-mux.yaml | 8 ++
> .../devicetree/bindings/spi/st,stm32-spi.yaml | 6 -
> 19 files changed, 58 insertions(+), 79 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml
> b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml
> index e9c4cf834aa7..e5d9d45dab8a 100644
> ---
> a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml
> +++
> b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml
> @@ -44,7 +44,7 @@ examples:
>- |
> clk@1c2 {
> #clock-cells = <0>;
> -compatible = "allwinner,sun4i-a10-pll1";
> +compatible = "allwinner,sun4i-a10-pll1-clk";
> reg = <0x01c2 0x4>;
> clocks = <>;
> clock-output-names = "osc24M";
> diff --git a/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml
> b/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml
> index 0e8b07710451..6d39344d2b70 100644
> --- a/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml
> @@ -18,10 +18,12 @@ description: |
>
> properties:
>compatible:
> -oneOf:
> - - items:
> - - enum:
> - - socionext,milbeaut-m10v-ccu
> +enum:
> + - socionext,milbeaut-m10v-ccu
> +
> + reg:
> +maxItems: 1
> +
>clocks:
> maxItems: 1
> description: external clock
> @@ -41,7 +43,7 @@ examples:
># Clock controller node:
>- |
> m10v-clk-ctrl@1d021000 {
> -compatible = "socionext,milbeaut-m10v-clk-ccu";
> +compatible = "socionext,milbeaut-m10v-ccu";
> reg = <0x1d021000 0x4000>;
> #clock-cells = <1>;
> clocks = <>;
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> index 55c60919991f..32608578a352 100644
> --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> @@ -77,12 +77,6 @@ examples:
>
> clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr";
>
> -pitouchscreen: panel@0 {
> -compatible = "raspberrypi,touchscreen";
> -reg = <0>;
> -
> -/* ... */
> -};
> };
>
> ...
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> index 0cd74c8dab42..dae0676b5c6e 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> @@ -40,7 +40,7 @@ additionalProperties: false
> examples:
>- |
> panel {
> -compatible =
[PATCH] virtio_net: replace if (cond) BUG() with BUG_ON()
Fix the following coccicheck warnings: ./drivers/net/virtio_net.c:1551:2-5: WARNING: Use BUG_ON instead of if condition followed by BUG. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/net/virtio_net.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 82e520d..093530b 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1545,10 +1545,8 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) else hdr = skb_vnet_hdr(skb); - if (virtio_net_hdr_from_skb(skb, >hdr, - virtio_is_little_endian(vi->vdev), false, - 0)) - BUG(); + BUG_ON(virtio_net_hdr_from_skb(skb, >hdr, virtio_is_little_endian(vi->vdev), + false, 0)); if (vi->mergeable_rx_bufs) hdr->num_buffers = 0; -- 1.8.3.1
Re: [PATCH] dt-bindings: Clean-up undocumented compatible strings
On Tue, Mar 16, 2021 at 01:49:18PM -0600, Rob Herring wrote: > Adding checks for undocumented compatible strings reveals a bunch of > warnings in the DT binding examples. Fix the cases which are typos, just > a mismatch between the schema and the example, or aren't documented at all. > In a couple of cases, fixing the compatible revealed some schema errors > which are fixed. > > There's a bunch of others remaining after this which have bindings, but > those aren't converted to schema yet. > > Cc: Stephen Boyd > Cc: Maxime Ripard > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Vinod Koul > Cc: Alexandre Belloni > Cc: Jonathan Cameron > Cc: Pavel Machek > Cc: Kishon Vijay Abraham I > Cc: Sebastian Reichel > Cc: Mark Brown > Cc: Greg Kroah-Hartman > Cc: linux-...@vger.kernel.org > Cc: dmaeng...@vger.kernel.org > Cc: linux-...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Cc: linux-l...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-ser...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring Acked-by: Greg Kroah-Hartman
Re: (subset) [PATCH v2 0/5] mtd: spi-nor: Cleanup patches
On Sat, 6 Mar 2021 11:49:57 +0200, Tudor Ambarus wrote: > Various cleanup patches done while reviewing contributions. > > Tudor Ambarus (5): > mtd: spi-nor: core: Advance erase after the erase cmd has been > completed > mtd: spi-nor: core: Add vdbg msg for spi_nor_erase_multi_sectors() > mtd: spi-nor: Get rid of duplicated argument in spi_nor_parse_sfdp() > mtd: spi-nor: Move Software Write Protection logic out of the core > mtd: spi-nor: swp: Drop 'else' after 'return' > > [...] For 2/5: s/%d/%u and then applied to spi-nor/next 1/5, 2/5 and 3/5. [1/5] mtd: spi-nor: core: Advance erase after the erase cmd has been completed https://git.kernel.org/mtd/c/786a0a75d0f3 [2/5] mtd: spi-nor: core: Add vdbg msg for spi_nor_erase_multi_sectors() https://git.kernel.org/mtd/c/875c3d78 [3/5] mtd: spi-nor: Get rid of duplicated argument in spi_nor_parse_sfdp() https://git.kernel.org/mtd/c/a580293a19fc Best regards, -- Tudor Ambarus
Re: [PATCH] dt-bindings: Drop type references on common properties
On Tue, Mar 16, 2021 at 01:48:58PM -0600, Rob Herring wrote: > Users of common properties shouldn't have a type definition as the > common schemas already have one. Drop all the unnecessary type > references in the tree. > > A meta-schema update to catch these is pending. > > Cc: Nicolas Saenz Julienne > Cc: Maxime Ripard > Cc: Linus Walleij > Cc: Bartosz Golaszewski > Cc: Bjorn Andersson > Cc: Krzysztof Kozlowski > Cc: Marc Kleine-Budde > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Srinivas Kandagatla > Cc: Ohad Ben-Cohen > Cc: Mark Brown > Cc: Cheng-Yi Chiang > Cc: Benson Leung > Cc: Zhang Rui > Cc: Daniel Lezcano > Cc: Greg Kroah-Hartman > Cc: Stefan Wahren > Cc: Masahiro Yamada > Cc: Odelu Kukatla > Cc: Alex Elder > Cc: Suman Anna > Cc: Kuninori Morimoto > Cc: Dmitry Baryshkov > Cc: linux-g...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: linux-remotep...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 5 + > Documentation/devicetree/bindings/arm/cpus.yaml | 2 -- > .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 1 - > .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml| 3 +-- > .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 1 - > .../devicetree/bindings/interconnect/qcom,rpmh.yaml | 1 - > .../bindings/memory-controllers/nvidia,tegra210-emc.yaml | 2 +- > Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml | 1 - > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 - > Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml | 2 -- > .../devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml | 2 +- > Documentation/devicetree/bindings/sound/ak4642.yaml | 2 -- > .../devicetree/bindings/sound/google,cros-ec-codec.yaml | 2 +- > Documentation/devicetree/bindings/sound/renesas,rsnd.yaml| 1 - > .../devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml | 1 - > Documentation/devicetree/bindings/usb/usb.yaml | 1 - > 16 files changed, 5 insertions(+), 23 deletions(-) Acked-by: Greg Kroah-Hartman
Re: [PATCH] mtd: spi-nor: Update comment about the default flash parameters
On Mon, 15 Mar 2021 07:56:34 +0200, Tudor Ambarus wrote: > s/legacy/default. spi_nor_info_init_params initializes some default > flash parameters and settings that can be overwritten when parsing > SFDP, or by fixup hooks. There's nothing legacy about them, they are > just some default settings, if not otherwise discovered or specified. Applied to spi-nor/next, thanks! [1/1] mtd: spi-nor: Update comment about the default flash parameters https://git.kernel.org/mtd/c/79321e752aff Best regards, -- Tudor Ambarus
Re: [PATCH v2] scsi: dt-bindings: ufs: Add sm8250, sm8350 compatible strings
Hello Martin, On 16-03-21, 21:21, Martin K. Petersen wrote: > > Vinod, > > >> Document "qcom,sm8250-ufshc" and "qcom,sm8350-ufshc" compatible string. > >> Use of "qcom,sm8250-ufshc" is already present upstream, so add misiing > >> documentation. "qcom,sm8350-ufshc" is for UFS HC found in SM8350 SoC. > > > > Gentle reminder for this patch, Rob has acked this > > Was not really expecting a DT patch to be routed through SCSI. But no > worries. I've queued it up. Thank you. You can blame MAINTAINERS for pointing it to you :) Typically DT binding go thru subsystem and dts thru soc trees -- ~Vinod
[syzbot] KMSAN: uninit-value in iptable_mangle_hook (5)
Hello, syzbot found the following issue on: HEAD commit:29ad81a1 arch/x86: add missing include to sparsemem.h git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=179b38f6d0 kernel config: https://syzkaller.appspot.com/x/.config?x=8b976581f6bd1e7d dashboard link: https://syzkaller.appspot.com/bug?extid=9b5e12c49c015d4c1aeb compiler: Debian clang version 11.0.1-2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+9b5e12c49c015d4c1...@syzkaller.appspotmail.com netlink: 24 bytes leftover after parsing attributes in process `syz-executor.4'. = BUG: KMSAN: uninit-value in ipt_mangle_out net/ipv4/netfilter/iptable_mangle.c:61 [inline] BUG: KMSAN: uninit-value in iptable_mangle_hook+0x75a/0x8c0 net/ipv4/netfilter/iptable_mangle.c:81 CPU: 1 PID: 25792 Comm: syz-executor.4 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:120 kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 ipt_mangle_out net/ipv4/netfilter/iptable_mangle.c:61 [inline] iptable_mangle_hook+0x75a/0x8c0 net/ipv4/netfilter/iptable_mangle.c:81 nf_hook_entry_hookfn include/linux/netfilter.h:136 [inline] nf_hook_slow+0x17b/0x460 net/netfilter/core.c:589 nf_hook include/linux/netfilter.h:256 [inline] __ip_local_out+0x78c/0x840 net/ipv4/ip_output.c:115 ip_local_out+0xa1/0x1e0 net/ipv4/ip_output.c:124 iptunnel_xmit+0x931/0xf20 net/ipv4/ip_tunnel_core.c:82 udp_tunnel_xmit_skb+0x526/0x640 net/ipv4/udp_tunnel_core.c:190 geneve_xmit_skb drivers/net/geneve.c:959 [inline] geneve_xmit+0x209e/0x3c20 drivers/net/geneve.c:1059 __netdev_start_xmit include/linux/netdevice.h:4778 [inline] netdev_start_xmit include/linux/netdevice.h:4792 [inline] xmit_one+0x2b6/0x760 net/core/dev.c:3574 dev_hard_start_xmit net/core/dev.c:3590 [inline] __dev_queue_xmit+0x3426/0x45c0 net/core/dev.c:4151 dev_queue_xmit+0x4b/0x60 net/core/dev.c:4184 packet_snd net/packet/af_packet.c:3006 [inline] packet_sendmsg+0x8778/0x9a60 net/packet/af_packet.c:3031 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] sys_sendmsg+0xcfc/0x12f0 net/socket.c:2345 ___sys_sendmsg net/socket.c:2399 [inline] __sys_sendmsg+0x714/0x830 net/socket.c:2432 __do_sys_sendmsg net/socket.c:2441 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2439 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2439 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x465f69 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7fae1692d188 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0056bf60 RCX: 00465f69 RDX: 8844 RSI: 25c0 RDI: 0003 RBP: 004bfa8f R08: R09: R10: R11: 0246 R12: 0056bf60 R13: 00a9fb1f R14: 7fae1692d300 R15: 00022000 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 iptunnel_xmit+0xbd6/0xf20 net/ipv4/ip_tunnel_core.c:76 udp_tunnel_xmit_skb+0x526/0x640 net/ipv4/udp_tunnel_core.c:190 geneve_xmit_skb drivers/net/geneve.c:959 [inline] geneve_xmit+0x209e/0x3c20 drivers/net/geneve.c:1059 __netdev_start_xmit include/linux/netdevice.h:4778 [inline] netdev_start_xmit include/linux/netdevice.h:4792 [inline] xmit_one+0x2b6/0x760 net/core/dev.c:3574 dev_hard_start_xmit net/core/dev.c:3590 [inline] __dev_queue_xmit+0x3426/0x45c0 net/core/dev.c:4151 dev_queue_xmit+0x4b/0x60 net/core/dev.c:4184 packet_snd net/packet/af_packet.c:3006 [inline] packet_sendmsg+0x8778/0x9a60 net/packet/af_packet.c:3031 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] sys_sendmsg+0xcfc/0x12f0 net/socket.c:2345 ___sys_sendmsg net/socket.c:2399 [inline] __sys_sendmsg+0x714/0x830 net/socket.c:2432 __do_sys_sendmsg net/socket.c:2441 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2439 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2439 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_poison_shadow+0x5c/0xf0 mm/kmsan/kmsan.c:104 kmsan_slab_alloc+0x8d/0xe0 mm/kmsan/kmsan_hooks.c:76 slab_alloc_node
Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
Le 17/03/2021 à 02:52, Kefeng Wang a écrit : mem_init_print_info() is called in mem_init() on each architecture, and pass NULL argument, so using void argument and move it into mm_init(). Acked-by: Dave Hansen Signed-off-by: Kefeng Wang --- v2: - Cleanup 'str' line suggested by Christophe and ACK arch/alpha/mm/init.c | 1 - arch/arc/mm/init.c | 1 - arch/arm/mm/init.c | 2 -- arch/arm64/mm/init.c | 2 -- arch/csky/mm/init.c | 1 - arch/h8300/mm/init.c | 2 -- arch/hexagon/mm/init.c | 1 - arch/ia64/mm/init.c | 1 - arch/m68k/mm/init.c | 1 - arch/microblaze/mm/init.c| 1 - arch/mips/loongson64/numa.c | 1 - arch/mips/mm/init.c | 1 - arch/mips/sgi-ip27/ip27-memory.c | 1 - arch/nds32/mm/init.c | 1 - arch/nios2/mm/init.c | 1 - arch/openrisc/mm/init.c | 2 -- arch/parisc/mm/init.c| 2 -- arch/powerpc/mm/mem.c| 1 - arch/riscv/mm/init.c | 1 - arch/s390/mm/init.c | 2 -- arch/sh/mm/init.c| 1 - arch/sparc/mm/init_32.c | 2 -- arch/sparc/mm/init_64.c | 1 - arch/um/kernel/mem.c | 1 - arch/x86/mm/init_32.c| 2 -- arch/x86/mm/init_64.c| 2 -- arch/xtensa/mm/init.c| 1 - include/linux/mm.h | 2 +- init/main.c | 1 + mm/page_alloc.c | 10 +- 30 files changed, 7 insertions(+), 42 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 89314651dd62..c2e0b3495c5a 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2373,7 +2373,7 @@ extern unsigned long free_reserved_area(void *start, void *end, int poison, const char *s); extern void adjust_managed_page_count(struct page *page, long count); -extern void mem_init_print_info(const char *str); +extern void mem_init_print_info(void); Sorry I didn't see that in previous patch. 'extern' keyword is pointless for function prototypes and is deprecated, you should remove it. That said, Reviewed-by: Christophe Leroy # focussed on powerpc extern void reserve_bootmem_region(phys_addr_t start, phys_addr_t end);
RE: Re: [PATCH v5 05/10] scsi: ufshpb: Region inactivation in host mode
>> >> ---
>> >> drivers/scsi/ufs/ufshpb.c | 14 ++
>> >> drivers/scsi/ufs/ufshpb.h | 1 +
>> >> 2 files changed, 15 insertions(+)
>> >>
>> >> diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
>> >> index 6f4fd22eaf2f..0744feb4d484 100644
>> >> --- a/drivers/scsi/ufs/ufshpb.c
>> >> +++ b/drivers/scsi/ufs/ufshpb.c
>> >> @@ -907,6 +907,7 @@ static int ufshpb_execute_umap_req(struct
>> >> ufshpb_lu *hpb,
>> >>
>> >> blk_execute_rq_nowait(q, NULL, req, 1, ufshpb_umap_req_compl_fn);
>> >>
>> >> +hpb->stats.umap_req_cnt++;
>> >> return 0;
>> >> }
>> >>
>> >> @@ -1103,6 +1104,12 @@ static int ufshpb_issue_umap_req(struct
>> >> ufshpb_lu *hpb,
>> >> return -EAGAIN;
>> >> }
>> >>
>> >> +static int ufshpb_issue_umap_single_req(struct ufshpb_lu *hpb,
>> >> +struct ufshpb_region *rgn)
>> >> +{
>> >> +return ufshpb_issue_umap_req(hpb, rgn);
>> >> +}
>> >> +
>> >> static int ufshpb_issue_umap_all_req(struct ufshpb_lu *hpb)
>> >> {
>> >> return ufshpb_issue_umap_req(hpb, NULL);
>> >> @@ -1115,6 +1122,10 @@ static void __ufshpb_evict_region(struct
>> >> ufshpb_lu *hpb,
>> >> struct ufshpb_subregion *srgn;
>> >> int srgn_idx;
>> >>
>> >> +
>> >> +if (hpb->is_hcm && ufshpb_issue_umap_single_req(hpb, rgn))
>> >
>> > __ufshpb_evict_region() is called with rgn_state_lock held and IRQ
>> > disabled,
>> > when ufshpb_issue_umap_single_req() invokes blk_execute_rq_nowait(),
>> > below
>> > warning shall pop up every time, fix it?
>> >
>> > void blk_execute_rq_nowait(struct request_queue *q, struct gendisk
>> > *bd_disk,
>> > struct request *rq, int at_head,
>> > rq_end_io_fn *done)
>> > {
>> > WARN_ON(irqs_disabled());
>> > ...
>> >
>>
>> Moreover, since we are here with rgn_state_lock held and IRQ
>> disabled,
>> in ufshpb_get_req(), rq = kmem_cache_alloc(hpb->map_req_cache,
>> GFP_KERNEL)
>> has the GFP_KERNEL flag, scheduling while atomic???
> I think your comment applies to ufshpb_issue_umap_all_req as well,
> Which is called from slave_configure/scsi_add_lun.
>
> Since the host-mode series is utilizing the framework laid by the
> device-mode,
> Maybe you can add this comment to Daejun's last version?
Hi Avri, Can Guo
I think ufshpb_issue_umap_single_req() can be moved to end of
ufshpb_evict_region().
Then we can avoid rgn_state_lock when it sends unmap command.
>>>
>>> I am not the expert here, please you two fix it. I am just reporting
>>> what can be wrong. Anyways, ufshpb_issue_umap_single_req() should not
>>> be called with rgn_state_lock held - think about below (another
>>> deadly)
>>> scenario.
>>>
>>> lock(rgn_state_lock)
>>> ufshpb_issue_umap_single_req()
>>> ufshpb_prep()
>>>lock(rgn_state_lock) <-- recursive spin_lock
>>>
>>> BTW, @Daejun shouldn't we stop passthrough cmds from stepping
>>> into ufshpb_prep()? In current code, you are trying to use below
>>> check to block cmds other than write/discard/read, but a passthrough
>>> cmd can not be blocked by the check.
>>>
>>> if (!ufshpb_is_write_or_discard_cmd(cmd) &&
>>> !ufshpb_is_read_cmd(cmd) )
>>> return 0;
>>
>> I found this problem too. I fixed it and submit next patch.
>
>You mean in V30, which has not been uploaded yet, right?
Yes, it is about v30.
Thanks,
Daejun
>Thanks,
>Can Guo.
>
>>
>> if (blk_rq_is_scsi(cmd->request) ||
>> (!ufshpb_is_write_or_discard_cmd(cmd) &&
>> !ufshpb_is_read_cmd(cmd)))
>> return 0;
>>
>>
>> Thanks,
>> Daejun
>>
>>> Thanks,
>>> Can Guo.
>>>
Thanks,
Daejun
> Thanks,
> Avri
>
>>
>> Can Guo.
>>
>> > Thanks.
>> > Can Guo.
>> >
>> >> +return;
>> >> +
>> >> lru_info = >lru_info;
>> >>
>> >> dev_dbg(>sdev_ufs_lu->sdev_dev, "evict region %d\n",
>> >> rgn->rgn_idx);
>> >> @@ -1855,6 +1866,7 @@ ufshpb_sysfs_attr_show_func(rb_noti_cnt);
>> >> ufshpb_sysfs_attr_show_func(rb_active_cnt);
>> >> ufshpb_sysfs_attr_show_func(rb_inactive_cnt);
>> >> ufshpb_sysfs_attr_show_func(map_req_cnt);
>> >> +ufshpb_sysfs_attr_show_func(umap_req_cnt);
>> >>
>> >> static struct attribute *hpb_dev_stat_attrs[] = {
>> >> _attr_hit_cnt.attr,
>> >> @@ -1863,6 +1875,7 @@ static struct attribute *hpb_dev_stat_attrs[] =
>> >> {
>> >> _attr_rb_active_cnt.attr,
>> >> _attr_rb_inactive_cnt.attr,
>> >> _attr_map_req_cnt.attr,
>> >> +_attr_umap_req_cnt.attr,
>> >> NULL,
>> >> };
>> >>
>>
[PATCH] KVM: arm: memcg awareness
From: Wanpeng Li
KVM allocations in the arm kvm code which are tied to the life
of the VM process should be charged to the VM process's cgroup.
This will help the memcg controler to do the right decisions.
Signed-off-by: Wanpeng Li
---
arch/arm64/kvm/arm.c | 5 +++--
arch/arm64/kvm/hyp/pgtable.c | 4 ++--
arch/arm64/kvm/mmu.c | 4 ++--
arch/arm64/kvm/pmu-emul.c | 2 +-
arch/arm64/kvm/reset.c | 2 +-
arch/arm64/kvm/vgic/vgic-debug.c | 2 +-
arch/arm64/kvm/vgic/vgic-init.c| 2 +-
arch/arm64/kvm/vgic/vgic-irqfd.c | 2 +-
arch/arm64/kvm/vgic/vgic-its.c | 14 +++---
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 2 +-
arch/arm64/kvm/vgic/vgic-v4.c | 2 +-
11 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7f06ba7..8040874 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -278,9 +278,10 @@ long kvm_arch_dev_ioctl(struct file *filp,
struct kvm *kvm_arch_alloc_vm(void)
{
if (!has_vhe())
- return kzalloc(sizeof(struct kvm), GFP_KERNEL);
+ return kzalloc(sizeof(struct kvm), GFP_KERNEL_ACCOUNT);
- return vzalloc(sizeof(struct kvm));
+ return __vmalloc(sizeof(struct kvm),
+ GFP_KERNEL_ACCOUNT | __GFP_ZERO);
}
void kvm_arch_free_vm(struct kvm *kvm)
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 926fc07..a0845d3 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -366,7 +366,7 @@ static int hyp_map_walker(u64 addr, u64 end, u32 level,
kvm_pte_t *ptep,
if (WARN_ON(level == KVM_PGTABLE_MAX_LEVELS - 1))
return -EINVAL;
- childp = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL);
+ childp = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL_ACCOUNT);
if (!childp)
return -ENOMEM;
@@ -401,7 +401,7 @@ int kvm_pgtable_hyp_init(struct kvm_pgtable *pgt, u32
va_bits)
{
u64 levels = ARM64_HW_PGTABLE_LEVELS(va_bits);
- pgt->pgd = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL);
+ pgt->pgd = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL_ACCOUNT);
if (!pgt->pgd)
return -ENOMEM;
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894..8c9dc49 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -370,7 +370,7 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu
*mmu)
return -EINVAL;
}
- pgt = kzalloc(sizeof(*pgt), GFP_KERNEL);
+ pgt = kzalloc(sizeof(*pgt), GFP_KERNEL_ACCOUNT);
if (!pgt)
return -ENOMEM;
@@ -1244,7 +1244,7 @@ int kvm_mmu_init(void)
goto out;
}
- hyp_pgtable = kzalloc(sizeof(*hyp_pgtable), GFP_KERNEL);
+ hyp_pgtable = kzalloc(sizeof(*hyp_pgtable), GFP_KERNEL_ACCOUNT);
if (!hyp_pgtable) {
kvm_err("Hyp mode page-table not allocated\n");
err = -ENOMEM;
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index e32c6e1..00cf750 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -967,7 +967,7 @@ int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct
kvm_device_attr *attr)
mutex_lock(>kvm->lock);
if (!vcpu->kvm->arch.pmu_filter) {
- vcpu->kvm->arch.pmu_filter = bitmap_alloc(nr_events,
GFP_KERNEL);
+ vcpu->kvm->arch.pmu_filter = bitmap_alloc(nr_events,
GFP_KERNEL_ACCOUNT);
if (!vcpu->kvm->arch.pmu_filter) {
mutex_unlock(>kvm->lock);
return -ENOMEM;
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index bd354cd..3cbcf6b 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -110,7 +110,7 @@ static int kvm_vcpu_finalize_sve(struct kvm_vcpu *vcpu)
vl > SVE_VL_ARCH_MAX))
return -EIO;
- buf = kzalloc(SVE_SIG_REGS_SIZE(sve_vq_from_vl(vl)), GFP_KERNEL);
+ buf = kzalloc(SVE_SIG_REGS_SIZE(sve_vq_from_vl(vl)),
GFP_KERNEL_ACCOUNT);
if (!buf)
return -ENOMEM;
diff --git a/arch/arm64/kvm/vgic/vgic-debug.c b/arch/arm64/kvm/vgic/vgic-debug.c
index f38c40a..e6a01f2 100644
--- a/arch/arm64/kvm/vgic/vgic-debug.c
+++ b/arch/arm64/kvm/vgic/vgic-debug.c
@@ -92,7 +92,7 @@ static void *vgic_debug_start(struct seq_file *s, loff_t *pos)
goto out;
}
- iter = kmalloc(sizeof(*iter), GFP_KERNEL);
+ iter = kmalloc(sizeof(*iter), GFP_KERNEL_ACCOUNT);
if (!iter) {
iter = ERR_PTR(-ENOMEM);
goto out;
diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 052917d..27d1513 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -134,7 +134,7 @@ static int
Re: A problem of Intel IOMMU hardware ？
> On Mar 16, 2021, at 8:16 PM, Longpeng (Mike, Cloud Infrastructure Service > Product Dept.) wrote: > > Hi guys, > > We find the Intel iommu cache (i.e. iotlb) maybe works wrong in a special > situation, it would cause DMA fails or get wrong data. > > The reproducer (based on Alex's vfio testsuite[1]) is in attachment, it can > reproduce the problem with high probability (~50%). I saw Lu replied, and he is much more knowledgable than I am (I was just intrigued by your email). However, if I were you I would try also to remove some “optimizations” to look for the root-cause (e.g., use domain specific invalidations instead of page-specific). The first thing that comes to my mind is the invalidation hint (ih) in iommu_flush_iotlb_psi(). I would remove it to see whether you get the failure without it. signature.asc Description: Message signed with OpenPGP
Re: [net PATCH 3/9] octeontx2-af: Do not allocate memory for devlink private
On Wed, Mar 17, 2021 at 1:57 AM Jakub Kicinski wrote:
>
> On Tue, 16 Mar 2021 23:33:40 +0530 sundeep subbaraya wrote:
> > On Tue, Mar 16, 2021 at 10:53 PM Jakub Kicinski wrote:
> > >
> > > On Tue, 16 Mar 2021 14:57:07 +0530 Hariprasad Kelam wrote:
> > > > From: Subbaraya Sundeep
> > > >
> > > > Memory for driver private structure rvu_devlink is
> > > > also allocated during devlink_alloc. Hence use
> > > > the allocated memory by devlink_alloc and access it
> > > > by devlink_priv call.
> > > >
> > > > Fixes: fae06da4("octeontx2-af: Add devlink suppoort to af driver")
> > > > Signed-off-by: Subbaraya Sundeep
> > > > Signed-off-by: Hariprasad Kelam
> > > > Signed-off-by: Sunil Kovvuri Goutham
> > >
> > > Does it fix any bug? Looks like a coding improvement.
> >
> > Without this we cannot fetch our private struct 'rvu_devlink' from any
> > of the functions in devlink_ops which may get added in future.
>
> "which may get added in future" does not sound like it's fixing
> an existing problem to me :(
>
> If you have particular case where the existing setup is problematic
> please describe it in more detail, or mention what other fix depends
> on this patch. Otherwise sending this one patch for net-next would
> be better IMHO.
Sure will send this one patch to net-next.
Thanks,
Sundeep
Re: [PATCH 04/13] lib: introduce BITS_{FIRST,LAST} macro
On Tue, Mar 16, 2021 at 01:42:45PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 16, 2021 at 09:35:35AM +0100, Rasmus Villemoes wrote:
> > On 16/03/2021 02.54, Yury Norov wrote:
> > > BITMAP_{LAST,FIRST}_WORD_MASK() in linux/bitmap.h duplicates the
> > > functionality of GENMASK(). The scope of BITMAP* macros is wider
> > > than just bitmaps. This patch defines 4 new macros: BITS_FIRST(),
> > > BITS_LAST(), BITS_FIRST_MASK() and BITS_LAST_MASK() in linux/bits.h
> > > on top of GENMASK() and replaces BITMAP_{LAST,FIRST}_WORD_MASK()
> > > to avoid duplication and increase the scope of the macros.
> > >
> > > This change doesn't affect code generation. On ARM64:
> > > scripts/bloat-o-meter vmlinux.before vmlinux
> > > add/remove: 1/2 grow/shrink: 2/0 up/down: 17/-16 (1)
> > > Function old new delta
> > > ethtool_get_drvinfo 900 908 +8
> > > e843419@0cf2_0001309d_7f0 - 8 +8
> > > vermagic 48 49 +1
> > > e843419@0d45_000138bb_f68 8 - -8
> > > e843419@0cc9_00012bce_198c 8 - -8
> >
> > [what on earth are those weird symbols?]
> >
> >
> > > diff --git a/include/linux/bits.h b/include/linux/bits.h
> > > index 7f475d59a097..8c191c29506e 100644
> > > --- a/include/linux/bits.h
> > > +++ b/include/linux/bits.h
> > > @@ -37,6 +37,12 @@
> > > #define GENMASK(h, l) \
> > > (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> > >
> > > +#define BITS_FIRST(nr) GENMASK((nr), 0)
> > > +#define BITS_LAST(nr)GENMASK(BITS_PER_LONG - 1, (nr))
> > > +
> > > +#define BITS_FIRST_MASK(nr) BITS_FIRST((nr) % BITS_PER_LONG)
> > > +#define BITS_LAST_MASK(nr) BITS_LAST((nr) % BITS_PER_LONG)
> >
> > I don't think it's a good idea to propagate the unusual closed-range
> > semantics of GENMASK to those wrappers. Almost all C and kernel code
> > uses the 'inclusive lower bound, exclusive upper bound', and I'd expect
> > BITS_FIRST(5) to result in a word with five bits set, not six. So I
> > think these changes as-is make the code much harder to read and understand.
> >
> > Regardless, please add some comments on the valid input ranges to the
> > macros, whether that ends up being 0 <= nr < BITS_PER_LONG or 0 < nr <=
> > BITS_PER_LONG or whatnot.
> >
> > It would also be much easier to review if you just redefined the
> > BITMAP_LAST_WORD_MASK macros etc. in terms of these new things, so you
> > wouldn't have to do a lot of mechanical changes at the same time as
> > introducing the new ones - especially when those mechanical changes
> > involve adding a "minus 1" everywhere.
>
> I tend to agree with Rasmus here.
OK. All this plus terrible GENMASK(high, low) design, when high goes
first, makes me feel like we need to deprecate GENMASK and propose a
new interface.
What do you think about this:
BITS_FIRST(bitnum) -> [0, bitnum)
BITS_LAST(bitnum) -> [bitnum, BITS_PER_LONG)
BITS_RANGE(begin, end) -> [begin, end)
We can pick BITS_{LAST,FIRST} implementation from existing BITMAP_*_WORD_MASK
analogues, and make the BITS_RANGE like:
#define BITS_RANGE(begin, end) BITS_FIRST(end) & BITS_LAST(begin)
Regarding BITMAP_*_WORD_MASK, I can save them in bitmap.h as aliases
to BITS_{LAST,FIRST} to avoid massive renaming. (Should I?)
Would this all work for you?
Re: [PATCH v7 25/38] iio/scmi: port driver to the new scmi_sensor_proto_ops interface
Hi Christian,
Thanks for the detailed explanation. Sounds good to me.
Thanks,
Jyoti
On Tue, Mar 16, 2021 at 3:22 PM Cristian Marussi
wrote:
>
> Hi Jyoti,
>
> On Tue, Mar 16, 2021 at 10:51:48AM -0700, Jyoti Bhayana wrote:
> > Hi Christian,
> >
> > Thanks for porting this driver to the new interface. I have two questions:
> >
> > 1) In the following code snippet, can the sensor_ops be made as part
> > of struct scmi_iio_priv as scmi_protocol_handle is also part of that
> > struct. Not sure if there are any particular reasons for having the
> > protocol handle as part of the struct but the sensor_ops as global?
> >
> > > +static const struct scmi_sensor_proto_ops *sensor_ops;
> > >+
> > >.struct scmi_iio_priv {
> > >- struct scmi_handle *handle;
> > >+ struct scmi_protocol_handle *ph;
> > > const struct scmi_sensor_info *sensor_info;
> > > struct iio_dev *indio_dev;
> >
>
> So, the protocol_handle represents a reference to an instance of
> the sensor protocol initialized against the specific SCMI platform
> instance referred by the handle provided in the probe: so that if you
> should have multiple SCMI platforms defined in the DT, this driver
> (as all SCMI drivers) would be probed multiple times each time with a
> different handle and it would obtain a different protocol_handle each
> time it issued a probe() => devm_protocol_get().
> For this reason the obtained protocol_handle cannot be kept as a global
> and it seemed a good fit to stay in the existent scmi_iio_priv.
>
> On the other side, the sensor_ops are just plain function pointers (as
> they were before), so on any possible probe they are returned the same
> (for the same proto): it is indeed the specified protocol_handle used
> at invocation time that determines against which instance they actually
> operates (if multiple instances present at all); so the sensor_ops seemed
> a good fit for a global, also because that way tehy are more easily
> accessible throughout the driver.
>
> Does it make sense ?
>
> > 2) Looks like the event notifier registration is SCMI device managed
> > and that's why there is no call to unregister. I am assuming that you
> > have tested the logic of inserting the module, removing it and then
> > again inserting it to make sure that when the event is registered a
> > second time , the logic is all good.
> >
> >> ret = handle->notify_ops->devm_event_notifier_register(sdev,
> >
>
> Sure, I tested load/unload in general for also other SCMI drivers just
> to be sure not to have broken completely the world with this series.
>
> Please find below a load/unload/load sequence for scmi_iio.ko.
> (there are 2 emulated sensors, only one is timestamped)
>
> Thanks
>
> Cristian
>
> ---
>
> (debian-arm64)root@debarm64:~# ls /sys/bus/iio/devices/
> (debian-arm64)root@debarm64:~# insmod ./scmi_iio.ko
> (debian-arm64)root@debarm64:~# ls /sys/bus/iio/devices/
> iio:device0 iio:device1
> (debian-arm64)root@debarm64:~# cat /sys/bus/iio/devices/iio\:device0/name
> emu8_accel
> (debian-arm64)root@debarm64:~# cat /sys/bus/iio/devices/iio\:device1/name
> emu9_gyro
> (debian-arm64)root@debarm64:~# /root/iio_generic_buffer -a -c -1 -g -l 100 -N > 0
> iio device number being used is 0
> trigger-less mode selected
> Enabling all channels
> Enabling: in_accel_x_en
> Enabling: in_accel_z_en
> Enabling: in_timestamp_en
> Enabling: in_accel_y_en
> -7737 -7729 -7721 16725578467193651200.00
> -7736 -7728 -7720 16725578467193651200.00
> -7735 -7727 -7719 16725578467193651200.00
> -7734 -7726 -7718 16725578467193651200.00
> -7733 -7725 -7717 16725578467193651200.00
> -7732 -7724 -7716 16725578467193651200.00
> -7731 -7723 -7715 16725578467193651200.00
> -7730 -7722 -7714 17725578795097784320.00
> -7729 -7721 -7713 17725578795097784320.00
> -7728 -7720 -7712 17725578795097784320.00
> -7727 -7719 -7711 17725578795097784320.00
> -7726 -7718 -7710 17725578795097784320.00
> -7725 -7717 -7709 17725578795097784320.00
> -7724 -7716 -7708 17725578795097784320.00
> -7723 -7715 -7707 17725578795097784320.00
> -7722 -7714 -7706 17725578795097784320.00
> -7721 -7713 -7705 17725578795097784320.00
> ^CCaught signal 2
> Disabling: in_accel_x_en
> Disabling: in_accel_z_en
> Disabling: in_timestamp_en
> Disabling: in_accel_y_en
> (debian-arm64)root@debarm64:~# /root/iio_generic_buffer -a -c -1 -g -l 100 -N
> 1
> iio device number being used is 1
> trigger-less mode selected
> Enabling all channels
> Enabling: in_accel_x_en
> Enabling: in_accel_z_en
> Enabling: in_timestamp_en
> Enabling: in_accel_y_en
> -3583 -3574 -3565 270679244800.00
> -3582 -3573 -3564 270780203008.00
> -3581 -3572 -3563 270880358400.00
> -3580 -3571 -3562 270980431872.00
> -3579 -3570 -3561 271080521728.00
> -3578 -3569 -3560 271180611584.00
> -3577 -3568 -3559 271280685056.00
> -3576 -3567 -3558 271380774912.00
> -3575 -3566 -3557 271480848384.00
> -3574 -3565 -3556
linux-next: build failure after merge of the rcu tree
Hi all,
After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: modpost: "rcu_read_lock_longwait_held" [kernel/rcu/rcutorture.ko]
undefined!
ERROR: modpost: "rcu_read_unlock_longwait" [kernel/rcu/rcutorture.ko] undefined!
ERROR: modpost: "rcu_read_lock_longwait" [kernel/rcu/rcutorture.ko] undefined!
Caused by commit
bd6ae31d1b1f ("rcutorture: Add the ability to torture RCU longsleep")
CONFIG_LONGWAIT_RCU=y
CONFIG_RCU_TORTURE_TEST=m
I have used the rcu tree from next-20210316 for today.
--
Cheers,
Stephen Rothwell
pgplAYHVyadYZ.pgp
Description: OpenPGP digital signature
Re: [PATCH v5 05/10] scsi: ufshpb: Region inactivation in host mode
On 2021-03-17 13:19, Daejun Park wrote:
>> ---
>> drivers/scsi/ufs/ufshpb.c | 14 ++
>> drivers/scsi/ufs/ufshpb.h | 1 +
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
>> index 6f4fd22eaf2f..0744feb4d484 100644
>> --- a/drivers/scsi/ufs/ufshpb.c
>> +++ b/drivers/scsi/ufs/ufshpb.c
>> @@ -907,6 +907,7 @@ static int ufshpb_execute_umap_req(struct
>> ufshpb_lu *hpb,
>>
>> blk_execute_rq_nowait(q, NULL, req, 1, ufshpb_umap_req_compl_fn);
>>
>> +hpb->stats.umap_req_cnt++;
>> return 0;
>> }
>>
>> @@ -1103,6 +1104,12 @@ static int ufshpb_issue_umap_req(struct
>> ufshpb_lu *hpb,
>> return -EAGAIN;
>> }
>>
>> +static int ufshpb_issue_umap_single_req(struct ufshpb_lu *hpb,
>> +struct ufshpb_region *rgn)
>> +{
>> +return ufshpb_issue_umap_req(hpb, rgn);
>> +}
>> +
>> static int ufshpb_issue_umap_all_req(struct ufshpb_lu *hpb)
>> {
>> return ufshpb_issue_umap_req(hpb, NULL);
>> @@ -1115,6 +1122,10 @@ static void __ufshpb_evict_region(struct
>> ufshpb_lu *hpb,
>> struct ufshpb_subregion *srgn;
>> int srgn_idx;
>>
>> +
>> +if (hpb->is_hcm && ufshpb_issue_umap_single_req(hpb, rgn))
>
> __ufshpb_evict_region() is called with rgn_state_lock held and IRQ
> disabled,
> when ufshpb_issue_umap_single_req() invokes blk_execute_rq_nowait(),
> below
> warning shall pop up every time, fix it?
>
> void blk_execute_rq_nowait(struct request_queue *q, struct gendisk
> *bd_disk,
> struct request *rq, int at_head,
> rq_end_io_fn *done)
> {
> WARN_ON(irqs_disabled());
> ...
>
Moreover, since we are here with rgn_state_lock held and IRQ
disabled,
in ufshpb_get_req(), rq = kmem_cache_alloc(hpb->map_req_cache,
GFP_KERNEL)
has the GFP_KERNEL flag, scheduling while atomic???
I think your comment applies to ufshpb_issue_umap_all_req as well,
Which is called from slave_configure/scsi_add_lun.
Since the host-mode series is utilizing the framework laid by the
device-mode,
Maybe you can add this comment to Daejun's last version?
Hi Avri, Can Guo
I think ufshpb_issue_umap_single_req() can be moved to end of
ufshpb_evict_region().
Then we can avoid rgn_state_lock when it sends unmap command.
I am not the expert here, please you two fix it. I am just reporting
what can be wrong. Anyways, ufshpb_issue_umap_single_req() should not
be called with rgn_state_lock held - think about below (another
deadly)
scenario.
lock(rgn_state_lock)
ufshpb_issue_umap_single_req()
ufshpb_prep()
lock(rgn_state_lock) <-- recursive spin_lock
BTW, @Daejun shouldn't we stop passthrough cmds from stepping
into ufshpb_prep()? In current code, you are trying to use below
check to block cmds other than write/discard/read, but a passthrough
cmd can not be blocked by the check.
if (!ufshpb_is_write_or_discard_cmd(cmd) &&
!ufshpb_is_read_cmd(cmd) )
return 0;
I found this problem too. I fixed it and submit next patch.
You mean in V30, which has not been uploaded yet, right?
Thanks,
Can Guo.
if (blk_rq_is_scsi(cmd->request) ||
(!ufshpb_is_write_or_discard_cmd(cmd) &&
!ufshpb_is_read_cmd(cmd)))
return 0;
Thanks,
Daejun
Thanks,
Can Guo.
Thanks,
Daejun
Thanks,
Avri
Can Guo.
> Thanks.
> Can Guo.
>
>> +return;
>> +
>> lru_info = >lru_info;
>>
>> dev_dbg(>sdev_ufs_lu->sdev_dev, "evict region %d\n",
>> rgn->rgn_idx);
>> @@ -1855,6 +1866,7 @@ ufshpb_sysfs_attr_show_func(rb_noti_cnt);
>> ufshpb_sysfs_attr_show_func(rb_active_cnt);
>> ufshpb_sysfs_attr_show_func(rb_inactive_cnt);
>> ufshpb_sysfs_attr_show_func(map_req_cnt);
>> +ufshpb_sysfs_attr_show_func(umap_req_cnt);
>>
>> static struct attribute *hpb_dev_stat_attrs[] = {
>> _attr_hit_cnt.attr,
>> @@ -1863,6 +1875,7 @@ static struct attribute *hpb_dev_stat_attrs[] =
>> {
>> _attr_rb_active_cnt.attr,
>> _attr_rb_inactive_cnt.attr,
>> _attr_map_req_cnt.attr,
>> +_attr_umap_req_cnt.attr,
>> NULL,
>> };
>>
>> @@ -1978,6 +1991,7 @@ static void ufshpb_stat_init(struct ufshpb_lu
>> *hpb)
>> hpb->stats.rb_active_cnt = 0;
>> hpb->stats.rb_inactive_cnt = 0;
>> hpb->stats.map_req_cnt = 0;
>> +hpb->stats.umap_req_cnt = 0;
>> }
>>
>> static void ufshpb_param_init(struct ufshpb_lu *hpb)
>> diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
>> index bd4308010466..84598a317897 100644
>> --- a/drivers/scsi/ufs/ufshpb.h
>> +++ b/drivers/scsi/ufs/ufshpb.h
>> @@ -186,6 +186,7 @@ struct ufshpb_stats {
>> u64 rb_inactive_cnt;
>> u64 map_req_cnt;
>> u64 pre_req_cnt;
>> +u64 umap_req_cnt;
>> };
>>
>> struct ufshpb_lu {
Re: [PATCH v2 1/1] PCI: pciehp: Skip DLLSC handling if DPC is triggered
On Tue, Mar 16, 2021 at 10:08:31PM -0700, Dan Williams wrote:
> On Tue, Mar 16, 2021 at 9:14 PM Lukas Wunner wrote:
> >
> > On Fri, Mar 12, 2021 at 07:32:08PM -0800,
> > sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > > + if ((events == PCI_EXP_SLTSTA_DLLSC) && is_dpc_reset_active(pdev)) {
> > > + ctrl_info(ctrl, "Slot(%s): DLLSC event(DPC), skipped\n",
> > > + slot_name(ctrl));
> > > + ret = IRQ_HANDLED;
> > > + goto out;
> > > + }
> >
> > Two problems here:
> >
> > (1) If recovery fails, the link will *remain* down, so there'll be
> > no Link Up event. You've filtered the Link Down event, thus the
> > slot will remain in ON_STATE even though the device in the slot is
> > no longer accessible. That's not good, the slot should be brought
> > down in this case.
>
> Can you elaborate on why that is "not good" from the end user
> perspective? From a driver perspective the device driver context is
> lost and the card needs servicing. The service event starts a new
> cycle of slot-attention being triggered and that syncs the slot-down
> state at that time.
All of pciehp's code assumes that if the link is down, the slot must be
off. A slot which is in ON_STATE for a prolonged period of time even
though the link is down is an oddity the code doesn't account for.
If the link goes down, the slot should be brought into OFF_STATE.
(It's okay though to delay bringdown until DPC recovery has completed
unsuccessfully, which is what the patch I'm proposing does.)
I don't understand what you mean by "service event". Someone unplugging
and replugging the NVMe drive?
> > (2) If recovery succeeds, there's a race where pciehp may call
> > is_dpc_reset_active() *after* dpc_reset_link() has finished.
> > So both the DPC Trigger Status bit as well as pdev->dpc_reset_active
> > will be cleared. Thus, the Link Up event is not filtered by pciehp
> > and the slot is brought down and back up even though DPC recovery
> > was succesful, which seems undesirable.
>
> The hotplug driver never saw the Link Down, so what does it do when
> the slot transitions from Link Up to Link Up? Do you mean the Link
> Down might fire after the dpc recovery has completed if the hotplug
> notification was delayed?
If the Link Down is filtered and the Link Up is not, pciehp will
bring down the slot and then bring it back up. That's because pciehp
can't really tell whether a DLLSC event is Link Up or Link Down.
It just knows that the link was previously up, is now up again,
but must have been down intermittently, so transactions to the
device in the slot may have been lost and the slot is therefore
brought down for safety. Because the link is up, it is then
brought back up.
Thanks,
Lukas
[PATCH 3/3] dt-bindings: interrupt-controller: Convert bindings to yaml for qcom,pdc
This change converts PDC interrupt controller bindings to yaml.
Cc: devicet...@vger.kernel.org
Signed-off-by: Maulik Shah
---
This change depends on [1] which adds sc7280 compatible for PDC
[1] https://patchwork.kernel.org/project/linux-arm-msm/list/?series=440315
---
.../bindings/interrupt-controller/qcom,pdc.txt | 76 --
.../bindings/interrupt-controller/qcom,pdc.yaml| 93 ++
2 files changed, 93 insertions(+), 76 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
deleted file mode 100644
index 98d89e5..000
--- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-PDC interrupt controller
-
-Qualcomm Technologies Inc. SoCs based on the RPM Hardened architecture have a
-Power Domain Controller (PDC) that is on always-on domain. In addition to
-providing power control for the power domains, the hardware also has an
-interrupt controller that can be used to help detect edge low interrupts as
-well detect interrupts when the GIC is non-operational.
-
-GIC is parent interrupt controller at the highest level. Platform interrupt
-controller PDC is next in hierarchy, followed by others. Drivers requiring
-wakeup capabilities of their device interrupts routed through the PDC, must
-specify PDC as their interrupt controller and request the PDC port associated
-with the GIC interrupt. See example below.
-
-Properties:
-
-- compatible:
- Usage: required
- Value type:
- Definition: Should contain "qcom,-pdc" and "qcom,pdc"
- - "qcom,sc7180-pdc": For SC7180
- - "qcom,sc7280-pdc": For SC7280
- - "qcom,sdm845-pdc": For SDM845
- - "qcom,sdm8250-pdc": For SM8250
- - "qcom,sdm8350-pdc": For SM8350
-
-- reg:
- Usage: required
- Value type:
- Definition: Specifies the base physical address for PDC hardware.
-
-- interrupt-cells:
- Usage: required
- Value type:
- Definition: Specifies the number of cells needed to encode an interrupt
- source.
- Must be 2.
- The first element of the tuple is the PDC pin for the
- interrupt.
- The second element is the trigger type.
-
-- interrupt-controller:
- Usage: required
- Value type:
- Definition: Identifies the node as an interrupt controller.
-
-- qcom,pdc-ranges:
- Usage: required
- Value type:
- Definition: Specifies the PDC pin offset and the number of PDC ports.
- The tuples indicates the valid mapping of valid PDC ports
- and their hwirq mapping.
- The first element of the tuple is the starting PDC port.
- The second element is the GIC hwirq number for the PDC port.
- The third element is the number of interrupts in sequence.
-
-Example:
-
- pdc: interrupt-controller@b22 {
- compatible = "qcom,sdm845-pdc";
- reg = <0xb22 0x3>;
- qcom,pdc-ranges = <0 512 94>, <94 641 15>, <115 662 7>;
- #interrupt-cells = <2>;
- interrupt-parent = <>;
- interrupt-controller;
- };
-
-DT binding of a device that wants to use the GIC SPI 514 as a wakeup
-interrupt, must do -
-
- wake-device {
- interrupts-extended = < 2 IRQ_TYPE_LEVEL_HIGH>;
- };
-
-In this case interrupt 514 would be mapped to port 2 on the PDC as defined by
-the qcom,pdc-ranges property.
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
new file mode 100644
index 000..26ae77c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/qcom,pdc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. PDC interrupt controller
+
+maintainers:
+ - Maulik Shah
+
+description: |
+ Qualcomm Technologies, Inc. SoCs based on the RPM Hardened architecture have
a
+ Power Domain Controller (PDC) that is on always-on domain. In addition to
+ providing power control for the power domains, the hardware also has an
+ interrupt controller that can be used to help detect edge low interrupts as
+ well detect interrupts when the GIC is non-operational.
+
+ GIC is parent interrupt controller at the highest level. Platform interrupt
+ controller
[PATCH 1/3] arm64: dts: qcom: sm8350: Remove second reg from pdc
PDC interrupt controller driver do not use second reg. Remove it.
This is in preparation to convert PDC bindings to yaml where
dtbs_check reports it as additional reg.
Cc: devicet...@vger.kernel.org
Signed-off-by: Maulik Shah
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index ea28514..b48bc1b 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -612,7 +612,7 @@
pdc: interrupt-controller@b22 {
compatible = "qcom,sm8350-pdc", "qcom,pdc";
- reg = <0 0x0b22 0 0x3>, <0 0x17c000f0 0 0x60>;
+ reg = <0 0x0b22 0 0x3>;
qcom,pdc-ranges = <0 480 40>, <40 140 14>, <54 263 1>,
<55 306 4>,
<59 312 3>, <62 374 2>, <64 434 2>,
<66 438 3>,
<69 86 1>, <70 520 54>, <124 609
31>, <155 63 1>,
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/3] arm64: dts: qcom: sm8250: Remove second reg from pdc
PDC interrupt controller driver do not use second reg. Remove it.
This is in preparation to convert PDC bindings to yaml where
dtbs_check reports it as additional reg.
Cc: devicet...@vger.kernel.org
Signed-off-by: Maulik Shah
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index bbb6e28..8090b8e 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -2617,7 +2617,7 @@
pdc: interrupt-controller@b22 {
compatible = "qcom,sm8250-pdc", "qcom,pdc";
- reg = <0 0x0b22 0 0x3>, <0 0x17c000f0 0 0x60>;
+ reg = <0 0x0b22 0 0x3>;
qcom,pdc-ranges = <0 480 94>, <94 609 31>,
<125 63 1>, <126 716 12>;
#interrupt-cells = <2>;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2 0/3] perf-stat: share hardware PMCs with BPF
Hi Song, On Wed, Mar 17, 2021 at 6:18 AM Song Liu wrote: > > perf uses performance monitoring counters (PMCs) to monitor system > performance. The PMCs are limited hardware resources. For example, > Intel CPUs have 3x fixed PMCs and 4x programmable PMCs per cpu. > > Modern data center systems use these PMCs in many different ways: > system level monitoring, (maybe nested) container level monitoring, per > process monitoring, profiling (in sample mode), etc. In some cases, > there are more active perf_events than available hardware PMCs. To allow > all perf_events to have a chance to run, it is necessary to do expensive > time multiplexing of events. > > On the other hand, many monitoring tools count the common metrics (cycles, > instructions). It is a waste to have multiple tools create multiple > perf_events of "cycles" and occupy multiple PMCs. Right, it'd be really helpful when the PMCs are frequently or mostly shared. But it'd also increase the overhead for uncontended cases as BPF programs need to run on every context switch. Depending on the workload, it may cause a non-negligible performance impact. So users should be aware of it. Thanks, Namhyung > > bperf tries to reduce such wastes by allowing multiple perf_events of > "cycles" or "instructions" (at different scopes) to share PMUs. Instead > of having each perf-stat session to read its own perf_events, bperf uses > BPF programs to read the perf_events and aggregate readings to BPF maps. > Then, the perf-stat session(s) reads the values from these BPF maps. > > Changes v1 => v2: > 1. Add documentation. > 2. Add a shell test. > 3. Rename options, default path of the atto-map, and some variables. > 4. Add a separate patch that moves clock_gettime() in __run_perf_stat() > to after enable_counters(). > 5. Make perf_cpu_map for all cpus a global variable. > 6. Use sysfs__mountpoint() for default attr-map path. > 7. Use cpu__max_cpu() instead of libbpf_num_possible_cpus(). > 8. Add flag "enabled" to the follower program. Then move follower attach > to bperf__load() and simplify bperf__enable(). > > Song Liu (3): > perf-stat: introduce bperf, share hardware PMCs with BPF > perf-stat: measure t0 and ref_time after enable_counters() > perf-test: add a test for perf-stat --bpf-counters option > > tools/perf/Documentation/perf-stat.txt| 11 + > tools/perf/Makefile.perf | 1 + > tools/perf/builtin-stat.c | 20 +- > tools/perf/tests/shell/stat_bpf_counters.sh | 34 ++ > tools/perf/util/bpf_counter.c | 519 +- > tools/perf/util/bpf_skel/bperf.h | 14 + > tools/perf/util/bpf_skel/bperf_follower.bpf.c | 69 +++ > tools/perf/util/bpf_skel/bperf_leader.bpf.c | 46 ++ > tools/perf/util/bpf_skel/bperf_u.h| 14 + > tools/perf/util/evsel.h | 20 +- > tools/perf/util/target.h | 4 +- > 11 files changed, 742 insertions(+), 10 deletions(-) > create mode 100755 tools/perf/tests/shell/stat_bpf_counters.sh > create mode 100644 tools/perf/util/bpf_skel/bperf.h > create mode 100644 tools/perf/util/bpf_skel/bperf_follower.bpf.c > create mode 100644 tools/perf/util/bpf_skel/bperf_leader.bpf.c > create mode 100644 tools/perf/util/bpf_skel/bperf_u.h > > -- > 2.30.2
Re: A problem of Intel IOMMU hardware ？
Hi Longpeng,
On 3/17/21 11:16 AM, Longpeng (Mike, Cloud Infrastructure Service
Product Dept.) wrote:
Hi guys,
We find the Intel iommu cache (i.e. iotlb) maybe works wrong in a special
situation, it would cause DMA fails or get wrong data.
The reproducer (based on Alex's vfio testsuite[1]) is in attachment, it can
reproduce the problem with high probability (~50%).
The machine we used is:
processor : 47
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Gold 6146 CPU @ 3.20GHz
stepping: 4
microcode : 0x269
And the iommu capability reported is:
ver 1:0 cap 8d2078c106f0466 ecap f020df
(caching mode = 0 , page-selective invalidation = 1)
(The problem is also on 'Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz' and
'Intel(R) Xeon(R) Platinum 8378A CPU @ 3.00GHz')
We run the reproducer on Linux 4.18 and it works as follow:
Step 1. alloc 4G *2M-hugetlb* memory (N.B. no problem with 4K-page mapping)
I don't understand 2M-hugetlb here means exactly. The IOMMU hardware
supports both 2M and 1G super page. The mapping physical memory is 4G.
Why couldn't it use 1G super page?
Step 2. DMA Map 4G memory
Step 3.
while (1) {
{UNMAP, 0x0, 0xa}, (a)
{UNMAP, 0xc, 0xbff4},
Have these two ranges been mapped before? Does the IOMMU driver
complains when you trying to unmap a range which has never been
mapped? The IOMMU driver implicitly assumes that mapping and
unmapping are paired.
{MAP, 0x0, 0xc000}, - (b)
use GDB to pause at here, and then DMA read IOVA=0,
IOVA 0 seems to be a special one. Have you verified with other addresses
than IOVA 0?
sometimes DMA success (as expected),
but sometimes DMA error (report not-present).
{UNMAP, 0x0, 0xc000}, - (c)
{MAP, 0x0, 0xa},
{MAP, 0xc, 0xbff4},
}
The DMA read operations sholud success between (b) and (c), it should NOT report
not-present at least!
After analysis the problem, we think maybe it's caused by the Intel iommu iotlb.
It seems the DMA Remapping hardware still uses the IOTLB or other caches of (a).
When do DMA unmap at (a), the iotlb will be flush:
intel_iommu_unmap
domain_unmap
iommu_flush_iotlb_psi
When do DMA map at (b), no need to flush the iotlb according to the capability
of this iommu:
intel_iommu_map
domain_pfn_mapping
domain_mapping
__mapping_notify_one
if (cap_caching_mode(iommu->cap)) // FALSE
iommu_flush_iotlb_psi
That's true. The iotlb flushing is not needed in case of PTE been
changed from non-present to present unless caching mode.
But the problem will disappear if we FORCE flush here. So we suspect the iommu
hardware.
Do you have any suggestion ?
Best regards,
baolu
Re: [PATCH] watchdog: Fix a typo in the file orion_wdt.c
On 3/16/21 10:17 PM, Bhaskar Chowdhury wrote: > > s/freqency/frequency/ > > Signed-off-by: Bhaskar Chowdhury Reviewed-by: Guenter Roeck > --- > drivers/watchdog/orion_wdt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c > index 4ddb4ea2e4a3..127eefc9161d 100644 > --- a/drivers/watchdog/orion_wdt.c > +++ b/drivers/watchdog/orion_wdt.c > @@ -174,7 +174,7 @@ static int armadaxp_wdt_clock_init(struct platform_device > *pdev, > return ret; > } > > - /* Fix the wdt and timer1 clock freqency to 25MHz */ > + /* Fix the wdt and timer1 clock frequency to 25MHz */ > val = WDT_AXP_FIXED_ENABLE_BIT | TIMER1_FIXED_ENABLE_BIT; > atomic_io_modify(dev->reg + TIMER_CTRL, val, val); > > -- > 2.30.2 >
RE: Re: [PATCH v5 05/10] scsi: ufshpb: Region inactivation in host mode
>> ---
>> drivers/scsi/ufs/ufshpb.c | 14 ++
>> drivers/scsi/ufs/ufshpb.h | 1 +
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
>> index 6f4fd22eaf2f..0744feb4d484 100644
>> --- a/drivers/scsi/ufs/ufshpb.c
>> +++ b/drivers/scsi/ufs/ufshpb.c
>> @@ -907,6 +907,7 @@ static int ufshpb_execute_umap_req(struct
>> ufshpb_lu *hpb,
>>
>> blk_execute_rq_nowait(q, NULL, req, 1, ufshpb_umap_req_compl_fn);
>>
>> +hpb->stats.umap_req_cnt++;
>> return 0;
>> }
>>
>> @@ -1103,6 +1104,12 @@ static int ufshpb_issue_umap_req(struct
>> ufshpb_lu *hpb,
>> return -EAGAIN;
>> }
>>
>> +static int ufshpb_issue_umap_single_req(struct ufshpb_lu *hpb,
>> +struct ufshpb_region *rgn)
>> +{
>> +return ufshpb_issue_umap_req(hpb, rgn);
>> +}
>> +
>> static int ufshpb_issue_umap_all_req(struct ufshpb_lu *hpb)
>> {
>> return ufshpb_issue_umap_req(hpb, NULL);
>> @@ -1115,6 +1122,10 @@ static void __ufshpb_evict_region(struct
>> ufshpb_lu *hpb,
>> struct ufshpb_subregion *srgn;
>> int srgn_idx;
>>
>> +
>> +if (hpb->is_hcm && ufshpb_issue_umap_single_req(hpb, rgn))
>
> __ufshpb_evict_region() is called with rgn_state_lock held and IRQ
> disabled,
> when ufshpb_issue_umap_single_req() invokes blk_execute_rq_nowait(),
> below
> warning shall pop up every time, fix it?
>
> void blk_execute_rq_nowait(struct request_queue *q, struct gendisk
> *bd_disk,
> struct request *rq, int at_head,
> rq_end_io_fn *done)
> {
> WARN_ON(irqs_disabled());
> ...
>
Moreover, since we are here with rgn_state_lock held and IRQ
disabled,
in ufshpb_get_req(), rq = kmem_cache_alloc(hpb->map_req_cache,
GFP_KERNEL)
has the GFP_KERNEL flag, scheduling while atomic???
>>> I think your comment applies to ufshpb_issue_umap_all_req as well,
>>> Which is called from slave_configure/scsi_add_lun.
>>>
>>> Since the host-mode series is utilizing the framework laid by the
>>> device-mode,
>>> Maybe you can add this comment to Daejun's last version?
>>
>> Hi Avri, Can Guo
>>
>> I think ufshpb_issue_umap_single_req() can be moved to end of
>> ufshpb_evict_region().
>> Then we can avoid rgn_state_lock when it sends unmap command.
>
>I am not the expert here, please you two fix it. I am just reporting
>what can be wrong. Anyways, ufshpb_issue_umap_single_req() should not
>be called with rgn_state_lock held - think about below (another deadly)
>scenario.
>
>lock(rgn_state_lock)
> ufshpb_issue_umap_single_req()
> ufshpb_prep()
>lock(rgn_state_lock) <-- recursive spin_lock
>
>BTW, @Daejun shouldn't we stop passthrough cmds from stepping
>into ufshpb_prep()? In current code, you are trying to use below
>check to block cmds other than write/discard/read, but a passthrough
>cmd can not be blocked by the check.
>
> if (!ufshpb_is_write_or_discard_cmd(cmd) &&
> !ufshpb_is_read_cmd(cmd) )
> return 0;
I found this problem too. I fixed it and submit next patch.
if (blk_rq_is_scsi(cmd->request) ||
(!ufshpb_is_write_or_discard_cmd(cmd) &&
!ufshpb_is_read_cmd(cmd)))
return 0;
Thanks,
Daejun
>Thanks,
>Can Guo.
>
>>
>> Thanks,
>> Daejun
>>
>>
>>> Thanks,
>>> Avri
>>>
Can Guo.
> Thanks.
> Can Guo.
>
>> +return;
>> +
>> lru_info = >lru_info;
>>
>> dev_dbg(>sdev_ufs_lu->sdev_dev, "evict region %d\n",
>> rgn->rgn_idx);
>> @@ -1855,6 +1866,7 @@ ufshpb_sysfs_attr_show_func(rb_noti_cnt);
>> ufshpb_sysfs_attr_show_func(rb_active_cnt);
>> ufshpb_sysfs_attr_show_func(rb_inactive_cnt);
>> ufshpb_sysfs_attr_show_func(map_req_cnt);
>> +ufshpb_sysfs_attr_show_func(umap_req_cnt);
>>
>> static struct attribute *hpb_dev_stat_attrs[] = {
>> _attr_hit_cnt.attr,
>> @@ -1863,6 +1875,7 @@ static struct attribute *hpb_dev_stat_attrs[] =
>> {
>> _attr_rb_active_cnt.attr,
>> _attr_rb_inactive_cnt.attr,
>> _attr_map_req_cnt.attr,
>> +_attr_umap_req_cnt.attr,
>> NULL,
>> };
>>
>> @@ -1978,6 +1991,7 @@ static void ufshpb_stat_init(struct ufshpb_lu
>> *hpb)
>> hpb->stats.rb_active_cnt = 0;
>> hpb->stats.rb_inactive_cnt = 0;
>> hpb->stats.map_req_cnt = 0;
>> +hpb->stats.umap_req_cnt = 0;
>> }
>>
>> static void ufshpb_param_init(struct ufshpb_lu *hpb)
>> diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
>> index
Re: [PATCH] watchdog: Fix a typo in the file orion_wdt.c
On 3/16/21 10:17 PM, Bhaskar Chowdhury wrote: > > s/freqency/frequency/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/watchdog/orion_wdt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c > index 4ddb4ea2e4a3..127eefc9161d 100644 > --- a/drivers/watchdog/orion_wdt.c > +++ b/drivers/watchdog/orion_wdt.c > @@ -174,7 +174,7 @@ static int armadaxp_wdt_clock_init(struct platform_device > *pdev, > return ret; > } > > - /* Fix the wdt and timer1 clock freqency to 25MHz */ > + /* Fix the wdt and timer1 clock frequency to 25MHz */ > val = WDT_AXP_FIXED_ENABLE_BIT | TIMER1_FIXED_ENABLE_BIT; > atomic_io_modify(dev->reg + TIMER_CTRL, val, val); > > -- -- ~Randy
[PATCH] watchdog: Fix a typo in the file orion_wdt.c
s/freqency/frequency/ Signed-off-by: Bhaskar Chowdhury --- drivers/watchdog/orion_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c index 4ddb4ea2e4a3..127eefc9161d 100644 --- a/drivers/watchdog/orion_wdt.c +++ b/drivers/watchdog/orion_wdt.c @@ -174,7 +174,7 @@ static int armadaxp_wdt_clock_init(struct platform_device *pdev, return ret; } - /* Fix the wdt and timer1 clock freqency to 25MHz */ + /* Fix the wdt and timer1 clock frequency to 25MHz */ val = WDT_AXP_FIXED_ENABLE_BIT | TIMER1_FIXED_ENABLE_BIT; atomic_io_modify(dev->reg + TIMER_CTRL, val, val); -- 2.30.2
Re: [PATCH] include: acpi: A typo fix in the file cppc_acpi.h
On 3/16/21 10:06 PM, Bhaskar Chowdhury wrote:
>
> s/folowing/following/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> include/acpi/cppc_acpi.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
> index c7fc4524e151..d174721bab33 100644
> --- a/include/acpi/cppc_acpi.h
> +++ b/include/acpi/cppc_acpi.h
> @@ -31,7 +31,7 @@
> #define CMD_READ 0
> #define CMD_WRITE 1
>
> -/* Each register has the folowing format. */
> +/* Each register has the following format. */
> struct cpc_reg {
> u8 descriptor;
> u16 length;
> --
--
~Randy
Re: [PATCH 4/4] locking/locktorture: Fix incorrect use of ww_acquire_ctx in ww_mutex test
On Tue, 16 Mar 2021, Waiman Long wrote:
The ww_acquire_ctx structure for ww_mutex needs to persist for a complete
lock/unlock cycle. In the ww_mutex test in locktorture, however, both
ww_acquire_init() and ww_acquire_fini() are called within the lock
function only. This causes a lockdep splat of "WARNING: Nested lock
was not taken" when lockdep is enabled in the kernel.
To fix this problem, we need to move the ww_acquire_fini() after the
ww_mutex_unlock() in torture_ww_mutex_unlock(). In other word, we need
to pass state information from the lock function to the unlock function.
Right, and afaict this _is_ the way ww_acquire_fini() should be called:
* Releases a w/w acquire context. This must be called _after_ all acquired w/w
* mutexes have been released with ww_mutex_unlock.
Change the writelock and writeunlock function prototypes to allow that
and change the torture_ww_mutex_lock() and torture_ww_mutex_unlock()
accordingly.
But wouldn't just making ctx a global variable be enough instead? That way
we don't deal with memory allocation for every lock/unlock operation (yuck).
Plus the ENOMEM would need to be handled/propagated accordingly - the code
really doesn't expect any failure from ->writelock().
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index 0ab94e1f1276..606c0f6c1657 100644
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -362,6 +362,8 @@ static DEFINE_WW_MUTEX(torture_ww_mutex_0,
_ww_class);
static DEFINE_WW_MUTEX(torture_ww_mutex_1, _ww_class);
static DEFINE_WW_MUTEX(torture_ww_mutex_2, _ww_class);
+static struct ww_acquire_ctx ctx;
+
static int torture_ww_mutex_lock(void)
__acquires(torture_ww_mutex_0)
__acquires(torture_ww_mutex_1)
@@ -372,7 +374,6 @@ __acquires(torture_ww_mutex_2)
struct list_head link;
struct ww_mutex *lock;
} locks[3], *ll, *ln;
- struct ww_acquire_ctx ctx;
locks[0].lock = _ww_mutex_0;
list_add([0].link, );
@@ -403,7 +404,6 @@ __acquires(torture_ww_mutex_2)
list_move(>link, );
}
- ww_acquire_fini();
return 0;
}
@@ -415,6 +415,8 @@ __releases(torture_ww_mutex_2)
ww_mutex_unlock(_ww_mutex_0);
ww_mutex_unlock(_ww_mutex_1);
ww_mutex_unlock(_ww_mutex_2);
+
+ ww_acquire_fini();
}
static struct lock_torture_ops ww_mutex_lock_ops = {
Re: [PATCH] mm: Typo fix in the file util.c
On 3/16/21 8:34 PM, Bhaskar Chowdhury wrote: > > > s/condtion/condition/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > mm/util.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/util.c b/mm/util.c > index 54870226cea6..f85da35b50eb 100644 > --- a/mm/util.c > +++ b/mm/util.c > @@ -775,7 +775,7 @@ int overcommit_policy_handler(struct ctl_table *table, > int write, void *buffer, >* The deviation of sync_overcommit_as could be big with loose policy >* like OVERCOMMIT_ALWAYS/OVERCOMMIT_GUESS. When changing policy to >* strict OVERCOMMIT_NEVER, we need to reduce the deviation to comply > - * with the strict "NEVER", and to avoid possible race condtion (even > + * with the strict "NEVER", and to avoid possible race condition (even >* though user usually won't too frequently do the switching to policy >* OVERCOMMIT_NEVER), the switch is done in the following order: >* 1. changing the batch > -- -- ~Randy
Re: [PATCH] staging: comedi: das800: fix request_irq() warn
On Tue, Mar 16, 2021 at 06:42:26PM -0400, Tong Zhang wrote: > request_irq() wont accept a name which contains slash so we need to > repalce it with something else -- otherwise it will trigger a warning ^^^ I don't normally comment on spelling mistakes in the commit message but you're copy and pasting "repalce" over and over... > and the entry in /proc/irq/ will not be created > since the .name might be used by userspace and we don't want to break > userspace, so we are changing the parameters passed to request_irq() regards, dan carpenter
Re: [PATCH] riscv: Fix spelling mistake "initialisation" -> "initialization
On Tue, 16 Mar 2021 02:30:54 PDT (-0700), musamaan...@gmail.com wrote: There is a spelling mistake in a comment. Fix it. Signed-off-by: Muhammad Usama Anjum --- arch/riscv/kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c index ea028d9e0d24..1ec014067855 100644 --- a/arch/riscv/kernel/smp.c +++ b/arch/riscv/kernel/smp.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-only /* - * SMP initialisation and IPI support + * SMP initialization and IPI support * Based on arch/arm64/kernel/smp.c * * Copyright (C) 2012 ARM Ltd. The internet seems to suggest that both of these are words and that they mean the same thing.
Re: [PATCH] kernel: Fix a typo in the file up.c
On 3/16/21 8:27 PM, Bhaskar Chowdhury wrote: > > s/condtions/conditions/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > Adding Andrew in the to list, becasue this file has no maintainer attached because > > kernel/up.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/up.c b/kernel/up.c > index c6f323dcd45b..1b9b135e77dd 100644 > --- a/kernel/up.c > +++ b/kernel/up.c > @@ -67,7 +67,7 @@ EXPORT_SYMBOL(on_each_cpu_mask); > > /* > * Preemption is disabled here to make sure the cond_func is called under the > - * same condtions in UP and SMP. > + * same conditions in UP and SMP. > */ > void on_each_cpu_cond_mask(smp_cond_func_t cond_func, smp_call_func_t func, > void *info, bool wait, const struct cpumask *mask) > -- -- ~Randy
Re: [PATCH] sched: rename __prepare_to_swait() to add_swait_queue_locked()
On Tue, 2021-03-16 at 19:59 +0800, Wang Qing wrote:
> This function just puts wait into queue, and does not do an operation similar
> to prepare_to_wait() in wait.c.
> And during the operation, the caller needs to hold the lock to protect.
I see zero benefit to churn like this. You're taking a dinky little
file that's perfectly clear (and pretty), and restating the obvious.
>
> Signed-off-by: Wang Qing
> ---
> kernel/sched/completion.c | 2 +-
> kernel/sched/sched.h | 2 +-
> kernel/sched/swait.c | 6 +++---
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
> index a778554..3d28a5a
> --- a/kernel/sched/completion.c
> +++ b/kernel/sched/completion.c
> @@ -79,7 +79,7 @@ do_wait_for_common(struct completion *x,
> timeout = -ERESTARTSYS;
> break;
> }
> - __prepare_to_swait(>wait, );
> + add_swait_queue_locked(>wait, );
> __set_current_state(state);
> raw_spin_unlock_irq(>wait.lock);
> timeout = action(timeout);
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 10a1522..0516f50
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -2719,4 +2719,4 @@ static inline bool is_per_cpu_kthread(struct
> task_struct *p)
> #endif
>
> void swake_up_all_locked(struct swait_queue_head *q);
> -void __prepare_to_swait(struct swait_queue_head *q, struct swait_queue
> *wait);
> +void add_swait_queue_locked(struct swait_queue_head *q, struct swait_queue
> *wait);
> diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c
> index 7a24925..f48a544
> --- a/kernel/sched/swait.c
> +++ b/kernel/sched/swait.c
> @@ -82,7 +82,7 @@ void swake_up_all(struct swait_queue_head *q)
> }
> EXPORT_SYMBOL(swake_up_all);
>
> -void __prepare_to_swait(struct swait_queue_head *q, struct swait_queue *wait)
> +void add_swait_queue_locked(struct swait_queue_head *q, struct swait_queue
> *wait)
> {
> wait->task = current;
> if (list_empty(>task_list))
> @@ -94,7 +94,7 @@ void prepare_to_swait_exclusive(struct swait_queue_head *q,
> struct swait_queue *
> unsigned long flags;
>
> raw_spin_lock_irqsave(>lock, flags);
> - __prepare_to_swait(q, wait);
> + add_swait_queue_locked(q, wait);
> set_current_state(state);
> raw_spin_unlock_irqrestore(>lock, flags);
> }
> @@ -114,7 +114,7 @@ long prepare_to_swait_event(struct swait_queue_head *q,
> struct swait_queue *wait
> list_del_init(>task_list);
> ret = -ERESTARTSYS;
> } else {
> - __prepare_to_swait(q, wait);
> + add_swait_queue_locked(q, wait);
> set_current_state(state);
> }
> raw_spin_unlock_irqrestore(>lock, flags);
Re: [PATCH v2 1/5] hwmon: (max31790) Rework to use regmap
Hi "Václav,
url:
https://github.com/0day-ci/linux/commits/V-clav-Kubern-t/hwmon-max31790-Rework-to-use-regmap/20210317-015931
base:
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-next
config: x86_64-randconfig-m001-20210316 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/hwmon/max31790.c:263 max31790_fan_is_visible() warn: impossible
condition '(fan_config < 0) => (0-255 < 0)'
drivers/hwmon/max31790.c:337 max31790_write_pwm() warn: impossible condition
'(fan_config < 0) => (0-255 < 0)'
drivers/hwmon/max31790.c:372 max31790_pwm_is_visible() warn: impossible
condition '(fan_config < 0) => (0-255 < 0)'
vim +263 drivers/hwmon/max31790.c
54187ff9d766b2 Guenter Roeck 2016-07-01 257 static umode_t
max31790_fan_is_visible(const void *_data, u32 attr, int channel)
195a4b4298a795 Il Han 2015-08-30 258 {
54187ff9d766b2 Guenter Roeck 2016-07-01 259 const struct
max31790_data *data = _data;
2c8602cfaeab63 Václav Kubernát 2021-03-16 260 struct regmap *regmap =
data->regmap;
2c8602cfaeab63 Václav Kubernát 2021-03-16 261 u8 fan_config =
read_reg_byte(regmap, MAX31790_REG_FAN_CONFIG(channel % NR_CHANNEL));
2c8602cfaeab63 Václav Kubernát 2021-03-16 262
2c8602cfaeab63 Václav Kubernát 2021-03-16 @263 if (fan_config < 0)
^^
A u8 can't be negative.
2c8602cfaeab63 Václav Kubernát 2021-03-16 264 return 0;
54187ff9d766b2 Guenter Roeck 2016-07-01 265
54187ff9d766b2 Guenter Roeck 2016-07-01 266 switch (attr) {
54187ff9d766b2 Guenter Roeck 2016-07-01 267 case hwmon_fan_input:
54187ff9d766b2 Guenter Roeck 2016-07-01 268 case hwmon_fan_fault:
54187ff9d766b2 Guenter Roeck 2016-07-01 269 if (channel <
NR_CHANNEL ||
54187ff9d766b2 Guenter Roeck 2016-07-01 270 (fan_config
& MAX31790_FAN_CFG_TACH_INPUT))
dc8dbb4d7672b7 Guenter Roeck 2018-12-10 271 return
0444;
54187ff9d766b2 Guenter Roeck 2016-07-01 272 return 0;
54187ff9d766b2 Guenter Roeck 2016-07-01 273 case hwmon_fan_target:
54187ff9d766b2 Guenter Roeck 2016-07-01 274 if (channel <
NR_CHANNEL &&
54187ff9d766b2 Guenter Roeck 2016-07-01 275
!(fan_config & MAX31790_FAN_CFG_TACH_INPUT))
dc8dbb4d7672b7 Guenter Roeck 2018-12-10 276 return
0644;
54187ff9d766b2 Guenter Roeck 2016-07-01 277 return 0;
54187ff9d766b2 Guenter Roeck 2016-07-01 278 default:
54187ff9d766b2 Guenter Roeck 2016-07-01 279 return 0;
195a4b4298a795 Il Han 2015-08-30 280 }
195a4b4298a795 Il Han 2015-08-30 281 }
195a4b4298a795 Il Han 2015-08-30 282
54187ff9d766b2 Guenter Roeck 2016-07-01 283 static int
max31790_read_pwm(struct device *dev, u32 attr, int channel,
54187ff9d766b2 Guenter Roeck 2016-07-01 284
long *val)
195a4b4298a795 Il Han 2015-08-30 285 {
2c8602cfaeab63 Václav Kubernát 2021-03-16 286 struct max31790_data
*data = dev_get_drvdata(dev);
2c8602cfaeab63 Václav Kubernát 2021-03-16 287 struct regmap *regmap =
data->regmap;
2c8602cfaeab63 Václav Kubernát 2021-03-16 288 int read;
195a4b4298a795 Il Han 2015-08-30 289
195a4b4298a795 Il Han 2015-08-30 290 if (IS_ERR(data))
195a4b4298a795 Il Han 2015-08-30 291 return
PTR_ERR(data);
195a4b4298a795 Il Han 2015-08-30 292
54187ff9d766b2 Guenter Roeck 2016-07-01 293 switch (attr) {
54187ff9d766b2 Guenter Roeck 2016-07-01 294 case hwmon_pwm_input:
2c8602cfaeab63 Václav Kubernát 2021-03-16 295 read =
read_reg_word(regmap, MAX31790_REG_PWMOUT(channel));
2c8602cfaeab63 Václav Kubernát 2021-03-16 296 if (read < 0)
2c8602cfaeab63 Václav Kubernát 2021-03-16 297 return
read;
2c8602cfaeab63 Václav Kubernát 2021-03-16 298
2c8602cfaeab63 Václav Kubernát 2021-03-16 299 *val = read >>
8;
54187ff9d766b2 Guenter Roeck 2016-07-01 300 return 0;
54187ff9d766b2 Guenter Roeck 2016-07-01 301 case hwmon_pwm_enable:
2c8602cfaeab63 Václav Kubernát 2021-03-16 302 read =
read_reg_byte(regmap, MAX31790_REG_FAN_CONFIG(channel));
2c8602cfaeab63 Václav Kubernát 2021-03-16 303 if (read < 0)
2c8602cfaeab63 Václav Kubernát 2021-03-16 304 return
read;
2c8602cfaeab63 Václav Kubernát 2021-03-16 305
Re: [PATCH] wireless: intel: iwlwifi: fw: api: Absolute rudimentary typo fixes in the file power.h
On 3/16/21 9:25 PM, Bhaskar Chowdhury wrote:
>
> s/folowing/following/
> s/Celsuis/Celsius/
> s/temerature/temperature/ ...twice
>
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/net/wireless/intel/iwlwifi/fw/api/power.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
> b/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
> index 798417182d54..f7c7852127d3 100644
> --- a/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
> +++ b/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
> @@ -54,7 +54,7 @@ struct iwl_ltr_config_cmd_v1 {
> * @flags: See iwl_ltr_config_flags
> * @static_long: static LTR Long register value.
> * @static_short: static LTR Short register value.
> - * @ltr_cfg_values: LTR parameters table values (in usec) in folowing order:
> + * @ltr_cfg_values: LTR parameters table values (in usec) in following order:
> * TX, RX, Short Idle, Long Idle. Used only if %LTR_CFG_FLAG_UPDATE_VALUES
> * is set.
> * @ltr_short_idle_timeout: LTR Short Idle timeout (in usec). Used only if
> @@ -493,7 +493,7 @@ union iwl_ppag_table_cmd {
> * Roaming Energy Delta Threshold, otherwise use normal Energy Delta
> * Threshold. Typical energy threshold is -72dBm.
> * @bf_temp_threshold: This threshold determines the type of temperature
> - * filtering (Slow or Fast) that is selected (Units are in Celsuis):
> + * filtering (Slow or Fast) that is selected (Units are in Celsius):
> * If the current temperature is above this threshold - Fast filter
> * will be used, If the current temperature is below this threshold -
> * Slow filter will be used.
> @@ -501,12 +501,12 @@ union iwl_ppag_table_cmd {
> * calculated for this and the last passed beacon is greater than this
> * threshold. Zero value means that the temperature change is ignored
> for
> * beacon filtering; beacons will not be forced to be sent to driver
> - * regardless of whether its temerature has been changed.
> + * regardless of whether its temperature has been changed.
> * @bf_temp_slow_filter: Send Beacon to driver if delta in temperature values
> * calculated for this and the last passed beacon is greater than this
> * threshold. Zero value means that the temperature change is ignored
> for
> * beacon filtering; beacons will not be forced to be sent to driver
> - * regardless of whether its temerature has been changed.
> + * regardless of whether its temperature has been changed.
> * @bf_enable_beacon_filter: 1, beacon filtering is enabled; 0, disabled.
> * @bf_debug_flag: beacon filtering debug configuration
> * @bf_escape_timer: Send beacons to to driver if no beacons were passed
> --
--
~Randy
Re: [PATCH] kernel: locking: Mundane typo fix in the file rwsem.c
On 3/16/21 9:18 PM, Bhaskar Chowdhury wrote: > > s/folowing/following/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > kernel/locking/rwsem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c > index abba5df50006..fe9cc65cd522 100644 > --- a/kernel/locking/rwsem.c > +++ b/kernel/locking/rwsem.c > @@ -632,7 +632,7 @@ static inline bool rwsem_can_spin_on_owner(struct > rw_semaphore *sem) > } > > /* > - * The rwsem_spin_on_owner() function returns the folowing 4 values > + * The rwsem_spin_on_owner() function returns the following 4 values > * depending on the lock owner state. > * OWNER_NULL : owner is currently NULL > * OWNER_WRITER: when owner changes and is a writer > -- -- ~Randy
Re: [PATCH] MIPS: fix memory reservation for non-usermem setups
Hi Thomas,
On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer
wrote:
>
> On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > From: Tobias Wolf
> >
> > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a
> > new
> > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is
> > not. As the prerequisite of custom memory map has been removed, this results
> > in the full memory range of 0x0 - 0x800 to be marked as reserved for
> > this
> > platform.
>
> and where is the problem here ?
Turns out this was already attempted to be upstreamed - not clear why
it wasn't merged. Context:
https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/
I hope the thread above helps you understand the problem.
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.[ RFC1925, 2.3 ]
Ilya
Re: [PATCH] ia64: hp: common: A typo fix in the file sba_iommu.c
On 3/16/21 8:14 PM, Bhaskar Chowdhury wrote: > > > s/minium/minimum/ > > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > arch/ia64/hp/common/sba_iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c > index 9148ddbf02e5..3dcb8c35faad 100644 > --- a/arch/ia64/hp/common/sba_iommu.c > +++ b/arch/ia64/hp/common/sba_iommu.c > @@ -828,7 +828,7 @@ mark_clean (void *addr, size_t size) > * corresponding IO TLB entry. The PCOM (Purge Command Register) > * is to purge stale entries in the IO TLB when unmapping entries. > * > - * The PCOM register supports purging of multiple pages, with a minium > + * The PCOM register supports purging of multiple pages, with a minimum > * of 1 page and a maximum of 2GB. Hardware requires the address be > * aligned to the size of the range being purged. The size of the range > * must be a power of 2. The "Cool perf optimization" in the > -- -- ~Randy
Re: RFC: dt-binding: media: document ON Semi AR0521 sensor bindings
Laurent, Laurent Pinchart writes: >> +const: on-semi,ar0521 > > That's not the correct prefix for ON Semiconductor. See > Documentation/devicetree/bindings/vendor-prefixes.yaml. Or just the name > of this file :-) Right, just missed this one. Thanks for the comments. -- Krzysztof Halasa Sieć Badawcza Łukasiewicz Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202, 02-486 Warszawa
Re: [PATCH v2 1/1] PCI: pciehp: Skip DLLSC handling if DPC is triggered
On Tue, Mar 16, 2021 at 9:14 PM Lukas Wunner wrote:
>
> On Fri, Mar 12, 2021 at 07:32:08PM -0800,
> sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > + if ((events == PCI_EXP_SLTSTA_DLLSC) && is_dpc_reset_active(pdev)) {
> > + ctrl_info(ctrl, "Slot(%s): DLLSC event(DPC), skipped\n",
> > + slot_name(ctrl));
> > + ret = IRQ_HANDLED;
> > + goto out;
> > + }
>
> Two problems here:
>
> (1) If recovery fails, the link will *remain* down, so there'll be
> no Link Up event. You've filtered the Link Down event, thus the
> slot will remain in ON_STATE even though the device in the slot is
> no longer accessible. That's not good, the slot should be brought
> down in this case.
Can you elaborate on why that is "not good" from the end user
perspective? From a driver perspective the device driver context is
lost and the card needs servicing. The service event starts a new
cycle of slot-attention being triggered and that syncs the slot-down
state at that time.
>
> (2) If recovery succeeds, there's a race where pciehp may call
> is_dpc_reset_active() *after* dpc_reset_link() has finished.
> So both the DPC Trigger Status bit as well as pdev->dpc_reset_active
> will be cleared. Thus, the Link Up event is not filtered by pciehp
> and the slot is brought down and back up even though DPC recovery
> was succesful, which seems undesirable.
The hotplug driver never saw the Link Down, so what does it do when
the slot transitions from Link Up to Link Up? Do you mean the Link
Down might fire after the dpc recovery has completed if the hotplug
notification was delayed?
Re: [PATCH v6 1/2] RISC-V: Don't print SBI version for all detected extensions
On Mon, 15 Mar 2021 04:04:59 PDT (-0700), Anup Patel wrote:
The sbi_init() already prints SBI version before detecting
various SBI extensions so we don't need to print SBI version
for all detected SBI extensions.
Signed-off-by: Anup Patel
---
arch/riscv/kernel/sbi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
index f4a7db3d309e..c0dcebdd30ec 100644
--- a/arch/riscv/kernel/sbi.c
+++ b/arch/riscv/kernel/sbi.c
@@ -577,19 +577,19 @@ void __init sbi_init(void)
sbi_get_firmware_id(), sbi_get_firmware_version());
if (sbi_probe_extension(SBI_EXT_TIME) > 0) {
__sbi_set_timer = __sbi_set_timer_v02;
- pr_info("SBI v0.2 TIME extension detected\n");
+ pr_info("SBI TIME extension detected\n");
} else {
__sbi_set_timer = __sbi_set_timer_v01;
}
if (sbi_probe_extension(SBI_EXT_IPI) > 0) {
__sbi_send_ipi = __sbi_send_ipi_v02;
- pr_info("SBI v0.2 IPI extension detected\n");
+ pr_info("SBI IPI extension detected\n");
} else {
__sbi_send_ipi = __sbi_send_ipi_v01;
}
if (sbi_probe_extension(SBI_EXT_RFENCE) > 0) {
__sbi_rfence= __sbi_rfence_v02;
- pr_info("SBI v0.2 RFENCE extension detected\n");
+ pr_info("SBI RFENCE extension detected\n");
} else {
__sbi_rfence= __sbi_rfence_v01;
}
Thanks. I'm just putting this one on for-next so you don't have to carry
around the diff.
[PATCH] include: acpi: A typo fix in the file cppc_acpi.h
s/folowing/following/
Signed-off-by: Bhaskar Chowdhury
---
include/acpi/cppc_acpi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index c7fc4524e151..d174721bab33 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -31,7 +31,7 @@
#defineCMD_READ 0
#defineCMD_WRITE 1
-/* Each register has the folowing format. */
+/* Each register has the following format. */
struct cpc_reg {
u8 descriptor;
u16 length;
--
2.30.2
[PATCH] RISC-V: kasan: Declare kasan_shallow_populate() static
From: Palmer Dabbelt
Without this I get a missing prototype warning.
Reported-by: kernel test robot
Fixes: e178d670f251 ("riscv/kasan: add KASAN_VMALLOC support")
Cc: sta...@vger.kernel.org
Signed-off-by: Palmer Dabbelt
---
arch/riscv/mm/kasan_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 5c35e0f71e88..4f85c6d0ddf8 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -155,7 +155,7 @@ static void __init kasan_populate(void *start, void *end)
memset(start, KASAN_SHADOW_INIT, end - start);
}
-void __init kasan_shallow_populate(void *start, void *end)
+static void __init kasan_shallow_populate(void *start, void *end)
{
unsigned long vaddr = (unsigned long)start & PAGE_MASK;
unsigned long vend = PAGE_ALIGN((unsigned long)end);
--
2.31.0.rc2.261.g7f71774620-goog
Re: [PATCH 0/3] Move kernel mapping outside the linear mapping
On Sat, 13 Mar 2021 01:26:47 PST (-0800), a...@ghiti.fr wrote: Hi Palmer, Le 3/9/21 à 9:54 PM, Palmer Dabbelt a écrit : On Thu, 25 Feb 2021 00:04:50 PST (-0800), a...@ghiti.fr wrote: I decided to split sv48 support in small series to ease the review. This patchset pushes the kernel mapping (modules and BPF too) to the last 4GB of the 64bit address space, this allows to: - implement relocatable kernel (that will come later in another patchset) that requires to move the kernel mapping out of the linear mapping to avoid to copy the kernel at a different physical address. - have a single kernel that is not relocatable (and then that avoids the performance penalty imposed by PIC kernel) for both sv39 and sv48. The first patch implements this behaviour, the second patch introduces a documentation that describes the virtual address space layout of the 64bit kernel and the last patch is taken from my sv48 series where I simply added the dump of the modules/kernel/BPF mapping. I removed the Reviewed-by on the first patch since it changed enough from last time and deserves a second look. Alexandre Ghiti (3): riscv: Move kernel mapping outside of linear mapping Documentation: riscv: Add documentation that describes the VM layout riscv: Prepare ptdump for vm layout dynamic addresses Documentation/riscv/index.rst | 1 + Documentation/riscv/vm-layout.rst | 61 ++ arch/riscv/boot/loader.lds.S | 3 +- arch/riscv/include/asm/page.h | 18 ++- arch/riscv/include/asm/pgtable.h | 37 + arch/riscv/include/asm/set_memory.h | 1 + arch/riscv/kernel/head.S | 3 +- arch/riscv/kernel/module.c | 6 +-- arch/riscv/kernel/setup.c | 3 ++ arch/riscv/kernel/vmlinux.lds.S | 3 +- arch/riscv/mm/fault.c | 13 + arch/riscv/mm/init.c | 81 +++-- arch/riscv/mm/kasan_init.c | 9 arch/riscv/mm/physaddr.c | 2 +- arch/riscv/mm/ptdump.c | 67 +++- 15 files changed, 258 insertions(+), 50 deletions(-) create mode 100644 Documentation/riscv/vm-layout.rst This generally looks good, but I'm getting a bunch of checkpatch warnings and some conflicts, do you mind fixing those up (and including your other kasan patch, as that's likely to conflict)? I fixed a few checkpatch warnings and rebased on top of for-next but had not conflicts. I have just sent the v2. Thanks. These (and the second patch of the one I just put on fixes) are for-next things, so I'm not going to get a look at them tonight because I want to make sure we don't have any more fixes outstanding.
Re: [PATCH] iio:imu:mpu6050: Modify matricies to matrices
On 3/16/21 7:41 PM, Guoqing chi wrote: > From: Guoqing Chi > > The complex number of "matrix" is "matrices". (I would say that the plural of matrix is matrices.) > > Signed-off-by: Guoqing Chi Acked-by: Randy Dunlap Thanks. > --- > include/linux/platform_data/invensense_mpu6050.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/platform_data/invensense_mpu6050.h > b/include/linux/platform_data/invensense_mpu6050.h > index 93974f4cfba1..f05b37521f67 100644 > --- a/include/linux/platform_data/invensense_mpu6050.h > +++ b/include/linux/platform_data/invensense_mpu6050.h > @@ -12,7 +12,7 @@ > * mounting matrix retrieved from device-tree) > * > * Contains platform specific information on how to configure the MPU6050 to > - * work on this platform. The orientation matricies are 3x3 rotation > matricies > + * work on this platform. The orientation matrices are 3x3 rotation matrices > * that are applied to the data to rotate from the mounting orientation to > the > * platform orientation. The values must be one of 0, 1, or -1 and each row > and > * column should have exactly 1 non-zero value. > -- ~Randy
[PATCH] sched: Warn on long periods of pending need_resched
From: Paul Turner
CPU scheduler marks need_resched flag to signal a schedule() on a
particular CPU. But, schedule() may not happen immediately in cases
where the current task is executing in the kernel mode (no
preemption state) for extended periods of time.
This patch adds a warn_on if need_resched is pending for more than the
time specified in sysctl resched_latency_warn_ms. Monitoring is done via
the tick and the accuracy is hence limited to jiffy scale. This also
means that we won't trigger the warning if the tick is disabled.
If resched_latency_warn_ms is set to the default value, only one warning
will be produced per boot.
This warning only exists under CONFIG_SCHED_DEBUG. If it goes off, it is
likely that there is a missing cond_resched() somewhere.
Signed-off-by: Paul Turner
Signed-off-by: Josh Don
---
We've caught various bugs using this patch. In fact, a followup patch to
this one will be a patch introducing a missing cond_resched(). However,
this may be too noisy to have as default enabled (especially given that
it requires some tuning); I'm open to having this default disabled
instead.
kernel/sched/core.c | 91
kernel/sched/sched.h | 6 +++
kernel/sysctl.c | 8
3 files changed, 105 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 98191218d891..ac037fc87d5e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -58,7 +58,25 @@ const_debug unsigned int sysctl_sched_features =
#include "features.h"
0;
#undef SCHED_FEAT
+
+/*
+ * Print a warning if need_resched is set for at least this long. At the
+ * default value, only a single warning will be printed per boot.
+ *
+ * Values less than 2 disable the feature.
+ *
+ * A kernel compiled with CONFIG_KASAN tends to run more slowly on average.
+ * Increase the need_resched timeout to reduce false alarms.
+ */
+#ifdef CONFIG_KASAN
+#define RESCHED_DEFAULT_WARN_LATENCY_MS 101
+#define RESCHED_BOOT_QUIET_SEC 600
+#else
+#define RESCHED_DEFAULT_WARN_LATENCY_MS 51
+#define RESCHED_BOOT_QUIET_SEC 300
#endif
+int sysctl_resched_latency_warn_ms = RESCHED_DEFAULT_WARN_LATENCY_MS;
+#endif /* CONFIG_SCHED_DEBUG */
/*
* Number of tasks to iterate in a single balance run.
@@ -4520,6 +4538,71 @@ unsigned long long task_sched_runtime(struct task_struct
*p)
return ns;
}
+#ifdef CONFIG_SCHED_DEBUG
+
+static inline u64 resched_latency_check(struct rq *rq)
+{
+ int latency_warn_ms = READ_ONCE(sysctl_resched_latency_warn_ms);
+ bool warn_only_once = (latency_warn_ms ==
RESCHED_DEFAULT_WARN_LATENCY_MS);
+ u64 need_resched_latency, now = rq_clock(rq);
+ static bool warned_once;
+
+ if (warn_only_once && warned_once)
+ return 0;
+
+ if (!need_resched() || latency_warn_ms < 2)
+ return 0;
+
+ /* Disable this warning for the first few mins after boot */
+ if (now < RESCHED_BOOT_QUIET_SEC * NSEC_PER_SEC)
+ return 0;
+
+ if (!rq->last_seen_need_resched_ns) {
+ rq->last_seen_need_resched_ns = now;
+ rq->ticks_without_resched = 0;
+ return 0;
+ }
+
+ rq->ticks_without_resched++;
+ need_resched_latency = now - rq->last_seen_need_resched_ns;
+ if (need_resched_latency <= latency_warn_ms * NSEC_PER_MSEC)
+ return 0;
+
+ warned_once = true;
+
+ return need_resched_latency;
+}
+
+static inline void resched_latency_warn(int cpu, u64 latency)
+{
+ static DEFINE_RATELIMIT_STATE(latency_check_ratelimit, 60 * 60 * HZ, 1);
+
+ WARN(__ratelimit(_check_ratelimit),
+"CPU %d: need_resched set for > %llu ns (%d ticks) "
+"without schedule\n",
+cpu, latency, cpu_rq(cpu)->ticks_without_resched);
+}
+
+
+static int __init setup_resched_latency_warn_ms(char *str)
+{
+ long val;
+
+ if ((kstrtol(str, 0, ))) {
+ pr_warn("Unable to set resched_latency_warn_ms\n");
+ return 1;
+ }
+
+ sysctl_resched_latency_warn_ms = val;
+ return 1;
+}
+__setup("resched_latency_warn_ms=", setup_resched_latency_warn_ms);
+#else
+static inline u64 resched_latency_check(struct rq *rq) { return 0; }
+static inline void resched_latency_warn(int cpu, u64 latency) {}
+#endif /* CONFIG_SCHED_DEBUG */
+
+
/*
* This function gets called by the timer code, with HZ frequency.
* We call it with interrupts disabled.
@@ -4531,6 +4614,7 @@ void scheduler_tick(void)
struct task_struct *curr = rq->curr;
struct rq_flags rf;
unsigned long thermal_pressure;
+ u64 resched_latency;
arch_scale_freq_tick();
sched_clock_tick();
@@ -4541,11 +4625,15 @@ void scheduler_tick(void)
thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure);
curr->sched_class->task_tick(rq, curr, 0);
+
Re: [PATCH 13/13] MAINTAINERS: Add entry for the bitmap API
On Tue, 2021-03-16 at 21:47 -0700, Yury Norov wrote: > [CC Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn] > > On Tue, Mar 16, 2021 at 01:45:51PM +0200, Andy Shevchenko wrote: > > On Mon, Mar 15, 2021 at 06:54:24PM -0700, Yury Norov wrote: > > > Add myself as maintainer for bitmap API and Andy and Rasmus as reviewers. > > > > > > I'm an author of current implementation of lib/find_bit and an active > > > contributor to lib/bitmap. It was spotted that there's no maintainer for > > > bitmap API. I'm willing to maintain it. > > > > > > Signed-off-by: Yury Norov > > > Acked-by: Andy Shevchenko > > > Acked-by: Rasmus Villemoes > > > --- > > > MAINTAINERS | 16 > > > 1 file changed, 16 insertions(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 3dd20015696e..44f94cdd5a20 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -3151,6 +3151,22 @@ F: Documentation/filesystems/bfs.rst > > > F: fs/bfs/ > > > F: include/uapi/linux/bfs_fs.h > > > > > > > > > +BITMAP API > > > +M: Yury Norov > > > +R: Andy Shevchenko > > > +R: Rasmus Villemoes > > > +S: Maintained > > > +F: include/asm-generic/bitops/find.h > > > +F: include/linux/bitmap.h > > > +F: lib/bitmap.c > > > +F: lib/find_bit.c > > > > > +F: lib/find_find_bit_benchmark.c > > > > Does this file exist? > > I guess checkpatch.pl nowadays has a MAINTAINER data base validation. > > No lib/find_find_bit_benchmark.c doesn't exist. It's a typo, it should > be lib/find_bit_benchmark.c. Checkpatch doesn't warn: > > yury:linux$ scripts/checkpatch.pl > 0013-MAINTAINERS-Add-entry-for-the-bitmap-API.patch > total: 0 errors, 0 warnings, 22 lines checked checkpatch does not validate filenames for each patch. checkpatch does have a --self-test=patterns capability that does validate file accessibility.
Re: [PATCH v3 1/2] riscv: Ensure page table writes are flushed when initializing KASAN vmalloc
On Sat, 13 Mar 2021 00:45:04 PST (-0800), a...@ghiti.fr wrote: Make sure that writes to kernel page table during KASAN vmalloc initialization are made visible by adding a sfence.vma. Signed-off-by: Alexandre Ghiti Reviewed-by: Palmer Dabbelt --- arch/riscv/mm/kasan_init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c index 1b968855d389..57bf4ae09361 100644 --- a/arch/riscv/mm/kasan_init.c +++ b/arch/riscv/mm/kasan_init.c @@ -187,6 +187,8 @@ void __init kasan_shallow_populate(void *start, void *end) } vaddr += PAGE_SIZE; } + + local_flush_tlb_all(); } void __init kasan_init(void) Thanks, this is on fixes.
Re: [question] Panic in dax_writeback_one
On Tue, Mar 16, 2021 at 8:00 PM chenjun (AM) wrote:
>
> 在 2021/3/12 1:25, Dan Williams 写道:
> > On Thu, Mar 11, 2021 at 4:20 AM Matthew Wilcox wrote:
> >>
> >> On Thu, Mar 11, 2021 at 07:48:25AM +, chenjun (AM) wrote:
> >>> static int dax_writeback_one(struct xa_state *xas, struct dax_device
> >>> *dax_dev, struct address_space *mapping, void *entry)
> >>> dax_flush(dax_dev, page_address(pfn_to_page(pfn)), count * PAGE_SIZE);
> >>> The pfn is returned by the driver. In my case, the pfn does not have
> >>> struct page. so pfn_to_page(pfn) return a wrong address.
> >>
> >> I wasn't involved, but I think the right solution here is simply to
> >> replace page_address(pfn_to_page(pfn)) with pfn_to_virt(pfn). I don't
> >> know why Dan decided to do this in the more complicated way.
> >
> > pfn_to_virt() only works for the direct-map. If pages are not mapped I
> > don't see how pfn_to_virt() is expected to work.
> >
> > The real question Chenjun is why are you writing a new simulator of
> > memory as a block-device vs reusing the pmem driver or brd?
> >
>
> Hi Dan
>
> In my case, I do not want to take memory to create the struct page of
> the memory my driver used.
There are efforts happening to drastically reduce that overhead. You
might want to check out Joao's work [1]. I think that direction holds
more promise than trying to extend FS_DAX_LIMITED.
[1]: http://lore.kernel.org/r/20201208172901.17384-1-joao.m.mart...@oracle.com
> And, I think this is also a problem for DCSSBLK.
If I understand correctly DAX replaced XIP for S390. There have not
been reports about this problem, and I can only guess because XIP
(eXecute-In-Place) is a read-only use case where dax_writeback_one()
is never triggered, or S390 just isn't using DCSSBLK anymore. The last
time I touched FS_DAX_LIMITED the DCSSBLK maintainers offered to just
delete this driver to get it out of the way.
>
> So I want to go back the older way if CONFIG_FS_DAX_LIMITED
>
> diff --git a/fs/dax.c b/fs/dax.c
> index b3d27fd..6395e84 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -867,6 +867,9 @@ static int dax_writeback_one(struct xa_state *xas,
> struct dax_device *dax_dev,
> {
> unsigned long pfn, index, count;
> long ret = 0;
> + void *kaddr;
> + pfn_t new_pfn_t;
> + pgoff_t pgoff;
>
> /*
> * A page got tagged dirty in DAX mapping? Something is seriously
> @@ -926,7 +929,25 @@ static int dax_writeback_one(struct xa_state *xas,
> struct dax_device *dax_dev,
> index = xas->xa_index & ~(count - 1);
>
> dax_entry_mkclean(mapping, index, pfn);
> - dax_flush(dax_dev, page_address(pfn_to_page(pfn)), count * PAGE_SIZE);
> +
> + if (!IS_ENABLED(CONFIG_FS_DAX_LIMITED) || pfn_valid(pfn))
> + kaddr = page_address(pfn_to_page(pfn));
> + else {
> + ret = bdev_dax_pgoff(mapping->host->i_sb->s_bdev, pfn <<
> PFN_SECTION_SHIFT, count << PAGE_SHIFT, );
This is broken:
mapping->host->i_sb->s_bdev
...there is no guarantee that the superblock associated with the
mapping is hosted on the same block device associated with the passed
in dax_device. See dax_rtdev in xfs_open_devices().
Re: [PATCH 06/13] lib: extend the scope of small_const_nbits() macro
On Tue, Mar 16, 2021 at 09:56:49AM +0100, Rasmus Villemoes wrote:
> On 16/03/2021 02.54, Yury Norov wrote:
> > find_bit would also benefit from small_const_nbits() optimizations.
> >
> > Signed-off-by: Yury Norov
> > ---
> > include/asm-generic/bitsperlong.h | 9 +
> > include/linux/bitmap.h| 3 ---
> > 2 files changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/asm-generic/bitsperlong.h
> > b/include/asm-generic/bitsperlong.h
> > index 3905c1c93dc2..96032f4f908f 100644
> > --- a/include/asm-generic/bitsperlong.h
> > +++ b/include/asm-generic/bitsperlong.h
> > @@ -23,4 +23,13 @@
> > #define BITS_PER_LONG_LONG 64
> > #endif
> >
> > +#define SMALL_CONST(n) (__builtin_constant_p(n) && (unsigned long)(n) <
> > BITS_PER_LONG)
> > +
> > +/*
> > + * The valid number of bits for a bitmap to be small enough, or in other
> > words,
> > + * fit into a single machine word is 1 to BITS_PER_LONG inclusively. 0 is
> > not a
> > + * valid number for size, and most probably a sing of error.
> > + */
> > +#define small_const_nbits(n) SMALL_CONST((n) - 1)
> > +
>
> I still don't see the point of introducing SMALL_CONST and still don't
> like the much-too-generic-name - especially since AFAICT you don't
> actually use it anywhere outside the definition of small_const_nbits()?
>
> > #endif /* __ASM_GENERIC_BITS_PER_LONG */
> > diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> > index adf7bd9f0467..bc13a890ecc1 100644
> > --- a/include/linux/bitmap.h
> > +++ b/include/linux/bitmap.h
> > @@ -224,9 +224,6 @@ extern int bitmap_print_to_pagebuf(bool list, char *buf,
> > * so make such users (should any ever turn up) call the out-of-line
> > * versions.
> > */
>
> You added another comment near its new definition, but the left-behind
> comment in bitmap.h is now somewhat confusing, no? I suggest expanding
> your new comment a bit so it's clear why we're interested in whether a
> bitmap is known at compile-time to consist of exactly one word:
>
> /*
> small_const_nbits(n) is true precisely when it is known at compile-time
> that BITMAP_SIZE(n) is 1, i.e. 1 <= n <= BITS_PER_LONG. This allows
> various bit/bitmap APIs to provide a fast inline implementation. Bitmaps
> of size 0 are very rare, and a compile-time-known-size 0 is most likely
> a sign of error. They will be handled correctly by the bit/bitmap APIs,
> but using the out-of-line functions, so that the inline implementations
> can unconditionally dereference the pointer(s).
> */
Ok, make sense
> > -#define small_const_nbits(nbits) \
> > - (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG && (nbits) > 0)
> > -
> > static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
> > {
> > unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
> >
>
> Rasmus
Re: [PATCH] RISC-V: Fix out-of-bounds accesses in init_resources()
On Fri, 12 Mar 2021 07:46:34 PST (-0800), ge...@linux-m68k.org wrote:
init_resources() allocates an array of resources, based on the current
total number of memory regions and reserved memory regions. However,
allocating this array using memblock_alloc() might increase the number
of reserved memory regions. If that happens, populating the array later
based on the new number of regions will cause out-of-bounds writes
beyond the end of the allocated array.
Fix this by allocating one more entry, which may or may not be used.
Fixes: 797f0375dd2ef5cd ("RISC-V: Do not allocate memblock while iterating reserved
memblocks")
Signed-off-by: Geert Uytterhoeven
---
Tested on vexriscv, which works now using L1_CACHE_SHIFT = 6, too.
This issue may show up during early boot as:
Unable to handle kernel paging request at virtual address c808
Oops [#1]
CPU: 0 PID: 0 Comm: swapper Not tainted
5.11.0-orangecrab-00023-g7c4fc8e3e982-dirty #137
epc: c04d6660 ra : c04d6560 sp : c05ddf70
gp : c0678bc0 tp : c05e5b40 t0 : c800
t1 : 0003 t2 : s0 : c05ddfc0
s1 : c800 a0 : a1 : c7e0
a2 : 0005 a3 : 0001 a4 : 000c
a5 : a6 : c04fe000 a7 : 000c
s2 : c04fe098 s3 : 00a0 s4 : c760
s5 : c04fe0dc s6 : 8200 s7 : c059f1d4
s8 : 81000200 s9 : c059f1f0 s10: 8200
s11: c059f1d4 t3 : 405dbb60 t4 : c05e6f08
t5 : 81000200 t6 : 40501000
status: 0100 badaddr: c808 cause: 000f
random: get_random_bytes called from print_oops_end_marker+0x38/0x7c with
crng_init=0
---[ end trace ]---
or much later as:
Unable to handle kernel paging request at virtual address 69726573
---
arch/riscv/kernel/setup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index e85bacff1b5075ee..f8f15332caa20263 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -147,7 +147,8 @@ static void __init init_resources(void)
bss_res.end = __pa_symbol(__bss_stop) - 1;
bss_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
- mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt) *
sizeof(*mem_res);
+ /* + 1 as memblock_alloc() might increase memblock.reserved.cnt */
+ mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt + 1) *
sizeof(*mem_res);
mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
if (!mem_res)
panic("%s: Failed to allocate %zu bytes\n", __func__,
mem_res_sz);
Thanks, this is on fixes.
Re: [RFC PATCH v1 0/3] IPI and remote TBL flush improvement
On Thu, 11 Mar 2021 08:47:09 PST (-0800), Anup Patel wrote: This series primarily does two things: 1. Allows RISC-V IPI provider to specificy whether IPI operations are suitable for remote TLB flush (PATCH1) 2. Improve remote TLB flush to use IPIs whenever possible (PATCH2) 3. Allow irqchip drivers to handle IPIs from chained IRQ handlers (PATCH3) IIUC this last one isn't technically used in both forms, as we don't have any drivers that behave that way yet? I'm OK taking it, under the assumption it makes keeping the out-of-tree driver for the draft interrupt controller easier, but I was wrong then it's probably out of order so I figured I'd check. Aside from that this generally LGTM. We are making quite a bit of mess in here, but I don't really see a way around that as we need to support the old hardware. We can always do a cleanup when the specifications settle down. Oddly enough this did come up in IRC recently and there may be some new bits in the CLINT on the FU740 that allow S-mode SW interrupts to show up directly -- there's at least a "delegate supervisor software interrupt" bit now, but the manual only calls out machine mode as being able to set it (though IIUC it's memory mapped, so not sure how that would be enforced). Not saying we need that in order to take the last patch, but if it is possible it's probably worth giving it a shot when the boards show up. This series also a preparatory series for upcoming RISC-V advanced interrupt architecture (AIA) support. These patches can be found in riscv_ipi_imp_v1 branch at https://github.com/avpatel/linux Anup Patel (3): RISC-V: IPI provider should specify if we can use IPI for remote FENCE RISC-V: Use IPIs for remote TLB flush when possible RISC-V: Add handle_IPI_noregs() for irqchip drivers arch/riscv/include/asm/smp.h | 19 +- arch/riscv/kernel/sbi.c | 2 +- arch/riscv/kernel/smp.c | 30 +++ arch/riscv/mm/cacheflush.c| 2 +- arch/riscv/mm/tlbflush.c | 62 --- drivers/clocksource/timer-clint.c | 2 +- 6 files changed, 91 insertions(+), 26 deletions(-)
drivers/net/ethernet/freescale/ucc_geth.c:2167:47: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1df27313f50a57497c1faeb6a6ae4ca939c85a7d commit: 9b0dfef4755301d9f7fcef63e2f64d23649bebb4 ethernet: ucc_geth: simplify rx/tx allocations date: 8 weeks ago config: powerpc-randconfig-s031-20210317 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-277-gc089cd2d-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9b0dfef4755301d9f7fcef63e2f64d23649bebb4 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 9b0dfef4755301d9f7fcef63e2f64d23649bebb4 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/net/ethernet/freescale/ucc_geth.c:243:21: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ drivers/net/ethernet/freescale/ucc_geth.c:243:21: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr drivers/net/ethernet/freescale/ucc_geth.c:243:21: sparse: got restricted __be32 [noderef] __iomem * drivers/net/ethernet/freescale/ucc_geth.c:404:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] __iomem *addr @@ got restricted __be16 [noderef] [usertype] __iomem * @@ drivers/net/ethernet/freescale/ucc_geth.c:404:22: sparse: expected unsigned short volatile [noderef] [usertype] __iomem *addr drivers/net/ethernet/freescale/ucc_geth.c:404:22: sparse: got restricted __be16 [noderef] [usertype] __iomem * drivers/net/ethernet/freescale/ucc_geth.c:405:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] __iomem *addr @@ got restricted __be16 [noderef] [usertype] __iomem * @@ drivers/net/ethernet/freescale/ucc_geth.c:405:22: sparse: expected unsigned short volatile [noderef] [usertype] __iomem *addr drivers/net/ethernet/freescale/ucc_geth.c:405:22: sparse: got restricted __be16 [noderef] [usertype] __iomem * drivers/net/ethernet/freescale/ucc_geth.c:406:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] __iomem *addr @@ got restricted __be16 [noderef] [usertype] __iomem * @@ drivers/net/ethernet/freescale/ucc_geth.c:406:22: sparse: expected unsigned short volatile [noderef] [usertype] __iomem *addr drivers/net/ethernet/freescale/ucc_geth.c:406:22: sparse: got restricted __be16 [noderef] [usertype] __iomem * drivers/net/ethernet/freescale/ucc_geth.c:448:23: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected restricted __be16 [noderef] [usertype] __iomem *reg @@ got unsigned short [noderef] __iomem * @@ drivers/net/ethernet/freescale/ucc_geth.c:448:23: sparse: expected restricted __be16 [noderef] [usertype] __iomem *reg drivers/net/ethernet/freescale/ucc_geth.c:448:23: sparse: got unsigned short [noderef] __iomem * drivers/net/ethernet/freescale/ucc_geth.c:1316:26: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ drivers/net/ethernet/freescale/ucc_geth.c:1316:26: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr drivers/net/ethernet/freescale/ucc_geth.c:1316:26: sparse: got restricted __be32 [noderef] __iomem * drivers/net/ethernet/freescale/ucc_geth.c:1343:19: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ drivers/net/ethernet/freescale/ucc_geth.c:1343:19: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr drivers/net/ethernet/freescale/ucc_geth.c:1343:19: sparse: got restricted __be32 [noderef] __iomem * drivers/net/ethernet/freescale/ucc_geth.c:1389:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef]
Re: [PATCH 13/13] MAINTAINERS: Add entry for the bitmap API
[CC Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn] On Tue, Mar 16, 2021 at 01:45:51PM +0200, Andy Shevchenko wrote: > On Mon, Mar 15, 2021 at 06:54:24PM -0700, Yury Norov wrote: > > Add myself as maintainer for bitmap API and Andy and Rasmus as reviewers. > > > > I'm an author of current implementation of lib/find_bit and an active > > contributor to lib/bitmap. It was spotted that there's no maintainer for > > bitmap API. I'm willing to maintain it. > > > > Signed-off-by: Yury Norov > > Acked-by: Andy Shevchenko > > Acked-by: Rasmus Villemoes > > --- > > MAINTAINERS | 16 > > 1 file changed, 16 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 3dd20015696e..44f94cdd5a20 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -3151,6 +3151,22 @@ F: Documentation/filesystems/bfs.rst > > F: fs/bfs/ > > F: include/uapi/linux/bfs_fs.h > > > > +BITMAP API > > +M: Yury Norov > > +R: Andy Shevchenko > > +R: Rasmus Villemoes > > +S: Maintained > > +F: include/asm-generic/bitops/find.h > > +F: include/linux/bitmap.h > > +F: lib/bitmap.c > > +F: lib/find_bit.c > > > +F: lib/find_find_bit_benchmark.c > > Does this file exist? > I guess checkpatch.pl nowadays has a MAINTAINER data base validation. No lib/find_find_bit_benchmark.c doesn't exist. It's a typo, it should be lib/find_bit_benchmark.c. Checkpatch doesn't warn: yury:linux$ scripts/checkpatch.pl 0013-MAINTAINERS-Add-entry-for-the-bitmap-API.patch total: 0 errors, 0 warnings, 22 lines checked > > +F: lib/test_bitmap.c > > +F: tools/include/asm-generic/bitops/find.h > > +F: tools/include/linux/bitmap.h > > +F: tools/lib/bitmap.c > > +F: tools/lib/find_bit.c > > + > > BLINKM RGB LED DRIVER > > M: Jan-Simon Moeller > > S: Maintained > > -- > > 2.25.1 > > > > -- > With Best Regards, > Andy Shevchenko >
Re: [PATCH] md: bcache: Trivial typo fixes in the file journal.c
On 3/17/21 12:30 PM, Bhaskar Chowdhury wrote:
>
> s/condidate/candidate/
> s/folowing/following/
>
> Signed-off-by: Bhaskar Chowdhury
I will add it in my for-next queue.
Thanks.
Coly Li
> ---
> drivers/md/bcache/journal.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/md/bcache/journal.c b/drivers/md/bcache/journal.c
> index c6613e817333..9f2eb8dec803 100644
> --- a/drivers/md/bcache/journal.c
> +++ b/drivers/md/bcache/journal.c
> @@ -111,7 +111,7 @@ reread: left = ca->sb.bucket_size - offset;
>* Check from the oldest jset for last_seq. If
>* i->j.seq < j->last_seq, it means the oldest jset
>* in list is expired and useless, remove it from
> - * this list. Otherwise, j is a condidate jset for
> + * this list. Otherwise, j is a candidate jset for
>* further following checks.
>*/
> while (!list_empty(list)) {
> @@ -498,7 +498,7 @@ static void btree_flush_write(struct cache_set *c)
>* - If there are matched nodes recorded in btree_nodes[],
>* they are clean now (this is why and how the oldest
>* journal entry can be reclaimed). These selected nodes
> - * will be ignored and skipped in the folowing for-loop.
> + * will be ignored and skipped in the following for-loop.
>*/
> if (((btree_current_write(b)->journal - fifo_front_p) &
>mask) != 0) {
> --
> 2.30.2
>
Re: [PATCH] sched: swait: use wake_up_process() instead of wake_up_state()
On Tue, 2021-03-16 at 19:20 +0800, Wang Qing wrote:
> Why not just use wake_up_process().
IMO this is not an improvement. There are other places where explicit
TASK_NORMAL is used as well, and they're all perfectly clear as is.
> Signed-off-by: Wang Qing
> ---
> kernel/sched/swait.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c
> index e1c655f..7a24925
> --- a/kernel/sched/swait.c
> +++ b/kernel/sched/swait.c
> @@ -69,7 +69,7 @@ void swake_up_all(struct swait_queue_head *q)
> while (!list_empty()) {
> curr = list_first_entry(, typeof(*curr), task_list);
>
> - wake_up_state(curr->task, TASK_NORMAL);
> + wake_up_process(curr->task);
> list_del_init(>task_list);
>
> if (list_empty())
Re: [PATCH v5 05/10] scsi: ufshpb: Region inactivation in host mode
On 2021-03-17 10:28, Daejun Park wrote:
>> ---
>> drivers/scsi/ufs/ufshpb.c | 14 ++
>> drivers/scsi/ufs/ufshpb.h | 1 +
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
>> index 6f4fd22eaf2f..0744feb4d484 100644
>> --- a/drivers/scsi/ufs/ufshpb.c
>> +++ b/drivers/scsi/ufs/ufshpb.c
>> @@ -907,6 +907,7 @@ static int ufshpb_execute_umap_req(struct
>> ufshpb_lu *hpb,
>>
>> blk_execute_rq_nowait(q, NULL, req, 1, ufshpb_umap_req_compl_fn);
>>
>> +hpb->stats.umap_req_cnt++;
>> return 0;
>> }
>>
>> @@ -1103,6 +1104,12 @@ static int ufshpb_issue_umap_req(struct
>> ufshpb_lu *hpb,
>> return -EAGAIN;
>> }
>>
>> +static int ufshpb_issue_umap_single_req(struct ufshpb_lu *hpb,
>> +struct ufshpb_region *rgn)
>> +{
>> +return ufshpb_issue_umap_req(hpb, rgn);
>> +}
>> +
>> static int ufshpb_issue_umap_all_req(struct ufshpb_lu *hpb)
>> {
>> return ufshpb_issue_umap_req(hpb, NULL);
>> @@ -1115,6 +1122,10 @@ static void __ufshpb_evict_region(struct
>> ufshpb_lu *hpb,
>> struct ufshpb_subregion *srgn;
>> int srgn_idx;
>>
>> +
>> +if (hpb->is_hcm && ufshpb_issue_umap_single_req(hpb, rgn))
>
> __ufshpb_evict_region() is called with rgn_state_lock held and IRQ
> disabled,
> when ufshpb_issue_umap_single_req() invokes blk_execute_rq_nowait(),
> below
> warning shall pop up every time, fix it?
>
> void blk_execute_rq_nowait(struct request_queue *q, struct gendisk
> *bd_disk,
> struct request *rq, int at_head,
> rq_end_io_fn *done)
> {
> WARN_ON(irqs_disabled());
> ...
>
Moreover, since we are here with rgn_state_lock held and IRQ
disabled,
in ufshpb_get_req(), rq = kmem_cache_alloc(hpb->map_req_cache,
GFP_KERNEL)
has the GFP_KERNEL flag, scheduling while atomic???
I think your comment applies to ufshpb_issue_umap_all_req as well,
Which is called from slave_configure/scsi_add_lun.
Since the host-mode series is utilizing the framework laid by the
device-mode,
Maybe you can add this comment to Daejun's last version?
Hi Avri, Can Guo
I think ufshpb_issue_umap_single_req() can be moved to end of
ufshpb_evict_region().
Then we can avoid rgn_state_lock when it sends unmap command.
I am not the expert here, please you two fix it. I am just reporting
what can be wrong. Anyways, ufshpb_issue_umap_single_req() should not
be called with rgn_state_lock held - think about below (another deadly)
scenario.
lock(rgn_state_lock)
ufshpb_issue_umap_single_req()
ufshpb_prep()
lock(rgn_state_lock) <-- recursive spin_lock
BTW, @Daejun shouldn't we stop passthrough cmds from stepping
into ufshpb_prep()? In current code, you are trying to use below
check to block cmds other than write/discard/read, but a passthrough
cmd can not be blocked by the check.
if (!ufshpb_is_write_or_discard_cmd(cmd) &&
!ufshpb_is_read_cmd(cmd))
return 0;
Thanks,
Can Guo.
Thanks,
Daejun
Thanks,
Avri
Can Guo.
> Thanks.
> Can Guo.
>
>> +return;
>> +
>> lru_info = >lru_info;
>>
>> dev_dbg(>sdev_ufs_lu->sdev_dev, "evict region %d\n",
>> rgn->rgn_idx);
>> @@ -1855,6 +1866,7 @@ ufshpb_sysfs_attr_show_func(rb_noti_cnt);
>> ufshpb_sysfs_attr_show_func(rb_active_cnt);
>> ufshpb_sysfs_attr_show_func(rb_inactive_cnt);
>> ufshpb_sysfs_attr_show_func(map_req_cnt);
>> +ufshpb_sysfs_attr_show_func(umap_req_cnt);
>>
>> static struct attribute *hpb_dev_stat_attrs[] = {
>> _attr_hit_cnt.attr,
>> @@ -1863,6 +1875,7 @@ static struct attribute *hpb_dev_stat_attrs[] =
>> {
>> _attr_rb_active_cnt.attr,
>> _attr_rb_inactive_cnt.attr,
>> _attr_map_req_cnt.attr,
>> +_attr_umap_req_cnt.attr,
>> NULL,
>> };
>>
>> @@ -1978,6 +1991,7 @@ static void ufshpb_stat_init(struct ufshpb_lu
>> *hpb)
>> hpb->stats.rb_active_cnt = 0;
>> hpb->stats.rb_inactive_cnt = 0;
>> hpb->stats.map_req_cnt = 0;
>> +hpb->stats.umap_req_cnt = 0;
>> }
>>
>> static void ufshpb_param_init(struct ufshpb_lu *hpb)
>> diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
>> index bd4308010466..84598a317897 100644
>> --- a/drivers/scsi/ufs/ufshpb.h
>> +++ b/drivers/scsi/ufs/ufshpb.h
>> @@ -186,6 +186,7 @@ struct ufshpb_stats {
>> u64 rb_inactive_cnt;
>> u64 map_req_cnt;
>> u64 pre_req_cnt;
>> +u64 umap_req_cnt;
>> };
>>
>> struct ufshpb_lu {
Re: [PATCH v3 2/2] rockchip: rk3399: Add support for FriendlyARM NanoPi R4S
Hi Pavel,
On 2021-03-17 03:38, Pavel Machek wrote:
>
> On Tue 2021-03-16 16:34:50, Geert Uytterhoeven wrote:
> > Hi Tianling,
> >
> > CC Jacek, Pavel
> >
> > On Tue, Mar 16, 2021 at 4:00 PM Tianling Shen wrote:
> > > On 2021-03-16 02:23 Geert Uytterhoeven wrote:
> > > > Personally, I'm not so fond of the -%u node names, and prefer
> > > > -. With the former, it's way too easy to have a silent
> > > > override in your .dts(i) stack.
> > > > Cfr. commit 45f5d5a9e34d3fe4 ("arm64: dts: renesas: r8a77995: draak:
> > > > Fix backlight regulator name")
> > >
> > > How about using `lan-led`, `sys-led` and `wan-led` here?
> >
> > Documentation/devicetree/bindings/leds/leds-gpio.yaml says "led-%u"
> > is the preferred form, but that anything containing "led" as a substring
> > is accepted. So I'd go for "led-lan" etc.
> >
> > BTW, you can validate your DTB against the leds-gpio DT bindings
> > by running:
> >
> > make dtbs_check
> > DT_SCHEMA_FILES=Documentation/devicetree/bindings/leds/leds-gpio.yaml
> >
> > Background info for CCed parties:
> >
> https://lore.kernel.org/linux-arm-kernel/20210316150033.15987-1-cns...@gmail.com/
>
> I don't care much either way, lan-0 is okay as is lan-led.
>
> but...
>
> + label = "nanopi-r4s:green:lan";
> + label = "nanopi-r4s:red:sys";
> + label = "nanopi-r4s:green:wan";
>
>
> It would be good to have common labels, that means LED_FUNCTION_LAN,
> LED_FUNCTION_WAN, and figuring out something better than "sys",
> possibly LED_FUNCTION_FAULT?
LED_FUNCTION_POWER for "sys" would be fine, I think.
However, Documentation/leds/leds-class.rst says the form of naming is
"devicename:color:function",
and according to the given examples, as well as other dts(i), would it
be okay to use `green:lan`
etc. as the lable?
>
> Thanks,
> Pavel
>
> --
> http://www.livejournal.com/~pavelmachek
Thanks,
Tianling.
[PATCH v3 2/2] arm64: dts: ti: k3-am642-evm: Add USB support
AM64 EVM board has a micro USB 2.0 AB connector and the USB0_VBUS is
connected with a resistor divider in between. USB0_DRVVBUS pin is muxed
between USB0_DRVVBUS and GPIO1_79 signals.
Add the corresponding properties and set the pinmux mode for USB subsystem
in the evm dts file.
Signed-off-by: Aswath Govindraju
Acked-by: Roger Quadros
---
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 25fa6fbc0619..1365e3164294 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -210,6 +210,12 @@
AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
>;
};
+
+ main_usb0_pins_default: main-usb0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19)
USB0_DRVVBUS */
+ >;
+ };
};
_uart0 {
@@ -335,6 +341,18 @@
disable-wp;
};
+ {
+ ti,vbus-divider;
+ ti,usb2-only;
+};
+
+ {
+ dr_mode = "otg";
+ maximum-speed = "high-speed";
+ pinctrl-names = "default";
+ pinctrl-0 = <_usb0_pins_default>;
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins_default
--
2.17.1
[PATCH] md: bcache: Trivial typo fixes in the file journal.c
s/condidate/candidate/
s/folowing/following/
Signed-off-by: Bhaskar Chowdhury
---
drivers/md/bcache/journal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/bcache/journal.c b/drivers/md/bcache/journal.c
index c6613e817333..9f2eb8dec803 100644
--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -111,7 +111,7 @@ reread: left = ca->sb.bucket_size - offset;
* Check from the oldest jset for last_seq. If
* i->j.seq < j->last_seq, it means the oldest jset
* in list is expired and useless, remove it from
-* this list. Otherwise, j is a condidate jset for
+* this list. Otherwise, j is a candidate jset for
* further following checks.
*/
while (!list_empty(list)) {
@@ -498,7 +498,7 @@ static void btree_flush_write(struct cache_set *c)
* - If there are matched nodes recorded in btree_nodes[],
* they are clean now (this is why and how the oldest
* journal entry can be reclaimed). These selected nodes
-* will be ignored and skipped in the folowing for-loop.
+* will be ignored and skipped in the following for-loop.
*/
if (((btree_current_write(b)->journal - fifo_front_p) &
mask) != 0) {
--
2.30.2
[PATCH v3 1/2] arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem
Add DT node for the single USB subsystem in main dtsi file.
Signed-off-by: Aswath Govindraju
Acked-by: Roger Quadros
---
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 30
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 0cf727e3d1e2..7e7997e3adff 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -491,4 +491,34 @@
ti,cpts-periodic-outputs = <6>;
ti,cpts-ext-ts-inputs = <8>;
};
+
+ usbss0: cdns-usb@f90{
+ compatible = "ti,am64-usb";
+ reg = <0x00 0xf90 0x00 0x100>;
+ power-domains = <_pds 161 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 161 9>, <_clks 161 1>;
+ clock-names = "ref", "lpm";
+ assigned-clocks = <_clks 161 9>; /* USB2_REFCLK */
+ assigned-clock-parents = <_clks 161 10>; /* HF0SC0 */
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ usb0: usb@f40{
+ compatible = "cdns,usb3";
+ reg = <0x00 0xf40 0x00 0x1>,
+ <0x00 0xf41 0x00 0x1>,
+ <0x00 0xf42 0x00 0x1>;
+ reg-names = "otg",
+ "xhci",
+ "dev";
+ interrupts = , /*
irq.0 */
+, /*
irq.6 */
+; /*
otgirq */
+ interrupt-names = "host",
+ "peripheral",
+ "otg";
+ maximum-speed = "super-speed";
+ dr_mode = "otg";
+ };
+ };
};
--
2.17.1
[PATCH v3 0/2] AM64: Add USB support
The following series of patches, add USB support for AM642 evm. USB test logs, https://pastebin.ubuntu.com/p/YSQRBWGmzd/ Changes since v2: - dropped compatible string "ti,j721e-usb" leading to DT schema errors - Reran test logs - Couldn't pick up reviewed-by from kishon as a change was made in the patch Changes since v1: - Rebased the patches on top of ti-k3-dts-next - Added test logs Aswath Govindraju (2): arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem arm64: dts: ti: k3-am642-evm: Add USB support arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 30 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 18 ++ 2 files changed, 48 insertions(+) -- 2.17.1
[PATCH] wireless: intel: iwlwifi: fw: api: Absolute rudimentary typo fixes in the file power.h
s/folowing/following/
s/Celsuis/Celsius/
s/temerature/temperature/ ...twice
Signed-off-by: Bhaskar Chowdhury
---
drivers/net/wireless/intel/iwlwifi/fw/api/power.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
b/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
index 798417182d54..f7c7852127d3 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
@@ -54,7 +54,7 @@ struct iwl_ltr_config_cmd_v1 {
* @flags: See iwl_ltr_config_flags
* @static_long: static LTR Long register value.
* @static_short: static LTR Short register value.
- * @ltr_cfg_values: LTR parameters table values (in usec) in folowing order:
+ * @ltr_cfg_values: LTR parameters table values (in usec) in following order:
* TX, RX, Short Idle, Long Idle. Used only if %LTR_CFG_FLAG_UPDATE_VALUES
* is set.
* @ltr_short_idle_timeout: LTR Short Idle timeout (in usec). Used only if
@@ -493,7 +493,7 @@ union iwl_ppag_table_cmd {
* Roaming Energy Delta Threshold, otherwise use normal Energy Delta
* Threshold. Typical energy threshold is -72dBm.
* @bf_temp_threshold: This threshold determines the type of temperature
- * filtering (Slow or Fast) that is selected (Units are in Celsuis):
+ * filtering (Slow or Fast) that is selected (Units are in Celsius):
* If the current temperature is above this threshold - Fast filter
* will be used, If the current temperature is below this threshold -
* Slow filter will be used.
@@ -501,12 +501,12 @@ union iwl_ppag_table_cmd {
* calculated for this and the last passed beacon is greater than this
* threshold. Zero value means that the temperature change is ignored for
* beacon filtering; beacons will not be forced to be sent to driver
- * regardless of whether its temerature has been changed.
+ * regardless of whether its temperature has been changed.
* @bf_temp_slow_filter: Send Beacon to driver if delta in temperature values
* calculated for this and the last passed beacon is greater than this
* threshold. Zero value means that the temperature change is ignored for
* beacon filtering; beacons will not be forced to be sent to driver
- * regardless of whether its temerature has been changed.
+ * regardless of whether its temperature has been changed.
* @bf_enable_beacon_filter: 1, beacon filtering is enabled; 0, disabled.
* @bf_debug_flag: beacon filtering debug configuration
* @bf_escape_timer: Send beacons to to driver if no beacons were passed
--
2.30.2
Re: [PATCH v5 03/24] wfx: add Makefile/Kconfig
On Mon, Mar 15, 2021 at 05:21:35PM +0100, Jérôme Pouiller wrote: > Hi Leon, > > On Monday 15 March 2021 16:11:52 CET Leon Romanovsky wrote: > > On Mon, Mar 15, 2021 at 02:24:40PM +0100, Jerome Pouiller wrote: > > > From: Jérôme Pouiller > > > > > > Signed-off-by: Jérôme Pouiller > > > --- > > > drivers/net/wireless/silabs/wfx/Kconfig | 12 +++ > > > drivers/net/wireless/silabs/wfx/Makefile | 26 > > > 2 files changed, 38 insertions(+) > > > create mode 100644 drivers/net/wireless/silabs/wfx/Kconfig > > > create mode 100644 drivers/net/wireless/silabs/wfx/Makefile > > > > > > diff --git a/drivers/net/wireless/silabs/wfx/Kconfig > > > b/drivers/net/wireless/silabs/wfx/Kconfig > > > new file mode 100644 > > > index ..3be4b1e735e1 > > > --- /dev/null > > > +++ b/drivers/net/wireless/silabs/wfx/Kconfig > > > @@ -0,0 +1,12 @@ > > > +config WFX > > > + tristate "Silicon Labs wireless chips WF200 and further" > > > + depends on MAC80211 > > > + depends on MMC || !MMC # do not allow WFX=y if MMC=m > > > + depends on (SPI || MMC) > > > + help > > > + This is a driver for Silicons Labs WFxxx series (WF200 and > > > further) > > > + chipsets. This chip can be found on SPI or SDIO buses. > > > + > > > + Silabs does not use a reliable SDIO vendor ID. So, to avoid > > > conflicts, > > > + the driver won't probe the device if it is not also declared in > > > the > > > + Device Tree. > > > diff --git a/drivers/net/wireless/silabs/wfx/Makefile > > > b/drivers/net/wireless/silabs/wfx/Makefile > > > new file mode 100644 > > > index ..f399962c8619 > > > --- /dev/null > > > +++ b/drivers/net/wireless/silabs/wfx/Makefile > > > @@ -0,0 +1,26 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > + > > > +# Necessary for CREATE_TRACE_POINTS > > > +CFLAGS_debug.o = -I$(src) > > > > I wonder if it is still relevant outside of the staging tree. > > It seems this pattern is common in the main tree. You suggest to relocate > trace.h to include/trace/events? No, leave it as it. Sorry for the noise. Thanks > > -- > Jérôme Pouiller > >
[tip:irq/urgent] BUILD SUCCESS ef4cb70a4c22bf301cd757dcc838dc8ca9526477
os2allyesconfig cskydefconfig alpha defconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20210316 i386 randconfig-a005-20210316 i386 randconfig-a002-20210316 i386 randconfig-a003-20210316 i386 randconfig-a004-20210316 i386 randconfig-a006-20210316 x86_64 randconfig-a011-20210316 x86_64 randconfig-a016-20210316 x86_64 randconfig-a013-20210316 x86_64 randconfig-a014-20210316 x86_64 randconfig-a015-20210316 x86_64 randconfig-a012-20210316 i386 randconfig-a013-20210316 i386 randconfig-a016-20210316 i386 randconfig-a011-20210316 i386 randconfig-a012-20210316 i386 randconfig-a015-20210316 i386 randconfig-a014-20210316 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a006-20210316 x86_64 randconfig-a001-20210316 x86_64 randconfig-a005-20210316 x86_64 randconfig-a004-20210316 x86_64 randconfig-a003-20210316 x86_64 randconfig-a002-20210316 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH] ftrace: Fix spelling mistake "disabed" -> "disabled"
On Thu, 11 Mar 2021 01:40:22 PST (-0800), colin.k...@canonical.com wrote:
From: Colin Ian King
There is a spelling mistake in a comment, fix it.
Signed-off-by: Colin Ian King
---
arch/csky/kernel/probes/ftrace.c | 2 +-
arch/riscv/kernel/probes/ftrace.c | 2 +-
arch/x86/kernel/kprobes/ftrace.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/csky/kernel/probes/ftrace.c b/arch/csky/kernel/probes/ftrace.c
index ae2b1c7b3b5c..ef2bb9bd9605 100644
--- a/arch/csky/kernel/probes/ftrace.c
+++ b/arch/csky/kernel/probes/ftrace.c
@@ -9,7 +9,7 @@ int arch_check_ftrace_location(struct kprobe *p)
return 0;
}
-/* Ftrace callback handler for kprobes -- called under preepmt disabed */
+/* Ftrace callback handler for kprobes -- called under preepmt disabled */
void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *ops, struct ftrace_regs *fregs)
{
diff --git a/arch/riscv/kernel/probes/ftrace.c
b/arch/riscv/kernel/probes/ftrace.c
index 2dfb33fdac74..17ca5e923bb0 100644
--- a/arch/riscv/kernel/probes/ftrace.c
+++ b/arch/riscv/kernel/probes/ftrace.c
@@ -2,7 +2,7 @@
#include
-/* Ftrace callback handler for kprobes -- called under preepmt disabed */
+/* Ftrace callback handler for kprobes -- called under preepmt disabled */
void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *ops, struct ftrace_regs *fregs)
{
diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
index 373e5fa3ce1f..51c7f5271aee 100644
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -12,7 +12,7 @@
#include "common.h"
-/* Ftrace callback handler for kprobes -- called under preepmt disabed */
+/* Ftrace callback handler for kprobes -- called under preepmt disabled */
void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *ops, struct ftrace_regs *fregs)
{
Thanks, this is on fixes.
Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism
On Mon, Mar 15, 2021 at 06:32:32PM +, Raphael Norwitz wrote: > On Mon, Mar 15, 2021 at 10:29:50AM -0600, Alex Williamson wrote: > > On Mon, 15 Mar 2021 21:03:41 +0530 > > Amey Narkhede wrote: > > > > > On 21/03/15 05:07PM, Leon Romanovsky wrote: > > > > On Mon, Mar 15, 2021 at 08:34:09AM -0600, Alex Williamson wrote: > > > > > On Mon, 15 Mar 2021 14:52:26 +0100 > > > > > Pali Rohár wrote: > > > > > > > > > > > On Monday 15 March 2021 19:13:23 Amey Narkhede wrote: > > > > > > > slot reset (pci_dev_reset_slot_function) and secondary bus > > > > > > > reset(pci_parent_bus_reset) which I think are hot reset and > > > > > > > warm reset respectively. > > > > > > > > > > > > No. PCI secondary bus reset = PCIe Hot Reset. Slot reset is just > > > > > > another > > > > > > type of reset, which is currently implemented only for PCIe hot plug > > > > > > bridges and for PowerPC PowerNV platform and it just call PCI > > > > > > secondary > > > > > > bus reset with some other hook. PCIe Warm Reset does not have API in > > > > > > kernel and therefore drivers do not export this type of reset via > > > > > > any > > > > > > kernel function (yet). > > > > > > > > > > Warm reset is beyond the scope of this series, but could be > > > > > implemented > > > > > in a compatible way to fit within the pci_reset_fn_methods[] array > > > > > defined here. Note that with this series the resets available through > > > > > pci_reset_function() and the per device reset attribute is sysfs > > > > > remain > > > > > exactly the same as they are currently. The bus and slot reset > > > > > methods used here are limited to devices where only a single function > > > > > is > > > > > affected by the reset, therefore it is not like the patch you proposed > > > > > which performed a reset irrespective of the downstream devices. This > > > > > series only enables selection of the existing methods. Thanks, > > > > > > > > Alex, > > > > > > > > I asked the patch author here [1], but didn't get any response, maybe > > > > you can answer me. What is the use case scenario for this functionality? > > > > > > > > Thanks > > > > > > > > [1] https://lore.kernel.org/lkml/YE389lAqjJSeTolM@unreal/ > > > > > > > Sorry for not responding immediately. There were some buggy wifi cards > > > which needed FLR explicitly not sure if that behavior is fixed in > > > drivers. Also there is use a case at Nutanix but the engineer who > > > is involved is on PTO that is why I did not respond immediately as > > > I don't know the details yet. > > > > And more generally, devices continue to have reset issues and we > > impose a fixed priority in our ordering. We can and probably should > > continue to quirk devices when we find broken resets so that we have > > the best default behavior, but it's currently not easy for an end user > > to experiment, ie. this reset works, that one doesn't. We might also > > have platform issues where a given reset works better on a certain > > platform. Exposing a way to test these things might lead to better > > quirks. In the case I think Pali was looking for, they wanted a > > mechanism to force a bus reset, if this was in reference to a single > > function device, this could be accomplished by setting a priority for > > that mechanism, which would translate to not only the sysfs reset > > attribute, but also the reset mechanism used by vfio-pci. Thanks, > > > > Alex > > > > To confirm from our end - we have seen many such instances where default > reset methods have not worked well on our platform. Debugging these > issues is painful in practice, and this interface would make it far > easier. > > Having an interface like this would also help us better communicate the > issues we find with upstream. Allowing others to more easily test our > (or other entities') findings should give better visibility into > which issues apply to the device in general and which are platform > specific. In disambiguating the former from the latter, we should be > able to better quirk devices for everyone, and in the latter cases, this > interface allows for a safer and more elegant solution than any of the > current alternatives. So to summarize, we are talking about test and debug interface to overcome HW bugs, am I right? My personal experience shows that once the easy workaround exists (and write to generally available sysfs is very simple), the vendors and users desire for proper fix decreases drastically. IMHO, we will see increase of copy/paste in SO and blog posts, but reduce in quirks. My 2-cents. > > CC Alay, Suresh, Shyam and Felipe in case they have anything to add.
Re: [PATCH v1 1/3] dt-bindings: crypto: ti,sa2ul: Add new compatible for AM64
On Tue, Mar 16, 2021 at 04:05:58PM -0600, Rob Herring wrote: > On Tue, Mar 09, 2021 at 01:50:03AM +0530, Vaibhav Gupta wrote: > > From: Peter Ujfalusi > > > > Add the AM64 version of sa2ul to the compatible list. > > > > [v_gu...@ti.com: Conditional dma-coherent requirement, clocks] > > Signed-off-by: Peter Ujfalusi > > Signed-off-by: Vaibhav Gupta > > --- > > .../devicetree/bindings/crypto/ti,sa2ul.yaml | 40 +++ > > 1 file changed, 33 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml > > b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml > > index 1d48ac712b23..6eb9acd564c2 100644 > > --- a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml > > +++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml > > @@ -14,6 +14,7 @@ properties: > > enum: > >- ti,j721e-sa2ul > >- ti,am654-sa2ul > > + - ti,am64-sa2ul > > > >reg: > > maxItems: 1 > > @@ -45,19 +46,44 @@ properties: > > description: > >Address translation for the possible RNG child node for SA2UL > > > > + clocks: > > +items: > > + - description: Clock used by PKA > > + - description: Main Input Clock > > + - description: Clock used by rng > > + > > + clock-names: > > +items: > > + - const: pka_in_clk > > + - const: x1_clk > > + - const: x2_clk > > + > > patternProperties: > >"^rng@[a-f0-9]+$": > > type: object > > description: > >Child RNG node for SA2UL > > > > -required: > > - - compatible > > - - reg > > - - power-domains > > - - dmas > > - - dma-names > > - - dma-coherent > > +if: > > + properties: > > +compatible: > > + const: ti,am64-sa2ul > > +then: > > + required: > > +- compatible > > +- reg > > +- power-domains > > +- dmas > > +- dma-names > > + > > +else: > > + required: > > +- compatible > > +- reg > > +- power-domains > > +- dmas > > +- dma-names > > +- dma-coherent > > The only difference is 'dma-coherent'. You can simplify the if/then to > just that. Hello Rob, I agree with your point. But with that case we will have to modify/append the 'required' list. Something like: if !(properties.compatible == 'ti,am64-sa2ul') required += dma-coherent I even tried to use anchors but that didn't help. I didn't find it even in examples. Any hint how to achieve that? Thanks, Vaibhav
[PATCH] kernel: locking: Mundane typo fix in the file rwsem.c
s/folowing/following/ Signed-off-by: Bhaskar Chowdhury --- kernel/locking/rwsem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c index abba5df50006..fe9cc65cd522 100644 --- a/kernel/locking/rwsem.c +++ b/kernel/locking/rwsem.c @@ -632,7 +632,7 @@ static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem) } /* - * The rwsem_spin_on_owner() function returns the folowing 4 values + * The rwsem_spin_on_owner() function returns the following 4 values * depending on the lock owner state. * OWNER_NULL : owner is currently NULL * OWNER_WRITER: when owner changes and is a writer -- 2.30.2
Re: [PATCH] Insert SFENCE.VMA in function set_pte_at for RISCV
On Tue, 09 Mar 2021 22:22:46 PST (-0800), l...@jiuyang.me wrote:
From: Jiuyang Liu
This patch inserts SFENCE.VMA after modifying PTE based on RISC-V
specification.
arch/riscv/include/asm/pgtable.h:
1. implement pte_user, pte_global and pte_leaf to check correspond
attribute of a pte_t.
2. insert SFENCE.VMA in set_pte_at based on RISC-V Volume 2, Privileged
Spec v. 20190608 page 66 and 67:
If software modifies a non-leaf PTE, it should execute SFENCE.VMA with
rs1=x0. If any PTE along the traversal path had its G bit set, rs2 must
be x0; otherwise, rs2 should be set to the ASID for which the
translation is being modified.
If software modifies a leaf PTE, it should execute SFENCE.VMA with rs1
set to a virtual address within the page. If any PTE along the traversal
path had its G bit set, rs2 must be x0; otherwise, rs2 should be set to
the ASID for which the translation is being modified.
arch/riscv/include/asm/tlbflush.h:
1. implement local_flush_tlb_asid to flush tlb with asid.
Signed-off-by: Jiuyang Liu
---
arch/riscv/include/asm/pgtable.h | 28
arch/riscv/include/asm/tlbflush.h | 8
2 files changed, 36 insertions(+)
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index ebf817c1bdf4..95f6546ddb5b 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -222,6 +222,16 @@ static inline int pte_write(pte_t pte)
return pte_val(pte) & _PAGE_WRITE;
}
+static inline int pte_user(pte_t pte)
+{
+ return pte_val(pte) & _PAGE_USER;
+}
+
+static inline int pte_global(pte_t pte)
+{
+ return pte_val(pte) & _PAGE_GLOBAL;
+}
+
static inline int pte_exec(pte_t pte)
{
return pte_val(pte) & _PAGE_EXEC;
@@ -248,6 +258,11 @@ static inline int pte_special(pte_t pte)
return pte_val(pte) & _PAGE_SPECIAL;
}
+static inline int pte_leaf(pte_t pte)
+{
+ return pte_val(pte) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC);
+}
+
/* static inline pte_t pte_rdprotect(pte_t pte) */
static inline pte_t pte_wrprotect(pte_t pte)
@@ -358,6 +370,18 @@ static inline void set_pte_at(struct mm_struct *mm,
flush_icache_pte(pteval);
set_pte(ptep, pteval);
+
+ if (pte_present(pteval)) {
+ if (pte_leaf(pteval)) {
+ local_flush_tlb_page(addr);
+ } else {
+ if (pte_global(pteval))
+ local_flush_tlb_all();
+ else
+ local_flush_tlb_asid();
+
+ }
+ }
}
static inline void pte_clear(struct mm_struct *mm,
diff --git a/arch/riscv/include/asm/tlbflush.h
b/arch/riscv/include/asm/tlbflush.h
index 394cfbccdcd9..4b25f51f163d 100644
--- a/arch/riscv/include/asm/tlbflush.h
+++ b/arch/riscv/include/asm/tlbflush.h
@@ -21,6 +21,14 @@ static inline void local_flush_tlb_page(unsigned long addr)
{
__asm__ __volatile__ ("sfence.vma %0" : : "r" (addr) : "memory");
}
+
+static unsigned long asid;
+static inline void local_flush_tlb_asid(void)
+{
+ asid = csr_read(CSR_SATP) | (SATP_ASID_MASK << SATP_ASID_SHIFT);
+ __asm__ __volatile__ ("sfence.vma x0, %0" : : "r" (asid) : "memory");
+}
+
#else /* CONFIG_MMU */
#define local_flush_tlb_all() do { } while (0)
#define local_flush_tlb_page(addr) do { } while (0)
We're trying to avoid this sort of thing, instead relying on the generic kernel
functionality to batch up page table modifications before we issue the fences.
If you're seeing some specific issue then I'd be happy to try and sort out a
fix for it, but this is a bit heavy-handed to use as anything but a last
resort.
Re: [PATCH v2 1/1] PCI: pciehp: Skip DLLSC handling if DPC is triggered
On Fri, Mar 12, 2021 at 07:32:08PM -0800,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> + if ((events == PCI_EXP_SLTSTA_DLLSC) && is_dpc_reset_active(pdev)) {
> + ctrl_info(ctrl, "Slot(%s): DLLSC event(DPC), skipped\n",
> + slot_name(ctrl));
> + ret = IRQ_HANDLED;
> + goto out;
> + }
Two problems here:
(1) If recovery fails, the link will *remain* down, so there'll be
no Link Up event. You've filtered the Link Down event, thus the
slot will remain in ON_STATE even though the device in the slot is
no longer accessible. That's not good, the slot should be brought
down in this case.
(2) If recovery succeeds, there's a race where pciehp may call
is_dpc_reset_active() *after* dpc_reset_link() has finished.
So both the DPC Trigger Status bit as well as pdev->dpc_reset_active
will be cleared. Thus, the Link Up event is not filtered by pciehp
and the slot is brought down and back up even though DPC recovery
was succesful, which seems undesirable.
The only viable solution I see is to wait until DPC has completed.
Sinan (+cc) proposed something along those lines a couple years back:
https://patchwork.ozlabs.org/project/linux-pci/patch/20180818065126.77912-1-ok...@kernel.org/
Included below please find my suggestion for how to fix this.
I've sort of combined yours and Sinan's approach, but I'm
using a waitqueue (Sinan used polling) and I'm using atomic bitops
on pdev->priv_flags (you're using an atomic_t instead, which needs
additionally space in struct pci_dev). Note: It's compile-tested
only, I don't have any DPC-capable hardware at my disposal.
Would this work for you? If so, I can add a commit message to the
patch and submit it properly. Let me know what you think. Thanks!
-- >8 --
Subject: [PATCH] PCI: pciehp: Ignore Link Down/Up caused by DPC
Signed-off-by: Lukas Wunner
---
drivers/pci/hotplug/pciehp_hpc.c | 11 +
drivers/pci/pci.h| 4
drivers/pci/pcie/dpc.c | 51 ++--
3 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index fb3840e..bcc018e 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -707,6 +707,17 @@ static irqreturn_t pciehp_ist(int irq, void *dev_id)
}
/*
+* Ignore Link Down/Up caused by Downstream Port Containment
+* if recovery from the error succeeded.
+*/
+ if ((events & PCI_EXP_SLTSTA_DLLSC) && pci_dpc_recovered(pdev) &&
+ ctrl->state == ON_STATE) {
+ atomic_and(~PCI_EXP_SLTSTA_DLLSC, >pending_events);
+ if (pciehp_check_link_active(ctrl) > 0)
+ events &= ~PCI_EXP_SLTSTA_DLLSC;
+ }
+
+ /*
* Disable requests have higher priority than Presence Detect Changed
* or Data Link Layer State Changed events.
*/
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 9684b46..e5ae5e8 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -392,6 +392,8 @@ static inline bool pci_dev_is_disconnected(const struct
pci_dev *dev)
/* pci_dev priv_flags */
#define PCI_DEV_ADDED 0
+#define PCI_DPC_RECOVERED 1
+#define PCI_DPC_RECOVERING 2
static inline void pci_dev_assign_added(struct pci_dev *dev, bool added)
{
@@ -446,10 +448,12 @@ struct rcec_ea {
void pci_dpc_init(struct pci_dev *pdev);
void dpc_process_error(struct pci_dev *pdev);
pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
+bool pci_dpc_recovered(struct pci_dev *pdev);
#else
static inline void pci_save_dpc_state(struct pci_dev *dev) {}
static inline void pci_restore_dpc_state(struct pci_dev *dev) {}
static inline void pci_dpc_init(struct pci_dev *pdev) {}
+static inline bool pci_dpc_recovered(struct pci_dev *pdev) { return false; }
#endif
#ifdef CONFIG_PCIEPORTBUS
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index e05aba8..7328d9c4 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -71,6 +71,44 @@ void pci_restore_dpc_state(struct pci_dev *dev)
pci_write_config_word(dev, dev->dpc_cap + PCI_EXP_DPC_CTL, *cap);
}
+static bool dpc_completed(struct pci_dev *pdev)
+{
+ u16 status;
+
+ pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_STATUS, );
+ if (status & PCI_EXP_DPC_STATUS_TRIGGER)
+ return false;
+
+ if (test_bit(PCI_DPC_RECOVERING, >priv_flags))
+ return false;
+
+ return true;
+}
+
+static DECLARE_WAIT_QUEUE_HEAD(dpc_completed_waitqueue);
+
+bool pci_dpc_recovered(struct pci_dev *pdev)
+{
+ struct pci_host_bridge *host;
+
+ if (!pdev->dpc_cap)
+ return false;
+
+ /*
+* If DPC is owned by firmware and EDR is not supported, there is
+* no race between hotplug and DPC recovery handler. So return
+* false.
arch/x86/include/asm/syscall_wrapper.h:40:2: warning: no previous prototype for '__ia32_compat_sys_io_setup'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1df27313f50a57497c1faeb6a6ae4ca939c85a7d commit: 6cc8d2b286d9e7168d72e342d1b031317cd7752b x86/entry: Refactor COND_SYSCALL macros date: 12 months ago config: x86_64-randconfig-r012-20210316 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6cc8d2b286d9e7168d72e342d1b031317cd7752b git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 6cc8d2b286d9e7168d72e342d1b031317cd7752b # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from kernel/sys_ni.c:10: arch/x86/include/asm/syscall_wrapper.h:40:2: warning: no previous prototype for '__x64_sys_io_setup' [-Wmissing-prototypes] 40 | __##abi##_##name(const struct pt_regs *__unused) \ | ^~ arch/x86/include/asm/syscall_wrapper.h:54:2: note: in expansion of macro '__COND_SYSCALL' 54 | __COND_SYSCALL(x64, sys_##name) | ^~ arch/x86/include/asm/syscall_wrapper.h:231:2: note: in expansion of macro '__X64_COND_SYSCALL' 231 | __X64_COND_SYSCALL(name) \ | ^~ kernel/sys_ni.c:39:1: note: in expansion of macro 'COND_SYSCALL' 39 | COND_SYSCALL(io_setup); | ^~~~ arch/x86/include/asm/syscall_wrapper.h:40:2: warning: no previous prototype for '__ia32_sys_io_setup' [-Wmissing-prototypes] 40 | __##abi##_##name(const struct pt_regs *__unused) \ | ^~ arch/x86/include/asm/syscall_wrapper.h:88:2: note: in expansion of macro '__COND_SYSCALL' 88 | __COND_SYSCALL(ia32, sys_##name) | ^~ arch/x86/include/asm/syscall_wrapper.h:232:2: note: in expansion of macro '__IA32_COND_SYSCALL' 232 | __IA32_COND_SYSCALL(name) | ^~~ kernel/sys_ni.c:39:1: note: in expansion of macro 'COND_SYSCALL' 39 | COND_SYSCALL(io_setup); | ^~~~ >> arch/x86/include/asm/syscall_wrapper.h:40:2: warning: no previous prototype >> for '__ia32_compat_sys_io_setup' [-Wmissing-prototypes] 40 | __##abi##_##name(const struct pt_regs *__unused) \ | ^~ arch/x86/include/asm/syscall_wrapper.h:78:2: note: in expansion of macro '__COND_SYSCALL' 78 | __COND_SYSCALL(ia32, compat_sys_##name) | ^~ arch/x86/include/asm/syscall_wrapper.h:157:2: note: in expansion of macro '__IA32_COMPAT_COND_SYSCALL' 157 | __IA32_COMPAT_COND_SYSCALL(name)\ | ^~ kernel/sys_ni.c:40:1: note: in expansion of macro 'COND_SYSCALL_COMPAT' 40 | COND_SYSCALL_COMPAT(io_setup); | ^~~ arch/x86/include/asm/syscall_wrapper.h:40:2: warning: no previous prototype for '__x64_sys_io_destroy' [-Wmissing-prototypes] 40 | __##abi##_##name(const struct pt_regs *__unused) \ | ^~ arch/x86/include/asm/syscall_wrapper.h:54:2: note: in expansion of macro '__COND_SYSCALL' 54 | __COND_SYSCALL(x64, sys_##name) | ^~ arch/x86/include/asm/syscall_wrapper.h:231:2: note: in expansion of macro '__X64_COND_SYSCALL' 231 | __X64_COND_SYSCALL(name) \ | ^~ kernel/sys_ni.c:41:1: note: in expansion of macro 'COND_SYSCALL' 41 | COND_SYSCALL(io_destroy); | ^~~~ arch/x86/include/asm/syscall_wrapper.h:40:2: warning: no previous prototype for '__ia32_sys_io_destroy' [-Wmissing-prototypes] 40 | __##abi##_##name(const struct pt_regs *__unused) \ | ^~ arch/x86/include/asm/syscall_wrapper.h:88:2: note: in expansion of macro '__COND_SYSCALL' 88 | __COND_SYSCALL(ia32, sys_##name) | ^~ arch/x86/include/asm/syscall_wrapper.h:232:2: note: in expansion of macro '__IA32_COND_SYSCALL' 232 | __IA32_COND_SYSCALL(name) | ^~~ kernel/sys_ni.c:41:1: note: in expansion of macro 'COND_SYSCALL' 41 | COND_SYSCALL(io_destroy); | ^~~~ arch/x86/include/asm/syscall_wrapper.h:40:2: warning: no previous prototype for '__x64_sys_io_submit' [-Wmissing-prototypes] 40 | __##abi##_##name(const struct pt_regs *__unused) \ | ^~ arch/x86/include/asm/syscall_wrapper.h:54:2: note: in expansion of macro '__COND_SYSCALL' 54 | __COND_SYSCALL(x64, sys_##name) | ^~ arch/x86/include/asm/syscall_wrapper.h:231:2: note: in expansion of macro '__X64_COND_SYSCALL' 231 | __X64_COND_SYSCALL(name) \ | ^~ kernel/sys_ni.c:42:1:
linux-next: build failure after merge of the tip tree
Hi all, After merging the tip tree, today's linux-next build (native perf) failed like this: In file included from util/intel-pt-decoder/intel-pt-insn-decoder.c:15: util/intel-pt-decoder/../../../arch/x86/lib/insn.c:14:10: fatal error: asm/inat.h: No such file or directory 14 | #include /*__ignore_sync_check__ */ | ^~~~ This is a powerpc build of perf. I can't see what caused this failure, so I have used the version of the tip tree from next-20210316 for today. -- Cheers, Stephen Rothwell pgpoZ3HRf6zCW.pgp Description: OpenPGP digital signature
Re: [PATCH V4 7/7] vDPA/ifcvf: deduce VIRTIO device ID from pdev ids
在 2021/3/15 下午3:45, Zhu Lingshan 写道:
static u32 ifcvf_vdpa_get_device_id(struct vdpa_device *vdpa_dev)
{
- return VIRTIO_ID_NET;
+ struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
+ u32 ret = -EOPNOTSUPP;
+
+ if (ifcvf_probed_virtio_net(vf))
+ ret = VIRTIO_ID_NET;
So the point is to simplify the future extension.
How about simply?
if (device_id>0x1040)
return devce_id - 0x1040;
else
return device_id;
Since I don't think you plan to introduce device whose vendor id is not
1AF4 and the subsys vendor/device id is not interesting to vDPA bus.
Thanks
+
+ return ret;
}
Re: [PATCH][next] scsi: mpt3sas: Replace unnecessary dynamic allocation with a static one
Hi Martin, On 3/16/21 22:32, Martin K. Petersen wrote: > > Gustavo, > >> Dynamic memory allocation isn't actually needed and it can be replaced >> by statically allocating memory for struct object io_unit_pg3 with 36 >> hardcoded entries for its GPIOVal array. > > Applied to 5.13/scsi-staging, thanks! Awesome. :) I wonder if you can take a look at this one, too, please: https://lore.kernel.org/lkml/20210304203822.GA102218@embeddedor/ Thanks! -- Gustavo
[PATCH net-next 1/1] net: stmmac: add timestamp correction to rid CDC sync error
From: Voon Weifeng
According to Synopsis DesignWare EQoS Databook, the Clock Domain Cross
synchronization error is introduced tue to the clock(GMII Tx/Rx clock)
being different at the capture as compared to the PTP
clock(clk_ptp_ref_i) that is used to generate the time.
The CDC synchronization error is almost equal to 2 times the clock
period of the PTP clock(clk_ptp_ref_i).
On a Intel Tigerlake platform (with Marvell 88E2110 external PHY):
Before applying this patch (with CDC synchronization error):
ptp4l[64.044]: rms8 max 13 freq +30877 +/- 11 delay 216 +/- 0
ptp4l[65.047]: rms 13 max 20 freq +30869 +/- 17 delay 213 +/- 0
ptp4l[66.050]: rms 12 max 20 freq +30857 +/- 11 delay 213 +/- 0
ptp4l[67.052]: rms 11 max 22 freq +30849 +/- 10 delay 215 +/- 0
ptp4l[68.055]: rms 10 max 16 freq +30853 +/- 13 delay 215 +/- 0
ptp4l[69.057]: rms7 max 13 freq +30848 +/- 9 delay 216 +/- 0
ptp4l[70.060]: rms8 max 13 freq +30846 +/- 10 delay 216 +/- 0
ptp4l[71.063]: rms9 max 15 freq +30836 +/- 8 delay 218 +/- 0
After applying this patch (CDC syncrhonization error is taken care of):
ptp4l[61.516]: rms 773 max 824 freq +31526 +/- 158 delay 200 +/- 0
ptp4l[62.519]: rms 427 max 596 freq +31668 +/- 39 delay 198 +/- 0
ptp4l[63.522]: rms 113 max 206 freq +31482 +/- 57 delay 198 +/- 0
ptp4l[64.525]: rms 40 max 56 freq +31316 +/- 29 delay 200 +/- 0
ptp4l[65.528]: rms 47 max 56 freq +31255 +/- 17 delay 200 +/- 0
ptp4l[66.531]: rms 26 max 36 freq +31246 +/- 9 delay 200 +/- 0
ptp4l[67.534]: rms 12 max 18 freq +31254 +/- 12 delay 202 +/- 0
ptp4l[68.537]: rms7 max 12 freq +31263 +/- 10 delay 202 +/- 0
Signed-off-by: Voon Weifeng
Signed-off-by: Wong Vee Khee
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c| 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a10704d8e3c6..ddf54b8ad75d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -466,6 +466,7 @@ static void stmmac_get_tx_hwtstamp(struct stmmac_priv *priv,
{
struct skb_shared_hwtstamps shhwtstamp;
bool found = false;
+ s64 adjust = 0;
u64 ns = 0;
if (!priv->hwts_tx_en)
@@ -484,6 +485,13 @@ static void stmmac_get_tx_hwtstamp(struct stmmac_priv
*priv,
}
if (found) {
+ /* Correct the clk domain crossing(CDC) error */
+ if (priv->plat->has_gmac4 && priv->plat->clk_ptp_rate) {
+ adjust += -(2 * (NSEC_PER_SEC /
+priv->plat->clk_ptp_rate));
+ ns += adjust;
+ }
+
memset(, 0, sizeof(struct skb_shared_hwtstamps));
shhwtstamp.hwtstamp = ns_to_ktime(ns);
@@ -507,6 +515,7 @@ static void stmmac_get_rx_hwtstamp(struct stmmac_priv
*priv, struct dma_desc *p,
{
struct skb_shared_hwtstamps *shhwtstamp = NULL;
struct dma_desc *desc = p;
+ u64 adjust = 0;
u64 ns = 0;
if (!priv->hwts_rx_en)
@@ -518,6 +527,13 @@ static void stmmac_get_rx_hwtstamp(struct stmmac_priv
*priv, struct dma_desc *p,
/* Check if timestamp is available */
if (stmmac_get_rx_timestamp_status(priv, p, np, priv->adv_ts)) {
stmmac_get_timestamp(priv, desc, priv->adv_ts, );
+
+ /* Correct the clk domain crossing(CDC) error */
+ if (priv->plat->has_gmac4 && priv->plat->clk_ptp_rate) {
+ adjust += 2 * (NSEC_PER_SEC / priv->plat->clk_ptp_rate);
+ ns -= adjust;
+ }
+
netdev_dbg(priv->dev, "get valid RX hw timestamp %llu\n", ns);
shhwtstamp = skb_hwtstamps(skb);
memset(shhwtstamp, 0, sizeof(struct skb_shared_hwtstamps));
--
2.25.1
Re: [PATCH v5] RISC-V: enable XIP
On Wed, 10 Mar 2021 01:22:35 PST (-0800), vitaly.w...@konsulko.com wrote: Introduce XIP (eXecute In Place) support for RISC-V platforms. It allows code to be executed directly from non-volatile storage directly addressable by the CPU, such as QSPI NOR flash which can be found on many RISC-V platforms. This makes way for significant optimization of RAM footprint. The XIP kernel is not compressed since it has to run directly from flash, so it will occupy more space on the non-volatile storage to The physical flash address used to link the kernel object files and for storing it has to be known at compile time and is represented by a Kconfig option. XIP on RISC-V will currently only work on MMU-enabled kernels. Signed-off-by: Vitaly Wool --- Changes in v2: - dedicated macro for XIP address fixup when MMU is not enabled yet o both for 32-bit and 64-bit RISC-V - SP is explicitly set to a safe place in RAM before __copy_data call - removed redundant alignment requirements in vmlinux-xip.lds.S - changed long -> uintptr_t typecast in __XIP_FIXUP macro. Changes in v3: - rebased against latest for-next - XIP address fixup macro now takes an argument - SMP related fixes Changes in v4: - rebased against the current for-next - less #ifdef's in C/ASM code - dedicated XIP_FIXUP_OFFSET assembler macro in head.S - C-specific definitions moved into #ifndef __ASSEMBLY__ - Fixed multi-core boot Changes in v5: - fixed build error for non-XIP kernels arch/riscv/Kconfig | 44 +- arch/riscv/Makefile | 8 +- arch/riscv/boot/Makefile| 13 +++ arch/riscv/include/asm/pgtable.h| 65 -- arch/riscv/kernel/cpu_ops_sbi.c | 12 ++- arch/riscv/kernel/head.S| 59 - arch/riscv/kernel/head.h| 3 + arch/riscv/kernel/setup.c | 8 +- arch/riscv/kernel/vmlinux-xip.lds.S | 132 arch/riscv/kernel/vmlinux.lds.S | 6 ++ arch/riscv/mm/init.c| 100 +++-- 11 files changed, 432 insertions(+), 18 deletions(-) create mode 100644 arch/riscv/kernel/vmlinux-xip.lds.S diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 85d626b8ce5e..59fb945a900e 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -438,7 +438,7 @@ config EFI_STUB config EFI bool "UEFI runtime support" - depends on OF + depends on OF && !XIP_KERNEL select LIBFDT select UCS2_STRING select EFI_PARAMS_FROM_FDT @@ -462,11 +462,51 @@ config STACKPROTECTOR_PER_TASK def_bool y depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS +config XIP_KERNEL + bool "Kernel Execute-In-Place from ROM" + depends on MMU + help + Execute-In-Place allows the kernel to run from non-volatile storage + directly addressable by the CPU, such as NOR flash. This saves RAM + space since the text section of the kernel is not loaded from flash + to RAM. Read-write sections, such as the data section and stack, + are still copied to RAM. The XIP kernel is not compressed since + it has to run directly from flash, so it will take more space to + store it. The flash address used to link the kernel object files, + and for storing it, is configuration dependent. Therefore, if you + say Y here, you must know the proper physical address where to + store the kernel image depending on your own flash memory usage. + + Also note that the make target becomes "make xipImage" rather than + "make zImage" or "make Image". The final kernel binary to put in + ROM memory will be arch/riscv/boot/xipImage. + + If unsure, say N. + +config XIP_PHYS_ADDR + hex "XIP Kernel Physical Location" + depends on XIP_KERNEL + default "0x2100" + help + This is the physical address in your flash memory the kernel will + be linked for and stored to. This address is dependent on your + own flash usage. + +config XIP_PHYS_RAM_BASE + hex "Platform Physical RAM address" + depends on XIP_KERNEL + default "0x8000" + help + This is the physical address of RAM in the system. It has to be + explicitly specified to run early relocations of read-write data + from flash to RAM. + endmenu config BUILTIN_DTB - def_bool n + bool depends on OF + default y if XIP_KERNEL menu "Power management options" diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 1368d943f1f3..8fcbec03974d 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -82,7 +82,11 @@ CHECKFLAGS += -D__riscv -D__riscv_xlen=$(BITS) # Default target when executing plain make boot := arch/riscv/boot +ifeq ($(CONFIG_XIP_KERNEL),y) +KBUILD_IMAGE := $(boot)/xipImage +else KBUILD_IMAGE := $(boot)/Image.gz +endif head-y :=
[PATCH v3 3/3] hwmon: (pmbus): Add driver for BluTek BPA-RS600
The BPA-RS600 is a compact 600W AC to DC removable power supply module. Signed-off-by: Chris Packham --- Notes: Changes in v3: - Fix typo BPD -> BPA - Allow for NUL terminator in buf Changes in v2: - Whitespace and line length cleanup - Add comments about commands that return data but shouldn't be used Documentation/hwmon/bpa-rs600.rst | 74 + drivers/hwmon/pmbus/Kconfig | 9 ++ drivers/hwmon/pmbus/Makefile | 1 + drivers/hwmon/pmbus/bpa-rs600.c | 172 ++ 4 files changed, 256 insertions(+) create mode 100644 Documentation/hwmon/bpa-rs600.rst create mode 100644 drivers/hwmon/pmbus/bpa-rs600.c diff --git a/Documentation/hwmon/bpa-rs600.rst b/Documentation/hwmon/bpa-rs600.rst new file mode 100644 index ..28313995d4ae --- /dev/null +++ b/Documentation/hwmon/bpa-rs600.rst @@ -0,0 +1,74 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver bpa-rs600 +=== + +Supported chips: + + * BPA-RS600-120 + +Datasheet: Publicly available at the BluTek website + http://blutekpower.com/wp-content/uploads/2019/01/BPA-RS600-120-07-19-2018.pdf + +Authors: + - Chris Packham + +Description +--- + +The BPA-RS600 is a compact 600W removable power supply module. + +Usage Notes +--- + +This driver does not probe for PMBus devices. You will have to instantiate +devices explicitly. + +Sysfs attributes + + +=== +curr1_label "iin" +curr1_inputMeasured input current +curr1_max Maximum input current +curr1_max_alarmInput current high alarm + +curr2_label"iout1" +curr2_inputMeasured output current +curr2_max Maximum output current +curr2_max_alarmOutput current high alarm + +fan1_input Measured fan speed +fan1_alarm Fan warning +fan1_fault Fan fault + +in1_label "vin" +in1_input Measured input voltage +in1_maxMaximum input voltage +in1_max_alarm Input voltage high alarm +in1_minMinimum input voltage +in1_min_alarm Input voltage low alarm + +in2_label "vout1" +in2_input Measured output voltage +in2_maxMaximum output voltage +in2_max_alarm Output voltage high alarm +in2_minMaximum output voltage +in2_min_alarm Output voltage low alarm + +power1_label "pin" +power1_input Measured input power +power1_alarm Input power alarm +power1_max Maximum input power + +power2_label "pout1" +power2_input Measured output power +power2_max Maximum output power +power2_max_alarm Output power high alarm + +temp1_inputMeasured temperature around input connector +temp1_alarmTemperature alarm + +temp2_inputMeasured temperature around output connector +temp2_alarmTemperature alarm +=== diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig index 32d2fc850621..512d6f656dca 100644 --- a/drivers/hwmon/pmbus/Kconfig +++ b/drivers/hwmon/pmbus/Kconfig @@ -56,6 +56,15 @@ config SENSORS_BEL_PFE This driver can also be built as a module. If so, the module will be called bel-pfe. +config SENSORS_BPA_RS600 + tristate "BluTek BPA-RS600 Power Supplies" + help + If you say yes here you get hardware monitoring support for BluTek + BPA-RS600 Power Supplies. + + This driver can also be built as a module. If so, the module will + be called bpa-rs600. + config SENSORS_IBM_CFFPS tristate "IBM Common Form Factor Power Supply" depends on LEDS_CLASS diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile index 6a4ba0fdc1db..80a437060dc4 100644 --- a/drivers/hwmon/pmbus/Makefile +++ b/drivers/hwmon/pmbus/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_SENSORS_PMBUS) += pmbus.o obj-$(CONFIG_SENSORS_ADM1266) += adm1266.o obj-$(CONFIG_SENSORS_ADM1275) += adm1275.o obj-$(CONFIG_SENSORS_BEL_PFE) += bel-pfe.o +obj-$(CONFIG_SENSORS_BPA_RS600)+= bpa-rs600.o obj-$(CONFIG_SENSORS_IBM_CFFPS)+= ibm-cffps.o obj-$(CONFIG_SENSORS_INSPUR_IPSPS) += inspur-ipsps.o obj-$(CONFIG_SENSORS_IR35221) += ir35221.o diff --git a/drivers/hwmon/pmbus/bpa-rs600.c b/drivers/hwmon/pmbus/bpa-rs600.c new file mode 100644 index ..c4ede68b3e26 --- /dev/null +++ b/drivers/hwmon/pmbus/bpa-rs600.c @@ -0,0 +1,172 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Hardware monitoring driver for BluTek BPA-RS600 Power Supplies + * + * Copyright 2021 Allied Telesis Labs + */ + +#include +#include +#include +#include +#include
[PATCH v3 1/3] dt-bindings: Add vendor prefix and trivial device for BluTek BPA-RS600
Add vendor prefix "blutek" for BluTek Power. Add trivial device entry for BPA-RS600. Signed-off-by: Chris Packham --- Notes: Changes in v3: - None Changes in v2: - None Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index a327130d1faa..569236e9bed0 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -50,6 +50,8 @@ properties: - atmel,atsha204a # i2c h/w elliptic curve crypto module - atmel,atecc508a +# BPA-RS600: Power Supply + - blutek,bpa-rs600 # Bosch Sensortec pressure, temperature, humididty and VOC sensor - bosch,bme680 # CM32181: Ambient Light Sensor diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index f6064d84a424..d9d7226f5dfe 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -169,6 +169,8 @@ patternProperties: description: Beckhoff Automation GmbH & Co. KG "^bitmain,.*": description: Bitmain Technologies + "^blutek,.*": +description: BluTek Power "^boe,.*": description: BOE Technology Group Co., Ltd. "^bosch,.*": -- 2.30.2
[PATCH v3 2/3] hwmon: (pmbus): Replace - with _ in device names before registration
The hwmon sysfs ABI requires that the `name` property doesn't include
any dashes. But when the pmbus code picks the name up from the device
tree it quite often does. Replace '-' with '_' before registering the
device.
Signed-off-by: Chris Packham
---
Notes:
Changes in v3:
- None
Changes in v2:
- New
drivers/hwmon/pmbus/pmbus_core.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index aadea85fe630..7d2f8f032314 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -2557,6 +2557,7 @@ int pmbus_do_probe(struct i2c_client *client, struct
pmbus_driver_info *info)
struct pmbus_data *data;
size_t groups_num = 0;
int ret;
+ char *name;
if (!info)
return -ENODEV;
@@ -2606,10 +2607,15 @@ int pmbus_do_probe(struct i2c_client *client, struct
pmbus_driver_info *info)
return -ENODEV;
}
+ name = devm_kstrdup(dev, client->name, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
+ strreplace(name, '-', '_');
+
data->groups[0] = >group;
memcpy(data->groups + 1, info->groups, sizeof(void *) * groups_num);
data->hwmon_dev = devm_hwmon_device_register_with_groups(dev,
- client->name, data, data->groups);
+ name, data, data->groups);
if (IS_ERR(data->hwmon_dev)) {
dev_err(dev, "Failed to register hwmon device\n");
return PTR_ERR(data->hwmon_dev);
--
2.30.2
Re: [PATCH] backlight: qcom-wled: Use sink_addr for sync toggle
On 2021-03-15 17:51, Daniel Thompson wrote: On Sun, Mar 14, 2021 at 11:11:10AM +0100, Marijn Suijten wrote: From: Obeida Shamoun WLED3_SINK_REG_SYNC is, as the name implies, a sink register offset. Therefore, use the sink address as base instead of the ctrl address. This fixes the sync toggle on wled4, which can be observed by the fact that adjusting brightness now works. It has no effect on wled3 because sink and ctrl base addresses are the same. This allows adjusting the brightness without having to disable then reenable the module. Signed-off-by: Obeida Shamoun Signed-off-by: Konrad Dybcio Signed-off-by: Marijn Suijten LGTM, although an acked-by from Kiran would be nice to have: Reviewed-by: Daniel Thompson Daniel. Acked-by: Kiran Gunda --- drivers/video/backlight/qcom-wled.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c index 091f07e7c145..fc8b443d10fd 100644 --- a/drivers/video/backlight/qcom-wled.c +++ b/drivers/video/backlight/qcom-wled.c @@ -336,13 +336,13 @@ static int wled3_sync_toggle(struct wled *wled) unsigned int mask = GENMASK(wled->max_string_count - 1, 0); rc = regmap_update_bits(wled->regmap, - wled->ctrl_addr + WLED3_SINK_REG_SYNC, + wled->sink_addr + WLED3_SINK_REG_SYNC, mask, mask); if (rc < 0) return rc; rc = regmap_update_bits(wled->regmap, - wled->ctrl_addr + WLED3_SINK_REG_SYNC, + wled->sink_addr + WLED3_SINK_REG_SYNC, mask, WLED3_SINK_REG_SYNC_CLEAR); return rc; -- 2.30.2
Re: [PATCH V4 6/7] vDPA/ifcvf: verify mandatory feature bits for vDPA
在 2021/3/15 下午3:45, Zhu Lingshan 写道:
vDPA requres VIRTIO_F_ACCESS_PLATFORM as a must, this commit
examines this when set features.
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_base.c | 12
drivers/vdpa/ifcvf/ifcvf_base.h | 1 +
drivers/vdpa/ifcvf/ifcvf_main.c | 5 +
3 files changed, 18 insertions(+)
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.c b/drivers/vdpa/ifcvf/ifcvf_base.c
index ea6a78791c9b..4f257c4b2f76 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.c
+++ b/drivers/vdpa/ifcvf/ifcvf_base.c
@@ -224,6 +224,18 @@ u64 ifcvf_get_features(struct ifcvf_hw *hw)
return hw->hw_features;
}
+int ifcvf_verify_min_features(struct ifcvf_hw *hw, u64 features)
+{
+ struct ifcvf_adapter *ifcvf = vf_to_adapter(hw);
+
+ if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)) && features) {
+ IFCVF_ERR(ifcvf->pdev, "VIRTIO_F_ACCESS_PLATFORM not
negotiated\n");
Should be "is not negotiated".
Otherwise:
Acked-by: Jason Wang
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
void ifcvf_read_net_config(struct ifcvf_hw *hw, u64 offset,
void *dst, int length)
{
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h b/drivers/vdpa/ifcvf/ifcvf_base.h
index dbb8c10aa3b1..f77239fc1644 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.h
+++ b/drivers/vdpa/ifcvf/ifcvf_base.h
@@ -123,6 +123,7 @@ void io_write64_twopart(u64 val, u32 *lo, u32 *hi);
void ifcvf_reset(struct ifcvf_hw *hw);
u64 ifcvf_get_features(struct ifcvf_hw *hw);
u64 ifcvf_get_hw_features(struct ifcvf_hw *hw);
+int ifcvf_verify_min_features(struct ifcvf_hw *hw, u64 features);
u16 ifcvf_get_vq_state(struct ifcvf_hw *hw, u16 qid);
int ifcvf_set_vq_state(struct ifcvf_hw *hw, u16 qid, u16 num);
struct ifcvf_adapter *vf_to_adapter(struct ifcvf_hw *hw);
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 25fb9dfe23f0..ea93ea7fd5df 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -179,6 +179,11 @@ static u64 ifcvf_vdpa_get_features(struct vdpa_device
*vdpa_dev)
static int ifcvf_vdpa_set_features(struct vdpa_device *vdpa_dev, u64 features)
{
struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
+ int ret;
+
+ ret = ifcvf_verify_min_features(vf, features);
+ if (ret)
+ return ret;
vf->req_features = features;
Re: [PATCH V4 5/7] vDPA/ifcvf: fetch device feature bits when probe
在 2021/3/15 下午3:44, Zhu Lingshan 写道:
This commit would read and store device feature
bits when probe.
rename ifcvf_get_features() to ifcvf_get_hw_features(),
it reads and stores features of the probed device.
new ifcvf_get_features() simply returns stored
feature bits.
Signed-off-by: Zhu Lingshan
Acked-by: Jason Wang
---
drivers/vdpa/ifcvf/ifcvf_base.c | 12 ++--
drivers/vdpa/ifcvf/ifcvf_base.h | 2 ++
drivers/vdpa/ifcvf/ifcvf_main.c | 2 ++
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.c b/drivers/vdpa/ifcvf/ifcvf_base.c
index f2a128e56de5..ea6a78791c9b 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.c
+++ b/drivers/vdpa/ifcvf/ifcvf_base.c
@@ -202,10 +202,11 @@ static void ifcvf_add_status(struct ifcvf_hw *hw, u8
status)
ifcvf_get_status(hw);
}
-u64 ifcvf_get_features(struct ifcvf_hw *hw)
+u64 ifcvf_get_hw_features(struct ifcvf_hw *hw)
{
struct virtio_pci_common_cfg __iomem *cfg = hw->common_cfg;
u32 features_lo, features_hi;
+ u64 features;
ifc_iowrite32(0, >device_feature_select);
features_lo = ifc_ioread32(>device_feature);
@@ -213,7 +214,14 @@ u64 ifcvf_get_features(struct ifcvf_hw *hw)
ifc_iowrite32(1, >device_feature_select);
features_hi = ifc_ioread32(>device_feature);
- return ((u64)features_hi << 32) | features_lo;
+ features = ((u64)features_hi << 32) | features_lo;
+
+ return features;
+}
+
+u64 ifcvf_get_features(struct ifcvf_hw *hw)
+{
+ return hw->hw_features;
}
void ifcvf_read_net_config(struct ifcvf_hw *hw, u64 offset,
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h b/drivers/vdpa/ifcvf/ifcvf_base.h
index 794d1505d857..dbb8c10aa3b1 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.h
+++ b/drivers/vdpa/ifcvf/ifcvf_base.h
@@ -83,6 +83,7 @@ struct ifcvf_hw {
void __iomem *notify_base;
u32 notify_off_multiplier;
u64 req_features;
+ u64 hw_features;
struct virtio_pci_common_cfg __iomem *common_cfg;
void __iomem *net_cfg;
struct vring_info vring[IFCVF_MAX_QUEUE_PAIRS * 2];
@@ -121,6 +122,7 @@ void ifcvf_set_status(struct ifcvf_hw *hw, u8 status);
void io_write64_twopart(u64 val, u32 *lo, u32 *hi);
void ifcvf_reset(struct ifcvf_hw *hw);
u64 ifcvf_get_features(struct ifcvf_hw *hw);
+u64 ifcvf_get_hw_features(struct ifcvf_hw *hw);
u16 ifcvf_get_vq_state(struct ifcvf_hw *hw, u16 qid);
int ifcvf_set_vq_state(struct ifcvf_hw *hw, u16 qid, u16 num);
struct ifcvf_adapter *vf_to_adapter(struct ifcvf_hw *hw);
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index c34e1eec6b6c..25fb9dfe23f0 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -458,6 +458,8 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
for (i = 0; i < IFCVF_MAX_QUEUE_PAIRS * 2; i++)
vf->vring[i].irq = -EINVAL;
+ vf->hw_features = ifcvf_get_hw_features(vf);
+
ret = vdpa_register_device(>vdpa);
if (ret) {
IFCVF_ERR(pdev, "Failed to register ifcvf to vdpa bus");
[PATCH v6 13/14] drm/bridge: imx: Add LDB support for i.MX8qm
This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB)
which is officially named as pixel mapper. The LDB has two channels.
Each of them supports up to 30bpp parallel input color format and can
map the input to VESA or JEIDA standards. The two channels can be used
simultaneously, either in dual mode or split mode. In dual mode, the
two channels output identical data. In split mode, channel0 outputs
odd pixels and channel1 outputs even pixels. This patch supports the
LDB single mode and split mode.
Signed-off-by: Liu Ying
---
Note that this patch depends on the patch 'phy: Add LVDS configuration options',
which has already been sent with the following series to add Mixel combo PHY
found in i.MX8qxp:
https://www.spinics.net/lists/arm-kernel/msg879957.html
v5->v6:
* No change.
v4->v5:
* Link with the imx-ldb-helper object. (Robert)
* Correspondingly, rename 'imx8qm-ldb.c' to 'imx8qm-ldb-drv.c'.
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* Drop unnecessary check for maximum available LDB channels.
* Mention i.MX8qm LDB official name 'pixel mapper' in the bridge driver
and Kconfig help message.
drivers/gpu/drm/bridge/imx/Kconfig | 9 +
drivers/gpu/drm/bridge/imx/Makefile | 3 +
drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 586
3 files changed, 598 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 94f8db4d..3a8683f 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -1,3 +1,12 @@
+config DRM_IMX8QM_LDB
+ tristate "Freescale i.MX8QM LVDS display bridge"
+ depends on OF
+ depends on COMMON_CLK
+ select DRM_KMS_HELPER
+ help
+ Choose this to enable the internal LVDS Display Bridge(LDB) found in
+ Freescale i.MX8qm processor. Official name of LDB is pixel mapper.
+
config DRM_IMX8QXP_LDB
tristate "Freescale i.MX8QXP LVDS display bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index 96d5d1e..aa90ec8 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,3 +1,6 @@
+imx8qm-ldb-objs := imx-ldb-helper.o imx8qm-ldb-drv.o
+obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
+
imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
new file mode 100644
index ..6c92636
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
@@ -0,0 +1,586 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "imx-ldb-helper.h"
+
+#define LDB_CH0_10BIT_EN (1 << 22)
+#define LDB_CH1_10BIT_EN (1 << 23)
+#define LDB_CH0_DATA_WIDTH_24BIT (1 << 24)
+#define LDB_CH1_DATA_WIDTH_24BIT (1 << 26)
+#define LDB_CH0_DATA_WIDTH_30BIT (2 << 24)
+#define LDB_CH1_DATA_WIDTH_30BIT (2 << 26)
+
+#define SS_CTRL0x20
+#define CH_HSYNC_M(id)BIT(0 + ((id) * 2))
+#define CH_VSYNC_M(id)BIT(1 + ((id) * 2))
+#define CH_PHSYNC(id) BIT(0 + ((id) * 2))
+#define CH_PVSYNC(id) BIT(1 + ((id) * 2))
+
+#define DRIVER_NAME"imx8qm-ldb"
+
+struct imx8qm_ldb_channel {
+ struct ldb_channel base;
+ struct phy *phy;
+};
+
+struct imx8qm_ldb {
+ struct ldb base;
+ struct device *dev;
+ struct imx8qm_ldb_channel channel[MAX_LDB_CHAN_NUM];
+ struct clk *clk_pixel;
+ struct clk *clk_bypass;
+ int active_chno;
+};
+
+static inline struct imx8qm_ldb_channel *
+base_to_imx8qm_ldb_channel(struct ldb_channel *base)
+{
+ return container_of(base, struct imx8qm_ldb_channel, base);
+}
+
+static inline struct imx8qm_ldb *base_to_imx8qm_ldb(struct ldb *base)
+{
+ return container_of(base, struct imx8qm_ldb, base);
+}
+
+static void imx8qm_ldb_set_phy_cfg(struct imx8qm_ldb *imx8qm_ldb,
+ unsigned long di_clk,
+ bool is_split, bool is_slave,
+ struct phy_configure_opts_lvds *phy_cfg)
+{
+ phy_cfg->bits_per_lane_and_dclk_cycle = 7;
+ phy_cfg->lanes = 4;
+ phy_cfg->differential_clk_rate = is_split ? di_clk / 2 : di_clk;
+ phy_cfg->is_slave = is_slave;
+}
+
+static int imx8qm_ldb_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state
[PATCH v6 14/14] MAINTAINERS: add maintainer for DRM bridge drivers for i.MX SoCs
Add myself as the maintainer of DRM bridge drivers for i.MX SoCs. Signed-off-by: Liu Ying --- v5->v6: * No change. v4->v5: * No change. v3->v4: * No change. v2->v3: * No change. v1->v2: * No change. MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4b705ba..488e0ef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5939,6 +5939,16 @@ F: Documentation/devicetree/bindings/display/imx/ F: drivers/gpu/drm/imx/ F: drivers/gpu/ipu-v3/ +DRM DRIVERS FOR FREESCALE IMX BRIDGE +M: Liu Ying +L: dri-de...@lists.freedesktop.org +S: Maintained +F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml +F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml +F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml +F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml +F: drivers/gpu/drm/bridge/imx/ + DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets) M: Patrik Jakobsson L: dri-de...@lists.freedesktop.org -- 2.7.4
[PATCH v6 12/14] drm/bridge: imx: Add LDB support for i.MX8qxp
This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
which is officially named as pixel mapper. The LDB has two channels.
Each of them supports up to 24bpp parallel input color format and can map
the input to VESA or JEIDA standards. The two channels cannot be used
simultaneously, that is to say, the user should pick one of them to use.
Two LDB channels from two LDB instances can work together in LDB split
mode to support a dual link LVDS display. The channel indexes have to be
different. Channel0 outputs odd pixels and channel1 outputs even pixels.
This patch supports the LDB single mode and split mode.
Signed-off-by: Liu Ying
---
Note that this patch depends on the patch 'phy: Add LVDS configuration options',
which has already been sent with the following series to add Mixel combo PHY
found in i.MX8qxp:
https://www.spinics.net/lists/arm-kernel/msg879957.html
v5->v6:
* No change.
v4->v5:
* Link with the imx-ldb-helper object. (Robert)
* Correspondingly, rename 'imx8qxp-ldb.c' to 'imx8qxp-ldb-drv.c'.
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* Drop unnecessary DT validation.
* Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
get the input remote endpoint in imx8qxp_ldb_set_di_id().
* Avoid using companion_port OF node after putting it in
imx8qxp_ldb_parse_dt_companion().
* Mention i.MX8qxp LDB official name 'pixel mapper' in the bridge driver
and Kconfig help message.
drivers/gpu/drm/bridge/imx/Kconfig | 9 +
drivers/gpu/drm/bridge/imx/Makefile | 3 +
drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 720 +++
3 files changed, 732 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 1ea1ce7..94f8db4d 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -1,3 +1,12 @@
+config DRM_IMX8QXP_LDB
+ tristate "Freescale i.MX8QXP LVDS display bridge"
+ depends on OF
+ depends on COMMON_CLK
+ select DRM_KMS_HELPER
+ help
+ Choose this to enable the internal LVDS Display Bridge(LDB) found in
+ Freescale i.MX8qxp processor. Official name of LDB is pixel mapper.
+
config DRM_IMX8QXP_PIXEL_COMBINER
tristate "Freescale i.MX8QM/QXP pixel combiner"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index e74dd64..96d5d1e 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,3 +1,6 @@
+imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
+obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
+
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
new file mode 100644
index ..d7f59c1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
@@ -0,0 +1,720 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "imx-ldb-helper.h"
+
+#define LDB_CH_SEL(1 << 28)
+
+#define SS_CTRL0x20
+#define CH_HSYNC_M(id)BIT(0 + ((id) * 2))
+#define CH_VSYNC_M(id)BIT(1 + ((id) * 2))
+#define CH_PHSYNC(id) BIT(0 + ((id) * 2))
+#define CH_PVSYNC(id) BIT(1 + ((id) * 2))
+
+#define DRIVER_NAME"imx8qxp-ldb"
+
+struct imx8qxp_ldb_channel {
+ struct ldb_channel base;
+ struct phy *phy;
+ unsigned int di_id;
+};
+
+struct imx8qxp_ldb {
+ struct ldb base;
+ struct device *dev;
+ struct imx8qxp_ldb_channel channel[MAX_LDB_CHAN_NUM];
+ struct clk *clk_pixel;
+ struct clk *clk_bypass;
+ struct drm_bridge *companion;
+ int active_chno;
+};
+
+static inline struct imx8qxp_ldb_channel *
+base_to_imx8qxp_ldb_channel(struct ldb_channel *base)
+{
+ return container_of(base, struct imx8qxp_ldb_channel, base);
+}
+
+static inline struct imx8qxp_ldb *base_to_imx8qxp_ldb(struct ldb *base)
+{
+ return container_of(base, struct imx8qxp_ldb, base);
+}
+
+static void imx8qxp_ldb_set_phy_cfg(struct imx8qxp_ldb *imx8qxp_ldb,
+ unsigned long di_clk, bool is_split,
+ struct phy_configure_opts_lvds *phy_cfg)
+{
+ phy_cfg->bits_per_lane_and_dclk_cycle = 7;
+ phy_cfg->lanes = 4;
+
+ if (is_split) {
+ phy_cfg->differential_clk_rate = di_clk / 2;
+ phy_cfg->is_slave = !imx8qxp_ldb->companion;
+ } else {
+
[PATCH v6 11/14] dt-bindings: display: bridge: Add i.MX8qm/qxp LVDS display bridge binding
This patch adds bindings for i.MX8qm/qxp LVDS display bridge(LDB).
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Add Rob's R-b tag.
v2->v3:
* Drop 'fsl,syscon' property. (Rob)
* Mention the CSR module controls LDB.
v1->v2:
* Use graph schema. (Laurent)
* Side note i.MX8qxp LDB official name 'pixel mapper'. (Laurent)
.../bindings/display/bridge/fsl,imx8qxp-ldb.yaml | 173 +
1 file changed, 173 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
new file mode 100644
index ..9454300
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
@@ -0,0 +1,173 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-ldb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp LVDS Display Bridge
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The Freescale i.MX8qm/qxp LVDS Display Bridge(LDB) has two channels.
+
+ The i.MX8qm/qxp LDB is controlled by Control and Status Registers(CSR)
module.
+ The CSR module, as a system controller, contains the LDB's configuration
+ registers.
+
+ For i.MX8qxp LDB, each channel supports up to 24bpp parallel input color
+ format and can map the input to VESA or JEIDA standards. The two channels
+ cannot be used simultaneously, that is to say, the user should pick one of
+ them to use. Two LDB channels from two LDB instances can work together in
+ LDB split mode to support a dual link LVDS display. The channel indexes
+ have to be different. Channel0 outputs odd pixels and channel1 outputs
+ even pixels.
+
+ For i.MX8qm LDB, each channel additionally supports up to 30bpp parallel
+ input color format. The two channels can be used simultaneously, either
+ in dual mode or split mode. In dual mode, the two channels output identical
+ data. In split mode, channel0 outputs odd pixels and channel1 outputs even
+ pixels.
+
+ A side note is that i.MX8qm/qxp LDB is officially called pixel mapper in
+ the SoC reference manuals. The pixel mapper uses logic of LDBs embedded in
+ i.MX6qdl/sx SoCs, i.e., it is essentially based on them. To keep the naming
+ consistency, this binding calls it LDB.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qm-ldb
+ - fsl,imx8qxp-ldb
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ clocks:
+items:
+ - description: pixel clock
+ - description: bypass clock
+
+ clock-names:
+items:
+ - const: pixel
+ - const: bypass
+
+ power-domains:
+maxItems: 1
+
+ fsl,companion-ldb:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+ A phandle which points to companion LDB which is used in LDB split mode.
+
+patternProperties:
+ "^channel@[0-1]$":
+type: object
+description: Represents a channel of LDB.
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ reg:
+description: The channel index.
+enum: [ 0, 1 ]
+
+ phys:
+description: A phandle to the phy module representing the LVDS PHY.
+maxItems: 1
+
+ phy-names:
+const: lvds_phy
+
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input port of the channel.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output port of the channel.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - reg
+ - phys
+ - phy-names
+
+additionalProperties: false
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - clocks
+ - clock-names
+ - power-domains
+ - channel@0
+ - channel@1
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: fsl,imx8qm-ldb
+then:
+ properties:
+fsl,companion-ldb: false
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+ldb {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx8qxp-ldb";
+clocks = < IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
+ < IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
+clock-names = "pixel", "bypass";
+power-domains = < IMX_SC_R_LVDS_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+phys = <_lvds_0_phy>;
+phy-names = "lvds_phy";
+
+port@0 {
+reg = <0>;
+
+mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint {
+remote-endpoint =
[PATCH v6 10/14] drm/bridge: imx: Add LDB driver helper support
This patch adds a helper to support LDB drm bridge drivers for
i.MX SoCs. Helper functions supported by this helper should
implement common logics for all LDB modules embedded in i.MX SoCs.
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge
driver and i.MX8qm LDB bridge driver. (Robert)
* Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'.
(Robert)
* s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/ for 'imx-ldb-helper.h'.
v3->v4:
* No change.
v2->v3:
* Call syscon_node_to_regmap() to get regmap instead of
syscon_regmap_lookup_by_phandle().
v1->v2:
* No change.
drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 232
drivers/gpu/drm/bridge/imx/imx-ldb-helper.h | 98
2 files changed, 330 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h
diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
new file mode 100644
index ..d01c4ff9
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2012 Sascha Hauer, Pengutronix
+ * Copyright 2019,2020 NXP
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "imx-ldb-helper.h"
+
+bool ldb_channel_is_single_link(struct ldb_channel *ldb_ch)
+{
+ return ldb_ch->link_type == LDB_CH_SINGLE_LINK;
+}
+
+bool ldb_channel_is_split_link(struct ldb_channel *ldb_ch)
+{
+ return ldb_ch->link_type == LDB_CH_DUAL_LINK_EVEN_ODD_PIXELS ||
+ ldb_ch->link_type == LDB_CH_DUAL_LINK_ODD_EVEN_PIXELS;
+}
+
+int ldb_bridge_atomic_check_helper(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct ldb_channel *ldb_ch = bridge->driver_private;
+
+ ldb_ch->in_bus_format = bridge_state->input_bus_cfg.format;
+ ldb_ch->out_bus_format = bridge_state->output_bus_cfg.format;
+
+ return 0;
+}
+
+void ldb_bridge_mode_set_helper(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ const struct drm_display_mode *adjusted_mode)
+{
+ struct ldb_channel *ldb_ch = bridge->driver_private;
+ struct ldb *ldb = ldb_ch->ldb;
+ bool is_split = ldb_channel_is_split_link(ldb_ch);
+
+ if (is_split)
+ ldb->ldb_ctrl |= LDB_SPLIT_MODE_EN;
+
+ switch (ldb_ch->out_bus_format) {
+ case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
+ if (ldb_ch->chno == 0 || is_split)
+ ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24;
+ if (ldb_ch->chno == 1 || is_split)
+ ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
+ if (ldb_ch->chno == 0 || is_split)
+ ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24 |
+LDB_BIT_MAP_CH0_JEIDA;
+ if (ldb_ch->chno == 1 || is_split)
+ ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24 |
+LDB_BIT_MAP_CH1_JEIDA;
+ break;
+ }
+}
+
+void ldb_bridge_enable_helper(struct drm_bridge *bridge)
+{
+ struct ldb_channel *ldb_ch = bridge->driver_private;
+ struct ldb *ldb = ldb_ch->ldb;
+
+ /*
+* Platform specific bridge drivers should set ldb_ctrl properly
+* for the enablement, so just write the ctrl_reg here.
+*/
+ regmap_write(ldb->regmap, ldb->ctrl_reg, ldb->ldb_ctrl);
+}
+
+void ldb_bridge_disable_helper(struct drm_bridge *bridge)
+{
+ struct ldb_channel *ldb_ch = bridge->driver_private;
+ struct ldb *ldb = ldb_ch->ldb;
+ bool is_split = ldb_channel_is_split_link(ldb_ch);
+
+ if (ldb_ch->chno == 0 || is_split)
+ ldb->ldb_ctrl &= ~LDB_CH0_MODE_EN_MASK;
+ if (ldb_ch->chno == 1 || is_split)
+ ldb->ldb_ctrl &= ~LDB_CH1_MODE_EN_MASK;
+
+ regmap_write(ldb->regmap, ldb->ctrl_reg, ldb->ldb_ctrl);
+}
+
+int ldb_bridge_attach_helper(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct ldb_channel *ldb_ch = bridge->driver_private;
+ struct ldb *ldb = ldb_ch->ldb;
+
+ if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+ DRM_DEV_ERROR(ldb->dev,
+ "do not support creating a drm_connector\n");
+ return -EINVAL;
+ }
+
+ if (!bridge->encoder) {
+ DRM_DEV_ERROR(ldb->dev,
[PATCH v6 09/14] drm/bridge: imx: Add i.MX8qxp pixel link to DPI support
This patch adds a drm bridge driver for i.MX8qxp pixel link to display
pixel interface(PXL2DPI). The PXL2DPI interfaces the pixel link 36-bit
data output and the DSI controller’s MIPI-DPI 24-bit data input, and
inputs of LVDS Display Bridge(LDB) module used in LVDS mode, to remap
the pixel color codings between those modules. The PXL2DPI is purely
combinatorial.
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Use 'fsl,sc-resource' DT property to get the SCU resource ID associated with
the PXL2DPI instance instead of using alias ID. (Rob)
v2->v3:
* Call syscon_node_to_regmap() to get regmap instead of
syscon_regmap_lookup_by_phandle().
v1->v2:
* Drop unnecessary port availability check.
drivers/gpu/drm/bridge/imx/Kconfig | 8 +
drivers/gpu/drm/bridge/imx/Makefile | 1 +
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 485 +++
3 files changed, 494 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 4d1f027..1ea1ce7 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -14,3 +14,11 @@ config DRM_IMX8QXP_PIXEL_LINK
help
Choose this to enable display pixel link found in
Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK_TO_DPI
+ tristate "Freescale i.MX8QXP pixel link to display pixel interface"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ Choose this to enable pixel link to display pixel interface(PXL2DPI)
+ found in Freescale i.MX8qxp processor.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index c15469f..e74dd64 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
new file mode 100644
index ..6696855
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -0,0 +1,485 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define PXL2DPI_CTRL 0x40
+#define CFG1_16BIT0x0
+#define CFG2_16BIT0x1
+#define CFG3_16BIT0x2
+#define CFG1_18BIT0x3
+#define CFG2_18BIT0x4
+#define CFG_24BIT 0x5
+
+#define DRIVER_NAME"imx8qxp-pxl2dpi"
+
+struct imx8qxp_pxl2dpi {
+ struct regmap *regmap;
+ struct drm_bridge bridge;
+ struct drm_bridge *next_bridge;
+ struct drm_bridge *companion;
+ struct device *dev;
+ struct imx_sc_ipc *ipc_handle;
+ u32 sc_resource;
+ u32 in_bus_format;
+ u32 out_bus_format;
+ u32 pl_sel;
+};
+
+#define bridge_to_p2d(b) container_of(b, struct imx8qxp_pxl2dpi, bridge)
+
+static int imx8qxp_pxl2dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+ if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+ DRM_DEV_ERROR(p2d->dev,
+ "do not support creating a drm_connector\n");
+ return -EINVAL;
+ }
+
+ if (!bridge->encoder) {
+ DRM_DEV_ERROR(p2d->dev, "missing encoder\n");
+ return -ENODEV;
+ }
+
+ return drm_bridge_attach(bridge->encoder,
+p2d->next_bridge, bridge,
+DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+}
+
+static int
+imx8qxp_pxl2dpi_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+ p2d->in_bus_format = bridge_state->input_bus_cfg.format;
+ p2d->out_bus_format = bridge_state->output_bus_cfg.format;
+
+ return 0;
+}
+
+static void
+imx8qxp_pxl2dpi_bridge_mode_set(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ const struct drm_display_mode *adjusted_mode)
+{
+ struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+ struct imx8qxp_pxl2dpi *companion_p2d;
+ int ret;
+
+ ret = pm_runtime_get_sync(p2d->dev);
+ if (ret < 0)
+ DRM_DEV_ERROR(p2d->dev,
+
[PATCH v6 08/14] dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding
This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* Add Rob's R-b tag.
v4->v5:
* No change.
v3->v4:
* Add 'fsl,sc-resource' property. (Rob)
v2->v3:
* Drop 'fsl,syscon' property. (Rob)
* Mention the CSR module controls PXL2DPI.
v1->v2:
* Use graph schema. (Laurent)
.../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 108 +
1 file changed, 108 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
new file mode 100644
index ..e4e77fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pxl2dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Pixel Link to Display Pixel Interface
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The Freescale i.MX8qxp Pixel Link to Display Pixel Interface(PXL2DPI)
+ interfaces the pixel link 36-bit data output and the DSI controller’s
+ MIPI-DPI 24-bit data input, and inputs of LVDS Display Bridge(LDB) module
+ used in LVDS mode, to remap the pixel color codings between those modules.
+ This module is purely combinatorial.
+
+ The i.MX8qxp PXL2DPI is controlled by Control and Status Registers(CSR)
module.
+ The CSR module, as a system controller, contains the PXL2DPI's configuration
+ register.
+
+properties:
+ compatible:
+const: fsl,imx8qxp-pxl2dpi
+
+ fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this PXL2DPI instance.
+
+ power-domains:
+maxItems: 1
+
+ fsl,companion-pxl2dpi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+ A phandle which points to companion PXL2DPI which is used by downstream
+ LVDS Display Bridge(LDB) in split mode.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: The PXL2DPI input port node from pixel link.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: The PXL2DPI output port node to downstream bridge.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - fsl,sc-resource
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+pxl2dpi {
+compatible = "fsl,imx8qxp-pxl2dpi";
+fsl,sc-resource = ;
+power-domains = < IMX_SC_R_MIPI_0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link0: endpoint@0 {
+reg = <0>;
+remote-endpoint = <_pixel_link0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_pixel_link1_mipi_lvds_0_pxl2dpi>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
+reg = <0>;
+remote-endpoint =
<_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
+reg = <1>;
+remote-endpoint =
<_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
+};
+};
+};
+};
--
2.7.4
[PATCH v6 05/14] dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link binding
This patch adds bindings for i.MX8qm/qxp display pixel link.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* No change.
v2->v3:
* Add Rob's R-b tag.
v1->v2:
* Use graph schema. (Laurent)
* Require all four pixel link output ports. (Laurent)
* Mention pixel link is accessed via SCU firmware. (Rob)
.../display/bridge/fsl,imx8qxp-pixel-link.yaml | 106 +
1 file changed, 106 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
new file mode 100644
index ..3af67cc
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-link.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Pixel Link
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The Freescale i.MX8qm/qxp Display Pixel Link(DPL) forms a standard
+ asynchronous linkage between pixel sources(display controller or
+ camera module) and pixel consumers(imaging or displays).
+ It consists of two distinct functions, a pixel transfer function and a
+ control interface. Multiple pixel channels can exist per one control
channel.
+ This binding documentation is only for pixel links whose pixel sources are
+ display controllers.
+
+ The i.MX8qm/qxp Display Pixel Link is accessed via System Controller
Unit(SCU)
+ firmware.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qm-dc-pixel-link
+ - fsl,imx8qxp-dc-pixel-link
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: The pixel link input port node from upstream video source.
+
+patternProperties:
+ "^port@[1-4]$":
+$ref: /schemas/graph.yaml#/properties/port
+description: The pixel link output port node to downstream bridge.
+
+required:
+ - port@0
+ - port@1
+ - port@2
+ - port@3
+ - port@4
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+dc0-pixel-link0 {
+compatible = "fsl,imx8qxp-dc-pixel-link";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+/* from dc0 pixel combiner channel0 */
+port@0 {
+reg = <0>;
+
+dc0_pixel_link0_dc0_pixel_combiner_ch0: endpoint {
+remote-endpoint =
<_pixel_combiner_ch0_dc0_pixel_link0>;
+};
+};
+
+/* to PXL2DPIs in MIPI/LVDS combo subsystems */
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+dc0_pixel_link0_mipi_lvds_0_pxl2dpi: endpoint@0 {
+reg = <0>;
+remote-endpoint = <_lvds_0_pxl2dpi_dc0_pixel_link0>;
+};
+
+dc0_pixel_link0_mipi_lvds_1_pxl2dpi: endpoint@1 {
+reg = <1>;
+remote-endpoint = <_lvds_1_pxl2dpi_dc0_pixel_link0>;
+};
+};
+
+/* unused */
+port@2 {
+reg = <2>;
+};
+
+/* unused */
+port@3 {
+reg = <3>;
+};
+
+/* to imaging subsystem */
+port@4 {
+reg = <4>;
+};
+};
+};
--
2.7.4
[PATCH v6 04/14] drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support
This patch adds a drm bridge driver for i.MX8qm/qxp pixel combiner.
The pixel combiner takes two output streams from a single display
controller and manipulates the two streams to support a number
of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
as either one screen, two screens, or virtual screens. The pixel
combiner is also responsible for generating some of the control signals
for the pixel link output channel. For now, the driver only supports
the bypass mode.
Reviewed-by: Robert Foss
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* Drop the 'PC_BUF_PARA_REG' register definition. (Robert)
* Add Robert's R-b tag.
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* No change.
drivers/gpu/drm/bridge/Kconfig | 2 +
drivers/gpu/drm/bridge/Makefile| 1 +
drivers/gpu/drm/bridge/imx/Kconfig | 8 +
drivers/gpu/drm/bridge/imx/Makefile| 1 +
.../gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c| 448 +
5 files changed, 460 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/Kconfig
create mode 100644 drivers/gpu/drm/bridge/imx/Makefile
create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6c..84944e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -256,6 +256,8 @@ source "drivers/gpu/drm/bridge/adv7511/Kconfig"
source "drivers/gpu/drm/bridge/cadence/Kconfig"
+source "drivers/gpu/drm/bridge/imx/Kconfig"
+
source "drivers/gpu/drm/bridge/synopsys/Kconfig"
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc..bc80cae 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -27,4 +27,5 @@ obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
obj-y += analogix/
obj-y += cadence/
+obj-y += imx/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
new file mode 100644
index ..f1c91b6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -0,0 +1,8 @@
+config DRM_IMX8QXP_PIXEL_COMBINER
+ tristate "Freescale i.MX8QM/QXP pixel combiner"
+ depends on OF
+ depends on COMMON_CLK
+ select DRM_KMS_HELPER
+ help
+ Choose this to enable pixel combiner found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
new file mode 100644
index ..7d7c8d6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
new file mode 100644
index ..0b9403a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
@@ -0,0 +1,448 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define PC_CTRL_REG0x0
+#define PC_COMBINE_ENABLE BIT(0)
+#define PC_DISP_BYPASS(n) BIT(1 + 21 * (n))
+#define PC_DISP_HSYNC_POLARITY(n) BIT(2 + 11 * (n))
+#define PC_DISP_HSYNC_POLARITY_POS(n) DISP_HSYNC_POLARITY(n)
+#define PC_DISP_VSYNC_POLARITY(n) BIT(3 + 11 * (n))
+#define PC_DISP_VSYNC_POLARITY_POS(n) DISP_VSYNC_POLARITY(n)
+#define PC_DISP_DVALID_POLARITY(n)BIT(4 + 11 * (n))
+#define PC_DISP_DVALID_POLARITY_POS(n)DISP_DVALID_POLARITY(n)
+#define PC_VSYNC_MASK_ENABLE BIT(5)
+#define PC_SKIP_MODE BIT(6)
+#define PC_SKIP_NUMBER_MASK GENMASK(12, 7)
+#define PC_SKIP_NUMBER(n) FIELD_PREP(PC_SKIP_NUMBER_MASK, (n))
+#define PC_DISP0_PIX_DATA_FORMAT_MASK GENMASK(18, 16)
+#define PC_DISP0_PIX_DATA_FORMAT(fmt) \
+ FIELD_PREP(PC_DISP0_PIX_DATA_FORMAT_MASK, (fmt))
+#define PC_DISP1_PIX_DATA_FORMAT_MASK GENMASK(21, 19)
+#define PC_DISP1_PIX_DATA_FORMAT(fmt) \
+ FIELD_PREP(PC_DISP1_PIX_DATA_FORMAT_MASK, (fmt))
+
+#define PC_SW_RESET_REG0x20
+#define PC_SW_RESET_N BIT(0)
+#define PC_DISP_SW_RESET_N(n) BIT(1 + (n))
+#define PC_FULL_RESET_N (PC_SW_RESET_N |\
+PC_DISP_SW_RESET_N(0) |\
+PC_DISP_SW_RESET_N(1))
+
+#define PC_REG_SET 0x4
+#define PC_REG_CLR 0x8
+
+#define DRIVER_NAME"imx8qxp-pixel-combiner"
+
+enum imx8qxp_pc_pix_data_format {
+ RGB,
+ YUV444,
+ YUV422,
+ SPLIT_RGB,
+};
+
+struct imx8qxp_pc_channel {
+ struct
[PATCH v6 00/14] Add some DRM bridge drivers support for i.MX8qm/qxp SoCs
Hi,
This is the v6 series to add some DRM bridge drivers support
for i.MX8qm/qxp SoCs.
The bridges may chain one by one to form display pipes to support
LVDS displays. The relevant display controller is DPU embedded in
i.MX8qm/qxp SoCs.
The DPU KMS driver can be found at:
https://www.spinics.net/lists/arm-kernel/msg878542.html
This series supports the following display pipes:
1) i.MX8qxp:
prefetch eng -> DPU -> pixel combiner -> pixel link ->
pixel link to DPI(PXL2DPI) -> LVDS display bridge(LDB)
2) i.MX8qm:
prefetch eng -> DPU -> pixel combiner -> pixel link -> LVDS display bridge(LDB)
This series dropped the patch 'phy: Add LVDS configuration options', as
suggested by Robert Foss, because it has already been sent with the following
series to add Mixel combo PHY found in i.MX8qxp:
https://www.spinics.net/lists/arm-kernel/msg879957.html
So, this version depends on that series.
Patch 1/14 and 2/14 add bus formats used by pixel combiner.
Patch 7/14 adds dt-binding for Control and Status Registers module(a syscon
used by PXL2DPI and LDB), which references the PXL2DPI and LDB schemas.
Patch 10/14 adds a helper for LDB bridge drivers.
Patch 3/14 ~ 6/14, 8/14, 9/14 and 11/14 ~ 13/14 add drm bridge drivers and
dt-bindings support for the bridges.
Patch 14/14 updates MAINTAINERS.
I've tested this series with a koe,tx26d202vm0bwa dual link LVDS panel and
a LVDS to HDMI bridge(with a downstream drm bridge driver).
Welcome comments, thanks.
v5->v6:
* Fix data organizations in documentation(patch 2/14) for
MEDIA_BUS_FMT_RGB{666,888}_1X30-CPADLO. (Laurent)
* Add Laurent's R-b tags on patch 1/14 and 2/14.
* Drop 'select' schema from the CSR dt-binding documentation(patch 7/14). (Rob)
* Add Rob's R-b tag on patch 8/14.
v4->v5:
* Drop the patch 'phy: Add LVDS configuration options'. (Robert)
* Add Robert's R-b tags on patch 1/14, 2/14, 4/14 and 6/14.
* Drop the 'PC_BUF_PARA_REG' register definition from the pixel combiner bridge
driver(patch 4/14). (Robert)
* Make a comment occupy a line in the pixel link bridge driver(patch 6/14).
(Robert)
* Introduce a new patch(patch 7/14) to add dt-binding for Control and Status
Registers module. (Rob)
* Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge
driver and i.MX8qm LDB bridge driver, instead of a module. Correspondingly,
rename 'imx8{qm, qxp}-ldb.c' to 'imx8{qm, qxp}-ldb-drv.c'. (Robert)
* Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'.
(Robert)
* s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/ for 'imx-ldb-helper.h'.
v3->v4:
* Use 'fsl,sc-resource' DT property to get the SCU resource ID associated with
the PXL2DPI instance instead of using alias ID. (Rob)
* Add Rob's R-b tag on patch 11/14.
v2->v3:
* Drop 'fsl,syscon' DT properties from fsl,imx8qxp-ldb.yaml and
fsl,imx8qxp-pxl2dpi.yaml. (Rob)
* Mention the CSR module controls LDB and PXL2DPI in fsl,imx8qxp-ldb.yaml and
fsl,imx8qxp-pxl2dpi.yaml.
* Call syscon_node_to_regmap() to get regmaps from LDB bridge helper driver
and PXL2DPI bridger driver instead of syscon_regmap_lookup_by_phandle().
* Drop two macros from pixel link bridge driver which help define functions
and define them directly.
* Properly disable all pixel link controls to POR value by calling
imx8qxp_pixel_link_disable_all_controls() from
imx8qxp_pixel_link_bridge_probe().
* Add Rob's R-b tags on patch 4/14 and 6/14.
v1->v2:
* Rebase the series upon the latest drm-misc-next branch(5.11-rc2 based).
* Use graph schema in the dt-bindings of the bridges. (Laurent)
* Require all four pixel link output ports in fsl,imx8qxp-pixel-link.yaml.
(Laurent)
* Side note i.MX8qm/qxp LDB official name 'pixel mapper' in
fsl,imx8qxp-ldb.yaml.
(Laurent)
* Mention pixel link is accessed via SCU firmware in
fsl,imx8qxp-pixel-link.yaml.
(Rob)
* Use enum instead of oneOf + const for the reg property of pixel combiner
channels in fsl,imx8qxp-pixel-combiner.yaml. (Rob)
* Rewrite the function to find the next bridge in pixel link bridge driver
by properly using OF APIs and dropping unnecessary DT validation. (Rob)
* Drop unnecessary port availability check in i.MX8qxp pixel link to DPI
bridge driver.
* Drop unnecessary DT validation from i.MX8qxp LDB bridge driver.
* Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
get the input remote endpoint in imx8qxp_ldb_set_di_id() of i.MX8qxp LDB
bridge driver.
* Avoid using companion_port OF node after putting it in
imx8qxp_ldb_parse_dt_companion() of i.MX8qxp LDB bridge driver.
* Drop unnecessary check for maximum available LDB channels from
i.MX8qm LDB bridge driver.
* Mention i.MX8qm/qxp LDB official name 'pixel mapper' in i.MX8qm/qxp LDB
bridge drivers and Kconfig help messages.
Liu Ying (14):
media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner
[PATCH v6 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding
This patch adds bindings for i.MX8qm/qxp Control and Status Registers module.
Signed-off-by: Liu Ying
---
v5->v6:
* Drop 'select' schema. (Rob)
v4->v5:
* Newly introduced in v5. (Rob)
.../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml | 192 +
1 file changed, 192 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
diff --git a/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
new file mode 100644
index ..f095771
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
@@ -0,0 +1,192 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/fsl,imx8qxp-csr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Control and Status Registers Module Bindings
+
+maintainers:
+ - Liu Ying
+
+description: |
+ As a system controller, the Freescale i.MX8qm/qxp Control and Status
+ Registers(CSR) module represents a set of miscellaneous registers of a
+ specific subsystem. It may provide control and/or status report interfaces
+ to a mix of standalone hardware devices within that subsystem. One typical
+ use-case is for some other nodes to acquire a reference to the syscon node
+ by phandle, and the other typical use-case is that the operating system
+ should consider all subnodes of the CSR module as separate child devices.
+
+properties:
+ $nodename:
+pattern: "^syscon@[0-9a-f]+$"
+
+ compatible:
+items:
+ - enum:
+ - fsl,imx8qxp-mipi-lvds-csr
+ - fsl,imx8qm-lvds-csr
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: ipg
+
+patternProperties:
+ "^(ldb|phy|pxl2dpi)$":
+type: object
+description: The possible child devices of the CSR module.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: fsl,imx8qxp-mipi-lvds-csr
+then:
+ required:
+- pxl2dpi
+- ldb
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: fsl,imx8qm-lvds-csr
+then:
+ required:
+- phy
+- ldb
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+mipi_lvds_0_csr: syscon@56221000 {
+compatible = "fsl,imx8qxp-mipi-lvds-csr", "syscon", "simple-mfd";
+reg = <0x56221000 0x1000>;
+clocks = <_lvds_0_di_mipi_lvds_regs_lpcg IMX_LPCG_CLK_4>;
+clock-names = "ipg";
+
+mipi_lvds_0_pxl2dpi: pxl2dpi {
+compatible = "fsl,imx8qxp-pxl2dpi";
+fsl,sc-resource = ;
+power-domains = < IMX_SC_R_MIPI_0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+mipi_lvds_0_pxl2dpi_dc0_pixel_link0: endpoint@0 {
+reg = <0>;
+remote-endpoint =
<_pixel_link0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_dc0_pixel_link1: endpoint@1 {
+reg = <1>;
+remote-endpoint =
<_pixel_link1_mipi_lvds_0_pxl2dpi>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
+reg = <0>;
+remote-endpoint =
<_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
+reg = <1>;
+remote-endpoint =
<_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
+};
+};
+};
+};
+
+mipi_lvds_0_ldb: ldb {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx8qxp-ldb";
+clocks = < IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
+ < IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
+clock-names = "pixel", "bypass";
+power-domains = < IMX_SC_R_LVDS_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+phys = <_lvds_0_phy>;
+phy-names = "lvds_phy";
+
+port@0 {
+reg = <0>;
+
+mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint {
+remote-endpoint =
[PATCH v6 06/14] drm/bridge: imx: Add i.MX8qm/qxp display pixel link support
This patch adds a drm bridge driver for i.MX8qm/qxp display pixel link.
The pixel link forms a standard asynchronous linkage between
pixel sources(display controller or camera module) and pixel
consumers(imaging or displays). It consists of two distinct
functions, a pixel transfer function and a control interface.
Reviewed-by: Robert Foss
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* Make a comment occupy a line. (Robert)
* Add Robert's R-b tag.
v3->v4:
* No change.
v2->v3:
* Drop two macros which help define functions and define them directly.
* Properly disable all pixel link controls to POR value by calling
imx8qxp_pixel_link_disable_all_controls() from
imx8qxp_pixel_link_bridge_probe().
v1->v2:
* Rewrite the function to find the next bridge by properly using OF APIs
and dropping unnecessary DT validation. (Rob)
drivers/gpu/drm/bridge/imx/Kconfig | 8 +
drivers/gpu/drm/bridge/imx/Makefile | 1 +
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 427
3 files changed, 436 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index f1c91b6..4d1f027 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -6,3 +6,11 @@ config DRM_IMX8QXP_PIXEL_COMBINER
help
Choose this to enable pixel combiner found in
Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK
+ tristate "Freescale i.MX8QM/QXP display pixel link"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ Choose this to enable display pixel link found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index 7d7c8d6..c15469f 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
new file mode 100644
index ..a549624
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -0,0 +1,427 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+#define DRIVER_NAME"imx8qxp-display-pixel-link"
+#define PL_MAX_MST_ADDR3
+#define PL_MAX_NEXT_BRIDGES2
+
+struct imx8qxp_pixel_link {
+ struct drm_bridge bridge;
+ struct drm_bridge *next_bridge;
+ struct device *dev;
+ struct imx_sc_ipc *ipc_handle;
+ int id;
+ int stream_id;
+ int dc_id;
+ u32 sink_rsc;
+ u32 mst_addr;
+ u8 mst_addr_ctrl;
+ u8 mst_en_ctrl;
+ u8 mst_vld_ctrl;
+ u8 sync_ctrl;
+};
+
+static void imx8qxp_pixel_link_enable_mst_en(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->mst_en_ctrl, true);
+ if (ret)
+ DRM_DEV_ERROR(pl->dev,
+ "failed to enable DC%d stream%d pixel link mst_en:
%d\n",
+ pl->dc_id, pl->stream_id, ret);
+}
+
+static void imx8qxp_pixel_link_enable_mst_vld(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->mst_vld_ctrl, true);
+ if (ret)
+ DRM_DEV_ERROR(pl->dev,
+ "failed to enable DC%d stream%d pixel link mst_vld: %d\n",
+ pl->dc_id, pl->stream_id, ret);
+}
+
+static void imx8qxp_pixel_link_enable_sync(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->sync_ctrl, true);
+ if (ret)
+ DRM_DEV_ERROR(pl->dev,
+ "failed to enable DC%d stream%d pixel link sync: %d\n",
+ pl->dc_id, pl->stream_id, ret);
+}
+
+static int imx8qxp_pixel_link_disable_mst_en(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->mst_en_ctrl, false);
+ if (ret)
+ DRM_DEV_ERROR(pl->dev,
+ "failed to disable DC%d stream%d pixel link mst_en: %d\n",
+ pl->dc_id, pl->stream_id, ret);
+
+ return ret;
+}
+
+static int imx8qxp_pixel_link_disable_mst_vld(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret =
[PATCH v6 01/14] media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner. The RGB pixels with padding low per component are transmitted on a 30-bit input bus(10-bit per component) from a display controller or a 36-bit output bus(12-bit per component) to a pixel link. Reviewed-by: Robert Foss Reviewed-by: Laurent Pinchart Signed-off-by: Liu Ying --- v5->v6: * Add Laurent's R-b tag. v4->v5: * Add Robert's R-b tag. v3->v4: * No change. v2->v3: * No change. v1->v2: * No change. include/uapi/linux/media-bus-format.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 0dfc11e..ec3323d 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -34,7 +34,7 @@ #define MEDIA_BUS_FMT_FIXED0x0001 -/* RGB - next is 0x101e */ +/* RGB - next is 0x1022 */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 @@ -59,9 +59,13 @@ #define MEDIA_BUS_FMT_RGB888_3X8_DELTA 0x101d #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 +#define MEDIA_BUS_FMT_RGB666_1X30_CPADLO 0x101e +#define MEDIA_BUS_FMT_RGB888_1X30_CPADLO 0x101f #define MEDIA_BUS_FMT_ARGB_1X320x100d #define MEDIA_BUS_FMT_RGB888_1X32_PADHI0x100f #define MEDIA_BUS_FMT_RGB101010_1X30 0x1018 +#define MEDIA_BUS_FMT_RGB666_1X36_CPADLO 0x1020 +#define MEDIA_BUS_FMT_RGB888_1X36_CPADLO 0x1021 #define MEDIA_BUS_FMT_RGB121212_1X36 0x1019 #define MEDIA_BUS_FMT_RGB161616_1X48 0x101a -- 2.7.4
[PATCH v6 03/14] dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding
This patch adds bindings for i.MX8qm/qxp pixel combiner.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* No change.
v2->v3:
* Add Rob's R-b tag.
v1->v2:
* Use graph schema. (Laurent)
* Use enum instead of oneOf + const for the reg property of pixel combiner
channels. (Rob)
.../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 144 +
1 file changed, 144 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
new file mode 100644
index ..50bae21
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-combiner.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Pixel Combiner
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The Freescale i.MX8qm/qxp Pixel Combiner takes two output streams from a
+ single display controller and manipulates the two streams to support a number
+ of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured as
+ either one screen, two screens, or virtual screens. The pixel combiner is
+ also responsible for generating some of the control signals for the pixel
link
+ output channel.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qm-pixel-combiner
+ - fsl,imx8qxp-pixel-combiner
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: apb
+
+ power-domains:
+maxItems: 1
+
+patternProperties:
+ "^channel@[0-1]$":
+type: object
+description: Represents a display stream of pixel combiner.
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ reg:
+description: The display stream index.
+enum: [ 0, 1 ]
+
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input endpoint of the display stream.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output endpoint of the display stream.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - reg
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+pixel-combiner@5602 {
+compatible = "fsl,imx8qxp-pixel-combiner";
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x5602 0x1>;
+clocks = <_pixel_combiner_lpcg IMX_LPCG_CLK_4>;
+clock-names = "apb";
+power-domains = < IMX_SC_R_DC_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch0_dc0_dpu_disp0: endpoint {
+remote-endpoint = <_dpu_disp0_dc0_pixel_combiner_ch0>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch0_dc0_pixel_link0: endpoint {
+remote-endpoint =
<_pixel_link0_dc0_pixel_combiner_ch0>;
+};
+};
+};
+
+channel@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch1_dc0_dpu_disp1: endpoint {
+remote-endpoint = <_dpu_disp1_dc0_pixel_combiner_ch1>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch1_dc0_pixel_link1: endpoint {
+remote-endpoint =
<_pixel_link1_dc0_pixel_combiner_ch1>;
+};
+};
+};
+};
--
2.7.4
