Re: Radeon HD 2600 XT, DVI outputs
On 2022-08-18 20:54, Alex Deucher wrote: On Thu, Aug 18, 2022 at 8:29 AM Andriy Gapon wrote: On 2022-08-16 12:01, Christian König wrote: Hi Andriy, well first of all can you please test that with Linux? If this works on Linux then there is probably just something missing on the FreeBSD port. Thank you for the suggestion. This is something that I should have tested from the start. But I was overly confident that the problem could not be a port problem as the hardware is so ancient and the port exists for quite a long while and it's currently on the Linux 5.10 level. But, yes, it is a port problem after all. I tested Debian with 5.10 kernel and the problem does not exist there. Here are some log messages from Linux: [ 397.379974] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:46:DVI-I-1] [ 397.395520] [drm:radeon_atom_dac_detect [radeon]] Bios 0 scratch 2 0014 [ 397.395534] [drm:radeon_atombios_connected_scratch_regs [radeon]] DFP1 disconnected [ 397.395546] [drm:radeon_atombios_connected_scratch_regs [radeon]] CRT2 disconnected [ 397.395550] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:46:DVI-I-1] status updated from unknown to disconnected [ 397.395553] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:46:DVI-I-1] disconnected [ 397.395557] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:DIN-1] [ 397.411838] [drm:radeon_atom_dac_detect [radeon]] Bios 0 scratch 2 0014 [ 397.411856] [drm:radeon_atombios_connected_scratch_regs [radeon]] TV1 disconnected [ 397.411864] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:DIN-1] status updated from unknown to disconnected [ 397.411867] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:DIN-1] disconnected [ 397.411873] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:50:DVI-I-2] [ 397.446829] [drm:drm_add_display_info [drm]] Supported Monitor Refresh rate range is 0 Hz - 0 Hz [ 397.446833] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 397.446845] [drm:radeon_atombios_connected_scratch_regs [radeon]] CRT1 disconnected [ 397.446855] [drm:radeon_atombios_connected_scratch_regs [radeon]] DFP2 connected I guess that this tells us that the monitor (DVI-I-2 + DFP2) is detected using some other method, so the detection does need to invoke radeon_atom_dac_detect for it. I guess that radeon_dvi_detect() is what is responsible for detecting DVI monitor connections. So, it looks like the difference could be in DDC / EDID probing. DVI-I connectors support both analog and digital encoders so the driver has to determine which type of monitor is connected so that it can enable the right encoder. If an EDID is available, we can check the digital bit to determine which encoder should be used. If there is no EDID, it gets more complicated. At that point we have to try and determine what type based on the hotplug detect pin or load detection on the DAC. Thank you very much for all the help. The problem turned out to be in FreeBSD support for bit-banging I2C. Hardware I2C found on newer cards was not affected, so the problem went under the radar. -- Andriy Gapon https://standforukraine.com https://razomforukraine.org
Re: Radeon HD 2600 XT, DVI outputs
On 2022-08-16 12:01, Christian König wrote: Hi Andriy, well first of all can you please test that with Linux? If this works on Linux then there is probably just something missing on the FreeBSD port. Thank you for the suggestion. This is something that I should have tested from the start. But I was overly confident that the problem could not be a port problem as the hardware is so ancient and the port exists for quite a long while and it's currently on the Linux 5.10 level. But, yes, it is a port problem after all. I tested Debian with 5.10 kernel and the problem does not exist there. Here are some log messages from Linux: [ 397.379974] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:46:DVI-I-1] [ 397.395520] [drm:radeon_atom_dac_detect [radeon]] Bios 0 scratch 2 0014 [ 397.395534] [drm:radeon_atombios_connected_scratch_regs [radeon]] DFP1 disconnected [ 397.395546] [drm:radeon_atombios_connected_scratch_regs [radeon]] CRT2 disconnected [ 397.395550] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:46:DVI-I-1] status updated from unknown to disconnected [ 397.395553] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:46:DVI-I-1] disconnected [ 397.395557] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:DIN-1] [ 397.411838] [drm:radeon_atom_dac_detect [radeon]] Bios 0 scratch 2 0014 [ 397.411856] [drm:radeon_atombios_connected_scratch_regs [radeon]] TV1 disconnected [ 397.411864] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:DIN-1] status updated from unknown to disconnected [ 397.411867] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:48:DIN-1] disconnected [ 397.411873] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:50:DVI-I-2] [ 397.446829] [drm:drm_add_display_info [drm]] Supported Monitor Refresh rate range is 0 Hz - 0 Hz [ 397.446833] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 397.446845] [drm:radeon_atombios_connected_scratch_regs [radeon]] CRT1 disconnected [ 397.446855] [drm:radeon_atombios_connected_scratch_regs [radeon]] DFP2 connected I guess that this tells us that the monitor (DVI-I-2 + DFP2) is detected using some other method, so the detection does need to invoke radeon_atom_dac_detect for it. I guess that radeon_dvi_detect() is what is responsible for detecting DVI monitor connections. So, it looks like the difference could be in DDC / EDID probing. Am 16.08.22 um 10:48 schrieb Andriy Gapon: Out of necessity I had to use an ancient Radeon HD 2600 XT card. It has two DVI outputs (and one S-video). I noticed a curious problem, if I attach a monitor to either of the DVI outputs, then initially there is video output but as soon as radeonkms driver attaches the monitor goes blank. But if I attach the same monitor to either of the outputs using its VGA input and DVI->VGA converter, then the video works fine all the time. I tested the monitor's DVI input with a different machine and there it works just fine (and, as I said, it also works fine before radeonkms is loaded). Here is a piece of output from the driver with the direct DVI attachment: [drm] Radeon Display Connectors [drm] Connector 0: [drm] DVI-I-1 [drm] HPD1 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_KLDSCP_TMDS1 [drm] CRT2: INTERNAL_KLDSCP_DAC2 [drm] Connector 1: [drm] DIN-1 [drm] Encoders: [drm] TV1: INTERNAL_KLDSCP_DAC2 [drm] Connector 2: [drm] DVI-I-2 [drm] HPD2 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] DFP2: INTERNAL_LVTM1 drmn0: [drm] Cannot find any crtc or sizes The same scenario with additional diagnostics: https://people.freebsd.org/~avg/radeon-2600-dvi-dvi.txt And here is with the DVI->VGA configuration: [drm] Radeon Display Connectors [drm] Connector 0: [drm] DVI-I-1 [drm] HPD1 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_KLDSCP_TMDS1 [drm] CRT2: INTERNAL_KLDSCP_DAC2 [drm] Connector 1: [drm] DIN-1 [drm] Encoders: [drm] TV1: INTERNAL_KLDSCP_DAC2 [drm] Connector 2: [drm] DVI-I-2 [drm] HPD2 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] DFP2: INTERNAL_LVTM1 [drm] fb mappable at 0xE0243000 [drm] vram apper at 0xE000 [drm] size 3145728 [drm] fb depth is 24 [drm] pitch is 4096 The same scenario with additional diagnostics: https://people.freebsd.org/~avg/radeon-2600-dvi-vga.txt Not sure if this is something with the hardware... Thanks! -- Andriy Gapon https://standforukraine.com https://razomforukraine.org
Radeon HD 2600 XT, DVI outputs
Out of necessity I had to use an ancient Radeon HD 2600 XT card. It has two DVI outputs (and one S-video). I noticed a curious problem, if I attach a monitor to either of the DVI outputs, then initially there is video output but as soon as radeonkms driver attaches the monitor goes blank. But if I attach the same monitor to either of the outputs using its VGA input and DVI->VGA converter, then the video works fine all the time. I tested the monitor's DVI input with a different machine and there it works just fine (and, as I said, it also works fine before radeonkms is loaded). Here is a piece of output from the driver with the direct DVI attachment: [drm] Radeon Display Connectors [drm] Connector 0: [drm] DVI-I-1 [drm] HPD1 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_KLDSCP_TMDS1 [drm] CRT2: INTERNAL_KLDSCP_DAC2 [drm] Connector 1: [drm] DIN-1 [drm] Encoders: [drm] TV1: INTERNAL_KLDSCP_DAC2 [drm] Connector 2: [drm] DVI-I-2 [drm] HPD2 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] DFP2: INTERNAL_LVTM1 drmn0: [drm] Cannot find any crtc or sizes The same scenario with additional diagnostics: https://people.freebsd.org/~avg/radeon-2600-dvi-dvi.txt And here is with the DVI->VGA configuration: [drm] Radeon Display Connectors [drm] Connector 0: [drm] DVI-I-1 [drm] HPD1 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_KLDSCP_TMDS1 [drm] CRT2: INTERNAL_KLDSCP_DAC2 [drm] Connector 1: [drm] DIN-1 [drm] Encoders: [drm] TV1: INTERNAL_KLDSCP_DAC2 [drm] Connector 2: [drm] DVI-I-2 [drm] HPD2 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] DFP2: INTERNAL_LVTM1 [drm] fb mappable at 0xE0243000 [drm] vram apper at 0xE000 [drm] size 3145728 [drm] fb depth is 24 [drm]pitch is 4096 The same scenario with additional diagnostics: https://people.freebsd.org/~avg/radeon-2600-dvi-vga.txt Not sure if this is something with the hardware... Thanks! -- Andriy Gapon https://standforukraine.com https://razomforukraine.org
[PATCH] amdgpu_acpi: add backlight control for the DC case
This uses backlight_device_set_brightness() to set the brightness
level requested via ATIF.
Signed-off-by: Andriy Gapon
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 1e41367ef74ee..a8157a5154243 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -444,7 +444,6 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
DRM_DEBUG_DRIVER("ATIF: %d pending SBIOS requests\n", count);
- /* todo: add DC handling */
if ((req.pending & ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST) &&
!amdgpu_device_has_dc_support(adev)) {
struct amdgpu_encoder *enc = atif->encoder_for_bl;
@@ -463,6 +462,25 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
#endif
}
}
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+ if ((req.pending & ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST) &&
+ amdgpu_device_has_dc_support(adev)) {
+ struct amdgpu_display_manager *dm = >dm;
+ struct backlight_device *bd = dm->backlight_dev;
+
+ if (bd) {
+ DRM_DEBUG_DRIVER("Changing brightness to %d\n",
+req.backlight_level);
+
+ /*
+* XXX backlight_device_set_brightness() is
+* hardwired to post BACKLIGHT_UPDATE_SYSFS.
+* It probably should accept 'reason' parameter.
+*/
+ backlight_device_set_brightness(bd,
req.backlight_level);
+ }
+ }
+#endif
if (req.pending & ATIF_DGPU_DISPLAY_EVENT) {
if (adev->flags & AMD_IS_PX) {
pm_runtime_get_sync(adev->ddev->dev);
--
2.22.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] amdgpu_acpi: add backlight control for the DC case
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 1e41367ef74ee..a8157a5154243 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -444,7 +444,6 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
DRM_DEBUG_DRIVER("ATIF: %d pending SBIOS requests\n", count);
- /* todo: add DC handling */
if ((req.pending & ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST) &&
!amdgpu_device_has_dc_support(adev)) {
struct amdgpu_encoder *enc = atif->encoder_for_bl;
@@ -463,6 +462,25 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
#endif
}
}
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+ if ((req.pending & ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST) &&
+ amdgpu_device_has_dc_support(adev)) {
+ struct amdgpu_display_manager *dm = >dm;
+ struct backlight_device *bd = dm->backlight_dev;
+
+ if (bd) {
+ DRM_DEBUG_DRIVER("Changing brightness to %d\n",
+req.backlight_level);
+
+ /*
+* XXX backlight_device_set_brightness() is
+* hardwired to post BACKLIGHT_UPDATE_SYSFS.
+* It probably should accept 'reason' parameter.
+*/
+ backlight_device_set_brightness(bd,
req.backlight_level);
+ }
+ }
+#endif
if (req.pending & ATIF_DGPU_DISPLAY_EVENT) {
if (adev->flags & AMD_IS_PX) {
pm_runtime_get_sync(adev->ddev->dev);
--
2.22.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: amdgpu, dc, backlight brightness
On 29/04/2020 21:15, Alex Deucher wrote:
> I think it varies from OEM to OEM and whatever windows required at the
> time. The sbios may also do different things depending on the osi
> string passed to ACPI. Originally, ACPI handled it all directly.
> Then we got some laptops which which did the whole event via ATIF
> thing (even that I think varied based on the . Later, I think the
> keys just produced brightness events and it was up to the OS to do
> something with them so the user's environment would catch the events
> and adjust the backlight via the standard OS backlight control
> interface. We never hooked up the ATIF stuff to DC since I don't
> recall ever running into any laptops that used it for backlight
> control (the code was carried over from radeon when we forked amdgpu).
Thank you for the information!
Indeed, I see that there are so many quirks in how brightness keys are handled
by firmware. Ranging from actually changing the brightness to posting ACPI
events to posting key codes. And then those options are not exclusive of each
other.
Just in case, I've written a bit of code for ATIF handler to control the
backlight in the DC case. I doubt that it is very useful, it was mostly an
exercise for myself.
commit ed2ca1d7e3fbdb641d9a1bc2de9b88e2927ff1bd
Author: Andriy Gapon
Date: Thu Apr 30 14:47:11 2020 +0300
amdgpu_acpi: perform automatic backlight adjustment in the DC case too
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 04bbd8f41441c..62fbae1177091 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -444,7 +444,6 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
DRM_DEBUG_DRIVER("ATIF: %d pending SBIOS requests\n", count);
- /* todo: add DC handling */
if ((req.pending & ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST) &&
!amdgpu_device_has_dc_support(adev)) {
struct amdgpu_encoder *enc = atif->encoder_for_bl;
@@ -463,6 +462,34 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
#endif
}
}
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+ if ((req.pending & ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST) &&
+ amdgpu_device_has_dc_support(adev)) {
+ struct amdgpu_display_manager *dm = >dm;
+ struct backlight_device *bd = dm->backlight_dev;
+
+ if (bd) {
+ DRM_DEBUG_DRIVER("Changing brightness to %d\n",
+req.backlight_level);
+
+ /*
+* Newer Linux has
+* backlight_device_set_brightness, but it is
+* hardwired to post BACKLIGHT_UPDATE_SYSFS.
+*/
+ mutex_lock(>ops_lock);
+ if (bd->ops &&
+ req.backlight_level <=
bd->props.max_brightness) {
+ bd->props.brightness =
req.backlight_level;
+ backlight_update_status(bd);
+ }
+ mutex_unlock(>ops_lock);
+#if 0
+ backlight_generate_event(bd,
BACKLIGHT_UPDATE_HOTKEY);
+#endif
+ }
+ }
+#endif
if (req.pending & ATIF_DGPU_DISPLAY_EVENT) {
if ((adev->flags & AMD_IS_PX) &&
amdgpu_atpx_dgpu_req_power_for_displays()) {
--
Andriy Gapon
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amdgpu, dc, backlight brightness
I see that amdgpu_atif_handler() has this comment and code:
/* todo: add DC handling */
if ((req.pending & ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST) &&
!amdgpu_device_has_dc_support(adev)) {
...
}
So, this makes me curious how a typical Linux distribution handles backlight
brightness change via special keys hooked to ACPI.
This is what I see on FreeBSD.
- a special key is pressed
- there is a bunch of uninteresting ACPI and kernel stuff involving EC
- ACPI notification 0x86 on VGA.LCD device is handled by acpi_video driver
- the driver invokes VGA.LCD._BCM method
- if I read the ASL of my system correctly, ACPI does not touch any hardware
but simply saves some things like the requested brightness level
- then ACPI posts notification 0x81 on VGA device
- the notification gets routed to amdgpu
- amdgpu invokes VGA.ATIF and gets some interesting data from ACPI
- and this is where things stop in the DC case (because of the code above)
In the non-DC case amdgpu would actually set the brightness based on the data
returned from ATIF. radeon driver also did the same as far as I can see.
So, how things work in the DC case?
I see that Linux acpi_video does something that FreeBSD doesn't do, it posts
KEY_BRIGHTNESSUP / KEY_BRIGHTNESSDOWN / etc. I guess that in the end this is
similar to just having the corresponding multimedia keys on a keyboard.
Is this how the brightness control supposed to work?
So, there must be some userland program listening for those keys and somehow
knowing about amdgpu backlight controls (e.g., /sys/class/backlight/amdgpu_bl0).
Is that correct?
I tried a live image of Void Linux (LXQT flavor). While it does handle the
special brightness keys it seems to do it without actually controlling the
backlight. That is, it makes the picture lighter / darker, but values under
/sys/class/backlight/amdgpu_bl0 do not change. If I set brightness under
/sys/class/backlight/amdgpu_bl0 to some low level then the brightness up key
cannot make the screen brighter. So, it appears to be just a rendering /
composition trick.
Thank you.
--
Andriy Gapon
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: FreeBSD / amdgpu / Vega 3, pstate TEST_DEBUG_DATA: 0x0
On 24/04/2020 20:22, Harry Wentland wrote: > On 2020-04-24 8:34 a.m., Andriy Gapon wrote: >> >> First, I understand that my platform is not directly supported and probably >> not >> very interesting, but I still hope to get some tips or pointers. >> > > Hi Andriy, > > yeah, limited insight here since FreeBSD isn't something I'm familiar > with. :) Harry, thanks a lot for your help. It set me on a right path, although a bit indirectly :-) Let me start by saying that I was able to fix the driver. After looking at the laptop in a dark room I could see that the backlight was actually on, but there was no video output. So, I went back to comparing FreeBSD and Linux logs, especially around the place where "TEST_DEBUG_DATA: 0x0" was reported. And then suddenly I spotted what I missed before. Linux reported 3 pipes while FreeBSD reported 4. And the errors were about the forth, non-existent, pipe -- I guess, not surprising at all. With some additional printfs I could confirm it for sure. So, then I looked for the code where the number of pipes is set and almost immediately could see the problem. FreeBSD amdgpu has DCN_VERSION_1_01 support ifdef-ed out, for whatever reason. Your commit "drm/amd/display: Drop DCN1_01 guards" has not been ported yet and CONFIG_DRM_AMD_DC_DCN1_01 is not defined. Of course, the number of pipes was not the only thing that did not match the actual hardware/firmware because of that. Once I set CONFIG_DRM_AMD_DC_DCN1_01 everything just worked. Thank you again! >> I am trying to get amdgpu/FreeBSD going on Motile M141 laptop with Ryzen 3 >> 3200U >> CPU that has Vega 3 graphics integrated. When amdgpu starts loading the >> screen >> goes black and never lights up again. I am not sure whether there is no >> signal >> at all or whether the backlight is turned off, but the screen is completely >> dark. I can blindly interact with the system, so it's not crashed or hung. >> From system logs I can see that the driver attaches successfully. It >> recognizes >> the hardware, loads its firmware, detects the eDP screen and so on. >> > > Does BSD have a way to check or set your backlight value manually (a la > /sys/class/backlight on linux)? If so I'd suggest checking and setting > it to non-zero values, ideally to max_brightness. > > Have you tried an external display? > >> The FreeBSD's amdgpu port that I am trying is based on code circa 5.0. >> There is no newer version ported. >> I tried a couple of Linux distros with 5.3.x kernels and they worked without >> any >> problems. So that gives me some hope. >> >> I compared driver messages (with drm_debug set to 0xfff) between Linux and >> FreeBSD and they look quite similar. Except for one thing. >> In the FreeBSD case there are these error messages that are not seen with >> Linux: >> >> [drm] pstate TEST_DEBUG_DATA: 0x0 >> WARNING !(0) failed at >> /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:868 >> #0 0x83451633 at linux_dump_stack+0x23 >> #1 0x8325a9ee at dcn10_verify_allow_pstate_change_high+0x4e >> #2 0x8325e925 at dcn10_wait_for_mpcc_disconnect+0x25 >> #3 0x8325de53 at dcn10_disable_plane+0x53 >> #4 0x8325c9f5 at dcn10_init_hw+0x755 >> #5 0x83295ca8 at dc_create+0x538 >> #6 0x8327a8da at dm_hw_init+0x1ea >> #7 0x831701d1 at amdgpu_device_init+0x1b11 >> #8 0x83185177 at amdgpu_driver_load_kms+0xd7 >> #9 0x833f138e at drm_dev_register+0x17e >> #10 0x83178dea at amdgpu_pci_probe+0x18a >> #11 0x83456f40 at linux_pci_attach+0x560 >> #12 0x80bf68ea at device_attach+0x3ca >> #13 0x80bf6490 at device_probe_and_attach+0x70 >> #14 0x80bf8358 at bus_generic_driver_added+0x58 >> #15 0x80bf4289 at devclass_driver_added+0x39 >> #16 0x80bf41c7 at devclass_add_driver+0x147 >> #17 0x83455ae9 at _linux_pci_register_driver+0xc9 >> >> That warning plus stack trace is actually BREAK_TO_DEBUGGER() in the original >> Linux code. >> So, that makes me think that the problem is pretty serious. > > BREAK_TO_DEBUGGER is probably overly scary here. It's somewhat a concern > as this means power consumption might be higher than expected. We've > seen this issue on several systems without any other adverse effects to > usability. > > Harry > >> I tried searching for "TEST_DEBUG_DATA: 0x0" and I could not find a single >> result with "0x0" in it. Usually there is some non-zero value. >> To me this looks like maybe some ha
FreeBSD / amdgpu / Vega 3, need help
First, I understand that my platform is not directly supported and probably not very interesting, but I still hope to get some tips or pointers. I am trying to get amdgpu/FreeBSD going on Motile M141 laptop with Ryzen 3 3200U CPU that has Vega 3 graphics integrated. When amdgpu starts loading the screen goes black and never lights up again. I am not sure whether there is no signal at all or whether the backlight is turned off, but the screen is completely dark. I can blindly interact with the system, so it's not crashed or hung. >From system logs I can see that the driver attaches successfully. It >recognizes the hardware, loads its firmware, detects the eDP screen and so on. The FreeBSD's amdgpu port that I am trying is based on code circa 5.0. There is no newer version ported. I tried a couple of Linux distros with 5.3.x kernels and they worked without any problems. So that gives me some hope. I compared driver messages (with drm_debug set to 0xfff) between Linux and FreeBSD and they look quite similar. Except for one thing. In the FreeBSD case there are these error messages that are not seen with Linux: [drm] pstate TEST_DEBUG_DATA: 0x0 WARNING !(0) failed at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:868 #0 0x83451633 at linux_dump_stack+0x23 #1 0x8325a9ee at dcn10_verify_allow_pstate_change_high+0x4e #2 0x8325e925 at dcn10_wait_for_mpcc_disconnect+0x25 #3 0x8325de53 at dcn10_disable_plane+0x53 #4 0x8325c9f5 at dcn10_init_hw+0x755 #5 0x83295ca8 at dc_create+0x538 #6 0x8327a8da at dm_hw_init+0x1ea #7 0x831701d1 at amdgpu_device_init+0x1b11 #8 0x83185177 at amdgpu_driver_load_kms+0xd7 #9 0x833f138e at drm_dev_register+0x17e #10 0x83178dea at amdgpu_pci_probe+0x18a #11 0x83456f40 at linux_pci_attach+0x560 #12 0x80bf68ea at device_attach+0x3ca #13 0x80bf6490 at device_probe_and_attach+0x70 #14 0x80bf8358 at bus_generic_driver_added+0x58 #15 0x80bf4289 at devclass_driver_added+0x39 #16 0x80bf41c7 at devclass_add_driver+0x147 #17 0x83455ae9 at _linux_pci_register_driver+0xc9 That warning plus stack trace is actually BREAK_TO_DEBUGGER() in the original Linux code. So, that makes me think that the problem is pretty serious. I tried searching for "TEST_DEBUG_DATA: 0x0" and I could not find a single result with "0x0" in it. Usually there is some non-zero value. To me this looks like maybe some hardware component is not turned on... Perhaps this is something relatively obvious for people that hack on the driver and the hardware. I hope to receive some hint about what to look for. I can cherry-pick commits from Linux, apply patches, add additional debugging logs, etc. FreeBSD amdgpu dmesg: https://people.freebsd.org/~avg/amdgpu.dmesg.txt Full Linux dmesg: https://people.freebsd.org/~avg/linux-5.3.0-28.dmesg.out And with with drm_debug=0xfff. FreeBSD: https://people.freebsd.org/~avg/fbsd-dmesg.txt Linux: https://people.freebsd.org/~avg/linux-5.3.9-dmesg.txt I see that both Linux and FreeBSD have similar messages about failing to load some microcode components, but I guess that it must be okay since Linux works: [4.487381] [drm] reserve 0x40 from 0xf400c0 for PSP TMR [4.564893] [drm] failed to load ucode id (12) [4.564894] [drm] psp command failed and response status is (-53233) [4.567891] [drm] failed to load ucode id (13) [4.567892] [drm] psp command failed and response status is (-65521) [4.570891] [drm] failed to load ucode id (14) [4.570892] [drm] psp command failed and response status is (-65521) Thank you! -- Andriy Gapon ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
