Connect new radeonkms firmware files to build.

[juikim]

Some firmware files for radeonkms were not connected to build. It prevented us from loading radeonkms.ko for those GPUs.

[iotamudelta]

One issue is that radeonkms is not supported by the drm-next code yet. I believe the radeonkms module should load in principle (different from amdkfd) but the few people who have access to such old hardware did not get it working and our priority is newer hardware.

[iotamudelta]

I'll merge and update this in the graphics/gpu-firmware-kmod port. Thanks!

[juikim]

One issue is that radeonkms is not supported by the drm-next code yet. I believe the radeonkms module should load in principle (different from amdkfd) but the few people who have access to such old hardware did not get it working and our priority is newer hardware.

I perfectly understand the priority. However, I wanted to make sure users can try it out. In fact, I have many "old" Radeon GPUs and I know it does not work. The biggest issue is monitors are not detected because Linux i2c to FreeBSD iic shim does not exist in linuxkpi AFAICT. :-(

[mattmacy]

I perfectly understand the priority. However, I wanted to make sure users can try it out. In fact, I have many "old" Radeon GPUs and I know it does not work. The biggest issue is monitors are not detected because Linux i2c to FreeBSD iic shim does not exist in linuxkpi AFAICT. :-(

Uhm - do you think amdgpu would work at all if linux_i2c emulation weren't complete for its purposes? It's not connected to FreeBSD's iic, because the latter is a decade behind and has an interface completely unsuited to the task.

You might look for tunables. There's one in amdgpu, that if left set to the default won't allow amdgpu to determine the correct monitor resolution on my UHD display.

[juikim]

Uhm - do you think amdgpu would work at all if linux_i2c emulation weren't complete for its purposes? It's not connected to FreeBSD's iic, because the latter is a decade behind and has an interface completely unsuited to the task.

I think it might.

You might look for tunables. There's one in amdgpu, that if left set to the default won't allow amdgpu to determine the correct monitor resolution on my UHD display.

I guess you're talking about hw_i2c stuff? Yes, I have seen that one. It works for certain cases but it's just a stopgap, AFAIK.

[mattmacy]

I guess you're talking about hw_i2c stuff? Yes, I have seen that one. It works for certain cases but it's just a stopgap, AFAIK.

That's the one I'm thinking of. I consider it an (upstream) amdgpu bug that it's even necessary at all.

Barring unforeseen circumstances I'll be updating DRM & amdgpu to 4.14 starting on the 8th and then getting amdkfd to work. My primary target is going to be Vega GPGPU compute support. How best to keep i915 in sync is an open question. It is both the most time consuming to track and the least useful commercially.

I definitely will not have time to work on Radeon. We of course welcome patches to linux_i2c.c to fix any probe issues. I gave an older card to @markjdb so there is some possibility that he can be cajoled in to looking at it if properly bribe^H^H^H^H^Hmotivated.

[markjdb]

Those cards are currently being shipped across several time zones; it'll be a couple of weeks before I can use them again. AFAIR, they all worked with amdgpu; I'm not sure how many cards are supported by both drivers.

[juikim]

We of course welcome patches to linux_i2c.c to fix any probe issues. I gave an older card to @markjdb so there is some possibility that he can be cajoled in to looking at it if properly bribe^H^H^H^H^Hmotivated.

I think we can reuse some i2c code from the in-kernel drm.

[mattmacy]

@markjdb only one of them works with the Radeon driver IIUC. The Fiji and Polaris cards both require amdgpu.

[mattmacy]

@juikim if you can extract the requisite bits that would be great. As far as I could tell, reconciling iic with the requirements of linux i2c was more work than benefit, but maybe you'll do better.

[juikim]

With hw_i2c=1 for radeonkms.ko, Turks kinda works but I see the following errors:

[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v1_0_start] UVD not responding, giving up!!!
drmn0: failed initializing UVD (-1).
[drm:r600_ib_test] radeon: fence wait timed out.
[drm:radeon_ib_ring_tests] radeon: failed testing IB on GFX ring (-60).
[drm:radeon_device_init] ib ring test failed (-60).

and acceleration is disabled, of course.

I also noticed weird connector names but it is the same with or without hw_i2c=1.

[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   <C0>\^AMI-A-1
[drm]   HPD4
[drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c
[drm]   Encoders:
[drm]     DFP1: INTERNAL_UNIPHY2
[drm] Connector 1:
[drm]   <C0>\^AI-I-1
[drm]   HPD1
[drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c
[drm]   Encoders:
[drm]     DFP2: INTERNAL_UNIPHY
[drm] Connector 2:
[drm]   <C0>\^AA-1
[drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[drm]   Encoders:
[drm]     CRT1: INTERNAL_KLDSCP_DAC1

Without hw_i2c=1, it just fails to detect any monitors:

[drm:drm_edid_block_valid] EDID checksum is invalid, remainder is 130
Raw EDID:
         00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
[drm:drm_edid_block_valid] EDID checksum is invalid, remainder is 130
Raw EDID:
         00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
[drm:drm_edid_block_valid] EDID checksum is invalid, remainder is 130
Raw EDID:
         00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
[drm:drm_edid_block_valid] EDID checksum is invalid, remainder is 130
Raw EDID:
         00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
         ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
drmn0: <C0>\^AI-I-1: EDID block 0 invalid.
[drm:radeon_dvi_detect] <C0>\^AI-I-1: probed a monitor but no|invalid EDID

Note <C0>\^AMI-A-1 is HDMI-A-1, <C0>\^AI-I-1 is DVI-I-1, and <C0>\^AA-1 is VGA-1.

[mattmacy]

@juikim Ugh. Have you tried disabling efifb? Yes - it means you're flying blind once the kernel boots :-( But that is necessary to avoid a similar problem on Carrizzo. In general, figuring out how the hardware works from the driver alone has always felt a bit like a medieval monk trying to understand how an internal combustion engine works.

Starting the 5th I'll have something approximating a professional relationship with AMD. Getting Vega chip docs is my first order of business, but I'll see if I can get docs for older chips as well.

[mattmacy]

@jmd what is the tunable to disable efifb that you need to use?

[mattmacy]

@juikim Ring set up failure is usually a conflict with the efifb mappings. Try setting hw.syscons.disable="1" in your loader.conf

[juikim]

@juikim Ring set up failure is usually a conflict with the efifb mappings. Try setting hw.syscons.disable="1" in your loader.conf

With that and "hw_i2c=1", Pitcairn at home works. Interesting. I'll try that on Turks at work tomorrow. Thanks for the hint!

[mattmacy]

@juikim Cool!

If Turks works as well, file an issue specifically regarding dropping the efifb mappings. It's been known for a very long time (it's the only way to get Carrizzo to work on an efi install), but there are so many issues flying around that it's been low priority because there's a workaround.

[juikim]

Yes, Turks works, too. :-)

[mattmacy]

@juikim Excellent! I'll try to find time to fix the efifb issue when I merge up to 4.14 in a week and a half.