HDMI Audio screwed up w/ recent kernels
>>>>> "AD" == Alex Deucher writes: AD> The GPU firmware is not involved in display or audio at all. Oh. Thanks for that! In that case the bug showed up some time between 3.19.0 and 4.1.0. git tag tells me 3.19 was the last 3. Only 14.56+ bits worth of commits between those two tags. ;) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
[lm-sensors] Kaveri [and Radeon] temps
>>>>> "GR" == Guenter Roeck writes: ... GR> AMD CPUs are known report wildly off temperatures especially at GR> low temperatures. Thanks. After some further digging, I wonder whether Aravind's recent patch might help? The apu does have both PCI_DEVICE_ID_AMD_16H_M30H_NB_F3 and PCI_DEVICE_ID_AMD_16H_M30H_NB_F4 and lspci reports no driver for the F4 device. GR> Does the temperature increase with load ? It seems to max out w/in a kelvin or two of the room's ambient temp. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
HDMI Audio screwed up w/ recent kernels
I haven't paid as close attention to Xorg issues sine the stroke last year, and I hadn't needed to reboot the box in the living room in several months. When I did need to, I found that hdmi audio was unlistenable. It sounded like it was mixed witht white noise. If I boot vmlinuz-3.19.0 is works fine. I had compiled 4.1.0 and 4.5.0, as well as its current default kernel, 4.9.0 (all from Linus' git). All of those 4. kernels show the crappy audio. In 4.9 I then tried switching to amdgpu. That did not help. The box has a Kaveri apu (ChipID 0x1313). Firmware is from linux-firmware.git and is compiled into the kernel via CONFIG_EXTRA_FIRMWARE. With radeon the kernel command line has: radeon.modeset=1 radeon.audio=1 With amdgpu I switched to: amdgpu.audio=1 amdgpu.exp_hw_support=1 Any thoughs on where to look? I find it hard to believe that a bug like this could persist for so long. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
HDMI Audio screwed up w/ recent kernels
>>>>> "DV" == Daniel Vetter writes: DV> amdgpu doesn't yet support hdmi audio. Then why does it support the amdgpu.audio command line option, and why does booting an amdgpu kernel with amdgpu.audio=1 sound the same as booting a radeon kernel w/ radeon.audio=1? In linux/drivers/gpu/drm/amd/amdgpu: :; grep -l audio_enable *.c|xargs dce_v10_0.c dce_v11_0.c dce_v6_0.c dce_v8_0.c :; grep -l amdgpu_audio *.c |xargs amdgpu_connectors.c amdgpu_display.c amdgpu_drv.c atombios_encoders.c dce_v10_0.c dce_v11_0.c dce_v6_0.c dce_v8_0.c -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
HDMI Audio screwed up w/ recent kernels
>>>>> "DV" == Daniel Vetter writes: DV> Hm, I thought there was in issue there still. Anyway, was just a drive-by DV> comment, please ignore me ;-) Any and all help is always appreciated. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
HDMI Audio screwed up w/ recent kernels
>>>>> "AD" == Alex Deucher writes: AD> That option is just a carry over from when the amdgpu was copied from AD> radeon. There is some code for older asics left over from when the AD> code was originally ported from radeon. If you want hdmi audio AD> support you need to use the new dc modesetting code we are working on: AD> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7 AD> As for radeon, a bisection would help. If both drivers worked before AD> and now both have issues, I'd suggest looking at the hda audio driver. All I know is that radeon audio worked fine in 3.x and stopped working in 4.x Where stopped working means fairly recognizable audio which sounds mixed with white noise. I doubt I can bisect. The screen it uses is in almost constant use In order for the fb to be there from boot, the firmware is all compiled into the kernels via CONFIG_EXTRA_FIRMWARE. Given that, with 4.9, the audio has exactly the same problem with amdgpu as with radeon, I suspect the actual problem is in the firmware. If so, and since I do not have whatever firmware files were installed back when I compiled the 3. kernels, I doubt bisecting the kernel would help. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2
>>>>> "CS" == Christian Schmidt writes: CS> The current logic misunderstands the spec about CEA 18byte descriptors. CS> First, the spec doesn't state "detailed timing descriptors" but "18 byte CS> descriptors", so any data record could be stored, mixed timings and CS> other data, just as in the standard EDID. CS> Second, the lower four bit of byte 3 of the CEA record do not contain CS> the number of descriptors, but "the total number of DTDs defining native CS> formats in the whole EDID [...], starting with the first DTD in the DTD CS> list (which starts in the base EDID block)." A device can of course CS> support non-native formats. CS> As such the number can't be used to determine n, and the existing code CS> will filter non-timing 18byte descriptors anyway. CS> V2 removes an unused variable warning. CS> Signed-off-by: Christian Schmidt Tested-by: James Cloos Works fine here on top of Linus’ 7f80850d3f9f with a Radeon HD 4290 and an hdmi-connected tv. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 CS> ___ CS> dri-devel mailing list CS> dri-devel@lists.freedesktop.org CS> http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm_edid_to_eld: check for CEA data blocks only from structure revision 3 on
>>>>> "CS" == Christian Schmidt writes: CS> CEA datablocks are only defined from revision 3 onwards. Only check for CS> them if the revision says so. CS> Signed-of-by: Christian Schmidt Tested-by: James Cloos Works fine here on top of Linus’ 7f80850d3f9f with a Radeon HD 4290 and an hdmi-connected tv. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm_edid: support CEA video modes
>>>>> "CS" == Christian Schmidt writes: CS> TFT/plasma televisions and projectors have become commonplace, and so CS> has the use of PCs to drive them. Add the video modes specified by an CS> EDID's CEA extension to the mode database for a connector. CS> Signed-off-by: Christian Schmidt Tested-by: James Cloos Works fine here on top of Linus’ 7f80850d3f9f with a Radeon HD 4290 and an hdmi-connected tv. The new modes not previously seen, as reported by libdrm’s modetest are: :; diff -U0 a/mt.out b/mt.out --- a/mt.out2011-11-14 17:25:21.785708725 -0500 +++ b/mt.out2011-11-14 18:41:22.023562219 -0500 @@ -11 +11 @@ -15 14 connected HDMI-A 820x460 17 14 +15 14 connected HDMI-A 820x460 22 14 @@ -15 +15,2 @@ - 1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 + 1920x1080 60 1920 2008 2052 2200 1080 1084 1094 1125 + 1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 @@ -19,0 +21 @@ + 1280x720 60 1280 1390 1430 1650 720 725 730 750 @@ -22,0 +25 @@ + 1440x480 60 1440 1478 1602 1716 480 488 494 525 @@ -26,0 +30 @@ + 720x480 60 720 736 798 858 480 489 495 525 @@ -29,0 +34 @@ + 640x480 60 640 656 752 800 480 490 492 525 @@ -41,2 +46,2 @@ -10 35 (0,0) (0x0) - 0 1920 2008 2052 2200 1080 1084 1089 1125 +10 19 (0,0) (0x0) + 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
QAContact
>>>>> "b" == bugzilla-daemon writes: Given: b> What|Removed |Added b> - b> QAContact|xorg-t...@lists.x.org | b>Product|xorg|DRI b> Component|Driver/intel|DRM/Intel DRI should have a list to put in qacontact akin to xorg's xorg-team list. It is vastly easier to stay aware of what bugs exist in bz when one can subscribe to a single mm list to read the reports and updates for a given product. And doing that is a useful exercise. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/165] radeon drm-next patches
>>>>> "AD" == Alex Deucher writes: AD> Nope. 6xx and APUs do not require ucode. only 7xx+ dGPUs. Does that mean that APUs do not require *any* ucode blobs? Or just that they do not require updated or additional blobs for the new functionality like DPM? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
>>>>> "WF" == Wu Fengguang writes: WF> ... If only the stereo playback capability is reported, the user WF> won't be able to start 8-channel playback; if the 8-channel ELD is WF> reported, then user space applications may send 8-channel samples WF> down, however the user may actually be listening to the 2-channel WF> monitor and not connecting speakers to the 8-channel monitor. WF> Overall, it's more safe to report maximum profiles to the user WF> space, so that the user can at least be able to do 8-channel WF> playback if he want to. Be aware that many TVs will either refuse the display anything or pop-up an OSD warning whenever they receive hdmi audio which they cannot handle. Sending 8-channel in your example may render the stereo-only monitor useless. That said, one step at a time is reasonable. But eventually you will require configurability and/or per-monitor audio control even when the video is cloned. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
found __[us]{8,16,32,64} type without #include
All noticed while compiling 3.1-r5:
linux/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type without
#include
linux/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type without
#include
linux/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without
#include
linux/usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type without
#include
linux/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without
#include
linux/usr/include/scsi/scsi_netlink.h:108: found __[us]{8,16,32,64} type
without #include
linux/usr/include/linux/mmc/ioctl.h:10: found __[us]{8,16,32,64} type without
#include
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: found __[us]{8,16,32,64} type without #include
>>>>> "AB" == Arnd Bergmann writes: AB> The script only checks for direct inclusions of types.h, while the AB> drm headers get it from drm.h. I see. It had been quite some time since I last did a make 1>/dev/null, long enough that I hadn't noticed that message before. It is good to know that it is a false positive. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
>>>>> "WF" == Wu Fengguang writes: WF> ... If only the stereo playback capability is reported, the user WF> won't be able to start 8-channel playback; if the 8-channel ELD is WF> reported, then user space applications may send 8-channel samples WF> down, however the user may actually be listening to the 2-channel WF> monitor and not connecting speakers to the 8-channel monitor. WF> Overall, it's more safe to report maximum profiles to the user WF> space, so that the user can at least be able to do 8-channel WF> playback if he want to. Be aware that many TVs will either refuse the display anything or pop-up an OSD warning whenever they receive hdmi audio which they cannot handle. Sending 8-channel in your example may render the stereo-only monitor useless. That said, one step at a time is reasonable. But eventually you will require configurability and/or per-monitor audio control even when the video is cloned. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
found __[us]{8,16,32,64} type without #include
All noticed while compiling 3.1-r5:
linux/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type without
#include
linux/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type without
#include
linux/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without
#include
linux/usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type without
#include
linux/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without
#include
linux/usr/include/scsi/scsi_netlink.h:108: found __[us]{8,16,32,64} type
without #include
linux/usr/include/linux/mmc/ioctl.h:10: found __[us]{8,16,32,64} type without
#include
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
found __[us]{8,16,32,64} type without #include
>>>>> "AB" == Arnd Bergmann writes: AB> The script only checks for direct inclusions of types.h, while the AB> drm headers get it from drm.h. I see. It had been quite some time since I last did a make 1>/dev/null, long enough that I hadn't noticed that message before. It is good to know that it is a false positive. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
QAContact
>>>>> "b" == bugzilla-daemon writes: Given: b> What|Removed |Added b> - b> QAContact|xorg-team at lists.x.org | b>Product|xorg|DRI b> Component|Driver/intel|DRM/Intel DRI should have a list to put in qacontact akin to xorg's xorg-team list. It is vastly easier to stay aware of what bugs exist in bz when one can subscribe to a single mm list to read the reports and updates for a given product. And doing that is a useful exercise. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
[PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2
>>>>> "CS" == Christian Schmidt writes: CS> The current logic misunderstands the spec about CEA 18byte descriptors. CS> First, the spec doesn't state "detailed timing descriptors" but "18 byte CS> descriptors", so any data record could be stored, mixed timings and CS> other data, just as in the standard EDID. CS> Second, the lower four bit of byte 3 of the CEA record do not contain CS> the number of descriptors, but "the total number of DTDs defining native CS> formats in the whole EDID [...], starting with the first DTD in the DTD CS> list (which starts in the base EDID block)." A device can of course CS> support non-native formats. CS> As such the number can't be used to determine n, and the existing code CS> will filter non-timing 18byte descriptors anyway. CS> V2 removes an unused variable warning. CS> Signed-off-by: Christian Schmidt Tested-by: James Cloos Works fine here on top of Linus? 7f80850d3f9f with a Radeon HD 4290 and an hdmi-connected tv. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 CS> ___ CS> dri-devel mailing list CS> dri-devel at lists.freedesktop.org CS> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm_edid_to_eld: check for CEA data blocks only from structure revision 3 on
>>>>> "CS" == Christian Schmidt writes: CS> CEA datablocks are only defined from revision 3 onwards. Only check for CS> them if the revision says so. CS> Signed-of-by: Christian Schmidt Tested-by: James Cloos Works fine here on top of Linus? 7f80850d3f9f with a Radeon HD 4290 and an hdmi-connected tv. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
[PATCH] drm_edid: support CEA video modes
>>>>> "CS" == Christian Schmidt writes: CS> TFT/plasma televisions and projectors have become commonplace, and so CS> has the use of PCs to drive them. Add the video modes specified by an CS> EDID's CEA extension to the mode database for a connector. CS> Signed-off-by: Christian Schmidt Tested-by: James Cloos Works fine here on top of Linus? 7f80850d3f9f with a Radeon HD 4290 and an hdmi-connected tv. The new modes not previously seen, as reported by libdrm?s modetest are: :; diff -U0 a/mt.out b/mt.out --- a/mt.out2011-11-14 17:25:21.785708725 -0500 +++ b/mt.out2011-11-14 18:41:22.023562219 -0500 @@ -11 +11 @@ -15 14 connected HDMI-A 820x460 17 14 +15 14 connected HDMI-A 820x460 22 14 @@ -15 +15,2 @@ - 1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 + 1920x1080 60 1920 2008 2052 2200 1080 1084 1094 1125 + 1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 @@ -19,0 +21 @@ + 1280x720 60 1280 1390 1430 1650 720 725 730 750 @@ -22,0 +25 @@ + 1440x480 60 1440 1478 1602 1716 480 488 494 525 @@ -26,0 +30 @@ + 720x480 60 720 736 798 858 480 489 495 525 @@ -29,0 +34 @@ + 640x480 60 640 656 752 800 480 490 492 525 @@ -41,2 +46,2 @@ -10 35 (0,0) (0x0) - 0 1920 2008 2052 2200 1080 1084 1089 1125 +10 19 (0,0) (0x0) + 1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
[PATCH 000/165] radeon drm-next patches
>>>>> "AD" == Alex Deucher writes: AD> Nope. 6xx and APUs do not require ucode. only 7xx+ dGPUs. Does that mean that APUs do not require *any* ucode blobs? Or just that they do not require updated or additional blobs for the new functionality like DPM? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
