Re: microwatt_defconfig broken: fined reference to `hash__tlb_flush'
Hi Jan-Benedict, Le 17/02/2023 à 21:41, Jan-Benedict Glaw a écrit : > Hi Christophe! > > On Fri, 2023-02-17 21:00:43 +0100, Jan-Benedict Glaw > wrote: >> On Fri, 2023-02-17 19:44:27 +, Christophe Leroy >> wrote: >>> Le 17/02/2023 à 18:14, Jan-Benedict Glaw a écrit : My CI builds showed that the microwatt_defconfig broke somewhere between (upstream Linus) 6d796c50f84ca79f1722bb131799e5a5710c4700 (last known good, log at [1]) and 033c40a89f55525139fd5b6342281b09b97d05bf (first known bad, log at [2]) with this: [...] make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64le-linux- INSTALL_MOD_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig INSTALL_DTBS_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig all [...] [mk all 2023-02-17 01:42:27] + powerpc64le-linux-ld -EL -z noexecstack --no-warn-rwx-segments -Bstatic --build-id=sha1 --orphan-handling=warn --script=./arch/powerpc/kernel/vmlinux.lds --strip-debug -o .tmp_vmlinux.kallsyms1 --whole-archive vmlinux.a init/version-timestamp.o --no-whole-archive --start-group lib/lib.a --end-group [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/memory.o: in function `tlb_flush_mmu_tlbonly': [mk all 2023-02-17 01:42:28] memory.c:(.text+0x320): undefined reference to `hash__tlb_flush' [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mmu_gather.o: in function `tlb_flush_mmu_tlbonly': [mk all 2023-02-17 01:42:28] mmu_gather.c:(.text+0xe0): undefined reference to `hash__tlb_flush' [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mprotect.o: in function `change_protection': [mk all 2023-02-17 01:42:28] mprotect.c:(.text+0x59c): undefined reference to `hash__tlb_flush' [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/madvise.o: in function `tlb_end_vma.isra.0': [mk all 2023-02-17 01:42:28] madvise.c:(.text+0x1f0): undefined reference to `hash__tlb_flush' [mk all 2023-02-17 01:42:28] make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 1 [mk all 2023-02-17 01:42:28] make: *** [Makefile:1264: vmlinux] Error 2 >>> >>> >>> The fix is available here : >>> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=4302abc628fc0dc08e5855f21bbfaed407a72bc3 >> >> I can give that patch a try, but on the first glimpse, it won't help: > [...] >> The patch handles a return-type issue. My above issue is a linkage >> issue, the linker cannot find hash__tlb_flush(). Or am I mistaken? > > I stand corrected: That patch fixes the linker issue. (Build log at > http://toolchain.lug-owl.de/laminar/jobs/linux-powerpc-microwatt_defconfig/69) > Just ftr: How does this work? > On microwatt_defconfig, radix_enabled() is always true so the compiler eliminates the else branch. Christophe
Re: 6.2-rc7 fails building on Talos II: memory.c:(.text+0x2e14): undefined reference to `hash__tlb_flush'
[TLDR: This mail in primarily relevant for Linux regression tracking. A change or fix related to the regression discussed in this thread was posted or applied, but it did not use a Link: tag to point to the report, as Linus and the documentation call for. Things happen, no worries -- but now the regression tracking bot needs to be told manually about the fix. See link in footer if these mails annoy you.] On 16.02.23 11:09, Linux regression tracking (Thorsten Leemhuis) wrote: > > On 16.02.23 00:55, Erhard F. wrote: >> Just noticed a build failure on 6.2-rc7 for my Talos 2 (.config attached): >> >> # make >> CALLscripts/checksyscalls.sh >> UPD include/generated/utsversion.h >> CC init/version-timestamp.o >> LD .tmp_vmlinux.kallsyms1 >> ld: ld: DWARF error: could not find abbrev number 6 >> mm/memory.o: in function `unmap_page_range': >> memory.c:(.text+0x2e14): undefined reference to `hash__tlb_flush' >> ld: memory.c:(.text+0x2f8c): undefined reference to `hash__tlb_flush' >> ld: ld: DWARF error: could not find abbrev number 3117 >> mm/mmu_gather.o: in function `tlb_remove_table': >> mmu_gather.c:(.text+0x584): undefined reference to `hash__tlb_flush' >> ld: mmu_gather.c:(.text+0x6c4): undefined reference to `hash__tlb_flush' >> ld: mm/mmu_gather.o: in function `tlb_flush_mmu': >> mmu_gather.c:(.text+0x80c): undefined reference to `hash__tlb_flush' >> ld: mm/mmu_gather.o:mmu_gather.c:(.text+0xbe0): more undefined references to >> `hash__tlb_flush' follow >> make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Fehler 1 >> make: *** [Makefile:1264: vmlinux] Error 2 #regzbot fix: 4302abc628fc0dc08e5855f21bbfa #regzbot ignore-activity Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.
[powerpc:merge] BUILD SUCCESS 4f8c30390bbb243a5ac0f4a25d9f0dfeaef90977
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 4f8c30390bbb243a5ac0f4a25d9f0dfeaef90977 Automatic merge of 'next' into merge (2023-02-17 12:38) elapsed time: 1276m configs tested: 118 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: alphaallyesconfig alpha defconfig arc allyesconfig arc defconfig arc nsimosci_hs_defconfig arc randconfig-r043-20230215 arc randconfig-r043-20230217 arc tb10x_defconfig arm allmodconfig arm allyesconfig arm axm55xx_defconfig arm corgi_defconfig arm defconfig arm tegra_defconfig arm64allyesconfig arm64 defconfig cskydefconfig i386 allyesconfig i386 debian-10.3 i386defconfig i386 randconfig-a011-20230213 i386 randconfig-a012 i386 randconfig-a012-20230213 i386 randconfig-a013-20230213 i386 randconfig-a014 i386 randconfig-a014-20230213 i386 randconfig-a015-20230213 i386 randconfig-a016 i386 randconfig-a016-20230213 i386 randconfig-c001 ia64 allmodconfig ia64defconfig loongarchallmodconfig loongarch allnoconfig loongarch defconfig m68k allmodconfig m68kdefconfig m68kmvme16x_defconfig m68k virt_defconfig microblaze defconfig mips allmodconfig mips allyesconfig nios2 defconfig parisc defconfig parisc64defconfig powerpc allmodconfig powerpc allnoconfig powerpc motionpro_defconfig powerpc mpc834x_mds_defconfig powerpc tqm8548_defconfig riscvallmodconfig riscv allnoconfig riscv defconfig riscvrandconfig-r042-20230215 riscvrandconfig-r042-20230217 riscv rv32_defconfig s390 allmodconfig s390 allyesconfig s390defconfig s390 randconfig-r044-20230215 s390 randconfig-r044-20230217 sh allmodconfig sh ecovec24_defconfig sh polaris_defconfig sh sh7770_generic_defconfig sh sh7785lcr_32bit_defconfig shtitan_defconfig sparc defconfig um i386_defconfig um x86_64_defconfig x86_64allnoconfig x86_64 allyesconfig x86_64 defconfig x86_64 kexec x86_64randconfig-a011 x86_64 randconfig-a011-20230213 x86_64 randconfig-a012-20230213 x86_64randconfig-a013 x86_64 randconfig-a013-20230213 x86_64 randconfig-a014-20230213 x86_64randconfig-a015 x86_64 randconfig-a015-20230213 x86_64 randconfig-a016-20230213 x86_64 rhel-8.3 xtensa alldefconfig xtensa audio_kc705_defconfig clang tested configs: arm aspeed_g4_defconfig arm colibri_pxa270_defconfig arm moxart_defconfig arm randconfig-r046-20230215 arm randconfig-r046-20230217 arm spear13xx_defconfig arm spitz_defconfig hexagon randconfig-r041-20230215 hexagon randconfig-r041-20230217 hexagon randconfig-r045-20230215 hexagon randconfig-r045-20230217 i386 randconfig-a001-20230213 i386 randconfig-a002-20230213 i386 randconfig-a003
[powerpc:next] BUILD SUCCESS 38d73b671a817328334f2a70a23fed4d1f4a952c
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 38d73b671a817328334f2a70a23fed4d1f4a952c powerpc/64: Fix unannotated intra-function call warning elapsed time: 753m configs tested: 73 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: alphaallyesconfig alpha defconfig arc allyesconfig arc defconfig arc randconfig-r043-20230217 arm allmodconfig arm allyesconfig arm defconfig arm64allyesconfig arm64 defconfig cskydefconfig i386 allyesconfig i386 debian-10.3 i386defconfig i386 randconfig-a001 i386 randconfig-a003 i386 randconfig-a005 i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 ia64 allmodconfig ia64defconfig loongarchallmodconfig loongarch allnoconfig loongarch defconfig m68k allmodconfig m68kdefconfig mips allmodconfig mips allyesconfig nios2 defconfig parisc defconfig parisc64defconfig powerpc allmodconfig powerpc allnoconfig riscvallmodconfig riscv allnoconfig riscv defconfig riscvrandconfig-r042-20230217 riscv rv32_defconfig s390 allmodconfig s390 allyesconfig s390defconfig s390 randconfig-r044-20230217 sh allmodconfig sparc defconfig um i386_defconfig um x86_64_defconfig x86_64allnoconfig x86_64 allyesconfig x86_64 defconfig x86_64 kexec x86_64randconfig-a002 x86_64randconfig-a004 x86_64randconfig-a006 x86_64randconfig-a011 x86_64randconfig-a013 x86_64randconfig-a015 x86_64 rhel-8.3 clang tested configs: arm randconfig-r046-20230217 hexagon randconfig-r041-20230217 hexagon randconfig-r045-20230217 i386 randconfig-a002 i386 randconfig-a004 i386 randconfig-a006 i386 randconfig-a011 i386 randconfig-a013 i386 randconfig-a015 x86_64randconfig-a001 x86_64randconfig-a003 x86_64randconfig-a005 x86_64randconfig-a012 x86_64randconfig-a014 x86_64randconfig-a016 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-6.2-6 tag
The pull request you sent on Sat, 18 Feb 2023 09:40:18 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-6.2-6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/dbeed98d89ea91ae68ff6dce6060671726292e85 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-6.2-6 tag
On Fri, Feb 17, 2023 at 2:40 PM Michael Ellerman wrote: > > Thanks to: Benjamin Gray, "Erhard F.". That just looks _odd_. It's not like the full name wasn't already elsewhere in the kernel logs as a reporter (and at least once as patch author), so I just fixed it up ;) Linus
[GIT PULL] Please pull powerpc/linux.git powerpc-6.2-6 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull one more powerpc fix for 6.2: The following changes since commit 2ea31e2e62bbc4d11c411eeb36f1b02841dbcab1: powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch (2023-02-07 10:13:33 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.2-6 for you to fetch changes up to 4302abc628fc0dc08e5855f21bbfaed407a72bc3: powerpc/64s: Prevent fallthrough to hash TLB flush when using radix (2023-02-17 12:30:56 +1100) - -- powerpc fixes for 6.2 #6 - Prevent fallthrough to hash TLB flush when using radix. Thanks to: Benjamin Gray, "Erhard F.". - -- Benjamin Gray (1): powerpc/64s: Prevent fallthrough to hash TLB flush when using radix arch/powerpc/include/asm/book3s/64/tlbflush.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmPwAU4ACgkQUevqPMjh pYDPjRAAlpjdeTzrSwV63jF3q9I5H9mgdmiNa2ZfRifKI7FLvHd9Yob8gs35D//x CLLhrQmtWL9LooFu5bx+UsLs2MuLevmUsWFWXhYPwDjEuLx12VP64i4obbugH89e QbGr6J9HwwHQLnwFacBWAPHl4NGO2KhRt/GEZZsWvw/1szikYDJfNlhh6M5vD5PW XNgkA5aJdyegkYWlYF+OsRVeE3GRzqU1dDagdc+9kzXzkqcMj4DsxVohviTLhhua cIdfUlZV8BDQc0F2I4376mh4O1+b/k4eGbnyIF14jd0Z/9ZOF9nAkgU7s3Z74n38 O5gIBPMSz8bXoYKyVCO61SoDZHUGCWTn0xx14/cl0PAgGoU29xUH5/+S1miN1LdE N9gA3hDNagfRpXTDCWmbp5BREHItLrDzKUv125Ipf5hilV0Yzp/G7JAfun8E37wx 3I0iHvH/Feq55fT9w1lggQ/Qt+9147xd5GyCbEQn7mJ/jolSFRkLzpAhsnec7Iwr qs00/n1JrRK5Owi6Ir2ds8vGZP4dFSGxnzhDMU/PaacavBpGDPP8xb2JsrvpoR6o rhReC7bnmYKIel7YJAaY+U3qwyCdYMBrQGpnfOb1eMXFYXK2LopP4TWfVO/LxHsp 7fllB3nBWGQX/fCwKe5QMUS9QhAYWJ1Y/hgq3Gg1o9nmfn2VWNY= =/f1f -END PGP SIGNATURE-
Re: microwatt_defconfig broken: fined reference to `hash__tlb_flush'
Hi Christophe! On Fri, 2023-02-17 21:00:43 +0100, Jan-Benedict Glaw wrote: > On Fri, 2023-02-17 19:44:27 +, Christophe Leroy > wrote: > > Le 17/02/2023 à 18:14, Jan-Benedict Glaw a écrit : > > > My CI builds showed that the microwatt_defconfig broke somewhere between > > > (upstream Linus) 6d796c50f84ca79f1722bb131799e5a5710c4700 (last known > > > good, log > > > at [1]) and 033c40a89f55525139fd5b6342281b09b97d05bf (first known bad, > > > log at > > > [2]) with this: > > > > > > [...] > > > make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64le-linux- > > > INSTALL_MOD_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig > > > > > > INSTALL_DTBS_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig > > > all > > > [...] > > > [mk all 2023-02-17 01:42:27] + powerpc64le-linux-ld -EL -z noexecstack > > > --no-warn-rwx-segments -Bstatic --build-id=sha1 --orphan-handling=warn > > > --script=./arch/powerpc/kernel/vmlinux.lds --strip-debug -o > > > .tmp_vmlinux.kallsyms1 --whole-archive vmlinux.a init/version-timestamp.o > > > --no-whole-archive --start-group lib/lib.a --end-group > > > [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/memory.o: in > > > function `tlb_flush_mmu_tlbonly': > > > [mk all 2023-02-17 01:42:28] memory.c:(.text+0x320): undefined reference > > > to `hash__tlb_flush' > > > [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mmu_gather.o: in > > > function `tlb_flush_mmu_tlbonly': > > > [mk all 2023-02-17 01:42:28] mmu_gather.c:(.text+0xe0): undefined > > > reference to `hash__tlb_flush' > > > [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mprotect.o: in > > > function `change_protection': > > > [mk all 2023-02-17 01:42:28] mprotect.c:(.text+0x59c): undefined > > > reference to `hash__tlb_flush' > > > [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/madvise.o: in > > > function `tlb_end_vma.isra.0': > > > [mk all 2023-02-17 01:42:28] madvise.c:(.text+0x1f0): undefined reference > > > to `hash__tlb_flush' > > > [mk all 2023-02-17 01:42:28] make[1]: *** [scripts/Makefile.vmlinux:35: > > > vmlinux] Error 1 > > > [mk all 2023-02-17 01:42:28] make: *** [Makefile:1264: vmlinux] Error 2 > > > > > > The fix is available here : > > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=4302abc628fc0dc08e5855f21bbfaed407a72bc3 > > I can give that patch a try, but on the first glimpse, it won't help: [...] > The patch handles a return-type issue. My above issue is a linkage > issue, the linker cannot find hash__tlb_flush(). Or am I mistaken? I stand corrected: That patch fixes the linker issue. (Build log at http://toolchain.lug-owl.de/laminar/jobs/linux-powerpc-microwatt_defconfig/69) Just ftr: How does this work? MfG, JBG -- signature.asc Description: PGP signature
Re: [PATCH v5 00/10] Add the PowerQUICC audio support using the QMC
On Fri, 17 Feb 2023 21:18:20 +0100 Herve Codina wrote: > On Fri, 17 Feb 2023 19:15:22 + > Mark Brown wrote: > > > On Fri, Feb 17, 2023 at 06:32:03AM +, Christophe Leroy wrote: > > > > > Mark, is that ok for you or do you expect this series to go via soc tree ? > > > > Sure, that sounds good to me. I'll give it another check and > > then assuming everything is fine apply for -rc1. > > Thanks a lot, > Hervé > And note that the v6 series is available. https://lore.kernel.org/linux-kernel/20230217145645.1768659-1-herve.cod...@bootlin.com/ with the v5 feedbacks from Krzysztof taken into account. Hervé -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v2] tools/perf/tests: Change true workload to sleep workload in all metric test for system wide check
Em Wed, Feb 15, 2023 at 08:08:20AM -0800, Ian Rogers escreveu:
> On Wed, Feb 15, 2023 at 1:38 AM Kajol Jain wrote:
> >
> > Testcase stat_all_metrics.sh fails in powerpc:
> >
> > 98: perf all metrics test : FAILED!
> >
> > Logs with verbose:
> >
> > [command]# ./perf test 98 -vv
> > 98: perf all metrics test :
> > --- start ---
> > test child forked, pid 13262
> > Testing BRU_STALL_CPI
> > Testing COMPLETION_STALL_CPI
> >
> > Testing TOTAL_LOCAL_NODE_PUMPS_P23
> > Metric 'TOTAL_LOCAL_NODE_PUMPS_P23' not printed in:
> > Error:
> > Invalid event (hv_24x7/PM_PB_LNS_PUMP23,chip=3/) in per-thread mode, enable
> > system wide with '-a'.
> > Testing TOTAL_LOCAL_NODE_PUMPS_RETRIES_P01
> > Metric 'TOTAL_LOCAL_NODE_PUMPS_RETRIES_P01' not printed in:
> > Error:
> > Invalid event (hv_24x7/PM_PB_RTY_LNS_PUMP01,chip=3/) in per-thread mode,
> > enable system wide with '-a'.
> >
> >
> > Based on above logs, we could see some of the hv-24x7 metric events fails,
> > and logs suggest to run the metric event with -a option.
> > This change happened after the commit a4b8cfcabb1d ("perf stat: Delay metric
> > parsing"), which delayed the metric parsing phase and now before metric
> > parsing
> > phase perf tool identifies, whether target is system-wide or not. With this
> > change, perf_event_open will fails with workload monitoring for uncore
> > events
> > as expected.
> >
> > The perf all metric test case fails as some of the hv-24x7 metric events
> > may need bigger workload with system wide monitoring to get the data.
> > Fix this issue by changing current system wide check from true workload to
> > sleep 0.01 workload.
> >
> > Result with the patch changes in powerpc:
> >
> > 98: perf all metrics test : Ok
> >
> > Reviewed-by: Athira Rajeev
> > Tested-by: Disha Goel
> > Suggested-by: Ian Rogers
> > Signed-off-by: Kajol Jain
>
> Tested-by: Ian Rogers
>
> The mention of a4b8cfcabb1d can be moved to a Fixes tag so that this
> is backported.
Done, thanks, applied.
- Arnaldo
Re: [PATCH] powerpc/perf: Add json metric events to present CPI stall cycles in powerpc
Em Thu, Feb 16, 2023 at 10:10:05AM -0800, Ian Rogers escreveu: > On Wed, Feb 15, 2023 at 10:12 PM Athira Rajeev > wrote: > > > > Power10 Performance Monitoring Unit (PMU) provides events > > to understand stall cycles of different pipeline stages. > > These events along with completed instructions provides > > useful metrics for application tuning. > > > > Patch implements the json changes to collect counter statistics > > to present the high level CPI stall breakdown metrics. New metric > > group is named as "CPI_STALL_RATIO" and this new metric group > > presents these stall metrics: > > - DISPATCHED_CPI ( Dispatch stall cycles per insn ) > > - ISSUE_STALL_CPI ( Issue stall cycles per insn ) > > - EXECUTION_STALL_CPI ( Execution stall cycles per insn ) > > - COMPLETION_STALL_CPI ( Completition stall cycles per insn ) > > > > To avoid multipling of events, PM_RUN_INST_CMPL event has been > > modified to use PMC5(performance monitoring counter5) instead > > of PMC4. This change is needed, since completion stall event > > is using PMC4. > > > > Usage example: > > > > ./perf stat --metric-no-group -M CPI_STALL_RATIO > > > > Performance counter stats for 'workload': > > > > 63,056,817,982 PM_CMPL_STALL# 0.28 > > COMPLETION_STALL_CPI > > 1,743,988,038,896 PM_ISSUE_STALL # 7.73 > > ISSUE_STALL_CPI > >225,597,495,030 PM_RUN_INST_CMPL # 6.18 > > DISPATCHED_CPI > > #37.48 > > EXECUTION_STALL_CPI > > 1,393,916,546,654 PM_DISP_STALL_CYC > > 8,455,376,836,463 PM_EXEC_STALL > > > > "--metric-no-group" is used for forcing PM_RUN_INST_CMPL to be scheduled > > in all group for more accuracy. > > > > Signed-off-by: Athira Rajeev > > Acked-by: Ian Rogers Thanks, applied. - Arnaldo
Re: [PATCH v5 00/10] Add the PowerQUICC audio support using the QMC
On Fri, 17 Feb 2023 19:15:22 + Mark Brown wrote: > On Fri, Feb 17, 2023 at 06:32:03AM +, Christophe Leroy wrote: > > > Mark, is that ok for you or do you expect this series to go via soc tree ? > > Sure, that sounds good to me. I'll give it another check and > then assuming everything is fine apply for -rc1. Thanks a lot, Hervé -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: microwatt_defconfig broken: fined reference to `hash__tlb_flush'
On Fri, 2023-02-17 19:44:27 +, Christophe Leroy
wrote:
>
>
> Le 17/02/2023 à 18:14, Jan-Benedict Glaw a écrit :
> > Hi!
> >
> > My CI builds showed that the microwatt_defconfig broke somewhere between
> > (upstream Linus) 6d796c50f84ca79f1722bb131799e5a5710c4700 (last known good,
> > log
> > at [1]) and 033c40a89f55525139fd5b6342281b09b97d05bf (first known bad, log
> > at
> > [2]) with this:
> >
> > [...]
> > make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-
> > INSTALL_MOD_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig
> >
> > INSTALL_DTBS_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig
> > all
> > [...]
> > [mk all 2023-02-17 01:42:27] + powerpc64le-linux-ld -EL -z noexecstack
> > --no-warn-rwx-segments -Bstatic --build-id=sha1 --orphan-handling=warn
> > --script=./arch/powerpc/kernel/vmlinux.lds --strip-debug -o
> > .tmp_vmlinux.kallsyms1 --whole-archive vmlinux.a init/version-timestamp.o
> > --no-whole-archive --start-group lib/lib.a --end-group
> > [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/memory.o: in function
> > `tlb_flush_mmu_tlbonly':
> > [mk all 2023-02-17 01:42:28] memory.c:(.text+0x320): undefined reference to
> > `hash__tlb_flush'
> > [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mmu_gather.o: in
> > function `tlb_flush_mmu_tlbonly':
> > [mk all 2023-02-17 01:42:28] mmu_gather.c:(.text+0xe0): undefined reference
> > to `hash__tlb_flush'
> > [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mprotect.o: in
> > function `change_protection':
> > [mk all 2023-02-17 01:42:28] mprotect.c:(.text+0x59c): undefined reference
> > to `hash__tlb_flush'
> > [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/madvise.o: in
> > function `tlb_end_vma.isra.0':
> > [mk all 2023-02-17 01:42:28] madvise.c:(.text+0x1f0): undefined reference
> > to `hash__tlb_flush'
> > [mk all 2023-02-17 01:42:28] make[1]: *** [scripts/Makefile.vmlinux:35:
> > vmlinux] Error 1
> > [mk all 2023-02-17 01:42:28] make: *** [Makefile:1264: vmlinux] Error 2
>
>
> The fix is available here :
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=4302abc628fc0dc08e5855f21bbfaed407a72bc3
I can give that patch a try, but on the first glimpse, it won't help:
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h
b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index d5cd16270c5d5..2bbc0fcce04a3 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -97,8 +97,8 @@ static inline void tlb_flush(struct mmu_gather *tlb)
{
if (radix_enabled())
radix__tlb_flush(tlb);
-
- return hash__tlb_flush(tlb);
+ else
+ hash__tlb_flush(tlb);
}
#ifdef CONFIG_SMP
The patch handles a return-type issue. My above issue is a linkage
issue, the linker cannot find hash__tlb_flush(). Or am I mistaken?
MfG, JBG
--
signature.asc
Description: PGP signature
Re: microwatt_defconfig broken: fined reference to `hash__tlb_flush'
Le 17/02/2023 à 18:14, Jan-Benedict Glaw a écrit :
> Hi!
>
> My CI builds showed that the microwatt_defconfig broke somewhere between
> (upstream Linus) 6d796c50f84ca79f1722bb131799e5a5710c4700 (last known good,
> log
> at [1]) and 033c40a89f55525139fd5b6342281b09b97d05bf (first known bad, log at
> [2]) with this:
>
> [...]
> make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-
> INSTALL_MOD_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig
>
> INSTALL_DTBS_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig
> all
> [...]
> [mk all 2023-02-17 01:42:27] + powerpc64le-linux-ld -EL -z noexecstack
> --no-warn-rwx-segments -Bstatic --build-id=sha1 --orphan-handling=warn
> --script=./arch/powerpc/kernel/vmlinux.lds --strip-debug -o
> .tmp_vmlinux.kallsyms1 --whole-archive vmlinux.a init/version-timestamp.o
> --no-whole-archive --start-group lib/lib.a --end-group
> [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/memory.o: in function
> `tlb_flush_mmu_tlbonly':
> [mk all 2023-02-17 01:42:28] memory.c:(.text+0x320): undefined reference to
> `hash__tlb_flush'
> [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mmu_gather.o: in
> function `tlb_flush_mmu_tlbonly':
> [mk all 2023-02-17 01:42:28] mmu_gather.c:(.text+0xe0): undefined reference
> to `hash__tlb_flush'
> [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mprotect.o: in function
> `change_protection':
> [mk all 2023-02-17 01:42:28] mprotect.c:(.text+0x59c): undefined reference to
> `hash__tlb_flush'
> [mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/madvise.o: in function
> `tlb_end_vma.isra.0':
> [mk all 2023-02-17 01:42:28] madvise.c:(.text+0x1f0): undefined reference to
> `hash__tlb_flush'
> [mk all 2023-02-17 01:42:28] make[1]: *** [scripts/Makefile.vmlinux:35:
> vmlinux] Error 1
> [mk all 2023-02-17 01:42:28] make: *** [Makefile:1264: vmlinux] Error 2
The fix is available here :
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=4302abc628fc0dc08e5855f21bbfaed407a72bc3
>
>
> It's not yet bisected fully, but I guess it was caused while trying to
> fix a missing tlb flush:
>
> commit 1665c027afb225882a5a0b014c45e84290b826c2
> Author: Michael Ellerman
> Date: Tue Jan 31 22:14:07 2023 +1100
>
> powerpc/64s: Reconnect tlb_flush() to hash__tlb_flush()
>
> Commit baf1ed24b27d ("powerpc/mm: Remove empty hash__ functions")
> removed some empty hash MMU flushing routines, but got a bit overeager
> and also removed the call to hash__tlb_flush() from tlb_flush().
>
> In regular use this doesn't lead to any noticable breakage, which is a
> little concerning. Presumably there are flushes happening via other
> paths such as arch_leave_lazy_mmu_mode(), and/or a bit of luck.
>
> Fix it by reinstating the call to hash__tlb_flush().
>
> Fixes: baf1ed24b27d ("powerpc/mm: Remove empty hash__ functions")
> Signed-off-by: Michael Ellerman
> Link:
> https://lore.kernel.org/r/2023013407.806770-1-...@ellerman.id.au
>
> MfG, JBG
>
>
> [1]
> http://toolchain.lug-owl.de/laminar/jobs/linux-powerpc-microwatt_defconfig/27
> [2]
> http://toolchain.lug-owl.de/laminar/jobs/linux-powerpc-microwatt_defconfig/28
Re: [PATCH v5 00/10] Add the PowerQUICC audio support using the QMC
On Fri, Feb 17, 2023 at 06:32:03AM +, Christophe Leroy wrote: > Mark, is that ok for you or do you expect this series to go via soc tree ? Sure, that sounds good to me. I'll give it another check and then assuming everything is fine apply for -rc1. signature.asc Description: PGP signature
Re: [PATCH v3 26/35] mm: fall back to mmap_lock if vma->anon_vma is not yet set
On Fri, Feb 17, 2023 at 08:13:01AM -0800, Suren Baghdasaryan wrote: > On Fri, Feb 17, 2023 at 2:21 AM Hyeonggon Yoo <42.hye...@gmail.com> wrote: > > > > On Fri, Feb 17, 2023 at 11:15 AM Suren Baghdasaryan > > wrote: > > > > > > On Thu, Feb 16, 2023 at 11:43 AM Suren Baghdasaryan > > > wrote: > > > > > > > > On Thu, Feb 16, 2023 at 7:44 AM Matthew Wilcox > > > > wrote: > > > > > > > > > > On Wed, Feb 15, 2023 at 09:17:41PM -0800, Suren Baghdasaryan wrote: > > > > > > When vma->anon_vma is not set, page fault handler will set it by > > > > > > either > > > > > > reusing anon_vma of an adjacent VMA if VMAs are compatible or by > > > > > > allocating a new one. find_mergeable_anon_vma() walks VMA tree to > > > > > > find > > > > > > a compatible adjacent VMA and that requires not only the faulting > > > > > > VMA > > > > > > to be stable but also the tree structure and other VMAs inside that > > > > > > tree. > > > > > > Therefore locking just the faulting VMA is not enough for this > > > > > > search. > > > > > > Fall back to taking mmap_lock when vma->anon_vma is not set. This > > > > > > situation happens only on the first page fault and should not affect > > > > > > overall performance. > > > > > > > > > > I think I asked this before, but don't remember getting an aswer. > > > > > Why do we defer setting anon_vma to the first fault? Why don't we > > > > > set it up at mmap time? > > > > > > > > Yeah, I remember that conversation Matthew and I could not find the > > > > definitive answer at the time. I'll look into that again or maybe > > > > someone can answer it here. > > > > > > After looking into it again I'm still under the impression that > > > vma->anon_vma is populated lazily (during the first page fault rather > > > than at mmap time) to avoid doing extra work for areas which are never > > > faulted. Though I might be missing some important detail here. > > > > I think this is because the kernel cannot merge VMAs that have > > different anon_vmas? > > > > Enabling lazy population of anon_vma could potentially increase the > > chances of merging VMAs. > > Hmm. Do you have a clear explanation why merging chances increase this > way? A couple of possibilities I can think of would be: > 1. If after mmap'ing a VMA and before faulting the first page into it > we often change something that affects anon_vma_compatible() decision, > like vm_policy; > 2. When mmap'ing VMAs we do not map them consecutively but the final > arrangement is actually contiguous. > > Don't think either of those cases would be very representative of a > usual case but maybe I'm wrong or there is another reason? Ok. I agree it does not represent common cases. Hmm then I wonder how it went from the initial approach of "allocate anon_vma objects only via fork()" [1] to "populate anon_vma at page faults". [2] [3] Maybe Hugh, Andrea or Andrew have opinions? [1] anon_vma RFC2, lore.kernel.org https://lore.kernel.org/lkml/20040311065254.GT30940@dualathlon.random [2] The status of object-based reverse mapping, LWN.net https://lwn.net/Articles/85908 [3] rmap 39 add anon_vma rmap https://gitlab.com/hyeyoo/linux-historical/-/commit/8aa3448cabdfca146aa3fd36e852d0209fb2276a > > > > > > > In the end rather than changing that logic I decided to skip > > > > vma->anon_vma==NULL cases because I measured them being less than > > > > 0.01% of all page faults, so ROI from changing that would be quite > > > > low. But I agree that the logic is weird and maybe we can improve > > > > that. I will have to review that again when I'm working on eliminating > > > > all these special cases we skip, like swap/userfaults/etc. > > > > -- > > To unsubscribe from this group and stop receiving emails from it, send an > > email to kernel-team+unsubscr...@android.com. > >
microwatt_defconfig broken: fined reference to `hash__tlb_flush'
Hi!
My CI builds showed that the microwatt_defconfig broke somewhere between
(upstream Linus) 6d796c50f84ca79f1722bb131799e5a5710c4700 (last known good, log
at [1]) and 033c40a89f55525139fd5b6342281b09b97d05bf (first known bad, log at
[2]) with this:
[...]
make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-
INSTALL_MOD_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig
INSTALL_DTBS_PATH=/var/lib/laminar/run/linux-powerpc-microwatt_defconfig/28/linux-powerpc-microwatt_defconfig
all
[...]
[mk all 2023-02-17 01:42:27] + powerpc64le-linux-ld -EL -z noexecstack
--no-warn-rwx-segments -Bstatic --build-id=sha1 --orphan-handling=warn
--script=./arch/powerpc/kernel/vmlinux.lds --strip-debug -o
.tmp_vmlinux.kallsyms1 --whole-archive vmlinux.a init/version-timestamp.o
--no-whole-archive --start-group lib/lib.a --end-group
[mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/memory.o: in function
`tlb_flush_mmu_tlbonly':
[mk all 2023-02-17 01:42:28] memory.c:(.text+0x320): undefined reference to
`hash__tlb_flush'
[mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mmu_gather.o: in function
`tlb_flush_mmu_tlbonly':
[mk all 2023-02-17 01:42:28] mmu_gather.c:(.text+0xe0): undefined reference to
`hash__tlb_flush'
[mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/mprotect.o: in function
`change_protection':
[mk all 2023-02-17 01:42:28] mprotect.c:(.text+0x59c): undefined reference to
`hash__tlb_flush'
[mk all 2023-02-17 01:42:28] powerpc64le-linux-ld: mm/madvise.o: in function
`tlb_end_vma.isra.0':
[mk all 2023-02-17 01:42:28] madvise.c:(.text+0x1f0): undefined reference to
`hash__tlb_flush'
[mk all 2023-02-17 01:42:28] make[1]: *** [scripts/Makefile.vmlinux:35:
vmlinux] Error 1
[mk all 2023-02-17 01:42:28] make: *** [Makefile:1264: vmlinux] Error 2
It's not yet bisected fully, but I guess it was caused while trying to
fix a missing tlb flush:
commit 1665c027afb225882a5a0b014c45e84290b826c2
Author: Michael Ellerman
Date: Tue Jan 31 22:14:07 2023 +1100
powerpc/64s: Reconnect tlb_flush() to hash__tlb_flush()
Commit baf1ed24b27d ("powerpc/mm: Remove empty hash__ functions")
removed some empty hash MMU flushing routines, but got a bit overeager
and also removed the call to hash__tlb_flush() from tlb_flush().
In regular use this doesn't lead to any noticable breakage, which is a
little concerning. Presumably there are flushes happening via other
paths such as arch_leave_lazy_mmu_mode(), and/or a bit of luck.
Fix it by reinstating the call to hash__tlb_flush().
Fixes: baf1ed24b27d ("powerpc/mm: Remove empty hash__ functions")
Signed-off-by: Michael Ellerman
Link: https://lore.kernel.org/r/2023013407.806770-1-...@ellerman.id.au
MfG, JBG
[1]
http://toolchain.lug-owl.de/laminar/jobs/linux-powerpc-microwatt_defconfig/27
[2]
http://toolchain.lug-owl.de/laminar/jobs/linux-powerpc-microwatt_defconfig/28
--
signature.asc
Description: PGP signature
Re: [PATCH v6 10/10] MAINTAINERS: add the Freescale QMC audio entry
Le 17/02/2023 à 15:56, Herve Codina a écrit : > After contributing the component, add myself as the maintainer > for the Freescale QMC audio ASoC component. > > Signed-off-by: Herve Codina Reviewed-by: Christophe Leroy > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 47eca5b06cce..4553e5a30e9e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8440,6 +8440,14 @@ F: sound/soc/fsl/fsl* > F: sound/soc/fsl/imx* > F: sound/soc/fsl/mpc8610_hpcd.c > > +FREESCALE SOC SOUND QMC DRIVER > +M: Herve Codina > +L: alsa-de...@alsa-project.org (moderated for non-subscribers) > +L: linuxppc-dev@lists.ozlabs.org > +S: Maintained > +F: Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml > +F: sound/soc/fsl/fsl_qmc_audio.c > + > FREESCALE USB PERIPHERAL DRIVERS > M: Li Yang > L: linux-...@vger.kernel.org
Re: [PATCH v6 09/10] ASoC: fsl: Add support for QMC audio
Le 17/02/2023 à 15:56, Herve Codina a écrit :
> The QMC audio is an ASoC component which provides DAIs
> that use the QMC (QUICC Multichannel Controller) to transfer
> the audio data.
>
> It provides as many DAIs as the number of QMC channels it
> references.
>
> Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
Tested-by: Christophe Leroy
> ---
> sound/soc/fsl/Kconfig | 9 +
> sound/soc/fsl/Makefile| 2 +
> sound/soc/fsl/fsl_qmc_audio.c | 735 ++
> 3 files changed, 746 insertions(+)
> create mode 100644 sound/soc/fsl/fsl_qmc_audio.c
>
> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index 614eceda6b9e..17db29c25d96 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -172,6 +172,15 @@ config SND_MPC52xx_DMA
> config SND_SOC_POWERPC_DMA
> tristate
>
> +config SND_SOC_POWERPC_QMC_AUDIO
> + tristate "QMC ALSA SoC support"
> + depends on CPM_QMC
> + help
> + ALSA SoC Audio support using the Freescale QUICC Multichannel
> + Controller (QMC).
> + Say Y or M if you want to add support for SoC audio using Freescale
> + QMC.
> +
> comment "SoC Audio support for Freescale PPC boards:"
>
> config SND_SOC_MPC8610_HPCD
> diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
> index b54beb1a66fa..8db7e97d0bd5 100644
> --- a/sound/soc/fsl/Makefile
> +++ b/sound/soc/fsl/Makefile
> @@ -28,6 +28,7 @@ snd-soc-fsl-easrc-objs := fsl_easrc.o
> snd-soc-fsl-xcvr-objs := fsl_xcvr.o
> snd-soc-fsl-aud2htx-objs := fsl_aud2htx.o
> snd-soc-fsl-rpmsg-objs := fsl_rpmsg.o
> +snd-soc-fsl-qmc-audio-objs := fsl_qmc_audio.o
>
> obj-$(CONFIG_SND_SOC_FSL_AUDMIX) += snd-soc-fsl-audmix.o
> obj-$(CONFIG_SND_SOC_FSL_ASOC_CARD) += snd-soc-fsl-asoc-card.o
> @@ -44,6 +45,7 @@ obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o
> obj-$(CONFIG_SND_SOC_FSL_XCVR) += snd-soc-fsl-xcvr.o
> obj-$(CONFIG_SND_SOC_FSL_AUD2HTX) += snd-soc-fsl-aud2htx.o
> obj-$(CONFIG_SND_SOC_FSL_RPMSG) += snd-soc-fsl-rpmsg.o
> +obj-$(CONFIG_SND_SOC_POWERPC_QMC_AUDIO) += snd-soc-fsl-qmc-audio.o
>
> # MPC5200 Platform Support
> obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
> diff --git a/sound/soc/fsl/fsl_qmc_audio.c b/sound/soc/fsl/fsl_qmc_audio.c
> new file mode 100644
> index ..7cbb8e4758cc
> --- /dev/null
> +++ b/sound/soc/fsl/fsl_qmc_audio.c
> @@ -0,0 +1,735 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ALSA SoC using the QUICC Multichannel Controller (QMC)
> + *
> + * Copyright 2022 CS GROUP France
> + *
> + * Author: Herve Codina
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct qmc_dai {
> + char *name;
> + int id;
> + struct device *dev;
> + struct qmc_chan *qmc_chan;
> + unsigned int nb_tx_ts;
> + unsigned int nb_rx_ts;
> +};
> +
> +struct qmc_audio {
> + struct device *dev;
> + unsigned int num_dais;
> + struct qmc_dai *dais;
> + struct snd_soc_dai_driver *dai_drivers;
> +};
> +
> +struct qmc_dai_prtd {
> + struct qmc_dai *qmc_dai;
> + dma_addr_t dma_buffer_start;
> + dma_addr_t period_ptr_submitted;
> + dma_addr_t period_ptr_ended;
> + dma_addr_t dma_buffer_end;
> + size_t period_size;
> + struct snd_pcm_substream *substream;
> +};
> +
> +static int qmc_audio_pcm_construct(struct snd_soc_component *component,
> +struct snd_soc_pcm_runtime *rtd)
> +{
> + struct snd_card *card = rtd->card->snd_card;
> + int ret;
> +
> + ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
> +
> + snd_pcm_set_managed_buffer_all(rtd->pcm, SNDRV_DMA_TYPE_DEV, card->dev,
> +64*1024, 64*1024);
> + return 0;
> +}
> +
> +static int qmc_audio_pcm_hw_params(struct snd_soc_component *component,
> +struct snd_pcm_substream *substream,
> +struct snd_pcm_hw_params *params)
> +{
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + struct qmc_dai_prtd *prtd = substream->runtime->private_data;
> +
> + prtd->dma_buffer_start = runtime->dma_addr;
> + prtd->dma_buffer_end = runtime->dma_addr + params_buffer_bytes(params);
> + prtd->period_size = params_period_bytes(params);
> + prtd->period_ptr_submitted = prtd->dma_buffer_start;
> + prtd->period_ptr_ended = prtd->dma_buffer_start;
> + prtd->substream = substream;
> +
> + return 0;
> +}
> +
> +static void qmc_audio_pcm_write_complete(void *context)
> +{
> + struct qmc_dai_prtd *prtd = context;
> + int ret;
> +
> + prtd->period_ptr_ended += prtd->period_size;
> + if (prtd->period_ptr_ended >= prtd->dma_buffer_end)
> + prtd->period_ptr_ended = prtd->dma_buffer_start;
> +
> + prtd->period_ptr_submitted
Re: [PATCH v6 08/10] dt-bindings: sound: Add support for QMC audio
Le 17/02/2023 à 15:56, Herve Codina a écrit :
> The QMC (QUICC mutichannel controller) is a controller
> present in some PowerQUICC SoC such as MPC885.
> The QMC audio is an ASoC component that uses the QMC
> controller to transfer the audio data.
>
> Signed-off-by: Herve Codina
> Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Christophe Leroy
> ---
> .../bindings/sound/fsl,qmc-audio.yaml | 117 ++
> 1 file changed, 117 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
> b/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
> new file mode 100644
> index ..ff5cd9241941
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/fsl,qmc-audio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: QMC audio
> +
> +maintainers:
> + - Herve Codina
> +
> +description: |
> + The QMC audio is an ASoC component which uses QMC (QUICC Multichannel
> + Controller) channels to transfer the audio data.
> + It provides as many DAI as the number of QMC channel used.
> +
> +allOf:
> + - $ref: dai-common.yaml#
> +
> +properties:
> + compatible:
> +const: fsl,qmc-audio
> +
> + '#address-cells':
> +const: 1
> + '#size-cells':
> +const: 0
> + '#sound-dai-cells':
> +const: 1
> +
> +patternProperties:
> + '^dai@([0-9]|[1-5][0-9]|6[0-3])$':
> +description:
> + A DAI managed by this controller
> +type: object
> +
> +properties:
> + reg:
> +minimum: 0
> +maximum: 63
> +description:
> + The DAI number
> +
> + fsl,qmc-chan:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +items:
> + - items:
> + - description: phandle to QMC node
> + - description: Channel number
> +description:
> + Should be a phandle/number pair. The phandle to QMC node and the
> QMC
> + channel to use for this DAI.
> +
> +required:
> + - reg
> + - fsl,qmc-chan
> +
> +required:
> + - compatible
> + - '#address-cells'
> + - '#size-cells'
> + - '#sound-dai-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +audio_controller: audio-controller {
> +compatible = "fsl,qmc-audio";
> +#address-cells = <1>;
> +#size-cells = <0>;
> +#sound-dai-cells = <1>;
> +dai@16 {
> +reg = <16>;
> +fsl,qmc-chan = < 16>;
> +};
> +dai@17 {
> +reg = <17>;
> +fsl,qmc-chan = < 17>;
> +};
> +};
> +
> +sound {
> +compatible = "simple-audio-card";
> +#address-cells = <1>;
> +#size-cells = <0>;
> +simple-audio-card,dai-link@0 {
> +reg = <0>;
> +format = "dsp_b";
> +cpu {
> +sound-dai = <_controller 16>;
> +};
> +codec {
> +sound-dai = <>;
> +dai-tdm-slot-num = <4>;
> +dai-tdm-slot-width = <8>;
> +/* TS 3, 5, 7, 9 */
> +dai-tdm-slot-tx-mask = <0 0 0 1 0 1 0 1 0 1>;
> +dai-tdm-slot-rx-mask = <0 0 0 1 0 1 0 1 0 1>;
> +};
> +};
> +simple-audio-card,dai-link@1 {
> +reg = <1>;
> +format = "dsp_b";
> +cpu {
> +sound-dai = <_controller 17>;
> +};
> +codec {
> +sound-dai = <>;
> +dai-tdm-slot-num = <4>;
> +dai-tdm-slot-width = <8>;
> +/* TS 2, 4, 6, 8 */
> +dai-tdm-slot-tx-mask = <0 0 1 0 1 0 1 0 1>;
> +dai-tdm-slot-rx-mask = <0 0 1 0 1 0 1 0 1>;
> +};
> +};
> +};
Re: [PATCH v6 07/10] MAINTAINERS: add the Freescale QMC controller entry
Le 17/02/2023 à 15:56, Herve Codina a écrit : > After contributing the driver, add myself as the maintainer > for the Freescale QMC controller. > > Signed-off-by: Herve Codina Reviewed-by: Christophe Leroy > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 097a80d6623b..47eca5b06cce 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8372,6 +8372,14 @@ S: Maintained > F: drivers/soc/fsl/qe/ > F: include/soc/fsl/qe/ > > +FREESCALE QUICC ENGINE QMC DRIVER > +M: Herve Codina > +L: linuxppc-dev@lists.ozlabs.org > +S: Maintained > +F: Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml > +F: drivers/soc/fsl/qe/qmc.c > +F: include/soc/fsl/qe/qmc.h > + > FREESCALE QUICC ENGINE TSA DRIVER > M: Herve Codina > L: linuxppc-dev@lists.ozlabs.org
Re: [PATCH v6 06/10] soc: fsl: cpm1: Add support for QMC
Le 17/02/2023 à 15:56, Herve Codina a écrit : > The QMC (QUICC Multichannel Controller) emulates up to 64 > channels within one serial controller using the same TDM > physical interface routed from the TSA. > > It is available in some PowerQUICC SoC such as the > MPC885 or MPC866. > > It is also available on some Quicc Engine SoCs. > This current version support CPM1 SoCs only and some > enhancement are needed to support Quicc Engine SoCs. > > Signed-off-by: Herve Codina > Acked-by: Li Yang Reviewed-by: Christophe Leroy > --- > drivers/soc/fsl/qe/Kconfig | 12 + > drivers/soc/fsl/qe/Makefile |1 + > drivers/soc/fsl/qe/qmc.c| 1533 +++ > include/soc/fsl/qe/qmc.h| 71 ++ > 4 files changed, 1617 insertions(+) > create mode 100644 drivers/soc/fsl/qe/qmc.c > create mode 100644 include/soc/fsl/qe/qmc.h > > diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig > index b0088495c323..f90cfdf0c763 100644 > --- a/drivers/soc/fsl/qe/Kconfig > +++ b/drivers/soc/fsl/qe/Kconfig > @@ -44,6 +44,18 @@ config CPM_TSA > This option enables support for this > controller > > +config CPM_QMC > + tristate "CPM QMC support" > + depends on OF && HAS_IOMEM > + depends on CPM1 || (SOC_FSL && COMPILE_TEST) > + depends on CPM_TSA > + help > + Freescale CPM QUICC Multichannel Controller > + (QMC) > + > + This option enables support for this > + controller > + > config QE_TDM > bool > default y if FSL_UCC_HDLC > diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile > index 45c961acc81b..ec8506e13113 100644 > --- a/drivers/soc/fsl/qe/Makefile > +++ b/drivers/soc/fsl/qe/Makefile > @@ -5,6 +5,7 @@ > obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o > obj-$(CONFIG_CPM) += qe_common.o > obj-$(CONFIG_CPM_TSA) += tsa.o > +obj-$(CONFIG_CPM_QMC)+= qmc.o > obj-$(CONFIG_UCC) += ucc.o > obj-$(CONFIG_UCC_SLOW) += ucc_slow.o > obj-$(CONFIG_UCC_FAST) += ucc_fast.o > diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c > new file mode 100644 > index ..cfa7207353e0 > --- /dev/null > +++ b/drivers/soc/fsl/qe/qmc.c > @@ -0,0 +1,1533 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * QMC driver > + * > + * Copyright 2022 CS GROUP France > + * > + * Author: Herve Codina > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "tsa.h" > + > +/* SCC general mode register high (32 bits) */ > +#define SCC_GSMRL0x00 > +#define SCC_GSMRL_ENR(1 << 5) > +#define SCC_GSMRL_ENT(1 << 4) > +#define SCC_GSMRL_MODE_QMC (0x0A << 0) > + > +/* SCC general mode register low (32 bits) */ > +#define SCC_GSMRH0x04 > +#define SCC_GSMRH_CTSS (1 << 7) > +#define SCC_GSMRH_CDS (1 << 8) > +#define SCC_GSMRH_CTSP (1 << 9) > +#define SCC_GSMRH_CDP (1 << 10) > + > +/* SCC event register (16 bits) */ > +#define SCC_SCCE 0x10 > +#define SCC_SCCE_IQOV (1 << 3) > +#define SCC_SCCE_GINT (1 << 2) > +#define SCC_SCCE_GUN (1 << 1) > +#define SCC_SCCE_GOV (1 << 0) > + > +/* SCC mask register (16 bits) */ > +#define SCC_SCCM 0x14 > +/* Multichannel base pointer (32 bits) */ > +#define QMC_GBL_MCBASE 0x00 > +/* Multichannel controller state (16 bits) */ > +#define QMC_GBL_QMCSTATE 0x04 > +/* Maximum receive buffer length (16 bits) */ > +#define QMC_GBL_MRBLR0x06 > +/* Tx time-slot assignment table pointer (16 bits) */ > +#define QMC_GBL_TX_S_PTR 0x08 > +/* Rx pointer (16 bits) */ > +#define QMC_GBL_RXPTR0x0A > +/* Global receive frame threshold (16 bits) */ > +#define QMC_GBL_GRFTHR 0x0C > +/* Global receive frame count (16 bits) */ > +#define QMC_GBL_GRFCNT 0x0E > +/* Multichannel interrupt base address (32 bits) */ > +#define QMC_GBL_INTBASE 0x10 > +/* Multichannel interrupt pointer (32 bits) */ > +#define QMC_GBL_INTPTR 0x14 > +/* Rx time-slot assignment table pointer (16 bits) */ > +#define QMC_GBL_RX_S_PTR 0x18 > +/* Tx pointer (16 bits) */ > +#define QMC_GBL_TXPTR0x1A > +/* CRC constant (32 bits) */ > +#define QMC_GBL_C_MASK32 0x1C > +/* Time slot assignment table Rx (32 x 16 bits) */ > +#define QMC_GBL_TSATRX 0x20 > +/* Time slot assignment table Tx (32 x 16 bits) */ > +#define QMC_GBL_TSATTX 0x60 > +/* CRC constant (16 bits) */ > +#define QMC_GBL_C_MASK16 0xA0 > + > +/* TSA entry (16bit entry in TSATRX and TSATTX) */ > +#define QMC_TSA_VALID(1 << 15) > +#define QMC_TSA_WRAP (1 << 14) > +#define QMC_TSA_MASK (0x303F) > +#define QMC_TSA_CHANNEL(x) ((x) << 6) > + >
Re: [PATCH v6 05/10] dt-bindings: soc: fsl: cpm_qe: Add QMC controller
Le 17/02/2023 à 15:56, Herve Codina a écrit :
> Add support for the QMC (QUICC Multichannel Controller)
> available in some PowerQUICC SoC such as MPC885 or MPC866.
>
> Signed-off-by: Herve Codina
> Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Christophe Leroy
> ---
> .../soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml | 172 ++
> 1 file changed, 172 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
> b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
> new file mode 100644
> index ..4ebbc7d52981
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
> @@ -0,0 +1,172 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PowerQUICC CPM QUICC Multichannel Controller (QMC)
> +
> +maintainers:
> + - Herve Codina
> +
> +description:
> + The QMC (QUICC Multichannel Controller) emulates up to 64 channels within
> one
> + serial controller using the same TDM physical interface routed from TSA.
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - fsl,mpc885-scc-qmc
> + - fsl,mpc866-scc-qmc
> + - const: fsl,cpm1-scc-qmc
> +
> + reg:
> +items:
> + - description: SCC (Serial communication controller) register base
> + - description: SCC parameter ram base
> + - description: Dual port ram base
> +
> + reg-names:
> +items:
> + - const: scc_regs
> + - const: scc_pram
> + - const: dpram
> +
> + interrupts:
> +maxItems: 1
> +description: SCC interrupt line in the CPM interrupt controller
> +
> + fsl,tsa-serial:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +items:
> + - items:
> + - description: phandle to TSA node
> + - enum: [1, 2, 3]
> +description: |
> + TSA serial interface (dt-bindings/soc/cpm1-fsl,tsa.h defines
> these
> + values)
> + - 1: SCC2
> + - 2: SCC3
> + - 3: SCC4
> +description:
> + Should be a phandle/number pair. The phandle to TSA node and the TSA
> + serial interface to use.
> +
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + '#fsl,chan-cells':
> +$ref: /schemas/types.yaml#/definitions/uint32
> +const: 1
> +description:
> + QMC consumers that use a phandle to QMC need to pass the channel number
> + with this phandle.
> + For instance "fsl,qmc-chan = < 16>;".
> +
> +patternProperties:
> + '^channel@([0-9]|[1-5][0-9]|6[0-3])$':
> +description:
> + A channel managed by this controller
> +type: object
> +
> +properties:
> + reg:
> +minimum: 0
> +maximum: 63
> +description:
> + The channel number
> +
> + fsl,operational-mode:
> +$ref: /schemas/types.yaml#/definitions/string
> +enum: [transparent, hdlc]
> +default: transparent
> +description: |
> + The channel operational mode
> +- hdlc: The channel handles HDLC frames
> +- transparent: The channel handles raw data without any
> processing
> +
> + fsl,reverse-data:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description:
> + The bit order as seen on the channels is reversed,
> + transmitting/receiving the MSB of each octet first.
> + This flag is used only in 'transparent' mode.
> +
> + fsl,tx-ts-mask:
> +$ref: /schemas/types.yaml#/definitions/uint64
> +description:
> + Channel assigned Tx time-slots within the Tx time-slots routed by
> the
> + TSA to this cell.
> +
> + fsl,rx-ts-mask:
> +$ref: /schemas/types.yaml#/definitions/uint64
> +description:
> + Channel assigned Rx time-slots within the Rx time-slots routed by
> the
> + TSA to this cell.
> +
> +required:
> + - reg
> + - fsl,tx-ts-mask
> + - fsl,rx-ts-mask
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - fsl,tsa-serial
> + - '#address-cells'
> + - '#size-cells'
> + - '#fsl,chan-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +qmc@a60 {
> +compatible = "fsl,mpc885-scc-qmc", "fsl,cpm1-scc-qmc";
> +reg = <0xa60 0x20>,
> + <0x3f00 0xc0>,
> + <0x2000 0x1000>;
> +reg-names = "scc_regs", "scc_pram", "dpram";
> +interrupts = <27>;
> +interrupt-parent = <_PIC>;
> +
> +#address-cells = <1>;
> +#size-cells = <0>;
> +#fsl,chan-cells = <1>;
> +
>
Re: [PATCH v6 03/10] MAINTAINERS: add the Freescale TSA controller entry
Le 17/02/2023 à 15:56, Herve Codina a écrit : > After contributing the driver, add myself as the maintainer > for the Freescale TSA controller. > > Signed-off-by: Herve Codina Reviewed-by: Christophe Leroy > --- > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7f86d02cb427..097a80d6623b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8372,6 +8372,15 @@ S: Maintained > F: drivers/soc/fsl/qe/ > F: include/soc/fsl/qe/ > > +FREESCALE QUICC ENGINE TSA DRIVER > +M: Herve Codina > +L: linuxppc-dev@lists.ozlabs.org > +S: Maintained > +F: Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml > +F: drivers/soc/fsl/qe/tsa.c > +F: drivers/soc/fsl/qe/tsa.h > +F: include/dt-bindings/soc/cpm1-fsl,tsa.h > + > FREESCALE QUICC ENGINE UCC ETHERNET DRIVER > M: Li Yang > L: net...@vger.kernel.org
Re: [PATCH v6 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller
Le 17/02/2023 à 15:56, Herve Codina a écrit : > Add support for the time slot assigner (TSA) > available in some PowerQUICC SoC such as MPC885 > or MPC866. > > Signed-off-by: Herve Codina Reviewed-by: Christophe Leroy > --- > .../bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml | 215 ++ > include/dt-bindings/soc/cpm1-fsl,tsa.h| 13 ++ > 2 files changed, 228 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml > create mode 100644 include/dt-bindings/soc/cpm1-fsl,tsa.h > > diff --git > a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml > b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml > new file mode 100644 > index ..332e902bcc21 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml > @@ -0,0 +1,215 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: PowerQUICC CPM Time-slot assigner (TSA) controller > + > +maintainers: > + - Herve Codina > + > +description: > + The TSA is the time-slot assigner that can be found on some PowerQUICC SoC. > + Its purpose is to route some TDM time-slots to other internal serial > + controllers. > + > +properties: > + compatible: > +items: > + - enum: > + - fsl,mpc885-tsa > + - fsl,mpc866-tsa > + - const: fsl,cpm1-tsa > + > + reg: > +items: > + - description: SI (Serial Interface) register base > + - description: SI RAM base > + > + reg-names: > +items: > + - const: si_regs > + - const: si_ram > + > + '#address-cells': > +const: 1 > + > + '#size-cells': > +const: 0 > + > + '#fsl,serial-cells': > +$ref: /schemas/types.yaml#/definitions/uint32 > +const: 1 > +description: > + TSA consumers that use a phandle to TSA need to pass the serial > identifier > + with this phandle (defined in dt-bindings/soc/fsl,tsa.h). > + For instance "fsl,tsa-serial = < FSL_CPM_TSA_SCC4>;". > + > +patternProperties: > + '^tdm@[0-1]$': > +description: > + The TDM managed by this controller > +type: object > + > +additionalProperties: false > + > +properties: > + reg: > +minimum: 0 > +maximum: 1 > +description: > + The TDM number for this TDM, 0 for TDMa and 1 for TDMb > + > + fsl,common-rxtx-pins: > +$ref: /schemas/types.yaml#/definitions/flag > +description: > + The hardware can use four dedicated pins for Tx clock, Tx sync, Rx > + clock and Rx sync or use only two pins, Tx/Rx clock and Tx/Rx sync. > + Without the 'fsl,common-rxtx-pins' property, the four pins are > used. > + With the 'fsl,common-rxtx-pins' property, two pins are used. > + > + clocks: > +minItems: 2 > +items: > + - description: External clock connected to L1RSYNC pin > + - description: External clock connected to L1RCLK pin > + - description: External clock connected to L1TSYNC pin > + - description: External clock connected to L1TCLK pin > + > + clock-names: > +minItems: 2 > +items: > + - const: l1rsync > + - const: l1rclk > + - const: l1tsync > + - const: l1tclk > + > + fsl,rx-frame-sync-delay-bits: > +enum: [0, 1, 2, 3] > +default: 0 > +description: | > + Receive frame sync delay in number of bits. > + Indicates the delay between the Rx sync and the first bit of the Rx > + frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay. > + > + fsl,tx-frame-sync-delay-bits: > +enum: [0, 1, 2, 3] > +default: 0 > +description: | > + Transmit frame sync delay in number of bits. > + Indicates the delay between the Tx sync and the first bit of the Tx > + frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay. > + > + fsl,clock-falling-edge: > +$ref: /schemas/types.yaml#/definitions/flag > +description: > + Data is sent on falling edge of the clock (and received on the > rising > + edge). If 'clock-falling-edge' is not present, data is sent on the > + rising edge (and received on the falling edge). > + > + fsl,fsync-rising-edge: > +$ref: /schemas/types.yaml#/definitions/flag > +description: > + Frame sync pulses are sampled with the rising edge of the channel > + clock. If 'fsync-rising-edge' is not present, pulses are sampled > with > + the falling edge. > + > + fsl,double-speed-clock: > +$ref: /schemas/types.yaml#/definitions/flag > +description: > + The channel clock is twice the data rate. > + > +
Re: [PATCH mm-unstable v1 2/5] kvm/x86: add kvm_arch_test_clear_young()
On Thu, Feb 16, 2023, Yu Zhao wrote:
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 6aaae18f1854..d2995c9e8f07 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1367,6 +1367,12 @@ struct kvm_arch {
>* the MMU lock in read mode + the tdp_mmu_pages_lock or
>* the MMU lock in write mode
>*
> + * kvm_arch_test_clear_young() is a special case. It relies on two
No, it's not. The TDP MMU already employs on RCU and CMPXCHG. Just drop the
entire comment.
> + * techniques, RCU and cmpxchg, to safely test and clear the accessed
> + * bit without taking the MMU lock. The former protects KVM page tables
> + * from being freed while the latter clears the accessed bit atomically
> + * against both the hardware and other software page table walkers.
> + *
>* Roots will remain in the list until their tdp_mmu_root_count
>* drops to zero, at which point the thread that decremented the
>* count to zero should removed the root from the list and clean
> @@ -2171,4 +2177,25 @@ int memslot_rmap_alloc(struct kvm_memory_slot *slot,
> unsigned long npages);
>KVM_X86_QUIRK_FIX_HYPERCALL_INSN | \
>KVM_X86_QUIRK_MWAIT_NEVER_UD_FAULTS)
>
> +extern u64 __read_mostly shadow_accessed_mask;
> +
> +/*
> + * Returns true if A/D bits are supported in hardware and are enabled by KVM.
> + * When enabled, KVM uses A/D bits for all non-nested MMUs. Because L1 can
> + * disable A/D bits in EPTP12, SP and SPTE variants are needed to handle the
> + * scenario where KVM is using A/D bits for L1, but not L2.
> + */
> +static inline bool kvm_ad_enabled(void)
> +{
> + return shadow_accessed_mask;
> +}
Absolutely not. This information is not getting directly exposed outside of
KVM.
> +
> +/* see the comments on the generic kvm_arch_has_test_clear_young() */
> +#define kvm_arch_has_test_clear_young kvm_arch_has_test_clear_young
> +static inline bool kvm_arch_has_test_clear_young(void)
> +{
> + return IS_ENABLED(CONFIG_KVM) && IS_ENABLED(CONFIG_X86_64) &&
> +(!IS_REACHABLE(CONFIG_KVM) || (kvm_ad_enabled() && tdp_enabled));
> +}
Pending the justification for why this is KVM-only, I would strongly prefer we
find a way to have the mmu_notifier framework track whether or not any listeners
have a test_clear_young(). E.g. have KVM nullify its hook during module load.
> +
> #endif /* _ASM_X86_KVM_HOST_H */
> diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h
> index 6f54dc9409c9..0dc7fed1f3fd 100644
> --- a/arch/x86/kvm/mmu/spte.h
> +++ b/arch/x86/kvm/mmu/spte.h
> @@ -153,7 +153,6 @@ extern u64 __read_mostly shadow_mmu_writable_mask;
> extern u64 __read_mostly shadow_nx_mask;
> extern u64 __read_mostly shadow_x_mask; /* mutual exclusive with nx_mask */
> extern u64 __read_mostly shadow_user_mask;
> -extern u64 __read_mostly shadow_accessed_mask;
> extern u64 __read_mostly shadow_dirty_mask;
> extern u64 __read_mostly shadow_mmio_value;
> extern u64 __read_mostly shadow_mmio_mask;
> @@ -247,17 +246,6 @@ static inline bool is_shadow_present_pte(u64 pte)
> return !!(pte & SPTE_MMU_PRESENT_MASK);
> }
>
> -/*
> - * Returns true if A/D bits are supported in hardware and are enabled by KVM.
> - * When enabled, KVM uses A/D bits for all non-nested MMUs. Because L1 can
> - * disable A/D bits in EPTP12, SP and SPTE variants are needed to handle the
> - * scenario where KVM is using A/D bits for L1, but not L2.
> - */
> -static inline bool kvm_ad_enabled(void)
> -{
> - return !!shadow_accessed_mask;
> -}
As Oliver said in the ARM patch, _if_ this is justified, please do code movement
in a separate patch.
> -
> static inline bool sp_ad_disabled(struct kvm_mmu_page *sp)
> {
> return sp->role.ad_disabled;
> diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> index d6df38d371a0..9028e09f1aab 100644
> --- a/arch/x86/kvm/mmu/tdp_mmu.c
> +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> @@ -1309,6 +1309,47 @@ bool kvm_tdp_mmu_age_gfn_range(struct kvm *kvm, struct
> kvm_gfn_range *range)
> return kvm_tdp_mmu_handle_gfn(kvm, range, age_gfn_range);
> }
>
> +bool kvm_arch_test_clear_young(struct kvm *kvm, struct kvm_gfn_range *range,
> +gfn_t lsb_gfn, unsigned long *bitmap)
> +{
> + struct kvm_mmu_page *root;
> +
> + if (WARN_ON_ONCE(!kvm_arch_has_test_clear_young()))
> + return false;
> +
> + if (kvm_memslots_have_rmaps(kvm))
This completely disables the API on VMs that have _ever_ run a nested VM. I
doubt
that's the intended behavior.
> + return false;
> +
> + /* see the comments on kvm_arch->tdp_mmu_roots */
> + rcu_read_lock();
> +
> + list_for_each_entry_rcu(root, >arch.tdp_mmu_roots, link) {
> + struct tdp_iter iter;
> +
> + if (kvm_mmu_page_as_id(root) != range->slot->as_id)
> +
Re: [PATCH v6 02/10] soc: fsl: cpm1: Add support for TSA
Le 17/02/2023 à 15:56, Herve Codina a écrit : > The TSA (Time Slot Assigner) purpose is to route some > TDM time-slots to other internal serial controllers. > > It is available in some PowerQUICC SoC such as the > MPC885 or MPC866. > > It is also available on some Quicc Engine SoCs. > This current version support CPM1 SoCs only and some > enhancement are needed to support Quicc Engine SoCs. > > Signed-off-by: Herve Codina > Acked-by: Li Yang Reviewed-by: Christophe Leroy > --- > drivers/soc/fsl/qe/Kconfig | 11 + > drivers/soc/fsl/qe/Makefile | 1 + > drivers/soc/fsl/qe/tsa.c| 846 > drivers/soc/fsl/qe/tsa.h| 42 ++ > 4 files changed, 900 insertions(+) > create mode 100644 drivers/soc/fsl/qe/tsa.c > create mode 100644 drivers/soc/fsl/qe/tsa.h > > diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig > index 357c5800b112..b0088495c323 100644 > --- a/drivers/soc/fsl/qe/Kconfig > +++ b/drivers/soc/fsl/qe/Kconfig > @@ -33,6 +33,17 @@ config UCC > bool > default y if UCC_FAST || UCC_SLOW > > +config CPM_TSA > + tristate "CPM TSA support" > + depends on OF && HAS_IOMEM > + depends on CPM1 || COMPILE_TEST > + help > + Freescale CPM Time Slot Assigner (TSA) > + controller. > + > + This option enables support for this > + controller > + > config QE_TDM > bool > default y if FSL_UCC_HDLC > diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile > index 55a555304f3a..45c961acc81b 100644 > --- a/drivers/soc/fsl/qe/Makefile > +++ b/drivers/soc/fsl/qe/Makefile > @@ -4,6 +4,7 @@ > # > obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o > obj-$(CONFIG_CPM) += qe_common.o > +obj-$(CONFIG_CPM_TSA)+= tsa.o > obj-$(CONFIG_UCC) += ucc.o > obj-$(CONFIG_UCC_SLOW) += ucc_slow.o > obj-$(CONFIG_UCC_FAST) += ucc_fast.o > diff --git a/drivers/soc/fsl/qe/tsa.c b/drivers/soc/fsl/qe/tsa.c > new file mode 100644 > index ..3646153117b3 > --- /dev/null > +++ b/drivers/soc/fsl/qe/tsa.c > @@ -0,0 +1,846 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * TSA driver > + * > + * Copyright 2022 CS GROUP France > + * > + * Author: Herve Codina > + */ > + > +#include "tsa.h" > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > + > +/* TSA SI RAM routing tables entry */ > +#define TSA_SIRAM_ENTRY_LAST (1 << 16) > +#define TSA_SIRAM_ENTRY_BYTE (1 << 17) > +#define TSA_SIRAM_ENTRY_CNT(x) (((x) & 0x0f) << 18) > +#define TSA_SIRAM_ENTRY_CSEL_MASK(0x7 << 22) > +#define TSA_SIRAM_ENTRY_CSEL_NU (0x0 << 22) > +#define TSA_SIRAM_ENTRY_CSEL_SCC2(0x2 << 22) > +#define TSA_SIRAM_ENTRY_CSEL_SCC3(0x3 << 22) > +#define TSA_SIRAM_ENTRY_CSEL_SCC4(0x4 << 22) > +#define TSA_SIRAM_ENTRY_CSEL_SMC1(0x5 << 22) > +#define TSA_SIRAM_ENTRY_CSEL_SMC2(0x6 << 22) > + > +/* SI mode register (32 bits) */ > +#define TSA_SIMODE 0x00 > +#define TSA_SIMODE_SMC20x8000 > +#define TSA_SIMODE_SMC10x8000 > +#define TSA_SIMODE_TDMA(x) ((x) << 0) > +#define TSA_SIMODE_TDMB(x) ((x) << 16) > +#define TSA_SIMODE_TDM_MASK 0x0fff > +#define TSA_SIMODE_TDM_SDM_MASK 0x0c00 > +#define TSA_SIMODE_TDM_SDM_NORM0x > +#define TSA_SIMODE_TDM_SDM_ECHO0x0400 > +#define TSA_SIMODE_TDM_SDM_INTL_LOOP 0x0800 > +#define TSA_SIMODE_TDM_SDM_LOOP_CTRL 0x0c00 > +#define TSA_SIMODE_TDM_RFSD(x) ((x) << 8) > +#define TSA_SIMODE_TDM_DSC 0x0080 > +#define TSA_SIMODE_TDM_CRT 0x0040 > +#define TSA_SIMODE_TDM_STZ 0x0020 > +#define TSA_SIMODE_TDM_CE0x0010 > +#define TSA_SIMODE_TDM_FE0x0008 > +#define TSA_SIMODE_TDM_GM0x0004 > +#define TSA_SIMODE_TDM_TFSD(x) ((x) << 0) > + > +/* SI global mode register (8 bits) */ > +#define TSA_SIGMR0x04 > +#define TSA_SIGMR_ENB(1<<3) > +#define TSA_SIGMR_ENA(1<<2) > +#define TSA_SIGMR_RDM_MASK 0x03 > +#define TSA_SIGMR_RDM_STATIC_TDMA 0x00 > +#define TSA_SIGMR_RDM_DYN_TDMA 0x01 > +#define TSA_SIGMR_RDM_STATIC_TDMAB 0x02 > +#define TSA_SIGMR_RDM_DYN_TDMAB0x03 > + > +/* SI status register (8 bits) */ > +#define TSA_SISTR0x06 > + > +/* SI command register (8 bits) */ > +#define TSA_SICMR0x07 > + > +/* SI clock route register (32 bits) */ > +#define TSA_SICR 0x0C > +#define TSA_SICR_SCC2(x) ((x) << 8) > +#define TSA_SICR_SCC3(x) ((x) << 16) > +#define TSA_SICR_SCC4(x) ((x) << 24) > +#define TSA_SICR_SCC_MASK0x0ff > +#define
Re: [PATCH v3 26/35] mm: fall back to mmap_lock if vma->anon_vma is not yet set
On Fri, Feb 17, 2023 at 2:21 AM Hyeonggon Yoo <42.hye...@gmail.com> wrote: > > On Fri, Feb 17, 2023 at 11:15 AM Suren Baghdasaryan wrote: > > > > On Thu, Feb 16, 2023 at 11:43 AM Suren Baghdasaryan > > wrote: > > > > > > On Thu, Feb 16, 2023 at 7:44 AM Matthew Wilcox > > > wrote: > > > > > > > > On Wed, Feb 15, 2023 at 09:17:41PM -0800, Suren Baghdasaryan wrote: > > > > > When vma->anon_vma is not set, page fault handler will set it by > > > > > either > > > > > reusing anon_vma of an adjacent VMA if VMAs are compatible or by > > > > > allocating a new one. find_mergeable_anon_vma() walks VMA tree to find > > > > > a compatible adjacent VMA and that requires not only the faulting VMA > > > > > to be stable but also the tree structure and other VMAs inside that > > > > > tree. > > > > > Therefore locking just the faulting VMA is not enough for this search. > > > > > Fall back to taking mmap_lock when vma->anon_vma is not set. This > > > > > situation happens only on the first page fault and should not affect > > > > > overall performance. > > > > > > > > I think I asked this before, but don't remember getting an aswer. > > > > Why do we defer setting anon_vma to the first fault? Why don't we > > > > set it up at mmap time? > > > > > > Yeah, I remember that conversation Matthew and I could not find the > > > definitive answer at the time. I'll look into that again or maybe > > > someone can answer it here. > > > > After looking into it again I'm still under the impression that > > vma->anon_vma is populated lazily (during the first page fault rather > > than at mmap time) to avoid doing extra work for areas which are never > > faulted. Though I might be missing some important detail here. > > I think this is because the kernel cannot merge VMAs that have > different anon_vmas? > > Enabling lazy population of anon_vma could potentially increase the > chances of merging VMAs. Hmm. Do you have a clear explanation why merging chances increase this way? A couple of possibilities I can think of would be: 1. If after mmap'ing a VMA and before faulting the first page into it we often change something that affects anon_vma_compatible() decision, like vm_policy; 2. When mmap'ing VMAs we do not map them consecutively but the final arrangement is actually contiguous. Don't think either of those cases would be very representative of a usual case but maybe I'm wrong or there is another reason? > > > > In the end rather than changing that logic I decided to skip > > > vma->anon_vma==NULL cases because I measured them being less than > > > 0.01% of all page faults, so ROI from changing that would be quite > > > low. But I agree that the logic is weird and maybe we can improve > > > that. I will have to review that again when I'm working on eliminating > > > all these special cases we skip, like swap/userfaults/etc. > > -- > To unsubscribe from this group and stop receiving emails from it, send an > email to kernel-team+unsubscr...@android.com. >
Re: [PATCH v3 26/35] mm: fall back to mmap_lock if vma->anon_vma is not yet set
On Fri, Feb 17, 2023 at 8:05 AM Matthew Wilcox wrote: > > On Thu, Feb 16, 2023 at 06:14:59PM -0800, Suren Baghdasaryan wrote: > > On Thu, Feb 16, 2023 at 11:43 AM Suren Baghdasaryan > > wrote: > > > > > > On Thu, Feb 16, 2023 at 7:44 AM Matthew Wilcox > > > wrote: > > > > > > > > On Wed, Feb 15, 2023 at 09:17:41PM -0800, Suren Baghdasaryan wrote: > > > > > When vma->anon_vma is not set, page fault handler will set it by > > > > > either > > > > > reusing anon_vma of an adjacent VMA if VMAs are compatible or by > > > > > allocating a new one. find_mergeable_anon_vma() walks VMA tree to find > > > > > a compatible adjacent VMA and that requires not only the faulting VMA > > > > > to be stable but also the tree structure and other VMAs inside that > > > > > tree. > > > > > Therefore locking just the faulting VMA is not enough for this search. > > > > > Fall back to taking mmap_lock when vma->anon_vma is not set. This > > > > > situation happens only on the first page fault and should not affect > > > > > overall performance. > > > > > > > > I think I asked this before, but don't remember getting an aswer. > > > > Why do we defer setting anon_vma to the first fault? Why don't we > > > > set it up at mmap time? > > > > > > Yeah, I remember that conversation Matthew and I could not find the > > > definitive answer at the time. I'll look into that again or maybe > > > someone can answer it here. > > > > After looking into it again I'm still under the impression that > > vma->anon_vma is populated lazily (during the first page fault rather > > than at mmap time) to avoid doing extra work for areas which are never > > faulted. Though I might be missing some important detail here. > > How often does userspace call mmap() and then _never_ fault on it? > I appreciate that userspace might mmap() gigabytes of address space and > then only end up using a small amount of it, so populating it lazily > makes sense. But creating a region and never faulting on it? The only > use-case I can think of is loading shared libraries: > > openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 > (...) > mmap(NULL, 197, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = > 0x7f0ce612e000 > mmap(0x7f0ce6154000, 1396736, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f0ce6154000 > mmap(0x7f0ce62a9000, 339968, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, > 3, 0x17b000) = 0x7f0ce62a9000 > mmap(0x7f0ce62fc000, 24576, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ce000) = 0x7f0ce62fc000 > mmap(0x7f0ce6302000, 53072, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0ce6302000 > > but that's a file-backed VMA, not an anon VMA. Might the case of dup_mmap() while forking be the reason why a VMA in the child process might be never used while parent uses it (or visa versa)? Again, I'm not sure this is the reason but I can find no other good explanation.
Re: [PATCH v3 26/35] mm: fall back to mmap_lock if vma->anon_vma is not yet set
On Thu, Feb 16, 2023 at 06:14:59PM -0800, Suren Baghdasaryan wrote: > On Thu, Feb 16, 2023 at 11:43 AM Suren Baghdasaryan wrote: > > > > On Thu, Feb 16, 2023 at 7:44 AM Matthew Wilcox wrote: > > > > > > On Wed, Feb 15, 2023 at 09:17:41PM -0800, Suren Baghdasaryan wrote: > > > > When vma->anon_vma is not set, page fault handler will set it by either > > > > reusing anon_vma of an adjacent VMA if VMAs are compatible or by > > > > allocating a new one. find_mergeable_anon_vma() walks VMA tree to find > > > > a compatible adjacent VMA and that requires not only the faulting VMA > > > > to be stable but also the tree structure and other VMAs inside that > > > > tree. > > > > Therefore locking just the faulting VMA is not enough for this search. > > > > Fall back to taking mmap_lock when vma->anon_vma is not set. This > > > > situation happens only on the first page fault and should not affect > > > > overall performance. > > > > > > I think I asked this before, but don't remember getting an aswer. > > > Why do we defer setting anon_vma to the first fault? Why don't we > > > set it up at mmap time? > > > > Yeah, I remember that conversation Matthew and I could not find the > > definitive answer at the time. I'll look into that again or maybe > > someone can answer it here. > > After looking into it again I'm still under the impression that > vma->anon_vma is populated lazily (during the first page fault rather > than at mmap time) to avoid doing extra work for areas which are never > faulted. Though I might be missing some important detail here. How often does userspace call mmap() and then _never_ fault on it? I appreciate that userspace might mmap() gigabytes of address space and then only end up using a small amount of it, so populating it lazily makes sense. But creating a region and never faulting on it? The only use-case I can think of is loading shared libraries: openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 (...) mmap(NULL, 197, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0ce612e000 mmap(0x7f0ce6154000, 1396736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f0ce6154000 mmap(0x7f0ce62a9000, 339968, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17b000) = 0x7f0ce62a9000 mmap(0x7f0ce62fc000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ce000) = 0x7f0ce62fc000 mmap(0x7f0ce6302000, 53072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0ce6302000 but that's a file-backed VMA, not an anon VMA.
Re: [PATCH mm-unstable v1 3/5] kvm/arm64: add kvm_arch_test_clear_young()
On Fri, Feb 17, 2023, Oliver Upton wrote:
> Hi Yu,
>
> scripts/get_maintainers.pl is your friend for getting the right set of
> emails for a series :) Don't know about others, but generally I would
> prefer to be Cc'ed on an entire series (to gather context) than just an
> individual patch.
+1
>
> On Thu, Feb 16, 2023 at 09:12:28PM -0700, Yu Zhao wrote:
> > This patch adds kvm_arch_test_clear_young() for the vast majority of
> > VMs that are not pKVM and run on hardware that sets the accessed bit
> > in KVM page tables.
At least for the x86 changes, please read
Documentation/process/maintainer-tip.rst
and rewrite the changelogs.
> > It relies on two techniques, RCU and cmpxchg, to safely test and clear
> > the accessed bit without taking the MMU lock. The former protects KVM
> > page tables from being freed while the latter clears the accessed bit
> > atomically against both the hardware and other software page table
> > walkers.
> >
> > Signed-off-by: Yu Zhao
> > ---
> > arch/arm64/include/asm/kvm_host.h | 7 +++
> > arch/arm64/include/asm/kvm_pgtable.h| 8 +++
> > arch/arm64/include/asm/stage2_pgtable.h | 43 ++
> > arch/arm64/kvm/arm.c| 1 +
> > arch/arm64/kvm/hyp/pgtable.c| 51 ++--
> > arch/arm64/kvm/mmu.c| 77 -
> > 6 files changed, 141 insertions(+), 46 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h
> > b/arch/arm64/include/asm/kvm_host.h
> > index 35a159d131b5..572bcd321586 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -1031,4 +1031,11 @@ static inline void kvm_hyp_reserve(void) { }
> > void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu);
> > bool kvm_arm_vcpu_stopped(struct kvm_vcpu *vcpu);
> >
> > +/* see the comments on the generic kvm_arch_has_test_clear_young() */
Please eliminate all of these "see the comments on blah", in every case they do
nothing more than redirect the reader to something they're likely already aware
of.
> > +#define kvm_arch_has_test_clear_young kvm_arch_has_test_clear_young
> > +static inline bool kvm_arch_has_test_clear_young(void)
> > +{
> > + return IS_ENABLED(CONFIG_KVM) && cpu_has_hw_af() &&
> > !is_protected_kvm_enabled();
> > +}
...
> Also, I'm at a loss for why we'd need to test if CONFIG_KVM is enabled.
> My expectation is that we should provide an implementation that returns
> false if !CONFIG_KVM, avoiding the need to repeat that bit in every
> single implementation of the function.
mm/vmscan.c uses kvm_arch_has_test_clear_young(). I have opinions on that, but
I'll hold off on expressing them until there's actual justification presented
somewhere.
Yu, this series and each patch needs a big pile of "why". I get that the goal
is to optimize memory oversubscribe, but there needs to be justification for
why this is KVM only, why nested VMs and !A/D hardware are out of scope, why yet
another mmu_notifier hook is being added, etc.
Re: [PATCH v3 21/35] mm/mmap: write-lock adjacent VMAs if they can grow into unmapped area
On Fri, Feb 17, 2023 at 6:51 AM Liam R. Howlett wrote:
>
> * Suren Baghdasaryan [230216 14:36]:
> > On Thu, Feb 16, 2023 at 7:34 AM Liam R. Howlett
> > wrote:
> > >
> > >
> > > First, sorry I didn't see this before v3..
> >
> > Feedback at any time is highly appreciated!
> >
> > >
> > > * Suren Baghdasaryan [230216 00:18]:
> > > > While unmapping VMAs, adjacent VMAs might be able to grow into the area
> > > > being unmapped. In such cases write-lock adjacent VMAs to prevent this
> > > > growth.
> > > >
> > > > Signed-off-by: Suren Baghdasaryan
> > > > ---
> > > > mm/mmap.c | 8 +---
> > > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > > index 118b2246bba9..00f8c5798936 100644
> > > > --- a/mm/mmap.c
> > > > +++ b/mm/mmap.c
> > > > @@ -2399,11 +2399,13 @@ do_vmi_align_munmap(struct vma_iterator *vmi,
> > > > struct vm_area_struct *vma,
> > > >* down_read(mmap_lock) and collide with the VMA we are about to
> > > > unmap.
> > > >*/
> > > > if (downgrade) {
> > > > - if (next && (next->vm_flags & VM_GROWSDOWN))
> > > > + if (next && (next->vm_flags & VM_GROWSDOWN)) {
> > > > + vma_start_write(next);
> > > > downgrade = false;
> > >
> > > If the mmap write lock is insufficient to protect us from next/prev
> > > modifications then we need to move *most* of this block above the maple
> > > tree write operation, otherwise we have a race here. When I say most, I
> > > mean everything besides the call to mmap_write_downgrade() needs to be
> > > moved.
> >
> > Which prior maple tree write operation are you referring to? I see
> > __split_vma() and munmap_sidetree() which both already lock the VMAs
> > they operate on, so page faults can't happen in those VMAs.
>
> The write that removes the VMAs from the maple tree a few lines above..
> /* Point of no return */
>
> If the mmap lock is not sufficient, then we need to move the
> vma_start_write() of prev/next to above the call to
> vma_iter_clear_gfp() in do_vmi_align_munmap().
>
> But I still think it IS enough.
>
> >
> > >
> > > If the mmap write lock is sufficient to protect us from next/prev
> > > modifications then we don't need to write lock the vmas themselves.
> >
> > mmap write lock is not sufficient because with per-VMA locks we do not
> > take mmap lock at all.
>
> Understood, but it also does not expand VMAs.
>
> >
> > >
> > > I believe this is for expand_stack() protection, so I believe it's okay
> > > to not vma write lock these vmas.. I don't think there are other areas
> > > where we can modify the vmas without holding the mmap lock, but others
> > > on the CC list please chime in if I've forgotten something.
> > >
> > > So, if I am correct, then you shouldn't lock next/prev and allow the
> > > vma locking fault method on these vmas. This will work because
> > > lock_vma_under_rcu() uses mas_walk() on the faulting address. That is,
> > > your lock_vma_under_rcu() will fail to find anything that needs to be
> > > grown and go back to mmap lock protection. As it is written today, the
> > > vma locking fault handler will fail and we will wait for the mmap lock
> > > to be released even when the vma isn't going to expand.
> >
> > So, let's consider a case when the next VMA is not being removed (so
> > it was neither removed nor locked by munmap_sidetree()) and it is
> > found by lock_vma_under_rcu() in the page fault handling path.
>
> By this point next VMA is either NULL or outside the munmap area, so
> what you said here is always true.
>
> >Page
> > fault handler can now expand it and push into the area we are
> > unmapping in unmap_region(). That is the race I'm trying to prevent
> > here by locking the next/prev VMAs which can be expanded before
> > unmap_region() unmaps them. Am I missing something?
>
> Yes, I think the part you are missing (or I am missing..) is that
> expand_stack() will never be called without the mmap lock. We don't use
> the vma locking to expand the stack.
Ah, yes, you are absolutely right. I missed that when the VMA explands
as a result of a page fault, lock_vma_under_rcu() can't find the
faulting VMA (the fault is outside of the area and hence the need to
expand) and will fall back to mmap read locking. Since
do_vmi_align_munmap() holds the mmap write lock and does not downgrade
it, the race will be avoided and expansion will wait until we drop the
mmap write lock.
Good catch Liam! We can drop this patch completely from the series.
Thanks,
Suren.
>
> ...
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kernel-team+unsubscr...@android.com.
>
[PATCH v6 10/10] MAINTAINERS: add the Freescale QMC audio entry
After contributing the component, add myself as the maintainer for the Freescale QMC audio ASoC component. Signed-off-by: Herve Codina --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 47eca5b06cce..4553e5a30e9e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8440,6 +8440,14 @@ F: sound/soc/fsl/fsl* F: sound/soc/fsl/imx* F: sound/soc/fsl/mpc8610_hpcd.c +FREESCALE SOC SOUND QMC DRIVER +M: Herve Codina +L: alsa-de...@alsa-project.org (moderated for non-subscribers) +L: linuxppc-dev@lists.ozlabs.org +S: Maintained +F: Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml +F: sound/soc/fsl/fsl_qmc_audio.c + FREESCALE USB PERIPHERAL DRIVERS M: Li Yang L: linux-...@vger.kernel.org -- 2.39.1
[PATCH v6 09/10] ASoC: fsl: Add support for QMC audio
The QMC audio is an ASoC component which provides DAIs
that use the QMC (QUICC Multichannel Controller) to transfer
the audio data.
It provides as many DAIs as the number of QMC channels it
references.
Signed-off-by: Herve Codina
---
sound/soc/fsl/Kconfig | 9 +
sound/soc/fsl/Makefile| 2 +
sound/soc/fsl/fsl_qmc_audio.c | 735 ++
3 files changed, 746 insertions(+)
create mode 100644 sound/soc/fsl/fsl_qmc_audio.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 614eceda6b9e..17db29c25d96 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -172,6 +172,15 @@ config SND_MPC52xx_DMA
config SND_SOC_POWERPC_DMA
tristate
+config SND_SOC_POWERPC_QMC_AUDIO
+ tristate "QMC ALSA SoC support"
+ depends on CPM_QMC
+ help
+ ALSA SoC Audio support using the Freescale QUICC Multichannel
+ Controller (QMC).
+ Say Y or M if you want to add support for SoC audio using Freescale
+ QMC.
+
comment "SoC Audio support for Freescale PPC boards:"
config SND_SOC_MPC8610_HPCD
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index b54beb1a66fa..8db7e97d0bd5 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -28,6 +28,7 @@ snd-soc-fsl-easrc-objs := fsl_easrc.o
snd-soc-fsl-xcvr-objs := fsl_xcvr.o
snd-soc-fsl-aud2htx-objs := fsl_aud2htx.o
snd-soc-fsl-rpmsg-objs := fsl_rpmsg.o
+snd-soc-fsl-qmc-audio-objs := fsl_qmc_audio.o
obj-$(CONFIG_SND_SOC_FSL_AUDMIX) += snd-soc-fsl-audmix.o
obj-$(CONFIG_SND_SOC_FSL_ASOC_CARD) += snd-soc-fsl-asoc-card.o
@@ -44,6 +45,7 @@ obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o
obj-$(CONFIG_SND_SOC_FSL_XCVR) += snd-soc-fsl-xcvr.o
obj-$(CONFIG_SND_SOC_FSL_AUD2HTX) += snd-soc-fsl-aud2htx.o
obj-$(CONFIG_SND_SOC_FSL_RPMSG) += snd-soc-fsl-rpmsg.o
+obj-$(CONFIG_SND_SOC_POWERPC_QMC_AUDIO) += snd-soc-fsl-qmc-audio.o
# MPC5200 Platform Support
obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
diff --git a/sound/soc/fsl/fsl_qmc_audio.c b/sound/soc/fsl/fsl_qmc_audio.c
new file mode 100644
index ..7cbb8e4758cc
--- /dev/null
+++ b/sound/soc/fsl/fsl_qmc_audio.c
@@ -0,0 +1,735 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ALSA SoC using the QUICC Multichannel Controller (QMC)
+ *
+ * Copyright 2022 CS GROUP France
+ *
+ * Author: Herve Codina
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct qmc_dai {
+ char *name;
+ int id;
+ struct device *dev;
+ struct qmc_chan *qmc_chan;
+ unsigned int nb_tx_ts;
+ unsigned int nb_rx_ts;
+};
+
+struct qmc_audio {
+ struct device *dev;
+ unsigned int num_dais;
+ struct qmc_dai *dais;
+ struct snd_soc_dai_driver *dai_drivers;
+};
+
+struct qmc_dai_prtd {
+ struct qmc_dai *qmc_dai;
+ dma_addr_t dma_buffer_start;
+ dma_addr_t period_ptr_submitted;
+ dma_addr_t period_ptr_ended;
+ dma_addr_t dma_buffer_end;
+ size_t period_size;
+ struct snd_pcm_substream *substream;
+};
+
+static int qmc_audio_pcm_construct(struct snd_soc_component *component,
+ struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_card *card = rtd->card->snd_card;
+ int ret;
+
+ ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+
+ snd_pcm_set_managed_buffer_all(rtd->pcm, SNDRV_DMA_TYPE_DEV, card->dev,
+ 64*1024, 64*1024);
+ return 0;
+}
+
+static int qmc_audio_pcm_hw_params(struct snd_soc_component *component,
+ struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct qmc_dai_prtd *prtd = substream->runtime->private_data;
+
+ prtd->dma_buffer_start = runtime->dma_addr;
+ prtd->dma_buffer_end = runtime->dma_addr + params_buffer_bytes(params);
+ prtd->period_size = params_period_bytes(params);
+ prtd->period_ptr_submitted = prtd->dma_buffer_start;
+ prtd->period_ptr_ended = prtd->dma_buffer_start;
+ prtd->substream = substream;
+
+ return 0;
+}
+
+static void qmc_audio_pcm_write_complete(void *context)
+{
+ struct qmc_dai_prtd *prtd = context;
+ int ret;
+
+ prtd->period_ptr_ended += prtd->period_size;
+ if (prtd->period_ptr_ended >= prtd->dma_buffer_end)
+ prtd->period_ptr_ended = prtd->dma_buffer_start;
+
+ prtd->period_ptr_submitted += prtd->period_size;
+ if (prtd->period_ptr_submitted >= prtd->dma_buffer_end)
+ prtd->period_ptr_submitted = prtd->dma_buffer_start;
+
+ ret = qmc_chan_write_submit(prtd->qmc_dai->qmc_chan,
+ prtd->period_ptr_submitted, prtd->period_size,
+ qmc_audio_pcm_write_complete,
[powerpc:fixes-test] BUILD SUCCESS 4302abc628fc0dc08e5855f21bbfaed407a72bc3
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test branch HEAD: 4302abc628fc0dc08e5855f21bbfaed407a72bc3 powerpc/64s: Prevent fallthrough to hash TLB flush when using radix elapsed time: 724m configs tested: 2 configs skipped: 126 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: powerpc allmodconfig powerpc allnoconfig -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
[PATCH v6 08/10] dt-bindings: sound: Add support for QMC audio
The QMC (QUICC mutichannel controller) is a controller
present in some PowerQUICC SoC such as MPC885.
The QMC audio is an ASoC component that uses the QMC
controller to transfer the audio data.
Signed-off-by: Herve Codina
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/sound/fsl,qmc-audio.yaml | 117 ++
1 file changed, 117 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
diff --git a/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
b/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
new file mode 100644
index ..ff5cd9241941
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,qmc-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QMC audio
+
+maintainers:
+ - Herve Codina
+
+description: |
+ The QMC audio is an ASoC component which uses QMC (QUICC Multichannel
+ Controller) channels to transfer the audio data.
+ It provides as many DAI as the number of QMC channel used.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+const: fsl,qmc-audio
+
+ '#address-cells':
+const: 1
+ '#size-cells':
+const: 0
+ '#sound-dai-cells':
+const: 1
+
+patternProperties:
+ '^dai@([0-9]|[1-5][0-9]|6[0-3])$':
+description:
+ A DAI managed by this controller
+type: object
+
+properties:
+ reg:
+minimum: 0
+maximum: 63
+description:
+ The DAI number
+
+ fsl,qmc-chan:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ - items:
+ - description: phandle to QMC node
+ - description: Channel number
+description:
+ Should be a phandle/number pair. The phandle to QMC node and the QMC
+ channel to use for this DAI.
+
+required:
+ - reg
+ - fsl,qmc-chan
+
+required:
+ - compatible
+ - '#address-cells'
+ - '#size-cells'
+ - '#sound-dai-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+audio_controller: audio-controller {
+compatible = "fsl,qmc-audio";
+#address-cells = <1>;
+#size-cells = <0>;
+#sound-dai-cells = <1>;
+dai@16 {
+reg = <16>;
+fsl,qmc-chan = < 16>;
+};
+dai@17 {
+reg = <17>;
+fsl,qmc-chan = < 17>;
+};
+};
+
+sound {
+compatible = "simple-audio-card";
+#address-cells = <1>;
+#size-cells = <0>;
+simple-audio-card,dai-link@0 {
+reg = <0>;
+format = "dsp_b";
+cpu {
+sound-dai = <_controller 16>;
+};
+codec {
+sound-dai = <>;
+dai-tdm-slot-num = <4>;
+dai-tdm-slot-width = <8>;
+/* TS 3, 5, 7, 9 */
+dai-tdm-slot-tx-mask = <0 0 0 1 0 1 0 1 0 1>;
+dai-tdm-slot-rx-mask = <0 0 0 1 0 1 0 1 0 1>;
+};
+};
+simple-audio-card,dai-link@1 {
+reg = <1>;
+format = "dsp_b";
+cpu {
+sound-dai = <_controller 17>;
+};
+codec {
+sound-dai = <>;
+dai-tdm-slot-num = <4>;
+dai-tdm-slot-width = <8>;
+/* TS 2, 4, 6, 8 */
+dai-tdm-slot-tx-mask = <0 0 1 0 1 0 1 0 1>;
+dai-tdm-slot-rx-mask = <0 0 1 0 1 0 1 0 1>;
+};
+};
+};
--
2.39.1
[PATCH v6 07/10] MAINTAINERS: add the Freescale QMC controller entry
After contributing the driver, add myself as the maintainer for the Freescale QMC controller. Signed-off-by: Herve Codina --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 097a80d6623b..47eca5b06cce 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8372,6 +8372,14 @@ S: Maintained F: drivers/soc/fsl/qe/ F: include/soc/fsl/qe/ +FREESCALE QUICC ENGINE QMC DRIVER +M: Herve Codina +L: linuxppc-dev@lists.ozlabs.org +S: Maintained +F: Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml +F: drivers/soc/fsl/qe/qmc.c +F: include/soc/fsl/qe/qmc.h + FREESCALE QUICC ENGINE TSA DRIVER M: Herve Codina L: linuxppc-dev@lists.ozlabs.org -- 2.39.1
[PATCH v6 06/10] soc: fsl: cpm1: Add support for QMC
The QMC (QUICC Multichannel Controller) emulates up to 64 channels within one serial controller using the same TDM physical interface routed from the TSA. It is available in some PowerQUICC SoC such as the MPC885 or MPC866. It is also available on some Quicc Engine SoCs. This current version support CPM1 SoCs only and some enhancement are needed to support Quicc Engine SoCs. Signed-off-by: Herve Codina Acked-by: Li Yang --- drivers/soc/fsl/qe/Kconfig | 12 + drivers/soc/fsl/qe/Makefile |1 + drivers/soc/fsl/qe/qmc.c| 1533 +++ include/soc/fsl/qe/qmc.h| 71 ++ 4 files changed, 1617 insertions(+) create mode 100644 drivers/soc/fsl/qe/qmc.c create mode 100644 include/soc/fsl/qe/qmc.h diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig index b0088495c323..f90cfdf0c763 100644 --- a/drivers/soc/fsl/qe/Kconfig +++ b/drivers/soc/fsl/qe/Kconfig @@ -44,6 +44,18 @@ config CPM_TSA This option enables support for this controller +config CPM_QMC + tristate "CPM QMC support" + depends on OF && HAS_IOMEM + depends on CPM1 || (SOC_FSL && COMPILE_TEST) + depends on CPM_TSA + help + Freescale CPM QUICC Multichannel Controller + (QMC) + + This option enables support for this + controller + config QE_TDM bool default y if FSL_UCC_HDLC diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile index 45c961acc81b..ec8506e13113 100644 --- a/drivers/soc/fsl/qe/Makefile +++ b/drivers/soc/fsl/qe/Makefile @@ -5,6 +5,7 @@ obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o obj-$(CONFIG_CPM) += qe_common.o obj-$(CONFIG_CPM_TSA) += tsa.o +obj-$(CONFIG_CPM_QMC) += qmc.o obj-$(CONFIG_UCC) += ucc.o obj-$(CONFIG_UCC_SLOW) += ucc_slow.o obj-$(CONFIG_UCC_FAST) += ucc_fast.o diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c new file mode 100644 index ..cfa7207353e0 --- /dev/null +++ b/drivers/soc/fsl/qe/qmc.c @@ -0,0 +1,1533 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * QMC driver + * + * Copyright 2022 CS GROUP France + * + * Author: Herve Codina + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "tsa.h" + +/* SCC general mode register high (32 bits) */ +#define SCC_GSMRL 0x00 +#define SCC_GSMRL_ENR (1 << 5) +#define SCC_GSMRL_ENT (1 << 4) +#define SCC_GSMRL_MODE_QMC (0x0A << 0) + +/* SCC general mode register low (32 bits) */ +#define SCC_GSMRH 0x04 +#define SCC_GSMRH_CTSS (1 << 7) +#define SCC_GSMRH_CDS(1 << 8) +#define SCC_GSMRH_CTSP (1 << 9) +#define SCC_GSMRH_CDP(1 << 10) + +/* SCC event register (16 bits) */ +#define SCC_SCCE 0x10 +#define SCC_SCCE_IQOV(1 << 3) +#define SCC_SCCE_GINT(1 << 2) +#define SCC_SCCE_GUN (1 << 1) +#define SCC_SCCE_GOV (1 << 0) + +/* SCC mask register (16 bits) */ +#define SCC_SCCM 0x14 +/* Multichannel base pointer (32 bits) */ +#define QMC_GBL_MCBASE 0x00 +/* Multichannel controller state (16 bits) */ +#define QMC_GBL_QMCSTATE 0x04 +/* Maximum receive buffer length (16 bits) */ +#define QMC_GBL_MRBLR 0x06 +/* Tx time-slot assignment table pointer (16 bits) */ +#define QMC_GBL_TX_S_PTR 0x08 +/* Rx pointer (16 bits) */ +#define QMC_GBL_RXPTR 0x0A +/* Global receive frame threshold (16 bits) */ +#define QMC_GBL_GRFTHR 0x0C +/* Global receive frame count (16 bits) */ +#define QMC_GBL_GRFCNT 0x0E +/* Multichannel interrupt base address (32 bits) */ +#define QMC_GBL_INTBASE0x10 +/* Multichannel interrupt pointer (32 bits) */ +#define QMC_GBL_INTPTR 0x14 +/* Rx time-slot assignment table pointer (16 bits) */ +#define QMC_GBL_RX_S_PTR 0x18 +/* Tx pointer (16 bits) */ +#define QMC_GBL_TXPTR 0x1A +/* CRC constant (32 bits) */ +#define QMC_GBL_C_MASK32 0x1C +/* Time slot assignment table Rx (32 x 16 bits) */ +#define QMC_GBL_TSATRX 0x20 +/* Time slot assignment table Tx (32 x 16 bits) */ +#define QMC_GBL_TSATTX 0x60 +/* CRC constant (16 bits) */ +#define QMC_GBL_C_MASK16 0xA0 + +/* TSA entry (16bit entry in TSATRX and TSATTX) */ +#define QMC_TSA_VALID (1 << 15) +#define QMC_TSA_WRAP (1 << 14) +#define QMC_TSA_MASK (0x303F) +#define QMC_TSA_CHANNEL(x) ((x) << 6) + +/* Tx buffer descriptor base address (16 bits, offset from MCBASE) */ +#define QMC_SPE_TBASE 0x00 + +/* Channel mode register (16 bits) */ +#define QMC_SPE_CHAMR 0x02 +#define QMC_SPE_CHAMR_MODE_HDLC (1 << 15) +#define QMC_SPE_CHAMR_MODE_TRANSP((0 << 15) | (1 << 13)) +#define QMC_SPE_CHAMR_ENT(1 << 12) +#define QMC_SPE_CHAMR_POL(1 << 8) +#define QMC_SPE_CHAMR_HDLC_IDLM (1
[PATCH v6 05/10] dt-bindings: soc: fsl: cpm_qe: Add QMC controller
Add support for the QMC (QUICC Multichannel Controller)
available in some PowerQUICC SoC such as MPC885 or MPC866.
Signed-off-by: Herve Codina
Reviewed-by: Krzysztof Kozlowski
---
.../soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml | 172 ++
1 file changed, 172 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
diff --git
a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
new file mode 100644
index ..4ebbc7d52981
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PowerQUICC CPM QUICC Multichannel Controller (QMC)
+
+maintainers:
+ - Herve Codina
+
+description:
+ The QMC (QUICC Multichannel Controller) emulates up to 64 channels within one
+ serial controller using the same TDM physical interface routed from TSA.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - fsl,mpc885-scc-qmc
+ - fsl,mpc866-scc-qmc
+ - const: fsl,cpm1-scc-qmc
+
+ reg:
+items:
+ - description: SCC (Serial communication controller) register base
+ - description: SCC parameter ram base
+ - description: Dual port ram base
+
+ reg-names:
+items:
+ - const: scc_regs
+ - const: scc_pram
+ - const: dpram
+
+ interrupts:
+maxItems: 1
+description: SCC interrupt line in the CPM interrupt controller
+
+ fsl,tsa-serial:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ - items:
+ - description: phandle to TSA node
+ - enum: [1, 2, 3]
+description: |
+ TSA serial interface (dt-bindings/soc/cpm1-fsl,tsa.h defines
these
+ values)
+ - 1: SCC2
+ - 2: SCC3
+ - 3: SCC4
+description:
+ Should be a phandle/number pair. The phandle to TSA node and the TSA
+ serial interface to use.
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ '#fsl,chan-cells':
+$ref: /schemas/types.yaml#/definitions/uint32
+const: 1
+description:
+ QMC consumers that use a phandle to QMC need to pass the channel number
+ with this phandle.
+ For instance "fsl,qmc-chan = < 16>;".
+
+patternProperties:
+ '^channel@([0-9]|[1-5][0-9]|6[0-3])$':
+description:
+ A channel managed by this controller
+type: object
+
+properties:
+ reg:
+minimum: 0
+maximum: 63
+description:
+ The channel number
+
+ fsl,operational-mode:
+$ref: /schemas/types.yaml#/definitions/string
+enum: [transparent, hdlc]
+default: transparent
+description: |
+ The channel operational mode
+- hdlc: The channel handles HDLC frames
+- transparent: The channel handles raw data without any processing
+
+ fsl,reverse-data:
+$ref: /schemas/types.yaml#/definitions/flag
+description:
+ The bit order as seen on the channels is reversed,
+ transmitting/receiving the MSB of each octet first.
+ This flag is used only in 'transparent' mode.
+
+ fsl,tx-ts-mask:
+$ref: /schemas/types.yaml#/definitions/uint64
+description:
+ Channel assigned Tx time-slots within the Tx time-slots routed by the
+ TSA to this cell.
+
+ fsl,rx-ts-mask:
+$ref: /schemas/types.yaml#/definitions/uint64
+description:
+ Channel assigned Rx time-slots within the Rx time-slots routed by the
+ TSA to this cell.
+
+required:
+ - reg
+ - fsl,tx-ts-mask
+ - fsl,rx-ts-mask
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - fsl,tsa-serial
+ - '#address-cells'
+ - '#size-cells'
+ - '#fsl,chan-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+qmc@a60 {
+compatible = "fsl,mpc885-scc-qmc", "fsl,cpm1-scc-qmc";
+reg = <0xa60 0x20>,
+ <0x3f00 0xc0>,
+ <0x2000 0x1000>;
+reg-names = "scc_regs", "scc_pram", "dpram";
+interrupts = <27>;
+interrupt-parent = <_PIC>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+#fsl,chan-cells = <1>;
+
+fsl,tsa-serial = < FSL_CPM_TSA_SCC4>;
+
+channel@16 {
+/* Ch16 : First 4 even TS from all routed from TSA */
+reg = <16>;
+fsl,mode = "transparent";
+fsl,reverse-data;
+fsl,tx-ts-mask = <0x 0x00aa>;
+fsl,rx-ts-mask = <0x 0x00aa>;
+};
+
+channel@17 {
+/* Ch17 : First 4 odd TS from all
[PATCH v6 04/10] powerpc/8xx: Use a larger CPM1 command check mask
The CPM1 command mask is defined for use with the standard CPM1 command register as described in the user's manual: 0 |13|47|8 11|12 14| 15| RST|- |OPCODE|CH_NUM| -|FLG| In the QMC extension the CPM1 command register is redefined (QMC supplement user's manuel) with the following mapping: 0 |13|47|8 13|14| 15| RST|QMC OPCODE| 1110|CHANNEL_NUMBER| -|FLG| Extend the check command mask in order to support both the standard CH_NUM field and the QMC extension CHANNEL_NUMBER field. Signed-off-by: Herve Codina Acked-by: Christophe Leroy Acked-by: Michael Ellerman --- arch/powerpc/platforms/8xx/cpm1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/8xx/cpm1.c b/arch/powerpc/platforms/8xx/cpm1.c index 8ef1f4392086..6b828b9f90d9 100644 --- a/arch/powerpc/platforms/8xx/cpm1.c +++ b/arch/powerpc/platforms/8xx/cpm1.c @@ -100,7 +100,7 @@ int cpm_command(u32 command, u8 opcode) int i, ret; unsigned long flags; - if (command & 0xff0f) + if (command & 0xff03) return -EINVAL; spin_lock_irqsave(_lock, flags); -- 2.39.1
[PATCH v6 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller
Add support for the time slot assigner (TSA) available in some PowerQUICC SoC such as MPC885 or MPC866. Signed-off-by: Herve Codina --- .../bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml | 215 ++ include/dt-bindings/soc/cpm1-fsl,tsa.h| 13 ++ 2 files changed, 228 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml create mode 100644 include/dt-bindings/soc/cpm1-fsl,tsa.h diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml new file mode 100644 index ..332e902bcc21 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml @@ -0,0 +1,215 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PowerQUICC CPM Time-slot assigner (TSA) controller + +maintainers: + - Herve Codina + +description: + The TSA is the time-slot assigner that can be found on some PowerQUICC SoC. + Its purpose is to route some TDM time-slots to other internal serial + controllers. + +properties: + compatible: +items: + - enum: + - fsl,mpc885-tsa + - fsl,mpc866-tsa + - const: fsl,cpm1-tsa + + reg: +items: + - description: SI (Serial Interface) register base + - description: SI RAM base + + reg-names: +items: + - const: si_regs + - const: si_ram + + '#address-cells': +const: 1 + + '#size-cells': +const: 0 + + '#fsl,serial-cells': +$ref: /schemas/types.yaml#/definitions/uint32 +const: 1 +description: + TSA consumers that use a phandle to TSA need to pass the serial identifier + with this phandle (defined in dt-bindings/soc/fsl,tsa.h). + For instance "fsl,tsa-serial = < FSL_CPM_TSA_SCC4>;". + +patternProperties: + '^tdm@[0-1]$': +description: + The TDM managed by this controller +type: object + +additionalProperties: false + +properties: + reg: +minimum: 0 +maximum: 1 +description: + The TDM number for this TDM, 0 for TDMa and 1 for TDMb + + fsl,common-rxtx-pins: +$ref: /schemas/types.yaml#/definitions/flag +description: + The hardware can use four dedicated pins for Tx clock, Tx sync, Rx + clock and Rx sync or use only two pins, Tx/Rx clock and Tx/Rx sync. + Without the 'fsl,common-rxtx-pins' property, the four pins are used. + With the 'fsl,common-rxtx-pins' property, two pins are used. + + clocks: +minItems: 2 +items: + - description: External clock connected to L1RSYNC pin + - description: External clock connected to L1RCLK pin + - description: External clock connected to L1TSYNC pin + - description: External clock connected to L1TCLK pin + + clock-names: +minItems: 2 +items: + - const: l1rsync + - const: l1rclk + - const: l1tsync + - const: l1tclk + + fsl,rx-frame-sync-delay-bits: +enum: [0, 1, 2, 3] +default: 0 +description: | + Receive frame sync delay in number of bits. + Indicates the delay between the Rx sync and the first bit of the Rx + frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay. + + fsl,tx-frame-sync-delay-bits: +enum: [0, 1, 2, 3] +default: 0 +description: | + Transmit frame sync delay in number of bits. + Indicates the delay between the Tx sync and the first bit of the Tx + frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay. + + fsl,clock-falling-edge: +$ref: /schemas/types.yaml#/definitions/flag +description: + Data is sent on falling edge of the clock (and received on the rising + edge). If 'clock-falling-edge' is not present, data is sent on the + rising edge (and received on the falling edge). + + fsl,fsync-rising-edge: +$ref: /schemas/types.yaml#/definitions/flag +description: + Frame sync pulses are sampled with the rising edge of the channel + clock. If 'fsync-rising-edge' is not present, pulses are sampled with + the falling edge. + + fsl,double-speed-clock: +$ref: /schemas/types.yaml#/definitions/flag +description: + The channel clock is twice the data rate. + +patternProperties: + '^fsl,[rt]x-ts-routes$': +$ref: /schemas/types.yaml#/definitions/uint32-matrix +description: | + A list of tuple that indicates the Tx or Rx time-slots routes. +items: + items: +- description: +The number of time-slots + minimum: 1 + maximum: 64 +- description: | +
[PATCH v6 02/10] soc: fsl: cpm1: Add support for TSA
The TSA (Time Slot Assigner) purpose is to route some TDM time-slots to other internal serial controllers. It is available in some PowerQUICC SoC such as the MPC885 or MPC866. It is also available on some Quicc Engine SoCs. This current version support CPM1 SoCs only and some enhancement are needed to support Quicc Engine SoCs. Signed-off-by: Herve Codina Acked-by: Li Yang --- drivers/soc/fsl/qe/Kconfig | 11 + drivers/soc/fsl/qe/Makefile | 1 + drivers/soc/fsl/qe/tsa.c| 846 drivers/soc/fsl/qe/tsa.h| 42 ++ 4 files changed, 900 insertions(+) create mode 100644 drivers/soc/fsl/qe/tsa.c create mode 100644 drivers/soc/fsl/qe/tsa.h diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig index 357c5800b112..b0088495c323 100644 --- a/drivers/soc/fsl/qe/Kconfig +++ b/drivers/soc/fsl/qe/Kconfig @@ -33,6 +33,17 @@ config UCC bool default y if UCC_FAST || UCC_SLOW +config CPM_TSA + tristate "CPM TSA support" + depends on OF && HAS_IOMEM + depends on CPM1 || COMPILE_TEST + help + Freescale CPM Time Slot Assigner (TSA) + controller. + + This option enables support for this + controller + config QE_TDM bool default y if FSL_UCC_HDLC diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile index 55a555304f3a..45c961acc81b 100644 --- a/drivers/soc/fsl/qe/Makefile +++ b/drivers/soc/fsl/qe/Makefile @@ -4,6 +4,7 @@ # obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o obj-$(CONFIG_CPM) += qe_common.o +obj-$(CONFIG_CPM_TSA) += tsa.o obj-$(CONFIG_UCC) += ucc.o obj-$(CONFIG_UCC_SLOW) += ucc_slow.o obj-$(CONFIG_UCC_FAST) += ucc_fast.o diff --git a/drivers/soc/fsl/qe/tsa.c b/drivers/soc/fsl/qe/tsa.c new file mode 100644 index ..3646153117b3 --- /dev/null +++ b/drivers/soc/fsl/qe/tsa.c @@ -0,0 +1,846 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * TSA driver + * + * Copyright 2022 CS GROUP France + * + * Author: Herve Codina + */ + +#include "tsa.h" +#include +#include +#include +#include +#include +#include +#include +#include + + +/* TSA SI RAM routing tables entry */ +#define TSA_SIRAM_ENTRY_LAST (1 << 16) +#define TSA_SIRAM_ENTRY_BYTE (1 << 17) +#define TSA_SIRAM_ENTRY_CNT(x) (((x) & 0x0f) << 18) +#define TSA_SIRAM_ENTRY_CSEL_MASK (0x7 << 22) +#define TSA_SIRAM_ENTRY_CSEL_NU(0x0 << 22) +#define TSA_SIRAM_ENTRY_CSEL_SCC2 (0x2 << 22) +#define TSA_SIRAM_ENTRY_CSEL_SCC3 (0x3 << 22) +#define TSA_SIRAM_ENTRY_CSEL_SCC4 (0x4 << 22) +#define TSA_SIRAM_ENTRY_CSEL_SMC1 (0x5 << 22) +#define TSA_SIRAM_ENTRY_CSEL_SMC2 (0x6 << 22) + +/* SI mode register (32 bits) */ +#define TSA_SIMODE 0x00 +#define TSA_SIMODE_SMC2 0x8000 +#define TSA_SIMODE_SMC1 0x8000 +#define TSA_SIMODE_TDMA(x) ((x) << 0) +#define TSA_SIMODE_TDMB(x) ((x) << 16) +#define TSA_SIMODE_TDM_MASK0x0fff +#define TSA_SIMODE_TDM_SDM_MASK0x0c00 +#define TSA_SIMODE_TDM_SDM_NORM 0x +#define TSA_SIMODE_TDM_SDM_ECHO 0x0400 +#define TSA_SIMODE_TDM_SDM_INTL_LOOP 0x0800 +#define TSA_SIMODE_TDM_SDM_LOOP_CTRL 0x0c00 +#define TSA_SIMODE_TDM_RFSD(x) ((x) << 8) +#define TSA_SIMODE_TDM_DSC 0x0080 +#define TSA_SIMODE_TDM_CRT 0x0040 +#define TSA_SIMODE_TDM_STZ 0x0020 +#define TSA_SIMODE_TDM_CE 0x0010 +#define TSA_SIMODE_TDM_FE 0x0008 +#define TSA_SIMODE_TDM_GM 0x0004 +#define TSA_SIMODE_TDM_TFSD(x) ((x) << 0) + +/* SI global mode register (8 bits) */ +#define TSA_SIGMR 0x04 +#define TSA_SIGMR_ENB (1<<3) +#define TSA_SIGMR_ENA (1<<2) +#define TSA_SIGMR_RDM_MASK 0x03 +#define TSA_SIGMR_RDM_STATIC_TDMA0x00 +#define TSA_SIGMR_RDM_DYN_TDMA 0x01 +#define TSA_SIGMR_RDM_STATIC_TDMAB 0x02 +#define TSA_SIGMR_RDM_DYN_TDMAB 0x03 + +/* SI status register (8 bits) */ +#define TSA_SISTR 0x06 + +/* SI command register (8 bits) */ +#define TSA_SICMR 0x07 + +/* SI clock route register (32 bits) */ +#define TSA_SICR 0x0C +#define TSA_SICR_SCC2(x) ((x) << 8) +#define TSA_SICR_SCC3(x) ((x) << 16) +#define TSA_SICR_SCC4(x) ((x) << 24) +#define TSA_SICR_SCC_MASK 0x0ff +#define TSA_SICR_SCC_GRX (1 << 7) +#define TSA_SICR_SCC_SCX_TSA (1 << 6) +#define TSA_SICR_SCC_RXCS_MASK (0x7 << 3) +#define TSA_SICR_SCC_RXCS_BRG1 (0x0 << 3) +#define TSA_SICR_SCC_RXCS_BRG2 (0x1 << 3) +#define TSA_SICR_SCC_RXCS_BRG3 (0x2 << 3) +#define TSA_SICR_SCC_RXCS_BRG4 (0x3 << 3) +#define
[PATCH v6 03/10] MAINTAINERS: add the Freescale TSA controller entry
After contributing the driver, add myself as the maintainer for the Freescale TSA controller. Signed-off-by: Herve Codina --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7f86d02cb427..097a80d6623b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8372,6 +8372,15 @@ S: Maintained F: drivers/soc/fsl/qe/ F: include/soc/fsl/qe/ +FREESCALE QUICC ENGINE TSA DRIVER +M: Herve Codina +L: linuxppc-dev@lists.ozlabs.org +S: Maintained +F: Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml +F: drivers/soc/fsl/qe/tsa.c +F: drivers/soc/fsl/qe/tsa.h +F: include/dt-bindings/soc/cpm1-fsl,tsa.h + FREESCALE QUICC ENGINE UCC ETHERNET DRIVER M: Li Yang L: net...@vger.kernel.org -- 2.39.1
[PATCH v6 00/10] Add the PowerQUICC audio support using the QMC
Hi,
This series adds support for audio using the QMC controller available in
some Freescale PowerQUICC SoCs.
This series contains three parts in order to show the different blocks
hierarchy and their usage in this support.
The first one is related to TSA (Time Slot Assigner).
The TSA handles the data present at the pin level (TDM with up to 64
time slots) and dispatchs them to one or more serial controller (SCC).
The second is related to QMC (QUICC Multichannel Controller).
The QMC handles the data at the serial controller (SCC) level and splits
again the data to creates some virtual channels.
The last one is related to the audio component (QMC audio).
It is the glue between the QMC controller and the ASoC component. It
handles one or more QMC virtual channels and creates one DAI per QMC
virtual channels handled.
Compared to the previous iteration
https://lore.kernel.org/linux-kernel/20230216134226.1692107-1-herve.cod...@bootlin.com/
this v6 series mainly:
- fixes bindings
Best regards,
Herve Codina
Changes v5 -> v6
- Patch 1
Fix blank lines and spaces
Remove fsl,diagnostic-mode
Add some maxItems values
Renamed fsl,tsa.h to cpm1-fsl,tsa.h
- Patch 2
Remove fsl,diagnostic-mode
Renamed fsl,tsa.h to cpm1-fsl,tsa.h
Add 'Acked-by: Li Yang '
- Patch 3
Renamed fsl,tsa.h to cpm1-fsl,tsa.h
- Patch 5
Renamed fsl,tsa.h to cpm1-fsl,tsa.h
Add 'Reviewed-by: Krzysztof Kozlowski '
Changes v4 -> v5
- patch 1
Rename fsl,tsa.yaml to fsl,cpm1-tsa.yaml
Rename #serial-cells to #fsl,serial-cells and add a description
Fix typos
Remove examples present in description
Use a pattern property for fsl,[rt]x-ts-routes
- patch 2
Remove one left out_8() ppc specific function call
Remove the no more needed PPC dependency in case of COMPILE_TEST
- patch 4
Add 'Acked-by: Michael Ellerman '
- patch 5
Rename fsl,qmc.yaml to fsl,cpm1-scc-qmc.yaml
Rename #chan-cells to #fsl,chan-cells and add a description
- patch 6
Add the SOC_FSL dependency in case of COMPILE_TEST (issue raised by
the kernel test robot).
Fix a typo in commit log
Add 'Acked-by: Li Yang '
Changes v3 -> v4
- patches 2, 6 and 9
Update code comment format.
- patch 1
Fix some description formats.
Add 'additionalProperties: false' in subnode.
Move fsl,mode to fsl,diagnostic-mode.
Change clocks and clock-names properties.
Add '#serial-cells' property related to the newly introduced
fsl,tsa-serial phandle.
- patch 2
Move fsl,mode to fsl,diagnostic-mode.
Replace the fsl,tsa phandle and the fsl,tsa-cell-id property by a
fsl,tsa-serial phandle and update the related API.
Add missing locks.
- patch 5
Fix some description format.
Replace the fsl,tsa phandle and the fsl,tsa-cell-id property by a
fsl,tsa-serial phandle.
Rename fsl,mode to fsl,operational-mode and update its description.
- patch 6
Replace the fsl,tsa phandle and the fsl,tsa-cell-id property by a
fsl,tsa-serial phandle and use the TSA updated API.
Rename fsl,mode to fsl,operational-mode.
- patch 8
Add 'Reviewed-by: Krzysztof Kozlowski '
Changes v2 -> v3
- All bindings
Rename fsl-tsa.h to fsl,tsa.h
Add missing vendor prefix
Various fixes (quotes, node names, upper/lower case)
- patches 1 and 2 (TSA binding specific)
Remove 'reserved' values in the routing tables
Remove fsl,grant-mode
Add a better description for 'fsl,common-rxtx-pins'
Fix clocks/clocks-name handling against fsl,common-rxtx-pins
Add information related to the delays unit
Removed FSL_CPM_TSA_NBCELL
Fix license in binding header file fsl,tsa.h
- patches 5 and 6 (QMC binding specific)
Remove fsl,cpm-command property
Add interrupt property constraint
- patches 8 and 9 (QMC audio binding specific)
Remove 'items' in compatible property definition
Add missing 'dai-common.yaml' reference
Fix the qmc_chan phandle definition
- patch 2 and 6
Use io{read,write}be{32,16}
Change commit subjects and logs
- patch 4
Add 'Acked-by: Christophe Leroy '
Changes v1 -> v2:
- patch 2 and 6
Fix kernel test robot errors
- other patches
No changes
Herve Codina (10):
dt-bindings: soc: fsl: cpm_qe: Add TSA controller
soc: fsl: cpm1: Add support for TSA
MAINTAINERS: add the Freescale TSA controller entry
powerpc/8xx: Use a larger CPM1 command check mask
dt-bindings: soc: fsl: cpm_qe: Add QMC controller
soc: fsl: cpm1: Add support for QMC
MAINTAINERS: add the Freescale QMC controller entry
dt-bindings: sound: Add support for QMC audio
ASoC: fsl: Add support for QMC audio
MAINTAINERS: add the Freescale QMC audio entry
.../soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml | 172 ++
.../bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml | 215 +++
.../bindings/sound/fsl,qmc-audio.yaml | 117 ++
MAINTAINERS | 25 +
Re: [PATCH v3 21/35] mm/mmap: write-lock adjacent VMAs if they can grow into unmapped area
* Suren Baghdasaryan [230216 14:36]:
> On Thu, Feb 16, 2023 at 7:34 AM Liam R. Howlett
> wrote:
> >
> >
> > First, sorry I didn't see this before v3..
>
> Feedback at any time is highly appreciated!
>
> >
> > * Suren Baghdasaryan [230216 00:18]:
> > > While unmapping VMAs, adjacent VMAs might be able to grow into the area
> > > being unmapped. In such cases write-lock adjacent VMAs to prevent this
> > > growth.
> > >
> > > Signed-off-by: Suren Baghdasaryan
> > > ---
> > > mm/mmap.c | 8 +---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > index 118b2246bba9..00f8c5798936 100644
> > > --- a/mm/mmap.c
> > > +++ b/mm/mmap.c
> > > @@ -2399,11 +2399,13 @@ do_vmi_align_munmap(struct vma_iterator *vmi,
> > > struct vm_area_struct *vma,
> > >* down_read(mmap_lock) and collide with the VMA we are about to
> > > unmap.
> > >*/
> > > if (downgrade) {
> > > - if (next && (next->vm_flags & VM_GROWSDOWN))
> > > + if (next && (next->vm_flags & VM_GROWSDOWN)) {
> > > + vma_start_write(next);
> > > downgrade = false;
> >
> > If the mmap write lock is insufficient to protect us from next/prev
> > modifications then we need to move *most* of this block above the maple
> > tree write operation, otherwise we have a race here. When I say most, I
> > mean everything besides the call to mmap_write_downgrade() needs to be
> > moved.
>
> Which prior maple tree write operation are you referring to? I see
> __split_vma() and munmap_sidetree() which both already lock the VMAs
> they operate on, so page faults can't happen in those VMAs.
The write that removes the VMAs from the maple tree a few lines above..
/* Point of no return */
If the mmap lock is not sufficient, then we need to move the
vma_start_write() of prev/next to above the call to
vma_iter_clear_gfp() in do_vmi_align_munmap().
But I still think it IS enough.
>
> >
> > If the mmap write lock is sufficient to protect us from next/prev
> > modifications then we don't need to write lock the vmas themselves.
>
> mmap write lock is not sufficient because with per-VMA locks we do not
> take mmap lock at all.
Understood, but it also does not expand VMAs.
>
> >
> > I believe this is for expand_stack() protection, so I believe it's okay
> > to not vma write lock these vmas.. I don't think there are other areas
> > where we can modify the vmas without holding the mmap lock, but others
> > on the CC list please chime in if I've forgotten something.
> >
> > So, if I am correct, then you shouldn't lock next/prev and allow the
> > vma locking fault method on these vmas. This will work because
> > lock_vma_under_rcu() uses mas_walk() on the faulting address. That is,
> > your lock_vma_under_rcu() will fail to find anything that needs to be
> > grown and go back to mmap lock protection. As it is written today, the
> > vma locking fault handler will fail and we will wait for the mmap lock
> > to be released even when the vma isn't going to expand.
>
> So, let's consider a case when the next VMA is not being removed (so
> it was neither removed nor locked by munmap_sidetree()) and it is
> found by lock_vma_under_rcu() in the page fault handling path.
By this point next VMA is either NULL or outside the munmap area, so
what you said here is always true.
>Page
> fault handler can now expand it and push into the area we are
> unmapping in unmap_region(). That is the race I'm trying to prevent
> here by locking the next/prev VMAs which can be expanded before
> unmap_region() unmaps them. Am I missing something?
Yes, I think the part you are missing (or I am missing..) is that
expand_stack() will never be called without the mmap lock. We don't use
the vma locking to expand the stack.
...
Re: [PATCH v5 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller
On 17/02/2023 14:50, Herve Codina wrote:
> Hi Krzysztof,
>
> On Fri, 17 Feb 2023 10:14:48 +0100
> Krzysztof Kozlowski wrote:
>
>> On 16/02/2023 14:42, Herve Codina wrote:
>>> Add support for the time slot assigner (TSA)
>>> available in some PowerQUICC SoC such as MPC885
>>> or MPC866.
>>>
>>> Signed-off-by: Herve Codina
>>> ---
>>> .../bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml | 234 ++
>>> include/dt-bindings/soc/fsl,tsa.h | 13 +
>>> 2 files changed, 247 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml
>>> create mode 100644 include/dt-bindings/soc/fsl,tsa.h
>
> [...]
>>> +
>>> +patternProperties:
>>> + '^tdm@[0-1]$':
>>> +description:
>>> + The TDM managed by this controller
>>> +type: object
>>> +
>>> +additionalProperties: false
>>> +
>>> +properties:
>>> + reg:
>>> +minimum: 0
>>> +maximum: 1
>>> +description:
>>> + The TDM number for this TDM, 0 for TDMa and 1 for TDMb
> [...]
>>> +
>>> + fsl,rx-frame-sync-delay-bits:
>>> +enum: [0, 1, 2, 3]
>>
>> maxItems: 1
>
> The property is an enum
> Why this maxItems value ?
Hm, it's an array, but you are right that enum forces dtschema to
interpret it as scalar value, so your code is correct.
>
> If I add the maxItems value, I've got some dt_binding_check errors:
> //bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml:
> patternProperties:^tdm@[0-1]$:properties:fsl,rx-frame-sync-delay-bits:
> 'enum' should not be valid under {'enum': ['const', 'enum',
> 'exclusiveMaximum', 'exclusiveMinimum', 'minimum', 'maximum', 'multipleOf',
> 'pattern']}
> hint: Scalar and array keywords cannot be mixed
> from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
Best regards,
Krzysztof
Re: [PATCH v5 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller
Hi Krzysztof,
On Fri, 17 Feb 2023 10:14:48 +0100
Krzysztof Kozlowski wrote:
> On 16/02/2023 14:42, Herve Codina wrote:
> > Add support for the time slot assigner (TSA)
> > available in some PowerQUICC SoC such as MPC885
> > or MPC866.
> >
> > Signed-off-by: Herve Codina
> > ---
> > .../bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml | 234 ++
> > include/dt-bindings/soc/fsl,tsa.h | 13 +
> > 2 files changed, 247 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml
> > create mode 100644 include/dt-bindings/soc/fsl,tsa.h
[...]
> > +
> > +patternProperties:
> > + '^tdm@[0-1]$':
> > +description:
> > + The TDM managed by this controller
> > +type: object
> > +
> > +additionalProperties: false
> > +
> > +properties:
> > + reg:
> > +minimum: 0
> > +maximum: 1
> > +description:
> > + The TDM number for this TDM, 0 for TDMa and 1 for TDMb
[...]
> > +
> > + fsl,rx-frame-sync-delay-bits:
> > +enum: [0, 1, 2, 3]
>
> maxItems: 1
The property is an enum
Why this maxItems value ?
If I add the maxItems value, I've got some dt_binding_check errors:
//bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml:
patternProperties:^tdm@[0-1]$:properties:fsl,rx-frame-sync-delay-bits:
'enum' should not be valid under {'enum': ['const', 'enum',
'exclusiveMaximum', 'exclusiveMinimum', 'minimum', 'maximum', 'multipleOf',
'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
>
> > +default: 0
> > +description: |
> > + Receive frame sync delay in number of bits.
> > + Indicates the delay between the Rx sync and the first bit of the
> > Rx
> > + frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay.
> > +
> > + fsl,tx-frame-sync-delay-bits:
> > +enum: [0, 1, 2, 3]
>
> maxItems: 1
Same question here.
Thanks for the review,
Hervé
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 02/11] fbdev: Transfer video= option strings to caller; clarify ownership
Thomas Zimmermann writes:
> Hi
>
> Am 17.02.23 um 09:37 schrieb Javier Martinez Canillas:
>> Thomas Zimmermann writes:
>>
>>> In fb_get_options(), always duplicate the returned option string and
>>> transfer ownership of the memory to the function's caller.
>>>
>>> Until now, only the global option string got duplicated and transferred
>>> to the caller; the per-driver options were owned by fb_get_options().
>>> In the end, it was impossible for the function's caller to detect if
>>> it had to release the string's memory buffer. Hence, all calling drivers
>>> leak the memory buffer. The leaks have existed ever since, but drivers
>>> only call fb_get_option() once as part of module initialization. So the
>>> amount of leaked memory is not significant.
>>>
>>> Fix the semantics of fb_get_option() by unconditionally transferring
>>> ownership of the memory buffer to the caller. Later patches can resolve
>>> the memory leaks in the fbdev drivers.
>>>
>>> Signed-off-by: Thomas Zimmermann
>>> ---
>>
>> [...]
>>
>>> + if (option) {
>>> + if (options)
>>> + *option = kstrdup(options, GFP_KERNEL);
>>> + else
>>> + *option = NULL;
>>> + }
>>>
>>
>> I know the old code wasn't checking if kstrdup() succeeded, but you should
>
> Kstrdup uses kmalloc, which already warns about failed allocations. I
> think it's discouraged to warn again. (Wasn't there a warning in sparse
> or checkpatch?) So I'd rather leave it as is.
>
I didn't mean to warn but to return an error code.
>> do it here and let the caller know. And same if (!options). So I guess the
>> following check can be added (to be consistent with the rest of the code):
>>
>> if (!*option)
>> retval = 1;
>
> Why is that needed for consistency?
>
> Retval is the state of the output: enabled or not. If there are no
> options, retval should be 0(=enabled). 1(=disabled) is only set by
> video=off or that ofonly thing.
>
Ah, I see. I misundertood what retval was about. Forget this comment then.
Maybe while you are there could have another patch to document the return
value in the fb_get_options() kernel-doc?
And this patch looks good to me too after your explanations.
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
Re: [PATCH v3 26/35] mm: fall back to mmap_lock if vma->anon_vma is not yet set
On Fri, Feb 17, 2023 at 11:15 AM Suren Baghdasaryan wrote: > > On Thu, Feb 16, 2023 at 11:43 AM Suren Baghdasaryan wrote: > > > > On Thu, Feb 16, 2023 at 7:44 AM Matthew Wilcox wrote: > > > > > > On Wed, Feb 15, 2023 at 09:17:41PM -0800, Suren Baghdasaryan wrote: > > > > When vma->anon_vma is not set, page fault handler will set it by either > > > > reusing anon_vma of an adjacent VMA if VMAs are compatible or by > > > > allocating a new one. find_mergeable_anon_vma() walks VMA tree to find > > > > a compatible adjacent VMA and that requires not only the faulting VMA > > > > to be stable but also the tree structure and other VMAs inside that > > > > tree. > > > > Therefore locking just the faulting VMA is not enough for this search. > > > > Fall back to taking mmap_lock when vma->anon_vma is not set. This > > > > situation happens only on the first page fault and should not affect > > > > overall performance. > > > > > > I think I asked this before, but don't remember getting an aswer. > > > Why do we defer setting anon_vma to the first fault? Why don't we > > > set it up at mmap time? > > > > Yeah, I remember that conversation Matthew and I could not find the > > definitive answer at the time. I'll look into that again or maybe > > someone can answer it here. > > After looking into it again I'm still under the impression that > vma->anon_vma is populated lazily (during the first page fault rather > than at mmap time) to avoid doing extra work for areas which are never > faulted. Though I might be missing some important detail here. I think this is because the kernel cannot merge VMAs that have different anon_vmas? Enabling lazy population of anon_vma could potentially increase the chances of merging VMAs. > > In the end rather than changing that logic I decided to skip > > vma->anon_vma==NULL cases because I measured them being less than > > 0.01% of all page faults, so ROI from changing that would be quite > > low. But I agree that the logic is weird and maybe we can improve > > that. I will have to review that again when I'm working on eliminating > > all these special cases we skip, like swap/userfaults/etc.
Re: [PATCH 02/11] fbdev: Transfer video= option strings to caller; clarify ownership
Hi
Am 17.02.23 um 09:37 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
In fb_get_options(), always duplicate the returned option string and
transfer ownership of the memory to the function's caller.
Until now, only the global option string got duplicated and transferred
to the caller; the per-driver options were owned by fb_get_options().
In the end, it was impossible for the function's caller to detect if
it had to release the string's memory buffer. Hence, all calling drivers
leak the memory buffer. The leaks have existed ever since, but drivers
only call fb_get_option() once as part of module initialization. So the
amount of leaked memory is not significant.
Fix the semantics of fb_get_option() by unconditionally transferring
ownership of the memory buffer to the caller. Later patches can resolve
the memory leaks in the fbdev drivers.
Signed-off-by: Thomas Zimmermann
---
[...]
+ if (option) {
+ if (options)
+ *option = kstrdup(options, GFP_KERNEL);
+ else
+ *option = NULL;
+ }
I know the old code wasn't checking if kstrdup() succeeded, but you should
Kstrdup uses kmalloc, which already warns about failed allocations. I
think it's discouraged to warn again. (Wasn't there a warning in sparse
or checkpatch?) So I'd rather leave it as is.
do it here and let the caller know. And same if (!options). So I guess the
following check can be added (to be consistent with the rest of the code):
if (!*option)
retval = 1;
Why is that needed for consistency?
Retval is the state of the output: enabled or not. If there are no
options, retval should be 0(=enabled). 1(=disabled) is only set by
video=off or that ofonly thing.
Best regards
Thomas
return retval;
}
--
2.39.1
Best regards,
Javier
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH mm-unstable v1 3/5] kvm/arm64: add kvm_arch_test_clear_young()
Hi Yu,
scripts/get_maintainers.pl is your friend for getting the right set of
emails for a series :) Don't know about others, but generally I would
prefer to be Cc'ed on an entire series (to gather context) than just an
individual patch.
On Thu, Feb 16, 2023 at 09:12:28PM -0700, Yu Zhao wrote:
> This patch adds kvm_arch_test_clear_young() for the vast majority of
> VMs that are not pKVM and run on hardware that sets the accessed bit
> in KVM page tables.
>
> It relies on two techniques, RCU and cmpxchg, to safely test and clear
> the accessed bit without taking the MMU lock. The former protects KVM
> page tables from being freed while the latter clears the accessed bit
> atomically against both the hardware and other software page table
> walkers.
>
> Signed-off-by: Yu Zhao
> ---
> arch/arm64/include/asm/kvm_host.h | 7 +++
> arch/arm64/include/asm/kvm_pgtable.h| 8 +++
> arch/arm64/include/asm/stage2_pgtable.h | 43 ++
> arch/arm64/kvm/arm.c| 1 +
> arch/arm64/kvm/hyp/pgtable.c| 51 ++--
> arch/arm64/kvm/mmu.c| 77 -
> 6 files changed, 141 insertions(+), 46 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h
> b/arch/arm64/include/asm/kvm_host.h
> index 35a159d131b5..572bcd321586 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -1031,4 +1031,11 @@ static inline void kvm_hyp_reserve(void) { }
> void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu);
> bool kvm_arm_vcpu_stopped(struct kvm_vcpu *vcpu);
>
> +/* see the comments on the generic kvm_arch_has_test_clear_young() */
> +#define kvm_arch_has_test_clear_young kvm_arch_has_test_clear_young
> +static inline bool kvm_arch_has_test_clear_young(void)
> +{
> + return IS_ENABLED(CONFIG_KVM) && cpu_has_hw_af() &&
> !is_protected_kvm_enabled();
> +}
Why does the lack of FEAT_HAFDBS preclude the use of the test-and-clear
notifier?
On implementations without FEAT_HAFDBS, hardware will generate a data
abort for software to set the access flag. Regardless of whether
software or hardware is responsible for updating the PTE that
information is available in the page tables.
Also, I'm at a loss for why we'd need to test if CONFIG_KVM is enabled.
My expectation is that we should provide an implementation that returns
false if !CONFIG_KVM, avoiding the need to repeat that bit in every
single implementation of the function.
> +
> #endif /* __ARM64_KVM_HOST_H__ */
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h
> b/arch/arm64/include/asm/kvm_pgtable.h
> index 63f81b27a4e3..8c9a04388c88 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -105,6 +105,7 @@ static inline bool kvm_level_supports_block_mapping(u32
> level)
> * @put_page:Decrement the refcount on a page. When
> the
> * refcount reaches 0 the page is automatically
> * freed.
> + * @put_page_rcu:RCU variant of put_page().
> * @page_count: Return the refcount of a page.
> * @phys_to_virt:Convert a physical address into a virtual
> * address mapped in the current context.
> @@ -122,6 +123,7 @@ struct kvm_pgtable_mm_ops {
> void(*free_removed_table)(void *addr, u32 level);
> void(*get_page)(void *addr);
> void(*put_page)(void *addr);
> + void(*put_page_rcu)(void *addr);
Why do we need this? We already defer dropping the last reference count
on a page to an RCU callback. Have you observed issues with the existing
implementation?
> int (*page_count)(void *addr);
> void* (*phys_to_virt)(phys_addr_t phys);
> phys_addr_t (*virt_to_phys)(void *addr);
> @@ -188,6 +190,12 @@ typedef bool (*kvm_pgtable_force_pte_cb_t)(u64 addr, u64
> end,
> * children.
> * @KVM_PGTABLE_WALK_SHARED: Indicates the page-tables may be shared
> * with other software walkers.
> + *
> + * kvm_arch_test_clear_young() is a special case. It relies on two
> + * techniques, RCU and cmpxchg, to safely test and clear the accessed
> + * bit without taking the MMU lock. The former protects KVM page tables
> + * from being freed while the latter clears the accessed bit atomically
> + * against both the hardware and other software page table walkers.
> */
> enum kvm_pgtable_walk_flags {
> KVM_PGTABLE_WALK_LEAF = BIT(0),
> diff --git a/arch/arm64/include/asm/stage2_pgtable.h
> b/arch/arm64/include/asm/stage2_pgtable.h
> index c8dca8ae359c..350437661d4b 100644
> --- a/arch/arm64/include/asm/stage2_pgtable.h
> +++ b/arch/arm64/include/asm/stage2_pgtable.h
> @@ -30,4 +30,47 @@
> */
> #define kvm_mmu_cache_min_pages(kvm)
Re: [PATCH v5 05/10] dt-bindings: soc: fsl: cpm_qe: Add QMC controller
On 16/02/2023 14:42, Herve Codina wrote: > Add support for the QMC (QUICC Multichannel Controller) > available in some PowerQUICC SoC such as MPC885 or MPC866. > > Signed-off-by: Herve Codina > --- > .../soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml | 172 ++ > 1 file changed, 172 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v5 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller
On 16/02/2023 14:42, Herve Codina wrote: > Add support for the time slot assigner (TSA) > available in some PowerQUICC SoC such as MPC885 > or MPC866. > > Signed-off-by: Herve Codina > --- > .../bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml | 234 ++ > include/dt-bindings/soc/fsl,tsa.h | 13 + > 2 files changed, 247 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml > create mode 100644 include/dt-bindings/soc/fsl,tsa.h > > diff --git > a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml > b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml > new file mode 100644 > index ..bcd03f89780e > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml > @@ -0,0 +1,234 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: PowerQUICC CPM Time-slot assigner (TSA) controller > + > +maintainers: > + - Herve Codina > + > +description: > + The TSA is the time-slot assigner that can be found on some PowerQUICC SoC. > + Its purpose is to route some TDM time-slots to other internal serial > + controllers. > + > +properties: > + compatible: > +items: > + - enum: > + - fsl,mpc885-tsa > + - fsl,mpc866-tsa > + - const: fsl,cpm1-tsa > + > + reg: > +items: > + - description: SI (Serial Interface) register base > + - description: SI RAM base > + > + reg-names: > +items: > + - const: si_regs > + - const: si_ram > + > + '#address-cells': > +const: 1 > + > + '#size-cells': > +const: 0 > + > + '#fsl,serial-cells': > +$ref: /schemas/types.yaml#/definitions/uint32 > +const: 1 > +description: > + TSA consumers that use a phandle to TSA need to pass the serial > identifier > + with this phandle (defined in dt-bindings/soc/fsl,tsa.h). > + For instance "fsl,tsa-serial = < FSL_CPM_TSA_SCC4>;". > + > +patternProperties: > + '^tdm@[0-1]$': > +description: > + The TDM managed by this controller > +type: object > + > +additionalProperties: false > + > +properties: > + reg: > +minimum: 0 > +maximum: 1 > +description: > + The TDM number for this TDM, 0 for TDMa and 1 for TDMb > + > + fsl,common-rxtx-pins: > +$ref: /schemas/types.yaml#/definitions/flag > +description: > + The hardware can use four dedicated pins for Tx clock, Tx sync, Rx > + clock and Rx sync or use only two pins, Tx/Rx clock and Tx/Rx sync. > + Without the 'fsl,common-rxtx-pins' property, the four pins are > used. > + With the 'fsl,common-rxtx-pins' property, two pins are used. > + > + clocks: > +minItems: 2 > +items: > + - description: External clock connected to L1RSYNC pin > + - description: External clock connected to L1RCLK pin > + - description: External clock connected to L1TSYNC pin > + - description: External clock connected to L1TCLK pin Blank line > + clock-names: > +minItems: 2 > +items: > + - const: l1rsync > + - const: l1rclk > + - const: l1tsync > + - const: l1tclk > + > + fsl,diagnostic-mode: > +$ref: /schemas/types.yaml#/definitions/string > +enum: [disabled, echo, internal-loopback, control-loopback] > +default: disabled > +description: | > + The diagnostic mode can be used to diagnose some communication > issues. > + It should not be set (or set to 'disabled') when diagnostic is not > + needed. I don't think this is property for DT. Are you going to ship devices to customers with diagnostic mode? As you explained: no, so this can never appear. You might need sysfs/debugfs knob. You already got a comment for this. Your explanation "I plan" is not an explanation why DT is suitable for such property. So let's make it more obvious: drop it. > + Diagnostic mode: > +- disabled: > +Diagnostic disabled (ie. normal operation) > +- echo: > +Automatic echo. Rx data is resent on Tx. > +- internal-loopback: > +The TDM transmitter is connected to the receiver. Data > appears > +on Tx pin. > +- control-loopback: > +The TDM transmitter is connected to the receiver. The Tx pin > is > +disconnected. > + > + fsl,rx-frame-sync-delay-bits: > +enum: [0, 1, 2, 3] maxItems: 1 > +default: 0 > +description: | > + Receive frame sync delay in number of bits. > + Indicates the delay between the Rx sync and the first bit of the Rx > + frame. 0 for
Re: [PATCH 11/11] drm: Fix comment on mode parsing
Thomas Zimmermann writes: > Do not claim that there's a default mode in the video= option parser. > if no option string has been given, the parser does nothing. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, Javier
Re: [PATCH 10/11] drm: Include for mode parsing
Thomas Zimmermann writes: > Include in drm_connector.c to get video_get_options() > and avoid the dependency on . The replaced function > fb_get_options() is just a tiny wrapper around video_get_opions(). No > functional changes. > > Include to get fwnode_handle_put(), which had been > provided via . > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, Javier
Re: [PATCH 09/11] driver/ps3: Include for mode parsing
Thomas Zimmermann writes: > Include in ps3av.c to get video_get_options() and > avoid the dependency on . The replaced function > fb_get_options() is just a tiny wrapper around video_get_opions(). No > functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, Javier
Re: [PATCH 08/11] fbdev: Handle video= parameter in video/cmdline.c
Thomas Zimmermann writes: > Handle the command-line parameter video= in video/cmdline.c. Implement > the fbdev helper fb_get_options() on top. Will allows to handle the > kernel parameter in DRM without fbdev dependencies. > > Note that __video_get_options() has the meaning of its return value > inverted compared to fb_get_options(). The new helper returns true if > the adapter has been enabled, and false otherwise. > > There is the ofonly parameter, which disables output for non-OF-based > framebuffers. It is only for offb and looks like a workaround. The actual > purpose it not clear to me. Use 'video=off' or 'nomodeset' instead. > s/it/is > Signed-off-by: Thomas Zimmermann > --- [..] > +#include /* for FB_MAX */ I believe including is enough here. Reviewed-by: Javier Martinez Canillas Best regards, Javier
Re: [PATCH mm-unstable v1 3/5] kvm/arm64: add kvm_arch_test_clear_young()
On Fri, 17 Feb 2023 04:21:28 +, Yu Zhao wrote: > > On Thu, Feb 16, 2023 at 9:12 PM Yu Zhao wrote: > > > > This patch adds kvm_arch_test_clear_young() for the vast majority of > > VMs that are not pKVM and run on hardware that sets the accessed bit > > in KVM page tables. I'm really interested in how you can back this statement. 90% of the HW I have access to is not FEAT_HWAFDB capable, either because it predates the feature or because the feature is too buggy to be useful. Do you have numbers? > > > > It relies on two techniques, RCU and cmpxchg, to safely test and clear > > the accessed bit without taking the MMU lock. The former protects KVM > > page tables from being freed while the latter clears the accessed bit > > atomically against both the hardware and other software page table > > walkers. > > > > Signed-off-by: Yu Zhao > > --- > > arch/arm64/include/asm/kvm_host.h | 7 +++ > > arch/arm64/include/asm/kvm_pgtable.h| 8 +++ > > arch/arm64/include/asm/stage2_pgtable.h | 43 ++ > > arch/arm64/kvm/arm.c| 1 + > > arch/arm64/kvm/hyp/pgtable.c| 51 ++-- > > arch/arm64/kvm/mmu.c| 77 - > > 6 files changed, 141 insertions(+), 46 deletions(-) > > Adding Marc and Will. > > Can you please add other interested parties that I've missed? The MAINTAINERS file has it all: KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64) M: Marc Zyngier M: Oliver Upton R: James Morse R: Suzuki K Poulose R: Zenghui Yu L: kvm...@lists.linux.dev May I suggest that you repost your patch and Cc the interested parties yourself? I guess most folks will want to see this in context, and not as a random, isolated change with no rationale. M. -- Without deviation from the norm, progress is not possible.
Re: [PATCH 07/11] fbdev: Move option-string lookup into helper
Thomas Zimmermann writes: > Move the lookup of the option string into an internal helper. No > functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, Javier
Re: [PATCH 06/11] fbdev: Unexport fb_mode_option
Thomas Zimmermann writes: > There are no external users of fb_mode_option. Unexport the variable > and declare it static. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, Javier
Re: [PATCH 05/11] fbdev: Read video= option with fb_get_option() in modedb
Thomas Zimmermann writes: > Get the kernel's global video= parameter with fb_get_option(). Done > to unexport the internal fbdev state fb_mode_config. No functional > changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, Javier
Re: [PATCH 04/11] drivers/ps3: Read video= option with fb_get_option()
Thomas Zimmermann writes: > Get the kernel's global video= parameter with fb_get_option(). Done > to unexport the internal fbdev state fb_mode_config. No functional > changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, Javier
Re: [PATCH 03/11] fbdev: Support NULL for name in option-string lookup
Thomas Zimmermann writes: > Ignore the per-driver video options if no driver name has been > specified to fb_get_option(). Return the global options in this > case. > > Signed-off-by: Thomas Zimmermann > --- I think you need to update the kernel-doc as well to mention that @name could be NULL ? Reviewed-by: Javier Martinez Canillas Best regards, Javier
Re: [PATCH 02/11] fbdev: Transfer video= option strings to caller; clarify ownership
Thomas Zimmermann writes:
> In fb_get_options(), always duplicate the returned option string and
> transfer ownership of the memory to the function's caller.
>
> Until now, only the global option string got duplicated and transferred
> to the caller; the per-driver options were owned by fb_get_options().
> In the end, it was impossible for the function's caller to detect if
> it had to release the string's memory buffer. Hence, all calling drivers
> leak the memory buffer. The leaks have existed ever since, but drivers
> only call fb_get_option() once as part of module initialization. So the
> amount of leaked memory is not significant.
>
> Fix the semantics of fb_get_option() by unconditionally transferring
> ownership of the memory buffer to the caller. Later patches can resolve
> the memory leaks in the fbdev drivers.
>
> Signed-off-by: Thomas Zimmermann
> ---
[...]
> + if (option) {
> + if (options)
> + *option = kstrdup(options, GFP_KERNEL);
> + else
> + *option = NULL;
> + }
>
I know the old code wasn't checking if kstrdup() succeeded, but you should
do it here and let the caller know. And same if (!options). So I guess the
following check can be added (to be consistent with the rest of the code):
if (!*option)
retval = 1;
> return retval;
> }
> --
> 2.39.1
Best regards,
Javier
Re: [PATCH 01/11] fbdev: Fix contact info in fb_cmdline.c
Thomas Zimmermann writes: > Fix Daniel's email address. No functional changes. > > Signed-off-by: Thomas Zimmermann > Cc: Daniel Vetter > --- Reviewed-by: Javier Martinez Canillas Best regards, Javier
