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. |
popcornmix
force-pushed
the
rpi-6.17.y
branch
from
1d77945 to
4b60b95
Compare
|
@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. |
|
I've also just found and responded to a similar Intel patch on the kernel mailing list: https://lore.kernel.org/lkml/C67D4EC2-649C-4E46-A55D-8B48A31E8928@jeffgeerling.com/ Looks like that's been sent from the RISC-V side of things (they're also affected). |
6by9
force-pushed
the
rpi-6.17.y-pcie-gpu
branch
2 times, most recently
from
1a989d9 to
636da1c
Compare
Add an overlay to allow composite video to be output on GPIOs 4-11 on Raspberry Pi 5, 500, 500+ or CM5 only, with an optional 108 MHz clock on GPIO 0 and duplicate MSB on GPIO 27. Requires composite video to be enabled and DPI to be disabled. Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Switch the power management in the imx708 device driver to use auto- suspend with a 5s timeout. This improves mode switching time that avoids additional regulator switch-on delays and common register I2C writes. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
EMMC clock speeds are based around divisions of 52Mhz, not the 50MHz used by SD. As such, relax the "full speed" check (intended to stop any overclock whenever an operation has to be retried) so that any requested speed of 50MHz or higher will be overclocked. See: raspberrypi#7120 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
EMMC clock speeds are based around divisions of 52Mhz, not the 50MHz used by SD. As such, relax the "full speed" check (intended to stop any overclock whenever an operation has to be retried) so that any requested speed of 50MHz or higher will be overclocked. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Remove the need for the user to know the limitations of this PWM implementation by adjusting configuration requests to be the closest acceptable value. Add a get_state method so that the actual values can be queried. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Correct the set_period method to pass (period - 1), as required by the PIO state machine. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Waveshare_Team <support@waveshare.com>
Signed-off-by: Waveshare_Team <support@waveshare.com>
The non-pi5 variant of tc358743 needs to update the compatible of csi0 rather than csi1 if the cam0 override is used, otherwise it gets loaded in Media Controller mode. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Previously, if an HDMI display was connected at boot time when composite was enabled, the firmware FB would get "stuck" and a login console would not appear on either HDMI or composite. With the change, a console will now appear, typically (invariably?) on HDMI (just as happens with HDMI + DPI). This may be helpful when booting to CLI when composite was enabled accidentally and cannot be viewed. The old behaviour can be reinstated by adding the "nohdmi" option. Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Added CONFIG_INPUT_PWM_BEEPR=m for proper integration of audible feedback devices.
Added missing pinctrl configuration lines which enable pull-up on GPIO26.
Fix the whitespace before making any other changes. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to prevent confusing problems where pin configuration is not be applied, an upcoming change to the overlaycheck utility will add a check that all added pin groups are in some way referenced by the overlay. Before that can be done, it is necessary to ensure that all existing overlays pass that test. This patch modifies some overlays by adding the required "pinctrl-0" properties, but for others that are just setting GPIOs to inputs and outputs, where those same GPIOs are declared by <name>-gpios properties, it is better to drop the pin groups and let the GPIO subsystem set up the GPIOs as required. Removing this duplication may be helpful in the future should we ever decide to enable the exclusive GPIO vs pinctrl locking (.strict in struct pinmux_ops). See: https://forums.raspberrypi.com/viewtopic.php?t=393742 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
force-pushed
the
rpi-6.17.y
branch
from
e7324e9 to
fda4fa3
Compare
Leave pcie1/pciex1/nvme disabled unless a DT parameter is used. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Corrects typo that set that register to only be 8 bit. Fixes: 7736218 ("media: imx477: Convert to use V4L2_CCI library") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
As far as I know it's not an option that needs enabling. At least I can't see an obvious kernel config option for it. I don't have an AMD GPU hooked up at the moment, but does |
|
@6by9 it seems like |
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 <bo.yang@smail.nju.edu.cn> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
6by9
force-pushed
the
rpi-6.17.y-pcie-gpu
branch
from
f21db4b to
8b2bd17
Compare
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
6by9
force-pushed
the
rpi-6.17.y-pcie-gpu
branch
from
8b2bd17 to
2b3bec9
Compare
Yes, it looks like it's CONFIG_SND_HDA_INTEL and CONFIG_SND_HDA_CODEC_HDMI - PR rebased and updated. It seems to work on my R7 360, even though it complains about the 64-bit MSI address when the device only supports 32bit. Using Do watch out if you try blacklisting modules for test purposes - I'm not sure that everything plays nicely if you have snd_hda_intel loaded but not amdgpu. |
popcornmix
force-pushed
the
rpi-6.17.y
branch
from
d00d979 to
6b4e079
Compare
|
Sound working now, thanks! Is there a significant downside to using this 6.17 kernel on the rpi5? I guess this will not make it into rpi's default kernel for some time, if ever? I also noticed that Jeff's benchmarks - made on a modified 6.12 rpi-kernel and with different patches - were notably faster than mine ;-) I hope the potential of adding graphic or ai-cards with oculink cables should incentivize the RPi people to provide two pcie ports on the rpi6 ;-) Thanks again, this is cool! |
|
6.18 is now released and has been announced as the next LTS kernel (see https://www.kernel.org/category/releases.html), so will be the next Pi default kernel once it has had sufficient testing. With 6.18 being officially released, 6.17 (and hence this branch) is dropped. I've just rebased my branch that feeds #7113 as 6.18 for both AMD and Intel Xe cards. |
20 participants
Wanted for the CI builds.