6.17: Testing PCIe graphics cards on Pi5 (AMD only) #7072
Conversation
6by9
force-pushed
the
rpi-6.17.y-pcie-gpu
branch
2 times, most recently
from
d352ac5 to
d783ebd
Compare
|
👀 |
6by9
force-pushed
the
rpi-6.17.y-pcie-gpu
branch
from
8b1e2b1 to
fe3d35c
Compare
popcornmix
force-pushed
the
rpi-6.17.y
branch
from
df370fe to
06b5122
Compare
popcornmix
force-pushed
the
rpi-6.17.y
branch
from
e68b449 to
1d1d7d6
Compare
|
Would you be able to rebase this PR, mostly to get a nicer view of this PR against the rebased 6.17.y branch? Also, is there any semi-official word from Pi Towers if this has a chance of merging? It's certainly been stable for me across multiple iterations of testing on multiple generations of AMD and Intel GPUs... |
I don't think we want this to be in the pi tree but not in the upstream tree. Ideally any "correct" commits here should be submitted upstream. |
|
I need to tidy up the branch. AMD GPUs only need 70fe325 and the defconfig update. Module size for amdgpu is 2.5MB. I haven't tested with 16kB page sizes, so it may only apply to bcm2711_defconfig and not bcm2712_defconfig. We could add in radeon for the older cards (module size is 466kB), but it won't work with labwc / wlroots as the DRM driver doesn't support atomic updates. Intel Xe isn't quite there yet, and the places it calls into i915 are annoying. Easiest to drop it for now. The i915 changes were proposed by Mesa devs so may be acceptable to mainline. The BAR resizing patch is already being discussed upstream and has been looked at by P33M. (Module size is 814kB). nouveau is a fair way off, so that can just be dropped for now. (Module size is 632kB). |
6by9
force-pushed
the
rpi-6.17.y-pcie-gpu
branch
from
fe3d35c to
72c2683
Compare
|
Branch cleaned to have the minimal changes (6 lines) required to support AMD gpus (either amdgpu or radeon). Other cards are dropped. I'll try to find a few mins to propose these upstream in the next few days. |
|
@6by9 last night I was thinking about it — and indeed, the Intel changes, while simpler, need more time in the oven. It would be nice to get full AMD support, and it seems like the changes shouldn't be hard to make a case for. Until we get the Xe driver past the weird corrupt/glitchy graphics bug, it's fine having it separate. I'm still working on getting someone on the Intel driver side to take a look, it may be something simple! |
|
BTW I've created https://github.com/6by9/linux/tree/rpi-6.18.y-pcie-gpu with both the AMD and Intel changes in. |
Users are reporting running out of DLIST memory. Add a debugfs file to dump out all the allocations. Signed-off-by: Dave Stevenson <[email protected]>
We have a read-modify-write race when updating SCALER_DISPCTRL for underrun and end-of-frame interrupts. Ideally it would be fixed via a spinlock or similar, but that will require a reasonable amount of study to ensure we don't get deadlocks. The underrun reporting is only for debug, so disable it for now. Signed-off-by: Dave Stevenson <[email protected]>
The dmabuf import already checks that the backing buffer is contiguous and rejects it if it isn't. vc4 also requires that the buffer is in the bottom 1GB of RAM, and this is all correctly defined via dma-ranges. However the kernel silently uses swiotlb to bounce dma buffers around if they are in the wrong region. This relies on dma sync functions to be called in order to copy the data to/from the bounce buffer. DRM is based on all memory allocations being coherent with the GPU so that any updates to a framebuffer will be acted on without the need for any additional update. This is fairly fundamentally incompatible with needing to call dma_sync_ to handle the bounce buffer copies, and therefore we have to detect and reject mappings that use bounce buffers. Signed-off-by: Dave Stevenson <[email protected]>
DSI0 is misbehaving and needs to action things on vblank to work around it. Add a new hook to call across during vblank. Signed-off-by: Dave Stevenson <[email protected]>
The initialisation sequence differs slightly from the documentation in that the clocks are meant to be running before resets and similar. Signed-off-by: Dave Stevenson <[email protected]>
vc4_dsi_bridge_disable wasn't resetting things during shutdown, so add that in. Signed-off-by: Dave Stevenson <[email protected]>
Although the PIO throughput benefits from larger burst sizes, only the first two DMA channels support a burst size of 8 - the others are capped at 4. To avoid misconfiguring the PIO hardware, retrieve the actual max_burst value from the DMA channel's capabilities. Signed-off-by: Phil Elwell <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Replace the use of vcdbg with vclog, and correct the documentation URL. See: raspberrypi#7093 Signed-off-by: Phil Elwell <[email protected]>
See: raspberrypi#7091 Signed-off-by: Phil Elwell <[email protected]>
See: raspberrypi#7091 Signed-off-by: Phil Elwell <[email protected]>
…P Mode commit 3776c685ebe5f43e9060af06872661de55e80b9a upstream. Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. Cc: [email protected] Fixes: 18e2f61 ("brcmfmac: P2P action frame tx") Signed-off-by: Gokul Sivakumar <[email protected]> Acked-by: Arend van Spriel <[email protected]> Link: https://patch.msgid.link/[email protected] [Cc stable] Signed-off-by: Johannes Berg <[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: c91c9f2 ("fbdev: Allow client to request a particular /dev/fbN node") Signed-off-by: Dave Stevenson <[email protected]>
8851BU, 8852BU
There were various points where the loader was using uninitialised data, had the potential to run off the end of an array, or was handling core functions incorrectly. Fix these up. Also handle 24bpp and 32bpp framebuffers. Signed-off-by: Dave Stevenson <[email protected]>
The mappings are the reverse of r8g8b8 and r5g6b5 respectively Signed-off-by: Dave Stevenson <[email protected]>
Modify the PDAF Datatype of the Arducam 64MP camera from 0x30 to 0x12 so that the Raspberry Pi 5 cfe driver can receive PDAF data. Signed-off-by: Lee Jackson <[email protected]>
popcornmix
force-pushed
the
rpi-6.17.y
branch
from
1d77945 to
4b60b95
Compare
This driver will be installed through DKMS going forward. Signed-off-by: Naushir Patuck <[email protected]>
Remove CONFIG_MEDIA_PCI_HAILO from all the arm64 defconfig files as this driver is no longer built in the kernel tree. Signed-off-by: Naushir Patuck <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
Add support for the AD799[1,2,3,4,5,7,8,9] ADCs to the i2c-sensor overlay. Signed-off-by: Phil Elwell <[email protected]>
|
@6by9 - I was thinking it would be nice to have a PR open on this repo for the convenience of users who want to just do an rpi-update to it (instead of a full kernel recompile). If I create and maintain a PR will it still trigger the same build process as yours? Or would updating it every few weeks or once a month create any undue burden on the RPi CI infrastructure? Just wanting to make it easier for people to test, since recompiling the kernel is a step too far for some. |
Pass-through mode disables all gamma and brightness processing, sending the raw pixel data directly to the LEDs. It is enabled by setting the brightness to zero, either in Device Tree or using the runtime method of writing a single byte (in this case 0) to the device. See: raspberrypi#7108 Signed-off-by: Phil Elwell <[email protected]>
|
I've also just found and responded to a similar Intel patch on the kernel mailing list: https://lore.kernel.org/lkml/[email protected]/ Looks like that's been sent from the RISC-V side of things (they're also affected). |
Various PCIe controllers on ARM64 platforms don't support cache snooping, which leads to numerous issues when attempting to use PCIe graphics cards. Switching ttm_prot_from_caching to return pgprot_dmacoherent for ttm_cached pages solves the issue, albeit with a performance hit. There is a second check in ttm_prot_from_caching that also needs updating. Signed-off-by: Yang Bo <[email protected]> Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Dave Stevenson <[email protected]>
6by9
force-pushed
the
rpi-6.17.y-pcie-gpu
branch
2 times, most recently
from
1a989d9 to
636da1c
Compare
|
#7113 for a 6.18 kernel with AMD and Xe enabled. I'll try to remember to bump it every so often. (Just bumped this 6.17 branch). There are a couple of issues with 6.18 that are still to be worked through, so use with caution. 6.17 should be fairly stable. Anyone can create a PR. Contributors without a couple of merged PRs require manual triggering to run the CI workflows. |
|
Thanks! And for tracking, could you change the title of this one to maybe say |
6by9
changed the title
Subjects updated to include the kernel version targeted, and which cards they cover. |
popcornmix
force-pushed
the
rpi-6.17.y
branch
from
025a969 to
b115fba
Compare
26 participants
Wanted for the CI builds.