port-macppc/57370: Status of radeon DRM2 on powerpc

[j.p.bryn%zoho.com@localhost]

>Number:         57370
>Category:       port-macppc
>Synopsis:       Status of radeon DRM2 on powerpc
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-macppc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 19 11:30:00 +0000 2023
>Originator:     Jackson Bryn
>Release:        netbsd-current
>Organization:
>Environment:
>Description:
Two years ago, I had a hack that implemented pmap bus transfers from x86 and forced the console to turn on for radeondrmkmsfb. You need to hardcode the connector since we have no way of retrieving the device dictionary from within radeon drm2.

The results were that while I was able to technically boot into the console, there was no presence of a backlight and you could start an xf86-video-radeon session, although there was no 3D acceleration. RV

Now that proper pmap transfers including tracking are in macppc, I set aside to reenable radeondrmkms. I think the console reassignment hack is still needed, although I am not sure. When I compile the new kernel, it appears that when the module is loaded, the kernel gets stuck and never succeeds after the connector information is initialized. There is no sign of a kernel crash, which means that debugging it is almost hopeless. All you get is a blank signal.

Has anyone tested it so far? Contributions are hopeless for a minority architecture like this.
>How-To-Repeat:

>Fix: