- User Since
- Nov 1 2020, 1:24 PM (124 w, 1 d)
Mon, Feb 20
How often do you OPEN objects?
You're taking current implementation into account only when I re-used dpaa2_cmd extensively without proper locking though. I'm working on a patch to allocate dpaa2_cmd on stack and initialize them ad-hoc. We won't need to lock them, but DPAA2 objects themselves will be opened/closed more frequently.
Feb 15 2023
Overall changes look good to me.
My understanding is that re-setting the command token to zero explicitly isn't what MC expects in most operations (except xxx_CREATE ones when token = 0 means that a newly created object will be assigned to the resource container that hosts the MC command portal currently executing the command), i.e. when you're going to open an object (DPNI, DPMAC, etc.) within a resource container, you must supply an authentication token obtained previously when the resource container was opened.
Feb 14 2023
Jan 22 2023
Oct 14 2022
Oct 13 2022
- dpaa2_mc.c patched to fix LINT-FDT build (discovered and fixed by @bz, thanks!);
- copyrights of dpaa2_ni_dpkg.h and dpaa2_swc.c updated to include copyright notices from the original files together with the updated SPDX license identifiers.
Oct 11 2022
Whitespace changes in sys/arm64/conf/std.nxp removed
Oct 10 2022
- DPAA2 files were placed between dev/cpufreq and dev/dwc in sys/conf/files.arm64;
- Copyrights were added to sys/dev/dpaa2/dpaa2_ni_dpkg.h (drivers/net/ethernet/freescale/dpaa2/dpkg.h) and sys/dev/dpaa2/dpaa2_swp.c (drivers/soc/fsl/dpio/qbman-portal.c) as their significant parts were copy-pasted from the Linux drivers.
Oct 6 2022
SOC_NXP_LS to lower case
Closed in favor of https://reviews.freebsd.org/D36793
Oct 5 2022
Obtain DEVICE_PROP_HANDLE properties using new API (as @bz suggested in https://reviews.freebsd.org/D36793#837246)
Oct 4 2022
@mw, this diff is supposed to substitute some pieces from sys/dev/dpaa2/dpaa2_mc_fdt.c and sys/dev/dpaa2/dpaa2_mc_acpi.c (https://reviews.freebsd.org/D36638):
Sep 30 2022
- memac bits are re-worked by @bz to separate FDT/ACPI parts into the different drivers (thanks!);
- frame queues aren't blocked anymore on Rx now (not necessary due to the QBMan's processing of the Volatile Dequeue commands where frames are pulled from the only frame queue in response to the command; it fixes LOR reported by @bz as well)
Sep 25 2022
OK, I'll make a note for myself. Thanks for a suggestion!
Sep 23 2022
Review for ACPI changes: https://reviews.freebsd.org/D36677
Sep 22 2022
Sep 21 2022
_STANDALONE test removed
cosmetic changes, alphabetical re-ordering and ACPI changes removed (to be reviewed separately)
Sep 20 2022
Aug 22 2022
Aug 21 2022
I've provided an actual diff revision URL and removed [PATCH] prefix from the commit message.
Aug 9 2022
Jul 23 2022
Jul 22 2022
Jul 19 2022
Dec 26 2021
I've just got a kernel panic at the same place with IOMMU enabled and DPAA2 driver WIP on Honeycomb board.
Aug 1 2021
outid will be written in case of a non-null output node found only. This is how iort_pci_rc_map() used to work and I don't want my patch to change this behavior.
Shared parts of the iort_pci_rc_map() and iort_named_comp_map() were extracted into a separate iort_smmu_trymap() function.
Jul 27 2021
@andrew It definitely won't be, but I wanted to have a separate function for named components from IORT table similar to one for PCI RC nodes. I'll probably extract the same parts of the both functions into a separate one.
You won't see "MSI allocated" in dmesg if you clone the repository or pull the latest changes now. Please, ping me and I'll explain how to test this patch.
Jul 22 2021
Dec 2 2020
@mhorne Should I update a patch attached to the PR also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251053 ?
Unnecessary tests of the devtype argument have been removed from uart_cpu_getdev() in sys/dev/uart/uart_cpu_arm64.c and sys/dev/uart/uart_cpu_fdt.c. uart_cpu_fdt_probe() checks for console types it supports.
Dec 1 2020
Please, take a look at the updated patch.
I've tried to follow all of the comments during the review.
Nov 30 2020
Nov 25 2020
There's some information here if you haven't found it already: https://wiki.freebsd.org/Phabricator
No, I haven't seen it yet - thanks for sharing! What's a preferred way to create a revision: via command line or web interface?
Nov 24 2020
Would you be willing to create a new phabricator review for the change?
Nov 11 2020
I've re-worked this patch and opened a PR at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251053.