Testing PCIe graphics cards on Pi5 #7072
Draft
+249,516
−6,544
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The i.MX8MP makes calls on it's source device to determine the link-frequency that should be configured on the CSI2 receiver. When the source is behind a video mux, we need to pass this call through to the connected device. Map the control handler of the source device to the video-mux, essentially proxying all controls on the mux to the device which has it's link enabled. Signed-off-by: Kieran Bingham <[email protected]>
system_heap.max_order=<uint> Signed-off-by: Tvrtko Ursulin <[email protected]>
Add numa_policy kernel argument to allow overriding the kernel's default NUMA policy at boot time. Syntax identical to what tmpfs accepts as it's mpol argument is accepted. Some examples: numa_policy=interleave numa_policy=interleave=skip-interleave numa_policy=bind:0-3,5,7,9-15 numa_policy=bind=static:1-2 Signed-off-by: Tvrtko Ursulin <[email protected]>
... Make sure CMA zones do not straddle the emulated NUMA nodes ... Signed-off-by: Tvrtko Ursulin <[email protected]>
…ed allocations Add iommu_dma_numa_policy= kernel parameter which can be used to modify the NUMA allocation policy of remapped buffer allocations. Policy is only used for devices which are not associated with a NUMA node. Syntax identical to what tmpfs accepts as it's mpol argument is accepted. Some examples: iommu_dma_numa_policy=interleave iommu_dma_numa_policy=interleave=skip-interleave iommu_dma_numa_policy=bind:0-3,5,7,9-15 iommu_dma_numa_policy=bind=static:1-2 Signed-off-by: Tvrtko Ursulin <[email protected]>
To help work around certain memory controller limitations or similar, a random NUMA allocation memory policy is added. Signed-off-by: Tvrtko Ursulin <[email protected]>
Some apps like linpack use numa_setpolicy to disable numa, but that tends to have a significant performance hit for us. If you have a cmdline.txt setting of numa_policy (to something other than default), then lets ignore runtime changes and stick with the cmdline.txt setting. Not specifying numa_setpolicy in cmdline, or setting numa_setpolicy=default(*) will allow runtime settings to work. (*) easier to do when numa_setpolicy=interleave is set in DT. Ignore logging for the first 40 seconds as there are some expected switches during boot. Signed-off-by: Dom Cobley <[email protected]> Show process name in set_mempolicy() ignored message Signed-off-by: Trevor Man <[email protected]>
As a workaround (and possibly a fix) for CPU spins observed on BCM2837, use ptep_clear_flush_young instead of ptep_test_and_clear_young inside lru_gen_look_around in order to expose PTE changes to the MMU. Note that on architectures that don't require an explicit flush, ptep_clear_flush_young just calls ptep_test_and_clear_young. Signed-off-by: Phil Elwell <[email protected]>
A user has reported that a card of this model from late 2021 doesn't work, so extend the date range and make it match on all card sizes. Signed-off-by: Jonathan Bell <[email protected]>
Add two quirk properties that control whether or not the controller issues many more handshakes to FS/HS Async endpoints in a single (micro)frame. Enabling these can significantly increase throughput for endpoints that frequently respond with NAKs. Signed-off-by: Jonathan Bell <[email protected]>
If a device frequently NAKs, it can exhaust the scheduled handshakes in a frame. It will then not get polled by the controller until the next frame interval. This is most noticeable on FS devices as the controller schedules a small set of transactions only once per full-speed frame. Setting the ENH_PER_NAK_FS/LS bits in the GUCTL1 register increases the number of transactions that can be scheduled to Async (Control/Bulk) endpoints in the respective frame time. In the FS case, this only applies to FS devices directly connected to root ports. Signed-off-by: Jonathan Bell <[email protected]>
For platforms that have xHCI controllers attached over PCIe, and non-coherent routes to main memory, a theoretical race exists between posting new TRBs to a ring, and writing to the doorbell register. In a contended system, write traffic from the CPU may be stalled before the memory controller, whereas the CPU to Endpoint route is separate and not likely to be contended. Similarly, the DMA route from the endpoint to main memory may be separate and uncontended. Therefore the xHCI can receive a doorbell write and find a stale view of a transfer ring. In cases where only a single TRB is ping-ponged at a time, this can cause the endpoint to not get polled at all. Adding a readl() before the write forces a round-trip transaction across PCIe, definitively serialising the CPU along the PCI producer-consumer ordering rules. Signed-off-by: Jonathan Bell <[email protected]>
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: raspberrypi#6220 Signed-off-by: Phil Elwell <[email protected]>
…ctors The non-desktop property "Indicates the output should be ignored for purposes of displaying a standard desktop environment or console." That sounds like it should be true for all writeback and virtual connectors as you shouldn't render a desktop to them, so set it by default. Signed-off-by: Dave Stevenson <[email protected]>
The limit of 32 planes per DRM device is dictated by the use of planes_mask returning a u32. Change to a u64 such that 64 planes can be supported by a device. Signed-off-by: Dave Stevenson <[email protected]>
Some hardware will implement transpose as a rotation operation, which when combined with X and Y reflect can result in a rotation, but is a discrete operation in its own right. Add an option for transpose only. Signed-off-by: Dave Stevenson <[email protected]>
Some connectors, particularly writeback, can implement flip or transpose operations as writing back to memory. Add a connector rotation property to control this. Signed-off-by: Dave Stevenson <[email protected]>
For devices where transfer lengths are not known upfront, there is a danger when the destination is wider than the source that partial words can be lost at the end of a transfer. Ideally the controller would be able to flush the residue, but it can't - it's not even possible to tell that there is any. Instead, allow the client driver to avoid the problem by setting a smaller width. Signed-off-by: Phil Elwell <[email protected]>
SPI transfers are of defined length, unlike some UART traffic, so it is safe to let the DMA controller choose a suitable memory width. Signed-off-by: Phil Elwell <[email protected]>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: raspberrypi#6365 Signed-off-by: Phil Elwell <[email protected]>
The xHC may commence Host Initiated Data Moves for streaming endpoints -
see USB3.2 spec s8.12.1.4.2.4. However, this behaviour is typically
counterproductive as the submission of UAS URBs in {Status, Data,
Command} order and 1 outstanding IO per stream ID means the device never
enters Move Data after a HIMD for Status or Data stages with the same
stream ID. For OUT transfers this is especially inefficient as the host
will start transmitting multiple bulk packets as a burst, all of which
get NAKed by the device - wasting bandwidth.
Also, some buggy UAS adapters don't properly handle the EP flow control
state this creates - e.g. RTL9210.
Set Host Initiated Data Move Disable to always defer stream selection to
the device. xHC implementations may treat this field as "don't care,
forced to 1" anyway - xHCI 1.2 s4.12.1.
Signed-off-by: Jonathan Bell <[email protected]>
Attempting to start a non-idle channel causes an error message to be logged, and is inefficient. Test for emptiness of the desc_issued list before doing so. Signed-off-by: Phil Elwell <[email protected]>
The Raspberry Pi RP1 includes 2 M3 cores running firmware. This driver adds a mailbox communication channel to them via a doorbell and some shared memory. Signed-off-by: Phil Elwell <[email protected]>
The RP1 firmware runs a simple communications channel over some shared memory and a mailbox. This driver provides access to that channel. Signed-off-by: Phil Elwell <[email protected]> firmware: rp1: Simplify rp1_firmware_get Simplify the implementation of rp1_firmware_get, requiring its clients to have a valid 'firmware' property. Also make it return NULL on error. Link: raspberrypi#6593 Signed-off-by: Phil Elwell <[email protected]> firmware: rp1: Linger on firmware failure To avoid pointless retries, let the probe function succeed if the firmware interface is configured correctly but the firmware is incompatible. The value of the private drvdata field holds the outcome. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <[email protected]> firmware: rp1: Rename to rp1-fw to avoid module name collision There is already the driver in drivers/mfd/rp1.ko, so having drivers/firmware/rp1.ko can cause issues when using modinfo and similar, and we can get errors with "Module rp1 is already loaded" when trying to load it. Rename the module so that the name is unique. Signed-off-by: Dave Stevenson <[email protected]> mailbox: rp1: Don't claim channels in of_xlate The of_xlate method saves the calculated event mask in the con_priv field. It also rejects subsequent attempt to use that channel because the mask is non-zero, which causes a repeated instantiation of a client driver to fail. The of_xlate method is not meant to be a point of resource acquisition. Leave the con_priv initialisation, but drop the test that it was previously zero. Signed-off-by: Phil Elwell <[email protected]>
Provide remote access to the PIO hardware in RP1. There is a single instance, with 4 state machines. Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: Support larger data transfers Add a separate IOCTL for larger transfer with a 32-bit data_bytes field. See: raspberrypi/utils#107 Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: More logical probe sequence Sort the probe function initialisation into a more logical order. Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: Minor cosmetic tweaks No functional change. Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: Add in-kernel DMA support Add kernel-facing implementations of pio_sm_config_xfer and pio_xm_xfer_data. Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: Handle probe errors Ensure that rp1_pio_open fails if the device failed to probe. Link: raspberrypi#6593 Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: SM_CONFIG_XFER32 = larger DMA bufs Add an ioctl type - SM_CONFIG_XFER32 - that takes uints for the buf_size and buf_count values. Signed-off-by: Phil Elwell <[email protected]> misc/rp1-pio: Fix copy/paste error in pio_rp1.h As per the subject, there was a copy/paste error that caused pio_sm_unclaim from a driver to result in a call to pio_sm_claim. Fix it. Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: Fix parameter checks wihout client Passing bad parameters to an API call without a pio pointer will cause a NULL pointer exception when the persistent error is set. Guard against that. Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: Convert floats to 24.8 fixed point Floating point arithmetic is not supported in the kernel, so use fixed point instead. Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: Error out on incompatible firmware If the RP1 firmware has reported an error then return that from the PIO probe function, otherwise defer the probing. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: Demote fw probe error to warning Support for the RP1 firmware mailbox API is rolling out to Pi 5 EEPROM images. For most users, the fact that the PIO is not available is no cause for alarm. Change the message to a warning, so that it does not appear with "quiet" in cmdline.txt. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <[email protected]> misc: rp1-pio: Don't just reuse the same DMA buf A missing pointer increment meant that not only was the same buffer being reused again and again, there was also no protection against using it simultaneously for multiple transfers. Fix that basic bug, and also move a similar increment to before the transfer is started, which feels less racy. See: raspberrypi#6919 Signed-off-by: Phil Elwell <[email protected]>
Use the PIO hardware on RP1 to implement a PWM interface. Signed-off-by: Phil Elwell <[email protected]> pwm: rp1: use pwmchip_get_drvdata() instead of container_of() The PWM framework may not embed struct pwm_chip within the driver’s private data. Using container_of() can result in accessing invalid memory or NULL pointers, especially after recent kernel changes. Switch to pwmchip_get_drvdata() to reliably access the driver data. This resolves kernel warnings and probe failures seen after updating from kernel 6.12.28 to 6.12.34 [1] While at it remove the now obsolete `struct pwm_chip chip` member from `struct pwm_pio_rp1`. [1] raspberrypi#6971 Signed-off-by: Nicolai Buchwitz <[email protected]>
ws2812-pio-rp1 is a PIO-based driver for WS2812 LEDS. It creates a character device in /dev, the default name of which is /dev/leds<n>, where <n> is the instance number. The number of LEDS should be set in the DT overlay, as should whether it is RGB or RGBW, and the default brightness. Write data to the /dev/* entry in a 4 bytes-per-pixel format in RGBW order: RR GG BB WW RR GG BB WW ... The white values are ignored unless the rgbw flag is set for the device. To change the brightness, write a single byte to offset 0, 255 being full brightness and 0 being off. Signed-off-by: Phil Elwell <[email protected]>
Using increased bit depth for no reason increases power consumption, and differs from the behaviour prior to the conversion to use the HDMI helper functions. Initialise the state max_bpc and requested_max_bpc to the minimum value supported. This only affects Raspberry Pi, as the other users of the helpers (rockchip/inno_hdmi and sunx4i) only support a bit depth of 8. Signed-off-by: Dave Stevenson <[email protected]>
DSI0 and DSI1 have different widths for the command FIFO (24bit vs 32bit), but the driver was assuming the 32bit width of DSI1 in all cases. DSI0 also wants the data packed as 24bit big endian, so the formatting code needs updating. Handle the difference via the variant structure. Signed-off-by: Dave Stevenson <[email protected]>
The Raspberry Pi RP1 chip has the Cadence GEM ethernet controller, so add a compatible string for it. Signed-off-by: Dave Stevenson <[email protected]>
Enable support for the Maxim DS2430A 256-Bit 1-Wire EEPROM. Signed-off-by: Nicolai Buchwitz <[email protected]>
Copy the firmware's handling of FSTROBE, but using module parameters instead of config.txt entries. Signed-off-by: Dave Stevenson <[email protected]>
Extend the LED control features of the led-modes property by adding a led-swap property. This allows the same led-modes values to be used across designs where the LED assignments differ. Signed-off-by: Phil Elwell <[email protected]>
…it PCIe DMA" This reverts commit a23cf5f. Signed-off-by: Jonathan Bell <[email protected]>
Adding a second inbound bridge window at <4GB for the MIP causes SWIOTLB allocations to overflow/fail. See tail of raspberrypi#7046 A simple fix is to switch to the RC-provided MSI target. Signed-off-by: Jonathan Bell <[email protected]>
Enable support for the VEML6030 light sensor family. See: raspberrypi#7048 Signed-off-by: Phil Elwell <[email protected]>
Add a veml6030 parameter to the i2c-sensor overlay. Signed-off-by: Phil Elwell <[email protected]>
Add more Vishay ambient light sensors. Signed-off-by: Phil Elwell <[email protected]>
Replace one-element array with flexible-array member to fix: [ 11.725017] ------------[ cut here ]------------ [ 11.725038] memcpy: detected field-spanning write (size 4) of single field "hdr->body" at drivers/staging/vc04_services/vc-sm-cma/vc_sm_cma_vchi.c:130 (size 0) [ 11.725113] WARNING: CPU: 3 PID: 455 at drivers/staging/vc04_services/vc-sm-cma/vc_sm_cma_vchi.c:130 vc_vchi_cmd_create+0x1a8/0x1d0 [vc_sm_cma] Signed-off-by: Juerg Haefliger <[email protected]>
Put particularly the PHY registers into order, bitmasks defined alongside the registers, and Use tabs for indentation. Signed-off-by: Dave Stevenson <[email protected]>
There was lots of register definition information dumped from the some source into the driver but unused. Remove it, and format the remaining lines according to the Linux kernel coding style. Signed-off-by: Dave Stevenson <[email protected]>
The D-PHY on RP1 support lane polarity swapping, and there is a standard device tree mechanism for configuring this, so tie the two together. Signed-off-by: Dave Stevenson <[email protected]>
The PL011 driver in this downstream kernel tree supports an extra compatible string - arm,pl011-axi - for use by RP1. This registers as a platform driver, not an AMBA driver, and has the advantage of responding to dynamic Device Tree changes such as loading one of the "uart<n>" overlays. Change all of the downstream Raspberry Pi dts files to use the new compatible string. At the same time, remove the override of the periphid as the upstream code now has the correct value. See: raspberrypi#7019 Signed-off-by: Phil Elwell <[email protected]>
The enum binning_mode is redundant, it only uses values from the earlier defined binning modes. Remove it. Signed-off-by: Naushir Patuck <[email protected]>
At a high FPS with RAW10, there is frame corruption for 480p because the rate_factor of 2 is used with the normal 2x2 bining [1]. This commit ties the rate_factor to the selected binning mode. For the 480p mode, analog 2x2 binning mode with a rate_factor of 2 is always used. For the 1232p mode the normal 2x2 binning mode is used for RAW10 while analog 2x2 binning mode is used for RAW8. [1] raspberrypi#5493 Signed-off-by: Vinay Varma <[email protected]> Signed-off-by: Dave Stevenson <[email protected]> Signed-off-by: Naushir Patuck <[email protected]> Reworked due to upstream changes
Allocate space for level-2 IOMMU translation tables on demand. This should save memory in most cases but means that map_pages() can now fail with -ENOMEM. Unused pages are retained for re-use. Move all dma_sync* calls into map and unmap functions rather than batching them up. This makes it easier to ensure they are safely balanced, now that the tables are held as separate pages. Add OF properties to override the default aperture size (2GB) and base address (40GB); this doesn't include any dma-iova-offset. Various tidy-ups. The internal representation of aperture limits *does* include dma_iova_offset, as that is more commonly useful. Clarify the distinction between Linux pages and IOMMU table pages. Fix wrong definition of MMMU_CTRL_PT_INVALID_EN flag. Signed-off-by: Nick Hollinghurst <[email protected]>
This is largely to test a previous change that made IOMMU aperture configurable and allocated lazily; it may be useful in its own right. We expect IOMMU2 to be well-utilized e.g. when using 64MPix cameras. Signed-off-by: Nick Hollinghurst <[email protected]>
Change-Id: Ic95c8514271d246dd668631810e8dee210f7f1b4 Signed-off-by: Yanghaku <[email protected]>
6by9
force-pushed
the
rpi-6.17.y-pcie-gpu
branch
from
c386ffd to
d352ac5
Compare
Signed-off-by: Dave Stevenson <[email protected]>
6by9
force-pushed
the
rpi-6.17.y-pcie-gpu
branch
from
d352ac5 to
d783ebd
Compare
Taken from https://github.com/chimera-linux/cports/blob/master/main/linux-stable/patches/xe-nonx86.patch Signed-off-by: Dave Stevenson <[email protected]>
…node") We lost a line in the forward port, which meant that it always used /dev/fb0, and complained that the sysfs nodes already existed. Fixes: 5769e04 ("fbdev: Allow client to request a particular /dev/fbN node") Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Dave Stevenson <[email protected]>
|
👀 |
This was referenced Oct 1, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Wanted for the CI builds.