Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
> > A simple "plugin" mechanism is provided to allow integration with > external kernel modules (*cough* PVR), but also to keep the code more > modular as support is added for various other accelerator blocks that > exist in various different OMAP variants. (2D accel, video encode/ > decode, etc.) However this driver and userspace xorg driver are > themselves fully functional without any closed-source components. It > doesn't (and won't) provide any command submission to IP blocks with > closed-source kernel or userspace components. At the moment I'd rather not merge any sort of plugin layer, until we had some users for it that were part of an open driver stack. I'll try and review the rest next week. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38622] [radeon cayman regresion] artefacts on screen
https://bugzilla.kernel.org/show_bug.cgi?id=38622 --- Comment #12 from Michel D?nzer 2011-08-29 17:33:42 --- This could be the same as https://bugs.freedesktop.org/show_bug.cgi?id=40221 . --- Comment #13 from Marek Hobler, 'neutrinus' 2011-09-02 21:17:04 --- I just checked kernel: vmlinuz-3.1.0-rc4-amd64 (from debian package) and problem is still there... Michel: yes, it looks similar -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RFC][PATCH v3] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
Hello Rob.
Below is my comments.
> -Original Message-
> From: Rob Clark [mailto:robdclark at gmail.com]
> Sent: Friday, September 02, 2011 10:18 AM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> sw0312.kim at samsung.com; linux-kernel at vger.kernel.org;
> kyungmin.park at samsung.com; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC][PATCH v3] DRM: add DRM Driver for Samsung SoC
> EXYNOS4210.
>
> On Thu, Sep 1, 2011 at 8:06 AM, Inki Dae wrote:
> >> >> > +struct samsung_drm_gem_obj *
> >> >> > + ? ? ? ? ? ? ? find_samsung_drm_gem_object(struct drm_file
> > *file_priv,
> >> >> > + ? ? ? ? ? ? ? ? ? ? ? struct drm_device *dev, unsigned int
handle)
> >> >> > +{
> >> >> > + ? ? ? struct drm_gem_object *gem_obj;
> >> >> > +
> >> >> > + ? ? ? gem_obj = drm_gem_object_lookup(dev, file_priv, handle);
> >> >> > + ? ? ? if (!gem_obj) {
> >> >> > + ? ? ? ? ? ? ? DRM_LOG_KMS("a invalid gem object not registered
to
> >> >> lookup.\n");
> >> >> > + ? ? ? ? ? ? ? return NULL;
> >> >> > + ? ? ? }
> >> >> > +
> >> >> > + ? ? ? /**
> >> >> > + ? ? ? ?* unreference refcount of the gem object.
> >> >> > + ? ? ? ?* at drm_gem_object_lookup(), the gem object was
> referenced.
> >> >> > + ? ? ? ?*/
> >> >> > + ? ? ? drm_gem_object_unreference(gem_obj);
> >> >>
> >> >> this doesn't seem right, to drop the reference before you use the
> >> >> buffer elsewhere..
> >> >>
> >> > No, see drm_gem_object_lookup fxn. at this function, if there is a
> >> object
> >> > found then drm_gem_object_reference is called to increase refcount of
> >> this
> >> > object. if there is any missing point, give me any comment please.
> thank
> >> > you.
> >>
> >>
> >> Right, but I think there is a reason it takes a reference... so that
> >> the object doesn't get free'd from under your feet. ?So pattern
> >> should, I think, be:
> >>
> >> ? obj = lookup(...);
> >> ? ... do stuff w/ obj ...
> >> ? unreference(obj)
> >>
> >> so the caller who is using the looked up obj should unref it when done
> >>
> >> Instead, you have:
> >>
> >> ? obj = lookup(...);
> >> ? unreference(obj);
> >> ? ... do stuff w/ obj ...
> >>
> >>
> >
> > Generally right, but in this case, it is just used to get specific gem
> > object through find_samsung_drm_gem_object() so doesn't reference this
> gem
> > object anywhere.
> > therefore reference and unreference should be done within
> > find_samsung_drm_gem_object(). if there is any point I missed then let
> me
> > know please. thank you.
> >
>
> Still, it seems like find_samsung_drm_gem_object() is encouraging the
> wrong usage-pattern, even if it works fine today because you know
> somewhere else is holding a reference to the object. Later if you
> expand your use of GEM objects, this fxn might come back to bite you.
> There is a good reason that drm_gem_object_lookup() takes a reference
> to the object, and it feels wrong to intentionally subvert that.
>
> (I'm perfectly willing to be overridden on the subject.. there are
> plenty of folks on this list who have been doing the GEM thing longer
> than I have. But it just seems better to use APIs like
> drm_gem_object_lookup() the way they were intended.)
>
Ah, you are right. I misunderstanded it. as you pointed out, a gem object
should be unreferenced after doing something with the gem object. so I will
remove find_samsung_drm_gem_object() and use drm_gem_object_lookup()
directly to get a gem object instead. of course, the gem object will be
unreferenced after doing something with it. thank you for your explanation.
:)
> BR,
> -R
[Bug 42172] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:267 radeon_fence_wait+0x39f/0x3d0()
https://bugzilla.kernel.org/show_bug.cgi?id=42172 nissa...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #6 from nissa...@gmail.com 2011-09-03 01:18:38 --- The patch works, thanks. *** This bug has been marked as a duplicate of bug 42162 *** -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40554] r200 falls back to software when clearing FBOs
https://bugs.freedesktop.org/show_bug.cgi?id=40554 --- Comment #1 from Roland Scheidegger 2011-09-02 17:21:26 PDT --- Hmm I guess at least when using the kernel_mm path (which is just _mesa_meta_Clear) there shouldn't be any swrast fallback. Not quite sure though how well fbos will actually work... The old kernel clear path is quite a mess anyway (though it has to be said fastzclear was fast...). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40554] r200 falls back to software when clearing FBOs
https://bugs.freedesktop.org/show_bug.cgi?id=40554 --- Comment #1 from Roland Scheidegger 2011-09-02 17:21:26 PDT --- Hmm I guess at least when using the kernel_mm path (which is just _mesa_meta_Clear) there shouldn't be any swrast fallback. Not quite sure though how well fbos will actually work... The old kernel clear path is quite a mess anyway (though it has to be said fastzclear was fast...). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH v4] drm/i915: pass ELD to HDMI/DP audio driver
Keith: this version completes the IvyBridge support :) Bossart: hotplug is working fine now, with some minor issues: - on G45, monitor hot removal is not handled at all in i915_driver_irq_handler(). I'll leave it as a future TODO. - on IvyBridge, _repeated_ plug/unplug will trigger [ 1183.654859] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 which means the ELD_valid flag will be seen by audio driver, however it cannot get any valid ELD data. I double checked and find everything in the graphics driver is working as expected: ironlake_write_eld() is writing the good ELD data to the same pipe on hot plug events. So I'll leave it as a possible bug of the early stage hardware. Thanks, Fengguang
[PATCH v4] drm/i915: pass ELD to HDMI/DP audio driver
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be used. This policy may not be suitable for all users, but
let's start it simple first.
The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor. Overall,
it's more safe to report maximum profiles to the user space, so that
the user can at least be able to do 8-channel playback if he want to.
This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
Minor imperfection: the GEN6_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.
Thanks to Zhenyu and Bossart for a lot of valuable help and testing.
CC: Zhao Yakui
CC: Wang Zhenyu
CC: Jeremy Bush
CC: Christopher White
CC: "Bossart, Pierre-louis"
Signed-off-by: Ben Skeggs
Signed-off-by: Wu Fengguang
---
drivers/gpu/drm/drm_edid.c | 171 +
drivers/gpu/drm/i915/i915_drv.h |2
drivers/gpu/drm/i915/i915_reg.h | 25 +++
drivers/gpu/drm/i915/intel_display.c | 132 +++
drivers/gpu/drm/i915/intel_dp.c |6
drivers/gpu/drm/i915/intel_drv.h |2
drivers/gpu/drm/i915/intel_hdmi.c|3
drivers/gpu/drm/i915/intel_modes.c |2
include/drm/drm_crtc.h |9 +
include/drm/drm_edid.h |9 +
10 files changed, 359 insertions(+), 2 deletions(-)
--- linux-next.orig/drivers/gpu/drm/drm_edid.c 2011-09-02 15:59:35.0
+0800
+++ linux-next/drivers/gpu/drm/drm_edid.c 2011-09-02 15:59:40.0
+0800
@@ -1319,6 +1319,7 @@ add_detailed_modes(struct drm_connector
#define HDMI_IDENTIFIER 0x000C03
#define AUDIO_BLOCK0x01
#define VENDOR_BLOCK0x03
+#define SPEAKER_BLOCK 0x04
#define EDID_BASIC_AUDIO (1 << 6)
/**
@@ -1347,6 +1348,176 @@ u8 *drm_find_cea_extension(struct edid *
}
EXPORT_SYMBOL(drm_find_cea_extension);
+static void
+parse_hdmi_vsdb(struct drm_connector *connector, uint8_t *db)
+{
+ connector->eld[5] |= (db[6] >> 7) << 1; /* Supports_AI */
+
+ connector->dvi_dual = db[6] & 1;
+ connector->max_tmds_clock = db[7] * 5;
+
+ connector->latency_present[0] = db[8] >> 7;
+ connector->latency_present[1] = (db[8] >> 6) & 1;
+ connector->video_latency[0] = db[9];
+ connector->audio_latency[0] = db[10];
+ connector->video_latency[1] = db[11];
+ connector->audio_latency[1] = db[12];
+
+ DRM_LOG_KMS("HDMI: DVI dual %d, "
+ "max TMDS clock %d, "
+ "latency present %d %d, "
+ "video latency %d %d, "
+ "audio latency %d %d\n",
+ connector->dvi_dual,
+ connector->max_tmds_clock,
+ (int) connector->latency_present[0],
+ (int) connector->latency_present[1],
+ connector->video_latency[0],
+ connector->video_latency[1],
+ connector->audio_latency[0],
+ connector->audio_latency[1]);
+}
+
+static void
+monitor_name(struct detailed_timing *t, void *data)
+{
+ if (t->data.other_data.type == EDID_DETAIL_MONITOR_NAME)
+ *(u8 **)data = t->data.other_data.data.str.str;
+}
+
+/**
+ * drm_edid_to_eld - build ELD from EDID
+ * @connector: connector corresponding to the HDMI/DP sink
+ * @edid: EDID to parse
+ *
+ * Fill the ELD (EDID-Like Data) buffer for passing to the audio driver.
+ * Some ELD fields are left to the graphics driver caller:
+ * - Conn_Type
+ * - HDCP
+ * - Port_ID
+ */
+void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
+{
+ uint8_t *eld = connector->eld;
+ u8 *cea;
+ u8 *name;
+ u8 *db;
+
[PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
From: Rob Clark A DRM display driver for TI OMAP platform. Similar to omapfb (fbdev) and omap_vout (v4l2 display) drivers in the past, this driver uses the DSS2 driver to access the display hardware, including support for HDMI, DVI, and various types of LCD panels. And it implements GEM support for buffer allocation (for KMS as well as offscreen buffers used by the xf86-video-omap userspace xorg driver). The driver maps CRTCs to overlays, encoders to overlay-managers, and connectors to dssdev's. Note that this arrangement might change slightly when support for drm_plane overlays is added. For GEM support, non-scanout buffers are using the shmem backed pages provided by GEM core (In drm_gem_object_init()). In the case of scanout buffers, which need to be physically contiguous, those are allocated from omap_vram and use drm_gem_private_object_init() (Thanks to "gem: RFC: add support for private objects" patch from Alan Cox.) Also used is the "drm/gem: add functions for mmap offset creation" patch to avoid duplicating some functions for mmap offset management in the omapdrm driver. Note that the usage of omap_vram carveout will be replaced by CMA in the future. A simple "plugin" mechanism is provided to allow integration with external kernel modules (*cough* PVR), but also to keep the code more modular as support is added for various other accelerator blocks that exist in various different OMAP variants. (2D accel, video encode/ decode, etc.) However this driver and userspace xorg driver are themselves fully functional without any closed-source components. It doesn't (and won't) provide any command submission to IP blocks with closed-source kernel or userspace components. See userspace xorg driver: git://github.com/robclark/xf86-video-omap.git --- Note that this patch depends on a few other patches which have been submitted to respective mailing lists (linux-omap for DSS2 and dri-devel for DRM), but not yet merged. But this is only a RFC, and I thought it was about time to put on the asbestos pants and let the good folks of dri-devel get their flame on. Special thanks to Tomi Valkeinen (DSS2 author) for patches to add the needed APIs for hotplug detection and EDID to DSS2 and various other help with the DRM driver. drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/omapdrm/Kconfig | 25 + drivers/staging/omapdrm/Makefile |8 + drivers/staging/omapdrm/TODO.txt | 15 + drivers/staging/omapdrm/omap_connector.c | 375 drivers/staging/omapdrm/omap_crtc.c | 348 drivers/staging/omapdrm/omap_drv.c | 910 ++ drivers/staging/omapdrm/omap_drv.h | 117 drivers/staging/omapdrm/omap_encoder.c | 198 +++ drivers/staging/omapdrm/omap_fb.c| 265 + drivers/staging/omapdrm/omap_fbdev.c | 303 ++ drivers/staging/omapdrm/omap_gem.c | 851 drivers/video/omap2/omapfb/Kconfig |4 +- include/linux/Kbuild |1 + include/linux/omap_drm.h | 191 +++ 16 files changed, 3612 insertions(+), 2 deletions(-) create mode 100644 drivers/staging/omapdrm/Kconfig create mode 100644 drivers/staging/omapdrm/Makefile create mode 100644 drivers/staging/omapdrm/TODO.txt create mode 100644 drivers/staging/omapdrm/omap_connector.c create mode 100644 drivers/staging/omapdrm/omap_crtc.c create mode 100644 drivers/staging/omapdrm/omap_drv.c create mode 100644 drivers/staging/omapdrm/omap_drv.h create mode 100644 drivers/staging/omapdrm/omap_encoder.c create mode 100644 drivers/staging/omapdrm/omap_fb.c create mode 100644 drivers/staging/omapdrm/omap_fbdev.c create mode 100644 drivers/staging/omapdrm/omap_gem.c create mode 100644 include/linux/omap_drm.h diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 196284d..99b7547 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -160,4 +160,6 @@ source "drivers/staging/mei/Kconfig" source "drivers/staging/nvec/Kconfig" +source "drivers/staging/omapdrm/Kconfig" + endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index fa41b9c..91ec21f 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -71,3 +71,4 @@ obj-$(CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4) += ste_rmi4/ obj-$(CONFIG_DRM_PSB) += gma500/ obj-$(CONFIG_INTEL_MEI)+= mei/ obj-$(CONFIG_MFD_NVEC) += nvec/ +obj-$(CONFIG_DRM_OMAP) += omapdrm/ diff --git a/drivers/staging/omapdrm/Kconfig b/drivers/staging/omapdrm/Kconfig new file mode 100644 index 000..bddf52b --- /dev/null +++ b/drivers/staging/omapdrm/Kconfig @@ -0,0 +1,25 @@ + +config DRM_OMAP + tristate "OMAP DRM (EXPERIMENTAL)" + depends on DRM && !CONFIG_FB_OMAP2 + select DRM_KMS_HELPER + select OMAP2_VRAM + select OMA
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #16 from Alex Deucher 2011-09-02 14:33:03 --- (In reply to comment #15) > I think the problem is that the audio device is *advertised* as working, > although it doesn't. > radeon should just stop advertising audio if radeon.audio isn't set. The GPU driver doesn't advertise/handle the audio device. The alsa driver does. All the GPU driver does is enable the audio packets in the HDMI stream. I don't think there's a way for the gpu driver to tell the alsa driver not to load. Moreover, there are audio devices on certain boards with where the audio can be sent to either hdmi or regular audio ports so you would still want it that case. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 --- Comment #8 from Niels Ole Salscheider 2011-09-02 14:31:03 --- Created an attachment (id=71362) --> (https://bugzilla.kernel.org/attachment.cgi?id=71362) vbios -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 --- Comment #7 from Alex Deucher 2011-09-02 14:24:26 --- Please attach a copy of your vbios: (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 Xavier Bestel changed: What|Removed |Added CC||xavier.bestel at free.fr --- Comment #15 from Xavier Bestel 2011-09-02 14:19:17 --- I think the problem is that the audio device is *advertised* as working, although it doesn't. radeon should just stop advertising audio if radeon.audio isn't set. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 38622] [radeon cayman regresion] artefacts on screen
https://bugzilla.kernel.org/show_bug.cgi?id=38622 --- Comment #12 from Michel Dänzer 2011-08-29 17:33:42 --- This could be the same as https://bugs.freedesktop.org/show_bug.cgi?id=40221 . --- Comment #13 from Marek Hobler, 'neutrinus' 2011-09-02 21:17:04 --- I just checked kernel: vmlinuz-3.1.0-rc4-amd64 (from debian package) and problem is still there... Michel: yes, it looks similar -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 --- Comment #6 from Niels Ole Salscheider 2011-09-02 14:04:51 --- Created an attachment (id=71342) --> (https://bugzilla.kernel.org/attachment.cgi?id=71342) edid for display connected to LVDS -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 --- Comment #5 from Niels Ole Salscheider 2011-09-02 14:03:30 --- Created an attachment (id=71332) --> (https://bugzilla.kernel.org/attachment.cgi?id=71332) dmesg output with drm.debug=4 note: radeon_fp_native_mode gets calld for LVDS although get-edid can find valid edid data for it (see next attachment) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #14 from Alex Deucher 2011-09-02 13:44:29 --- (In reply to comment #13) > (I don't know the details of this bug, but am just responding to comment #11) > @Michel: Fixing regressions without introducing other regressions is a > prerequisite for being sure of forward progress. Else it's possible we are > going in circles. The policy on the linux kernel is: no regressions. So, we > revert even fixes if they cause _new_ regressions. Not being able to see your screen(s) seems like a bigger issue than having to set an option to enable audio. Although, audio support itself regressed working video for the bad cases originally, so audio support was a regression as well for some people. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
DPMS will keep switching monitor on and off
Some time ago there was a patch [1] merged in which was designed to fix DPMS (monitor would go on/off all the time [2] instead of just going off), I was happy to see this one but unfortunately it doesn't work for me - I still experience the same behaviour. I'm terrible lazy so I didn't report it before but seeing that some "unrelated" change might be the cause of bug in dri code (as in #42162) got me wondering. Should I open a bug report for it ? [1] 73104b5cfe3067d68f2c2de3f3d4d4964c55873e [2] https://bugzilla.redhat.com/show_bug.cgi?id=728228
DPMS will keep switching monitor on and off
On Fri, Sep 2, 2011 at 6:29 AM, Wojciech Pyczak wrote: > Some time ago there was a patch [1] merged in which was designed to fix DPMS > (monitor would go on/off all the time [2] instead of just going off), I was > happy to see this one but unfortunately it doesn't work for me - I still > experience the same behaviour. > I'm terrible lazy so I didn't report it before but seeing that some > "unrelated" change might be the cause of bug in dri code (as in #42162) got > me wondering. This patch may also fix the issue: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d5811e8731213f80c80d89e980505052f16aca1c Alex
DPMS will keep switching monitor on and off
On Fri, Sep 2, 2011 at 6:29 AM, Wojciech Pyczak wrote: > Some time ago there was a patch [1] merged in which was designed to fix DPMS > (monitor would go on/off all the time [2] instead of just going off), I was > happy to see this one but unfortunately it doesn't work for me - I still > experience the same behaviour. > I'm terrible lazy so I didn't report it before but seeing that some > "unrelated" change might be the cause of bug in dri code (as in #42162) got > me wondering. > > Should I open a bug report for it ? File a bug (https://bugs.freedesktop.org) and attach your xorg log and dmesg output. Alex
[git pull] drm-fixes from an alternate place
Hi Linus, two radeon fixes from my tree on fd.o, not sure you can really do much, since its not like you can republish it :) Dave. The following changes since commit 9e79e3e9dd9672b37ac9412e9a926714306551fe: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (2011-08-30 11:28:18 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes Alex Deucher (1): drm/radeon/kms: make sure pci max read request size is valid on evergreen+ (v2) Dave Airlie (1): drm/radeon/kms: set a default max_pixel_clock drivers/gpu/drm/radeon/evergreen.c | 27 +++ drivers/gpu/drm/radeon/ni.c|3 +++ drivers/gpu/drm/radeon/radeon_clocks.c |3 +++ 3 files changed, 33 insertions(+), 0 deletions(-)
[PATCH] drm/radeon/kms: fix DP detect and EDID fetch for DP bridges
From: Alex Deucher
Sink type is always DP for DP bridges and EDID fetch on
DP bridges is always i2c over aux rather than plain i2c.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 37 ++--
drivers/gpu/drm/radeon/radeon_display.c| 19 +-
2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 7f65940..9efb356 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1287,12 +1287,33 @@ radeon_dp_detect(struct drm_connector *connector, bool
force)
if (!radeon_dig_connector->edp_on)
atombios_set_edp_panel_power(connector,
ATOM_TRANSMITTER_ACTION_POWER_OFF);
- } else {
- /* need to setup ddc on the bridge */
- if (radeon_connector_encoder_is_dp_bridge(connector)) {
+ } else if (radeon_connector_encoder_is_dp_bridge(connector)) {
+ /* DP bridges are always DP */
+ radeon_dig_connector->dp_sink_type =
CONNECTOR_OBJECT_ID_DISPLAYPORT;
+ /* get the DPCD from the bridge */
+ radeon_dp_getdpcd(radeon_connector);
+
+ if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd))
+ ret = connector_status_connected;
+ else {
+ /* need to setup ddc on the bridge */
if (encoder)
radeon_atom_ext_encoder_setup_ddc(encoder);
+ if (radeon_ddc_probe(radeon_connector,
+
radeon_connector->requires_extended_probe))
+ ret = connector_status_connected;
+ }
+
+ if ((ret == connector_status_disconnected) &&
+ radeon_connector->dac_load_detect) {
+ struct drm_encoder *encoder =
radeon_best_single_encoder(connector);
+ struct drm_encoder_helper_funcs *encoder_funcs;
+ if (encoder) {
+ encoder_funcs = encoder->helper_private;
+ ret = encoder_funcs->detect(encoder, connector);
+ }
}
+ } else {
radeon_dig_connector->dp_sink_type =
radeon_dp_getsinktype(radeon_connector);
if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) {
ret = connector_status_connected;
@@ -1308,16 +1329,6 @@ radeon_dp_detect(struct drm_connector *connector, bool
force)
ret = connector_status_connected;
}
}
-
- if ((ret == connector_status_disconnected) &&
- radeon_connector->dac_load_detect) {
- struct drm_encoder *encoder =
radeon_best_single_encoder(connector);
- struct drm_encoder_helper_funcs *encoder_funcs;
- if (encoder) {
- encoder_funcs = encoder->helper_private;
- ret = encoder_funcs->detect(encoder, connector);
- }
- }
}
radeon_connector_update_scratch_regs(connector, ret);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 1a85894..6cc17fb 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -707,16 +707,21 @@ int radeon_ddc_get_modes(struct radeon_connector
*radeon_connector)
radeon_router_select_ddc_port(radeon_connector);
if ((radeon_connector->base.connector_type ==
DRM_MODE_CONNECTOR_DisplayPort) ||
- (radeon_connector->base.connector_type == DRM_MODE_CONNECTOR_eDP)) {
+ (radeon_connector->base.connector_type == DRM_MODE_CONNECTOR_eDP) ||
+ radeon_connector_encoder_is_dp_bridge(&radeon_connector->base)) {
struct radeon_connector_atom_dig *dig =
radeon_connector->con_priv;
+
if ((dig->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT ||
dig->dp_sink_type == CONNECTOR_OBJECT_ID_eDP) &&
dig->dp_i2c_bus)
- radeon_connector->edid =
drm_get_edid(&radeon_connector->base, &dig->dp_i2c_bus->adapter);
- }
- if (!radeon_connector->ddc_bus)
- return -1;
- if (!radeon_connector->edid) {
- radeon_connector->edid = drm_get_edid(&radeon_connector->base,
&radeon_connector->ddc_bus->adapter);
+ radeon_connector->edid =
drm_get_edid(&radeon_connector->base,
+
&dig->dp_i2c_bus->adapter);
+ else if (radeon_connec
[RFC][PATCH v3] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
On Thu, Sep 1, 2011 at 10:06 PM, Inki Dae wrote:
> Hello Rob.
> Below is my comments. thank you.
>
>> -Original Message-
>> From: Rob Clark [mailto:robdclark at gmail.com]
>> Sent: Thursday, September 01, 2011 1:02 AM
>> To: Inki Dae
>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>> sw0312.kim at samsung.com; linux-kernel at vger.kernel.org;
>> kyungmin.park at samsung.com; linux-arm-kernel at lists.infradead.org
>> Subject: Re: [RFC][PATCH v3] DRM: add DRM Driver for Samsung SoC
>> EXYNOS4210.
>>
>> On Wed, Aug 31, 2011 at 1:51 AM, Inki Dae wrote:
>> > Hello, Rob.
>> > Below is my answers and questions. and could you please include me as CC
>> > when you post your driver?
>>
>> sure thing
>>
>>
>> >> > +static int samsung_drm_connector_get_modes(struct drm_connector
>> >> *connector)
>> >> > +{
>> >> > + ? ? ? struct samsung_drm_connector *samsung_connector =
>> >> > + ? ? ? ? ? ? ? to_samsung_connector(connector);
>> >> > + ? ? ? struct samsung_drm_display *display =
>> >> > + ? ? ? ? ? ? ? samsung_drm_get_manager(samsung_connector->encoder)-
>> >> >display;
>> >> > + ? ? ? unsigned int count;
>> >> > +
>> >> > + ? ? ? DRM_DEBUG_KMS("%s\n", __FILE__);
>> >> > +
>> >> > + ? ? ? if (display && display->get_edid) {
>> >> > + ? ? ? ? ? ? ? void *edid = kzalloc(MAX_EDID, GFP_KERNEL);
>> >> > + ? ? ? ? ? ? ? if (!edid) {
>> >> > + ? ? ? ? ? ? ? ? ? ? ? DRM_ERROR("failed to allocate edid\n");
>> >> > + ? ? ? ? ? ? ? ? ? ? ? return 0;
>> >> > + ? ? ? ? ? ? ? }
>> >> > +
>> >> > + ? ? ? ? ? ? ? display->get_edid(connector, edid, MAX_EDID);
>> >> > +
>> >> > + ? ? ? ? ? ? ? drm_mode_connector_update_edid_property(connector,
>> > edid);
>> >> > + ? ? ? ? ? ? ? count = drm_add_edid_modes(connector, edid);
>> >> > +
>> >> > + ? ? ? ? ? ? ? kfree(connector->display_info.raw_edid);
>> >> > + ? ? ? ? ? ? ? connector->display_info.raw_edid = edid;
>> >> > + ? ? ? } else {
>> >> > + ? ? ? ? ? ? ? struct drm_display_mode *mode =
>> > drm_mode_create(connector-
>> >> >dev);
>> >> > + ? ? ? ? ? ? ? struct fb_videomode *timing;
>> >> > +
>> >> > + ? ? ? ? ? ? ? if (display && display->get_timing)
>> >> > + ? ? ? ? ? ? ? ? ? ? ? timing = display->get_timing();
>> >>
>> >> also seems a bit weird to not do: display->get_timings(display)..
>> >>
>> >> maybe you don't have the case of multiple instances of the same
>> >> display time.. but maybe someday you need that. ?(Maybe this is just
>> >> an artifact of how the API of your current lower layer driver is.. but
>> >> maybe now is a good time to think about those APIs)
>> >>
>> >
>> > display is static object set by hardware specific driver such as display
>> > controller or hdmi. each hardware specific driver has their own display
>> > object statically. You can refer to the definition in
> samsung_drm_fimd.c.
>> > and I understood a encoder and a connector is 1:1 relationship, when any
>> > hardware specific driver is probed, they would be created with a manager
>> > that includes their own display object as pointer. Could you please give
>> me
>> > more comments why display object should be considered for multiple
>> > instances? I am afraid there is any part I don't care.
>> >
>> > thank you.
>>
>> Just thinking hypothetically.. what if some future device had two hdmi
>> controllers. ?Then you'd want two instances of the same display
>> object.
>>
>> Although it seems this API is just internal to the DRM driver (which I
>> had not realized earlier), so it should be pretty easy to change later
>> if needed.
>>
>
> You are right. I guess we should consider multiple instances to display
> object because the Exynos hardware has two display controllers and also each
> display controller needs one display panel with sharing same driver. thank
> you for your pointing. :)
Two HDMI and two FIMD is different. even though exynos4 supports the
two display controller. it has only one HDMI port and now there's no
device to use it. Of course if new device uses it. it will support it.
I mena currently make it simple and make it TODO list.
Thank you,
Kyungmin Park
>
>>
>> >> > +static void samsung_drm_connector_destroy(struct drm_connector
>> >> *connector)
>> >> > +{
>> >> > + ? ? ? struct samsung_drm_connector *samsung_connector =
>> >> > + ? ? ? ? ? ? ? to_samsung_connector(connector);
>> >> > +
>> >> > + ? ? ? DRM_DEBUG_KMS("%s\n", __FILE__);
>> >> > +
>> >> > + ? ? ? drm_sysfs_connector_remove(connector);
>> >> > + ? ? ? drm_connector_cleanup(connector);
>> >> > + ? ? ? connector->dev->mode_config.num_connector--;
>> >>
>> >> I wonder if num_connector-- should be in drm_connector_cleanup()..
>> >>
>> >> I missed this in OMAP driver, but it seems that none of the other drm
>> >> drivers are directly decrementing this.. and it would seem more
>> >> symmetric for it to be in drm_connector_cleanup(). ?But would be
>> >
>> > For this, it was already commented by Joonyoun Shim.
>>
>> And it seems (which I hadn't noticed earlier) already merged :-)
>>
>> So I think
[Bug 42172] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:267 radeon_fence_wait+0x39f/0x3d0()
https://bugzilla.kernel.org/show_bug.cgi?id=42172 --- Comment #5 from nissarin at gmail.com 2011-09-02 09:52:26 --- Yes, it seems to be the same issue. Currently I'm testing the patch, I'll notify you later if it worked for me. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #13 from Florian Mickler 2011-09-02 09:47:04 --- (I don't know the details of this bug, but am just responding to comment #11) @Michel: Fixing regressions without introducing other regressions is a prerequisite for being sure of forward progress. Else it's possible we are going in circles. The policy on the linux kernel is: no regressions. So, we revert even fixes if they cause _new_ regressions. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #7 from Alex Deucher 2011-09-02 09:05:51 PDT --- (In reply to comment #6) > ok, Got it now. > > I disabled the VESA fb framebuffer and added the radeonfb instead (want my > penguins during boot). This did it. You don't need radeonfb; it doesn't even support your chip. The radeon KMS drm provides a fb interface itself. radeonfb is an old fbdev driver from the pre-KMS days and will conflict with the kms drm on chips supported by both. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #7 from Alex Deucher 2011-09-02 09:05:51 PDT --- (In reply to comment #6) > ok, Got it now. > > I disabled the VESA fb framebuffer and added the radeonfb instead (want my > penguins during boot). This did it. You don't need radeonfb; it doesn't even support your chip. The radeon KMS drm provides a fb interface itself. radeonfb is an old fbdev driver from the pre-KMS days and will conflict with the kms drm on chips supported by both. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 RandomCore changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #6 from RandomCore 2011-09-02 08:58:08 PDT --- ok, Got it now. I disabled the VESA fb framebuffer and added the radeonfb instead (want my penguins during boot). This did it. [51.021] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [51.021] (II) AIGLX: enabled GLX_INTEL_swap_event [51.021] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [51.021] (II) AIGLX: enabled GLX_SGI_make_current_read [51.021] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects [51.022] (II) AIGLX: Loaded and initialized /usr/lib/i386-linux-gnu/dri/r600_dri.so [51.022] (II) GLX: Initialized DRI2 GL provider for screen 0 Confirmation through $ glxinfo|grep render direct rendering: Yes OpenGL renderer string: Gallium 0.4 on AMD RS880 glxgears tells me it sync with the monitor now (and does indeed 60 FPS, but even on fullscreen). For those google'ing for answers, here's the dmesg bootlog from this one: $ grep drm dmesg_bootlog_20110902_1746 [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RS880 0x1002:0x9714). [drm] register mmio base: 0xFE6F [drm] register mmio size: 65536 [drm] Detected VRAM RAM=368M, BAR=256M [drm] RAM width 32bits DDR [drm] radeon: 368M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RS780 Microcode [drm] ring test succeeded in 0 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D [drm] HPD3 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_KLDSCP_LVTMA [drm] radeon: power management initialized [drm] fb mappable at 0xD0141000 [drm] vram apper at 0xD000 [drm] size 9216000 [drm] fb depth is 24 [drm]pitch is 7680 fbcon: radeondrmfb (fb0) is primary device fb0: radeondrmfb frame buffer device drm: registered panic notifier [drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0 Thank you Alex, thank you Michel and all those who (silently) contributed. Cool software indeed. All in all it was my inability to get it configured. cu, RandomCore -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 RandomCore changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #6 from RandomCore 2011-09-02 08:58:08 PDT --- ok, Got it now. I disabled the VESA fb framebuffer and added the radeonfb instead (want my penguins during boot). This did it. [51.021] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [51.021] (II) AIGLX: enabled GLX_INTEL_swap_event [51.021] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [51.021] (II) AIGLX: enabled GLX_SGI_make_current_read [51.021] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects [51.022] (II) AIGLX: Loaded and initialized /usr/lib/i386-linux-gnu/dri/r600_dri.so [51.022] (II) GLX: Initialized DRI2 GL provider for screen 0 Confirmation through $ glxinfo|grep render direct rendering: Yes OpenGL renderer string: Gallium 0.4 on AMD RS880 glxgears tells me it sync with the monitor now (and does indeed 60 FPS, but even on fullscreen). For those google'ing for answers, here's the dmesg bootlog from this one: $ grep drm dmesg_bootlog_20110902_1746 [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RS880 0x1002:0x9714). [drm] register mmio base: 0xFE6F [drm] register mmio size: 65536 [drm] Detected VRAM RAM=368M, BAR=256M [drm] RAM width 32bits DDR [drm] radeon: 368M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RS780 Microcode [drm] ring test succeeded in 0 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D [drm] HPD3 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_KLDSCP_LVTMA [drm] radeon: power management initialized [drm] fb mappable at 0xD0141000 [drm] vram apper at 0xD000 [drm] size 9216000 [drm] fb depth is 24 [drm]pitch is 7680 fbcon: radeondrmfb (fb0) is primary device fb0: radeondrmfb frame buffer device drm: registered panic notifier [drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0 Thank you Alex, thank you Michel and all those who (silently) contributed. Cool software indeed. All in all it was my inability to get it configured. cu, RandomCore -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: DPMS will keep switching monitor on and off
On Fri, Sep 2, 2011 at 6:29 AM, Wojciech Pyczak wrote: > Some time ago there was a patch [1] merged in which was designed to fix DPMS > (monitor would go on/off all the time [2] instead of just going off), I was > happy to see this one but unfortunately it doesn't work for me - I still > experience the same behaviour. > I'm terrible lazy so I didn't report it before but seeing that some > "unrelated" change might be the cause of bug in dri code (as in #42162) got > me wondering. This patch may also fix the issue: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d5811e8731213f80c80d89e980505052f16aca1c Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DPMS will keep switching monitor on and off
On Fri, Sep 2, 2011 at 6:29 AM, Wojciech Pyczak wrote: > Some time ago there was a patch [1] merged in which was designed to fix DPMS > (monitor would go on/off all the time [2] instead of just going off), I was > happy to see this one but unfortunately it doesn't work for me - I still > experience the same behaviour. > I'm terrible lazy so I didn't report it before but seeing that some > "unrelated" change might be the cause of bug in dri code (as in #42162) got > me wondering. > > Should I open a bug report for it ? File a bug (https://bugs.freedesktop.org) and attach your xorg log and dmesg output. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #5 from RandomCore 2011-09-02 08:42:15 PDT --- You were right; partly. It was tehre, but I guess the pathes in the kernel build got mixed up. Since I didn't know which firmware to include I included all, whihc made the string constant too long and the make fell back to configuration. So I changed the _DIR to "/lib/firmware/radeon" and added the firmwares without "radeon/" as prefix. Well, seems to have messed up the build process. Anyway, I did a mrproper and just included the R*.bin files. Here's the outcome: $ dmesg|grep drm [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [drm] initializing kernel modesetting (RS880 0x1002:0x9714). [drm] register mmio base: 0xFE6F [drm] register mmio size: 65536 [drm] Detected VRAM RAM=368M, BAR=256M [drm] RAM width 32bits DDR [drm] radeon: 368M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RS780 Microcode [drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD) [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D [drm] HPD3 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_KLDSCP_LVTMA [drm] radeon: power management initialized [drm] fb mappable at 0xD0141000 [drm] vram apper at 0xD000 [drm] size 9216000 [drm] fb depth is 24 [drm]pitch is 7680 fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver fbcon: radeondrmfb (fb1) is primary device fb1: radeondrmfb frame buffer device drm: registered panic notifier [drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0 I guess a failing ring-test is not that good. Performance (glxgears) is still around 730 FPS. Which firmwares shall I include for my HD4290 / RS880? Shall I disable the VESA console fb device? Oh, and there was no 30s pause anymore. cu, RandomCore -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #5 from RandomCore 2011-09-02 08:42:15 PDT --- You were right; partly. It was tehre, but I guess the pathes in the kernel build got mixed up. Since I didn't know which firmware to include I included all, whihc made the string constant too long and the make fell back to configuration. So I changed the _DIR to "/lib/firmware/radeon" and added the firmwares without "radeon/" as prefix. Well, seems to have messed up the build process. Anyway, I did a mrproper and just included the R*.bin files. Here's the outcome: $ dmesg|grep drm [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [drm] initializing kernel modesetting (RS880 0x1002:0x9714). [drm] register mmio base: 0xFE6F [drm] register mmio size: 65536 [drm] Detected VRAM RAM=368M, BAR=256M [drm] RAM width 32bits DDR [drm] radeon: 368M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RS780 Microcode [drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD) [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D [drm] HPD3 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_KLDSCP_LVTMA [drm] radeon: power management initialized [drm] fb mappable at 0xD0141000 [drm] vram apper at 0xD000 [drm] size 9216000 [drm] fb depth is 24 [drm]pitch is 7680 fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver fbcon: radeondrmfb (fb1) is primary device fb1: radeondrmfb frame buffer device drm: registered panic notifier [drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0 I guess a failing ring-test is not that good. Performance (glxgears) is still around 730 FPS. Which firmwares shall I include for my HD4290 / RS880? Shall I disable the VESA console fb device? Oh, and there was no 30s pause anymore. cu, RandomCore -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DPMS will keep switching monitor on and off
Some time ago there was a patch [1] merged in which was designed to fix DPMS (monitor would go on/off all the time [2] instead of just going off), I was happy to see this one but unfortunately it doesn't work for me - I still experience the same behaviour. I'm terrible lazy so I didn't report it before but seeing that some "unrelated" change might be the cause of bug in dri code (as in #42162) got me wondering. Should I open a bug report for it ? [1] 73104b5cfe3067d68f2c2de3f3d4d4964c55873e [2] https://bugzilla.redhat.com/show_bug.cgi?id=728228 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #4 from Michel Dänzer 2011-09-02 07:59:40 PDT --- (In reply to comment #3) > I installed firmware-linux-nonfree (Debian v0.33), added the necessary lines > to > the kernel .config to have them all included. [...] > r600_cp: Failed to load firmware "radeon/R600_rlc.bin" Well, at least this one is missing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #4 from Michel D?nzer 2011-09-02 07:59:40 PDT --- (In reply to comment #3) > I installed firmware-linux-nonfree (Debian v0.33), added the necessary lines > to > the kernel .config to have them all included. [...] > r600_cp: Failed to load firmware "radeon/R600_rlc.bin" Well, at least this one is missing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576
--- Comment #3 from RandomCore 2011-09-02 07:50:12 PDT
---
ok, one by one.
1) /lib/firmware/radeon
I installed firmware-linux-nonfree (Debian v0.33), added the necessary lines to
the kernel .config to have them all included.
Booting with this (radeon.modeset=0 or =1) was not different or better then
without.
2) PCI Quirks
I added CONFIG_PCI_QUIRKS=y to my .config
This got me some difference:
a) a 30s lag where the firmware should install:
$ grep "drm\|radeon" dmesg_bootlog_20110902_1624-kms-fw-pciquirks
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
radeon :01:05.0: setting latency timer to 64
[drm] initializing kernel modesetting (RS880 0x1002:0x9714).
[drm] register mmio base: 0xFE6F
[drm] register mmio size: 65536
radeon :01:05.0: VRAM: 368M 0xC000 - 0xD6FF (368M
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=368M, BAR=256M
[drm] RAM width 32bits DDR
[drm] radeon: 368M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
--->> 30s waiting <<---
r600_cp: Failed to load firmware "radeon/R600_rlc.bin"
[drm:r600_startup] *ERROR* Failed to load firmware!
radeon :01:05.0: disabling GPU acceleration
radeon :01:05.0: 88021f00f800 unpin not necessary
radeon :01:05.0: 88021f00f800 unpin not necessary
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] VGA
[drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm] Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm] DVI-D
[drm] HPD3
[drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm] Encoders:
[drm] DFP1: INTERNAL_KLDSCP_LVTMA
[drm] radeon: power management initialized
[drm] fb mappable at 0xD004
[drm] vram apper at 0xD000
[drm] size 9216000
[drm] fb depth is 24
[drm]pitch is 7680
fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
fbcon: radeondrmfb (fb1) is primary device
fb1: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0
b) Xorg seems to be faster (glxgears shows around 730 FPS now == 15% increase).
Here's the (relevant part of the) log:
$ grep "DRI" /var/log/Xorg.0.log
[ 139.748] (II) RADEON(0): Front buffer size: 9600K
[ 139.748] (II) RADEON(0): VRAM usage limit set to 218959K
[ 139.803] (==) RADEON(0): Backing store disabled
[ 139.803] (WW) RADEON(0): Direct rendering disabled
[ 139.803] (II) RADEON(0): Acceleration disabled
[ 139.803] (==) RADEON(0): DPMS enabled
[ 139.803] (==) RADEON(0): Silken mouse enabled
[ 139.805] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR
disabled message.
[ 139.805] (--) RandR disabled
[ 139.805] (II) Initializing built-in extension Generic Event Extension
[ 139.805] (II) Initializing built-in extension SHAPE
[ 139.805] (II) Initializing built-in extension MIT-SHM
[ 139.805] (II) Initializing built-in extension XInputExtension
[ 139.805] (II) Initializing built-in extension XTEST
[ 139.805] (II) Initializing built-in extension BIG-REQUESTS
[ 139.805] (II) Initializing built-in extension SYNC
[ 139.805] (II) Initializing built-in extension XKEYBOARD
[ 139.805] (II) Initializing built-in extension XC-MISC
[ 139.805] (II) Initializing built-in extension SECURITY
[ 139.805] (II) Initializing built-in extension XINERAMA
[ 139.805] (II) Initializing built-in extension XFIXES
[ 139.805] (II) Initializing built-in extension RENDER
[ 139.805] (II) Initializing built-in extension RANDR
[ 139.805] (II) Initializing built-in extension COMPOSITE
[ 139.805] (II) Initializing built-in extension DAMAGE
[ 139.807] (II) SELinux: Disabled on system
[ 139.227] (II) Loading extension XFree86-DRI
[ 139.239] (II) Loading extension DRI2
[ 139.816] (II) AIGLX: Screen 0 is not DRI2 capable
[ 139.816] (II) AIGLX: Screen 0 is not DRI capable
[ 139.962] (II) GLX: Initialized DRISWRAST GL provider for screen 0
Otherwise no (EE) in there and no more (WW) lines.
So, many thanks for this improvement alone (factor 12 against software renderer
only).
How can I address this firmware problem ("Failed to load firmware")? Why is it
the R600_rlc.bin and not the R700_rlc.bin? Is there a newer/better one around?
Anything more I can do or test?
cu, RandomCore
--
Configure bugmail: https:/
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576
--- Comment #3 from RandomCore 2011-09-02 07:50:12
PDT ---
ok, one by one.
1) /lib/firmware/radeon
I installed firmware-linux-nonfree (Debian v0.33), added the necessary lines to
the kernel .config to have them all included.
Booting with this (radeon.modeset=0 or =1) was not different or better then
without.
2) PCI Quirks
I added CONFIG_PCI_QUIRKS=y to my .config
This got me some difference:
a) a 30s lag where the firmware should install:
$ grep "drm\|radeon" dmesg_bootlog_20110902_1624-kms-fw-pciquirks
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
radeon :01:05.0: setting latency timer to 64
[drm] initializing kernel modesetting (RS880 0x1002:0x9714).
[drm] register mmio base: 0xFE6F
[drm] register mmio size: 65536
radeon :01:05.0: VRAM: 368M 0xC000 - 0xD6FF (368M
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=368M, BAR=256M
[drm] RAM width 32bits DDR
[drm] radeon: 368M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
--->> 30s waiting <<---
r600_cp: Failed to load firmware "radeon/R600_rlc.bin"
[drm:r600_startup] *ERROR* Failed to load firmware!
radeon :01:05.0: disabling GPU acceleration
radeon :01:05.0: 88021f00f800 unpin not necessary
radeon :01:05.0: 88021f00f800 unpin not necessary
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] VGA
[drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm] Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm] DVI-D
[drm] HPD3
[drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm] Encoders:
[drm] DFP1: INTERNAL_KLDSCP_LVTMA
[drm] radeon: power management initialized
[drm] fb mappable at 0xD004
[drm] vram apper at 0xD000
[drm] size 9216000
[drm] fb depth is 24
[drm]pitch is 7680
fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
fbcon: radeondrmfb (fb1) is primary device
fb1: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0
b) Xorg seems to be faster (glxgears shows around 730 FPS now == 15% increase).
Here's the (relevant part of the) log:
$ grep "DRI" /var/log/Xorg.0.log
[ 139.748] (II) RADEON(0): Front buffer size: 9600K
[ 139.748] (II) RADEON(0): VRAM usage limit set to 218959K
[ 139.803] (==) RADEON(0): Backing store disabled
[ 139.803] (WW) RADEON(0): Direct rendering disabled
[ 139.803] (II) RADEON(0): Acceleration disabled
[ 139.803] (==) RADEON(0): DPMS enabled
[ 139.803] (==) RADEON(0): Silken mouse enabled
[ 139.805] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR
disabled message.
[ 139.805] (--) RandR disabled
[ 139.805] (II) Initializing built-in extension Generic Event Extension
[ 139.805] (II) Initializing built-in extension SHAPE
[ 139.805] (II) Initializing built-in extension MIT-SHM
[ 139.805] (II) Initializing built-in extension XInputExtension
[ 139.805] (II) Initializing built-in extension XTEST
[ 139.805] (II) Initializing built-in extension BIG-REQUESTS
[ 139.805] (II) Initializing built-in extension SYNC
[ 139.805] (II) Initializing built-in extension XKEYBOARD
[ 139.805] (II) Initializing built-in extension XC-MISC
[ 139.805] (II) Initializing built-in extension SECURITY
[ 139.805] (II) Initializing built-in extension XINERAMA
[ 139.805] (II) Initializing built-in extension XFIXES
[ 139.805] (II) Initializing built-in extension RENDER
[ 139.805] (II) Initializing built-in extension RANDR
[ 139.805] (II) Initializing built-in extension COMPOSITE
[ 139.805] (II) Initializing built-in extension DAMAGE
[ 139.807] (II) SELinux: Disabled on system
[ 139.227] (II) Loading extension XFree86-DRI
[ 139.239] (II) Loading extension DRI2
[ 139.816] (II) AIGLX: Screen 0 is not DRI2 capable
[ 139.816] (II) AIGLX: Screen 0 is not DRI capable
[ 139.962] (II) GLX: Initialized DRISWRAST GL provider for screen 0
Otherwise no (EE) in there and no more (WW) lines.
So, many thanks for this improvement alone (factor 12 against software renderer
only).
How can I address this firmware problem ("Failed to load firmware")? Why is it
the R600_rlc.bin and not the R700_rlc.bin? Is there a newer/better one around?
Anything more I can do or test?
cu, RandomCore
--
Configure bugmail: https:/
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #16 from Alex Deucher 2011-09-02 14:33:03 --- (In reply to comment #15) > I think the problem is that the audio device is *advertised* as working, > although it doesn't. > radeon should just stop advertising audio if radeon.audio isn't set. The GPU driver doesn't advertise/handle the audio device. The alsa driver does. All the GPU driver does is enable the audio packets in the HDMI stream. I don't think there's a way for the gpu driver to tell the alsa driver not to load. Moreover, there are audio devices on certain boards with where the audio can be sent to either hdmi or regular audio ports so you would still want it that case. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 --- Comment #8 from Niels Ole Salscheider 2011-09-02 14:31:03 --- Created an attachment (id=71362) --> (https://bugzilla.kernel.org/attachment.cgi?id=71362) vbios -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 --- Comment #7 from Alex Deucher 2011-09-02 14:24:26 --- Please attach a copy of your vbios: (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix DP detect and EDID fetch for DP bridges
From: Alex Deucher
Sink type is always DP for DP bridges and EDID fetch on
DP bridges is always i2c over aux rather than plain i2c.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 37 ++--
drivers/gpu/drm/radeon/radeon_display.c| 19 +-
2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 7f65940..9efb356 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1287,12 +1287,33 @@ radeon_dp_detect(struct drm_connector *connector, bool
force)
if (!radeon_dig_connector->edp_on)
atombios_set_edp_panel_power(connector,
ATOM_TRANSMITTER_ACTION_POWER_OFF);
- } else {
- /* need to setup ddc on the bridge */
- if (radeon_connector_encoder_is_dp_bridge(connector)) {
+ } else if (radeon_connector_encoder_is_dp_bridge(connector)) {
+ /* DP bridges are always DP */
+ radeon_dig_connector->dp_sink_type =
CONNECTOR_OBJECT_ID_DISPLAYPORT;
+ /* get the DPCD from the bridge */
+ radeon_dp_getdpcd(radeon_connector);
+
+ if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd))
+ ret = connector_status_connected;
+ else {
+ /* need to setup ddc on the bridge */
if (encoder)
radeon_atom_ext_encoder_setup_ddc(encoder);
+ if (radeon_ddc_probe(radeon_connector,
+
radeon_connector->requires_extended_probe))
+ ret = connector_status_connected;
+ }
+
+ if ((ret == connector_status_disconnected) &&
+ radeon_connector->dac_load_detect) {
+ struct drm_encoder *encoder =
radeon_best_single_encoder(connector);
+ struct drm_encoder_helper_funcs *encoder_funcs;
+ if (encoder) {
+ encoder_funcs = encoder->helper_private;
+ ret = encoder_funcs->detect(encoder, connector);
+ }
}
+ } else {
radeon_dig_connector->dp_sink_type =
radeon_dp_getsinktype(radeon_connector);
if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) {
ret = connector_status_connected;
@@ -1308,16 +1329,6 @@ radeon_dp_detect(struct drm_connector *connector, bool
force)
ret = connector_status_connected;
}
}
-
- if ((ret == connector_status_disconnected) &&
- radeon_connector->dac_load_detect) {
- struct drm_encoder *encoder =
radeon_best_single_encoder(connector);
- struct drm_encoder_helper_funcs *encoder_funcs;
- if (encoder) {
- encoder_funcs = encoder->helper_private;
- ret = encoder_funcs->detect(encoder, connector);
- }
- }
}
radeon_connector_update_scratch_regs(connector, ret);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 1a85894..6cc17fb 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -707,16 +707,21 @@ int radeon_ddc_get_modes(struct radeon_connector
*radeon_connector)
radeon_router_select_ddc_port(radeon_connector);
if ((radeon_connector->base.connector_type ==
DRM_MODE_CONNECTOR_DisplayPort) ||
- (radeon_connector->base.connector_type == DRM_MODE_CONNECTOR_eDP)) {
+ (radeon_connector->base.connector_type == DRM_MODE_CONNECTOR_eDP) ||
+ radeon_connector_encoder_is_dp_bridge(&radeon_connector->base)) {
struct radeon_connector_atom_dig *dig =
radeon_connector->con_priv;
+
if ((dig->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT ||
dig->dp_sink_type == CONNECTOR_OBJECT_ID_eDP) &&
dig->dp_i2c_bus)
- radeon_connector->edid =
drm_get_edid(&radeon_connector->base, &dig->dp_i2c_bus->adapter);
- }
- if (!radeon_connector->ddc_bus)
- return -1;
- if (!radeon_connector->edid) {
- radeon_connector->edid = drm_get_edid(&radeon_connector->base,
&radeon_connector->ddc_bus->adapter);
+ radeon_connector->edid =
drm_get_edid(&radeon_connector->base,
+
&dig->dp_i2c_bus->adapter);
+ else if (radeon_conn
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 Xavier Bestel changed: What|Removed |Added CC||xavier.bes...@free.fr --- Comment #15 from Xavier Bestel 2011-09-02 14:19:17 --- I think the problem is that the audio device is *advertised* as working, although it doesn't. radeon should just stop advertising audio if radeon.audio isn't set. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 --- Comment #6 from Niels Ole Salscheider 2011-09-02 14:04:51 --- Created an attachment (id=71342) --> (https://bugzilla.kernel.org/attachment.cgi?id=71342) edid for display connected to LVDS -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 --- Comment #5 from Niels Ole Salscheider 2011-09-02 14:03:30 --- Created an attachment (id=71332) --> (https://bugzilla.kernel.org/attachment.cgi?id=71332) dmesg output with drm.debug=4 note: radeon_fp_native_mode gets calld for LVDS although get-edid can find valid edid data for it (see next attachment) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #2 from Alex Deucher 2011-09-02 06:58:24 PDT --- Make sure you enable PCI quirks in your kernel. They are needed to access the vbios rom on a lot of cards. Without access to the vbios, the drm can't set up your card. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #2 from Alex Deucher 2011-09-02 06:58:24 PDT --- Make sure you enable PCI quirks in your kernel. They are needed to access the vbios rom on a lot of cards. Without access to the vbios, the drm can't set up your card. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27069] OpenGl is slower on dri2
https://bugs.freedesktop.org/show_bug.cgi?id=27069 --- Comment #8 from Alex Deucher 2011-09-02 06:49:43 PDT --- UMS supported Colortiling and hyperZ on r1xx/r2xx asics and a few other features that haven't been implemented with KMS yet. The information is available if someone wants to add support to KMS. KMS also defaults to vsynced 3D. r3xx and newer asics should be faster with KMS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27069] OpenGl is slower on dri2
https://bugs.freedesktop.org/show_bug.cgi?id=27069 --- Comment #8 from Alex Deucher 2011-09-02 06:49:43 PDT --- UMS supported Colortiling and hyperZ on r1xx/r2xx asics and a few other features that haven't been implemented with KMS yet. The information is available if someone wants to add support to KMS. KMS also defaults to vsynced 3D. r3xx and newer asics should be faster with KMS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #14 from Alex Deucher 2011-09-02 13:44:29 --- (In reply to comment #13) > (I don't know the details of this bug, but am just responding to comment #11) > @Michel: Fixing regressions without introducing other regressions is a > prerequisite for being sure of forward progress. Else it's possible we are > going in circles. The policy on the linux kernel is: no regressions. So, we > revert even fixes if they cause _new_ regressions. Not being able to see your screen(s) seems like a bigger issue than having to set an option to enable audio. Although, audio support itself regressed working video for the bad cases originally, so audio support was a regression as well for some people. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27069] OpenGl is slower on dri2
https://bugs.freedesktop.org/show_bug.cgi?id=27069 --- Comment #7 from Tom Stellard 2011-09-02 06:20:39 PDT --- (In reply to comment #4) > (In reply to comment #3) > > This problem still exists, > I forgot to add the usual software version info: > > Kernel: 3.0.4-gentoo > Xorg: X.Org X Server 1.10.2 > DDX: xf86-video-ati-6.14.2 > Mesa: Mesa 7.11. (Also tried mesa git, revision db3a7c366b5) Can you also post the output of dmesg and glxinfo, as well as your Xorg.log. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27069] OpenGl is slower on dri2
https://bugs.freedesktop.org/show_bug.cgi?id=27069 --- Comment #7 from Tom Stellard 2011-09-02 06:20:39 PDT --- (In reply to comment #4) > (In reply to comment #3) > > This problem still exists, > I forgot to add the usual software version info: > > Kernel: 3.0.4-gentoo > Xorg: X.Org X Server 1.10.2 > DDX: xf86-video-ati-6.14.2 > Mesa: Mesa 7.11. (Also tried mesa git, revision db3a7c366b5) Can you also post the output of dmesg and glxinfo, as well as your Xorg.log. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27069] OpenGl is slower on dri2
https://bugs.freedesktop.org/show_bug.cgi?id=27069 --- Comment #6 from Xavier Bestel 2011-09-02 06:11:01 PDT --- That does not explain the 15-20 fps he sees with etracer. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27069] OpenGl is slower on dri2
https://bugs.freedesktop.org/show_bug.cgi?id=27069 --- Comment #6 from Xavier Bestel 2011-09-02 06:11:01 PDT --- That does not explain the 15-20 fps he sees with etracer. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #1 from Michel Dänzer 2011-09-02 06:06:47 PDT --- (In reply to comment #1) > CONFIG_DRM_RADEON=y In that case KMS requires the microcode from /lib/firmware/radeon to be built into the kernel as well. Are you doing that? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 --- Comment #1 from Michel D?nzer 2011-09-02 06:06:47 PDT --- (In reply to comment #1) > CONFIG_DRM_RADEON=y In that case KMS requires the microcode from /lib/firmware/radeon to be built into the kernel as well. Are you doing that? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH 10/10] vmwgfx: Implement GMR2
On Wed, Aug 31, 2011 at 09:42:55AM +0200, Thomas Hellstrom wrote:
> Guest Memory Regions 2 is a way to bind pages to the GPU, but using
> the FIFO instead of an io-submitted descriptor chain.
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Jakob Bornecantz
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c | 81
> ++-
> 1 files changed, 80 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
> index de0c594..f4e7763 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
> @@ -1,6 +1,6 @@
> /**
> *
> - * Copyright © 2009 VMware, Inc., Palo Alto, CA., USA
> + * Copyright © 2009-2011 VMware, Inc., Palo Alto, CA., USA
> * All Rights Reserved.
> *
> * Permission is hereby granted, free of charge, to any person obtaining a
> @@ -29,6 +29,77 @@
> #include "drmP.h"
> #include "ttm/ttm_bo_driver.h"
>
> +#define VMW_PPN_SIZE sizeof(unsigned long)
> +
> +static int vmw_gmr2_bind(struct vmw_private *dev_priv,
> + struct page *pages[],
> + unsigned long num_pages,
> + int gmr_id)
> +{
> + SVGAFifoCmdDefineGMR2 define_cmd;
> + SVGAFifoCmdRemapGMR2 remap_cmd;
> + uint32_t define_size = sizeof(define_cmd) + 4;
> + uint32_t remap_size = VMW_PPN_SIZE * num_pages + sizeof(remap_cmd) + 4;
Why the +4? Is it just as a precaution in case you over-ran?
> + uint32_t *cmd;
> + uint32_t *cmd_orig;
> + uint32_t i;
> +
> + cmd_orig = cmd = vmw_fifo_reserve(dev_priv, define_size + remap_size);
> + if (unlikely(cmd == NULL))
> + return -ENOMEM;
> +
> + define_cmd.gmrId = gmr_id;
> + define_cmd.numPages = num_pages;
> +
> + remap_cmd.gmrId = gmr_id;
> + remap_cmd.flags = (VMW_PPN_SIZE > sizeof(*cmd)) ?
> + SVGA_REMAP_GMR2_PPN64 : SVGA_REMAP_GMR2_PPN32;
> + remap_cmd.offsetPages = 0;
> + remap_cmd.numPages = num_pages;
> +
> + *cmd++ = SVGA_CMD_DEFINE_GMR2;
> + memcpy(cmd, &define_cmd, sizeof(define_cmd));
> + cmd += sizeof(define_cmd) / sizeof(uint32);
ALIGN macro? Thought I would have thought you would
want:
cmd += sizeof(define_cmd) - sizeof(uint32);
since you stuck a SVGA_CMD_DEFINE_GMR2 and then copied
the define_cmd right afterwards?
> +
> + *cmd++ = SVGA_CMD_REMAP_GMR2;
> + memcpy(cmd, &remap_cmd, sizeof(remap_cmd));
> + cmd += sizeof(remap_cmd) / sizeof(uint32);
> +
> + for (i = 0; i < num_pages; ++i) {
> + if (VMW_PPN_SIZE > 4)
> + *cmd = page_to_pfn(*pages++);
> + else
> + *((uint64_t *)cmd) = page_to_pfn(*pages++);
> +
> + cmd += VMW_PPN_SIZE / sizeof(*cmd);
> + }
> +
> + vmw_fifo_commit(dev_priv, define_size + remap_size);
> +
> + return 0;
> +}
> +
> +static void vmw_gmr2_unbind(struct vmw_private *dev_priv,
> + int gmr_id)
> +{
> + SVGAFifoCmdDefineGMR2 define_cmd;
> + uint32_t define_size = sizeof(define_cmd) + 4;
> + uint32_t *cmd;
> +
> + cmd = vmw_fifo_reserve(dev_priv, define_size);
> + if (unlikely(cmd == NULL)) {
> + DRM_ERROR("GMR2 unbind failed.\n");
> + return;
> + }
> + define_cmd.gmrId = gmr_id;
> + define_cmd.numPages = 0;
> +
> + *cmd++ = SVGA_CMD_DEFINE_GMR2;
Ah, that is what the +4 is for. Would it be cleaner
to just do 'sizeof(SVGA_CMD_DEFINE_GMR2)' ?
> + memcpy(cmd, &define_cmd, sizeof(define_cmd));
> +
> + vmw_fifo_commit(dev_priv, define_size);
> +}
> +
> /**
> * FIXME: Adjust to the ttm lowmem / highmem storage to minimize
> * the number of used descriptors.
> @@ -170,6 +241,9 @@ int vmw_gmr_bind(struct vmw_private *dev_priv,
> struct list_head desc_pages;
> int ret;
>
> + if (likely(dev_priv->capabilities & SVGA_CAP_GMR2))
> + return vmw_gmr2_bind(dev_priv, pages, num_pages, gmr_id);
> +
> if (unlikely(!(dev_priv->capabilities & SVGA_CAP_GMR)))
> return -EINVAL;
>
> @@ -192,6 +266,11 @@ int vmw_gmr_bind(struct vmw_private *dev_priv,
>
> void vmw_gmr_unbind(struct vmw_private *dev_priv, int gmr_id)
> {
> + if (likely(dev_priv->capabilities & SVGA_CAP_GMR2)) {
> + vmw_gmr2_unbind(dev_priv, gmr_id);
> + return;
> + }
> +
> mutex_lock(&dev_priv->hw_mutex);
> vmw_write(dev_priv, SVGA_REG_GMR_ID, gmr_id);
> wmb();
> --
> 1.7.4.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> 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
[Bug 27069] OpenGl is slower on dri2
https://bugs.freedesktop.org/show_bug.cgi?id=27069 --- Comment #5 from Thierry Vignaud 2011-09-02 05:17:51 PDT --- This is because output is maxed at screen refreshing and won't go over 60fps -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27069] OpenGl is slower on dri2
https://bugs.freedesktop.org/show_bug.cgi?id=27069 --- Comment #5 from Thierry Vignaud 2011-09-02 05:17:51 PDT --- This is because output is maxed at screen refreshing and won't go over 60fps -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40576] New: HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 Summary: HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: freedesk...@erben.com I have a Debian (somewhere between unstable and testing) and a homebrewn kernel (v3.0.1 with vserver 2.3.1-pre9) on my M4A89GTD/Pro. The M4A89GTD/Pro has HD4290 on-board graphics (RS880). There's no other graphic card installed. For bootup I have a vesa console framebuffer configured but no radeon (couldn't get it to work). If I set in my kernel .config file CONFIG_DRM_RADEON=y CONFIG_DRM_RADEON_KMS=y a dmesg shows: [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. checking generic (d000 28) vs hw (d000 1000) fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 radeon :01:05.0: setting latency timer to 64 [drm] initializing kernel modesetting (RS880 0x1002:0x9714). [drm] register mmio base: 0xFE6F [drm] register mmio size: 65536 radeon :01:05.0: BAR 6: can't assign [??? 0x flags 0x0] (bogus alignment) [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM radeon :01:05.0: Fatal error during GPU init [drm] radeon: finishing device. Unnecessary to tell, that there are no /dev/dri/* around then. If I unset CONFIG_DRM_RADEON_KMS I get: [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to userspace modesetting. pci :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 pci :01:05.0: setting latency timer to 64 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] No driver support for vblank timestamp query. [drm] Initialized radeon 1.33.0 20080528 for :01:05.0 on minor 0 ... (much later, at the end) ... [drm] Setting GART location based on new memory map [drm] Loading RS780 CP Microcode [drm] Resetting GPU [drm] writeback test succeeded in 1 usecs [drm] Resetting GPU and /dev/dri/card0 is present. The Problem however is that the libGL (Debian libgl1-mesa-glx v7.11-5, xorg v1:7.5+8) has Problems with that: $ LIBGL_DEBUG=verbose /usr/bin/glxinfo -b libGL: XF86DRIGetClientDriverName: 4.3.0 r600 (screen 0) libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/r600_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci::01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: Interface 1.4 failed, trying 1.1 drmOpenByBusid: drmGetBusid reports pci::01:05.0 libGL error: Calling driver entry point failed libGL error: reverting to software direct rendering ... The performance of X (measured with glxgears) without KMS (~630 FPS) is better than with KMS and no DRI (~85 FPS), but there should be more. Do you have any idea, what I can change? Or, can I do more to help analyzing this? cu, RandomCore -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40576] New: HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled
https://bugs.freedesktop.org/show_bug.cgi?id=40576 Summary: HD4290 (Asus M4A89GTD/Pro onboard): no DRI (/dev/dri/card0) with CONFIG_DRM_RADEON_KMS enabled Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: freedesktop at erben.com I have a Debian (somewhere between unstable and testing) and a homebrewn kernel (v3.0.1 with vserver 2.3.1-pre9) on my M4A89GTD/Pro. The M4A89GTD/Pro has HD4290 on-board graphics (RS880). There's no other graphic card installed. For bootup I have a vesa console framebuffer configured but no radeon (couldn't get it to work). If I set in my kernel .config file CONFIG_DRM_RADEON=y CONFIG_DRM_RADEON_KMS=y a dmesg shows: [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. checking generic (d000 28) vs hw (d000 1000) fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 radeon :01:05.0: setting latency timer to 64 [drm] initializing kernel modesetting (RS880 0x1002:0x9714). [drm] register mmio base: 0xFE6F [drm] register mmio size: 65536 radeon :01:05.0: BAR 6: can't assign [??? 0x flags 0x0] (bogus alignment) [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM radeon :01:05.0: Fatal error during GPU init [drm] radeon: finishing device. Unnecessary to tell, that there are no /dev/dri/* around then. If I unset CONFIG_DRM_RADEON_KMS I get: [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to userspace modesetting. pci :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 pci :01:05.0: setting latency timer to 64 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] No driver support for vblank timestamp query. [drm] Initialized radeon 1.33.0 20080528 for :01:05.0 on minor 0 ... (much later, at the end) ... [drm] Setting GART location based on new memory map [drm] Loading RS780 CP Microcode [drm] Resetting GPU [drm] writeback test succeeded in 1 usecs [drm] Resetting GPU and /dev/dri/card0 is present. The Problem however is that the libGL (Debian libgl1-mesa-glx v7.11-5, xorg v1:7.5+8) has Problems with that: $ LIBGL_DEBUG=verbose /usr/bin/glxinfo -b libGL: XF86DRIGetClientDriverName: 4.3.0 r600 (screen 0) libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/r600_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci::01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: Interface 1.4 failed, trying 1.1 drmOpenByBusid: drmGetBusid reports pci::01:05.0 libGL error: Calling driver entry point failed libGL error: reverting to software direct rendering ... The performance of X (measured with glxgears) without KMS (~630 FPS) is better than with KMS and no DRI (~85 FPS), but there should be more. Do you have any idea, what I can change? Or, can I do more to help analyzing this? cu, RandomCore -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42172] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:267 radeon_fence_wait+0x39f/0x3d0()
https://bugzilla.kernel.org/show_bug.cgi?id=42172 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #4 from Alex Deucher 2011-09-02 05:02:08 --- Should mark this as a dupe of bug 42162 then. Does the patch on bug 42162 help? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
RE: [RFC][PATCH v3] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
Hello Rob.
Below is my comments.
> -Original Message-
> From: Rob Clark [mailto:robdcl...@gmail.com]
> Sent: Friday, September 02, 2011 10:18 AM
> To: Inki Dae
> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
> sw0312@samsung.com; linux-ker...@vger.kernel.org;
> kyungmin.p...@samsung.com; linux-arm-ker...@lists.infradead.org
> Subject: Re: [RFC][PATCH v3] DRM: add DRM Driver for Samsung SoC
> EXYNOS4210.
>
> On Thu, Sep 1, 2011 at 8:06 AM, Inki Dae wrote:
> >> >> > +struct samsung_drm_gem_obj *
> >> >> > + find_samsung_drm_gem_object(struct drm_file
> > *file_priv,
> >> >> > + struct drm_device *dev, unsigned int
handle)
> >> >> > +{
> >> >> > + struct drm_gem_object *gem_obj;
> >> >> > +
> >> >> > + gem_obj = drm_gem_object_lookup(dev, file_priv, handle);
> >> >> > + if (!gem_obj) {
> >> >> > + DRM_LOG_KMS("a invalid gem object not registered
to
> >> >> lookup.\n");
> >> >> > + return NULL;
> >> >> > + }
> >> >> > +
> >> >> > + /**
> >> >> > + * unreference refcount of the gem object.
> >> >> > + * at drm_gem_object_lookup(), the gem object was
> referenced.
> >> >> > + */
> >> >> > + drm_gem_object_unreference(gem_obj);
> >> >>
> >> >> this doesn't seem right, to drop the reference before you use the
> >> >> buffer elsewhere..
> >> >>
> >> > No, see drm_gem_object_lookup fxn. at this function, if there is a
> >> object
> >> > found then drm_gem_object_reference is called to increase refcount of
> >> this
> >> > object. if there is any missing point, give me any comment please.
> thank
> >> > you.
> >>
> >>
> >> Right, but I think there is a reason it takes a reference... so that
> >> the object doesn't get free'd from under your feet. So pattern
> >> should, I think, be:
> >>
> >> obj = lookup(...);
> >> ... do stuff w/ obj ...
> >> unreference(obj)
> >>
> >> so the caller who is using the looked up obj should unref it when done
> >>
> >> Instead, you have:
> >>
> >> obj = lookup(...);
> >> unreference(obj);
> >> ... do stuff w/ obj ...
> >>
> >>
> >
> > Generally right, but in this case, it is just used to get specific gem
> > object through find_samsung_drm_gem_object() so doesn't reference this
> gem
> > object anywhere.
> > therefore reference and unreference should be done within
> > find_samsung_drm_gem_object(). if there is any point I missed then let
> me
> > know please. thank you.
> >
>
> Still, it seems like find_samsung_drm_gem_object() is encouraging the
> wrong usage-pattern, even if it works fine today because you know
> somewhere else is holding a reference to the object. Later if you
> expand your use of GEM objects, this fxn might come back to bite you.
> There is a good reason that drm_gem_object_lookup() takes a reference
> to the object, and it feels wrong to intentionally subvert that.
>
> (I'm perfectly willing to be overridden on the subject.. there are
> plenty of folks on this list who have been doing the GEM thing longer
> than I have. But it just seems better to use APIs like
> drm_gem_object_lookup() the way they were intended.)
>
Ah, you are right. I misunderstanded it. as you pointed out, a gem object
should be unreferenced after doing something with the gem object. so I will
remove find_samsung_drm_gem_object() and use drm_gem_object_lookup()
directly to get a gem object instead. of course, the gem object will be
unreferenced after doing something with it. thank you for your explanation.
:)
> BR,
> -R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42172] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:267 radeon_fence_wait+0x39f/0x3d0()
https://bugzilla.kernel.org/show_bug.cgi?id=42172 --- Comment #5 from nissa...@gmail.com 2011-09-02 09:52:26 --- Yes, it seems to be the same issue. Currently I'm testing the patch, I'll notify you later if it worked for me. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm-fixes from an alternate place
Hi Linus, two radeon fixes from my tree on fd.o, not sure you can really do much, since its not like you can republish it :) Dave. The following changes since commit 9e79e3e9dd9672b37ac9412e9a926714306551fe: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (2011-08-30 11:28:18 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes Alex Deucher (1): drm/radeon/kms: make sure pci max read request size is valid on evergreen+ (v2) Dave Airlie (1): drm/radeon/kms: set a default max_pixel_clock drivers/gpu/drm/radeon/evergreen.c | 27 +++ drivers/gpu/drm/radeon/ni.c|3 +++ drivers/gpu/drm/radeon/radeon_clocks.c |3 +++ 3 files changed, 33 insertions(+), 0 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #13 from Florian Mickler 2011-09-02 09:47:04 --- (I don't know the details of this bug, but am just responding to comment #11) @Michel: Fixing regressions without introducing other regressions is a prerequisite for being sure of forward progress. Else it's possible we are going in circles. The policy on the linux kernel is: no regressions. So, we revert even fixes if they cause _new_ regressions. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/i915: pass ELD to HDMI/DP audio driver
Keith: this version completes the IvyBridge support :) Bossart: hotplug is working fine now, with some minor issues: - on G45, monitor hot removal is not handled at all in i915_driver_irq_handler(). I'll leave it as a future TODO. - on IvyBridge, _repeated_ plug/unplug will trigger [ 1183.654859] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 which means the ELD_valid flag will be seen by audio driver, however it cannot get any valid ELD data. I double checked and find everything in the graphics driver is working as expected: ironlake_write_eld() is writing the good ELD data to the same pipe on hot plug events. So I'll leave it as a possible bug of the early stage hardware. Thanks, Fengguang ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/i915: pass ELD to HDMI/DP audio driver
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be used. This policy may not be suitable for all users, but
let's start it simple first.
The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor. Overall,
it's more safe to report maximum profiles to the user space, so that
the user can at least be able to do 8-channel playback if he want to.
This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
Minor imperfection: the GEN6_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.
Thanks to Zhenyu and Bossart for a lot of valuable help and testing.
CC: Zhao Yakui
CC: Wang Zhenyu
CC: Jeremy Bush
CC: Christopher White
CC: "Bossart, Pierre-louis"
Signed-off-by: Ben Skeggs
Signed-off-by: Wu Fengguang
---
drivers/gpu/drm/drm_edid.c | 171 +
drivers/gpu/drm/i915/i915_drv.h |2
drivers/gpu/drm/i915/i915_reg.h | 25 +++
drivers/gpu/drm/i915/intel_display.c | 132 +++
drivers/gpu/drm/i915/intel_dp.c |6
drivers/gpu/drm/i915/intel_drv.h |2
drivers/gpu/drm/i915/intel_hdmi.c|3
drivers/gpu/drm/i915/intel_modes.c |2
include/drm/drm_crtc.h |9 +
include/drm/drm_edid.h |9 +
10 files changed, 359 insertions(+), 2 deletions(-)
--- linux-next.orig/drivers/gpu/drm/drm_edid.c 2011-09-02 15:59:35.0
+0800
+++ linux-next/drivers/gpu/drm/drm_edid.c 2011-09-02 15:59:40.0
+0800
@@ -1319,6 +1319,7 @@ add_detailed_modes(struct drm_connector
#define HDMI_IDENTIFIER 0x000C03
#define AUDIO_BLOCK0x01
#define VENDOR_BLOCK0x03
+#define SPEAKER_BLOCK 0x04
#define EDID_BASIC_AUDIO (1 << 6)
/**
@@ -1347,6 +1348,176 @@ u8 *drm_find_cea_extension(struct edid *
}
EXPORT_SYMBOL(drm_find_cea_extension);
+static void
+parse_hdmi_vsdb(struct drm_connector *connector, uint8_t *db)
+{
+ connector->eld[5] |= (db[6] >> 7) << 1; /* Supports_AI */
+
+ connector->dvi_dual = db[6] & 1;
+ connector->max_tmds_clock = db[7] * 5;
+
+ connector->latency_present[0] = db[8] >> 7;
+ connector->latency_present[1] = (db[8] >> 6) & 1;
+ connector->video_latency[0] = db[9];
+ connector->audio_latency[0] = db[10];
+ connector->video_latency[1] = db[11];
+ connector->audio_latency[1] = db[12];
+
+ DRM_LOG_KMS("HDMI: DVI dual %d, "
+ "max TMDS clock %d, "
+ "latency present %d %d, "
+ "video latency %d %d, "
+ "audio latency %d %d\n",
+ connector->dvi_dual,
+ connector->max_tmds_clock,
+ (int) connector->latency_present[0],
+ (int) connector->latency_present[1],
+ connector->video_latency[0],
+ connector->video_latency[1],
+ connector->audio_latency[0],
+ connector->audio_latency[1]);
+}
+
+static void
+monitor_name(struct detailed_timing *t, void *data)
+{
+ if (t->data.other_data.type == EDID_DETAIL_MONITOR_NAME)
+ *(u8 **)data = t->data.other_data.data.str.str;
+}
+
+/**
+ * drm_edid_to_eld - build ELD from EDID
+ * @connector: connector corresponding to the HDMI/DP sink
+ * @edid: EDID to parse
+ *
+ * Fill the ELD (EDID-Like Data) buffer for passing to the audio driver.
+ * Some ELD fields are left to the graphics driver caller:
+ * - Conn_Type
+ * - HDCP
+ * - Port_ID
+ */
+void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
+{
+ uint8_t *eld = connector->eld;
+ u8 *cea;
+ u8 *name;
+ u8 *db;
+
[Bug 42172] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:267 radeon_fence_wait+0x39f/0x3d0()
https://bugzilla.kernel.org/show_bug.cgi?id=42172 --- Comment #3 from nissarin at gmail.com 2011-09-02 00:59:20 --- More than 8 hours have passed without a single glitch (same as before.. glxgears, web browser, wesnoth, etc.) so yeah, it appears that b03e7495a862b028294f59fc87286d6d78ee7fa1 is most likely the cause. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #11 from Michel D?nzer 2011-08-29 17:46:25 --- If you want to consider this a regression, it was caused by the currently best known fix for another regression: enabling HDMI audio by default caused blank screens and display problems. Are you seriously suggesting going back to that would be the better? --- Comment #12 from Andreas Steinmetz 2011-09-02 00:21:00 --- I am suggesting that if audio is disabled by default the HDMI output must not be advertised as an alsa device. If the device is not there users will look for what switch to use to enable the device if the device works for them with no side effects. The way it is now is a cable that is plugged in on both sides but after a long search is apparently broken somewhere in between. You know, probably from experience, that this state of affairs is no fun. That's what I'm seriously suggesting. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
