[Bug 41592] [Radeon] The display often freezes with gnome-shell 3.2
https://bugs.freedesktop.org/show_bug.cgi?id=41592 --- Comment #8 from miran...@orange.fr 2011-10-30 04:35:13 PDT --- Sorry for the delay, I haven't had time to work on this sooner. The "freeze" seems to begin to (ramdomly) happen after that gnome-screensaver switches off the screen. As Archlinux don't provides debug packages, I must recompile some packages, and I have an error when I try to recompile X, I'm trying to solve that. But the gnome packager provides some debug packages for gnome, so I can have a backtrace when the problem occur. I don't know if it's usefull, maybe I should open a bugreport on the gnome-shell bugzilla too ? -- 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 41592] [Radeon] The display often freezes with gnome-shell 3.2
https://bugs.freedesktop.org/show_bug.cgi?id=41592 --- Comment #9 from miran...@orange.fr 2011-10-30 04:35:59 PDT --- Created attachment 52909 --> https://bugs.freedesktop.org/attachment.cgi?id=52909 gdb 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 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #7 from Chris Wilson 2011-10-30 05:44:20 PDT --- I've just tried to reproduce this running firefox+chromium+others under e17 using SNA. I'm pretty certain this was the tiling bugs we fixed early. -- 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 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #8 from Bruno 2011-10-30 05:55:23 PDT --- (In reply to comment #7) > I've just tried to reproduce this running firefox+chromium+others under e17 > using SNA. I'm pretty certain this was the tiling bugs we fixed early. I've not seen them recently either, except for sporadically a pixel line with with white/gray pixels in the e17 cursor. (always at same place of the cursor, more or less middle in height). Might be there is one tiling bug remaining around cursor handling. -- 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
Re: [Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
> --- Comment #8 from Bruno 2011-10-30 05:55:23 PDT --- > I've not seen them recently either, except for sporadically a pixel line with > with white/gray pixels in the e17 cursor. (always at same place of the cursor, > more or less middle in height). > Might be there is one tiling bug remaining around cursor handling. Cursors on gen2 are stored in physical mem. On a quick lock we're indeed missing the clflush that should be there. Let me whip up a patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #9 from Daniel Vetter 2011-10-30 06:44:19 PDT --- > --- Comment #8 from Bruno 2011-10-30 05:55:23 PDT --- > I've not seen them recently either, except for sporadically a pixel line with > with white/gray pixels in the e17 cursor. (always at same place of the cursor, > more or less middle in height). > Might be there is one tiling bug remaining around cursor handling. Cursors on gen2 are stored in physical mem. On a quick lock we're indeed missing the clflush that should be there. Let me whip up a patch. -Daniel -- 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 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #10 from Daniel Vetter 2011-10-30 06:46:37 PDT --- Created attachment 52913 --> https://bugs.freedesktop.org/attachment.cgi?id=52913 clflush phys objects to fix cursor corruptions Test-feedback highly appreciated. -- 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 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 Daniel Vetter changed: What|Removed |Added Attachment #52913|0 |1 is obsolete|| --- Comment #11 from Daniel Vetter 2011-10-30 08:42:04 PDT --- Created attachment 52920 --> https://bugs.freedesktop.org/attachment.cgi?id=52920 clflush phys objects to fix cursor corruptions Chris Wilson pointed out that I'm missing memory barriers. -- 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
Re: [Intel-gfx] [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there
Hi Eugeni, On Mon, 24 Oct 2011 12:40:14 -0200, Eugeni Dodonov wrote: > On Thu, Oct 20, 2011 at 10:33, Jean Delvare wrote: > > > Just to clarify: by "connectivity is setup", do you mean code in the > > driver setting the GPIO pin direction etc., or a display being > > connected to the graphics card? > > > > I admit I am a little surprised. I2C buses should have their lines up > > by default, thanks to pull-up resistors, and masters and slaves should > > merely drive the lines low as needed. The absence of slaves should have > > no impact on the line behavior. If the Intel graphics chips (or the > > driver) rely on the display to hold the lines high, I'd say this is a > > seriously broken design. > > > > As a side note, I thought that HDMI had the capability of presence > > detection, so there may be a better way to know if a display is > > connected or not, and this information could used to dynamically > > instantiate and delete the I2C buses? That way we could skip probing > > for EDID when there is no chance of success. > > Yes, I think so too. > > I admit I haven't got to the root of the problem here. My test was really > simple, borrowed from the test_bus() at i2c-algo-bit.c - without HDMI cable > plugged in, I was getting the "SDA stuck high" messages; with the cable > plugged in, I wasn't getting any of those. Just the HDMI cable, or with a screen at the other end? Either way, this smells like bad hardware design. The graphics card itself should pull the I2C bus lines up by default, it shouldn't rely on a cable (I'm not familiar with HDMI but I'm not sure if that makes sense at all) or external display (more likely) to do it. But I can also imagine that this could be a driver issue, maybe the GPIO lines aren't setup properly by the driver? I'm not familiar enough with the Intel graphics hardware and driver to tell, you'll know better. > But in any case, I haven't investigated it deeper in the hardware direction > after figuring out that drm_get_edid would retry its attempts for retreiving > the edid for 15 times, getting the -ENXIO error for all of them. > > > > Well, you could always do manual line testing of the I2C bus _before_ > > calling drm_do_probe_ddc_edid()? And skip the call if the test fails > > (i.e. the bus isn't ready for use.) As said before, I am willing to > > export bit_test if it helps any. I've attached a patch doing exactly > > this. Let me know if you want me to commit it. > > Yes, surely, I can do this. I did a similar test in the i915-specific patch, > checking if we can talk to i2c adapter pior to call drm_do_probe_ddc_edid, > but I thought that perhaps it would be easier for all the cards relying on > drm_get_edid to have a faster return path in case of problems. > > I am fine with any solution, if this problem is happening to appear on i915 > cards only, we could do this in our driver. It is that 15 attempts looks a > bit overkill. Yes, I agree, 15 retries makes no sense. And I like your original patch, it makes a lot of sense. > > Your proposed patch is better than I first thought. I had forgotten > > that i2c-algo-bit tries up to 3 times to get a first ack from a slave. > > So if i2c_transfer returns -ENXIO, this means that i2c-algo-bit has > > already attempted 3 times to contact the slave, with no reply, so > > there's probably no point going on. A communication problem with a > > present slave would have returned a different error code. > > > > Without your patch, a missing slave would cause 3 * 5 = 15 retries, > > which is definitely too much. > > > > That being said, even then the whole probe sequence shouldn't exceed > > 10 ms, which I wouldn't expect a user to notice. The user-reported 4 > > second delay when running xrandr can't be caused by this. 4 seconds for > > 15 attempts is 250 ms per attempt, this looks like a timeout due to > > non-functional bus, not a nack. Not that 250 ms is 1 jiffy for HZ=250, > > which I guess was what the reporting user was running. So even with > > your patch, there's still 750 ms to wait, I don't think this is > > acceptable. You really have to fix that I2C bus or skip probing it. > > Yep, true. I've followed the easiest route so far - find out where the > initial problem happens, and attempt at solving it. This change in > drm_get_edid solves the delay at its origin, but we certainly could have > additional delays propagated somewhere else. I couldn't reproduce the > original reporter's huge delay, so I looked at what was within my reach. Your fix is not really "at the origin" of the problem. Fixing it at the origin would be not creating the I2C bus if it won't work (or marking it as unavailable in some way, if the drm framework allows this.) If that is not possible, testing the lines before accessing the bus would be closer to the origin, however it might be argued that it adds delays in the working case, and also somehow violates the I2C specification (the line testing is not part of the specification and could c
[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)
https://bugs.freedesktop.org/show_bug.cgi?id=41766 --- Comment #11 from Pasi Kärkkäinen 2011-10-30 10:57:46 PDT --- I just tried with the latest Fedora 16 Final RC1 (using Linux 3.1.0 final), and I noticed the LVDS flickering actually happens *sometimes* also when booting the laptop with lid open. So it's not actually always related to opening the laptop LID. -- 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 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)
https://bugs.freedesktop.org/show_bug.cgi?id=41766 --- Comment #12 from Pasi Kärkkäinen 2011-10-30 11:01:04 PDT --- Created attachment 52925 --> https://bugs.freedesktop.org/attachment.cgi?id=52925 Linux 3.1.0 dmesg radeon internal lvds flickering dmesg from Fedora 16 Final RC1 using Linux kernel 3.1.0. -- 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 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Alex Deucher 2011-10-30 12:13:22 UTC --- Should be fixed with this patch: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=12d5180bd7e683a4ae80830b82ba67e7b7fac7b2 *** This bug has been marked as a duplicate of bug 40103 *** -- 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
Re: [PATCH] drm/radeon/kms: remove useless radeon_ddc_dump()
On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim wrote:
> Dear Alex,
>
> but we use DDC probing e. g. to identify connectors with improperly
> terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
> we decided some months ago to use this function during module loading to
> inform the user once (and only once!), which connector has a monitor
> connected with valid EDID and which connector has not.
There's nothing in that function that actually prevents the printing
of bad EDIDs. All it does is call drm_get_edid() and report whether
it found an EDID or not. radeon_dvi_detect() already takes into
account the requires_extended_probe flag. The connectors are probed by
the fb code for the console as well so it just adds to the module load
time. If we want to print what connectors are connected, it should be
done from the fb code so we only have to do it once.
>
> Graphic solutions in general have several connectors integrated, and it's
> sometimes really difficult to identify, which one of the does not work as
> expected, based on the logs. From above log we see, that a monitor is
> connected to DVI connector, nothing is connected to the VGA connector, and
> we have a problem with the HDMI connector. Without this fuinction, nothing
> helpful from radeon module would be in the logs.
We should print the connector name in the generic drm error code then
if we want to print this info at boot time.
>
> Maybe we can keep this function, but call it only for connectors, for which
> it works, i. e. not for DP, eDP and DP bridge connectors.
That's just as bad. Users won't understand why only certain
connectors are probed.
>
> Best regards
>
> Thomas Reim
>
> Am Dienstag, den 25.10.2011, 19:24 -0400 schrieb alexdeuc...@gmail.com:
>
> From: Alex Deucher
>
> The function didn't work with DP, eDP, or DP bridge
> connectors and thus confused users as it lead them to
> believe nothing was connected or the EDID was invalid
> when in fact is was, just on the aux bus rather an i2c.
>
> It should also speed up module loading as it avoids a
> bunch of extra DDC probing.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 33
> ---
> 1 files changed, 0 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 6adb3e5..4998736 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -33,8 +33,6 @@
> #include "drm_crtc_helper.h"
> #include "drm_edid.h"
>
> -static int radeon_ddc_dump(struct drm_connector *connector);
> -
> static void avivo_crtc_load_lut(struct drm_crtc *crtc)
> {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> @@ -669,7 +667,6 @@ static void radeon_print_display_setup(struct drm_device
> *dev)
> static bool radeon_setup_enc_conn(struct drm_device *dev)
> {
> struct radeon_device *rdev = dev->dev_private;
> - struct drm_connector *drm_connector;
> bool ret = false;
>
> if (rdev->bios) {
> @@ -689,8 +686,6 @@ static bool radeon_setup_enc_conn(struct drm_device
> *dev)
> if (ret) {
> radeon_setup_encoder_clones(dev);
> radeon_print_display_setup(dev);
> - list_for_each_entry(drm_connector,
> &dev->mode_config.connector_list,
> head)
> - radeon_ddc_dump(drm_connector);
> }
>
> return ret;
> @@ -743,34 +738,6 @@ int radeon_ddc_get_modes(struct radeon_connector
> *radeon_connector)
> return 0;
> }
>
> -static int radeon_ddc_dump(struct drm_connector *connector)
> -{
> - struct edid *edid;
> - struct radeon_connector *radeon_connector =
> to_radeon_connector(connector);
> - int ret = 0;
> -
> - /* on hw with routers, select right port */
> - if (radeon_connector->router.ddc_valid)
> - radeon_router_select_ddc_port(radeon_connector);
> -
> - if (!radeon_connector->ddc_bus)
> - return -1;
> - edid = drm_get_edid(connector, &radeon_connector->ddc_bus->adapter);
> - /* Log EDID retrieval status here. In particular with regard to
> - * connectors with requires_extended_probe flag set, that will prevent
> - * function radeon_dvi_detect() to fetch EDID on this connector,
> - * as long as there is no valid EDID header found */
> - if (edid) {
> - DRM_INFO("Radeon display connector %s: Found valid EDID",
> - drm_get_connector_name(connector));
> - kfree(edid);
> - } else {
> - DRM_INFO("Radeon display connector %s: No monitor connected or
> invalid
> EDID",
> - drm_get_connector_name(connector));
> - }
> - return ret;
> -}
> -
> /* avivo */
> static void avivo_get_fb_div(struct radeon_pll *pll,
>u32 target_clock,
>
>
___
dri-devel mai
[Bug 41592] [Radeon] The display often freezes with gnome-shell 3.2
https://bugs.freedesktop.org/show_bug.cgi?id=41592 --- Comment #10 from pete...@hottemptation.org 2011-10-30 13:58:51 PDT --- Bugzilla Gnome 661898 Posted some days ago. Because it can be just a bug around the radeon driver in kernel I opened a new bug here. https://bugs.freedesktop.org/show_bug.cgi?id=41838 Would be intersting to see if it freezes your system in the same way, if you visit the website I mentioned in my bug. So we can be sure, that is the same issue. -- 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
[PATCH] drm/radeon/kms: always do extended edid probe
From: Alex Deucher
Rather than having a quirk list just always check the EDID header
when probing. This is the recommended behavior according to the
display team. This avoids problems with improperly terminated
i2c lines on some boards. This is also what the proprietary
driver does.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 69 ++-
drivers/gpu/drm/radeon/radeon_i2c.c| 28 ---
drivers/gpu/drm/radeon/radeon_mode.h |6 +--
3 files changed, 18 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 8cec3db..7b70c8a 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -430,55 +430,6 @@ int radeon_connector_set_property(struct drm_connector
*connector, struct drm_pr
return 0;
}
-/*
- * Some integrated ATI Radeon chipset implementations (e. g.
- * Asus M2A-VM HDMI) may indicate the availability of a DDC,
- * even when there's no monitor connected. For these connectors
- * following DDC probe extension will be applied: check also for the
- * availability of EDID with at least a correct EDID header. Only then,
- * DDC is assumed to be available. This prevents drm_get_edid() and
- * drm_edid_block_valid() from periodically dumping data and kernel
- * errors into the logs and onto the terminal.
- */
-static bool radeon_connector_needs_extended_probe(struct radeon_device *dev,
-uint32_t supported_device,
-int connector_type)
-{
- /* Asus M2A-VM HDMI board sends data to i2c bus even,
-* if HDMI add-on card is not plugged in or HDMI is disabled in
-* BIOS. Valid DDC can only be assumed, if also a valid EDID header
-* can be retrieved via i2c bus during DDC probe */
- if ((dev->pdev->device == 0x791e) &&
- (dev->pdev->subsystem_vendor == 0x1043) &&
- (dev->pdev->subsystem_device == 0x826d)) {
- if ((connector_type == DRM_MODE_CONNECTOR_HDMIA) &&
- (supported_device == ATOM_DEVICE_DFP2_SUPPORT))
- return true;
- }
- /* ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
-* for a DVI connector that is not implemented */
- if ((dev->pdev->device == 0x796e) &&
- (dev->pdev->subsystem_vendor == 0x1019) &&
- (dev->pdev->subsystem_device == 0x2615)) {
- if ((connector_type == DRM_MODE_CONNECTOR_DVID) &&
- (supported_device == ATOM_DEVICE_DFP2_SUPPORT))
- return true;
- }
- /* TOSHIBA Satellite L300D with ATI Mobility Radeon x1100
-* (RS690M) sends data to i2c bus for a HDMI connector that
-* is not implemented */
- if ((dev->pdev->device == 0x791f) &&
- (dev->pdev->subsystem_vendor == 0x1179) &&
- (dev->pdev->subsystem_device == 0xff68)) {
- if ((connector_type == DRM_MODE_CONNECTOR_HDMIA) &&
- (supported_device == ATOM_DEVICE_DFP2_SUPPORT))
- return true;
- }
-
- /* Default: no EDID header probe required for DDC probing */
- return false;
-}
-
static void radeon_fixup_lvds_native_mode(struct drm_encoder *encoder,
struct drm_connector *connector)
{
@@ -719,8 +670,7 @@ radeon_vga_detect(struct drm_connector *connector, bool
force)
ret = connector_status_disconnected;
if (radeon_connector->ddc_bus)
- dret = radeon_ddc_probe(radeon_connector,
-
radeon_connector->requires_extended_probe);
+ dret = radeon_ddc_probe(radeon_connector);
if (dret) {
radeon_connector->detected_by_load = false;
if (radeon_connector->edid) {
@@ -902,8 +852,7 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
bool dret = false;
if (radeon_connector->ddc_bus)
- dret = radeon_ddc_probe(radeon_connector,
-
radeon_connector->requires_extended_probe);
+ dret = radeon_ddc_probe(radeon_connector);
if (dret) {
radeon_connector->detected_by_load = false;
if (radeon_connector->edid) {
@@ -1326,8 +1275,7 @@ radeon_dp_detect(struct drm_connector *connector, bool
force)
if (encoder) {
/* setup ddc on the bridge */
radeon_atom_ext_encoder_setup_ddc(encoder);
- if (radeon_ddc_probe(radeon_connector,
-
radeon_connector->requires_extended_probe)) /* try DDC */
+ if (radeon_ddc_probe(radeon_connector)) /* try DDC */
ret = connector_s
[PATCH 2/4] drm/radeon/kms: make atombios_dvo_setup() version based
From: Alex Deucher
Use table version numbers for param setup.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 63 +--
1 files changed, 40 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 36274fa..7d91d3c 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -239,32 +239,49 @@ atombios_dvo_setup(struct drm_encoder *encoder, int
action)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
union dvo_encoder_control args;
int index = GetIndexIntoMasterTable(COMMAND, DVOEncoderControl);
+ uint8_t frev, crev;
memset(&args, 0, sizeof(args));
- if (ASIC_IS_DCE3(rdev)) {
- /* DCE3+ */
- args.dvo_v3.ucAction = action;
- args.dvo_v3.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
- args.dvo_v3.ucDVOConfig = 0; /* XXX */
- } else if (ASIC_IS_DCE2(rdev)) {
- /* DCE2 (pre-DCE3 R6xx, RS600/690/740 */
- args.dvo.sDVOEncoder.ucAction = action;
- args.dvo.sDVOEncoder.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
- /* DFP1, CRT1, TV1 depending on the type of port */
- args.dvo.sDVOEncoder.ucDeviceType = ATOM_DEVICE_DFP1_INDEX;
-
- if (radeon_encoder->pixel_clock > 165000)
- args.dvo.sDVOEncoder.usDevAttr.sDigAttrib.ucAttribute
|= PANEL_ENCODER_MISC_DUAL;
- } else {
- /* R4xx, R5xx */
- args.ext_tmds.sXTmdsEncoder.ucEnable = action;
+ if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, &frev,
&crev))
+ return;
- if (radeon_encoder->pixel_clock > 165000)
- args.ext_tmds.sXTmdsEncoder.ucMisc |=
PANEL_ENCODER_MISC_DUAL;
+ switch (frev) {
+ case 1:
+ switch (crev) {
+ case 1:
+ /* R4xx, R5xx */
+ args.ext_tmds.sXTmdsEncoder.ucEnable = action;
+
+ if (radeon_encoder->pixel_clock > 165000)
+ args.ext_tmds.sXTmdsEncoder.ucMisc |=
PANEL_ENCODER_MISC_DUAL;
+
+ args.ext_tmds.sXTmdsEncoder.ucMisc |=
ATOM_PANEL_MISC_888RGB;
+ break;
+ case 2:
+ /* RS600/690/740 */
+ args.dvo.sDVOEncoder.ucAction = action;
+ args.dvo.sDVOEncoder.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
+ /* DFP1, CRT1, TV1 depending on the type of port */
+ args.dvo.sDVOEncoder.ucDeviceType =
ATOM_DEVICE_DFP1_INDEX;
- /*if (pScrn->rgbBits == 8)*/
- args.ext_tmds.sXTmdsEncoder.ucMisc |= ATOM_PANEL_MISC_888RGB;
+ if (radeon_encoder->pixel_clock > 165000)
+
args.dvo.sDVOEncoder.usDevAttr.sDigAttrib.ucAttribute |=
PANEL_ENCODER_MISC_DUAL;
+ break;
+ case 3:
+ /* R6xx */
+ args.dvo_v3.ucAction = action;
+ args.dvo_v3.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
+ args.dvo_v3.ucDVOConfig = 0; /* XXX */
+ break;
+ default:
+ DRM_ERROR("Unknown table version %d, %d\n", frev, crev);
+ break;
+ }
+ break;
+ default:
+ DRM_ERROR("Unknown table version %d, %d\n", frev, crev);
+ break;
}
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t
*)&args);
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/radeon/kms: make atombios_dig_encoder_setup() version based
From: Alex Deucher
set up the params based on the table version number.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 213 +---
1 files changed, 128 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 7d91d3c..e0285c4 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -585,97 +585,140 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder,
int action, int panel_mo
if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, &frev,
&crev))
return;
- args.v1.ucAction = action;
- args.v1.usPixelClock = cpu_to_le16(radeon_encoder->pixel_clock / 10);
- if (action == ATOM_ENCODER_CMD_SETUP_PANEL_MODE)
- args.v3.ucPanelMode = panel_mode;
- else
- args.v1.ucEncoderMode = atombios_get_encoder_mode(encoder);
+ switch (frev) {
+ case 1:
+ switch (crev) {
+ case 1:
+ args.v1.ucAction = action;
+ args.v1.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
+ if (action == ATOM_ENCODER_CMD_SETUP_PANEL_MODE)
+ args.v3.ucPanelMode = panel_mode;
+ else
+ args.v1.ucEncoderMode =
atombios_get_encoder_mode(encoder);
- if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode))
- args.v1.ucLaneNum = dp_lane_count;
- else if (radeon_encoder->pixel_clock > 165000)
- args.v1.ucLaneNum = 8;
- else
- args.v1.ucLaneNum = 4;
-
- if (ASIC_IS_DCE5(rdev)) {
- if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode)) {
- if (dp_clock == 27)
- args.v1.ucConfig |=
ATOM_ENCODER_CONFIG_V4_DPLINKRATE_2_70GHZ;
- else if (dp_clock == 54)
- args.v1.ucConfig |=
ATOM_ENCODER_CONFIG_V4_DPLINKRATE_5_40GHZ;
- }
- args.v4.acConfig.ucDigSel = dig->dig_encoder;
- switch (bpc) {
- case 0:
- args.v4.ucBitPerColor = PANEL_BPC_UNDEFINE;
- break;
- case 6:
- args.v4.ucBitPerColor = PANEL_6BIT_PER_COLOR;
- break;
- case 8:
- default:
- args.v4.ucBitPerColor = PANEL_8BIT_PER_COLOR;
- break;
- case 10:
- args.v4.ucBitPerColor = PANEL_10BIT_PER_COLOR;
- break;
- case 12:
- args.v4.ucBitPerColor = PANEL_12BIT_PER_COLOR;
- break;
- case 16:
- args.v4.ucBitPerColor = PANEL_16BIT_PER_COLOR;
+ if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode))
+ args.v1.ucLaneNum = dp_lane_count;
+ else if (radeon_encoder->pixel_clock > 165000)
+ args.v1.ucLaneNum = 8;
+ else
+ args.v1.ucLaneNum = 4;
+
+ if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode) &&
(dp_clock == 27))
+ args.v1.ucConfig |=
ATOM_ENCODER_CONFIG_DPLINKRATE_2_70GHZ;
+ switch (radeon_encoder->encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ args.v1.ucConfig =
ATOM_ENCODER_CONFIG_V2_TRANSMITTER1;
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+ args.v1.ucConfig =
ATOM_ENCODER_CONFIG_V2_TRANSMITTER2;
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+ args.v1.ucConfig =
ATOM_ENCODER_CONFIG_V2_TRANSMITTER3;
+ break;
+ }
+ if (dig->linkb)
+ args.v1.ucConfig |= ATOM_ENCODER_CONFIG_LINKB;
+ else
+ args.v1.ucConfig |= ATOM_ENCODER_CONFIG_LINKA;
break;
- }
- if (hpd_id == RADEON_HPD_NONE)
- args.v4.ucHPD_ID = 0;
- else
- args.v4.ucHPD_ID = hpd_id + 1;
- } else if (ASIC_IS_DCE4(rdev)) {
- if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode) && (dp_clock ==
27))
- args.v1.ucConfig |=
ATOM_ENCODER_CONFIG_V3_DPLINKRATE_2_70GHZ;
- args.v3.acConfig.ucDigSel = dig->dig
[PATCH 4/4] drm/radeon/kms: make atombios_dig_transmitter_setup() version based
From: Alex Deucher
Use the table version to determine which params to use.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 343 ++--
1 files changed, 221 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index e0285c4..39c04c1 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -772,6 +772,11 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
igp_lane_info = dig_connector->igp_lane_info;
}
+ if (encoder->crtc) {
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
+ pll_id = radeon_crtc->pll_id;
+ }
+
/* no dig encoder assigned */
if (dig_encoder == -1)
return;
@@ -798,146 +803,240 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, &frev,
&crev))
return;
- args.v1.ucAction = action;
- if (action == ATOM_TRANSMITTER_ACTION_INIT) {
- args.v1.usInitInfo = cpu_to_le16(connector_object_id);
- } else if (action == ATOM_TRANSMITTER_ACTION_SETUP_VSEMPH) {
- args.v1.asMode.ucLaneSel = lane_num;
- args.v1.asMode.ucLaneSet = lane_set;
- } else {
- if (is_dp)
- args.v1.usPixelClock =
- cpu_to_le16(dp_clock / 10);
- else if (radeon_encoder->pixel_clock > 165000)
- args.v1.usPixelClock =
cpu_to_le16((radeon_encoder->pixel_clock / 2) / 10);
- else
- args.v1.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
- }
- if (ASIC_IS_DCE4(rdev)) {
- if (is_dp)
- args.v3.ucLaneNum = dp_lane_count;
- else if (radeon_encoder->pixel_clock > 165000)
- args.v3.ucLaneNum = 8;
- else
- args.v3.ucLaneNum = 4;
+ switch (frev) {
+ case 1:
+ switch (crev) {
+ case 1:
+ args.v1.ucAction = action;
+ if (action == ATOM_TRANSMITTER_ACTION_INIT) {
+ args.v1.usInitInfo =
cpu_to_le16(connector_object_id);
+ } else if (action ==
ATOM_TRANSMITTER_ACTION_SETUP_VSEMPH) {
+ args.v1.asMode.ucLaneSel = lane_num;
+ args.v1.asMode.ucLaneSet = lane_set;
+ } else {
+ if (is_dp)
+ args.v1.usPixelClock =
+ cpu_to_le16(dp_clock / 10);
+ else if (radeon_encoder->pixel_clock > 165000)
+ args.v1.usPixelClock =
cpu_to_le16((radeon_encoder->pixel_clock / 2) / 10);
+ else
+ args.v1.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
+ }
- if (dig->linkb)
- args.v3.acConfig.ucLinkSel = 1;
- if (dig_encoder & 1)
- args.v3.acConfig.ucEncoderSel = 1;
+ args.v1.ucConfig = ATOM_TRANSMITTER_CONFIG_CLKSRC_PPLL;
- /* Select the PLL for the PHY
-* DP PHY should be clocked from external src if there is
-* one.
-*/
- if (encoder->crtc) {
- struct radeon_crtc *radeon_crtc =
to_radeon_crtc(encoder->crtc);
- pll_id = radeon_crtc->pll_id;
- }
+ if (dig_encoder)
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG2_ENCODER;
+ else
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
+
+ if ((rdev->flags & RADEON_IS_IGP) &&
+ (radeon_encoder->encoder_id ==
ENCODER_OBJECT_ID_INTERNAL_UNIPHY)) {
+ if (is_dp || (radeon_encoder->pixel_clock <=
165000)) {
+ if (igp_lane_info & 0x1)
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_LANE_0_3;
+ else if (igp_lane_info & 0x2)
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_LANE_4_7;
+ else if (igp_lane_info & 0x4)
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_LANE_8_11;
+
[PATCH] drm: serialize access to debugs_nodes.list
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_debugfs.c |5 +
include/drm/drmP.h|1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 9d2668a..1144fbe 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -120,7 +120,9 @@ int drm_debugfs_create_files(struct drm_info_list *files,
int count,
tmp->minor = minor;
tmp->dent = ent;
tmp->info_ent = &files[i];
+ mutex_lock(&minor->debugfs_nodes.mutex);
list_add(&(tmp->list), &(minor->debugfs_nodes.list));
+ mutex_unlock(&minor->debugfs_nodes.mutex);
}
return 0;
@@ -149,6 +151,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
int ret;
INIT_LIST_HEAD(&minor->debugfs_nodes.list);
+ mutex_init(&minor->debugfs_nodes.mutex);
sprintf(name, "%d", minor_id);
minor->debugfs_root = debugfs_create_dir(name, root);
if (!minor->debugfs_root) {
@@ -194,6 +197,7 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
struct drm_info_node *tmp;
int i;
+ mutex_lock(&minor->debugfs_nodes.mutex);
for (i = 0; i < count; i++) {
list_for_each_safe(pos, q, &minor->debugfs_nodes.list) {
tmp = list_entry(pos, struct drm_info_node, list);
@@ -204,6 +208,7 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
}
}
}
+ mutex_unlock(&minor->debugfs_nodes.mutex);
return 0;
}
EXPORT_SYMBOL(drm_debugfs_remove_files);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9b7c2bb..c70c943 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -970,6 +970,7 @@ struct drm_info_list {
* debugfs node structure. This structure represents a debugfs file.
*/
struct drm_info_node {
+ struct mutex mutex;
struct list_head list;
struct drm_minor *minor;
struct drm_info_list *info_ent;
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42409] New: Mesa 7.12-devel /dri/r600 compilation error: no makefile found
https://bugs.freedesktop.org/show_bug.cgi?id=42409 Bug #: 42409 Summary: Mesa 7.12-devel /dri/r600 compilation error: no makefile found Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: wol...@onsneteindhoven.nl git mesa 7.72-devel compilation error: drivers/dri/r600 no targets specified and no makefile found --- make[5]: Entering directory `/home/jos/src/xorg/git-master/mesa/src/mesa/drivers/dri/r600' make[5]: *** No targets specified and no makefile found. Stop. make[5]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/mesa/drivers/dri/r600' make[4]: *** [subdirs] Error 1 make[4]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/mesa/drivers/dri' make[3]: *** [default] Error 1 make[3]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/mesa/drivers' make[2]: *** [driver_subdirs] Error 2 make[2]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/mesa' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src' make: *** [default] Error 1 --- -- 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 42409] Mesa 7.12-devel /dri/r600 compilation error: no makefile found
https://bugs.freedesktop.org/show_bug.cgi?id=42409 --- Comment #1 from Jos van Wolput 2011-10-30 22:27:17 PDT --- I understand the dri r600 driver has been removed, isn't it? So this issue is not a bug and can be closed. -- 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 41592] [Radeon] The display often freezes with gnome-shell 3.2
https://bugs.freedesktop.org/show_bug.cgi?id=41592 --- Comment #8 from mirandir at orange.fr 2011-10-30 04:35:13 PDT --- Sorry for the delay, I haven't had time to work on this sooner. The "freeze" seems to begin to (ramdomly) happen after that gnome-screensaver switches off the screen. As Archlinux don't provides debug packages, I must recompile some packages, and I have an error when I try to recompile X, I'm trying to solve that. But the gnome packager provides some debug packages for gnome, so I can have a backtrace when the problem occur. I don't know if it's usefull, maybe I should open a bugreport on the gnome-shell bugzilla too ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41592] [Radeon] The display often freezes with gnome-shell 3.2
https://bugs.freedesktop.org/show_bug.cgi?id=41592 --- Comment #9 from mirandir at orange.fr 2011-10-30 04:35:59 PDT --- Created attachment 52909 --> https://bugs.freedesktop.org/attachment.cgi?id=52909 gdb 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 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #7 from Chris Wilson 2011-10-30 05:44:20 PDT --- I've just tried to reproduce this running firefox+chromium+others under e17 using SNA. I'm pretty certain this was the tiling bugs we fixed early. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #8 from Bruno 2011-10-30 05:55:23 PDT --- (In reply to comment #7) > I've just tried to reproduce this running firefox+chromium+others under e17 > using SNA. I'm pretty certain this was the tiling bugs we fixed early. I've not seen them recently either, except for sporadically a pixel line with with white/gray pixels in the e17 cursor. (always at same place of the cursor, more or less middle in height). Might be there is one tiling bug remaining around cursor handling. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
> --- Comment #8 from Bruno 2011-10-30 05:55:23 PDT > --- > I've not seen them recently either, except for sporadically a pixel line with > with white/gray pixels in the e17 cursor. (always at same place of the cursor, > more or less middle in height). > Might be there is one tiling bug remaining around cursor handling. Cursors on gen2 are stored in physical mem. On a quick lock we're indeed missing the clflush that should be there. Let me whip up a patch. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #9 from Daniel Vetter 2011-10-30 06:44:19 PDT --- > --- Comment #8 from Bruno 2011-10-30 05:55:23 PDT > --- > I've not seen them recently either, except for sporadically a pixel line with > with white/gray pixels in the e17 cursor. (always at same place of the cursor, > more or less middle in height). > Might be there is one tiling bug remaining around cursor handling. Cursors on gen2 are stored in physical mem. On a quick lock we're indeed missing the clflush that should be there. Let me whip up a patch. -Daniel -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #10 from Daniel Vetter 2011-10-30 06:46:37 PDT --- Created attachment 52913 --> https://bugs.freedesktop.org/attachment.cgi?id=52913 clflush phys objects to fix cursor corruptions Test-feedback highly appreciated. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
https://bugs.freedesktop.org/show_bug.cgi?id=35460 Daniel Vetter changed: What|Removed |Added Attachment #52913|0 |1 is obsolete|| --- Comment #11 from Daniel Vetter 2011-10-30 08:42:04 PDT --- Created attachment 52920 --> https://bugs.freedesktop.org/attachment.cgi?id=52920 clflush phys objects to fix cursor corruptions Chris Wilson pointed out that I'm missing memory barriers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Intel-gfx] [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there
Hi Eugeni, On Mon, 24 Oct 2011 12:40:14 -0200, Eugeni Dodonov wrote: > On Thu, Oct 20, 2011 at 10:33, Jean Delvare wrote: > > > Just to clarify: by "connectivity is setup", do you mean code in the > > driver setting the GPIO pin direction etc., or a display being > > connected to the graphics card? > > > > I admit I am a little surprised. I2C buses should have their lines up > > by default, thanks to pull-up resistors, and masters and slaves should > > merely drive the lines low as needed. The absence of slaves should have > > no impact on the line behavior. If the Intel graphics chips (or the > > driver) rely on the display to hold the lines high, I'd say this is a > > seriously broken design. > > > > As a side note, I thought that HDMI had the capability of presence > > detection, so there may be a better way to know if a display is > > connected or not, and this information could used to dynamically > > instantiate and delete the I2C buses? That way we could skip probing > > for EDID when there is no chance of success. > > Yes, I think so too. > > I admit I haven't got to the root of the problem here. My test was really > simple, borrowed from the test_bus() at i2c-algo-bit.c - without HDMI cable > plugged in, I was getting the "SDA stuck high" messages; with the cable > plugged in, I wasn't getting any of those. Just the HDMI cable, or with a screen at the other end? Either way, this smells like bad hardware design. The graphics card itself should pull the I2C bus lines up by default, it shouldn't rely on a cable (I'm not familiar with HDMI but I'm not sure if that makes sense at all) or external display (more likely) to do it. But I can also imagine that this could be a driver issue, maybe the GPIO lines aren't setup properly by the driver? I'm not familiar enough with the Intel graphics hardware and driver to tell, you'll know better. > But in any case, I haven't investigated it deeper in the hardware direction > after figuring out that drm_get_edid would retry its attempts for retreiving > the edid for 15 times, getting the -ENXIO error for all of them. > > > > Well, you could always do manual line testing of the I2C bus _before_ > > calling drm_do_probe_ddc_edid()? And skip the call if the test fails > > (i.e. the bus isn't ready for use.) As said before, I am willing to > > export bit_test if it helps any. I've attached a patch doing exactly > > this. Let me know if you want me to commit it. > > Yes, surely, I can do this. I did a similar test in the i915-specific patch, > checking if we can talk to i2c adapter pior to call drm_do_probe_ddc_edid, > but I thought that perhaps it would be easier for all the cards relying on > drm_get_edid to have a faster return path in case of problems. > > I am fine with any solution, if this problem is happening to appear on i915 > cards only, we could do this in our driver. It is that 15 attempts looks a > bit overkill. Yes, I agree, 15 retries makes no sense. And I like your original patch, it makes a lot of sense. > > Your proposed patch is better than I first thought. I had forgotten > > that i2c-algo-bit tries up to 3 times to get a first ack from a slave. > > So if i2c_transfer returns -ENXIO, this means that i2c-algo-bit has > > already attempted 3 times to contact the slave, with no reply, so > > there's probably no point going on. A communication problem with a > > present slave would have returned a different error code. > > > > Without your patch, a missing slave would cause 3 * 5 = 15 retries, > > which is definitely too much. > > > > That being said, even then the whole probe sequence shouldn't exceed > > 10 ms, which I wouldn't expect a user to notice. The user-reported 4 > > second delay when running xrandr can't be caused by this. 4 seconds for > > 15 attempts is 250 ms per attempt, this looks like a timeout due to > > non-functional bus, not a nack. Not that 250 ms is 1 jiffy for HZ=250, > > which I guess was what the reporting user was running. So even with > > your patch, there's still 750 ms to wait, I don't think this is > > acceptable. You really have to fix that I2C bus or skip probing it. > > Yep, true. I've followed the easiest route so far - find out where the > initial problem happens, and attempt at solving it. This change in > drm_get_edid solves the delay at its origin, but we certainly could have > additional delays propagated somewhere else. I couldn't reproduce the > original reporter's huge delay, so I looked at what was within my reach. Your fix is not really "at the origin" of the problem. Fixing it at the origin would be not creating the I2C bus if it won't work (or marking it as unavailable in some way, if the drm framework allows this.) If that is not possible, testing the lines before accessing the bus would be closer to the origin, however it might be argued that it adds delays in the working case, and also somehow violates the I2C specification (the line testing is not part of the specification and could c
[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)
https://bugs.freedesktop.org/show_bug.cgi?id=41766 --- Comment #11 from Pasi K?rkk?inen 2011-10-30 10:57:46 PDT --- I just tried with the latest Fedora 16 Final RC1 (using Linux 3.1.0 final), and I noticed the LVDS flickering actually happens *sometimes* also when booting the laptop with lid open. So it's not actually always related to opening the laptop LID. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)
https://bugs.freedesktop.org/show_bug.cgi?id=41766 --- Comment #12 from Pasi K?rkk?inen 2011-10-30 11:01:04 PDT --- Created attachment 52925 --> https://bugs.freedesktop.org/attachment.cgi?id=52925 Linux 3.1.0 dmesg radeon internal lvds flickering dmesg from Fedora 16 Final RC1 using Linux kernel 3.1.0. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Alex Deucher 2011-10-30 12:13:22 UTC --- Should be fixed with this patch: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=12d5180bd7e683a4ae80830b82ba67e7b7fac7b2 *** This bug has been marked as a duplicate of bug 40103 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms: remove useless radeon_ddc_dump()
On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim wrote:
> Dear Alex,
>
> but we use DDC probing e. g. to identify connectors with improperly
> terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
> we decided some months ago to use this function during module loading to
> inform the user once (and only once!), which connector has a monitor
> connected with valid EDID and which connector has not.
There's nothing in that function that actually prevents the printing
of bad EDIDs. All it does is call drm_get_edid() and report whether
it found an EDID or not. radeon_dvi_detect() already takes into
account the requires_extended_probe flag. The connectors are probed by
the fb code for the console as well so it just adds to the module load
time. If we want to print what connectors are connected, it should be
done from the fb code so we only have to do it once.
>
> Graphic solutions in general have several connectors integrated, and it's
> sometimes really difficult to identify, which one of the does not work as
> expected, based on the logs. From above log we see, that a monitor is
> connected to DVI connector, nothing is connected to the VGA connector, and
> we have a problem with the HDMI connector. Without this fuinction, nothing
> helpful from radeon module would be in the logs.
We should print the connector name in the generic drm error code then
if we want to print this info at boot time.
>
> Maybe we can keep this function, but call it only for connectors, for which
> it works, i. e. not for DP, eDP and DP bridge connectors.
That's just as bad. Users won't understand why only certain
connectors are probed.
>
> Best regards
>
> Thomas Reim
>
> Am Dienstag, den 25.10.2011, 19:24 -0400 schrieb alexdeucher at gmail.com:
>
> From: Alex Deucher
>
> The function didn't work with DP, eDP, or DP bridge
> connectors and thus confused users as it lead them to
> believe nothing was connected or the EDID was invalid
> when in fact is was, just on the aux bus rather an i2c.
>
> It should also speed up module loading as it avoids a
> bunch of extra DDC probing.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 33
> ---
> 1 files changed, 0 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 6adb3e5..4998736 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -33,8 +33,6 @@
> #include "drm_crtc_helper.h"
> #include "drm_edid.h"
>
> -static int radeon_ddc_dump(struct drm_connector *connector);
> -
> static void avivo_crtc_load_lut(struct drm_crtc *crtc)
> {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> @@ -669,7 +667,6 @@ static void radeon_print_display_setup(struct drm_device
> *dev)
> static bool radeon_setup_enc_conn(struct drm_device *dev)
> {
> struct radeon_device *rdev = dev->dev_private;
> - struct drm_connector *drm_connector;
> bool ret = false;
>
> if (rdev->bios) {
> @@ -689,8 +686,6 @@ static bool radeon_setup_enc_conn(struct drm_device
> *dev)
> if (ret) {
> radeon_setup_encoder_clones(dev);
> radeon_print_display_setup(dev);
> - list_for_each_entry(drm_connector,
> &dev->mode_config.connector_list,
> head)
> - radeon_ddc_dump(drm_connector);
> }
>
> return ret;
> @@ -743,34 +738,6 @@ int radeon_ddc_get_modes(struct radeon_connector
> *radeon_connector)
> return 0;
> }
>
> -static int radeon_ddc_dump(struct drm_connector *connector)
> -{
> - struct edid *edid;
> - struct radeon_connector *radeon_connector =
> to_radeon_connector(connector);
> - int ret = 0;
> -
> - /* on hw with routers, select right port */
> - if (radeon_connector->router.ddc_valid)
> - radeon_router_select_ddc_port(radeon_connector);
> -
> - if (!radeon_connector->ddc_bus)
> - return -1;
> - edid = drm_get_edid(connector, &radeon_connector->ddc_bus->adapter);
> - /* Log EDID retrieval status here. In particular with regard to
> - * connectors with requires_extended_probe flag set, that will prevent
> - * function radeon_dvi_detect() to fetch EDID on this connector,
> - * as long as there is no valid EDID header found */
> - if (edid) {
> - DRM_INFO("Radeon display connector %s: Found valid EDID",
> - drm_get_connector_name(connector));
> - kfree(edid);
> - } else {
> - DRM_INFO("Radeon display connector %s: No monitor connected or
> invalid
> EDID",
> - drm_get_connector_name(connector));
> - }
> - return ret;
> -}
> -
> /* avivo */
> static void avivo_get_fb_div(struct radeon_pll *pll,
>u32 target_clock,
>
>
[Bug 41592] [Radeon] The display often freezes with gnome-shell 3.2
https://bugs.freedesktop.org/show_bug.cgi?id=41592 --- Comment #10 from peterle at hottemptation.org 2011-10-30 13:58:51 PDT --- Bugzilla Gnome 661898 Posted some days ago. Because it can be just a bug around the radeon driver in kernel I opened a new bug here. https://bugs.freedesktop.org/show_bug.cgi?id=41838 Would be intersting to see if it freezes your system in the same way, if you visit the website I mentioned in my bug. So we can be sure, that is the same issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms: always do extended edid probe
From: Alex Deucher
Rather than having a quirk list just always check the EDID header
when probing. This is the recommended behavior according to the
display team. This avoids problems with improperly terminated
i2c lines on some boards. This is also what the proprietary
driver does.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 69 ++-
drivers/gpu/drm/radeon/radeon_i2c.c| 28 ---
drivers/gpu/drm/radeon/radeon_mode.h |6 +--
3 files changed, 18 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 8cec3db..7b70c8a 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -430,55 +430,6 @@ int radeon_connector_set_property(struct drm_connector
*connector, struct drm_pr
return 0;
}
-/*
- * Some integrated ATI Radeon chipset implementations (e. g.
- * Asus M2A-VM HDMI) may indicate the availability of a DDC,
- * even when there's no monitor connected. For these connectors
- * following DDC probe extension will be applied: check also for the
- * availability of EDID with at least a correct EDID header. Only then,
- * DDC is assumed to be available. This prevents drm_get_edid() and
- * drm_edid_block_valid() from periodically dumping data and kernel
- * errors into the logs and onto the terminal.
- */
-static bool radeon_connector_needs_extended_probe(struct radeon_device *dev,
-uint32_t supported_device,
-int connector_type)
-{
- /* Asus M2A-VM HDMI board sends data to i2c bus even,
-* if HDMI add-on card is not plugged in or HDMI is disabled in
-* BIOS. Valid DDC can only be assumed, if also a valid EDID header
-* can be retrieved via i2c bus during DDC probe */
- if ((dev->pdev->device == 0x791e) &&
- (dev->pdev->subsystem_vendor == 0x1043) &&
- (dev->pdev->subsystem_device == 0x826d)) {
- if ((connector_type == DRM_MODE_CONNECTOR_HDMIA) &&
- (supported_device == ATOM_DEVICE_DFP2_SUPPORT))
- return true;
- }
- /* ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
-* for a DVI connector that is not implemented */
- if ((dev->pdev->device == 0x796e) &&
- (dev->pdev->subsystem_vendor == 0x1019) &&
- (dev->pdev->subsystem_device == 0x2615)) {
- if ((connector_type == DRM_MODE_CONNECTOR_DVID) &&
- (supported_device == ATOM_DEVICE_DFP2_SUPPORT))
- return true;
- }
- /* TOSHIBA Satellite L300D with ATI Mobility Radeon x1100
-* (RS690M) sends data to i2c bus for a HDMI connector that
-* is not implemented */
- if ((dev->pdev->device == 0x791f) &&
- (dev->pdev->subsystem_vendor == 0x1179) &&
- (dev->pdev->subsystem_device == 0xff68)) {
- if ((connector_type == DRM_MODE_CONNECTOR_HDMIA) &&
- (supported_device == ATOM_DEVICE_DFP2_SUPPORT))
- return true;
- }
-
- /* Default: no EDID header probe required for DDC probing */
- return false;
-}
-
static void radeon_fixup_lvds_native_mode(struct drm_encoder *encoder,
struct drm_connector *connector)
{
@@ -719,8 +670,7 @@ radeon_vga_detect(struct drm_connector *connector, bool
force)
ret = connector_status_disconnected;
if (radeon_connector->ddc_bus)
- dret = radeon_ddc_probe(radeon_connector,
-
radeon_connector->requires_extended_probe);
+ dret = radeon_ddc_probe(radeon_connector);
if (dret) {
radeon_connector->detected_by_load = false;
if (radeon_connector->edid) {
@@ -902,8 +852,7 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
bool dret = false;
if (radeon_connector->ddc_bus)
- dret = radeon_ddc_probe(radeon_connector,
-
radeon_connector->requires_extended_probe);
+ dret = radeon_ddc_probe(radeon_connector);
if (dret) {
radeon_connector->detected_by_load = false;
if (radeon_connector->edid) {
@@ -1326,8 +1275,7 @@ radeon_dp_detect(struct drm_connector *connector, bool
force)
if (encoder) {
/* setup ddc on the bridge */
radeon_atom_ext_encoder_setup_ddc(encoder);
- if (radeon_ddc_probe(radeon_connector,
-
radeon_connector->requires_extended_probe)) /* try DDC */
+ if (radeon_ddc_probe(radeon_connector)) /* try DDC */
ret = connector_stat
[PATCH 2/4] drm/radeon/kms: make atombios_dvo_setup() version based
From: Alex Deucher
Use table version numbers for param setup.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 63 +--
1 files changed, 40 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 36274fa..7d91d3c 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -239,32 +239,49 @@ atombios_dvo_setup(struct drm_encoder *encoder, int
action)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
union dvo_encoder_control args;
int index = GetIndexIntoMasterTable(COMMAND, DVOEncoderControl);
+ uint8_t frev, crev;
memset(&args, 0, sizeof(args));
- if (ASIC_IS_DCE3(rdev)) {
- /* DCE3+ */
- args.dvo_v3.ucAction = action;
- args.dvo_v3.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
- args.dvo_v3.ucDVOConfig = 0; /* XXX */
- } else if (ASIC_IS_DCE2(rdev)) {
- /* DCE2 (pre-DCE3 R6xx, RS600/690/740 */
- args.dvo.sDVOEncoder.ucAction = action;
- args.dvo.sDVOEncoder.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
- /* DFP1, CRT1, TV1 depending on the type of port */
- args.dvo.sDVOEncoder.ucDeviceType = ATOM_DEVICE_DFP1_INDEX;
-
- if (radeon_encoder->pixel_clock > 165000)
- args.dvo.sDVOEncoder.usDevAttr.sDigAttrib.ucAttribute
|= PANEL_ENCODER_MISC_DUAL;
- } else {
- /* R4xx, R5xx */
- args.ext_tmds.sXTmdsEncoder.ucEnable = action;
+ if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, &frev,
&crev))
+ return;
- if (radeon_encoder->pixel_clock > 165000)
- args.ext_tmds.sXTmdsEncoder.ucMisc |=
PANEL_ENCODER_MISC_DUAL;
+ switch (frev) {
+ case 1:
+ switch (crev) {
+ case 1:
+ /* R4xx, R5xx */
+ args.ext_tmds.sXTmdsEncoder.ucEnable = action;
+
+ if (radeon_encoder->pixel_clock > 165000)
+ args.ext_tmds.sXTmdsEncoder.ucMisc |=
PANEL_ENCODER_MISC_DUAL;
+
+ args.ext_tmds.sXTmdsEncoder.ucMisc |=
ATOM_PANEL_MISC_888RGB;
+ break;
+ case 2:
+ /* RS600/690/740 */
+ args.dvo.sDVOEncoder.ucAction = action;
+ args.dvo.sDVOEncoder.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
+ /* DFP1, CRT1, TV1 depending on the type of port */
+ args.dvo.sDVOEncoder.ucDeviceType =
ATOM_DEVICE_DFP1_INDEX;
- /*if (pScrn->rgbBits == 8)*/
- args.ext_tmds.sXTmdsEncoder.ucMisc |= ATOM_PANEL_MISC_888RGB;
+ if (radeon_encoder->pixel_clock > 165000)
+
args.dvo.sDVOEncoder.usDevAttr.sDigAttrib.ucAttribute |=
PANEL_ENCODER_MISC_DUAL;
+ break;
+ case 3:
+ /* R6xx */
+ args.dvo_v3.ucAction = action;
+ args.dvo_v3.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
+ args.dvo_v3.ucDVOConfig = 0; /* XXX */
+ break;
+ default:
+ DRM_ERROR("Unknown table version %d, %d\n", frev, crev);
+ break;
+ }
+ break;
+ default:
+ DRM_ERROR("Unknown table version %d, %d\n", frev, crev);
+ break;
}
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t
*)&args);
--
1.7.1.1
[PATCH 1/4] drm/radeon/kms: move atom encoder setup to a new file
From: Alex Deucher
Leave the common code in radeon_encoders.c and move the atom
specific code to atombios_encoders.c. This matches legacy
encoder setup and crtc setup.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/Makefile|2 +-
drivers/gpu/drm/radeon/atombios_encoders.c | 2210
drivers/gpu/drm/radeon/radeon_encoders.c | 2182 +---
drivers/gpu/drm/radeon/radeon_mode.h |2 +-
4 files changed, 2214 insertions(+), 2182 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/atombios_encoders.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 9f363e0..cf8b4bc 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -70,7 +70,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit.o r600_blit_shaders.o \
r600_blit_kms.o radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o
evergreen_blit_kms.o \
- radeon_trace_points.o ni.o cayman_blit_shaders.o
+ radeon_trace_points.o ni.o cayman_blit_shaders.o atombios_encoders.o
radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
new file mode 100644
index 000..36274fa
--- /dev/null
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -0,0 +1,2210 @@
+/*
+ * Copyright 2007-11 Advanced Micro Devices, Inc.
+ * Copyright 2008 Red Hat Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Dave Airlie
+ * Alex Deucher
+ */
+#include "drmP.h"
+#include "drm_crtc_helper.h"
+#include "radeon_drm.h"
+#include "radeon.h"
+#include "atom.h"
+
+extern int atom_debug;
+
+/* evil but including atombios.h is much worse */
+bool radeon_atom_get_tv_timings(struct radeon_device *rdev, int index,
+ struct drm_display_mode *mode);
+
+
+static inline bool radeon_encoder_is_digital(struct drm_encoder *encoder)
+{
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ switch (radeon_encoder->encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_LVDS:
+ case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+ case ENCODER_OBJECT_ID_INTERNAL_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_DDI:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static struct drm_connector *
+radeon_get_connector_for_encoder_init(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder->dev;
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ struct drm_connector *connector;
+ struct radeon_connector *radeon_connector;
+
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ radeon_connector = to_radeon_connector(connector);
+ if (radeon_encoder->devices & radeon_connector->devices)
+ return connector;
+ }
+ return NULL;
+}
+
+static bool radeon_atom_mode_fixup(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ struct drm_device *dev = encoder->dev;
+ struct radeon_device *rdev = dev->dev_private;
+
+ /* set the active enc
[PATCH 3/4] drm/radeon/kms: make atombios_dig_encoder_setup() version based
From: Alex Deucher
set up the params based on the table version number.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 213 +---
1 files changed, 128 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 7d91d3c..e0285c4 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -585,97 +585,140 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder,
int action, int panel_mo
if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, &frev,
&crev))
return;
- args.v1.ucAction = action;
- args.v1.usPixelClock = cpu_to_le16(radeon_encoder->pixel_clock / 10);
- if (action == ATOM_ENCODER_CMD_SETUP_PANEL_MODE)
- args.v3.ucPanelMode = panel_mode;
- else
- args.v1.ucEncoderMode = atombios_get_encoder_mode(encoder);
+ switch (frev) {
+ case 1:
+ switch (crev) {
+ case 1:
+ args.v1.ucAction = action;
+ args.v1.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
+ if (action == ATOM_ENCODER_CMD_SETUP_PANEL_MODE)
+ args.v3.ucPanelMode = panel_mode;
+ else
+ args.v1.ucEncoderMode =
atombios_get_encoder_mode(encoder);
- if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode))
- args.v1.ucLaneNum = dp_lane_count;
- else if (radeon_encoder->pixel_clock > 165000)
- args.v1.ucLaneNum = 8;
- else
- args.v1.ucLaneNum = 4;
-
- if (ASIC_IS_DCE5(rdev)) {
- if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode)) {
- if (dp_clock == 27)
- args.v1.ucConfig |=
ATOM_ENCODER_CONFIG_V4_DPLINKRATE_2_70GHZ;
- else if (dp_clock == 54)
- args.v1.ucConfig |=
ATOM_ENCODER_CONFIG_V4_DPLINKRATE_5_40GHZ;
- }
- args.v4.acConfig.ucDigSel = dig->dig_encoder;
- switch (bpc) {
- case 0:
- args.v4.ucBitPerColor = PANEL_BPC_UNDEFINE;
- break;
- case 6:
- args.v4.ucBitPerColor = PANEL_6BIT_PER_COLOR;
- break;
- case 8:
- default:
- args.v4.ucBitPerColor = PANEL_8BIT_PER_COLOR;
- break;
- case 10:
- args.v4.ucBitPerColor = PANEL_10BIT_PER_COLOR;
- break;
- case 12:
- args.v4.ucBitPerColor = PANEL_12BIT_PER_COLOR;
- break;
- case 16:
- args.v4.ucBitPerColor = PANEL_16BIT_PER_COLOR;
+ if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode))
+ args.v1.ucLaneNum = dp_lane_count;
+ else if (radeon_encoder->pixel_clock > 165000)
+ args.v1.ucLaneNum = 8;
+ else
+ args.v1.ucLaneNum = 4;
+
+ if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode) &&
(dp_clock == 27))
+ args.v1.ucConfig |=
ATOM_ENCODER_CONFIG_DPLINKRATE_2_70GHZ;
+ switch (radeon_encoder->encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ args.v1.ucConfig =
ATOM_ENCODER_CONFIG_V2_TRANSMITTER1;
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+ args.v1.ucConfig =
ATOM_ENCODER_CONFIG_V2_TRANSMITTER2;
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+ args.v1.ucConfig =
ATOM_ENCODER_CONFIG_V2_TRANSMITTER3;
+ break;
+ }
+ if (dig->linkb)
+ args.v1.ucConfig |= ATOM_ENCODER_CONFIG_LINKB;
+ else
+ args.v1.ucConfig |= ATOM_ENCODER_CONFIG_LINKA;
break;
- }
- if (hpd_id == RADEON_HPD_NONE)
- args.v4.ucHPD_ID = 0;
- else
- args.v4.ucHPD_ID = hpd_id + 1;
- } else if (ASIC_IS_DCE4(rdev)) {
- if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode) && (dp_clock ==
27))
- args.v1.ucConfig |=
ATOM_ENCODER_CONFIG_V3_DPLINKRATE_2_70GHZ;
- args.v3.acConfig.ucDigSel = dig->dig_e
[PATCH 4/4] drm/radeon/kms: make atombios_dig_transmitter_setup() version based
From: Alex Deucher
Use the table version to determine which params to use.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 343 ++--
1 files changed, 221 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index e0285c4..39c04c1 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -772,6 +772,11 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
igp_lane_info = dig_connector->igp_lane_info;
}
+ if (encoder->crtc) {
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
+ pll_id = radeon_crtc->pll_id;
+ }
+
/* no dig encoder assigned */
if (dig_encoder == -1)
return;
@@ -798,146 +803,240 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, &frev,
&crev))
return;
- args.v1.ucAction = action;
- if (action == ATOM_TRANSMITTER_ACTION_INIT) {
- args.v1.usInitInfo = cpu_to_le16(connector_object_id);
- } else if (action == ATOM_TRANSMITTER_ACTION_SETUP_VSEMPH) {
- args.v1.asMode.ucLaneSel = lane_num;
- args.v1.asMode.ucLaneSet = lane_set;
- } else {
- if (is_dp)
- args.v1.usPixelClock =
- cpu_to_le16(dp_clock / 10);
- else if (radeon_encoder->pixel_clock > 165000)
- args.v1.usPixelClock =
cpu_to_le16((radeon_encoder->pixel_clock / 2) / 10);
- else
- args.v1.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
- }
- if (ASIC_IS_DCE4(rdev)) {
- if (is_dp)
- args.v3.ucLaneNum = dp_lane_count;
- else if (radeon_encoder->pixel_clock > 165000)
- args.v3.ucLaneNum = 8;
- else
- args.v3.ucLaneNum = 4;
+ switch (frev) {
+ case 1:
+ switch (crev) {
+ case 1:
+ args.v1.ucAction = action;
+ if (action == ATOM_TRANSMITTER_ACTION_INIT) {
+ args.v1.usInitInfo =
cpu_to_le16(connector_object_id);
+ } else if (action ==
ATOM_TRANSMITTER_ACTION_SETUP_VSEMPH) {
+ args.v1.asMode.ucLaneSel = lane_num;
+ args.v1.asMode.ucLaneSet = lane_set;
+ } else {
+ if (is_dp)
+ args.v1.usPixelClock =
+ cpu_to_le16(dp_clock / 10);
+ else if (radeon_encoder->pixel_clock > 165000)
+ args.v1.usPixelClock =
cpu_to_le16((radeon_encoder->pixel_clock / 2) / 10);
+ else
+ args.v1.usPixelClock =
cpu_to_le16(radeon_encoder->pixel_clock / 10);
+ }
- if (dig->linkb)
- args.v3.acConfig.ucLinkSel = 1;
- if (dig_encoder & 1)
- args.v3.acConfig.ucEncoderSel = 1;
+ args.v1.ucConfig = ATOM_TRANSMITTER_CONFIG_CLKSRC_PPLL;
- /* Select the PLL for the PHY
-* DP PHY should be clocked from external src if there is
-* one.
-*/
- if (encoder->crtc) {
- struct radeon_crtc *radeon_crtc =
to_radeon_crtc(encoder->crtc);
- pll_id = radeon_crtc->pll_id;
- }
+ if (dig_encoder)
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG2_ENCODER;
+ else
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
+
+ if ((rdev->flags & RADEON_IS_IGP) &&
+ (radeon_encoder->encoder_id ==
ENCODER_OBJECT_ID_INTERNAL_UNIPHY)) {
+ if (is_dp || (radeon_encoder->pixel_clock <=
165000)) {
+ if (igp_lane_info & 0x1)
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_LANE_0_3;
+ else if (igp_lane_info & 0x2)
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_LANE_4_7;
+ else if (igp_lane_info & 0x4)
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_LANE_8_11;
+
[PATCH] drm: serialize access to debugs_nodes.list
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_debugfs.c |5 +
include/drm/drmP.h|1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 9d2668a..1144fbe 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -120,7 +120,9 @@ int drm_debugfs_create_files(struct drm_info_list *files,
int count,
tmp->minor = minor;
tmp->dent = ent;
tmp->info_ent = &files[i];
+ mutex_lock(&minor->debugfs_nodes.mutex);
list_add(&(tmp->list), &(minor->debugfs_nodes.list));
+ mutex_unlock(&minor->debugfs_nodes.mutex);
}
return 0;
@@ -149,6 +151,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
int ret;
INIT_LIST_HEAD(&minor->debugfs_nodes.list);
+ mutex_init(&minor->debugfs_nodes.mutex);
sprintf(name, "%d", minor_id);
minor->debugfs_root = debugfs_create_dir(name, root);
if (!minor->debugfs_root) {
@@ -194,6 +197,7 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
struct drm_info_node *tmp;
int i;
+ mutex_lock(&minor->debugfs_nodes.mutex);
for (i = 0; i < count; i++) {
list_for_each_safe(pos, q, &minor->debugfs_nodes.list) {
tmp = list_entry(pos, struct drm_info_node, list);
@@ -204,6 +208,7 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
}
}
}
+ mutex_unlock(&minor->debugfs_nodes.mutex);
return 0;
}
EXPORT_SYMBOL(drm_debugfs_remove_files);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9b7c2bb..c70c943 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -970,6 +970,7 @@ struct drm_info_list {
* debugfs node structure. This structure represents a debugfs file.
*/
struct drm_info_node {
+ struct mutex mutex;
struct list_head list;
struct drm_minor *minor;
struct drm_info_list *info_ent;
--
1.7.7
[PATCH] drm: Make the per-driver file_operations struct const
The DRM layer keeps a copy of struct file_operations inside its
big driver struct... which prevents it from being consistent and static.
For consistency (and the general security objective of having such things
static), it's desirable to get this fixed.
This patch splits out the file_operations field to its own struct,
which is then "static const", and just stick a pointer to this into
the driver struct, making it more consistent with how the rest of the
kernel does this.
Signed-off-by: Arjan van de Ven
---
drivers/gpu/drm/drm_fops.c|2 +-
drivers/gpu/drm/i810/i810_drv.c | 23 ++--
drivers/gpu/drm/i915/i915_drv.c | 31 +
drivers/gpu/drm/mga/mga_drv.c | 29
drivers/gpu/drm/nouveau/nouveau_drv.c | 31 +
drivers/gpu/drm/r128/r128_drv.c | 30
drivers/gpu/drm/radeon/radeon_drv.c | 60 +
drivers/gpu/drm/savage/savage_drv.c | 23 ++--
drivers/gpu/drm/sis/sis_drv.c | 23 ++--
drivers/gpu/drm/tdfx/tdfx_drv.c | 23 ++--
drivers/gpu/drm/via/via_drv.c | 23 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 28 ---
drivers/staging/gma500/psb_drv.c | 23 ++--
include/drm/drmP.h|2 +-
14 files changed, 182 insertions(+), 169 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 2ec7d48..3d7a75e 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -181,7 +181,7 @@ int drm_stub_open(struct inode *inode, struct file *filp)
goto out;
old_fops = filp->f_op;
- filp->f_op = fops_get(&dev->driver->fops);
+ filp->f_op = fops_get(dev->driver->fops);
if (filp->f_op == NULL) {
filp->f_op = old_fops;
goto out;
diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
index 6f98d05..c923956 100644
--- a/drivers/gpu/drm/i810/i810_drv.c
+++ b/drivers/gpu/drm/i810/i810_drv.c
@@ -41,6 +41,17 @@ static struct pci_device_id pciidlist[] = {
i810_PCI_IDS
};
+static const struct file_operations i810_driver_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .release = drm_release,
+ .unlocked_ioctl = drm_ioctl,
+ .mmap = drm_mmap,
+ .poll = drm_poll,
+ .fasync = drm_fasync,
+ .llseek = noop_llseek,
+};
+
static struct drm_driver driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | DRIVER_USE_MTRR |
@@ -53,17 +64,7 @@ static struct drm_driver driver = {
.reclaim_buffers_locked = i810_driver_reclaim_buffers_locked,
.dma_quiescent = i810_driver_dma_quiescent,
.ioctls = i810_ioctls,
- .fops = {
-.owner = THIS_MODULE,
-.open = drm_open,
-.release = drm_release,
-.unlocked_ioctl = drm_ioctl,
-.mmap = drm_mmap,
-.poll = drm_poll,
-.fasync = drm_fasync,
-.llseek = noop_llseek,
- },
-
+ .fops = &i810_driver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f07e4252..c395713 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -784,6 +784,21 @@ static struct vm_operations_struct i915_gem_vm_ops = {
.close = drm_gem_vm_close,
};
+static const struct file_operations i915_driver_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .release = drm_release,
+ .unlocked_ioctl = drm_ioctl,
+ .mmap = drm_gem_mmap,
+ .poll = drm_poll,
+ .fasync = drm_fasync,
+ .read = drm_read,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = i915_compat_ioctl,
+#endif
+ .llseek = noop_llseek,
+};
+
static struct drm_driver driver = {
/* don't use mtrr's here, the Xserver or user space app should
* deal with them for intel hardware.
@@ -817,21 +832,7 @@ static struct drm_driver driver = {
.dumb_map_offset = i915_gem_mmap_gtt,
.dumb_destroy = i915_gem_dumb_destroy,
.ioctls = i915_ioctls,
- .fops = {
-.owner = THIS_MODULE,
-.open = drm_open,
-.release = drm_release,
-.unlocked_ioctl = drm_ioctl,
-.mmap = drm_gem_mmap,
-.poll = drm_poll,
-.fasync = drm_fasync,
-.read = drm_read,
-#ifdef CONFIG_COMPAT
-.compat_ioctl = i915_compat_ioctl,
-#endif
-.llseek = noop_llseek,
- },
-
+ .fops = &i915_driver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
diff --git a/drivers/gpu/drm/mga/mga_drv.c b/drivers/gpu/drm/mga/mga_drv.
