summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-01-23drm/i915/selftest: fix intel_selftest_modify_policy argument typesArnd Bergmann
The definition of intel_selftest_modify_policy() does not match the declaration, as gcc-13 points out: drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:29:5: error: conflicting types for 'intel_selftest_modify_policy' due to enum/integer mismatch; have 'int(struct intel_engine_cs *, struct intel_selftest_saved_policy *, u32)' {aka 'int(struct intel_engine_cs *, struct intel_selftest_saved_policy *, unsigned int)'} [-Werror=enum-int-mismatch] 29 | int intel_selftest_modify_policy(struct intel_engine_cs *engine, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:11: drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.h:28:5: note: previous declaration of 'intel_selftest_modify_policy' with type 'int(struct intel_engine_cs *, struct intel_selftest_saved_policy *, enum selftest_scheduler_modify)' 28 | int intel_selftest_modify_policy(struct intel_engine_cs *engine, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change the type in the definition to match. Fixes: 617e87c05c72 ("drm/i915/selftest: Fix hangcheck self test for GuC submission") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230117163743.1003219-1-arnd@kernel.org (cherry picked from commit 8d7eb8ed3f83f248e01a4f548d9c500a950a2c2d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-01-23drm/i915/mtl: Fix bcs default contextLucas De Marchi
Commit 0d0e7d1eea9e ("drm/i915/mtl: Define engine context layouts") added the engine context for Meteor Lake. In a second revision of the patch it was believed the xcs offsets were wrong due to a tagging issue in the spec. The first version was actually correct, as shown by the intel_lrc_live_selftests/live_lrc_layout test: i915: Running gt_lrc i915: Running intel_lrc_live_selftests/live_lrc_layout bcs0: LRI command mismatch at dword 1, expected 1108101d found 11081019 [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:236:DP-1] disconnected bcs0: HW register image: [0000] 00000000 1108101d 00022244 ffff0008 00022034 00000088 00022030 00000088 ... bcs0: SW register image: [0000] 00000000 11081019 00022244 00090009 00022034 00000000 00022030 00000000 The difference in the 2 additional dwords (0x1d vs 0x19) are the offsets 0x120 / 0x124 that are indeed part of the context image. Bspec: 45585 Fixes: 0d0e7d1eea9e ("drm/i915/mtl: Define engine context layouts") Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230111235531.3353815-2-radhakrishna.sripada@intel.com (cherry picked from commit ca54a9a32da0f0ef7e5cbcd111b66f3c9d78b7d2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-01-23nvme-fc: fix initialization orderRoss Lagerwall
ctrl->ops is used by nvme_alloc_admin_tag_set() but set by nvme_init_ctrl() so reorder the calls to avoid a NULL pointer dereference. Fixes: 6dfba1c09c10 ("nvme-fc: use the tagset alloc/free helpers") Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de>
2023-01-23drm: rcar-du: lvds: Add reset controlTomi Valkeinen
Reset LVDS using the reset control as CPG reset/release is required in the hardware manual sequence. Based on a BSP patch from Koji Matsuoka <koji.matsuoka.xm@renesas.com>. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2023-01-23drm: rcar-du: lvds: Add runtime PMTomi Valkeinen
Add simple runtime PM suspend and resume functionality. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2023-01-23drm: rcar-du: dsi: Add 'select RESET_CONTROLLER'Tomi Valkeinen
The RCAR DSI driver uses reset controller, so we should select it in the Kconfig. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2023-01-23drm/simpledrm: Support the XB24/AB24 formatThierry Reding
Add XB24 and AB24 to the list of supported formats. The format helpers support conversion to these formats and they are documented in the simple-framebuffer device tree bindings. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120173103.4002342-8-thierry.reding@gmail.com
2023-01-23gpiolib-acpi: Don't set GPIOs for wakeup in S3 modeMario Limonciello
commit 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable") adjusted the policy to enable wakeup by default if the ACPI tables indicated that a device was wake capable. It was reported however that this broke suspend on at least two System76 systems in S3 mode and two Lenovo Gen2a systems, but only with S3. When the machines are set to s2idle, wakeup behaves properly. Configuring the GPIOs for wakeup with S3 doesn't work properly, so only set it when the system supports low power idle. Fixes: 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable") Fixes: b38f2d5d9615c ("i2c: acpi: Use ACPI wake capability bit to set wake_irq") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2357 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2162013 Reported-by: Nathan Smythe <ncsmythe@scruboak.org> Tested-by: Nathan Smythe <ncsmythe@scruboak.org> Suggested-by: Raul Rangel <rrangel@chromium.org> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-01-23nfsd: don't free files unconditionally in __nfsd_file_cache_purgeJeff Layton
nfsd_file_cache_purge is called when the server is shutting down, in which case, tearing things down is generally fine, but it also gets called when the exports cache is flushed. Instead of walking the cache and freeing everything unconditionally, handle it the same as when we have a notification of conflicting access. Fixes: ac3a2585f018 ("nfsd: rework refcounting in filecache") Reported-by: Ruben Vestergaard <rubenv@drcmr.dk> Reported-by: Torkil Svensgaard <torkil@drcmr.dk> Reported-by: Shachar Kagan <skagan@nvidia.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Tested-by: Shachar Kagan <skagan@nvidia.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-01-23ARM: 9287/1: Reduce __thumb2__ definition to crypto files that require itNathan Chancellor
Commit 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler") added a __thumb2__ define to ASFLAGS to avoid build errors in the crypto code, which relies on __thumb2__ for preprocessing. Commit 59e2cf8d21e0 ("ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA") followed up on this by removing -mthumb from AFLAGS so that __thumb2__ would not be defined when the default target was ARMv7 or newer. Unfortunately, the second commit's fix assumes that the toolchain defaults to -mno-thumb / -marm, which is not the case for Debian's arm-linux-gnueabihf target, which defaults to -mthumb: $ echo | arm-linux-gnueabihf-gcc -dM -E - | grep __thumb #define __thumb2__ 1 #define __thumb__ 1 This target is used by several CI systems, which will still see redefined macro warnings, despite '-mthumb' not being present in the flags: <command-line>: warning: "__thumb2__" redefined <built-in>: note: this is the location of the previous definition Remove the global AFLAGS __thumb2__ define and move it to the crypto folder where it is required by the imported OpenSSL algorithms; the rest of the kernel should use the internal CONFIG_THUMB2_KERNEL symbol to know whether or not Thumb2 is being used or not. Be sure that __thumb2__ is undefined first so that there are no macro redefinition warnings. Link: https://github.com/ClangBuiltLinux/linux/issues/1772 Reported-by: "kernelci.org bot" <bot@kernelci.org> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Fixes: 59e2cf8d21e0 ("ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA") Fixes: 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2023-01-23io_uring/net: cache provided buffer group value for multishot receivesJens Axboe
If we're using ring provided buffers with multishot receive, and we end up doing an io-wq based issue at some points that also needs to select a buffer, we'll lose the initially assigned buffer group as io_ring_buffer_select() correctly clears the buffer group list as the issue isn't serialized by the ctx uring_lock. This is fine for normal receives as the request puts the buffer and finishes, but for multishot, we will re-arm and do further receives. On the next trigger for this multishot receive, the receive will try and pick from a buffer group whose value is the same as the buffer ID of the las receive. That is obviously incorrect, and will result in a premature -ENOUFS error for the receive even if we had available buffers in the correct group. Cache the buffer group value at prep time, so we can restore it for future receives. This only needs doing for the above mentioned case, but just do it by default to keep it easier to read. Cc: stable@vger.kernel.org Fixes: b3fdea6ecb55 ("io_uring: multishot recv") Fixes: 9bb66906f23e ("io_uring: support multishot in recvmsg") Cc: Dylan Yudaken <dylany@meta.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-01-23drm/format-helper: Support the AB24/XB24 formatsThierry Reding
Add a conversion helper for the AB24 and XB24 formats to use in drm_fb_blit(). Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120173103.4002342-7-thierry.reding@gmail.com
2023-01-23drm/simpledrm: Add support for system memory framebuffersThierry Reding
Simple framebuffers can be set up in system memory, which cannot be requested and/or I/O remapped using the I/O resource helpers. Add a separate code path that obtains system memory framebuffers from the reserved memory region referenced in the memory-region property. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120173103.4002342-6-thierry.reding@gmail.com
2023-01-23drm/simpledrm: Use struct iosys_map consistentlyThierry Reding
The majority of the driver already uses struct iosys_map to encapsulate accesses to I/O remapped vs. system memory. Accesses via the screen base pointer still use __iomem annotations, which can lead to inconsistencies and conflicts with subsequent patches. Convert the screen base to a struct iosys_map as well for consistency and to avoid these issues. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120173103.4002342-5-thierry.reding@gmail.com
2023-01-23dt-bindings: reserved-memory: Support framebuffer reserved memoryThierry Reding
Document the "framebuffer" compatible string for reserved memory nodes to annotate reserved memory regions used for framebuffer carveouts. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120173103.4002342-4-thierry.reding@gmail.com
2023-01-23dt-bindings: display: simple-framebuffer: Document 32-bit BGR formatThierry Reding
This is a variant of the 32-bit RGB format where the red and blue components are swapped. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120173103.4002342-3-thierry.reding@gmail.com
2023-01-23dt-bindings: display: simple-framebuffer: Support system memory framebuffersThierry Reding
In order to support framebuffers residing in system memory, allow the memory-region property to override the framebuffer memory specification in the "reg" property. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120173103.4002342-2-thierry.reding@gmail.com
2023-01-23ipv6: fix reachability confirmation with proxy_ndpGergely Risko
When proxying IPv6 NDP requests, the adverts to the initial multicast solicits are correct and working. On the other hand, when later a reachability confirmation is requested (on unicast), no reply is sent. This causes the neighbor entry expiring on the sending node, which is mostly a non-issue, as a new multicast request is sent. There are routers, where the multicast requests are intentionally delayed, and in these environments the current implementation causes periodic packet loss for the proxied endpoints. The root cause is the erroneous decrease of the hop limit, as this is checked in ndisc.c and no answer is generated when it's 254 instead of the correct 255. Cc: stable@vger.kernel.org Fixes: 46c7655f0b56 ("ipv6: decrease hop limit counter in ip6_forward()") Signed-off-by: Gergely Risko <gergely.risko@gmail.com> Tested-by: Gergely Risko <gergely.risko@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-01-23Merge branch 'ethtool-mac-merge'David S. Miller
Vladimir Oltean say: ==================== ethtool support for IEEE 802.3 MAC Merge layer Change log ---------- v3->v4: - add missing opening bracket in ocelot_port_mm_irq() - moved cfg.verify_time range checking so that it actually takes place for the updated rather than old value v3 at: https://patchwork.kernel.org/project/netdevbpf/cover/20230117085947.2176464-1-vladimir.oltean@nxp.com/ v2->v3: - made get_mm return int instead of void - deleted ETHTOOL_A_MM_SUPPORTED - renamed ETHTOOL_A_MM_ADD_FRAG_SIZE to ETHTOOL_A_MM_TX_MIN_FRAG_SIZE - introduced ETHTOOL_A_MM_RX_MIN_FRAG_SIZE - cleaned up documentation - rebased on top of PLCA changes - renamed ETHTOOL_STATS_SRC_* to ETHTOOL_MAC_STATS_SRC_* v2 at: https://patchwork.kernel.org/project/netdevbpf/cover/20230111161706.1465242-1-vladimir.oltean@nxp.com/ v1->v2: I've decided to focus just on the MAC Merge layer for now, which is why I am able to submit this patch set as non-RFC. v1 (RFC) at: https://patchwork.kernel.org/project/netdevbpf/cover/20220816222920.1952936-1-vladimir.oltean@nxp.com/ What is being introduced ------------------------ TL;DR: a MAC Merge layer as defined by IEEE 802.3-2018, clause 99 (interspersing of express traffic). This is controlled through ethtool netlink (ETHTOOL_MSG_MM_GET, ETHTOOL_MSG_MM_SET). The raw ethtool commands are posted here: https://patchwork.kernel.org/project/netdevbpf/cover/20230111153638.1454687-1-vladimir.oltean@nxp.com/ The MAC Merge layer has its own statistics counters (ethtool --include-statistics --show-mm swp0) as well as two member MACs, the statistics of which can be queried individually, through a new ethtool netlink attribute, corresponding to: $ ethtool -I --show-pause eno2 --src aggregate $ ethtool -S eno2 --groups eth-mac eth-phy eth-ctrl rmon -- --src pmac The core properties of the MAC Merge layer are described in great detail in patches 02/12 and 03/12. They can be viewed in "make htmldocs" format. Devices for which the API is supported -------------------------------------- I decided to start with the Ethernet switch on NXP LS1028A (Felix) because of the smaller patch set. I also have support for the ENETC controller pending. I would like to get confirmation that the UAPI being proposed here will not restrict any use cases known by other hardware vendors. Why is support for preemptible traffic classes not here? -------------------------------------------------------- There is legitimate concern whether the 802.1Q portion of the standard (which traffic classes go to the eMAC and which to the pMAC) should be modeled in Linux using tc or using another UAPI. I think that is stalling the entire series, but should be discussed separately instead. Removing FP adminStatus support makes me confident enough to submit this patch set without an RFC tag (meaning: I wouldn't mind if it was merged as is). What is submitted here is sufficient for an LLDP daemon to do its job. I've patched openlldp to advertise and configure frame preemption: https://github.com/vladimiroltean/openlldp/tree/frame-preemption-v3 In case someone wants to try it out, here are some commands I've used. # Configure the interfaces to receive and transmit LLDP Data Units lldptool -L -i eno0 adminStatus=rxtx lldptool -L -i swp0 adminStatus=rxtx # Enable the transmission of certain TLVs on switch's interface lldptool -T -i eno0 -V addEthCap enableTx=yes lldptool -T -i swp0 -V addEthCap enableTx=yes # Query LLDP statistics on switch's interface lldptool -S -i swp0 # Query the received neighbor TLVs lldptool -i swp0 -t -n -V addEthCap Additional Ethernet Capabilities TLV Preemption capability supported Preemption capability enabled Preemption capability active Additional fragment size: 60 octets So using this patch set, lldpad will be able to advertise and configure frame preemption, but still, no data packet will be sent as preemptible over the link, because there is no UAPI to control which traffic classes are sent as preemptible and which as express. Preemptable or preemptible? --------------------------- IEEE 802.3 uses "preemptable" throughout. IEEE 802.1Q uses "preemptible" throughout. Because the definition of "preemptible" falls under 802.1Q's jurisdiction and 802.3 just references it, I went with the 802.1Q naming even where supporting an 802.3 feature. Also, checkpatch agrees with this. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-01-23net: ethtool: netlink: introduce ethnl_update_bool()Vladimir Oltean
Due to the fact that the kernel-side data structures have been carried over from the ioctl-based ethtool, we are now in the situation where we have an ethnl_update_bool32() function, but the plain function that operates on a boolean value kept in an actual u8 netlink attribute doesn't exist. With new ethtool features that are exposed solely over netlink, the kernel data structures will use the "bool" type, so we will need this kind of helper. Introduce it now; it's needed for things like verify-disabled for the MAC merge configuration. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-01-23net: fec: Use page_pool_put_full_page when freeing rx buffersWei Fang
The page_pool_release_page was used when freeing rx buffers, and this function just unmaps the page (if mapped) and does not recycle the page. So after hundreds of down/up the eth0, the system will out of memory. For more details, please refer to the following reproduce steps and bug logs. To solve this issue and refer to the doc of page pool, the page_pool_put_full_page should be used to replace page_pool_release_page. Because this API will try to recycle the page if the page refcnt equal to 1. After testing 20000 times, the issue can not be reproduced anymore (about testing 391 times the issue will occur on i.MX8MN-EVK before). Reproduce steps: Create the test script and run the script. The script content is as follows: LOOPS=20000 i=1 while [ $i -le $LOOPS ] do echo "TINFO:ENET $curface up and down test $i times" org_macaddr=$(cat /sys/class/net/eth0/address) ifconfig eth0 down ifconfig eth0 hw ether $org_macaddr up i=$(expr $i + 1) done sleep 5 if cat /sys/class/net/eth0/operstate | grep 'up';then echo "TEST PASS" else echo "TEST FAIL" fi Bug detail logs: TINFO:ENET up and down test 391 times [ 850.471205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [ 853.535318] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 853.541694] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 870.590531] page_pool_release_retry() stalled pool shutdown 199 inflight 60 sec [ 931.006557] page_pool_release_retry() stalled pool shutdown 199 inflight 120 sec TINFO:ENET up and down test 392 times [ 991.426544] page_pool_release_retry() stalled pool shutdown 192 inflight 181 sec [ 1051.838531] page_pool_release_retry() stalled pool shutdown 170 inflight 241 sec [ 1093.751217] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [ 1096.446520] page_pool_release_retry() stalled pool shutdown 308 inflight 60 sec [ 1096.831245] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 1096.839092] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 1112.254526] page_pool_release_retry() stalled pool shutdown 103 inflight 302 sec [ 1156.862533] page_pool_release_retry() stalled pool shutdown 308 inflight 120 sec [ 1172.674516] page_pool_release_retry() stalled pool shutdown 103 inflight 362 sec [ 1217.278532] page_pool_release_retry() stalled pool shutdown 308 inflight 181 sec TINFO:ENET up and down test 393 times [ 1233.086535] page_pool_release_retry() stalled pool shutdown 103 inflight 422 sec [ 1277.698513] page_pool_release_retry() stalled pool shutdown 308 inflight 241 sec [ 1293.502525] page_pool_release_retry() stalled pool shutdown 86 inflight 483 sec [ 1338.110518] page_pool_release_retry() stalled pool shutdown 308 inflight 302 sec [ 1353.918540] page_pool_release_retry() stalled pool shutdown 32 inflight 543 sec [ 1361.179205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [ 1364.255298] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 1364.263189] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 1371.998532] page_pool_release_retry() stalled pool shutdown 310 inflight 60 sec [ 1398.530542] page_pool_release_retry() stalled pool shutdown 308 inflight 362 sec [ 1414.334539] page_pool_release_retry() stalled pool shutdown 16 inflight 604 sec [ 1432.414520] page_pool_release_retry() stalled pool shutdown 310 inflight 120 sec [ 1458.942523] page_pool_release_retry() stalled pool shutdown 308 inflight 422 sec [ 1474.750521] page_pool_release_retry() stalled pool shutdown 16 inflight 664 sec TINFO:ENET up and down test 394 times [ 1492.830522] page_pool_release_retry() stalled pool shutdown 310 inflight 181 sec [ 1519.358519] page_pool_release_retry() stalled pool shutdown 308 inflight 483 sec [ 1535.166545] page_pool_release_retry() stalled pool shutdown 2 inflight 724 sec [ 1537.090278] eth_test2.sh invoked oom-killer: gfp_mask=0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), order=0, oom_score_adj=0 [ 1537.101192] CPU: 3 PID: 2379 Comm: eth_test2.sh Tainted: G C 6.1.1+g56321e101aca #1 [ 1537.110249] Hardware name: NXP i.MX8MNano EVK board (DT) [ 1537.115561] Call trace: [ 1537.118005] dump_backtrace.part.0+0xe0/0xf0 [ 1537.122289] show_stack+0x18/0x40 [ 1537.125608] dump_stack_lvl+0x64/0x80 [ 1537.129276] dump_stack+0x18/0x34 [ 1537.132592] dump_header+0x44/0x208 [ 1537.136083] oom_kill_process+0x2b4/0x2c0 [ 1537.140097] out_of_memory+0xe4/0x594 [ 1537.143766] __alloc_pages+0xb68/0xd00 [ 1537.147521] alloc_pages+0xac/0x160 [ 1537.151013] __get_free_pages+0x14/0x40 [ 1537.154851] pgd_alloc+0x1c/0x30 [ 1537.158082] mm_init+0xf8/0x1d0 [ 1537.161228] mm_alloc+0x48/0x60 [ 1537.164368] alloc_bprm+0x7c/0x240 [ 1537.167777] do_execveat_common.isra.0+0x70/0x240 [ 1537.172486] __arm64_sys_execve+0x40/0x54 [ 1537.176502] invoke_syscall+0x48/0x114 [ 1537.180255] el0_svc_common.constprop.0+0xcc/0xec [ 1537.184964] do_el0_svc+0x2c/0xd0 [ 1537.188280] el0_svc+0x2c/0x84 [ 1537.191340] el0t_64_sync_handler+0xf4/0x120 [ 1537.195613] el0t_64_sync+0x18c/0x190 [ 1537.199334] Mem-Info: [ 1537.201620] active_anon:342 inactive_anon:10343 isolated_anon:0 [ 1537.201620] active_file:54 inactive_file:112 isolated_file:0 [ 1537.201620] unevictable:0 dirty:0 writeback:0 [ 1537.201620] slab_reclaimable:2620 slab_unreclaimable:7076 [ 1537.201620] mapped:1489 shmem:2473 pagetables:466 [ 1537.201620] sec_pagetables:0 bounce:0 [ 1537.201620] kernel_misc_reclaimable:0 [ 1537.201620] free:136672 free_pcp:96 free_cma:129241 [ 1537.240419] Node 0 active_anon:1368kB inactive_anon:41372kB active_file:216kB inactive_file:5052kB unevictable:0kB isolated(anon):0kB isolated(file):0kB s [ 1537.271422] Node 0 DMA free:541636kB boost:0kB min:30000kB low:37500kB high:45000kB reserved_highatomic:0KB active_anon:1368kB inactive_anon:41372kB actiB [ 1537.300219] lowmem_reserve[]: 0 0 0 0 [ 1537.303929] Node 0 DMA: 1015*4kB (UMEC) 743*8kB (UMEC) 417*16kB (UMEC) 235*32kB (UMEC) 116*64kB (UMEC) 25*128kB (UMEC) 4*256kB (UC) 2*512kB (UC) 0*1024kBB [ 1537.323938] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ 1537.332708] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB [ 1537.341292] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 1537.349776] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB [ 1537.358087] 2939 total pagecache pages [ 1537.361876] 0 pages in swap cache [ 1537.365229] Free swap = 0kB [ 1537.368147] Total swap = 0kB [ 1537.371065] 516096 pages RAM [ 1537.373959] 0 pages HighMem/MovableOnly [ 1537.377834] 17302 pages reserved [ 1537.381103] 163840 pages cma reserved [ 1537.384809] 0 pages hwpoisoned [ 1537.387902] Tasks state (memory values in pages): [ 1537.392652] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name [ 1537.401356] [ 201] 993 201 1130 72 45056 0 0 rpcbind [ 1537.409772] [ 202] 0 202 4529 1640 77824 0 -250 systemd-journal [ 1537.418861] [ 222] 0 222 4691 801 69632 0 -1000 systemd-udevd [ 1537.427787] [ 248] 994 248 20914 130 65536 0 0 systemd-timesyn [ 1537.436884] [ 497] 0 497 620 31 49152 0 0 atd [ 1537.444938] [ 500] 0 500 854 77 53248 0 0 crond [ 1537.453165] [ 503] 997 503 1470 160 49152 0 -900 dbus-daemon [ 1537.461908] [ 505] 0 505 633 24 40960 0 0 firmwared [ 1537.470491] [ 513] 0 513 2507 180 61440 0 0 ofonod [ 1537.478800] [ 514] 990 514 69640 137 81920 0 0 parsec [ 1537.487120] [ 533] 0 533 599 39 40960 0 0 syslogd [ 1537.495518] [ 534] 0 534 4546 148 65536 0 0 systemd-logind [ 1537.504560] [ 535] 0 535 690 24 45056 0 0 tee-supplicant [ 1537.513564] [ 540] 996 540 2769 168 61440 0 0 systemd-network [ 1537.522680] [ 566] 0 566 3878 228 77824 0 0 connmand [ 1537.531168] [ 645] 998 645 1538 133 57344 0 0 avahi-daemon [ 1537.540004] [ 646] 998 646 1461 64 57344 0 0 avahi-daemon [ 1537.548846] [ 648] 992 648 781 41 45056 0 0 rpc.statd [ 1537.557415] [ 650] 64371 650 590 23 45056 0 0 ninfod [ 1537.565754] [ 653] 61563 653 555 24 45056 0 0 rdisc [ 1537.573971] [ 655] 0 655 374569 2999 290816 0 -999 containerd [ 1537.582621] [ 658] 0 658 1311 20 49152 0 0 agetty [ 1537.590922] [ 663] 0 663 1529 97 49152 0 0 login [ 1537.599138] [ 666] 0 666 3430 202 69632 0 0 wpa_supplicant [ 1537.608147] [ 667] 0 667 2344 96 61440 0 0 systemd-userdbd [ 1537.617240] [ 677] 0 677 2964 314 65536 0 100 systemd [ 1537.625651] [ 679] 0 679 3720 646 73728 0 100 (sd-pam) [ 1537.634138] [ 687] 0 687 1289 403 45056 0 0 sh [ 1537.642108] [ 789] 0 789 970 93 45056 0 0 eth_test2.sh [ 1537.650955] [ 2355] 0 2355 2346 94 61440 0 0 systemd-userwor [ 1537.660046] [ 2356] 0 2356 2346 94 61440 0 0 systemd-userwor [ 1537.669137] [ 2358] 0 2358 2346 95 57344 0 0 systemd-userwor [ 1537.678258] [ 2379] 0 2379 970 93 45056 0 0 eth_test2.sh [ 1537.687098] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-0.slice/user@0.service,tas0 [ 1537.703009] Out of memory: Killed process 679 ((sd-pam)) total-vm:14880kB, anon-rss:2584kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:72kB oom_score_ad0 [ 1553.246526] page_pool_release_retry() stalled pool shutdown 310 inflight 241 sec Fixes: 95698ff6177b ("net: fec: using page pool to manage RX buffers") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: shenwei wang <Shenwei.wang@nxp.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-01-23drm/edid: remove redundant _drm_connector_update_edid_property()Jani Nikula
Realize that drm_edid_connector_update() and _drm_connector_update_edid_property() are now the same thing. Drop the latter. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/712cc299afe33d8f6279a15d5b0117aeeab88bb4.1674144945.git.jani.nikula@intel.com
2023-01-23drm/edid: add separate drm_edid_connector_add_modes()Jani Nikula
The original goal with drm_edid_connector_update() was to have a single call for updating the connector and adding probed modes, in this order, but that turned out to be problematic. Drivers that need to update the connector in the .detect() callback would end up updating the probed modes as well. Turns out the callback may be called so many times that the probed mode list fills up without bounds, and this is amplified by add_alternate_cea_modes() duplicating the CEA modes on every call, actually running out of memory on some machines. Kudos to Imre Deak <imre.deak@intel.com> for explaining this to me. Go back to having separate drm_edid_connector_update() and drm_edid_connector_add_modes() calls. The former may be called from .detect(), .force(), or .get_modes(), but the latter only from .get_modes(). Unlike drm_add_edid_modes(), have drm_edid_connector_add_modes() update the probed modes from the EDID property instead of the passed in EDID. This is mainly to enforce two things: 1) drm_edid_connector_update() must be called before drm_edid_connector_add_modes(). Display info and quirks are needed for parsing the modes, and we don't want to call update_display_info() again to ensure the info is available, like drm_add_edid_modes() does. 2) The same EDID is used for both updating the connector and adding the probed modes. Fortunately, the change is easy, because no driver has actually adopted drm_edid_connector_update(). Not even i915, and that's mainly because of the problem described above. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e86fff1579f14ebf6334692526c8f6831cd02cac.1674144945.git.jani.nikula@intel.com
2023-01-23drm/edid: refactor _drm_edid_connector_update() and renameJani Nikula
By moving update_display_info() out of _drm_edid_connector_update() we make the function purely about adding modes. Rename accordingly. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e9880bbb2b5724d9aac88a90a31ba3ba9af9da3f.1674144945.git.jani.nikula@intel.com
2023-01-23drm/edid: split HDMI VSDB info and mode parsingJani Nikula
Separate the parsing of display info and modes from the HDMI VSDB. This is prerequisite work for overall better separation of the two parsing steps. The info parsing is about figuring out whether the sink supports HDMI infoframes. Since they were added in HDMI 1.4, assume the sink supports HDMI infoframes if it has the HDMI_Video_present bit set (introduced in HDMI 1.4). For details, see commit f1781e9bb2dd ("drm/edid: Allow HDMI infoframe without VIC or S3D"). The logic is not exactly the same, but since it was somewhat heuristic to begin with, assume this is close enough. v2: - Simplify to only check HDMI_Video_present bit (Ville) - Drop cea_db_raw_size() helper (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/238e15f7ab15a86f7fd1812271dcaec9bc6e1506.1674144945.git.jani.nikula@intel.com
2023-01-23drm/bridge: fsl-ldb: Add i.MX93 LDB supportLiu Ying
Same to i.MX8mp LDB, i.MX93 LDB is controlled by mediamix blk-ctrl through LDB_CTRL and LVDS_CTRL registers. i.MX93 LDB supports only one LVDS channel(channel 0) and it's LVDS_CTRL register bit1 is used as LVDS_EN instead of CH1_EN. Add i.MX93 LDB support in the existing i.MX8mp LDB bridge driver by adding i.MX93 LDB compatible string and device data(to reflect different register offsets and LVDS_CTRL register bit1 definition). Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Liu Ying <victor.liu@nxp.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230123021449.969243-3-victor.liu@nxp.com
2023-01-23dt-bindings: display: bridge: ldb: Add i.MX93 LDBLiu Ying
Same to i.MX8mp LDB, i.MX93 LDB is controlled by mediamix blk-ctrl through 'ldb' register and 'lvds' register. Also, the 'ldb' clock is required. i.MX93 LDB supports only one LVDS channel(channel 0, a.k.a, LVDS Channel-A in the device tree binding documentation), while i.MX8mp LDB supports at most two. Add i.MX93 LDB device tree binding in the existing i.MX8mp LDB device tree binding documentation. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Liu Ying <victor.liu@nxp.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230123021449.969243-2-victor.liu@nxp.com
2023-01-22Merge branch 'msm-next-lumag' into HEADDmitry Baryshkov
Merge display-related changes targeting Qualcomm DRM MSM driver. Notable changes: DPU, DSI, MDSS: - Support for SM8350, SM8450 SM8550 and SC8280XP platform Core: - Added bindings for SM8150 (driver support already present) DPU: - Partial support for DSC on SM8150 and SM8250 - Fixed color transformation matrix being lost on suspend/resume DP: - Support for DP on SDM845 and SC8280XP platforms - HPD fixes - Support for limiting DP link rate via DT property, this enables support for HBR3 rates. DSI: - Validate display modes according to the DSI OPP table - DSI PHY support for the SM6375 platform - Fixed byte intf clock selection for 14nm PHYs MDP5: - Schema conversion to YAML Misc fixes as usual Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22Merge branches 'msm-next-lumag-core', 'msm-next-lumag-dpu', ↵Dmitry Baryshkov
'msm-next-lumag-dp', 'msm-next-lumag-dsi', 'msm-next-lumag-hdmi', 'msm-next-lumag-mdp5' and 'msm-next-lumag-mdp4' into msm-next-lumag DPU, DSI, MDSS: - Support for SM8350, SM8450 SM8550 and SC8280XP platform Core: - Added bindings for SM8150 (driver support already present) DPU: - Partial support for DSC on SM8150 and SM8250 - Fixed color transformation matrix being lost on suspend/resume DP: - Support for DP on SDM845 and SC8280XP platforms - HPD fixes - Support for limiting DP link rate via DT property, this enables support for HBR3 rates. DSI: - Validate display modes according to the DSI OPP table - DSI PHY support for the SM6375 platform - Fixed byte intf clock selection for 14nm PHYs MDP5: - Schema conversion to YAML Misc fixes as usual Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: Allow 2 CTRLs on v2.5.0Konrad Dybcio
v2.5.0 support was originally added for SC7280, but this hw is also present on SM8350, which has one more DSI host. Bump up the dsi count and fill in the register of the secondary host to allow it to probe. This should not have any adverse effects on SC7280, as the secondary CTRL will only be touched if it's defined, anyway. Fixes: 65c391b31994 ("drm/msm/dsi: Add DSI support for SC7280") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/519513/ Link: https://lore.kernel.org/r/20230120210101.2146852-1-konrad.dybcio@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: correct byte intf clock rate for 14nm DSI PHYDmitry Baryshkov
According to the vendor kernel, byte intf clock rate should be a half of the byte clock only when DSI PHY version is above 2.0 (in other words, 10nm PHYs and later) and only if PHY is used in D-PHY mode. Currently MSM DSI code handles only the second part of the clause (C-PHY vs D-PHY), skipping DSI PHY version check, which causes issues on some of 14nm DSI PHY platforms (e.g. qcm2290). Move divisor selection to DSI PHY code, pass selected divisor through shared timings and set byte intf clock rate accordingly. Cc: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # SM6115P J606F Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/519006/ Link: https://lore.kernel.org/r/20230118130027.2345719-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22dt-bindings: msm: dsi-controller-main: Add vdd* descriptions back inBryan O'Donoghue
When converting from .txt to .yaml we didn't include descriptions for the existing regulator supplies. - vdd - vdda - vddio Add those descriptions into the yaml now as they were prior to the conversion. In the .txt description we marked these regulators as required, however, that requirement appears to have been in error. Taking the example of sc7180-trogdor-wormdingler.dtsi. The avdd and avee come from GPIO controlled external regulators, not the SoC and in this case there's no need for vddio to power an I/O bus. Similarly the regulators for the LCD are controlled by the panel driver not by the dsi-ctrl driver. It would be possible to connect a different type of panel to the DSI bus here in which case we may or may not want to make use of vdd, vdda or vddio. This is also the case for older chipsets like apq8064, msm8916 etc the vdd* regulators in the dsi-ctrl block are helpers not dependencies. Add the description of vdd, vdda and vddio back in for the existing upstream dts where vdd, vdda or vddio are already declared but, don't declare those regulators required - they are not SoC requirements. Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings") Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/518643/ Link: https://lore.kernel.org/r/20230116225217.1056258-4-bryan.odonoghue@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22dt-bindings: msm/dsi: Don't require vdds-supply on 7nm PHYKonrad Dybcio
On some SoCs (hello SM6375) vdds-supply is not wired to any smd-rpm or rpmh regulator, but instead powered by the VDD_MX/mx.lvl line, which is voted for in the DSI ctrl node. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/518513/ Link: https://lore.kernel.org/r/20230116115132.348961-1-konrad.dybcio@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: Add phy configuration for SM6375Konrad Dybcio
SM6375 uses a boring standard 7nm PHY. Add a configuration entry for it. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/518511/ Link: https://lore.kernel.org/r/20230116114059.346327-2-konrad.dybcio@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22dt-bindings: display/msm: Add SM6375 DSI PHYKonrad Dybcio
SM6375 has a single 7nm DSI PHY. Document it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/518509/ Link: https://lore.kernel.org/r/20230116114059.346327-1-konrad.dybcio@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid()Abhinav Kumar
Currently there is no protection against a user trying to set an unsupported mode on DSI. Implement a check based on the opp table whether the byte clock for the mode can be supported by validating whether an opp table entry exists. For devices which have not added opp table support yet, skip this check otherwise it will break bootup on those devices. changes in v3: - make the comment shorter - handle all errors except ENODEV Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/15 Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/518008/ Link: https://lore.kernel.org/r/20230112001600.12791-2-quic_abhinavk@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: add a helper method to compute the dsi byte clkAbhinav Kumar
Re-arrange the dsi_calc_pclk method to two helpers, one to compute the DSI byte clk and the other to compute the pclk. This makes the separation of the two clean and also allows clients to compute and use the dsi byte clk separately. changes in v2: - move the assignments to definition lines Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/518005/ Link: https://lore.kernel.org/r/20230112001600.12791-1-quic_abhinavk@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: Drop the redundant fail labelJiasheng Jiang
Drop the redundant fail label and change the "goto fail" into "return ret" since they are the same. Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/517816/ Link: https://lore.kernel.org/r/20230111011006.6238-1-jiasheng@iscas.ac.cn Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: Add missing check for alloc_ordered_workqueueJiasheng Jiang
Add check for the return value of alloc_ordered_workqueue as it may return NULL pointer and cause NULL pointer dereference. Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/517646/ Link: https://lore.kernel.org/r/20230110021651.12770-1-jiasheng@iscas.ac.cn Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: add support for DSI 2.7.0Neil Armstrong
Add support for DSI 2.7.0 (block used on sm8550). Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/517517/ Link: https://lore.kernel.org/r/20230103-topic-sm8550-upstream-mdss-dsi-v3-7-660c3bcb127f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: add support for DSI-PHY on SM8550Neil Armstrong
SM8550 use a 4nm DSI PHYs, which share register definitions with 7nm DSI PHYs. Rather than duplicating the driver, handle 4nm variant inside the common 5+7nm driver. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/517515/ Link: https://lore.kernel.org/r/20230103-topic-sm8550-upstream-mdss-dsi-v3-6-660c3bcb127f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22dt-bindings: display/msm: document the SM8550 DSI PHYNeil Armstrong
Document the SM8550 DSI PHY which is very close from the 7nm and 5nm DSI PHYs found in earlier platforms. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/517509/ Link: https://lore.kernel.org/r/20230103-topic-sm8550-upstream-mdss-dsi-v3-1-660c3bcb127f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22dt-bindings: msm: dsi-phy-28nm: Document fam-b compatibleAdam Skladowski
Document omitted 28nm compatible which will be used on MSM8976 SoC. Signed-off-by: Adam Skladowski <a39.skl@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/516427/ Link: https://lore.kernel.org/r/20221231170532.77000-1-a39.skl@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: add support for DSI 2.6.0Dmitry Baryshkov
Add support for DSI 2.6.0 (block used on sm8450). Tested-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/514237/ Link: https://lore.kernel.org/r/20221207012231.112059-8-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450Dmitry Baryshkov
SM8350 and SM8450 use 5nm DSI PHYs, which share register definitions with 7nm DSI PHYs. Rather than duplicating the driver, handle 5nm variants inside the common 5+7nm driver. Co-developed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Tested-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/514230/ Link: https://lore.kernel.org/r/20221207012231.112059-7-dmitry.baryshkov@linaro.org [DB: changed compatibles per Krzysztof's request] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2023-01-22Merge tag 'sched_urgent_for_v6.2_rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Borislav Petkov: - Make sure the scheduler doesn't use stale frequency scaling values when latter get disabled due to a value error - Fix a NULL pointer access on UP configs - Use the proper locking when updating CPU capacity * tag 'sched_urgent_for_v6.2_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/aperfmperf: Erase stale arch_freq_scale values when disabling frequency invariance readings sched/core: Fix NULL pointer access fault in sched_setaffinity() with non-SMP configs sched/fair: Fixes for capacity inversion detection sched/uclamp: Fix a uninitialized variable warnings
2023-01-22Merge tag 'edac_urgent_for_v6.2_rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fixes from Borislav Petkov: - Respect user-supplied polling value in the EDAC device code - Fix a use-after-free issue in qcom_edac * tag 'edac_urgent_for_v6.2_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info EDAC/device: Respect any driver-supplied workqueue polling value
2023-01-22Merge tag 'perf_urgent_for_v6.2_rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fix from Borislav Petkov: - Add Emerald Rapids model support to more perf machinery * tag 'perf_urgent_for_v6.2_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel/cstate: Add Emerald Rapids perf/x86/intel: Add Emerald Rapids
2023-01-22Merge tag 'gfs2-v6.2-rc4-fix' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 Pull gfs2 writepage fix from Andreas Gruenbacher: - Fix a regression introduced by commit "gfs2: stop using generic_writepages in gfs2_ail1_start_one". * tag 'gfs2-v6.2-rc4-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2: Revert "gfs2: stop using generic_writepages in gfs2_ail1_start_one"
2023-01-22drm/panel: Add driver for the AUO A030JTN01 TFT LCDChristophe Branchereau
Add driver for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit interface. Signed-off-by: Christophe Branchereau <cbranchereau@gmail.com> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230121162419.284523-3-cbranchereau@gmail.com
generated by cgit (git 2.34.1) at 2025-09-16 19:28:10 +0000