[Bug 35861] [r300g] Oilrush: whiter triangle between center of the screen and horizon
https://bugs.freedesktop.org/show_bug.cgi?id=35861 --- Comment #3 from Pavel Ondračka 2011-09-19 00:05:34 PDT --- Created an attachment (id=51327) --> (https://bugs.freedesktop.org/attachment.cgi?id=51327) Oilrush output with RADEON_DEBUG=vp (In reply to comment #2) > Is this still an issue with the latest version from git, and if so can you > post > the output of RADEON_DEBUG=vp ? Yes, this is still an issue with latest mesa. Requested log attached. I can also make you an apitrace if you don't have access to the game. -- 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 34218] [r300g] Unigine: some surfaces are reflecting too much light
https://bugs.freedesktop.org/show_bug.cgi?id=34218 Pavel Ondračka changed: What|Removed |Added Summary|[r300g] Unigine Sanctuary: |[r300g] Unigine: some |some surfaces are |surfaces are reflecting too |reflecting too much light |much light --- Comment #10 from Pavel Ondračka 2011-09-19 00:06:43 PDT --- Unigine Oilrush is also affected. -- 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: Proposal for a low-level Linux display framework
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote: > On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen > wrote: > > > I think it's a bit more complex than that. True, there are MIPI > > standards, for the video there are DPI, DBI, DSI, and for the commands > > there is DCS. And, as you mentioned, many panels need custom > > initialization, or support only parts of the DCS, or have other > > quirks. > > So DSI is more like i2c than the DisplayPort aux channel or DDC. That Well, not quite. DSI is like DisplayPort and DisplayPort aux combined; there's only one bus, DSI, which is used to transfer video data and commands. For DSI video mode, the transfer is somewhat like traditional displays, and video data is send according to a pixel clock as a constant stream. However, before the video stream is enabled the bus can be used in bi-directional communication. And even when the video stream is enabled, there can be other communication in the blanking periods. For DSI command mode the transfer is a bit like high speed i2c; messages are sent when needed (when the userspace gives the command to update), without any strict timings. In practice this means that the peripheral needs to have a framebuffer memory of its own, which it uses to refresh the actual panel (or send the pixels forward to another peripheral). As the use patterns of these two types of displays are quite different, we have the terms auto-update and manual-update displays for them. > seems fine; you can create a DSI infrastructure like the i2c > infrastructure and then just have your display drivers use it to talk to > the panel. We might eventually end up with some shared DRM code to deal > with common DSI functions for display devices, like the EDID code > today, but that doesn't need to happen before you can write your first > DSI-using display driver. One difference with i2c and DSI is that i2c is independent of the video path, so it's easy to keep that separate from DRM. But for DSI the data is produced by the video hardware using the overlays, encoders etc. I don't quite see how we could have an i2c-like separate DSI API, which wasn't part of DRM. And even in simpler case MIPI DPI, which is a traditional parallel RGB interface, a panel may need custom configuration via, say, i2c or spi. We can, of course, create a i2c device driver for the panel, but how is that then connected to DRM? The i2c driver may need to know things like when the display is enabled/disabled, about backlight changes, or any other display related event. Is there a way for the i2c driver to get these events, and add new properties to the DRM (say, if the panel has a feature configured via i2c, but we'd like it to be visible to the userspace via the DRM driver)? Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Updated plane support v3
2011/6/21 Jesse Barnes : > This version adds both source and dest rect params to the set_plane > ioctl, and makes the source fixed point to support hardware that needs > it. > > I haven't changed the name of the SNB implementation yet (per Chris's > suggestions) but will before it gets upstream. > > I'd be interested to see whether these interfaces will work for other > hardware, so please take a close look at them and ideally implement them > on your hardware to make sure (see my userspace example code from > earlier posts if you want something to crib from). > > Thanks, > Jesse > Hi, Jesse. Could you have any posting plan for plane? Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29951] [r300g] xscreensaver hack "antspotlight" reveals something other than desktop
https://bugs.freedesktop.org/show_bug.cgi?id=29951 --- Comment #7 from Chris Rankin 2011-09-19 01:29:22 PDT --- (In reply to comment #6) > I just tested this with the latest version from git, and it appears to be > working. Can you confirm this? Sorry, it's not fixed yet. I ran antspotlight about 5 times in succession and the problem reoccurred. It did work the first few times, though. -- 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
[git pull] drm fixes
Hi Linus, Some fixes for page size mismatches in radeon, a lockdep noticed locking problem, and a fix to zero some memory that was being passed to userspace. Dave. The following changes since commit 003f6c9df54970d8b19578d195b3e2b398cdbde2: lib/sha1.c: quiet sparse noise about symbol not declared (2011-09-13 16:09:41 -0700) are available in the git repository at: git://people.freedesktop.org/~/linux.git drm-fixes Alex Deucher (2): drm/radeon/kms: fix typo in r100_blit_copy drm/radeon/kms: Make GPU/CPU page size handling consistent in blit code (v2) Ben Skeggs (1): drm/ttm: request zeroed system memory pages for new TT buffer objects Michel Dänzer (2): drm/radeon: Don't read from CP ring write pointer registers. drm/radeon: Unreference GEM object outside of spinlock in page flip error path. drivers/gpu/drm/radeon/evergreen.c | 14 -- drivers/gpu/drm/radeon/ni.c | 12 ++-- drivers/gpu/drm/radeon/r100.c | 22 ++ drivers/gpu/drm/radeon/r200.c |4 ++-- drivers/gpu/drm/radeon/r600.c | 14 -- drivers/gpu/drm/radeon/radeon.h |7 --- drivers/gpu/drm/radeon/radeon_asic.h|8 drivers/gpu/drm/radeon/radeon_display.c |2 +- drivers/gpu/drm/radeon/radeon_ttm.c |7 ++- drivers/gpu/drm/ttm/ttm_bo.c|3 ++- 10 files changed, 51 insertions(+), 42 deletions(-)___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41002] New: Switching doesn't work between plymouth and xorg.
https://bugs.freedesktop.org/show_bug.cgi?id=41002 Summary: Switching doesn't work between plymouth and xorg. Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: fabian.deut...@gmx.de When initiating a switch to the discrete card while plymouth is running, the switch doesn't happen completely in the small slot between the end of ply and Xorg's start. This happens with current Fedora 15 (all updates). Note: Maybe this is similar to bug #32970 -- 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 40935] radeon lockup on resume
https://bugs.freedesktop.org/show_bug.cgi?id=40935 --- Comment #4 from Michal Suchanek 2011-09-19 04:21:10 PDT --- It's a redwood. The bootup dmesg is below the locup messages. I am not sure what dev_err() would be. And now I rebooted and tried to kill Xorg with suspend and it would not lock up the card, only keep resetting it. -- 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] RFCv2: omapdrm DRM/KMS driver for TI OMAP platforms
On Mon, Sep 19, 2011 at 2:44 AM, Inki Dae wrote:
> Hello Rob.
>
> Is there some reason that you don't head your driver gpu/drm, just staging?
> and below is my short comments. thank you.
>
mainly because it is still a work-in-progress.. I expect some
re-shuffling of the mode-setting code when drm_plane support is added,
the plugin layer, etc. And perhaps at some point merging of the
omapdss and omapdrm layers.
I don't expect the ioctl ABI to change, and the driver is useful
as-is, but I still think there is enough changes that will happen that
staging is perhaps the better place for it to start life..
[snip]
>> +/* initialize connector */
>> +struct drm_connector * omap_connector_init(struct drm_device *dev,
>> + int connector_type, struct omap_dss_device *dssdev)
>> +{
>> + struct drm_connector *connector = NULL;
>> + struct omap_connector *omap_connector;
>> +
>> + DBG("%s", dssdev->name);
>> +
>> + omap_dss_get_device(dssdev);
>> +
>> + omap_connector = kzalloc(sizeof(struct omap_connector), GFP_KERNEL);
>> + if (!omap_connector) {
>> + dev_err(dev->dev, "could not allocate connector\n");
>> + goto fail;
>> + }
>> +
>> + omap_connector->dssdev = dssdev;
>> + connector = &omap_connector->base;
>> +
>> + drm_connector_init(dev, connector, &omap_connector_funcs,
>> + connector_type);
>> + drm_connector_helper_add(connector, &omap_connector_helper_funcs);
>> +
>> +#if 0 /* enable when dss2 supports hotplug */
>> + if (dssdev->caps & OMAP_DSS_DISPLAY_CAP_HPD)
>> + connector->polled = 0;
>> + else
>> +#endif
>
> How about removing the codes above until dss2 supports hotplug?
>
easier not to forget about them this way ;-)
if someone has a strong opinion, I can remove them.. but I guess it
should be not too distant future when support lands in dss2.. I guess
I should put a note in the TODO about re-enabling hotplug code
>> + connector->polled = DRM_CONNECTOR_POLL_CONNECT |
>> + DRM_CONNECTOR_POLL_DISCONNECT;
>> +
>> + connector->interlace_allowed = 1;
>> + connector->doublescan_allowed = 0;
>> +
>> + drm_sysfs_connector_add(connector);
>> +
>> + return connector;
>> +
>> +fail:
>> + if (connector) {
>> + omap_connector_destroy(connector);
>> + }
>> +
>> + return NULL;
>> +}
[snip]
>> +static void omap_crtc_dpms(struct drm_crtc *crtc, int mode)
>> +{
>> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> +
>> + DBG("%s: %d", omap_crtc->ovl->name, mode);
>> +
>> + if (mode == DRM_MODE_DPMS_ON) {
>> + update_scanout(crtc);
>
> Is there any reason that update_scanout function should be called here to
> update buffer address.? I think it's enough to call this function at
> mode_set callback.
In theory it should not be needed.. IIRC at some point I was hitting
some problem that the buffer address wasn't set yet, but that was w/
older version of the driver, older kernel, and different xorg driver..
>> + omap_crtc->info.enabled = true;
>> + } else {
>> + omap_crtc->info.enabled = false;
>> + }
>> +
>> + commit(crtc);
>
> and commit callback to apply those data on hw.
>
>> +}
>> +
[snip]
>> +
>> +/**
>> + * load - setup chip and create an initial config
>> + * @dev: DRM device
>> + * @flags: startup flags
>> + *
>> + * The driver load routine has to do several things:
>> + * - initialize the memory manager
>> + * - allocate initial config memory
>> + * - setup the DRM framebuffer with the allocated memory
>> + */
>> +static int dev_load(struct drm_device *dev, unsigned long flags)
>> +{
>> + struct omap_drm_private *priv;
>> + int ret;
>> +
>> + DBG("load: dev=%p", dev);
>> +
>> + drm_device = dev;
>> +
>> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>> + if (!priv) {
>> + dev_err(dev->dev, "could not allocate priv\n");
>> + return -1;
>> + }
>> +
>> + dev->dev_private = priv;
>> +
>> + ret = omap_modeset_init(dev);
>> + if (ret) {
>> + dev_err(dev->dev, "omap_modeset_init failed: ret=%d\n",
> ret);
>> + // hmm
>> + //return ret;
>
> Doesn't it need return? you output error message using dev_err().
Well.. currently omap_modeset_init() never returns !=0
I'm still a bit undecided on some of the error cases.. for example if
we don't successfully initialize everything, but do at least have >1
of each crtc/encoder/connector, maybe it makes sense to continue in
some reduced capacity..
But "check error handling/cleanup paths" is still in the TODO file ;-)
>> + }
>> +
>> + priv->fbdev = omap_fbdev_init(dev);
>> + if (!priv->fbdev) {
>> + dev_err(dev->dev, "omap_fbdev_init failed\n");
>> + ret = -ENOMEM;
>> + // hmm
>> + //return ret;
>
> Ditto. and also you would have to rele
[Bug 41002] Switching doesn't work between plymouth and xorg. (vgaswitcheroo)
https://bugs.freedesktop.org/show_bug.cgi?id=41002 Fabian Deutsch changed: What|Removed |Added Summary|Switching doesn't work |Switching doesn't work |between plymouth and xorg. |between plymouth and xorg. ||(vgaswitcheroo) -- 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 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #7 from Michal Suchanek 2011-09-19 09:39:58 PDT --- According to apitrace author the glretrace crash is due to gallium reading more data than is in the buffer. https://github.com/apitrace/apitrace/issues/39#issuecomment-2134199 -- 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 41019] New: DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 Summary: DPMS doesn't work correctly Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: General AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: nissa...@gmail.com Created an attachment (id=51369) --> (https://bugs.freedesktop.org/attachment.cgi?id=51369) dmesg output Monitor will keep constantly switching off/on when entering power saving mode: - LCD going black - OSD message "Entering power saving mode" - LCD turns off, then immediately goes back on and the cycle repeats This bug was previously reported on other list and should be fixed but unfortunately it's still present on my system. - Gentoo/AMD64 - kernel 3.1.0-rc6-00120 (linus + drm-fixes) - xorg 1.11.0/1.10.4 - Radeon 6850 (+internal card disabled) - Dell U2410 I'm not sure if this is relevant but the same effect can be observed on every power mode, i.e. xset dpms force standby/suspend/off. -- 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 41019] DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 --- Comment #1 from Wojciech Pyczak 2011-09-19 11:56:00 PDT --- Created an attachment (id=51370) --> (https://bugs.freedesktop.org/attachment.cgi?id=51370) 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 41019] DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 Alex Deucher changed: What|Removed |Added Attachment #51369|text/x-log |text/plain mime type|| Attachment #51369|0 |1 is patch|| -- 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 28847] Regnum Online: shader backend not rendering
https://bugs.freedesktop.org/show_bug.cgi?id=28847 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Sven Arvidsson 2011-09-19 12:05:02 PDT --- (In reply to comment #8) > Is this still an issue with the latest mesa from git? The game is still busted, but this is not specific to r300g but a problem with the GLSL compiler. There's already bug 28138 open about this, but that's filed against i965 and Intel is making some progress there, but only on their own backend. It's probably easier to close this report and file a new one against Mesa core to keep things simple. -- 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 41019] DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Alex Deucher 2011-09-19 12:05:11 PDT --- *** This bug has been marked as a duplicate of bug 40851 *** -- 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 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #8 from Marek Olšák 2011-09-19 12:44:51 PDT --- Created an attachment (id=51371) View: https://bugs.freedesktop.org/attachment.cgi?id=51371 Review: https://bugs.freedesktop.org/review?bug=39320&attachment=51371 print debug info I think it crashes because offset >= upload->buffer->width0. Could you apply the attached patch and post the output of stderr? -- 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 1/2] drm/radeon: add tracepoint for setting mode clocks.
From: Dave Airlie
This just adds a tracepoint that can be caught in perf for when the clocks
change.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_pm.c|3 +++
drivers/gpu/drm/radeon/radeon_trace.h | 18 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 6fabe89..2a44332 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include "radeon_trace.h"
#define RADEON_IDLE_LOOP_MS 100
#define RADEON_RECLOCK_DELAY_MS 200
@@ -165,6 +166,8 @@ static void radeon_set_power_state(struct radeon_device
*rdev)
(rdev->pm.requested_power_state_index ==
rdev->pm.current_power_state_index))
return;
+ trace_radeon_set_power_state(rdev);
+
if (radeon_gui_idle(rdev)) {
sclk =
rdev->pm.power_state[rdev->pm.requested_power_state_index].
clock_info[rdev->pm.requested_clock_mode_index].sclk;
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h
b/drivers/gpu/drm/radeon/radeon_trace.h
index eafd816..ef0fd05 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -27,6 +27,24 @@ TRACE_EVENT(radeon_bo_create,
TP_printk("bo=%p, pages=%u", __entry->bo, __entry->pages)
);
+TRACE_EVENT(radeon_set_power_state,
+TP_PROTO(struct radeon_device *rdev),
+TP_ARGS(rdev),
+ TP_STRUCT__entry(
+__field(int, requested_clock_mode)
+__field(int, current_clock_mode)
+__field(int, requested_power_state)
+__field(int, current_power_state)
+ ),
+ TP_fast_assign(
+ __entry->requested_clock_mode =
rdev->pm.requested_clock_mode_index;
+ __entry->current_clock_mode =
rdev->pm.current_clock_mode_index;
+ __entry->requested_power_state =
rdev->pm.requested_power_state_index;
+ __entry->current_power_state =
rdev->pm.current_power_state_index;
+ ),
+ TP_printk("clock %d->%d, power %d->%d",
__entry->current_clock_mode, __entry->requested_clock_mode,
__entry->current_power_state, __entry->requested_power_state)
+);
+
DECLARE_EVENT_CLASS(radeon_fence_request,
TP_PROTO(struct drm_device *dev, u32 seqno),
--
1.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: make pm method file show default + option.
From: Dave Airlie If we add more options in the future this will need rework. this is modelled after the example in /sys/power/disk. Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/radeon_pm.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 2a44332..25bc75e 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -390,9 +390,13 @@ static ssize_t radeon_get_pm_method(struct device *dev, struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev)); struct radeon_device *rdev = ddev->dev_private; int pm = rdev->pm.pm_method; + char *start = buf; - return snprintf(buf, PAGE_SIZE, "%s\n", - (pm == PM_METHOD_DYNPM) ? "dynpm" : "profile"); + if (pm == PM_METHOD_DYNPM) + buf += snprintf(buf, PAGE_SIZE, "[dynpm] profile\n"); + else + buf += snprintf(buf, PAGE_SIZE, "dynpm [profile]\n"); + return buf - start; } static ssize_t radeon_set_pm_method(struct device *dev, -- 1.7.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #9 from Michal Suchanek 2011-09-19 14:52:19 PDT --- I get this extra output: u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_upload_alloc:194: min_out_offset = 4294966000, size = 1296, alloc_size = 1296, alloc_offset = 4294966000, upload->offset = 322528, upload->size = 1048576, upload->buffer->width0 = 1048576, offset = 4294966000 util/u_upload_mgr.c:195:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed. -- 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
drm/i915: eDP cleanup patch series -- fixes SNB MacBook Air
Here's a sequence of eDP patches which are necessary to make the driver work on the Sandybridge MacBook Air The key trick was to make sure that the eDP power was applied before trying to communicate with the device. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/i915: Enable digital port hotplug on PCH systems
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 542453f..b7fbb74 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2903,12 +2903,13 @@
#define SDEIER 0xc400c
/* digital port hotplug */
-#define PCH_PORT_HOTPLUG0xc4030
+#define PCH_PORT_HOTPLUG0xc4030/* SHOTPLUG_CTL */
#define PORTD_HOTPLUG_ENABLE(1 << 20)
#define PORTD_PULSE_DURATION_2ms(0)
#define PORTD_PULSE_DURATION_4_5ms (1 << 18)
#define PORTD_PULSE_DURATION_6ms(2 << 18)
#define PORTD_PULSE_DURATION_100ms (3 << 18)
+#define PORTD_PULSE_DURATION_MASK (3 << 18)
#define PORTD_HOTPLUG_NO_DETECT (0)
#define PORTD_HOTPLUG_SHORT_DETECT (1 << 16)
#define PORTD_HOTPLUG_LONG_DETECT (1 << 17)
@@ -2917,6 +2918,7 @@
#define PORTC_PULSE_DURATION_4_5ms (1 << 10)
#define PORTC_PULSE_DURATION_6ms(2 << 10)
#define PORTC_PULSE_DURATION_100ms (3 << 10)
+#define PORTC_PULSE_DURATION_MASK (3 << 10)
#define PORTC_HOTPLUG_NO_DETECT (0)
#define PORTC_HOTPLUG_SHORT_DETECT (1 << 8)
#define PORTC_HOTPLUG_LONG_DETECT (1 << 9)
@@ -2925,6 +2927,7 @@
#define PORTB_PULSE_DURATION_4_5ms (1 << 2)
#define PORTB_PULSE_DURATION_6ms(2 << 2)
#define PORTB_PULSE_DURATION_100ms (3 << 2)
+#define PORTB_PULSE_DURATION_MASK (3 << 2)
#define PORTB_HOTPLUG_NO_DETECT (0)
#define PORTB_HOTPLUG_SHORT_DETECT (1 << 0)
#define PORTB_HOTPLUG_LONG_DETECT (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9fb4a40..54403dd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7151,6 +7151,18 @@ static void intel_setup_outputs(struct drm_device *dev)
I915_WRITE(PFIT_CONTROL, 0);
}
+ /* Enable digital port hotplug detect on PCH hardware */
+ if (HAS_PCH_SPLIT(dev)) {
+ u32 hotplug;
+
+ hotplug = I915_READ(PCH_PORT_HOTPLUG);
+ hotplug &=
~(PORTD_PULSE_DURATION_MASK|PORTC_PULSE_DURATION_MASK|PORTB_PULSE_DURATION_MASK);
+ hotplug |= PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_2ms;
+ hotplug |= PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_2ms;
+ hotplug |= PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_2ms;
+ I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
+ }
+
if (HAS_PCH_SPLIT(dev)) {
dpd_is_edp = intel_dpd_is_edp(dev);
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/i915: Remove extra 300ms delay during eDP mode setting
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..f0cfb6b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -903,13 +903,6 @@ static void ironlake_edp_backlight_on (struct drm_device
*dev)
u32 pp;
DRM_DEBUG_KMS("\n");
- /*
-* If we enable the backlight right away following a panel power
-* on, we may see slight flicker as the panel syncs with the eDP
-* link. So delay a bit to make sure the image is solid before
-* allowing it to appear.
-*/
- msleep(300);
pp = I915_READ(PCH_PP_CONTROL);
pp |= EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/i915: Only use VBT panel mode on eDP if no EDID is found
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f0cfb6b..8ab2a88 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1748,7 +1748,16 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
/* if eDP has no EDID, try to use fixed panel mode from VBT */
if (is_edp(intel_dp)) {
- if (dev_priv->panel_fixed_mode != NULL) {
+ /* initialize panel mode from VBT if available for eDP */
+ if (dev_priv->panel_fixed_mode == NULL &&
dev_priv->lfp_lvds_vbt_mode != NULL) {
+ dev_priv->panel_fixed_mode =
+ drm_mode_duplicate(dev,
dev_priv->lfp_lvds_vbt_mode);
+ if (dev_priv->panel_fixed_mode) {
+ dev_priv->panel_fixed_mode->type |=
+ DRM_MODE_TYPE_PREFERRED;
+ }
+ }
+ if (dev_priv->panel_fixed_mode) {
struct drm_display_mode *mode;
mode = drm_mode_duplicate(dev,
dev_priv->panel_fixed_mode);
drm_mode_probed_add(connector, mode);
@@ -2061,15 +2070,6 @@ intel_dp_init(struct drm_device *dev, int output_reg)
intel_encoder->hot_plug = intel_dp_hot_plug;
if (is_edp(intel_dp)) {
- /* initialize panel mode from VBT if available for eDP */
- if (dev_priv->lfp_lvds_vbt_mode) {
- dev_priv->panel_fixed_mode =
- drm_mode_duplicate(dev,
dev_priv->lfp_lvds_vbt_mode);
- if (dev_priv->panel_fixed_mode) {
- dev_priv->panel_fixed_mode->type |=
- DRM_MODE_TYPE_PREFERRED;
- }
- }
dev_priv->int_edp_connector = connector;
intel_panel_setup_backlight(dev);
}
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/i915: Check eDP power when doing aux channel communications
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8ab2a88..3b29a6f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -279,6 +279,24 @@ intel_hrawclk(struct drm_device *dev)
}
}
+static void
+intel_dp_check_edp(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 pp_status, pp_control;
+ if (!is_edp(intel_dp))
+ return;
+ pp_status = I915_READ(PCH_PP_STATUS);
+ pp_control = I915_READ(PCH_PP_CONTROL);
+ if ((pp_status & PP_ON) == 0 && (pp_control & EDP_FORCE_VDD) == 0) {
+ WARN(1, "eDP powered off while attempting aux channel
communication.\n");
+ DRM_DEBUG_KMS("Status 0x%08x Control 0x%08x\n",
+ pp_status,
+ I915_READ(PCH_PP_CONTROL));
+ }
+}
+
static int
intel_dp_aux_ch(struct intel_dp *intel_dp,
uint8_t *send, int send_bytes,
@@ -295,6 +313,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
uint32_t aux_clock_divider;
int try, precharge;
+ intel_dp_check_edp(intel_dp);
/* The clock divider is based off the hrawclk,
* and would like to run at 2MHz. So, take the
* hrawclk value and divide by 2 and use that
@@ -408,6 +427,7 @@ intel_dp_aux_native_write(struct intel_dp *intel_dp,
int msg_bytes;
uint8_t ack;
+ intel_dp_check_edp(intel_dp);
if (send_bytes > 16)
return -1;
msg[0] = AUX_NATIVE_WRITE << 4;
@@ -450,6 +470,7 @@ intel_dp_aux_native_read(struct intel_dp *intel_dp,
uint8_t ack;
int ret;
+ intel_dp_check_edp(intel_dp);
msg[0] = AUX_NATIVE_READ << 4;
msg[1] = address >> 8;
msg[2] = address & 0xff;
@@ -493,6 +514,7 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
int reply_bytes;
int ret;
+ intel_dp_check_edp(intel_dp);
/* Set up the command byte */
if (mode & MODE_I2C_READ)
msg[0] = AUX_I2C_READ << 4;
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/i915: Unlock PCH_PP_CONTROL always
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b7fbb74..5596e8e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3311,6 +3311,7 @@
#define PCH_PP_STATUS 0xc7200
#define PCH_PP_CONTROL 0xc7204
#define PANEL_UNLOCK_REGS (0xabcd << 16)
+#define PANEL_UNLOCK_MASK (0x << 16)
#define EDP_FORCE_VDD (1 << 3)
#define EDP_BLC_ENABLE(1 << 2)
#define PANEL_POWER_RESET (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3b29a6f..a983d0f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -840,6 +840,8 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
msleep(dev_priv->panel_t3);
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp |= EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -852,6 +854,8 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
u32 pp;
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp &= ~EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -871,13 +875,15 @@ static bool ironlake_edp_panel_on (struct intel_dp
*intel_dp)
return true;
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
/* ILK workaround: disable reset around power sequence */
pp &= ~PANEL_POWER_RESET;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
- pp |= PANEL_UNLOCK_REGS | POWER_TARGET_ON;
+ pp |= POWER_TARGET_ON;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -900,6 +906,8 @@ static void ironlake_edp_panel_off (struct drm_device *dev)
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
/* ILK workaround: disable reset around power sequence */
pp &= ~PANEL_POWER_RESET;
@@ -926,6 +934,8 @@ static void ironlake_edp_backlight_on (struct drm_device
*dev)
DRM_DEBUG_KMS("\n");
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp |= EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
}
@@ -937,6 +947,8 @@ static void ironlake_edp_backlight_off (struct drm_device
*dev)
DRM_DEBUG_KMS("\n");
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp &= ~EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
}
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/i915: Move eDP panel fixed mode from dev_priv to intel_dp
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bcdf58b..e6dd19e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -347,7 +347,6 @@ typedef struct drm_i915_private {
/* LVDS info */
int backlight_level; /* restore backlight to this value */
bool backlight_enabled;
- struct drm_display_mode *panel_fixed_mode;
struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1d6105..5bc30f9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -61,6 +61,7 @@ struct intel_dp {
uint8_t link_status[DP_LINK_STATUS_SIZE];
int panel_power_up_delay;
int panel_power_down_delay;
+ struct drm_display_mode *panel_fixed_mode; /* for eDP */
};
/**
@@ -202,16 +203,14 @@ intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
- struct drm_device *dev = connector->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
int max_link_clock =
intel_dp_link_clock(intel_dp_max_link_bw(intel_dp));
int max_lanes = intel_dp_max_lane_count(intel_dp);
- if (is_edp(intel_dp) && dev_priv->panel_fixed_mode) {
- if (mode->hdisplay > dev_priv->panel_fixed_mode->hdisplay)
+ if (is_edp(intel_dp) && intel_dp->panel_fixed_mode) {
+ if (mode->hdisplay > intel_dp->panel_fixed_mode->hdisplay)
return MODE_PANEL;
- if (mode->vdisplay > dev_priv->panel_fixed_mode->vdisplay)
+ if (mode->vdisplay > intel_dp->panel_fixed_mode->vdisplay)
return MODE_PANEL;
}
@@ -630,22 +629,21 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_device *dev = encoder->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
int lane_count, clock;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 :
0;
static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
- if (is_edp(intel_dp) && dev_priv->panel_fixed_mode) {
- intel_fixed_panel_mode(dev_priv->panel_fixed_mode,
adjusted_mode);
+ if (is_edp(intel_dp) && intel_dp->panel_fixed_mode) {
+ intel_fixed_panel_mode(intel_dp->panel_fixed_mode,
adjusted_mode);
intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
mode, adjusted_mode);
/*
* the mode->clock is used to calculate the Data&Link M/N
* of the pipe. For the eDP the fixed clock should be used.
*/
- mode->clock = dev_priv->panel_fixed_mode->clock;
+ mode->clock = intel_dp->panel_fixed_mode->clock;
}
for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
@@ -1812,35 +1810,34 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
ret = intel_dp_get_edid_modes(connector, &intel_dp->adapter);
if (ret) {
- if (is_edp(intel_dp) && !dev_priv->panel_fixed_mode) {
+ if (is_edp(intel_dp) && !intel_dp->panel_fixed_mode) {
struct drm_display_mode *newmode;
list_for_each_entry(newmode, &connector->probed_modes,
head) {
- if (newmode->type & DRM_MODE_TYPE_PREFERRED) {
- dev_priv->panel_fixed_mode =
+ if ((newmode->type & DRM_MODE_TYPE_PREFERRED)) {
+ intel_dp->panel_fixed_mode =
drm_mode_duplicate(dev,
newmode);
break;
}
}
}
-
return ret;
}
/* if eDP has no EDID, try to use fixed panel mode from VBT */
if (is_edp(intel_dp)) {
/* initialize panel mode from VBT if available for eDP */
- if (dev_priv->panel_fixed_mode == NULL &&
dev_priv->lfp_lvds_vbt_mode != NULL) {
-
[PATCH 6/9] drm/i915: Make sure eDP power is on before using aux channel
The eDP panel may not be able to respond to aux channel communications
unless it has power supplied. During mode setting, power may be
cut-off during panel power sequencing. Make sure that any aux channel
communications will work by forcing vdd power active as needed.
This also delays after turning power on and off to ensure that the
panel is keeping up.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 84 +-
1 files changed, 64 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a983d0f..41b1e05 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -595,10 +595,15 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
return -EREMOTEIO;
}
+static void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp);
+static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp);
+
static int
intel_dp_i2c_init(struct intel_dp *intel_dp,
struct intel_connector *intel_connector, const char *name)
{
+ int ret;
+
DRM_DEBUG_KMS("i2c_init %s\n", name);
intel_dp->algo.running = false;
intel_dp->algo.address = 0;
@@ -612,7 +617,10 @@ intel_dp_i2c_init(struct intel_dp *intel_dp,
intel_dp->adapter.algo_data = &intel_dp->algo;
intel_dp->adapter.dev.parent = &intel_connector->base.kdev;
- return i2c_dp_aux_add_bus(&intel_dp->adapter);
+ ironlake_edp_panel_vdd_on(intel_dp);
+ ret = i2c_dp_aux_add_bus(&intel_dp->adapter);
+ ironlake_edp_panel_vdd_off(intel_dp);
+ return ret;
}
static bool
@@ -830,14 +838,20 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
{
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- u32 pp;
+ u32 pp, pp_status;
+ if (!is_edp(intel_dp))
+ return;
+ DRM_DEBUG_KMS("Turn eDP VDD on\n");
/*
* If the panel wasn't on, make sure there's not a currently
* active PP sequence before enabling AUX VDD.
*/
- if (!(I915_READ(PCH_PP_STATUS) & PP_ON))
+ pp_status = I915_READ(PCH_PP_STATUS);
+ if (!(pp_status & PP_ON)) {
+ DRM_DEBUG_KMS("eDP VDD was not on\n");
msleep(dev_priv->panel_t3);
+ }
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -845,6 +859,9 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
pp |= EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
+ DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
+ I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
+ msleep(1000);
}
static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -853,6 +870,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp;
+ if (!is_edp(intel_dp))
+ return;
+ DRM_DEBUG_KMS("Turn eDP VDD off\n");
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
pp |= PANEL_UNLOCK_REGS;
@@ -862,6 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
/* Make sure sequencer is idle before allowing subsequent activity */
msleep(dev_priv->panel_t12);
+ DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
+ I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
+ msleep(1000);
}
/* Returns true if the panel was already on when called */
@@ -1016,7 +1039,9 @@ static void intel_dp_prepare(struct drm_encoder *encoder)
struct drm_device *dev = encoder->dev;
/* Wake up the sink first */
+ ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ ironlake_edp_panel_vdd_off(intel_dp);
if (is_edp(intel_dp)) {
ironlake_edp_backlight_off(dev);
@@ -1034,21 +1059,17 @@ static void intel_dp_commit(struct drm_encoder *encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct drm_device *dev = encoder->dev;
- if (is_edp(intel_dp))
- ironlake_edp_panel_vdd_on(intel_dp);
-
+ ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_start_link_train(intel_dp);
- if (is_edp(intel_dp)) {
+ if (is_edp(intel_dp))
ironlake_edp_panel_on(intel_dp);
- ironlake_edp_panel_vdd_off(intel_dp);
- }
intel_dp_complete_link_train(intel_dp);
if (is_edp(intel_dp))
ironlake_edp_backlight_on(dev);
-
+ ironlake_edp_panel_vdd_off(intel_dp);
intel_dp->dpms_mode = DRM_MODE_DPMS_ON;
}
@@ -1060,6 +1081,7 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
struct
[PATCH 7/9] drm/i915: Correct eDP panel power sequencing delay computations
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum of the two
delays, to make sure things work reliably. If there is no VBT data,
then those values will be initialized to zero, so we'll just use the
values as programmed in the hardware.
This patch computes power-up and power-down delays, rather than using
portions of the appropriate delay values as found in the hardware. The
eDP specified delay between raising VCC and communicating over the aux
channel includes both the power rise time (T1) and the aux channel
communication delay (T3). The eDP specified delay between powering
down the device and powering it back up includes both the power fall
time (T11) and the device idle time (T12).
>From the hardware, I'm taking the T3 value from the PP_OFF_DELAYS
Power_Down_delay value, which is actually documented to be the 'T3
time sequence' value used 'during power up'. There aren't separate T1
and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS
register, so I use that instead.
VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.
The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.
The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.
On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 56 --
2 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..bcdf58b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -672,7 +672,6 @@ typedef struct drm_i915_private {
unsigned int lvds_border_bits;
/* Panel fitter placement and size for Ironlake+ */
u32 pch_pf_pos, pch_pf_size;
- int panel_t3, panel_t12;
struct drm_crtc *plane_to_crtc_mapping[2];
struct drm_crtc *pipe_to_crtc_mapping[2];
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 41b1e05..f1d6105 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -59,6 +59,8 @@ struct intel_dp {
bool is_pch_edp;
uint8_t train_set[4];
uint8_t link_status[DP_LINK_STATUS_SIZE];
+ int panel_power_up_delay;
+ int panel_power_down_delay;
};
/**
@@ -848,10 +850,6 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
* active PP sequence before enabling AUX VDD.
*/
pp_status = I915_READ(PCH_PP_STATUS);
- if (!(pp_status & PP_ON)) {
- DRM_DEBUG_KMS("eDP VDD was not on\n");
- msleep(dev_priv->panel_t3);
- }
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -861,7 +859,10 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
- msleep(1000);
+ if (!(pp_status & PP_ON)) {
+ msleep(intel_dp->panel_power_up_delay);
+ DRM_DEBUG_KMS("eDP VDD was not on\n");
+ }
}
static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -881,10 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
/* Make sure sequencer is idle before allowing subsequent activity */
- msleep(dev_priv->panel_t12);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
- msleep(1000);
+ msleep(intel_dp->panel_power_down_delay);
}
/* Returns true if the panel was already on when called */
@@ -922,8 +922,10 @@ static bool ironlake_edp_panel_on (struct intel_dp
*intel_dp)
return false;
}
-static void ironlake_edp_panel_off (struct drm_device *dev)
+static void ironlake_edp_panel_off(struct drm_encoder *encoder)
{
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp, idle_off_mask = PP_ON | PP_SEQUENCE_MASK |
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
@@ -940,6 +942,7 @@ static void ironlake_edp_pan
[PATCH 9/9] drm/i915: Disable eDP VDD in a delayed work proc instead of synchronously
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respected before trying to turn it back on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 93 +-
1 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5bc30f9..8130e82 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -62,6 +62,9 @@ struct intel_dp {
int panel_power_up_delay;
int panel_power_down_delay;
struct drm_display_mode *panel_fixed_mode; /* for eDP */
+ struct delayed_work panel_vdd_work;
+ bool panel_vdd_force;
+ unsigned long panel_off_jiffies;
};
/**
@@ -834,6 +837,23 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct
drm_display_mode *mode,
}
}
+static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
+{
+ unsigned long off_time;
+ unsigned long delay;
+ DRM_DEBUG_KMS("Wait for panel power off time\n");
+ off_time = intel_dp->panel_off_jiffies +
msecs_to_jiffies(intel_dp->panel_power_down_delay);
+ if (time_after(jiffies, off_time)) {
+ DRM_DEBUG_KMS("Time already passed");
+ return;
+ }
+ delay = jiffies_to_msecs(off_time - jiffies);
+ if (delay > intel_dp->panel_power_down_delay)
+ delay = intel_dp->panel_power_down_delay;
+ DRM_DEBUG_KMS("Waiting an additional %ld ms\n", delay);
+ msleep(delay);
+}
+
static void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp->base.base.dev;
@@ -843,13 +863,18 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
if (!is_edp(intel_dp))
return;
DRM_DEBUG_KMS("Turn eDP VDD on\n");
- /*
-* If the panel wasn't on, make sure there's not a currently
-* active PP sequence before enabling AUX VDD.
-*/
- pp_status = I915_READ(PCH_PP_STATUS);
+ WARN(intel_dp->panel_vdd_force,
+"eDP VDD already forced on\n");
+
+ intel_dp->panel_vdd_force = true;
pp = I915_READ(PCH_PP_CONTROL);
+ if (pp & EDP_FORCE_VDD) {
+ DRM_DEBUG_KMS("eDP VDD already on\n");
+ return;
+ }
+
+ ironlake_wait_panel_off(intel_dp);
pp &= ~PANEL_UNLOCK_MASK;
pp |= PANEL_UNLOCK_REGS;
pp |= EDP_FORCE_VDD;
@@ -857,21 +882,23 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
+
+ /*
+* If the panel wasn't on, delay before accessing aux channel
+*/
+ pp_status = I915_READ(PCH_PP_STATUS);
if (!(pp_status & PP_ON)) {
+ DRM_DEBUG_KMS("eDP was not running\n");
msleep(intel_dp->panel_power_up_delay);
- DRM_DEBUG_KMS("eDP VDD was not on\n");
}
}
-static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
+static void ironlake_panel_vdd_delayed_off(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp;
- if (!is_edp(intel_dp))
- return;
- DRM_DEBUG_KMS("Turn eDP VDD off\n");
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
pp |= PANEL_UNLOCK_REGS;
@@ -882,7 +909,37 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
/* Make sure sequencer is idle before allowing subsequent activity */
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
- msleep(intel_dp->panel_power_down_delay);
+ intel_dp->panel_off_jiffies = jiffies;
+}
+
+static void ironlake_panel_vdd_work(struct work_struct *__work)
+{
+ struct intel_dp *intel_dp = container_of(to_delayed_work(__work),
+struct intel_dp,
panel_vdd_work);
+ struct drm_device *dev = intel_dp->base.base.dev;
+
+ mutex_lock(&dev->struct_mutex);
+ if (!intel_dp->panel_vdd_force)
+ ironlake_panel_vdd_delayed_off(intel_dp);
+ mutex_unlock(&dev->struct_mutex);
+}
+
+static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
+{
+ if (!is_edp(intel_dp))
+ return;
+
+ DRM_DEBUG_KMS("Turn eDP VDD off %d\n", intel_dp->panel_vdd_force);
+ WARN(!intel_dp->panel_vdd_force, "eDP VDD not forced on");
[Bug 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #10 from Michal Suchanek 2011-09-19 15:36:08 PDT --- Created an attachment (id=51377) --> (https://bugs.freedesktop.org/attachment.cgi?id=51377) backtrace of glretrace backtrace of glretrace on older unpatched mesa -- 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 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 Michal Suchanek changed: What|Removed |Added Attachment #51377|text/x-log |text/plain mime type|| -- 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
[PULL] drm-intel-next
This is a single patch which cleans up almost all of the whitespace errors in the i915 driver. It currently merges cleanly with your fdo drm-core-next tree. I've checked this patch quite carefully, examining the .o files with objdump -s to make sure nothing significant changed. The only thing that found was a couple of debug messages which had blank space before newlines. The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linux 3.1-rc6 (2011-09-12 14:02:02 -0700) are available in the git repository at: git://people.freedesktop.org/~keithp/linux drm-intel-next Akshay Joshi (1): Drivers: i915: Fix all space related issues. drivers/gpu/drm/i915/dvo_ch7017.c |2 +- drivers/gpu/drm/i915/dvo_ch7xxx.c |4 +- drivers/gpu/drm/i915/dvo_ivch.c |6 +- drivers/gpu/drm/i915/dvo_sil164.c |2 +- drivers/gpu/drm/i915/dvo_tfp410.c | 14 +- drivers/gpu/drm/i915/i915_debugfs.c | 38 +- drivers/gpu/drm/i915/i915_dma.c | 44 ++-- drivers/gpu/drm/i915/i915_drv.c | 16 +- drivers/gpu/drm/i915/i915_drv.h | 70 ++-- drivers/gpu/drm/i915/i915_gem.c | 12 +- drivers/gpu/drm/i915/i915_gem_debug.c |2 +- drivers/gpu/drm/i915/i915_gem_evict.c |2 +- drivers/gpu/drm/i915/i915_irq.c |6 +- drivers/gpu/drm/i915/i915_mem.c | 14 +- drivers/gpu/drm/i915/i915_reg.h |8 +- drivers/gpu/drm/i915/i915_suspend.c |8 +- drivers/gpu/drm/i915/i915_trace.h | 46 ++-- drivers/gpu/drm/i915/intel_acpi.c |2 +- drivers/gpu/drm/i915/intel_bios.c |4 +- drivers/gpu/drm/i915/intel_bios.h |2 +- drivers/gpu/drm/i915/intel_crt.c|2 +- drivers/gpu/drm/i915/intel_display.c| 222 ++-- drivers/gpu/drm/i915/intel_dp.c | 26 +- drivers/gpu/drm/i915/intel_drv.h| 12 +- drivers/gpu/drm/i915/intel_opregion.c | 90 +++--- drivers/gpu/drm/i915/intel_overlay.c| 146 drivers/gpu/drm/i915/intel_panel.c |6 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 76 ++-- drivers/gpu/drm/i915/intel_ringbuffer.h |8 +- drivers/gpu/drm/i915/intel_sdvo.c | 228 +++--- drivers/gpu/drm/i915/intel_sdvo_regs.h | 558 +++--- drivers/gpu/drm/i915/intel_tv.c | 58 ++-- 32 files changed, 867 insertions(+), 867 deletions(-) -- keith.pack...@intel.com pgplgiKN0Lhl5.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/i915 git repository at freedesktop.org
I've created a (temporary?) git repository for the drm/i915 driver at git://people.freedesktop.org/~keithp/linux This has the drm-intel-next and drm-intel-fixes branches, and may also have occasional temporary branches with code which has not been merged yet. -- keith.pack...@intel.com pgp1wNikipeHi.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: FBC off for ironlake, otherwise on by default
Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for everything except Ironlake where it has been
seen to cause trouble with screen updates.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915/intel_display.c | 10 +-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ce045a8..f07e425 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -67,11 +67,11 @@ module_param_named(i915_enable_rc6, i915_enable_rc6, int,
0600);
MODULE_PARM_DESC(i915_enable_rc6,
"Enable power-saving render C-state 6 (default: true)");
-unsigned int i915_enable_fbc __read_mostly = 1;
+unsigned int i915_enable_fbc __read_mostly = -1;
module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600);
MODULE_PARM_DESC(i915_enable_fbc,
"Enable frame buffer compression for power savings "
- "(default: false)");
+ "(default: -1 (use per-chip default))");
unsigned int i915_lvds_downclock __read_mostly = 0;
module_param_named(lvds_downclock, i915_lvds_downclock, int, 0400);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9fb4a40..bc05deb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1799,6 +1799,7 @@ static void intel_update_fbc(struct drm_device *dev)
struct drm_framebuffer *fb;
struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj;
+ int enable_fbc;
DRM_DEBUG_KMS("\n");
@@ -1839,7 +1840,14 @@ static void intel_update_fbc(struct drm_device *dev)
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb->obj;
- if (!i915_enable_fbc) {
+ enable_fbc = i915_enable_fbc;
+ if (enable_fbc < 0) {
+ DRM_DEBUG_KMS("fbc set to per-chip default\n");
+ enable_fbc = 1;
+ if (INTEL_INFO(dev)->gen == 5)
+ enable_fbc = 0;
+ }
+ if (!enable_fbc) {
DRM_DEBUG_KMS("fbc disabled per module param (default off)\n");
dev_priv->no_fbc_reason = FBC_MODULE_PARAM;
goto out_disable;
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35861] [r300g] Oilrush: whiter triangle between center of the screen and horizon
https://bugs.freedesktop.org/show_bug.cgi?id=35861 --- Comment #3 from Pavel Ondračka 2011-09-19 00:05:34 PDT --- Created an attachment (id=51327) --> (https://bugs.freedesktop.org/attachment.cgi?id=51327) Oilrush output with RADEON_DEBUG=vp (In reply to comment #2) > Is this still an issue with the latest version from git, and if so can you > post > the output of RADEON_DEBUG=vp ? Yes, this is still an issue with latest mesa. Requested log attached. I can also make you an apitrace if you don't have access to the game. -- 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 34218] [r300g] Unigine: some surfaces are reflecting too much light
https://bugs.freedesktop.org/show_bug.cgi?id=34218 Pavel Ondračka changed: What|Removed |Added Summary|[r300g] Unigine Sanctuary: |[r300g] Unigine: some |some surfaces are |surfaces are reflecting too |reflecting too much light |much light --- Comment #10 from Pavel Ondračka 2011-09-19 00:06:43 PDT --- Unigine Oilrush is also affected. -- 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: Proposal for a low-level Linux display framework
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote: > On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen > wrote: > > > I think it's a bit more complex than that. True, there are MIPI > > standards, for the video there are DPI, DBI, DSI, and for the commands > > there is DCS. And, as you mentioned, many panels need custom > > initialization, or support only parts of the DCS, or have other > > quirks. > > So DSI is more like i2c than the DisplayPort aux channel or DDC. That Well, not quite. DSI is like DisplayPort and DisplayPort aux combined; there's only one bus, DSI, which is used to transfer video data and commands. For DSI video mode, the transfer is somewhat like traditional displays, and video data is send according to a pixel clock as a constant stream. However, before the video stream is enabled the bus can be used in bi-directional communication. And even when the video stream is enabled, there can be other communication in the blanking periods. For DSI command mode the transfer is a bit like high speed i2c; messages are sent when needed (when the userspace gives the command to update), without any strict timings. In practice this means that the peripheral needs to have a framebuffer memory of its own, which it uses to refresh the actual panel (or send the pixels forward to another peripheral). As the use patterns of these two types of displays are quite different, we have the terms auto-update and manual-update displays for them. > seems fine; you can create a DSI infrastructure like the i2c > infrastructure and then just have your display drivers use it to talk to > the panel. We might eventually end up with some shared DRM code to deal > with common DSI functions for display devices, like the EDID code > today, but that doesn't need to happen before you can write your first > DSI-using display driver. One difference with i2c and DSI is that i2c is independent of the video path, so it's easy to keep that separate from DRM. But for DSI the data is produced by the video hardware using the overlays, encoders etc. I don't quite see how we could have an i2c-like separate DSI API, which wasn't part of DRM. And even in simpler case MIPI DPI, which is a traditional parallel RGB interface, a panel may need custom configuration via, say, i2c or spi. We can, of course, create a i2c device driver for the panel, but how is that then connected to DRM? The i2c driver may need to know things like when the display is enabled/disabled, about backlight changes, or any other display related event. Is there a way for the i2c driver to get these events, and add new properties to the DRM (say, if the panel has a feature configured via i2c, but we'd like it to be visible to the userspace via the DRM driver)? Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Updated plane support v3
2011/6/21 Jesse Barnes : > This version adds both source and dest rect params to the set_plane > ioctl, and makes the source fixed point to support hardware that needs > it. > > I haven't changed the name of the SNB implementation yet (per Chris's > suggestions) but will before it gets upstream. > > I'd be interested to see whether these interfaces will work for other > hardware, so please take a close look at them and ideally implement them > on your hardware to make sure (see my userspace example code from > earlier posts if you want something to crib from). > > Thanks, > Jesse > Hi, Jesse. Could you have any posting plan for plane? Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29951] [r300g] xscreensaver hack "antspotlight" reveals something other than desktop
https://bugs.freedesktop.org/show_bug.cgi?id=29951 --- Comment #7 from Chris Rankin 2011-09-19 01:29:22 PDT --- (In reply to comment #6) > I just tested this with the latest version from git, and it appears to be > working. Can you confirm this? Sorry, it's not fixed yet. I ran antspotlight about 5 times in succession and the problem reoccurred. It did work the first few times, though. -- 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
[git pull] drm fixes
Hi Linus, Some fixes for page size mismatches in radeon, a lockdep noticed locking problem, and a fix to zero some memory that was being passed to userspace. Dave. The following changes since commit 003f6c9df54970d8b19578d195b3e2b398cdbde2: lib/sha1.c: quiet sparse noise about symbol not declared (2011-09-13 16:09:41 -0700) are available in the git repository at: git://people.freedesktop.org/~/linux.git drm-fixes Alex Deucher (2): drm/radeon/kms: fix typo in r100_blit_copy drm/radeon/kms: Make GPU/CPU page size handling consistent in blit code (v2) Ben Skeggs (1): drm/ttm: request zeroed system memory pages for new TT buffer objects Michel Dänzer (2): drm/radeon: Don't read from CP ring write pointer registers. drm/radeon: Unreference GEM object outside of spinlock in page flip error path. drivers/gpu/drm/radeon/evergreen.c | 14 -- drivers/gpu/drm/radeon/ni.c | 12 ++-- drivers/gpu/drm/radeon/r100.c | 22 ++ drivers/gpu/drm/radeon/r200.c |4 ++-- drivers/gpu/drm/radeon/r600.c | 14 -- drivers/gpu/drm/radeon/radeon.h |7 --- drivers/gpu/drm/radeon/radeon_asic.h|8 drivers/gpu/drm/radeon/radeon_display.c |2 +- drivers/gpu/drm/radeon/radeon_ttm.c |7 ++- drivers/gpu/drm/ttm/ttm_bo.c|3 ++- 10 files changed, 51 insertions(+), 42 deletions(-)___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41002] New: Switching doesn't work between plymouth and xorg.
https://bugs.freedesktop.org/show_bug.cgi?id=41002 Summary: Switching doesn't work between plymouth and xorg. Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: fabian.deut...@gmx.de When initiating a switch to the discrete card while plymouth is running, the switch doesn't happen completely in the small slot between the end of ply and Xorg's start. This happens with current Fedora 15 (all updates). Note: Maybe this is similar to bug #32970 -- 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 40935] radeon lockup on resume
https://bugs.freedesktop.org/show_bug.cgi?id=40935 --- Comment #4 from Michal Suchanek 2011-09-19 04:21:10 PDT --- It's a redwood. The bootup dmesg is below the locup messages. I am not sure what dev_err() would be. And now I rebooted and tried to kill Xorg with suspend and it would not lock up the card, only keep resetting it. -- 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] RFCv2: omapdrm DRM/KMS driver for TI OMAP platforms
On Mon, Sep 19, 2011 at 2:44 AM, Inki Dae wrote:
> Hello Rob.
>
> Is there some reason that you don't head your driver gpu/drm, just staging?
> and below is my short comments. thank you.
>
mainly because it is still a work-in-progress.. I expect some
re-shuffling of the mode-setting code when drm_plane support is added,
the plugin layer, etc. And perhaps at some point merging of the
omapdss and omapdrm layers.
I don't expect the ioctl ABI to change, and the driver is useful
as-is, but I still think there is enough changes that will happen that
staging is perhaps the better place for it to start life..
[snip]
>> +/* initialize connector */
>> +struct drm_connector * omap_connector_init(struct drm_device *dev,
>> + int connector_type, struct omap_dss_device *dssdev)
>> +{
>> + struct drm_connector *connector = NULL;
>> + struct omap_connector *omap_connector;
>> +
>> + DBG("%s", dssdev->name);
>> +
>> + omap_dss_get_device(dssdev);
>> +
>> + omap_connector = kzalloc(sizeof(struct omap_connector), GFP_KERNEL);
>> + if (!omap_connector) {
>> + dev_err(dev->dev, "could not allocate connector\n");
>> + goto fail;
>> + }
>> +
>> + omap_connector->dssdev = dssdev;
>> + connector = &omap_connector->base;
>> +
>> + drm_connector_init(dev, connector, &omap_connector_funcs,
>> + connector_type);
>> + drm_connector_helper_add(connector, &omap_connector_helper_funcs);
>> +
>> +#if 0 /* enable when dss2 supports hotplug */
>> + if (dssdev->caps & OMAP_DSS_DISPLAY_CAP_HPD)
>> + connector->polled = 0;
>> + else
>> +#endif
>
> How about removing the codes above until dss2 supports hotplug?
>
easier not to forget about them this way ;-)
if someone has a strong opinion, I can remove them.. but I guess it
should be not too distant future when support lands in dss2.. I guess
I should put a note in the TODO about re-enabling hotplug code
>> + connector->polled = DRM_CONNECTOR_POLL_CONNECT |
>> + DRM_CONNECTOR_POLL_DISCONNECT;
>> +
>> + connector->interlace_allowed = 1;
>> + connector->doublescan_allowed = 0;
>> +
>> + drm_sysfs_connector_add(connector);
>> +
>> + return connector;
>> +
>> +fail:
>> + if (connector) {
>> + omap_connector_destroy(connector);
>> + }
>> +
>> + return NULL;
>> +}
[snip]
>> +static void omap_crtc_dpms(struct drm_crtc *crtc, int mode)
>> +{
>> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> +
>> + DBG("%s: %d", omap_crtc->ovl->name, mode);
>> +
>> + if (mode == DRM_MODE_DPMS_ON) {
>> + update_scanout(crtc);
>
> Is there any reason that update_scanout function should be called here to
> update buffer address.? I think it's enough to call this function at
> mode_set callback.
In theory it should not be needed.. IIRC at some point I was hitting
some problem that the buffer address wasn't set yet, but that was w/
older version of the driver, older kernel, and different xorg driver..
>> + omap_crtc->info.enabled = true;
>> + } else {
>> + omap_crtc->info.enabled = false;
>> + }
>> +
>> + commit(crtc);
>
> and commit callback to apply those data on hw.
>
>> +}
>> +
[snip]
>> +
>> +/**
>> + * load - setup chip and create an initial config
>> + * @dev: DRM device
>> + * @flags: startup flags
>> + *
>> + * The driver load routine has to do several things:
>> + * - initialize the memory manager
>> + * - allocate initial config memory
>> + * - setup the DRM framebuffer with the allocated memory
>> + */
>> +static int dev_load(struct drm_device *dev, unsigned long flags)
>> +{
>> + struct omap_drm_private *priv;
>> + int ret;
>> +
>> + DBG("load: dev=%p", dev);
>> +
>> + drm_device = dev;
>> +
>> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>> + if (!priv) {
>> + dev_err(dev->dev, "could not allocate priv\n");
>> + return -1;
>> + }
>> +
>> + dev->dev_private = priv;
>> +
>> + ret = omap_modeset_init(dev);
>> + if (ret) {
>> + dev_err(dev->dev, "omap_modeset_init failed: ret=%d\n",
> ret);
>> + // hmm
>> + //return ret;
>
> Doesn't it need return? you output error message using dev_err().
Well.. currently omap_modeset_init() never returns !=0
I'm still a bit undecided on some of the error cases.. for example if
we don't successfully initialize everything, but do at least have >1
of each crtc/encoder/connector, maybe it makes sense to continue in
some reduced capacity..
But "check error handling/cleanup paths" is still in the TODO file ;-)
>> + }
>> +
>> + priv->fbdev = omap_fbdev_init(dev);
>> + if (!priv->fbdev) {
>> + dev_err(dev->dev, "omap_fbdev_init failed\n");
>> + ret = -ENOMEM;
>> + // hmm
>> + //return ret;
>
> Ditto. and also you would have to rele
[Bug 41002] Switching doesn't work between plymouth and xorg. (vgaswitcheroo)
https://bugs.freedesktop.org/show_bug.cgi?id=41002 Fabian Deutsch changed: What|Removed |Added Summary|Switching doesn't work |Switching doesn't work |between plymouth and xorg. |between plymouth and xorg. ||(vgaswitcheroo) -- 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 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #7 from Michal Suchanek 2011-09-19 09:39:58 PDT --- According to apitrace author the glretrace crash is due to gallium reading more data than is in the buffer. https://github.com/apitrace/apitrace/issues/39#issuecomment-2134199 -- 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 41019] New: DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 Summary: DPMS doesn't work correctly Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: General AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: nissa...@gmail.com Created an attachment (id=51369) --> (https://bugs.freedesktop.org/attachment.cgi?id=51369) dmesg output Monitor will keep constantly switching off/on when entering power saving mode: - LCD going black - OSD message "Entering power saving mode" - LCD turns off, then immediately goes back on and the cycle repeats This bug was previously reported on other list and should be fixed but unfortunately it's still present on my system. - Gentoo/AMD64 - kernel 3.1.0-rc6-00120 (linus + drm-fixes) - xorg 1.11.0/1.10.4 - Radeon 6850 (+internal card disabled) - Dell U2410 I'm not sure if this is relevant but the same effect can be observed on every power mode, i.e. xset dpms force standby/suspend/off. -- 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 41019] DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 --- Comment #1 from Wojciech Pyczak 2011-09-19 11:56:00 PDT --- Created an attachment (id=51370) --> (https://bugs.freedesktop.org/attachment.cgi?id=51370) 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 41019] DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 Alex Deucher changed: What|Removed |Added Attachment #51369|text/x-log |text/plain mime type|| Attachment #51369|0 |1 is patch|| -- 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 28847] Regnum Online: shader backend not rendering
https://bugs.freedesktop.org/show_bug.cgi?id=28847 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Sven Arvidsson 2011-09-19 12:05:02 PDT --- (In reply to comment #8) > Is this still an issue with the latest mesa from git? The game is still busted, but this is not specific to r300g but a problem with the GLSL compiler. There's already bug 28138 open about this, but that's filed against i965 and Intel is making some progress there, but only on their own backend. It's probably easier to close this report and file a new one against Mesa core to keep things simple. -- 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 41019] DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Alex Deucher 2011-09-19 12:05:11 PDT --- *** This bug has been marked as a duplicate of bug 40851 *** -- 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 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #8 from Marek Olšák 2011-09-19 12:44:51 PDT --- Created an attachment (id=51371) View: https://bugs.freedesktop.org/attachment.cgi?id=51371 Review: https://bugs.freedesktop.org/review?bug=39320&attachment=51371 print debug info I think it crashes because offset >= upload->buffer->width0. Could you apply the attached patch and post the output of stderr? -- 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 1/2] drm/radeon: add tracepoint for setting mode clocks.
From: Dave Airlie
This just adds a tracepoint that can be caught in perf for when the clocks
change.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_pm.c|3 +++
drivers/gpu/drm/radeon/radeon_trace.h | 18 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 6fabe89..2a44332 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include "radeon_trace.h"
#define RADEON_IDLE_LOOP_MS 100
#define RADEON_RECLOCK_DELAY_MS 200
@@ -165,6 +166,8 @@ static void radeon_set_power_state(struct radeon_device
*rdev)
(rdev->pm.requested_power_state_index ==
rdev->pm.current_power_state_index))
return;
+ trace_radeon_set_power_state(rdev);
+
if (radeon_gui_idle(rdev)) {
sclk =
rdev->pm.power_state[rdev->pm.requested_power_state_index].
clock_info[rdev->pm.requested_clock_mode_index].sclk;
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h
b/drivers/gpu/drm/radeon/radeon_trace.h
index eafd816..ef0fd05 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -27,6 +27,24 @@ TRACE_EVENT(radeon_bo_create,
TP_printk("bo=%p, pages=%u", __entry->bo, __entry->pages)
);
+TRACE_EVENT(radeon_set_power_state,
+TP_PROTO(struct radeon_device *rdev),
+TP_ARGS(rdev),
+ TP_STRUCT__entry(
+__field(int, requested_clock_mode)
+__field(int, current_clock_mode)
+__field(int, requested_power_state)
+__field(int, current_power_state)
+ ),
+ TP_fast_assign(
+ __entry->requested_clock_mode =
rdev->pm.requested_clock_mode_index;
+ __entry->current_clock_mode =
rdev->pm.current_clock_mode_index;
+ __entry->requested_power_state =
rdev->pm.requested_power_state_index;
+ __entry->current_power_state =
rdev->pm.current_power_state_index;
+ ),
+ TP_printk("clock %d->%d, power %d->%d",
__entry->current_clock_mode, __entry->requested_clock_mode,
__entry->current_power_state, __entry->requested_power_state)
+);
+
DECLARE_EVENT_CLASS(radeon_fence_request,
TP_PROTO(struct drm_device *dev, u32 seqno),
--
1.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: make pm method file show default + option.
From: Dave Airlie If we add more options in the future this will need rework. this is modelled after the example in /sys/power/disk. Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/radeon_pm.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 2a44332..25bc75e 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -390,9 +390,13 @@ static ssize_t radeon_get_pm_method(struct device *dev, struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev)); struct radeon_device *rdev = ddev->dev_private; int pm = rdev->pm.pm_method; + char *start = buf; - return snprintf(buf, PAGE_SIZE, "%s\n", - (pm == PM_METHOD_DYNPM) ? "dynpm" : "profile"); + if (pm == PM_METHOD_DYNPM) + buf += snprintf(buf, PAGE_SIZE, "[dynpm] profile\n"); + else + buf += snprintf(buf, PAGE_SIZE, "dynpm [profile]\n"); + return buf - start; } static ssize_t radeon_set_pm_method(struct device *dev, -- 1.7.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #9 from Michal Suchanek 2011-09-19 14:52:19 PDT --- I get this extra output: u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_upload_alloc:194: min_out_offset = 4294966000, size = 1296, alloc_size = 1296, alloc_offset = 4294966000, upload->offset = 322528, upload->size = 1048576, upload->buffer->width0 = 1048576, offset = 4294966000 util/u_upload_mgr.c:195:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed. -- 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
drm/i915: eDP cleanup patch series -- fixes SNB MacBook Air
Here's a sequence of eDP patches which are necessary to make the driver work on the Sandybridge MacBook Air The key trick was to make sure that the eDP power was applied before trying to communicate with the device. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/i915: Enable digital port hotplug on PCH systems
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 542453f..b7fbb74 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2903,12 +2903,13 @@
#define SDEIER 0xc400c
/* digital port hotplug */
-#define PCH_PORT_HOTPLUG0xc4030
+#define PCH_PORT_HOTPLUG0xc4030/* SHOTPLUG_CTL */
#define PORTD_HOTPLUG_ENABLE(1 << 20)
#define PORTD_PULSE_DURATION_2ms(0)
#define PORTD_PULSE_DURATION_4_5ms (1 << 18)
#define PORTD_PULSE_DURATION_6ms(2 << 18)
#define PORTD_PULSE_DURATION_100ms (3 << 18)
+#define PORTD_PULSE_DURATION_MASK (3 << 18)
#define PORTD_HOTPLUG_NO_DETECT (0)
#define PORTD_HOTPLUG_SHORT_DETECT (1 << 16)
#define PORTD_HOTPLUG_LONG_DETECT (1 << 17)
@@ -2917,6 +2918,7 @@
#define PORTC_PULSE_DURATION_4_5ms (1 << 10)
#define PORTC_PULSE_DURATION_6ms(2 << 10)
#define PORTC_PULSE_DURATION_100ms (3 << 10)
+#define PORTC_PULSE_DURATION_MASK (3 << 10)
#define PORTC_HOTPLUG_NO_DETECT (0)
#define PORTC_HOTPLUG_SHORT_DETECT (1 << 8)
#define PORTC_HOTPLUG_LONG_DETECT (1 << 9)
@@ -2925,6 +2927,7 @@
#define PORTB_PULSE_DURATION_4_5ms (1 << 2)
#define PORTB_PULSE_DURATION_6ms(2 << 2)
#define PORTB_PULSE_DURATION_100ms (3 << 2)
+#define PORTB_PULSE_DURATION_MASK (3 << 2)
#define PORTB_HOTPLUG_NO_DETECT (0)
#define PORTB_HOTPLUG_SHORT_DETECT (1 << 0)
#define PORTB_HOTPLUG_LONG_DETECT (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9fb4a40..54403dd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7151,6 +7151,18 @@ static void intel_setup_outputs(struct drm_device *dev)
I915_WRITE(PFIT_CONTROL, 0);
}
+ /* Enable digital port hotplug detect on PCH hardware */
+ if (HAS_PCH_SPLIT(dev)) {
+ u32 hotplug;
+
+ hotplug = I915_READ(PCH_PORT_HOTPLUG);
+ hotplug &=
~(PORTD_PULSE_DURATION_MASK|PORTC_PULSE_DURATION_MASK|PORTB_PULSE_DURATION_MASK);
+ hotplug |= PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_2ms;
+ hotplug |= PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_2ms;
+ hotplug |= PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_2ms;
+ I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
+ }
+
if (HAS_PCH_SPLIT(dev)) {
dpd_is_edp = intel_dpd_is_edp(dev);
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/i915: Remove extra 300ms delay during eDP mode setting
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..f0cfb6b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -903,13 +903,6 @@ static void ironlake_edp_backlight_on (struct drm_device
*dev)
u32 pp;
DRM_DEBUG_KMS("\n");
- /*
-* If we enable the backlight right away following a panel power
-* on, we may see slight flicker as the panel syncs with the eDP
-* link. So delay a bit to make sure the image is solid before
-* allowing it to appear.
-*/
- msleep(300);
pp = I915_READ(PCH_PP_CONTROL);
pp |= EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/i915: Only use VBT panel mode on eDP if no EDID is found
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f0cfb6b..8ab2a88 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1748,7 +1748,16 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
/* if eDP has no EDID, try to use fixed panel mode from VBT */
if (is_edp(intel_dp)) {
- if (dev_priv->panel_fixed_mode != NULL) {
+ /* initialize panel mode from VBT if available for eDP */
+ if (dev_priv->panel_fixed_mode == NULL &&
dev_priv->lfp_lvds_vbt_mode != NULL) {
+ dev_priv->panel_fixed_mode =
+ drm_mode_duplicate(dev,
dev_priv->lfp_lvds_vbt_mode);
+ if (dev_priv->panel_fixed_mode) {
+ dev_priv->panel_fixed_mode->type |=
+ DRM_MODE_TYPE_PREFERRED;
+ }
+ }
+ if (dev_priv->panel_fixed_mode) {
struct drm_display_mode *mode;
mode = drm_mode_duplicate(dev,
dev_priv->panel_fixed_mode);
drm_mode_probed_add(connector, mode);
@@ -2061,15 +2070,6 @@ intel_dp_init(struct drm_device *dev, int output_reg)
intel_encoder->hot_plug = intel_dp_hot_plug;
if (is_edp(intel_dp)) {
- /* initialize panel mode from VBT if available for eDP */
- if (dev_priv->lfp_lvds_vbt_mode) {
- dev_priv->panel_fixed_mode =
- drm_mode_duplicate(dev,
dev_priv->lfp_lvds_vbt_mode);
- if (dev_priv->panel_fixed_mode) {
- dev_priv->panel_fixed_mode->type |=
- DRM_MODE_TYPE_PREFERRED;
- }
- }
dev_priv->int_edp_connector = connector;
intel_panel_setup_backlight(dev);
}
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/i915: Check eDP power when doing aux channel communications
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8ab2a88..3b29a6f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -279,6 +279,24 @@ intel_hrawclk(struct drm_device *dev)
}
}
+static void
+intel_dp_check_edp(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 pp_status, pp_control;
+ if (!is_edp(intel_dp))
+ return;
+ pp_status = I915_READ(PCH_PP_STATUS);
+ pp_control = I915_READ(PCH_PP_CONTROL);
+ if ((pp_status & PP_ON) == 0 && (pp_control & EDP_FORCE_VDD) == 0) {
+ WARN(1, "eDP powered off while attempting aux channel
communication.\n");
+ DRM_DEBUG_KMS("Status 0x%08x Control 0x%08x\n",
+ pp_status,
+ I915_READ(PCH_PP_CONTROL));
+ }
+}
+
static int
intel_dp_aux_ch(struct intel_dp *intel_dp,
uint8_t *send, int send_bytes,
@@ -295,6 +313,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
uint32_t aux_clock_divider;
int try, precharge;
+ intel_dp_check_edp(intel_dp);
/* The clock divider is based off the hrawclk,
* and would like to run at 2MHz. So, take the
* hrawclk value and divide by 2 and use that
@@ -408,6 +427,7 @@ intel_dp_aux_native_write(struct intel_dp *intel_dp,
int msg_bytes;
uint8_t ack;
+ intel_dp_check_edp(intel_dp);
if (send_bytes > 16)
return -1;
msg[0] = AUX_NATIVE_WRITE << 4;
@@ -450,6 +470,7 @@ intel_dp_aux_native_read(struct intel_dp *intel_dp,
uint8_t ack;
int ret;
+ intel_dp_check_edp(intel_dp);
msg[0] = AUX_NATIVE_READ << 4;
msg[1] = address >> 8;
msg[2] = address & 0xff;
@@ -493,6 +514,7 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
int reply_bytes;
int ret;
+ intel_dp_check_edp(intel_dp);
/* Set up the command byte */
if (mode & MODE_I2C_READ)
msg[0] = AUX_I2C_READ << 4;
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/i915: Unlock PCH_PP_CONTROL always
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b7fbb74..5596e8e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3311,6 +3311,7 @@
#define PCH_PP_STATUS 0xc7200
#define PCH_PP_CONTROL 0xc7204
#define PANEL_UNLOCK_REGS (0xabcd << 16)
+#define PANEL_UNLOCK_MASK (0x << 16)
#define EDP_FORCE_VDD (1 << 3)
#define EDP_BLC_ENABLE(1 << 2)
#define PANEL_POWER_RESET (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3b29a6f..a983d0f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -840,6 +840,8 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
msleep(dev_priv->panel_t3);
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp |= EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -852,6 +854,8 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
u32 pp;
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp &= ~EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -871,13 +875,15 @@ static bool ironlake_edp_panel_on (struct intel_dp
*intel_dp)
return true;
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
/* ILK workaround: disable reset around power sequence */
pp &= ~PANEL_POWER_RESET;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
- pp |= PANEL_UNLOCK_REGS | POWER_TARGET_ON;
+ pp |= POWER_TARGET_ON;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -900,6 +906,8 @@ static void ironlake_edp_panel_off (struct drm_device *dev)
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
/* ILK workaround: disable reset around power sequence */
pp &= ~PANEL_POWER_RESET;
@@ -926,6 +934,8 @@ static void ironlake_edp_backlight_on (struct drm_device
*dev)
DRM_DEBUG_KMS("\n");
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp |= EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
}
@@ -937,6 +947,8 @@ static void ironlake_edp_backlight_off (struct drm_device
*dev)
DRM_DEBUG_KMS("\n");
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp &= ~EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
}
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/i915: Move eDP panel fixed mode from dev_priv to intel_dp
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bcdf58b..e6dd19e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -347,7 +347,6 @@ typedef struct drm_i915_private {
/* LVDS info */
int backlight_level; /* restore backlight to this value */
bool backlight_enabled;
- struct drm_display_mode *panel_fixed_mode;
struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1d6105..5bc30f9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -61,6 +61,7 @@ struct intel_dp {
uint8_t link_status[DP_LINK_STATUS_SIZE];
int panel_power_up_delay;
int panel_power_down_delay;
+ struct drm_display_mode *panel_fixed_mode; /* for eDP */
};
/**
@@ -202,16 +203,14 @@ intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
- struct drm_device *dev = connector->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
int max_link_clock =
intel_dp_link_clock(intel_dp_max_link_bw(intel_dp));
int max_lanes = intel_dp_max_lane_count(intel_dp);
- if (is_edp(intel_dp) && dev_priv->panel_fixed_mode) {
- if (mode->hdisplay > dev_priv->panel_fixed_mode->hdisplay)
+ if (is_edp(intel_dp) && intel_dp->panel_fixed_mode) {
+ if (mode->hdisplay > intel_dp->panel_fixed_mode->hdisplay)
return MODE_PANEL;
- if (mode->vdisplay > dev_priv->panel_fixed_mode->vdisplay)
+ if (mode->vdisplay > intel_dp->panel_fixed_mode->vdisplay)
return MODE_PANEL;
}
@@ -630,22 +629,21 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_device *dev = encoder->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
int lane_count, clock;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 :
0;
static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
- if (is_edp(intel_dp) && dev_priv->panel_fixed_mode) {
- intel_fixed_panel_mode(dev_priv->panel_fixed_mode,
adjusted_mode);
+ if (is_edp(intel_dp) && intel_dp->panel_fixed_mode) {
+ intel_fixed_panel_mode(intel_dp->panel_fixed_mode,
adjusted_mode);
intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
mode, adjusted_mode);
/*
* the mode->clock is used to calculate the Data&Link M/N
* of the pipe. For the eDP the fixed clock should be used.
*/
- mode->clock = dev_priv->panel_fixed_mode->clock;
+ mode->clock = intel_dp->panel_fixed_mode->clock;
}
for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
@@ -1812,35 +1810,34 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
ret = intel_dp_get_edid_modes(connector, &intel_dp->adapter);
if (ret) {
- if (is_edp(intel_dp) && !dev_priv->panel_fixed_mode) {
+ if (is_edp(intel_dp) && !intel_dp->panel_fixed_mode) {
struct drm_display_mode *newmode;
list_for_each_entry(newmode, &connector->probed_modes,
head) {
- if (newmode->type & DRM_MODE_TYPE_PREFERRED) {
- dev_priv->panel_fixed_mode =
+ if ((newmode->type & DRM_MODE_TYPE_PREFERRED)) {
+ intel_dp->panel_fixed_mode =
drm_mode_duplicate(dev,
newmode);
break;
}
}
}
-
return ret;
}
/* if eDP has no EDID, try to use fixed panel mode from VBT */
if (is_edp(intel_dp)) {
/* initialize panel mode from VBT if available for eDP */
- if (dev_priv->panel_fixed_mode == NULL &&
dev_priv->lfp_lvds_vbt_mode != NULL) {
-
[PATCH 6/9] drm/i915: Make sure eDP power is on before using aux channel
The eDP panel may not be able to respond to aux channel communications
unless it has power supplied. During mode setting, power may be
cut-off during panel power sequencing. Make sure that any aux channel
communications will work by forcing vdd power active as needed.
This also delays after turning power on and off to ensure that the
panel is keeping up.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 84 +-
1 files changed, 64 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a983d0f..41b1e05 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -595,10 +595,15 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
return -EREMOTEIO;
}
+static void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp);
+static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp);
+
static int
intel_dp_i2c_init(struct intel_dp *intel_dp,
struct intel_connector *intel_connector, const char *name)
{
+ int ret;
+
DRM_DEBUG_KMS("i2c_init %s\n", name);
intel_dp->algo.running = false;
intel_dp->algo.address = 0;
@@ -612,7 +617,10 @@ intel_dp_i2c_init(struct intel_dp *intel_dp,
intel_dp->adapter.algo_data = &intel_dp->algo;
intel_dp->adapter.dev.parent = &intel_connector->base.kdev;
- return i2c_dp_aux_add_bus(&intel_dp->adapter);
+ ironlake_edp_panel_vdd_on(intel_dp);
+ ret = i2c_dp_aux_add_bus(&intel_dp->adapter);
+ ironlake_edp_panel_vdd_off(intel_dp);
+ return ret;
}
static bool
@@ -830,14 +838,20 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
{
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- u32 pp;
+ u32 pp, pp_status;
+ if (!is_edp(intel_dp))
+ return;
+ DRM_DEBUG_KMS("Turn eDP VDD on\n");
/*
* If the panel wasn't on, make sure there's not a currently
* active PP sequence before enabling AUX VDD.
*/
- if (!(I915_READ(PCH_PP_STATUS) & PP_ON))
+ pp_status = I915_READ(PCH_PP_STATUS);
+ if (!(pp_status & PP_ON)) {
+ DRM_DEBUG_KMS("eDP VDD was not on\n");
msleep(dev_priv->panel_t3);
+ }
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -845,6 +859,9 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
pp |= EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
+ DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
+ I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
+ msleep(1000);
}
static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -853,6 +870,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp;
+ if (!is_edp(intel_dp))
+ return;
+ DRM_DEBUG_KMS("Turn eDP VDD off\n");
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
pp |= PANEL_UNLOCK_REGS;
@@ -862,6 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
/* Make sure sequencer is idle before allowing subsequent activity */
msleep(dev_priv->panel_t12);
+ DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
+ I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
+ msleep(1000);
}
/* Returns true if the panel was already on when called */
@@ -1016,7 +1039,9 @@ static void intel_dp_prepare(struct drm_encoder *encoder)
struct drm_device *dev = encoder->dev;
/* Wake up the sink first */
+ ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ ironlake_edp_panel_vdd_off(intel_dp);
if (is_edp(intel_dp)) {
ironlake_edp_backlight_off(dev);
@@ -1034,21 +1059,17 @@ static void intel_dp_commit(struct drm_encoder *encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct drm_device *dev = encoder->dev;
- if (is_edp(intel_dp))
- ironlake_edp_panel_vdd_on(intel_dp);
-
+ ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_start_link_train(intel_dp);
- if (is_edp(intel_dp)) {
+ if (is_edp(intel_dp))
ironlake_edp_panel_on(intel_dp);
- ironlake_edp_panel_vdd_off(intel_dp);
- }
intel_dp_complete_link_train(intel_dp);
if (is_edp(intel_dp))
ironlake_edp_backlight_on(dev);
-
+ ironlake_edp_panel_vdd_off(intel_dp);
intel_dp->dpms_mode = DRM_MODE_DPMS_ON;
}
@@ -1060,6 +1081,7 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
struct
[PATCH 7/9] drm/i915: Correct eDP panel power sequencing delay computations
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum of the two
delays, to make sure things work reliably. If there is no VBT data,
then those values will be initialized to zero, so we'll just use the
values as programmed in the hardware.
This patch computes power-up and power-down delays, rather than using
portions of the appropriate delay values as found in the hardware. The
eDP specified delay between raising VCC and communicating over the aux
channel includes both the power rise time (T1) and the aux channel
communication delay (T3). The eDP specified delay between powering
down the device and powering it back up includes both the power fall
time (T11) and the device idle time (T12).
>From the hardware, I'm taking the T3 value from the PP_OFF_DELAYS
Power_Down_delay value, which is actually documented to be the 'T3
time sequence' value used 'during power up'. There aren't separate T1
and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS
register, so I use that instead.
VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.
The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.
The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.
On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 56 --
2 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..bcdf58b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -672,7 +672,6 @@ typedef struct drm_i915_private {
unsigned int lvds_border_bits;
/* Panel fitter placement and size for Ironlake+ */
u32 pch_pf_pos, pch_pf_size;
- int panel_t3, panel_t12;
struct drm_crtc *plane_to_crtc_mapping[2];
struct drm_crtc *pipe_to_crtc_mapping[2];
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 41b1e05..f1d6105 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -59,6 +59,8 @@ struct intel_dp {
bool is_pch_edp;
uint8_t train_set[4];
uint8_t link_status[DP_LINK_STATUS_SIZE];
+ int panel_power_up_delay;
+ int panel_power_down_delay;
};
/**
@@ -848,10 +850,6 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
* active PP sequence before enabling AUX VDD.
*/
pp_status = I915_READ(PCH_PP_STATUS);
- if (!(pp_status & PP_ON)) {
- DRM_DEBUG_KMS("eDP VDD was not on\n");
- msleep(dev_priv->panel_t3);
- }
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -861,7 +859,10 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
- msleep(1000);
+ if (!(pp_status & PP_ON)) {
+ msleep(intel_dp->panel_power_up_delay);
+ DRM_DEBUG_KMS("eDP VDD was not on\n");
+ }
}
static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -881,10 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
/* Make sure sequencer is idle before allowing subsequent activity */
- msleep(dev_priv->panel_t12);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
- msleep(1000);
+ msleep(intel_dp->panel_power_down_delay);
}
/* Returns true if the panel was already on when called */
@@ -922,8 +922,10 @@ static bool ironlake_edp_panel_on (struct intel_dp
*intel_dp)
return false;
}
-static void ironlake_edp_panel_off (struct drm_device *dev)
+static void ironlake_edp_panel_off(struct drm_encoder *encoder)
{
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp, idle_off_mask = PP_ON | PP_SEQUENCE_MASK |
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
@@ -940,6 +942,7 @@ static void ironlake_edp_pan
[PATCH 9/9] drm/i915: Disable eDP VDD in a delayed work proc instead of synchronously
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respected before trying to turn it back on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 93 +-
1 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5bc30f9..8130e82 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -62,6 +62,9 @@ struct intel_dp {
int panel_power_up_delay;
int panel_power_down_delay;
struct drm_display_mode *panel_fixed_mode; /* for eDP */
+ struct delayed_work panel_vdd_work;
+ bool panel_vdd_force;
+ unsigned long panel_off_jiffies;
};
/**
@@ -834,6 +837,23 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct
drm_display_mode *mode,
}
}
+static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
+{
+ unsigned long off_time;
+ unsigned long delay;
+ DRM_DEBUG_KMS("Wait for panel power off time\n");
+ off_time = intel_dp->panel_off_jiffies +
msecs_to_jiffies(intel_dp->panel_power_down_delay);
+ if (time_after(jiffies, off_time)) {
+ DRM_DEBUG_KMS("Time already passed");
+ return;
+ }
+ delay = jiffies_to_msecs(off_time - jiffies);
+ if (delay > intel_dp->panel_power_down_delay)
+ delay = intel_dp->panel_power_down_delay;
+ DRM_DEBUG_KMS("Waiting an additional %ld ms\n", delay);
+ msleep(delay);
+}
+
static void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp->base.base.dev;
@@ -843,13 +863,18 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
if (!is_edp(intel_dp))
return;
DRM_DEBUG_KMS("Turn eDP VDD on\n");
- /*
-* If the panel wasn't on, make sure there's not a currently
-* active PP sequence before enabling AUX VDD.
-*/
- pp_status = I915_READ(PCH_PP_STATUS);
+ WARN(intel_dp->panel_vdd_force,
+"eDP VDD already forced on\n");
+
+ intel_dp->panel_vdd_force = true;
pp = I915_READ(PCH_PP_CONTROL);
+ if (pp & EDP_FORCE_VDD) {
+ DRM_DEBUG_KMS("eDP VDD already on\n");
+ return;
+ }
+
+ ironlake_wait_panel_off(intel_dp);
pp &= ~PANEL_UNLOCK_MASK;
pp |= PANEL_UNLOCK_REGS;
pp |= EDP_FORCE_VDD;
@@ -857,21 +882,23 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
+
+ /*
+* If the panel wasn't on, delay before accessing aux channel
+*/
+ pp_status = I915_READ(PCH_PP_STATUS);
if (!(pp_status & PP_ON)) {
+ DRM_DEBUG_KMS("eDP was not running\n");
msleep(intel_dp->panel_power_up_delay);
- DRM_DEBUG_KMS("eDP VDD was not on\n");
}
}
-static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
+static void ironlake_panel_vdd_delayed_off(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp;
- if (!is_edp(intel_dp))
- return;
- DRM_DEBUG_KMS("Turn eDP VDD off\n");
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
pp |= PANEL_UNLOCK_REGS;
@@ -882,7 +909,37 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
/* Make sure sequencer is idle before allowing subsequent activity */
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
- msleep(intel_dp->panel_power_down_delay);
+ intel_dp->panel_off_jiffies = jiffies;
+}
+
+static void ironlake_panel_vdd_work(struct work_struct *__work)
+{
+ struct intel_dp *intel_dp = container_of(to_delayed_work(__work),
+struct intel_dp,
panel_vdd_work);
+ struct drm_device *dev = intel_dp->base.base.dev;
+
+ mutex_lock(&dev->struct_mutex);
+ if (!intel_dp->panel_vdd_force)
+ ironlake_panel_vdd_delayed_off(intel_dp);
+ mutex_unlock(&dev->struct_mutex);
+}
+
+static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
+{
+ if (!is_edp(intel_dp))
+ return;
+
+ DRM_DEBUG_KMS("Turn eDP VDD off %d\n", intel_dp->panel_vdd_force);
+ WARN(!intel_dp->panel_vdd_force, "eDP VDD not forced on");
[Bug 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #10 from Michal Suchanek 2011-09-19 15:36:08 PDT --- Created an attachment (id=51377) --> (https://bugs.freedesktop.org/attachment.cgi?id=51377) backtrace of glretrace backtrace of glretrace on older unpatched mesa -- 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 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 Michal Suchanek changed: What|Removed |Added Attachment #51377|text/x-log |text/plain mime type|| -- 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
[PULL] drm-intel-next
This is a single patch which cleans up almost all of the whitespace errors in the i915 driver. It currently merges cleanly with your fdo drm-core-next tree. I've checked this patch quite carefully, examining the .o files with objdump -s to make sure nothing significant changed. The only thing that found was a couple of debug messages which had blank space before newlines. The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linux 3.1-rc6 (2011-09-12 14:02:02 -0700) are available in the git repository at: git://people.freedesktop.org/~keithp/linux drm-intel-next Akshay Joshi (1): Drivers: i915: Fix all space related issues. drivers/gpu/drm/i915/dvo_ch7017.c |2 +- drivers/gpu/drm/i915/dvo_ch7xxx.c |4 +- drivers/gpu/drm/i915/dvo_ivch.c |6 +- drivers/gpu/drm/i915/dvo_sil164.c |2 +- drivers/gpu/drm/i915/dvo_tfp410.c | 14 +- drivers/gpu/drm/i915/i915_debugfs.c | 38 +- drivers/gpu/drm/i915/i915_dma.c | 44 ++-- drivers/gpu/drm/i915/i915_drv.c | 16 +- drivers/gpu/drm/i915/i915_drv.h | 70 ++-- drivers/gpu/drm/i915/i915_gem.c | 12 +- drivers/gpu/drm/i915/i915_gem_debug.c |2 +- drivers/gpu/drm/i915/i915_gem_evict.c |2 +- drivers/gpu/drm/i915/i915_irq.c |6 +- drivers/gpu/drm/i915/i915_mem.c | 14 +- drivers/gpu/drm/i915/i915_reg.h |8 +- drivers/gpu/drm/i915/i915_suspend.c |8 +- drivers/gpu/drm/i915/i915_trace.h | 46 ++-- drivers/gpu/drm/i915/intel_acpi.c |2 +- drivers/gpu/drm/i915/intel_bios.c |4 +- drivers/gpu/drm/i915/intel_bios.h |2 +- drivers/gpu/drm/i915/intel_crt.c|2 +- drivers/gpu/drm/i915/intel_display.c| 222 ++-- drivers/gpu/drm/i915/intel_dp.c | 26 +- drivers/gpu/drm/i915/intel_drv.h| 12 +- drivers/gpu/drm/i915/intel_opregion.c | 90 +++--- drivers/gpu/drm/i915/intel_overlay.c| 146 drivers/gpu/drm/i915/intel_panel.c |6 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 76 ++-- drivers/gpu/drm/i915/intel_ringbuffer.h |8 +- drivers/gpu/drm/i915/intel_sdvo.c | 228 +++--- drivers/gpu/drm/i915/intel_sdvo_regs.h | 558 +++--- drivers/gpu/drm/i915/intel_tv.c | 58 ++-- 32 files changed, 867 insertions(+), 867 deletions(-) -- keith.pack...@intel.com pgplgiKN0Lhl5.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/i915 git repository at freedesktop.org
I've created a (temporary?) git repository for the drm/i915 driver at git://people.freedesktop.org/~keithp/linux This has the drm-intel-next and drm-intel-fixes branches, and may also have occasional temporary branches with code which has not been merged yet. -- keith.pack...@intel.com pgp1wNikipeHi.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: FBC off for ironlake, otherwise on by default
Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for everything except Ironlake where it has been
seen to cause trouble with screen updates.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915/intel_display.c | 10 +-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ce045a8..f07e425 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -67,11 +67,11 @@ module_param_named(i915_enable_rc6, i915_enable_rc6, int,
0600);
MODULE_PARM_DESC(i915_enable_rc6,
"Enable power-saving render C-state 6 (default: true)");
-unsigned int i915_enable_fbc __read_mostly = 1;
+unsigned int i915_enable_fbc __read_mostly = -1;
module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600);
MODULE_PARM_DESC(i915_enable_fbc,
"Enable frame buffer compression for power savings "
- "(default: false)");
+ "(default: -1 (use per-chip default))");
unsigned int i915_lvds_downclock __read_mostly = 0;
module_param_named(lvds_downclock, i915_lvds_downclock, int, 0400);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9fb4a40..bc05deb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1799,6 +1799,7 @@ static void intel_update_fbc(struct drm_device *dev)
struct drm_framebuffer *fb;
struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj;
+ int enable_fbc;
DRM_DEBUG_KMS("\n");
@@ -1839,7 +1840,14 @@ static void intel_update_fbc(struct drm_device *dev)
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb->obj;
- if (!i915_enable_fbc) {
+ enable_fbc = i915_enable_fbc;
+ if (enable_fbc < 0) {
+ DRM_DEBUG_KMS("fbc set to per-chip default\n");
+ enable_fbc = 1;
+ if (INTEL_INFO(dev)->gen == 5)
+ enable_fbc = 0;
+ }
+ if (!enable_fbc) {
DRM_DEBUG_KMS("fbc disabled per module param (default off)\n");
dev_priv->no_fbc_reason = FBC_MODULE_PARAM;
goto out_disable;
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35861] [r300g] Oilrush: whiter triangle between center of the screen and horizon
https://bugs.freedesktop.org/show_bug.cgi?id=35861 --- Comment #3 from Pavel Ondračka 2011-09-19 00:05:34 PDT --- Created an attachment (id=51327) --> (https://bugs.freedesktop.org/attachment.cgi?id=51327) Oilrush output with RADEON_DEBUG=vp (In reply to comment #2) > Is this still an issue with the latest version from git, and if so can you > post > the output of RADEON_DEBUG=vp ? Yes, this is still an issue with latest mesa. Requested log attached. I can also make you an apitrace if you don't have access to the game. -- 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 34218] [r300g] Unigine: some surfaces are reflecting too much light
https://bugs.freedesktop.org/show_bug.cgi?id=34218 Pavel Ondračka changed: What|Removed |Added Summary|[r300g] Unigine Sanctuary: |[r300g] Unigine: some |some surfaces are |surfaces are reflecting too |reflecting too much light |much light --- Comment #10 from Pavel Ondračka 2011-09-19 00:06:43 PDT --- Unigine Oilrush is also affected. -- 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: Proposal for a low-level Linux display framework
On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote: > On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen > wrote: > > > I think it's a bit more complex than that. True, there are MIPI > > standards, for the video there are DPI, DBI, DSI, and for the commands > > there is DCS. And, as you mentioned, many panels need custom > > initialization, or support only parts of the DCS, or have other > > quirks. > > So DSI is more like i2c than the DisplayPort aux channel or DDC. That Well, not quite. DSI is like DisplayPort and DisplayPort aux combined; there's only one bus, DSI, which is used to transfer video data and commands. For DSI video mode, the transfer is somewhat like traditional displays, and video data is send according to a pixel clock as a constant stream. However, before the video stream is enabled the bus can be used in bi-directional communication. And even when the video stream is enabled, there can be other communication in the blanking periods. For DSI command mode the transfer is a bit like high speed i2c; messages are sent when needed (when the userspace gives the command to update), without any strict timings. In practice this means that the peripheral needs to have a framebuffer memory of its own, which it uses to refresh the actual panel (or send the pixels forward to another peripheral). As the use patterns of these two types of displays are quite different, we have the terms auto-update and manual-update displays for them. > seems fine; you can create a DSI infrastructure like the i2c > infrastructure and then just have your display drivers use it to talk to > the panel. We might eventually end up with some shared DRM code to deal > with common DSI functions for display devices, like the EDID code > today, but that doesn't need to happen before you can write your first > DSI-using display driver. One difference with i2c and DSI is that i2c is independent of the video path, so it's easy to keep that separate from DRM. But for DSI the data is produced by the video hardware using the overlays, encoders etc. I don't quite see how we could have an i2c-like separate DSI API, which wasn't part of DRM. And even in simpler case MIPI DPI, which is a traditional parallel RGB interface, a panel may need custom configuration via, say, i2c or spi. We can, of course, create a i2c device driver for the panel, but how is that then connected to DRM? The i2c driver may need to know things like when the display is enabled/disabled, about backlight changes, or any other display related event. Is there a way for the i2c driver to get these events, and add new properties to the DRM (say, if the panel has a feature configured via i2c, but we'd like it to be visible to the userspace via the DRM driver)? Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Updated plane support v3
2011/6/21 Jesse Barnes : > This version adds both source and dest rect params to the set_plane > ioctl, and makes the source fixed point to support hardware that needs > it. > > I haven't changed the name of the SNB implementation yet (per Chris's > suggestions) but will before it gets upstream. > > I'd be interested to see whether these interfaces will work for other > hardware, so please take a close look at them and ideally implement them > on your hardware to make sure (see my userspace example code from > earlier posts if you want something to crib from). > > Thanks, > Jesse > Hi, Jesse. Could you have any posting plan for plane? Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29951] [r300g] xscreensaver hack "antspotlight" reveals something other than desktop
https://bugs.freedesktop.org/show_bug.cgi?id=29951 --- Comment #7 from Chris Rankin 2011-09-19 01:29:22 PDT --- (In reply to comment #6) > I just tested this with the latest version from git, and it appears to be > working. Can you confirm this? Sorry, it's not fixed yet. I ran antspotlight about 5 times in succession and the problem reoccurred. It did work the first few times, though. -- 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
[git pull] drm fixes
Hi Linus, Some fixes for page size mismatches in radeon, a lockdep noticed locking problem, and a fix to zero some memory that was being passed to userspace. Dave. The following changes since commit 003f6c9df54970d8b19578d195b3e2b398cdbde2: lib/sha1.c: quiet sparse noise about symbol not declared (2011-09-13 16:09:41 -0700) are available in the git repository at: git://people.freedesktop.org/~/linux.git drm-fixes Alex Deucher (2): drm/radeon/kms: fix typo in r100_blit_copy drm/radeon/kms: Make GPU/CPU page size handling consistent in blit code (v2) Ben Skeggs (1): drm/ttm: request zeroed system memory pages for new TT buffer objects Michel Dänzer (2): drm/radeon: Don't read from CP ring write pointer registers. drm/radeon: Unreference GEM object outside of spinlock in page flip error path. drivers/gpu/drm/radeon/evergreen.c | 14 -- drivers/gpu/drm/radeon/ni.c | 12 ++-- drivers/gpu/drm/radeon/r100.c | 22 ++ drivers/gpu/drm/radeon/r200.c |4 ++-- drivers/gpu/drm/radeon/r600.c | 14 -- drivers/gpu/drm/radeon/radeon.h |7 --- drivers/gpu/drm/radeon/radeon_asic.h|8 drivers/gpu/drm/radeon/radeon_display.c |2 +- drivers/gpu/drm/radeon/radeon_ttm.c |7 ++- drivers/gpu/drm/ttm/ttm_bo.c|3 ++- 10 files changed, 51 insertions(+), 42 deletions(-)___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41002] New: Switching doesn't work between plymouth and xorg.
https://bugs.freedesktop.org/show_bug.cgi?id=41002 Summary: Switching doesn't work between plymouth and xorg. Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: fabian.deut...@gmx.de When initiating a switch to the discrete card while plymouth is running, the switch doesn't happen completely in the small slot between the end of ply and Xorg's start. This happens with current Fedora 15 (all updates). Note: Maybe this is similar to bug #32970 -- 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 40935] radeon lockup on resume
https://bugs.freedesktop.org/show_bug.cgi?id=40935 --- Comment #4 from Michal Suchanek 2011-09-19 04:21:10 PDT --- It's a redwood. The bootup dmesg is below the locup messages. I am not sure what dev_err() would be. And now I rebooted and tried to kill Xorg with suspend and it would not lock up the card, only keep resetting it. -- 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] RFCv2: omapdrm DRM/KMS driver for TI OMAP platforms
On Mon, Sep 19, 2011 at 2:44 AM, Inki Dae wrote:
> Hello Rob.
>
> Is there some reason that you don't head your driver gpu/drm, just staging?
> and below is my short comments. thank you.
>
mainly because it is still a work-in-progress.. I expect some
re-shuffling of the mode-setting code when drm_plane support is added,
the plugin layer, etc. And perhaps at some point merging of the
omapdss and omapdrm layers.
I don't expect the ioctl ABI to change, and the driver is useful
as-is, but I still think there is enough changes that will happen that
staging is perhaps the better place for it to start life..
[snip]
>> +/* initialize connector */
>> +struct drm_connector * omap_connector_init(struct drm_device *dev,
>> + int connector_type, struct omap_dss_device *dssdev)
>> +{
>> + struct drm_connector *connector = NULL;
>> + struct omap_connector *omap_connector;
>> +
>> + DBG("%s", dssdev->name);
>> +
>> + omap_dss_get_device(dssdev);
>> +
>> + omap_connector = kzalloc(sizeof(struct omap_connector), GFP_KERNEL);
>> + if (!omap_connector) {
>> + dev_err(dev->dev, "could not allocate connector\n");
>> + goto fail;
>> + }
>> +
>> + omap_connector->dssdev = dssdev;
>> + connector = &omap_connector->base;
>> +
>> + drm_connector_init(dev, connector, &omap_connector_funcs,
>> + connector_type);
>> + drm_connector_helper_add(connector, &omap_connector_helper_funcs);
>> +
>> +#if 0 /* enable when dss2 supports hotplug */
>> + if (dssdev->caps & OMAP_DSS_DISPLAY_CAP_HPD)
>> + connector->polled = 0;
>> + else
>> +#endif
>
> How about removing the codes above until dss2 supports hotplug?
>
easier not to forget about them this way ;-)
if someone has a strong opinion, I can remove them.. but I guess it
should be not too distant future when support lands in dss2.. I guess
I should put a note in the TODO about re-enabling hotplug code
>> + connector->polled = DRM_CONNECTOR_POLL_CONNECT |
>> + DRM_CONNECTOR_POLL_DISCONNECT;
>> +
>> + connector->interlace_allowed = 1;
>> + connector->doublescan_allowed = 0;
>> +
>> + drm_sysfs_connector_add(connector);
>> +
>> + return connector;
>> +
>> +fail:
>> + if (connector) {
>> + omap_connector_destroy(connector);
>> + }
>> +
>> + return NULL;
>> +}
[snip]
>> +static void omap_crtc_dpms(struct drm_crtc *crtc, int mode)
>> +{
>> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> +
>> + DBG("%s: %d", omap_crtc->ovl->name, mode);
>> +
>> + if (mode == DRM_MODE_DPMS_ON) {
>> + update_scanout(crtc);
>
> Is there any reason that update_scanout function should be called here to
> update buffer address.? I think it's enough to call this function at
> mode_set callback.
In theory it should not be needed.. IIRC at some point I was hitting
some problem that the buffer address wasn't set yet, but that was w/
older version of the driver, older kernel, and different xorg driver..
>> + omap_crtc->info.enabled = true;
>> + } else {
>> + omap_crtc->info.enabled = false;
>> + }
>> +
>> + commit(crtc);
>
> and commit callback to apply those data on hw.
>
>> +}
>> +
[snip]
>> +
>> +/**
>> + * load - setup chip and create an initial config
>> + * @dev: DRM device
>> + * @flags: startup flags
>> + *
>> + * The driver load routine has to do several things:
>> + * - initialize the memory manager
>> + * - allocate initial config memory
>> + * - setup the DRM framebuffer with the allocated memory
>> + */
>> +static int dev_load(struct drm_device *dev, unsigned long flags)
>> +{
>> + struct omap_drm_private *priv;
>> + int ret;
>> +
>> + DBG("load: dev=%p", dev);
>> +
>> + drm_device = dev;
>> +
>> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>> + if (!priv) {
>> + dev_err(dev->dev, "could not allocate priv\n");
>> + return -1;
>> + }
>> +
>> + dev->dev_private = priv;
>> +
>> + ret = omap_modeset_init(dev);
>> + if (ret) {
>> + dev_err(dev->dev, "omap_modeset_init failed: ret=%d\n",
> ret);
>> + // hmm
>> + //return ret;
>
> Doesn't it need return? you output error message using dev_err().
Well.. currently omap_modeset_init() never returns !=0
I'm still a bit undecided on some of the error cases.. for example if
we don't successfully initialize everything, but do at least have >1
of each crtc/encoder/connector, maybe it makes sense to continue in
some reduced capacity..
But "check error handling/cleanup paths" is still in the TODO file ;-)
>> + }
>> +
>> + priv->fbdev = omap_fbdev_init(dev);
>> + if (!priv->fbdev) {
>> + dev_err(dev->dev, "omap_fbdev_init failed\n");
>> + ret = -ENOMEM;
>> + // hmm
>> + //return ret;
>
> Ditto. and also you would have to rele
[Bug 41002] Switching doesn't work between plymouth and xorg. (vgaswitcheroo)
https://bugs.freedesktop.org/show_bug.cgi?id=41002 Fabian Deutsch changed: What|Removed |Added Summary|Switching doesn't work |Switching doesn't work |between plymouth and xorg. |between plymouth and xorg. ||(vgaswitcheroo) -- 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 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #7 from Michal Suchanek 2011-09-19 09:39:58 PDT --- According to apitrace author the glretrace crash is due to gallium reading more data than is in the buffer. https://github.com/apitrace/apitrace/issues/39#issuecomment-2134199 -- 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 41019] New: DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 Summary: DPMS doesn't work correctly Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: General AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: nissa...@gmail.com Created an attachment (id=51369) --> (https://bugs.freedesktop.org/attachment.cgi?id=51369) dmesg output Monitor will keep constantly switching off/on when entering power saving mode: - LCD going black - OSD message "Entering power saving mode" - LCD turns off, then immediately goes back on and the cycle repeats This bug was previously reported on other list and should be fixed but unfortunately it's still present on my system. - Gentoo/AMD64 - kernel 3.1.0-rc6-00120 (linus + drm-fixes) - xorg 1.11.0/1.10.4 - Radeon 6850 (+internal card disabled) - Dell U2410 I'm not sure if this is relevant but the same effect can be observed on every power mode, i.e. xset dpms force standby/suspend/off. -- 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 41019] DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 --- Comment #1 from Wojciech Pyczak 2011-09-19 11:56:00 PDT --- Created an attachment (id=51370) --> (https://bugs.freedesktop.org/attachment.cgi?id=51370) 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 41019] DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 Alex Deucher changed: What|Removed |Added Attachment #51369|text/x-log |text/plain mime type|| Attachment #51369|0 |1 is patch|| -- 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 28847] Regnum Online: shader backend not rendering
https://bugs.freedesktop.org/show_bug.cgi?id=28847 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Sven Arvidsson 2011-09-19 12:05:02 PDT --- (In reply to comment #8) > Is this still an issue with the latest mesa from git? The game is still busted, but this is not specific to r300g but a problem with the GLSL compiler. There's already bug 28138 open about this, but that's filed against i965 and Intel is making some progress there, but only on their own backend. It's probably easier to close this report and file a new one against Mesa core to keep things simple. -- 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 41019] DPMS doesn't work correctly
https://bugs.freedesktop.org/show_bug.cgi?id=41019 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Alex Deucher 2011-09-19 12:05:11 PDT --- *** This bug has been marked as a duplicate of bug 40851 *** -- 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 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #8 from Marek Olšák 2011-09-19 12:44:51 PDT --- Created an attachment (id=51371) View: https://bugs.freedesktop.org/attachment.cgi?id=51371 Review: https://bugs.freedesktop.org/review?bug=39320&attachment=51371 print debug info I think it crashes because offset >= upload->buffer->width0. Could you apply the attached patch and post the output of stderr? -- 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 1/2] drm/radeon: add tracepoint for setting mode clocks.
From: Dave Airlie
This just adds a tracepoint that can be caught in perf for when the clocks
change.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_pm.c|3 +++
drivers/gpu/drm/radeon/radeon_trace.h | 18 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 6fabe89..2a44332 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include "radeon_trace.h"
#define RADEON_IDLE_LOOP_MS 100
#define RADEON_RECLOCK_DELAY_MS 200
@@ -165,6 +166,8 @@ static void radeon_set_power_state(struct radeon_device
*rdev)
(rdev->pm.requested_power_state_index ==
rdev->pm.current_power_state_index))
return;
+ trace_radeon_set_power_state(rdev);
+
if (radeon_gui_idle(rdev)) {
sclk =
rdev->pm.power_state[rdev->pm.requested_power_state_index].
clock_info[rdev->pm.requested_clock_mode_index].sclk;
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h
b/drivers/gpu/drm/radeon/radeon_trace.h
index eafd816..ef0fd05 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -27,6 +27,24 @@ TRACE_EVENT(radeon_bo_create,
TP_printk("bo=%p, pages=%u", __entry->bo, __entry->pages)
);
+TRACE_EVENT(radeon_set_power_state,
+TP_PROTO(struct radeon_device *rdev),
+TP_ARGS(rdev),
+ TP_STRUCT__entry(
+__field(int, requested_clock_mode)
+__field(int, current_clock_mode)
+__field(int, requested_power_state)
+__field(int, current_power_state)
+ ),
+ TP_fast_assign(
+ __entry->requested_clock_mode =
rdev->pm.requested_clock_mode_index;
+ __entry->current_clock_mode =
rdev->pm.current_clock_mode_index;
+ __entry->requested_power_state =
rdev->pm.requested_power_state_index;
+ __entry->current_power_state =
rdev->pm.current_power_state_index;
+ ),
+ TP_printk("clock %d->%d, power %d->%d",
__entry->current_clock_mode, __entry->requested_clock_mode,
__entry->current_power_state, __entry->requested_power_state)
+);
+
DECLARE_EVENT_CLASS(radeon_fence_request,
TP_PROTO(struct drm_device *dev, u32 seqno),
--
1.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: make pm method file show default + option.
From: Dave Airlie If we add more options in the future this will need rework. this is modelled after the example in /sys/power/disk. Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/radeon_pm.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 2a44332..25bc75e 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -390,9 +390,13 @@ static ssize_t radeon_get_pm_method(struct device *dev, struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev)); struct radeon_device *rdev = ddev->dev_private; int pm = rdev->pm.pm_method; + char *start = buf; - return snprintf(buf, PAGE_SIZE, "%s\n", - (pm == PM_METHOD_DYNPM) ? "dynpm" : "profile"); + if (pm == PM_METHOD_DYNPM) + buf += snprintf(buf, PAGE_SIZE, "[dynpm] profile\n"); + else + buf += snprintf(buf, PAGE_SIZE, "dynpm [profile]\n"); + return buf - start; } static ssize_t radeon_set_pm_method(struct device *dev, -- 1.7.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39320] util/u_upload_mgr.c:192:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=39320 --- Comment #9 from Michal Suchanek 2011-09-19 14:52:19 PDT --- I get this extra output: u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_vbuf_upload_buffers u_upload_alloc:194: min_out_offset = 4294966000, size = 1296, alloc_size = 1296, alloc_offset = 4294966000, upload->offset = 322528, upload->size = 1048576, upload->buffer->width0 = 1048576, offset = 4294966000 util/u_upload_mgr.c:195:u_upload_alloc: Assertion `offset < upload->buffer->width0' failed. -- 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
drm/i915: eDP cleanup patch series -- fixes SNB MacBook Air
Here's a sequence of eDP patches which are necessary to make the driver work on the Sandybridge MacBook Air The key trick was to make sure that the eDP power was applied before trying to communicate with the device. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/i915: Enable digital port hotplug on PCH systems
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 542453f..b7fbb74 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2903,12 +2903,13 @@
#define SDEIER 0xc400c
/* digital port hotplug */
-#define PCH_PORT_HOTPLUG0xc4030
+#define PCH_PORT_HOTPLUG0xc4030/* SHOTPLUG_CTL */
#define PORTD_HOTPLUG_ENABLE(1 << 20)
#define PORTD_PULSE_DURATION_2ms(0)
#define PORTD_PULSE_DURATION_4_5ms (1 << 18)
#define PORTD_PULSE_DURATION_6ms(2 << 18)
#define PORTD_PULSE_DURATION_100ms (3 << 18)
+#define PORTD_PULSE_DURATION_MASK (3 << 18)
#define PORTD_HOTPLUG_NO_DETECT (0)
#define PORTD_HOTPLUG_SHORT_DETECT (1 << 16)
#define PORTD_HOTPLUG_LONG_DETECT (1 << 17)
@@ -2917,6 +2918,7 @@
#define PORTC_PULSE_DURATION_4_5ms (1 << 10)
#define PORTC_PULSE_DURATION_6ms(2 << 10)
#define PORTC_PULSE_DURATION_100ms (3 << 10)
+#define PORTC_PULSE_DURATION_MASK (3 << 10)
#define PORTC_HOTPLUG_NO_DETECT (0)
#define PORTC_HOTPLUG_SHORT_DETECT (1 << 8)
#define PORTC_HOTPLUG_LONG_DETECT (1 << 9)
@@ -2925,6 +2927,7 @@
#define PORTB_PULSE_DURATION_4_5ms (1 << 2)
#define PORTB_PULSE_DURATION_6ms(2 << 2)
#define PORTB_PULSE_DURATION_100ms (3 << 2)
+#define PORTB_PULSE_DURATION_MASK (3 << 2)
#define PORTB_HOTPLUG_NO_DETECT (0)
#define PORTB_HOTPLUG_SHORT_DETECT (1 << 0)
#define PORTB_HOTPLUG_LONG_DETECT (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9fb4a40..54403dd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7151,6 +7151,18 @@ static void intel_setup_outputs(struct drm_device *dev)
I915_WRITE(PFIT_CONTROL, 0);
}
+ /* Enable digital port hotplug detect on PCH hardware */
+ if (HAS_PCH_SPLIT(dev)) {
+ u32 hotplug;
+
+ hotplug = I915_READ(PCH_PORT_HOTPLUG);
+ hotplug &=
~(PORTD_PULSE_DURATION_MASK|PORTC_PULSE_DURATION_MASK|PORTB_PULSE_DURATION_MASK);
+ hotplug |= PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_2ms;
+ hotplug |= PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_2ms;
+ hotplug |= PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_2ms;
+ I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
+ }
+
if (HAS_PCH_SPLIT(dev)) {
dpd_is_edp = intel_dpd_is_edp(dev);
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/i915: Remove extra 300ms delay during eDP mode setting
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..f0cfb6b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -903,13 +903,6 @@ static void ironlake_edp_backlight_on (struct drm_device
*dev)
u32 pp;
DRM_DEBUG_KMS("\n");
- /*
-* If we enable the backlight right away following a panel power
-* on, we may see slight flicker as the panel syncs with the eDP
-* link. So delay a bit to make sure the image is solid before
-* allowing it to appear.
-*/
- msleep(300);
pp = I915_READ(PCH_PP_CONTROL);
pp |= EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/i915: Only use VBT panel mode on eDP if no EDID is found
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f0cfb6b..8ab2a88 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1748,7 +1748,16 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
/* if eDP has no EDID, try to use fixed panel mode from VBT */
if (is_edp(intel_dp)) {
- if (dev_priv->panel_fixed_mode != NULL) {
+ /* initialize panel mode from VBT if available for eDP */
+ if (dev_priv->panel_fixed_mode == NULL &&
dev_priv->lfp_lvds_vbt_mode != NULL) {
+ dev_priv->panel_fixed_mode =
+ drm_mode_duplicate(dev,
dev_priv->lfp_lvds_vbt_mode);
+ if (dev_priv->panel_fixed_mode) {
+ dev_priv->panel_fixed_mode->type |=
+ DRM_MODE_TYPE_PREFERRED;
+ }
+ }
+ if (dev_priv->panel_fixed_mode) {
struct drm_display_mode *mode;
mode = drm_mode_duplicate(dev,
dev_priv->panel_fixed_mode);
drm_mode_probed_add(connector, mode);
@@ -2061,15 +2070,6 @@ intel_dp_init(struct drm_device *dev, int output_reg)
intel_encoder->hot_plug = intel_dp_hot_plug;
if (is_edp(intel_dp)) {
- /* initialize panel mode from VBT if available for eDP */
- if (dev_priv->lfp_lvds_vbt_mode) {
- dev_priv->panel_fixed_mode =
- drm_mode_duplicate(dev,
dev_priv->lfp_lvds_vbt_mode);
- if (dev_priv->panel_fixed_mode) {
- dev_priv->panel_fixed_mode->type |=
- DRM_MODE_TYPE_PREFERRED;
- }
- }
dev_priv->int_edp_connector = connector;
intel_panel_setup_backlight(dev);
}
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/i915: Check eDP power when doing aux channel communications
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8ab2a88..3b29a6f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -279,6 +279,24 @@ intel_hrawclk(struct drm_device *dev)
}
}
+static void
+intel_dp_check_edp(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 pp_status, pp_control;
+ if (!is_edp(intel_dp))
+ return;
+ pp_status = I915_READ(PCH_PP_STATUS);
+ pp_control = I915_READ(PCH_PP_CONTROL);
+ if ((pp_status & PP_ON) == 0 && (pp_control & EDP_FORCE_VDD) == 0) {
+ WARN(1, "eDP powered off while attempting aux channel
communication.\n");
+ DRM_DEBUG_KMS("Status 0x%08x Control 0x%08x\n",
+ pp_status,
+ I915_READ(PCH_PP_CONTROL));
+ }
+}
+
static int
intel_dp_aux_ch(struct intel_dp *intel_dp,
uint8_t *send, int send_bytes,
@@ -295,6 +313,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
uint32_t aux_clock_divider;
int try, precharge;
+ intel_dp_check_edp(intel_dp);
/* The clock divider is based off the hrawclk,
* and would like to run at 2MHz. So, take the
* hrawclk value and divide by 2 and use that
@@ -408,6 +427,7 @@ intel_dp_aux_native_write(struct intel_dp *intel_dp,
int msg_bytes;
uint8_t ack;
+ intel_dp_check_edp(intel_dp);
if (send_bytes > 16)
return -1;
msg[0] = AUX_NATIVE_WRITE << 4;
@@ -450,6 +470,7 @@ intel_dp_aux_native_read(struct intel_dp *intel_dp,
uint8_t ack;
int ret;
+ intel_dp_check_edp(intel_dp);
msg[0] = AUX_NATIVE_READ << 4;
msg[1] = address >> 8;
msg[2] = address & 0xff;
@@ -493,6 +514,7 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
int reply_bytes;
int ret;
+ intel_dp_check_edp(intel_dp);
/* Set up the command byte */
if (mode & MODE_I2C_READ)
msg[0] = AUX_I2C_READ << 4;
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/i915: Unlock PCH_PP_CONTROL always
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b7fbb74..5596e8e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3311,6 +3311,7 @@
#define PCH_PP_STATUS 0xc7200
#define PCH_PP_CONTROL 0xc7204
#define PANEL_UNLOCK_REGS (0xabcd << 16)
+#define PANEL_UNLOCK_MASK (0x << 16)
#define EDP_FORCE_VDD (1 << 3)
#define EDP_BLC_ENABLE(1 << 2)
#define PANEL_POWER_RESET (1 << 1)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3b29a6f..a983d0f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -840,6 +840,8 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
msleep(dev_priv->panel_t3);
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp |= EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -852,6 +854,8 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
u32 pp;
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp &= ~EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -871,13 +875,15 @@ static bool ironlake_edp_panel_on (struct intel_dp
*intel_dp)
return true;
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
/* ILK workaround: disable reset around power sequence */
pp &= ~PANEL_POWER_RESET;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
- pp |= PANEL_UNLOCK_REGS | POWER_TARGET_ON;
+ pp |= POWER_TARGET_ON;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -900,6 +906,8 @@ static void ironlake_edp_panel_off (struct drm_device *dev)
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
/* ILK workaround: disable reset around power sequence */
pp &= ~PANEL_POWER_RESET;
@@ -926,6 +934,8 @@ static void ironlake_edp_backlight_on (struct drm_device
*dev)
DRM_DEBUG_KMS("\n");
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp |= EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
}
@@ -937,6 +947,8 @@ static void ironlake_edp_backlight_off (struct drm_device
*dev)
DRM_DEBUG_KMS("\n");
pp = I915_READ(PCH_PP_CONTROL);
+ pp &= ~PANEL_UNLOCK_MASK;
+ pp |= PANEL_UNLOCK_REGS;
pp &= ~EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
}
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/i915: Move eDP panel fixed mode from dev_priv to intel_dp
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bcdf58b..e6dd19e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -347,7 +347,6 @@ typedef struct drm_i915_private {
/* LVDS info */
int backlight_level; /* restore backlight to this value */
bool backlight_enabled;
- struct drm_display_mode *panel_fixed_mode;
struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1d6105..5bc30f9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -61,6 +61,7 @@ struct intel_dp {
uint8_t link_status[DP_LINK_STATUS_SIZE];
int panel_power_up_delay;
int panel_power_down_delay;
+ struct drm_display_mode *panel_fixed_mode; /* for eDP */
};
/**
@@ -202,16 +203,14 @@ intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
- struct drm_device *dev = connector->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
int max_link_clock =
intel_dp_link_clock(intel_dp_max_link_bw(intel_dp));
int max_lanes = intel_dp_max_lane_count(intel_dp);
- if (is_edp(intel_dp) && dev_priv->panel_fixed_mode) {
- if (mode->hdisplay > dev_priv->panel_fixed_mode->hdisplay)
+ if (is_edp(intel_dp) && intel_dp->panel_fixed_mode) {
+ if (mode->hdisplay > intel_dp->panel_fixed_mode->hdisplay)
return MODE_PANEL;
- if (mode->vdisplay > dev_priv->panel_fixed_mode->vdisplay)
+ if (mode->vdisplay > intel_dp->panel_fixed_mode->vdisplay)
return MODE_PANEL;
}
@@ -630,22 +629,21 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_device *dev = encoder->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
int lane_count, clock;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 :
0;
static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
- if (is_edp(intel_dp) && dev_priv->panel_fixed_mode) {
- intel_fixed_panel_mode(dev_priv->panel_fixed_mode,
adjusted_mode);
+ if (is_edp(intel_dp) && intel_dp->panel_fixed_mode) {
+ intel_fixed_panel_mode(intel_dp->panel_fixed_mode,
adjusted_mode);
intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
mode, adjusted_mode);
/*
* the mode->clock is used to calculate the Data&Link M/N
* of the pipe. For the eDP the fixed clock should be used.
*/
- mode->clock = dev_priv->panel_fixed_mode->clock;
+ mode->clock = intel_dp->panel_fixed_mode->clock;
}
for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
@@ -1812,35 +1810,34 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
ret = intel_dp_get_edid_modes(connector, &intel_dp->adapter);
if (ret) {
- if (is_edp(intel_dp) && !dev_priv->panel_fixed_mode) {
+ if (is_edp(intel_dp) && !intel_dp->panel_fixed_mode) {
struct drm_display_mode *newmode;
list_for_each_entry(newmode, &connector->probed_modes,
head) {
- if (newmode->type & DRM_MODE_TYPE_PREFERRED) {
- dev_priv->panel_fixed_mode =
+ if ((newmode->type & DRM_MODE_TYPE_PREFERRED)) {
+ intel_dp->panel_fixed_mode =
drm_mode_duplicate(dev,
newmode);
break;
}
}
}
-
return ret;
}
/* if eDP has no EDID, try to use fixed panel mode from VBT */
if (is_edp(intel_dp)) {
/* initialize panel mode from VBT if available for eDP */
- if (dev_priv->panel_fixed_mode == NULL &&
dev_priv->lfp_lvds_vbt_mode != NULL) {
-
[PATCH 6/9] drm/i915: Make sure eDP power is on before using aux channel
The eDP panel may not be able to respond to aux channel communications
unless it has power supplied. During mode setting, power may be
cut-off during panel power sequencing. Make sure that any aux channel
communications will work by forcing vdd power active as needed.
This also delays after turning power on and off to ensure that the
panel is keeping up.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 84 +-
1 files changed, 64 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a983d0f..41b1e05 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -595,10 +595,15 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
return -EREMOTEIO;
}
+static void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp);
+static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp);
+
static int
intel_dp_i2c_init(struct intel_dp *intel_dp,
struct intel_connector *intel_connector, const char *name)
{
+ int ret;
+
DRM_DEBUG_KMS("i2c_init %s\n", name);
intel_dp->algo.running = false;
intel_dp->algo.address = 0;
@@ -612,7 +617,10 @@ intel_dp_i2c_init(struct intel_dp *intel_dp,
intel_dp->adapter.algo_data = &intel_dp->algo;
intel_dp->adapter.dev.parent = &intel_connector->base.kdev;
- return i2c_dp_aux_add_bus(&intel_dp->adapter);
+ ironlake_edp_panel_vdd_on(intel_dp);
+ ret = i2c_dp_aux_add_bus(&intel_dp->adapter);
+ ironlake_edp_panel_vdd_off(intel_dp);
+ return ret;
}
static bool
@@ -830,14 +838,20 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
{
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- u32 pp;
+ u32 pp, pp_status;
+ if (!is_edp(intel_dp))
+ return;
+ DRM_DEBUG_KMS("Turn eDP VDD on\n");
/*
* If the panel wasn't on, make sure there's not a currently
* active PP sequence before enabling AUX VDD.
*/
- if (!(I915_READ(PCH_PP_STATUS) & PP_ON))
+ pp_status = I915_READ(PCH_PP_STATUS);
+ if (!(pp_status & PP_ON)) {
+ DRM_DEBUG_KMS("eDP VDD was not on\n");
msleep(dev_priv->panel_t3);
+ }
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -845,6 +859,9 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
pp |= EDP_FORCE_VDD;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
+ DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
+ I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
+ msleep(1000);
}
static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -853,6 +870,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp;
+ if (!is_edp(intel_dp))
+ return;
+ DRM_DEBUG_KMS("Turn eDP VDD off\n");
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
pp |= PANEL_UNLOCK_REGS;
@@ -862,6 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
/* Make sure sequencer is idle before allowing subsequent activity */
msleep(dev_priv->panel_t12);
+ DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
+ I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
+ msleep(1000);
}
/* Returns true if the panel was already on when called */
@@ -1016,7 +1039,9 @@ static void intel_dp_prepare(struct drm_encoder *encoder)
struct drm_device *dev = encoder->dev;
/* Wake up the sink first */
+ ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ ironlake_edp_panel_vdd_off(intel_dp);
if (is_edp(intel_dp)) {
ironlake_edp_backlight_off(dev);
@@ -1034,21 +1059,17 @@ static void intel_dp_commit(struct drm_encoder *encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct drm_device *dev = encoder->dev;
- if (is_edp(intel_dp))
- ironlake_edp_panel_vdd_on(intel_dp);
-
+ ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_start_link_train(intel_dp);
- if (is_edp(intel_dp)) {
+ if (is_edp(intel_dp))
ironlake_edp_panel_on(intel_dp);
- ironlake_edp_panel_vdd_off(intel_dp);
- }
intel_dp_complete_link_train(intel_dp);
if (is_edp(intel_dp))
ironlake_edp_backlight_on(dev);
-
+ ironlake_edp_panel_vdd_off(intel_dp);
intel_dp->dpms_mode = DRM_MODE_DPMS_ON;
}
@@ -1060,6 +1081,7 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
struct
[PATCH 7/9] drm/i915: Correct eDP panel power sequencing delay computations
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum of the two
delays, to make sure things work reliably. If there is no VBT data,
then those values will be initialized to zero, so we'll just use the
values as programmed in the hardware.
This patch computes power-up and power-down delays, rather than using
portions of the appropriate delay values as found in the hardware. The
eDP specified delay between raising VCC and communicating over the aux
channel includes both the power rise time (T1) and the aux channel
communication delay (T3). The eDP specified delay between powering
down the device and powering it back up includes both the power fall
time (T11) and the device idle time (T12).
>From the hardware, I'm taking the T3 value from the PP_OFF_DELAYS
Power_Down_delay value, which is actually documented to be the 'T3
time sequence' value used 'during power up'. There aren't separate T1
and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS
register, so I use that instead.
VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.
The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.
The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.
On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 56 --
2 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..bcdf58b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -672,7 +672,6 @@ typedef struct drm_i915_private {
unsigned int lvds_border_bits;
/* Panel fitter placement and size for Ironlake+ */
u32 pch_pf_pos, pch_pf_size;
- int panel_t3, panel_t12;
struct drm_crtc *plane_to_crtc_mapping[2];
struct drm_crtc *pipe_to_crtc_mapping[2];
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 41b1e05..f1d6105 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -59,6 +59,8 @@ struct intel_dp {
bool is_pch_edp;
uint8_t train_set[4];
uint8_t link_status[DP_LINK_STATUS_SIZE];
+ int panel_power_up_delay;
+ int panel_power_down_delay;
};
/**
@@ -848,10 +850,6 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
* active PP sequence before enabling AUX VDD.
*/
pp_status = I915_READ(PCH_PP_STATUS);
- if (!(pp_status & PP_ON)) {
- DRM_DEBUG_KMS("eDP VDD was not on\n");
- msleep(dev_priv->panel_t3);
- }
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -861,7 +859,10 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
- msleep(1000);
+ if (!(pp_status & PP_ON)) {
+ msleep(intel_dp->panel_power_up_delay);
+ DRM_DEBUG_KMS("eDP VDD was not on\n");
+ }
}
static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -881,10 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
/* Make sure sequencer is idle before allowing subsequent activity */
- msleep(dev_priv->panel_t12);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
- msleep(1000);
+ msleep(intel_dp->panel_power_down_delay);
}
/* Returns true if the panel was already on when called */
@@ -922,8 +922,10 @@ static bool ironlake_edp_panel_on (struct intel_dp
*intel_dp)
return false;
}
-static void ironlake_edp_panel_off (struct drm_device *dev)
+static void ironlake_edp_panel_off(struct drm_encoder *encoder)
{
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp, idle_off_mask = PP_ON | PP_SEQUENCE_MASK |
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
@@ -940,6 +942,7 @@ static void ironlake_edp_pan
[PATCH 9/9] drm/i915: Disable eDP VDD in a delayed work proc instead of synchronously
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respected before trying to turn it back on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 93 +-
1 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5bc30f9..8130e82 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -62,6 +62,9 @@ struct intel_dp {
int panel_power_up_delay;
int panel_power_down_delay;
struct drm_display_mode *panel_fixed_mode; /* for eDP */
+ struct delayed_work panel_vdd_work;
+ bool panel_vdd_force;
+ unsigned long panel_off_jiffies;
};
/**
@@ -834,6 +837,23 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct
drm_display_mode *mode,
}
}
+static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
+{
+ unsigned long off_time;
+ unsigned long delay;
+ DRM_DEBUG_KMS("Wait for panel power off time\n");
+ off_time = intel_dp->panel_off_jiffies +
msecs_to_jiffies(intel_dp->panel_power_down_delay);
+ if (time_after(jiffies, off_time)) {
+ DRM_DEBUG_KMS("Time already passed");
+ return;
+ }
+ delay = jiffies_to_msecs(off_time - jiffies);
+ if (delay > intel_dp->panel_power_down_delay)
+ delay = intel_dp->panel_power_down_delay;
+ DRM_DEBUG_KMS("Waiting an additional %ld ms\n", delay);
+ msleep(delay);
+}
+
static void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp->base.base.dev;
@@ -843,13 +863,18 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
if (!is_edp(intel_dp))
return;
DRM_DEBUG_KMS("Turn eDP VDD on\n");
- /*
-* If the panel wasn't on, make sure there's not a currently
-* active PP sequence before enabling AUX VDD.
-*/
- pp_status = I915_READ(PCH_PP_STATUS);
+ WARN(intel_dp->panel_vdd_force,
+"eDP VDD already forced on\n");
+
+ intel_dp->panel_vdd_force = true;
pp = I915_READ(PCH_PP_CONTROL);
+ if (pp & EDP_FORCE_VDD) {
+ DRM_DEBUG_KMS("eDP VDD already on\n");
+ return;
+ }
+
+ ironlake_wait_panel_off(intel_dp);
pp &= ~PANEL_UNLOCK_MASK;
pp |= PANEL_UNLOCK_REGS;
pp |= EDP_FORCE_VDD;
@@ -857,21 +882,23 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
+
+ /*
+* If the panel wasn't on, delay before accessing aux channel
+*/
+ pp_status = I915_READ(PCH_PP_STATUS);
if (!(pp_status & PP_ON)) {
+ DRM_DEBUG_KMS("eDP was not running\n");
msleep(intel_dp->panel_power_up_delay);
- DRM_DEBUG_KMS("eDP VDD was not on\n");
}
}
-static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
+static void ironlake_panel_vdd_delayed_off(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp;
- if (!is_edp(intel_dp))
- return;
- DRM_DEBUG_KMS("Turn eDP VDD off\n");
pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
pp |= PANEL_UNLOCK_REGS;
@@ -882,7 +909,37 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp)
/* Make sure sequencer is idle before allowing subsequent activity */
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
- msleep(intel_dp->panel_power_down_delay);
+ intel_dp->panel_off_jiffies = jiffies;
+}
+
+static void ironlake_panel_vdd_work(struct work_struct *__work)
+{
+ struct intel_dp *intel_dp = container_of(to_delayed_work(__work),
+struct intel_dp,
panel_vdd_work);
+ struct drm_device *dev = intel_dp->base.base.dev;
+
+ mutex_lock(&dev->struct_mutex);
+ if (!intel_dp->panel_vdd_force)
+ ironlake_panel_vdd_delayed_off(intel_dp);
+ mutex_unlock(&dev->struct_mutex);
+}
+
+static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
+{
+ if (!is_edp(intel_dp))
+ return;
+
+ DRM_DEBUG_KMS("Turn eDP VDD off %d\n", intel_dp->panel_vdd_force);
+ WARN(!intel_dp->panel_vdd_force, "eDP VDD not forced on");
