[Intel-gfx] [PATCH] drm/i915: Export the eLLC size from KMD via IOCTL
commit 6033637a040eeb8ae0f31bdbca8d9c988582f99d
Author: GuoYejun mailto:yejun@intel.com>>
Date: Fri Sep 27 16:26:18 2013 +0800
drm/i915: Export the eLLC size from KMD via IOCTL
The usermode driver needs the eLLC information in order to
make decisions which can result in significant performance improvements.
Since all userspace drivers require this same information,
it makes sense to store it in one globally accessible place, the kernel.
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index dd76d93..4ce36f4 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1003,6 +1003,9 @@ static int i915_getparam(struct drm_device *dev, void
*data,
case I915_PARAM_HAS_EXEC_HANDLE_LUT:
value = 1;
break;
+ case I915_PARAM_ELLC_SIZE:
+ value = dev_priv->ellc_size;
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n",
param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3a4e97b..a0d4e00 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -335,6 +335,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_EXEC_NO_RELOC25
#define I915_PARAM_HAS_EXEC_HANDLE_LUT 26
#define I915_PARAM_HAS_WT 27
+#define I915_PARAM_ELLC_SIZE 28
typedef struct drm_i915_getparam {
int param;
Yejun
graphics software engineer
Tel: (+86) 021-6116-6181
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [IGT PATCH] README: list some of the dependencies
I'm using Ubuntu 13.10 sudo apt-get install libpciaccess-dev Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libpciaccess-dev 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 23,6 kB of archives. After this operation, 121 kB of additional disk space will be used. Get:1 http://ro.archive.ubuntu.com/ubuntu/ saucy/main libpciaccess-dev amd64 0.13.2-1 [23,6 kB] Fetched 23,6 kB in 0s (160 kB/s) Selecting previously unselected package libpciaccess-dev:amd64. (Reading database ... 232755 files and directories currently installed.) Unpacking libpciaccess-dev:amd64 (from .../libpciaccess-dev_0.13.2-1_amd64.deb) ... Setting up libpciaccess-dev:amd64 (0.13.2-1) ... Hmm. You need to discuss this with your dristro maintainers. On Wed, Oct 9, 2013 at 2:11 AM, Ben Widawsky wrote: > On Tue, Oct 08, 2013 at 09:19:06PM +0300, Jani Nikula wrote: >> Signed-off-by: Jani Nikula >> --- >> README | 12 >> 1 file changed, 12 insertions(+) >> >> diff --git a/README b/README >> index 653bfcd..a04c987 100644 >> --- a/README >> +++ b/README >> @@ -96,3 +96,15 @@ debugger/ >> initiating connections with debug clients.. >> >> The debugger must be run as root: "sudo debugger/eudb" >> + >> +DEPENDENCIES >> + This is a non-exchaustive list of package dependencies required for >> + building everything: >> + >> + libpciaccess-dev >> + libdrm-dev >> + xutils-dev >> + libcairo2-dev >> + swig2.0 >> + libpython3.3-dev >> + x11proto-dri2-dev > > I guess my gripe with this kind of thing is people always tend you use > distro specific package names. Can we somehow prevent it though? > > $ sudo pacman -S libpciaccess-dev > error: target not found: libpciaccess-dev > > -- > Ben Widawsky, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/hsw: Add I915_EXEC_RESOURCE_STREAMER flag
On Tue, Oct 08, 2013 at 10:50:50PM +0100, Chris Wilson wrote: > On Wed, Oct 09, 2013 at 12:09:51AM +0300, Abdiel Janulgue wrote: > > Ensures that the batch buffer is executed by the resource streamer. > > > > Signed-off-by: Abdiel Janulgue > > --- > > drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 ++ > > include/uapi/drm/i915_drm.h|5 + > > 2 files changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > index 0ce0d47..4a56c58 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > @@ -962,6 +962,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void > > *data, > > case I915_EXEC_DEFAULT: > > case I915_EXEC_RENDER: > > ring = &dev_priv->ring[RCS]; > > + flags |= (args->flags & I915_EXEC_RESOURCE_STREAMER) ? > > + I915_EXEC_RESOURCE_STREAMER : 0; > > Besides this being flags |= args->flags & I915_EXEC_RESOURCE_STREAMER; > flags is a completely different bitfield and you should be translating > into a dispatch value rather than the execbuffer value. > -Chris > To decrypt Chris just a bit, though he was rather more verbose than usual ;-), see the translation of I915_EXEC_SECURE to I915_DISPATCH_SECURE. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Do PCH and uncore init earlier
For future platforms we'll need to initialize our MMIO function pointers even earlier. Specifically, we'll need to be able to have register reads/writes at GTT initialization. Similarly, these platforms also have MMIO differences based on the PCH id, so while moving stuff around, also move the PCH initialization. CC: Chris Wilson Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_dma.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index ad55c02..df6efbf 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1549,6 +1549,11 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) intel_uncore_early_sanitize(dev); + /* This must be called before any calls to HAS_PCH_* */ + intel_detect_pch(dev); + + intel_uncore_init(dev); + ret = i915_gem_gtt_init(dev); if (ret) goto out_regs; @@ -1606,12 +1611,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) goto out_mtrrfree; } - /* This must be called before any calls to HAS_PCH_* */ - intel_detect_pch(dev); - intel_irq_init(dev); intel_pm_init(dev); - intel_uncore_init(dev); intel_uncore_sanitize(dev); /* Try to make sure MCHBAR is enabled before poking at it */ @@ -1696,6 +1697,7 @@ out_gtt: drm_mm_takedown(&dev_priv->gtt.base.mm); dev_priv->gtt.base.cleanup(&dev_priv->gtt.base); out_regs: + intel_uncore_fini(dev); pci_iounmap(dev->pdev, dev_priv->regs); put_bridge: pci_dev_put(dev_priv->bridge_dev); -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [IGT PATCH] README: list some of the dependencies
On Tue, Oct 08, 2013 at 09:19:06PM +0300, Jani Nikula wrote: > Signed-off-by: Jani Nikula > --- > README | 12 > 1 file changed, 12 insertions(+) > > diff --git a/README b/README > index 653bfcd..a04c987 100644 > --- a/README > +++ b/README > @@ -96,3 +96,15 @@ debugger/ > initiating connections with debug clients.. > > The debugger must be run as root: "sudo debugger/eudb" > + > +DEPENDENCIES > + This is a non-exchaustive list of package dependencies required for > + building everything: > + > + libpciaccess-dev > + libdrm-dev > + xutils-dev > + libcairo2-dev > + swig2.0 > + libpython3.3-dev > + x11proto-dri2-dev I guess my gripe with this kind of thing is people always tend you use distro specific package names. Can we somehow prevent it though? $ sudo pacman -S libpciaccess-dev error: target not found: libpciaccess-dev -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/hsw: Add display Audio codec disable sequence for Haswell
Hi
2013/9/24 :
> From: Mukesh
>
> The code defines a new function intel_disable_audio() to implement the
> entire audio codec disable sequence, called by intel_disable_ddi() in
> DDI port disablement. This audio codec disbale sequence is implemented
> as per the recommendation of the Bspec.
>
> [Patch modified by Mendong to apply to both HDMI and DP port.]
>
> Signed-off-by: Mukesh Arora
> Signed-off-by: Mengdong Lin
> Reviewed-by: Ben Widawsky
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b042ee5..bda9181 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1088,6 +1088,50 @@ static void intel_ddi_post_disable(struct
> intel_encoder *intel_encoder)
> I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
> }
>
> +/* audio codec disable sequence, as per Bspec */
> +void intel_disable_audio(struct intel_encoder *intel_encoder)
This needs to be static. I'd also rename it to
"intel_ddi_disable_audio" or "hsw_disable_audio" or something that
suggests we're doing this for DDI/HSW only.
With this fixed: Reviewed-by: Paulo Zanoni
> +{
> + int type = intel_encoder->type;
> + struct drm_encoder *encoder = &intel_encoder->base;
> + struct drm_device *dev = encoder->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> + int pipe = intel_crtc->pipe;
> + int aud_config = HSW_AUD_CFG(pipe);
> + u32 temp;
> +
> + /* need not disable sample fabrication because never enabled */
> +
> + /* disable timestamps */
> + temp = I915_READ(aud_config);
> + if (type == INTEL_OUTPUT_HDMI)
> + temp &= ~AUD_CONFIG_N_VALUE_INDEX;
> + else if (type == INTEL_OUTPUT_DISPLAYPORT)
> + temp |= AUD_CONFIG_N_VALUE_INDEX;
> + else
> + return;
> + temp |= AUD_CONFIG_N_PROG_ENABLE;
> + temp &= ~(AUD_CONFIG_UPPER_N_VALUE|AUD_CONFIG_LOWER_N_VALUE);
> + I915_WRITE(aud_config, temp);
> + POSTING_READ(aud_config);
> +
> + /* Disable ELDV and ELD buffer */
> + temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> + temp &= ~(AUDIO_ELD_VALID_A << (pipe * 4));
> + I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, temp);
> + POSTING_READ(HSW_AUD_PIN_ELD_CP_VLD);
> +
> + /* Wait for 2 vertical blanks */
> + intel_wait_for_vblank(dev, pipe);
> + intel_wait_for_vblank(dev, pipe);
> +
> + /* Disable audio PD. This is optional as per Bspec. */
> + temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> + temp &= ~(AUDIO_OUTPUT_ENABLE_A << (pipe * 4));
> + I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, temp);
> + POSTING_READ(HSW_AUD_PIN_ELD_CP_VLD);
> +}
> +
> static void intel_enable_ddi(struct intel_encoder *intel_encoder)
> {
> struct drm_encoder *encoder = &intel_encoder->base;
> @@ -1132,18 +1176,10 @@ static void intel_disable_ddi(struct intel_encoder
> *intel_encoder)
> struct drm_encoder *encoder = &intel_encoder->base;
> struct drm_crtc *crtc = encoder->crtc;
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - int pipe = intel_crtc->pipe;
> int type = intel_encoder->type;
> - struct drm_device *dev = encoder->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - uint32_t tmp;
>
> - if (intel_crtc->eld_vld && type != INTEL_OUTPUT_EDP) {
> - tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> - tmp &= ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) <<
> -(pipe * 4));
> - I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
> - }
> + if (intel_crtc->eld_vld && type != INTEL_OUTPUT_EDP)
> + intel_disable_audio(intel_encoder);
>
> if (type == INTEL_OUTPUT_EDP) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> --
> 1.8.1.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/ns2501: Update from git working
On Tue, Oct 08, 2013 at 10:56:41PM +0200, Thomas Richter wrote: > Hi Daniel, dear kernel developers, > > just tried the 3.12.rc3+ from the intel-drm git. This version > *worked* again, pretty much the same way the 3.10.10 "worked". > > Side effects are, however, quite the same when you connect an > external monitor: > > If connected while the gdm login screen is on, the external monitor > works fine with the internal TFT (mirroring is turned on). > Resolutions > 1024x768 and 800x600 are fine, switching to 640x480 locks up the > internal DVO, the external monitor keeps working. Note that the DVO > does *not* lock up if the external monitor is not connect (probably > a frequency issue, need to check). > > Booting with the external monitor connected creates a "locked up" > display on the internal TFT, and a flickering display on the > external > screen as if the watermark levels are not set correctly. The > external screen shows a horizontal offset of approximately half the > screen > width (scrolled to the right), but jumps back to its correct > position irregularly. Note that this type of flickering is different > from the flicker > created by panning on the 835GM (already reported this problem), > which shows a regular 30Hz flicker. > > Once the gdm comes up, the internal TFT keeps dead, and the external > shows only a black screen but with a working mouse pointer. > Logging in blindly restores a working screen on both monitors. > > So thanks for the update, seems to have worked, but is still not > working perfectly. External monitors are not supported correctly, > and panning is still a problem, even with a "linear" framebuffer. My drm-intel git branch doesn't yet have the two patches that are meant to replace your ns2501 hack ... So I'm not too sure what exactly you've tested that made things magically better? For me the key to get rid of the black screen was the two sna patches, not the kernel stuff here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: wait for IPS_ENABLE when enabling IPS
On Tue, Oct 08, 2013 at 06:02:30PM -0300, Paulo Zanoni wrote: > 2013/9/20 Daniel Vetter : > > On Fri, Sep 20, 2013 at 12:18:29PM -0300, Paulo Zanoni wrote: > >> 2013/9/20 Daniel Vetter : > >> > On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote: > >> >> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote: > >> >> > From: Paulo Zanoni > >> >> > > >> >> > At the end of haswell_crtc_enable we have an intel_wait_for_vblank > >> >> > with a big comment, and the message suggests it's a workaround for > >> >> > something we don't really understand. So I removed that wait and > >> >> > started getting HW state readout error messages saying that the IPS > >> >> > state is not what we expected. > >> >> > > >> >> > I investigated and concluded that after you write IPS_ENABLE to > >> >> > IPS_CTL, the bit will only actually become 1 on the next vblank. So > >> >> > add code to wait for the IPS_ENABLE bit. We don't really need this > >> >> > wait right now due to the wait I already mentioned, but at least this > >> >> > one has a reason to be there, while the other one is just to > >> >> > workaround some problem: we may remove it in the future. > >> >> > > >> >> > The wait also acts as a POSTING_READ which we missed. > >> >> > > >> >> > Signed-off-by: Paulo Zanoni > >> >> > >> >> Both patches: > >> >> Reviewed-by: Chris Wilson > >> >> > >> >> I was thinking that maybe the intel_wait_for_vblank would be better from > >> >> a documenting perspective - and it would also give warnings for trying > >> >> to enable ips whilst the pipe was off. But you would still need the wait > >> >> for IPS_ENABLE as confirmation anyway. > >> > > >> > Both queued for -next, thanks for the patches&review. > >> > >> Hmmm, this patch depends on the "enable planes only after the pipe is > >> really running" patch. Due to that missing patch, now I get > >> "[drm:hsw_enable_ips] *ERROR* Timed out waiting for IPS enable" when > >> booting. I should have said this, sorry :( > > > > Ok, I've dropped it again. > > It should be safe to merge it now. Done, thanks for the ping. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/hsw: Add I915_EXEC_RESOURCE_STREAMER flag
On Wed, Oct 09, 2013 at 12:09:51AM +0300, Abdiel Janulgue wrote: > Ensures that the batch buffer is executed by the resource streamer. > > Signed-off-by: Abdiel Janulgue > --- > drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 ++ > include/uapi/drm/i915_drm.h|5 + > 2 files changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 0ce0d47..4a56c58 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -962,6 +962,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, > case I915_EXEC_DEFAULT: > case I915_EXEC_RENDER: > ring = &dev_priv->ring[RCS]; > + flags |= (args->flags & I915_EXEC_RESOURCE_STREAMER) ? > + I915_EXEC_RESOURCE_STREAMER : 0; Besides this being flags |= args->flags & I915_EXEC_RESOURCE_STREAMER; flags is a completely different bitfield and you should be translating into a dispatch value rather than the execbuffer value. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] tty/vt: add con_bind and con_unbind functions
2013/10/1 Ville Syrjälä :
> On Thu, Sep 26, 2013 at 08:06:00PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> The consoles who need to do something when unbinding or binding can
>> optionally implement these functions.
>>
>> The current problem I'm trying to solve is that when i915+fbcon is
>> loaded on Haswell, if we disable the power well (to save power) the
>> VGA interface gets completely disabled, so when we unbind fbcon we
>> need to restore the VGA interface to allow vgacon to work.
>
> We don't need to make it work. No one else does, and in the general case
> it's even impossible since on some hardware that would definitely
> corrupt the state that the real driver is attempting to use. The only
> case where it might be nice to restore vgacon is on i915 unload, but no
> one else does that either AFAIK, so I would not waste any cycles on
> attempting that.
I don't understand your point. Without patches 3-4-5, module_reload
doesn't work at all if the power well is disabled: we need these
patches to fix it. The plan is not to restore everything to make
vgacon actually work, the plan is just to prevent it from breaking
module_reload.
>
>>
>> Signed-off-by: Paulo Zanoni
>> ---
>> drivers/tty/vt/vt.c | 6 ++
>> include/linux/console.h | 2 ++
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
>> index 9a8e8c5..beb5986 100644
>> --- a/drivers/tty/vt/vt.c
>> +++ b/drivers/tty/vt/vt.c
>> @@ -3014,6 +3014,9 @@ static int do_bind_con_driver(const struct consw *csw,
>> int first, int last,
>> if (retval)
>> goto err;
>>
>> + if (csw->con_bind)
>> + csw->con_bind();
>> +
>> if (!(con_driver->flag & CON_DRIVER_FLAG_INIT)) {
>> csw->con_startup();
>> con_driver->flag |= CON_DRIVER_FLAG_INIT;
>> @@ -3152,6 +3155,9 @@ int do_unbind_con_driver(const struct consw *csw, int
>> first, int last, int deflt
>> if (!con_is_bound(csw))
>> goto err;
>>
>> + if (csw->con_unbind)
>> + csw->con_unbind();
>> +
>> first = max(first, con_driver->first);
>> last = min(last, con_driver->last);
>>
>> diff --git a/include/linux/console.h b/include/linux/console.h
>> index 7571a16..5cd2c35 100644
>> --- a/include/linux/console.h
>> +++ b/include/linux/console.h
>> @@ -65,6 +65,8 @@ struct consw {
>>* Restore the console to its pre-debug state as closely as possible.
>>*/
>> int (*con_debug_leave)(struct vc_data *);
>> + void(*con_bind)(void);
>> + void(*con_unbind)(void);
>> };
>>
>> extern const struct consw *conswitchp;
>> --
>> 1.8.3.1
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/hsw: Enable resource streamer bit on MI_BATCH_BUFFER_START
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c246727..f3c9103 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -246,6 +246,7 @@
#define MI_BATCH_NON_SECURE_HSW (1<<13)
#define MI_BATCH_BUFFER_START MI_INSTR(0x31, 0)
#define MI_BATCH_GTT (2<<6) /* aliased with (1<<7) on gen4 */
+#define MI_BATCH_RESOURCE_STREAMER (1<<10)
#define MI_SEMAPHORE_MBOX MI_INSTR(0x16, 1) /* gen6+ */
#define MI_SEMAPHORE_GLOBAL_GTT(1<<22)
#define MI_SEMAPHORE_UPDATE (1<<21)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b67104a..c5dd71b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1647,14 +1647,15 @@ hsw_ring_dispatch_execbuffer(struct intel_ring_buffer
*ring,
unsigned flags)
{
int ret;
+ int ring_emit_flags = MI_BATCH_BUFFER_START | MI_BATCH_PPGTT_HSW |
+ (flags & I915_DISPATCH_SECURE ? 0 : MI_BATCH_NON_SECURE_HSW);
ret = intel_ring_begin(ring, 2);
if (ret)
return ret;
- intel_ring_emit(ring,
- MI_BATCH_BUFFER_START | MI_BATCH_PPGTT_HSW |
- (flags & I915_DISPATCH_SECURE ? 0 :
MI_BATCH_NON_SECURE_HSW));
+ intel_ring_emit(ring, ring_emit_flags | (flags &
I915_EXEC_RESOURCE_STREAMER ?
+MI_BATCH_RESOURCE_STREAMER : 0));
/* bit0-7 is the length on GEN6+ */
intel_ring_emit(ring, offset);
intel_ring_advance(ring);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/hsw: Add I915_EXEC_RESOURCE_STREAMER flag
Ensures that the batch buffer is executed by the resource streamer.
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 ++
include/uapi/drm/i915_drm.h|5 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ce0d47..4a56c58 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -962,6 +962,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
case I915_EXEC_DEFAULT:
case I915_EXEC_RENDER:
ring = &dev_priv->ring[RCS];
+ flags |= (args->flags & I915_EXEC_RESOURCE_STREAMER) ?
+ I915_EXEC_RESOURCE_STREAMER : 0;
break;
case I915_EXEC_BSD:
ring = &dev_priv->ring[VCS];
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3a4e97b..5a4bd16 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -731,6 +731,11 @@ struct drm_i915_gem_execbuffer2 {
*/
#define I915_EXEC_HANDLE_LUT (1<<12)
+/** Tell the kernel that the batchbuffer is processed by
+ * the resource streamer.
+ */
+#define I915_EXEC_RESOURCE_STREAMER (1<<13)
+
#define __I915_EXEC_UNKNOWN_FLAGS -(I915_EXEC_HANDLE_LUT<<1)
#define I915_EXEC_CONTEXT_ID_MASK (0x)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915/hsw: Enable resource streamer (v2)
v2 of drm-i915 part of resource streamer enabling. Re-submitted finally now that the Mesa portions are starting to take shape. I also addressed some of the comments from Daniel and Chris from the previous implementation. Cc: Daniel Vetter Cc: Chris Wilson Abdiel Janulgue (2): drm/i915/hsw: Add I915_EXEC_RESOURCE_STREAMER flag drm/i915/hsw: Enable resource streamer bit on MI_BATCH_BUFFER_START -- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++ drivers/gpu/drm/i915/i915_reg.h| 1 + drivers/gpu/drm/i915/intel_ringbuffer.c| 7 --- include/uapi/drm/i915_drm.h| 5 + 4 files changed, 12 insertions(+), 3 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: wait for IPS_ENABLE when enabling IPS
2013/9/20 Daniel Vetter : > On Fri, Sep 20, 2013 at 12:18:29PM -0300, Paulo Zanoni wrote: >> 2013/9/20 Daniel Vetter : >> > On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote: >> >> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote: >> >> > From: Paulo Zanoni >> >> > >> >> > At the end of haswell_crtc_enable we have an intel_wait_for_vblank >> >> > with a big comment, and the message suggests it's a workaround for >> >> > something we don't really understand. So I removed that wait and >> >> > started getting HW state readout error messages saying that the IPS >> >> > state is not what we expected. >> >> > >> >> > I investigated and concluded that after you write IPS_ENABLE to >> >> > IPS_CTL, the bit will only actually become 1 on the next vblank. So >> >> > add code to wait for the IPS_ENABLE bit. We don't really need this >> >> > wait right now due to the wait I already mentioned, but at least this >> >> > one has a reason to be there, while the other one is just to >> >> > workaround some problem: we may remove it in the future. >> >> > >> >> > The wait also acts as a POSTING_READ which we missed. >> >> > >> >> > Signed-off-by: Paulo Zanoni >> >> >> >> Both patches: >> >> Reviewed-by: Chris Wilson >> >> >> >> I was thinking that maybe the intel_wait_for_vblank would be better from >> >> a documenting perspective - and it would also give warnings for trying >> >> to enable ips whilst the pipe was off. But you would still need the wait >> >> for IPS_ENABLE as confirmation anyway. >> > >> > Both queued for -next, thanks for the patches&review. >> >> Hmmm, this patch depends on the "enable planes only after the pipe is >> really running" patch. Due to that missing patch, now I get >> "[drm:hsw_enable_ips] *ERROR* Timed out waiting for IPS enable" when >> booting. I should have said this, sorry :( > > Ok, I've dropped it again. It should be safe to merge it now. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915/ns2501: Update from git working
Hi Daniel, dear kernel developers, just tried the 3.12.rc3+ from the intel-drm git. This version *worked* again, pretty much the same way the 3.10.10 "worked". Side effects are, however, quite the same when you connect an external monitor: If connected while the gdm login screen is on, the external monitor works fine with the internal TFT (mirroring is turned on). Resolutions 1024x768 and 800x600 are fine, switching to 640x480 locks up the internal DVO, the external monitor keeps working. Note that the DVO does *not* lock up if the external monitor is not connect (probably a frequency issue, need to check). Booting with the external monitor connected creates a "locked up" display on the internal TFT, and a flickering display on the external screen as if the watermark levels are not set correctly. The external screen shows a horizontal offset of approximately half the screen width (scrolled to the right), but jumps back to its correct position irregularly. Note that this type of flickering is different from the flicker created by panning on the 835GM (already reported this problem), which shows a regular 30Hz flicker. Once the gdm comes up, the internal TFT keeps dead, and the external shows only a black screen but with a working mouse pointer. Logging in blindly restores a working screen on both monitors. So thanks for the update, seems to have worked, but is still not working perfectly. External monitors are not supported correctly, and panning is still a problem, even with a "linear" framebuffer. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 deadlock on laptop undock
On Tue, Oct 8, 2013 at 6:08 PM, Roland Dreier wrote: > On Mon, Oct 7, 2013 at 11:10 PM, Daniel Vetter wrote: >> Can you please boot with drm.debug=0xe, reproduce the issue and then >> attach the dmesg. The additional debug spam should shed some light on how >> we managed to get into this peculiar situation ... > > Sure, here it is. As suspected a DP screen, and we disconnect right before a modeset sequence. The unexpected thing here is that the modeset santizer kicks in and wreaks utter havoc due to a lid event. Now we shouldn't hang the entire box fundamentally when we unplug the DP cable, and that's a bug in the DP code. It's also quite some work. But we also should be a bit less enthusiastic with wreaking havoc in the lid noifier, and I think that can be fixed quickly. I'll reply with some patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
On 2013-10-08 00:06 (GMT-0400) Felix Miata composed:
Still broken:
Linux gx110 3.11.3-3.gac1d7be-default #1 SMP Fri Oct 4 12:14:40 UTC 2013
(ac1d7be) i686 i686 i386 GNU/Linux
glamor-0.5.1-39.2.i586
intel-gpu-tools-1.3-20.10.i586
libdrm_intel1-2.4.46-121.1.i586
libdrm2-2.4.46-121.1.i586
vaapi-intel-driver-1.2.0-22.8.i586
xf86-video-intel-2.99.903-88.2.i586
xorg-x11-server-7.6_1.14.3-251.15.i586
Linux gx110 3.11.4-1.g40d7ca3-default #1 SMP Sat Oct 5 16:59:29 UTC 2013
(40d7ca3) i686 i686 i386 GNU/Linux
Turns out configuring a screen section in the old pre-KMS format enumerating
desired/selectable modes solves the problem, even enabling virtal (aka KMS
panning). However on exit from the X session back to the ttys, the default
mode set on boot (neither vga= nor video= on {Grub Legacy} cmdline), or one
that was set via vga= (video= is ignored), may or may not restored. When not,
the ttys are left unusable from mismatch between font used and (no longer
correct) rows/columns. Apparently the first X session following boot exits
OK, but not a second.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: make backlight functions take a connector v2
On Sat, 5 Oct 2013 13:04:08 +0200 Daniel Vetter wrote: > On Fri, Oct 4, 2013 at 9:42 PM, Jesse Barnes wrote: > > On VLV/BYT, backlight controls a per-pipe, so when adjusting the > > backlight we need to pass the correct info. So make the externally > > visible backlight functions take a connector argument, which can be used > > internally to figure out the pipe backlight to adjust. > > > > v2: make connector pipe lookup check for NULL crtc (Jani) > > fixup connector check in ASLE code (Jani) > > > > Signed-off-by: Jesse Barnes > > To high-level things that we need to figure out first: > > 1. You're connector->pipe chasing is buggy. You shouldn't chase > intel_connector->encoder since for shared encoders this doesn't > reflect whether the connector is actually connected to that encoder. > Instead check intel_connector->base.encoder for non-NULL, which > guarantees you that you also have a valid crtc. Then getting at the > pipe is simple: > > pipe = to_intel_crtc(intel_connector->base.encoder->crtc); > > so I think we can also ditch your little helper and PIPE_INVALID > (which is good, since otherwise I'll volunteer your for a follow-up > patch to use PIPE_INVALID at a bunch more places ...). > > 2. You can only chase the above pointers if you have the big modeset > lock locked. Which at least for the functions implementing the > backlight sysfs interface seems to not be the case. Ah ok thanks. I actually coded it a couple of times and I think I used the base.encoder first, but then lost that somehow in a rebase. I'll go back to that. Good catch on the locking, I'll see about that too. As for putting this in the connector, yes it really only applies to LVDS and eDP panels (though it could apply to monitors that support the VESA backlight control extensions too, but I don't think we have code for that yet). Anyway all of that is just icing on the cake after the panel bits handle multiple pipes correctly. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGT PATCH] README: list some of the dependencies
Signed-off-by: Jani Nikula --- README | 12 1 file changed, 12 insertions(+) diff --git a/README b/README index 653bfcd..a04c987 100644 --- a/README +++ b/README @@ -96,3 +96,15 @@ debugger/ initiating connections with debug clients.. The debugger must be run as root: "sudo debugger/eudb" + +DEPENDENCIES + This is a non-exchaustive list of package dependencies required for + building everything: + + libpciaccess-dev + libdrm-dev + xutils-dev + libcairo2-dev + swig2.0 + libpython3.3-dev + x11proto-dri2-dev -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGT PATCH 2/2] intel_opregion_decode: decipher bclm table
Signed-off-by: Jani Nikula
---
tools/intel_opregion_decode.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/intel_opregion_decode.c b/tools/intel_opregion_decode.c
index e5f79df..8a9ef20 100644
--- a/tools/intel_opregion_decode.c
+++ b/tools/intel_opregion_decode.c
@@ -258,8 +258,18 @@ static void decode_asle(const void *buffer)
printf("\tcblv:\t0x%08x\n", asle->cblv);
printf("\tbclm:\n");
- for (i = 0; i < ARRAY_SIZE(asle->bclm); i++)
- printf("\t\tbclm[%d]:\t0x%04x\n", i, asle->bclm[i]);
+ for (i = 0; i < ARRAY_SIZE(asle->bclm); i++) {
+ int valid = asle->bclm[i] & (1 << 15);
+ int percentage = (asle->bclm[i] & 0x7f00) >> 8;
+ int duty_cycle = asle->bclm[i] & 0xff;
+
+ printf("\t\tbclm[%d]:\t0x%04x", i, asle->bclm[i]);
+ if (valid)
+ printf(" (%3d%% -> 0x%02x)\n", percentage, duty_cycle);
+ else
+ printf("\n");
+
+ }
printf("\tcpfm:\t0x%08x\n", asle->cpfm);
printf("\tepfm:\t0x%08x\n", asle->epfm);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGT PATCH 0/2] intel_opregion_decode
Finally a tool to decode opregion a bit. This is initially just a structural dump, no real interpretation of the values. But helps immensely. BR, Jani. Jani Nikula (2): intel_opregion_decode: new tool for decoding graphics opregion intel_opregion_decode: decipher bclm table tools/Makefile.am |1 + tools/intel_opregion_decode.c | 448 + 2 files changed, 449 insertions(+) create mode 100644 tools/intel_opregion_decode.c -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGT PATCH 1/2] intel_opregion_decode: new tool for decoding graphics opregion
Signed-off-by: Jani Nikula
---
tools/Makefile.am |1 +
tools/intel_opregion_decode.c | 438 +
2 files changed, 439 insertions(+)
create mode 100644 tools/intel_opregion_decode.c
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 19810cf..59fea97 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -13,6 +13,7 @@ bin_PROGRAMS =\
intel_gpu_top \
intel_gpu_time \
intel_gtt \
+ intel_opregion_decode \
intel_perf_counters \
intel_stepping \
intel_reg_checker \
diff --git a/tools/intel_opregion_decode.c b/tools/intel_opregion_decode.c
new file mode 100644
index 000..e5f79df
--- /dev/null
+++ b/tools/intel_opregion_decode.c
@@ -0,0 +1,438 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Jani Nikula
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "intel_gpu_tools.h"
+
+#define OPREGION_HEADER_OFFSET 0
+#define OPREGION_ACPI_OFFSET 0x100
+#define OPREGION_SWSCI_OFFSET 0x200
+#define OPREGION_ASLE_OFFSET 0x300
+#define OPREGION_VBT_OFFSET0x400
+#define OPREGION_ASLE_EXT_OFFSET 0x1C00
+
+#define MBOX_ACPI (1 << 0)
+#define MBOX_SWSCI (1 << 1)
+#define MBOX_ASLE (1 << 2)
+#define MBOX_VBT (1 << 3)
+#define MBOX_ASLE_EXT (1 << 4)
+
+struct opregion_header {
+ char sign[16];
+ uint32_t size;
+ uint32_t over;
+ char sver[32];
+ char vver[16];
+ char gver[16];
+ uint32_t mbox;
+ uint32_t dmod;
+ uint32_t pcon;
+ char dver[32];
+ uint8_t rsv1[124];
+} __attribute__((packed));
+
+/* OpRegion mailbox #1: public ACPI methods */
+struct opregion_acpi {
+ uint32_t drdy; /* driver readiness */
+ uint32_t csts; /* notification status */
+ uint32_t cevt; /* current event */
+ uint8_t rsvd1[20];
+ uint32_t didl[8]; /* supported display devices ID list */
+ uint32_t cpdl[8]; /* currently presented display list */
+ uint32_t cadl[8]; /* currently active display list */
+ uint32_t nadl[8]; /* next active devices list */
+ uint32_t aslp; /* ASL sleep time-out */
+ uint32_t tidx; /* toggle table index */
+ uint32_t chpd; /* current hotplug enable indicator */
+ uint32_t clid; /* current lid state*/
+ uint32_t cdck; /* current docking state */
+ uint32_t sxsw; /* Sx state resume */
+ uint32_t evts; /* ASL supported events */
+ uint32_t cnot; /* current OS notification */
+ uint32_t nrdy; /* driver status */
+ uint32_t did2[7];
+ uint32_t cpd2[7];
+ uint8_t rsvd2[4];
+} __attribute__((packed));
+
+/* OpRegion mailbox #2: SWSCI */
+struct opregion_swsci {
+ uint32_t scic; /* SWSCI command|status|data */
+ uint32_t parm; /* command parameters */
+ uint32_t dslp; /* driver sleep time-out */
+ uint8_t rsvd[244];
+} __attribute__((packed));
+
+/* OpRegion mailbox #3: ASLE */
+struct opregion_asle {
+ uint32_t ardy; /* driver readiness */
+ uint32_t aslc; /* ASLE interrupt command */
+ uint32_t tche; /* technology enabled indicator */
+ uint32_t alsi; /* current ALS illuminance reading */
+ uint32_t bclp; /* backlight brightness to set */
+ uint32_t pfit; /* panel fitting state */
+ uint32_t cblv; /* current brightn
[Intel-gfx] [IGT PATCH 3/4] intel_bios_reader: dump all sections, including unknown ones
We still need to dump some of the known sections explicitly due to
dependencies on information extracted, such as LFP data pointers and
panel_type.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 30c3470..e906efd 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -779,13 +779,16 @@ static void dump_section(int section_id, int size)
{
struct dumper *dumper = NULL;
const struct bdb_block *block;
+ static int done[256];
int i;
+ if (done[section_id])
+ return;
+ done[section_id] = 1;
+
block = find_section(section_id, size);
- if (!block) {
- printf("No section %d\n", section_id);
+ if (!block)
return;
- }
for (i = 0; i < ARRAY_SIZE(dumpers); i++) {
if (block->id == dumpers[i].id) {
@@ -923,5 +926,8 @@ int main(int argc, char **argv)
dump_section(BDB_DRIVER_FEATURES, size);
dump_section(BDB_EDP, size);
+ for (i = 0; i < 256; i++)
+ dump_section(i, size);
+
return 0;
}
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGT PATCH 4/4] intel_bios_reader: dump all edp device info structs
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 165 +
1 file changed, 93 insertions(+), 72 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index e906efd..19b0fd9 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -535,79 +535,100 @@ static void dump_driver_feature(const struct bdb_block
*block)
static void dump_edp(const struct bdb_block *block)
{
struct bdb_edp *edp = block->data;
- int bpp;
-
- printf("\tPanel type %d\n", panel_type);
- printf("\tPower Sequence: T3 %d T7 %d T9 %d T10 %d T12 %d\n",
- edp->power_seqs[panel_type].t3,
- edp->power_seqs[panel_type].t7,
- edp->power_seqs[panel_type].t9,
- edp->power_seqs[panel_type].t10,
- edp->power_seqs[panel_type].t12);
-
- bpp = (edp->color_depth >> (panel_type * 2)) & 3;
-
- printf("\tPanel color depth: ");
- switch (bpp) {
- case EDP_18BPP:
- printf("18bpp\n");
- break;
- case EDP_24BPP:
- printf("24bpp\n");
- break;
- case EDP_30BPP:
- printf("30bpp\n");
- break;
- }
+ int bpp, msa;
+ int i;
- printf("\teDP sDRRs MSA timing delay: %d\n",
edp->sdrrs_msa_timing_delay);
- printf("\tLink params:\n");
- printf("\t\trate: ");
- if (edp->link_params[panel_type].rate == EDP_RATE_1_62)
- printf("1.62G\n");
- else if (edp->link_params[panel_type].rate == EDP_RATE_2_7)
- printf("2.7G\n");
- printf("\t\tlanes: ");
- switch (edp->link_params[panel_type].lanes) {
- case EDP_LANE_1:
- printf("x1 mode\n");
- break;
- case EDP_LANE_2:
- printf("x2 mode\n");
- break;
- case EDP_LANE_4:
- printf("x4 mode\n");
- break;
- }
- printf("\t\tpre-emphasis: ");
- switch (edp->link_params[panel_type].preemphasis) {
- case EDP_PREEMPHASIS_NONE:
- printf("none\n");
- break;
- case EDP_PREEMPHASIS_3_5dB:
- printf("3.5dB\n");
- break;
- case EDP_PREEMPHASIS_6dB:
- printf("6dB\n");
- break;
- case EDP_PREEMPHASIS_9_5dB:
- printf("9.5dB\n");
- break;
- }
- printf("\t\tvswing: ");
- switch (edp->link_params[panel_type].vswing) {
- case EDP_VSWING_0_4V:
- printf("0.4V\n");
- break;
- case EDP_VSWING_0_6V:
- printf("0.6V\n");
- break;
- case EDP_VSWING_0_8V:
- printf("0.8V\n");
- break;
- case EDP_VSWING_1_2V:
- printf("1.2V\n");
- break;
+ for (i = 0; i < 16; i++) {
+ printf("\tPanel %d%s\n", i, panel_type == i ? " *" : "");
+
+ printf("\t\tPower Sequence: T3 %d T7 %d T9 %d T10 %d T12 %d\n",
+ edp->power_seqs[i].t3,
+ edp->power_seqs[i].t7,
+ edp->power_seqs[i].t9,
+ edp->power_seqs[i].t10,
+ edp->power_seqs[i].t12);
+
+ bpp = (edp->color_depth >> (i * 2)) & 3;
+
+ printf("\t\tPanel color depth: ");
+ switch (bpp) {
+ case EDP_18BPP:
+ printf("18 bpp\n");
+ break;
+ case EDP_24BPP:
+ printf("24 bpp\n");
+ break;
+ case EDP_30BPP:
+ printf("30 bpp\n");
+ break;
+ default:
+ printf("(unknown value %d)\n", bpp);
+ break;
+ }
+
+ msa = (edp->sdrrs_msa_timing_delay >> (i * 2)) & 3;
+ printf("\t\teDP sDRRS MSA Delay: Lane %d\n", msa + 1);
+
+ printf("\t\tLink params:\n");
+ printf("\t\t\trate: ");
+ if (edp->link_params[i].rate == EDP_RATE_1_62)
+ printf("1.62G\n");
+ else if (edp->link_params[i].rate == EDP_RATE_2_7)
+ printf("2.7G\n");
+ printf("\t\t\tlanes: ");
+ switch (edp->link_params[i].lanes) {
+ case EDP_LANE_1:
+ printf("x1 mode\n");
+ break;
+ case EDP_LANE_2:
+ printf("x2 mode\n");
+ break;
+ case EDP_LANE_4:
+ printf("x4 mode\n");
+ break;
+ default:
+ printf("(unknown value %d)\n",
+ edp->link_params[i].lanes);
+ break;
+
[Intel-gfx] [IGT PATCH 2/4] intel_bios_reader: prepare for dumping all sections
Dump sections through a table based on the section id.
Hex dump the section. This works also for unknown sections.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 342 +
1 file changed, 160 insertions(+), 182 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index d30026e..30c3470 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -70,6 +70,7 @@ struct bdb_block {
};
struct bdb_header *bdb;
+struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
static int tv_present;
static int lvds_present;
static int panel_type;
@@ -115,19 +116,9 @@ static struct bdb_block *find_section(int section_id, int
length)
return NULL;
}
-static void dump_general_features(int length)
+static void dump_general_features(const struct bdb_block *block)
{
- struct bdb_general_features *features;
- struct bdb_block *block;
-
- block = find_section(BDB_GENERAL_FEATURES, length);
-
- if (!block)
- return;
-
- features = block->data;
-
- printf("General features block:\n");
+ struct bdb_general_features *features = block->data;
printf("\tPanel fitting: ");
switch (features->panel_fitting) {
@@ -172,25 +163,13 @@ static void dump_general_features(int length)
tv_present = 1; /* should be based on whether TV DAC exists */
lvds_present = 1; /* should be based on IS_MOBILE() */
-
- free(block);
}
-static void dump_backlight_info(int length)
+static void dump_backlight_info(const struct bdb_block *block)
{
- struct bdb_block *block;
- struct bdb_lvds_backlight *backlight;
+ struct bdb_lvds_backlight *backlight = block->data;
struct blc_struct *blc;
- block = find_section(BDB_LVDS_BACKLIGHT, length);
-
- if (!block)
- return;
-
- backlight = block->data;
-
- printf("Backlight info block (len %d):\n", block->size);
-
if (sizeof(struct blc_struct) != backlight->blcstruct_size) {
printf("\tBacklight struct sizes don't match (expected %zu, got
%u), skipping\n",
sizeof(struct blc_struct), backlight->blcstruct_size);
@@ -345,23 +324,13 @@ static void dump_child_device(struct child_device_config
*child)
}
}
-static void dump_general_definitions(int length)
+static void dump_general_definitions(const struct bdb_block *block)
{
- struct bdb_block *block;
- struct bdb_general_definitions *defs;
+ struct bdb_general_definitions *defs = block->data;
struct child_device_config *child;
int i;
int child_device_num;
- block = find_section(BDB_GENERAL_DEFINITIONS, length);
-
- if (!block)
- return;
-
- defs = block->data;
-
- printf("General definitions block:\n");
-
printf("\tCRT DDC GMBUS addr: 0x%02x\n", defs->crt_ddc_gmbus_pin);
printf("\tUse ACPI DPMS CRT power states: %s\n",
YESNO(defs->dpms_acpi));
@@ -374,25 +343,14 @@ static void dump_general_definitions(int length)
child_device_num = (block->size - sizeof(*defs)) / sizeof(*child);
for (i = 0; i < child_device_num; i++)
dump_child_device(&defs->devices[i]);
- free(block);
}
-static void dump_child_devices(int length)
+static void dump_child_devices(const struct bdb_block *block)
{
- struct bdb_block *block;
- struct bdb_child_devices *child_devs;
+ struct bdb_child_devices *child_devs = block->data;
struct child_device_config *child;
int i;
- block = find_section(BDB_CHILD_DEVICE_TABLE, length);
- if (!block) {
- printf("No child device table found\n");
- return;
- }
-
- child_devs = block->data;
-
- printf("Child devices block:\n");
for (i = 0; i < DEVICE_CHILD_SIZE; i++) {
child = &child_devs->children[i];
/* Skip nonexistent children */
@@ -408,24 +366,11 @@ static void dump_child_devices(int length)
printf("\t\tDVO config: 0x%02x\n", child->dvo_cfg);
printf("\t\tDVO wiring: 0x%02x\n", child->dvo_wiring);
}
-
- free(block);
}
-static void dump_lvds_options(int length)
+static void dump_lvds_options(const struct bdb_block *block)
{
- struct bdb_block *block;
- struct bdb_lvds_options *options;
-
- block = find_section(BDB_LVDS_OPTIONS, length);
- if (!block) {
- printf("No LVDS options block\n");
- return;
- }
-
- options = block->data;
-
- printf("LVDS options block:\n");
+ struct bdb_lvds_options *options = block->data;
panel_type = options->panel_type;
printf("\tPanel type: %d\n", panel_type);
@@ -437,54 +382,22 @@ static void dump_lvds_options(int length)
printf("\tPFIT enhanced text mode: %s\n",
[Intel-gfx] [IGT PATCH 1/4] intel_bios_reader: add size temp variable as a shorthand for finfo.st_size
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 46 +++--
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 493fb63..d30026e 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -835,6 +835,7 @@ int main(int argc, char **argv)
int vbt_off, bdb_off, i;
const char *filename = "bios";
struct stat finfo;
+ int size;
struct bdb_block *block;
char signature[17];
char *devid_string;
@@ -860,12 +861,13 @@ int main(int argc, char **argv)
strerror(errno));
return 1;
}
+ size = finfo.st_size;
- if (finfo.st_size == 0) {
+ if (size == 0) {
int len = 0, ret;
- finfo.st_size = 8192;
- VBIOS = malloc (finfo.st_size);
- while ((ret = read(fd, VBIOS + len, finfo.st_size - len))) {
+ size = 8192;
+ VBIOS = malloc (size);
+ while ((ret = read(fd, VBIOS + len, size - len))) {
if (ret < 0) {
printf("failed to read \"%s\": %s\n", filename,
strerror(errno));
@@ -873,13 +875,13 @@ int main(int argc, char **argv)
}
len += ret;
- if (len == finfo.st_size) {
- finfo.st_size *= 2;
- VBIOS = realloc(VBIOS, finfo.st_size);
+ if (len == size) {
+ size *= 2;
+ VBIOS = realloc(VBIOS, size);
}
}
} else {
- VBIOS = mmap(NULL, finfo.st_size, PROT_READ, MAP_SHARED, fd, 0);
+ VBIOS = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
if (VBIOS == MAP_FAILED) {
printf("failed to map \"%s\": %s\n", filename,
strerror(errno));
return 1;
@@ -887,7 +889,7 @@ int main(int argc, char **argv)
}
/* Scour memory looking for the VBT signature */
- for (i = 0; i + 4 < finfo.st_size; i++) {
+ for (i = 0; i + 4 < size; i++) {
if (!memcmp(VBIOS + i, "$VBT", 4)) {
vbt_off = i;
vbt = (struct vbt_header *)(VBIOS + i);
@@ -903,7 +905,7 @@ int main(int argc, char **argv)
printf("VBT vers: %d.%d\n", vbt->version / 100, vbt->version % 100);
bdb_off = vbt_off + vbt->bdb_offset;
- if (bdb_off >= finfo.st_size - sizeof(struct bdb_header)) {
+ if (bdb_off >= size - sizeof(struct bdb_header)) {
printf("Invalid VBT found, BDB points beyond end of data
block\n");
return 1;
}
@@ -916,7 +918,7 @@ int main(int argc, char **argv)
printf("Available sections: ");
for (i = 0; i < 256; i++) {
- block = find_section(i, finfo.st_size);
+ block = find_section(i, size);
if (!block)
continue;
printf("%d ", i);
@@ -929,19 +931,19 @@ int main(int argc, char **argv)
if (devid == -1)
printf("Warning: could not find PCI device ID!\n");
- dump_general_features(finfo.st_size);
- dump_general_definitions(finfo.st_size);
- dump_child_devices(finfo.st_size);
- dump_lvds_options(finfo.st_size);
- dump_lvds_data(finfo.st_size);
- dump_lvds_ptr_data(finfo.st_size);
- dump_backlight_info(finfo.st_size);
+ dump_general_features(size);
+ dump_general_definitions(size);
+ dump_child_devices(size);
+ dump_lvds_options(size);
+ dump_lvds_data(size);
+ dump_lvds_ptr_data(size);
+ dump_backlight_info(size);
- dump_sdvo_lvds_options(finfo.st_size);
- dump_sdvo_panel_dtds(finfo.st_size);
+ dump_sdvo_lvds_options(size);
+ dump_sdvo_panel_dtds(size);
- dump_driver_feature(finfo.st_size);
- dump_edp(finfo.st_size);
+ dump_driver_feature(size);
+ dump_edp(size);
return 0;
}
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGT PATCH 0/4] intel_bios_reader updates
Add some verbosity to the bios reader, and hex dump also the sections we currently don't parse. BR, Jani. Jani Nikula (4): intel_bios_reader: add size temp variable as a shorthand for finfo.st_size intel_bios_reader: prepare for dumping all sections intel_bios_reader: dump all sections, including unknown ones intel_bios_reader: dump all edp device info structs tools/intel_bios_reader.c | 533 +++-- 1 file changed, 270 insertions(+), 263 deletions(-) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Keep intel_drv.h tidy
On Tue, Oct 08, 2013 at 02:45:33PM -0300, Paulo Zanoni wrote: > 2013/10/8 Daniel Vetter : > > Something already got misplaced (although it's from a patch from > > before Paulo's cleanup). Move it to the right spot. > > > > Reported-by: Paulo Zanoni > > Cc: Paulo Zanoni > > Signed-off-by: Daniel Vetter > > We could argue about that new blank line (I removed them all and no > one complained), but I won't =P. You villian. Of course the other rps stuff is in i915_drv.h -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Keep intel_drv.h tidy
Something already got misplaced (although it's from a patch from before Paulo's cleanup). Move it to the right spot. Reported-by: Paulo Zanoni Cc: Paulo Zanoni Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_drv.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index adfb57c..d5d0763 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -804,6 +804,9 @@ void intel_enable_gt_powersave(struct drm_device *dev); void intel_disable_gt_powersave(struct drm_device *dev); void ironlake_teardown_rc6(struct drm_device *dev); void gen6_update_ring_freq(struct drm_device *dev); +void gen6_rps_idle(struct drm_i915_private *dev_priv); +void gen6_rps_boost(struct drm_i915_private *dev_priv); + void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv); void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv); @@ -827,7 +830,4 @@ int intel_sprite_get_colorkey(struct drm_device *dev, void *data, /* intel_tv.c */ void intel_tv_init(struct drm_device *dev); -void gen6_rps_idle(struct drm_i915_private *dev_priv); -void gen6_rps_boost(struct drm_i915_private *dev_priv); - #endif /* __INTEL_DRV_H__ */ -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Keep intel_drv.h tidy
2013/10/8 Daniel Vetter : > Something already got misplaced (although it's from a patch from > before Paulo's cleanup). Move it to the right spot. > > Reported-by: Paulo Zanoni > Cc: Paulo Zanoni > Signed-off-by: Daniel Vetter We could argue about that new blank line (I removed them all and no one complained), but I won't =P. Reviewed-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_drv.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index adfb57c..d5d0763 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -804,6 +804,9 @@ void intel_enable_gt_powersave(struct drm_device *dev); > void intel_disable_gt_powersave(struct drm_device *dev); > void ironlake_teardown_rc6(struct drm_device *dev); > void gen6_update_ring_freq(struct drm_device *dev); > +void gen6_rps_idle(struct drm_i915_private *dev_priv); > +void gen6_rps_boost(struct drm_i915_private *dev_priv); > + > void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv); > void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv); > > @@ -827,7 +830,4 @@ int intel_sprite_get_colorkey(struct drm_device *dev, > void *data, > /* intel_tv.c */ > void intel_tv_init(struct drm_device *dev); > > -void gen6_rps_idle(struct drm_i915_private *dev_priv); > -void gen6_rps_boost(struct drm_i915_private *dev_priv); > - > #endif /* __INTEL_DRV_H__ */ > -- > 1.8.4.rc3 > -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken in 3.10.10
On 08.10.2013 10:39, Daniel Vetter wrote: On Tue, Oct 8, 2013 at 9:24 AM, Daniel Vetter wrote: I guess step one is to bisect the regression in 3.11. Fixing things on top of 3.10 is imo pointless if later kernels break things harder ... btw the two SNA patches I've just submitted should improve things quite a bit. If that gets rid of the black screen then there's not really a need to do the bisect. I'll try to pull these right now. The system is a bit on the slow side, given its age, and it might take the whole evening. Unfortunately, I won't have it available until next weekend, and then for quite a while. BTW, there is not really any sense in trying to re-program the DVO once it is locked up, the "for" loop around it can simply go away. If it is stuck, nothing will made it un-stuck until the DPLL is again correct, and once the DPLL is correct, it works on first attempt. On a second note: The current ns2501 code also assumes that the display is 1024x768, which is probably *often* correct, but not always correct. Thus, it turns of scaling for this resolution, and turns it on for all others, where the scaling parameters come from the bios of the old lifebook I have here. Would be interesting to see whether this specific DVO was used on a system with any other display resolution, and extract the DVO scaling parameters from there. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: revert vga arbiter changes
On Tue, 2013-10-08 at 17:29 +0100, Chris Wilson wrote: > On Tue, Oct 08, 2013 at 10:18:54AM -0600, Alex Williamson wrote: > > On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote: > > > On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote: > > > > Adding drm/i915 into the vga arbiter chain means that X (in a piece of > > > > well-meant paranoia) will do a get/put on the vga decoding around > > > > _every_ accel call down into the ddx. Which results in some nice > > > > performance disasters [1]. > > > > > > And disables DRI for the system, interferring with the use of OpenGL > > > compositors, playing games, PRIME, etc. This effect is not limited to > > > users of i915, but any system with a dGPU and an igfx enabled Core CPU. > > > > > > I still think we are downplaying the complete and utter disaster caused > > > by X and the patch, and why the revert is required. > > > > I'm failing to understand the disaster myself, can you explain? i915 is > > already attempting to make use of the VGA arbiter, but the code hadn't > > been updated so what it was doing was ineffective. The external > > difference I see is that before i915 incorrectly reported that it was > > not involved in VGA arbitration (even though it still claims VGA > > transactions). With the fixes, it opts-out of MMIO arbitration, but > > requires I/O port arbitration. I'm OK with reverting these and going > > back to the drawing board for v3.13, but what i915 is doing is still > > incorrect and precludes making use of a guest assigned VGA device (or > > separate display server requiring VGA), because we can't use the VGA > > arbiter for what it's designed to do, re-route VGA accesses. Thanks, > > The problem stems from the system reporting to X that there are two > legacy vga IO capable devices, and then X disabling DRI and wrapping > every operation with vga_get/vga_put. X will do this even if it is only > using one of the devices and the other device is not being used by the > system. > > We are not arguing that your fix isn't correct, it is just the > rammifications it has to the existing install base outweighs improving > a currently broken feature. Sure, my use case is not a priority. Do you have any thoughts on how we can redesign the interface? For my use for VM access, I'm pretty much resolved and OK with the fact that VGA access is slow. Without para-virtualizing VGA, I can't predict or batch accesses, so I take the arbiter lock for the appropriate resource around each individual access. If the lock is contended, VM boot can be painful, but eventually accelerated drivers take over and VGA access becomes rare. I know Ville was concerned about stopped processes holding the lock when i915 needs it. In my case, that can't happen because the VGA arbiter lock is handled within the VFIO interface. A read/write to the device file descriptor will grab and release the lock internally. It's hard to get around the benefits of knowing your access pattern and batching accesses within a lock, but I wonder if VGA arbiter's lazy switching would be sufficient to provide a general purpose legacy VGA file descriptor that X could open and use for all VGA accesses. For example, pci-sysfs will provide legacy I/O interfaces for some architectures, and I think X already makes use of these. What if they were provided on x86 and allowed read/write to VGA ranges wrapped in VGA arbiter locks? Thanks, Alex ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On 10/08/2013 06:47 PM, Jerome Glisse wrote: On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote: On 10/08/2013 04:55 PM, Jerome Glisse wrote: On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote: Am 08.10.2013 16:33, schrieb Jerome Glisse: On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: Allocate and copy all kernel memory before doing reservations. This prevents a locking inversion between mmap_sem and reservation_class, and allows us to drop the trylocking in ttm_bo_vm_fault without upsetting lockdep. Signed-off-by: Maarten Lankhorst I would say NAK. Current code only allocate temporary page in AGP case. So AGP case is userspace -> temp page -> cs checker -> radeon ib. Non AGP is directly memcpy to radeon IB. Your patch allocate memory memcpy userspace to it and it will then be memcpy to IB. Which means you introduce an extra memcpy in the process not something we want. Totally agree. Additional to that there is no good reason to provide anything else than anonymous system memory to the CS ioctl, so the dependency between the mmap_sem and reservations are not really clear to me. Christian. I think is that in other code path you take mmap_sem first then reserve bo. But here we reserve bo and then we take mmap_sem because of copy >from user. Cheers, Jerome Actually the log message is a little confusing. I think the mmap_sem locking inversion problem is orthogonal to what's being fixed here. This patch fixes the possible recursive bo::reserve caused by malicious user-space handing a pointer to ttm memory so that the ttm fault handler is called when bos are already reserved. That may cause a (possibly interruptible) livelock. Once that is fixed, we are free to choose the mmap_sem -> bo::reserve locking order. Currently it's bo::reserve->mmap_sem(), but the hack required in the ttm fault handler is admittedly a bit ugly. The plan is to change the locking order to mmap_sem->bo::reserve I'm not sure if it applies to this particular case, but it should be possible to make sure that copy_from_user_inatomic() will always succeed, by making sure the pages are present using get_user_pages(), and release the pages after copy_from_user_inatomic() is done. That way there's no need for a double memcpy slowpath, but if the copied data is very fragmented I guess the resulting code may look ugly. The get_user_pages() function will return an error if it hits TTM pages. /Thomas get_user_pages + copy_from_user_inatomic is overkill. We should just do get_user_pages which fails with ttm memory and then use copy_highpage helper. Cheers, Jerome Yeah, it may well be that that's the preferred solution. /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Add separate Kconfig option for fbdev helpers
On Tue, Oct 8, 2013 at 11:44 AM, Daniel Vetter wrote: > For drivers which might want to disable fbdev legacy support. > > Select the new option in all drivers for now, so this shouldn't result > in any change. Drivers need some work anyway to make fbdev support > optional (if they have it implemented, that is), so the recommended > way to expose this is by adding per-driver options. At least as long > as most drivers don't support disabling the fbdev support. > > v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm > driver can already take advantage of this, which allows us to build > msm without any fbdev depencies in the kernel! > > v3: Move the MODULE_* stuff from the fbdev helper file to > drm_crtc_helper.c. > > Cc: David Herrmann > Cc: Rob Clark > Signed-off-by: Daniel Vetter \o/-by: Rob Clark (and also: Reviewed-by: Rob Clark ) > --- > drivers/gpu/drm/Kconfig | 11 ++- > drivers/gpu/drm/Makefile | 3 ++- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig| 1 + > drivers/gpu/drm/drm_crtc_helper.c | 4 > drivers/gpu/drm/drm_fb_helper.c | 4 > drivers/gpu/drm/exynos/Kconfig| 1 + > drivers/gpu/drm/gma500/Kconfig| 1 + > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/msm/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/rcar-du/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig| 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig| 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 19 files changed, 31 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 95d..3104b6d 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -29,11 +29,17 @@ config DRM_USB > config DRM_KMS_HELPER > tristate > depends on DRM > + help > + CRTC helpers for KMS drivers. > + > +config DRM_KMS_FB_HELPER > + bool > + depends on DRM_KMS_HELPER > select FB > select FRAMEBUFFER_CONSOLE if !EXPERT > select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE > help > - FB and CRTC helpers for KMS drivers. > + FBDEV helpers for KMS drivers. > > config DRM_LOAD_EDID_FIRMWARE > bool "Allow to specify an EDID data set instead of probing for it" > @@ -64,6 +70,7 @@ config DRM_GEM_CMA_HELPER > config DRM_KMS_CMA_HELPER > bool > select DRM_GEM_CMA_HELPER > + select DRM_KMS_FB_HELPER > select FB_SYS_FILLRECT > select FB_SYS_COPYAREA > select FB_SYS_IMAGEBLIT > @@ -96,6 +103,7 @@ config DRM_RADEON > select FB_CFB_IMAGEBLIT > select FW_LOADER > select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > select DRM_TTM > select POWER_SUPPLY > select HWMON > @@ -130,6 +138,7 @@ config DRM_I915 > select SHMEM > select TMPFS > select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > select FB_CFB_IMAGEBLIT > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index f089adf..5af240b 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -21,8 +21,9 @@ drm-$(CONFIG_PCI) += ati_pcigart.o > > drm-usb-y := drm_usb.o > > -drm_kms_helper-y := drm_fb_helper.o drm_crtc_helper.o drm_dp_helper.o > +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > +drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o > > obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o > diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig > index da4a51e..8a784c4 100644 > --- a/drivers/gpu/drm/ast/Kconfig > +++ b/drivers/gpu/drm/ast/Kconfig > @@ -6,6 +6,7 @@ config DRM_AST > select FB_SYS_FILLRECT > select FB_SYS_IMAGEBLIT > select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > select DRM_TTM > help > Say yes for experimental AST GPU driver. Do not enable > diff --git a/drivers/gpu/drm/cirrus/Kconfig b/drivers/gpu/drm/cirrus/Kconfig > index bf67b22..9864559 100644 > --- a/drivers/gpu/drm/cirrus/Kconfig > +++ b/drivers/gpu/drm/cirrus/Kconfig > @@ -5,6 +5,7 @@ config DRM_CIRRUS_QEMU > select FB_SYS_COPYAREA > select FB_SYS_IMAGEBLIT > select DRM_KMS_HELPER > + select DRM_KMS_FB_HELPER > select DRM_TTM > help > This is a KMS driver for emulated cirrus device in qemu. > diff --git a/drivers/gpu/drm/drm_crtc_helper.c > b/drivers/gpu/drm/drm_crtc_helper.c > index 4280e37..c4bfd69 100644 >
Re: [Intel-gfx] [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote: > On 10/08/2013 04:55 PM, Jerome Glisse wrote: > >On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote: > >>Am 08.10.2013 16:33, schrieb Jerome Glisse: > >>>On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: > Allocate and copy all kernel memory before doing reservations. This > prevents a locking > inversion between mmap_sem and reservation_class, and allows us to drop > the trylocking > in ttm_bo_vm_fault without upsetting lockdep. > > Signed-off-by: Maarten Lankhorst > >>>I would say NAK. Current code only allocate temporary page in AGP case. > >>>So AGP case is userspace -> temp page -> cs checker -> radeon ib. > >>> > >>>Non AGP is directly memcpy to radeon IB. > >>> > >>>Your patch allocate memory memcpy userspace to it and it will then be > >>>memcpy to IB. Which means you introduce an extra memcpy in the process > >>>not something we want. > >>Totally agree. Additional to that there is no good reason to provide > >>anything else than anonymous system memory to the CS ioctl, so the > >>dependency between the mmap_sem and reservations are not really > >>clear to me. > >> > >>Christian. > >I think is that in other code path you take mmap_sem first then reserve > >bo. But here we reserve bo and then we take mmap_sem because of copy > >from user. > > > >Cheers, > >Jerome > > > Actually the log message is a little confusing. I think the mmap_sem > locking inversion problem is orthogonal to what's being fixed here. > > This patch fixes the possible recursive bo::reserve caused by > malicious user-space handing a pointer to ttm memory so that the ttm > fault handler is called when bos are already reserved. That may > cause a (possibly interruptible) livelock. > > Once that is fixed, we are free to choose the mmap_sem -> > bo::reserve locking order. Currently it's bo::reserve->mmap_sem(), > but the hack required in the ttm fault handler is admittedly a bit > ugly. The plan is to change the locking order to > mmap_sem->bo::reserve > > I'm not sure if it applies to this particular case, but it should be > possible to make sure that copy_from_user_inatomic() will always > succeed, by making sure the pages are present using > get_user_pages(), and release the pages after > copy_from_user_inatomic() is done. That way there's no need for a > double memcpy slowpath, but if the copied data is very fragmented I > guess the resulting code may look ugly. The get_user_pages() > function will return an error if it hits TTM pages. > > /Thomas get_user_pages + copy_from_user_inatomic is overkill. We should just do get_user_pages which fails with ttm memory and then use copy_highpage helper. Cheers, Jerome ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On 10/08/2013 04:55 PM, Jerome Glisse wrote: On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote: Am 08.10.2013 16:33, schrieb Jerome Glisse: On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: Allocate and copy all kernel memory before doing reservations. This prevents a locking inversion between mmap_sem and reservation_class, and allows us to drop the trylocking in ttm_bo_vm_fault without upsetting lockdep. Signed-off-by: Maarten Lankhorst I would say NAK. Current code only allocate temporary page in AGP case. So AGP case is userspace -> temp page -> cs checker -> radeon ib. Non AGP is directly memcpy to radeon IB. Your patch allocate memory memcpy userspace to it and it will then be memcpy to IB. Which means you introduce an extra memcpy in the process not something we want. Totally agree. Additional to that there is no good reason to provide anything else than anonymous system memory to the CS ioctl, so the dependency between the mmap_sem and reservations are not really clear to me. Christian. I think is that in other code path you take mmap_sem first then reserve bo. But here we reserve bo and then we take mmap_sem because of copy from user. Cheers, Jerome Actually the log message is a little confusing. I think the mmap_sem locking inversion problem is orthogonal to what's being fixed here. This patch fixes the possible recursive bo::reserve caused by malicious user-space handing a pointer to ttm memory so that the ttm fault handler is called when bos are already reserved. That may cause a (possibly interruptible) livelock. Once that is fixed, we are free to choose the mmap_sem -> bo::reserve locking order. Currently it's bo::reserve->mmap_sem(), but the hack required in the ttm fault handler is admittedly a bit ugly. The plan is to change the locking order to mmap_sem->bo::reserve I'm not sure if it applies to this particular case, but it should be possible to make sure that copy_from_user_inatomic() will always succeed, by making sure the pages are present using get_user_pages(), and release the pages after copy_from_user_inatomic() is done. That way there's no need for a double memcpy slowpath, but if the copied data is very fragmented I guess the resulting code may look ugly. The get_user_pages() function will return an error if it hits TTM pages. /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: revert vga arbiter changes
On Tue, Oct 08, 2013 at 10:18:54AM -0600, Alex Williamson wrote: > On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote: > > On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote: > > > Adding drm/i915 into the vga arbiter chain means that X (in a piece of > > > well-meant paranoia) will do a get/put on the vga decoding around > > > _every_ accel call down into the ddx. Which results in some nice > > > performance disasters [1]. > > > > And disables DRI for the system, interferring with the use of OpenGL > > compositors, playing games, PRIME, etc. This effect is not limited to > > users of i915, but any system with a dGPU and an igfx enabled Core CPU. > > > > I still think we are downplaying the complete and utter disaster caused > > by X and the patch, and why the revert is required. > > I'm failing to understand the disaster myself, can you explain? i915 is > already attempting to make use of the VGA arbiter, but the code hadn't > been updated so what it was doing was ineffective. The external > difference I see is that before i915 incorrectly reported that it was > not involved in VGA arbitration (even though it still claims VGA > transactions). With the fixes, it opts-out of MMIO arbitration, but > requires I/O port arbitration. I'm OK with reverting these and going > back to the drawing board for v3.13, but what i915 is doing is still > incorrect and precludes making use of a guest assigned VGA device (or > separate display server requiring VGA), because we can't use the VGA > arbiter for what it's designed to do, re-route VGA accesses. Thanks, The problem stems from the system reporting to X that there are two legacy vga IO capable devices, and then X disabling DRI and wrapping every operation with vga_get/vga_put. X will do this even if it is only using one of the devices and the other device is not being used by the system. We are not arguing that your fix isn't correct, it is just the rammifications it has to the existing install base outweighs improving a currently broken feature. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: revert vga arbiter changes
On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote: > On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote: > > Adding drm/i915 into the vga arbiter chain means that X (in a piece of > > well-meant paranoia) will do a get/put on the vga decoding around > > _every_ accel call down into the ddx. Which results in some nice > > performance disasters [1]. > > And disables DRI for the system, interferring with the use of OpenGL > compositors, playing games, PRIME, etc. This effect is not limited to > users of i915, but any system with a dGPU and an igfx enabled Core CPU. > > I still think we are downplaying the complete and utter disaster caused > by X and the patch, and why the revert is required. I'm failing to understand the disaster myself, can you explain? i915 is already attempting to make use of the VGA arbiter, but the code hadn't been updated so what it was doing was ineffective. The external difference I see is that before i915 incorrectly reported that it was not involved in VGA arbitration (even though it still claims VGA transactions). With the fixes, it opts-out of MMIO arbitration, but requires I/O port arbitration. I'm OK with reverting these and going back to the drawing board for v3.13, but what i915 is doing is still incorrect and precludes making use of a guest assigned VGA device (or separate display server requiring VGA), because we can't use the VGA arbiter for what it's designed to do, re-route VGA accesses. Thanks, Alex ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: revert vga arbiter changes
On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote: > Adding drm/i915 into the vga arbiter chain means that X (in a piece of > well-meant paranoia) will do a get/put on the vga decoding around > _every_ accel call down into the ddx. Which results in some nice > performance disasters [1]. And disables DRI for the system, interferring with the use of OpenGL compositors, playing games, PRIME, etc. This effect is not limited to users of i915, but any system with a dGPU and an igfx enabled Core CPU. I still think we are downplaying the complete and utter disaster caused by X and the patch, and why the revert is required. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] fbdev-less i915, take 2
On Tue, Oct 08, 2013 at 05:44:46PM +0200, Daniel Vetter wrote: > Hi all, > > By popular demand (our embedded guys kept asking for this) I've resurrected my > fbdev less patches. Now Rob's msm driver can be completely completely without > CONFIG_FB stuff at all when disabling the fbdev helper support. > > Review highly welcome. I still think this is misleading. fbdev to me is /dev/fb not fbcon. They are related only by implementation. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: rename intel_fb.c to intel_fbdev.c
This file is all about the legacy fbdev support. If we want to extract
framebuffer functions, we better put those into a separate file.
Also rename functions accordingly, only two have used the intel_fb_
prefix anyway.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile| 2 +-
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_drv.h | 8 +-
drivers/gpu/drm/i915/intel_fb.c | 323 ---
drivers/gpu/drm/i915/intel_fbdev.c | 323 +++
6 files changed, 331 insertions(+), 331 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/intel_fb.c
create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 45e14a8..41838ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -53,7 +53,7 @@ i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_ACPI)+= intel_acpi.o
-i915-$(CONFIG_DRM_I915_FBDEV) += intel_fb.o
+i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
obj-$(CONFIG_DRM_I915) += i915.o
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 057ddeb..6744490 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1865,7 +1865,7 @@ void i915_driver_lastclose(struct drm_device * dev)
return;
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
- intel_fb_restore_mode(dev);
+ intel_fbdev_restore_mode(dev);
vga_switcheroo_process_delayed_switch();
return;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 43e4e75..ac50539 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10089,14 +10089,14 @@ intel_user_framebuffer_create(struct drm_device *dev,
}
#ifndef CONFIG_DRM_I915_FBDEV
-static inline void intel_fb_output_poll_changed(struct drm_device *dev)
+static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
}
#endif
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
- .output_poll_changed = intel_fb_output_poll_changed,
+ .output_poll_changed = intel_fbdev_output_poll_changed,
};
/* Set up chip specific display functions */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 181d10b..6a8b027 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -716,14 +716,14 @@ bool intel_dsi_init(struct drm_device *dev);
void intel_dvo_init(struct drm_device *dev);
-/* legacy fbdev emulation in intel_fb.c */
+/* legacy fbdev emulation in intel_fbdev.c */
#ifdef CONFIG_DRM_I915_FBDEV
extern int intel_fbdev_init(struct drm_device *dev);
extern void intel_fbdev_initial_config(struct drm_device *dev);
extern void intel_fbdev_fini(struct drm_device *dev);
extern void intel_fbdev_set_suspend(struct drm_device *dev, int state);
-extern void intel_fb_output_poll_changed(struct drm_device *dev);
-extern void intel_fb_restore_mode(struct drm_device *dev);
+extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
+extern void intel_fbdev_restore_mode(struct drm_device *dev);
#else
static inline int intel_fbdev_init(struct drm_device *dev)
{
@@ -742,7 +742,7 @@ static inline void intel_fbdev_set_suspend(struct
drm_device *dev, int state)
{
}
-static inline void intel_fb_restore_mode(struct drm_device *dev)
+static inline void intel_fbdev_restore_mode(struct drm_device *dev)
{
}
#endif
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
deleted file mode 100644
index d883b77..000
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ /dev/null
@@ -1,323 +0,0 @@
-/*
- * Copyright © 2007 David Airlie
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARI
[Intel-gfx] [PATCH 2/3] drm/i915: Kconfig option to disable the legacy fbdev support
Boots Just Fine (tm)! The only glitch seems to be that at least on Fedora the boot splash gets confused and doesn't display much at all. And since there's no ugly console flickering anymore in between, the flicker while switching between X servers (VT support is still enabled) is even more jarring. Also, I'm unsure whether we don't need to somehow kick out vgacon, now that nothing else gets in the way. But stuff seems to work, so I don't care. Also everything still works as well with VGA_CONSOLE=n Also the #ifdef mess needs a bit of a cleanup, follow-up patches will do just that. To keep the Kconfig tidy, extract all the i915 options into its own file. v2: - Rebase on top of the preliminary hw support option and the intel_drv.h cleanup. - Shut up warnings in i915_debugfs.c Cc: David Herrmann Signed-off-by: Daniel Vetter --- drivers/gpu/drm/Kconfig | 60 +--- drivers/gpu/drm/i915/Kconfig | 67 drivers/gpu/drm/i915/Makefile| 3 +- drivers/gpu/drm/i915/i915_debugfs.c | 9 ++--- drivers/gpu/drm/i915/i915_dma.c | 6 drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_display.c | 10 ++ drivers/gpu/drm/i915/intel_drv.h | 36 +++ 8 files changed, 122 insertions(+), 71 deletions(-) create mode 100644 drivers/gpu/drm/i915/Kconfig diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3104b6d..b4e4fc0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -128,65 +128,7 @@ config DRM_I810 selected, the module will be called i810. AGP support is required for this driver to work. -config DRM_I915 - tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics" - depends on DRM - depends on AGP - depends on AGP_INTEL - # we need shmfs for the swappable backing store, and in particular - # the shmem_readpage() which depends upon tmpfs - select SHMEM - select TMPFS - select DRM_KMS_HELPER - select DRM_KMS_FB_HELPER - select FB_CFB_FILLRECT - select FB_CFB_COPYAREA - select FB_CFB_IMAGEBLIT - # i915 depends on ACPI_VIDEO when ACPI is enabled - # but for select to work, need to select ACPI_VIDEO's dependencies, ick - select BACKLIGHT_LCD_SUPPORT if ACPI - select BACKLIGHT_CLASS_DEVICE if ACPI - select VIDEO_OUTPUT_CONTROL if ACPI - select INPUT if ACPI - select THERMAL if ACPI - select ACPI_VIDEO if ACPI - select ACPI_BUTTON if ACPI - help - Choose this option if you have a system that has "Intel Graphics - Media Accelerator" or "HD Graphics" integrated graphics, - including 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G, - G35, G41, G43, G45 chipsets and Celeron, Pentium, Core i3, - Core i5, Core i7 as well as Atom CPUs with integrated graphics. - If M is selected, the module will be called i915. AGP support - is required for this driver to work. This driver is used by - the Intel driver in X.org 6.8 and XFree86 4.4 and above. It - replaces the older i830 module that supported a subset of the - hardware in older X.org releases. - - Note that the older i810/i815 chipsets require the use of the - i810 driver instead, and the Atom z5xx series has an entirely - different implementation. - -config DRM_I915_KMS - bool "Enable modesetting on intel by default" - depends on DRM_I915 - help - Choose this option if you want kernel modesetting enabled by default, - and you have a new enough userspace to support this. Running old - userspaces with this enabled will cause pain. Note that this causes - the driver to bind to PCI devices, which precludes loading things - like intelfb. - -config DRM_I915_PRELIMINARY_HW_SUPPORT - bool "Enable preliminary support for prerelease Intel hardware by default" - depends on DRM_I915 - help - Choose this option if you have prerelease Intel hardware and want the - i915 driver to support it by default. You can enable such support at - runtime with the module option i915.preliminary_hw_support=1; this - option changes the default for that module option. - - If in doubt, say "N". +source "drivers/gpu/drm/i915/Kconfig" config DRM_MGA tristate "Matrox g200/g400" diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig new file mode 100644 index 000..6199d0b --- /dev/null +++ b/drivers/gpu/drm/i915/Kconfig @@ -0,0 +1,67 @@ +config DRM_I915 + tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics" + depends on DRM + depends on AGP + depends on AGP_INTEL + # we need shmfs for the swappable backing store, and in particular + # the shmem_readpage() which depends upon tmpfs + select SHMEM +
[Intel-gfx] [PATCH 1/3] drm: Add separate Kconfig option for fbdev helpers
For drivers which might want to disable fbdev legacy support.
Select the new option in all drivers for now, so this shouldn't result
in any change. Drivers need some work anyway to make fbdev support
optional (if they have it implemented, that is), so the recommended
way to expose this is by adding per-driver options. At least as long
as most drivers don't support disabling the fbdev support.
v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm
driver can already take advantage of this, which allows us to build
msm without any fbdev depencies in the kernel!
v3: Move the MODULE_* stuff from the fbdev helper file to
drm_crtc_helper.c.
Cc: David Herrmann
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Kconfig | 11 ++-
drivers/gpu/drm/Makefile | 3 ++-
drivers/gpu/drm/ast/Kconfig | 1 +
drivers/gpu/drm/cirrus/Kconfig| 1 +
drivers/gpu/drm/drm_crtc_helper.c | 4
drivers/gpu/drm/drm_fb_helper.c | 4
drivers/gpu/drm/exynos/Kconfig| 1 +
drivers/gpu/drm/gma500/Kconfig| 1 +
drivers/gpu/drm/mgag200/Kconfig | 1 +
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/omapdrm/Kconfig | 1 +
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/rcar-du/Kconfig | 1 +
drivers/gpu/drm/shmobile/Kconfig | 1 +
drivers/gpu/drm/tilcdc/Kconfig| 1 +
drivers/gpu/drm/udl/Kconfig | 1 +
drivers/gpu/host1x/drm/Kconfig| 1 +
drivers/staging/imx-drm/Kconfig | 1 +
19 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..3104b6d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -29,11 +29,17 @@ config DRM_USB
config DRM_KMS_HELPER
tristate
depends on DRM
+ help
+ CRTC helpers for KMS drivers.
+
+config DRM_KMS_FB_HELPER
+ bool
+ depends on DRM_KMS_HELPER
select FB
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
help
- FB and CRTC helpers for KMS drivers.
+ FBDEV helpers for KMS drivers.
config DRM_LOAD_EDID_FIRMWARE
bool "Allow to specify an EDID data set instead of probing for it"
@@ -64,6 +70,7 @@ config DRM_GEM_CMA_HELPER
config DRM_KMS_CMA_HELPER
bool
select DRM_GEM_CMA_HELPER
+ select DRM_KMS_FB_HELPER
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
@@ -96,6 +103,7 @@ config DRM_RADEON
select FB_CFB_IMAGEBLIT
select FW_LOADER
select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
select DRM_TTM
select POWER_SUPPLY
select HWMON
@@ -130,6 +138,7 @@ config DRM_I915
select SHMEM
select TMPFS
select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..5af240b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -21,8 +21,9 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
drm-usb-y := drm_usb.o
-drm_kms_helper-y := drm_fb_helper.o drm_crtc_helper.o drm_dp_helper.o
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
index da4a51e..8a784c4 100644
--- a/drivers/gpu/drm/ast/Kconfig
+++ b/drivers/gpu/drm/ast/Kconfig
@@ -6,6 +6,7 @@ config DRM_AST
select FB_SYS_FILLRECT
select FB_SYS_IMAGEBLIT
select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
select DRM_TTM
help
Say yes for experimental AST GPU driver. Do not enable
diff --git a/drivers/gpu/drm/cirrus/Kconfig b/drivers/gpu/drm/cirrus/Kconfig
index bf67b22..9864559 100644
--- a/drivers/gpu/drm/cirrus/Kconfig
+++ b/drivers/gpu/drm/cirrus/Kconfig
@@ -5,6 +5,7 @@ config DRM_CIRRUS_QEMU
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
select DRM_TTM
help
This is a KMS driver for emulated cirrus device in qemu.
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 4280e37..c4bfd69 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -39,6 +39,10 @@
#include
#include
+MODULE_AUTHOR("David Airlie, Jesse Barnes");
+MODULE_DESCRIPTION("DRM KMS helper");
+MODULE_LICENSE("GPL and additional rights");
+
/**
* drm_helper_move_panel_connectors_to_head() - move panels to the front in the
*
[Intel-gfx] [PATCH 0/3] fbdev-less i915, take 2
Hi all, By popular demand (our embedded guys kept asking for this) I've resurrected my fbdev less patches. Now Rob's msm driver can be completely completely without CONFIG_FB stuff at all when disabling the fbdev helper support. Review highly welcome. Cheers, Daniel Daniel Vetter (3): drm: Add separate Kconfig option for fbdev helpers drm/i915: Kconfig option to disable the legacy fbdev support drm/i915: rename intel_fb.c to intel_fbdev.c drivers/gpu/drm/Kconfig | 69 ++-- drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/ast/Kconfig | 1 + drivers/gpu/drm/cirrus/Kconfig | 1 + drivers/gpu/drm/drm_crtc_helper.c| 4 + drivers/gpu/drm/drm_fb_helper.c | 4 - drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/gma500/Kconfig | 1 + drivers/gpu/drm/i915/Kconfig | 67 drivers/gpu/drm/i915/Makefile| 3 +- drivers/gpu/drm/i915/i915_debugfs.c | 9 +- drivers/gpu/drm/i915/i915_dma.c | 8 +- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/intel_display.c | 12 +- drivers/gpu/drm/i915/intel_drv.h | 36 +++- drivers/gpu/drm/i915/intel_fb.c | 323 --- drivers/gpu/drm/i915/intel_fbdev.c | 323 +++ drivers/gpu/drm/mgag200/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/nouveau/Kconfig | 1 + drivers/gpu/drm/omapdrm/Kconfig | 1 + drivers/gpu/drm/qxl/Kconfig | 1 + drivers/gpu/drm/rcar-du/Kconfig | 1 + drivers/gpu/drm/shmobile/Kconfig | 1 + drivers/gpu/drm/tilcdc/Kconfig | 1 + drivers/gpu/drm/udl/Kconfig | 1 + drivers/gpu/host1x/drm/Kconfig | 1 + drivers/staging/imx-drm/Kconfig | 1 + 28 files changed, 477 insertions(+), 401 deletions(-) create mode 100644 drivers/gpu/drm/i915/Kconfig delete mode 100644 drivers/gpu/drm/i915/intel_fb.c create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c -- 1.8.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: revert vga arbiter changes
Adding drm/i915 into the vga arbiter chain means that X (in a piece of
well-meant paranoia) will do a get/put on the vga decoding around
_every_ accel call down into the ddx. Which results in some nice
performance disasters [1].
Ville tried to come up with a Great Hack to fiddle the required VGA
I/O ops behind everyone's back using stop_machine, but that didn't
really work out [2]. Given that we're fairly late in the -rc stage for
such games let's just revert this all.
This reverts
commit 6e1b4fdad5157bb9e88777d525704aba24389bee
Author: Ville Syrjälä
Date: Thu Sep 5 20:40:52 2013 +0300
drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done
and
commit 81b5c7bc8de3e6f63419139c2fc91bf81dea8a7d
Author: Alex Williamson
Date: Wed Aug 28 09:39:08 2013 -0600
i915: Update VGA arbiter support for newer devices
One thing we might want to keep is to delay the disabling of the vga
decoding until the fbdev emulation and the fbcon screen is set up. If
we kill vga mem decoding beforehand fbcon can end up with a white
square in the top-left corner it tried to save from the vga memory for
a seamless transition. And we have bug reports on older platforms
which seem to match these symptoms.
But again that's something to play around with in -next.
References: [1]
http://lists.x.org/archives/xorg-devel/2013-September/037763.html
References: [2] http://www.spinics.net/lists/intel-gfx/msg34062.html
Cc: Alex Williamson
Cc: Ville Syrjälä
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 15 +++
drivers/gpu/drm/i915/intel_display.c | 30 --
drivers/gpu/drm/i915/intel_drv.h | 1 -
include/linux/vgaarb.h | 7 ---
4 files changed, 3 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index c27a210..d5c784d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1290,12 +1290,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
* then we do not take part in VGA arbitration and the
* vga_client_register() fails with -ENODEV.
*/
- if (!HAS_PCH_SPLIT(dev)) {
- ret = vga_client_register(dev->pdev, dev, NULL,
- i915_vga_set_decode);
- if (ret && ret != -ENODEV)
- goto out;
- }
+ ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode);
+ if (ret && ret != -ENODEV)
+ goto out;
intel_register_dsm_handler();
@@ -1351,12 +1348,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
*/
intel_fbdev_initial_config(dev);
- /*
-* Must do this after fbcon init so that
-* vgacon_save_screen() works during the handover.
-*/
- i915_disable_vga_mem(dev);
-
/* Only enable hotplug handling once the fbdev is fully set up. */
dev_priv->enable_hotplug_processing = true;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c89abd3..581fb4b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10045,33 +10045,6 @@ static void i915_disable_vga(struct drm_device *dev)
POSTING_READ(vga_reg);
}
-static void i915_enable_vga_mem(struct drm_device *dev)
-{
- /* Enable VGA memory on Intel HD */
- if (HAS_PCH_SPLIT(dev)) {
- vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
- outb(inb(VGA_MSR_READ) | VGA_MSR_MEM_EN, VGA_MSR_WRITE);
- vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
- VGA_RSRC_LEGACY_MEM |
- VGA_RSRC_NORMAL_IO |
- VGA_RSRC_NORMAL_MEM);
- vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
- }
-}
-
-void i915_disable_vga_mem(struct drm_device *dev)
-{
- /* Disable VGA memory on Intel HD */
- if (HAS_PCH_SPLIT(dev)) {
- vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
- outb(inb(VGA_MSR_READ) & ~VGA_MSR_MEM_EN, VGA_MSR_WRITE);
- vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
- VGA_RSRC_NORMAL_IO |
- VGA_RSRC_NORMAL_MEM);
- vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
- }
-}
-
void intel_modeset_init_hw(struct drm_device *dev)
{
intel_init_power_well(dev);
@@ -10350,7 +10323,6 @@ void i915_redisable_vga(struct drm_device *dev)
if (I915_READ(vga_reg) != VGA_DISP_DISABLE) {
DRM_DEBUG_KMS("Something enabled VGA plane, disabling it\n");
i915_disable_vga(dev);
- i915_disable_vga_mem(dev);
}
}
@
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Prevent using uninitialized MMIO funcs
On Tue, Oct 08, 2013 at 02:38:22PM +0100, Damien Lespiau wrote: > On Fri, Oct 04, 2013 at 09:22:49PM -0700, Ben Widawsky wrote: > > For upcoming patches which will have GEN specific MMIO functions, we'll > > need to initialize the uncore data structure earlier than we do today. > > > > If we do not do this, the following will be problematic: > > > > intel_uncore_sanitize > > intel_disable_gt_powersave > > gen6_disable_rps > > I915_WRITE(GEN6_RC_CONTROL, 0); <--- MMIO > > intel_uncore_init // initializes MMIO > > > > By initializing the function pointers first, we should be safe. > > > > Signed-off-by: Ben Widawsky > > For the whole series: > > Reviewed-by: Damien Lespiau All merged, thanks for patches&review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On Tue, Oct 8, 2013 at 10:45 AM, Maarten Lankhorst < maarten.lankho...@canonical.com> wrote: > op 08-10-13 16:33, Jerome Glisse schreef: > > On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: > >> Allocate and copy all kernel memory before doing reservations. This > prevents a locking > >> inversion between mmap_sem and reservation_class, and allows us to drop > the trylocking > >> in ttm_bo_vm_fault without upsetting lockdep. > >> > >> Signed-off-by: Maarten Lankhorst > > I would say NAK. Current code only allocate temporary page in AGP case. > > So AGP case is userspace -> temp page -> cs checker -> radeon ib. > > > > Non AGP is directly memcpy to radeon IB. > > > > Your patch allocate memory memcpy userspace to it and it will then be > > memcpy to IB. Which means you introduce an extra memcpy in the process > > not something we want. > > > Can we move up the call to radeon_ib_get then to be done before calling > radeon_cs_parser_relocs? > > ~Maarten > No won't work with the AGP case where we copy one page at a time while cs checker is processing. For AGP we could however go to the 2 memcpy and temp buffer case. For other, we don't know upfront the ib size or the number of ib we want. Cheers, Jerome ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
> Am 08.10.2013 16:33, schrieb Jerome Glisse:
> >On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
> >>Allocate and copy all kernel memory before doing reservations. This
> >>prevents a locking
> >>inversion between mmap_sem and reservation_class, and allows us to drop the
> >>trylocking
> >>in ttm_bo_vm_fault without upsetting lockdep.
> >>
> >>Signed-off-by: Maarten Lankhorst
> >I would say NAK. Current code only allocate temporary page in AGP case.
> >So AGP case is userspace -> temp page -> cs checker -> radeon ib.
> >
> >Non AGP is directly memcpy to radeon IB.
> >
> >Your patch allocate memory memcpy userspace to it and it will then be
> >memcpy to IB. Which means you introduce an extra memcpy in the process
> >not something we want.
>
> Totally agree. Additional to that there is no good reason to provide
> anything else than anonymous system memory to the CS ioctl, so the
> dependency between the mmap_sem and reservations are not really
> clear to me.
>
> Christian.
I think is that in other code path you take mmap_sem first then reserve
bo. But here we reserve bo and then we take mmap_sem because of copy
from user.
Cheers,
Jerome
>
> >Cheers,
> >Jerome
> >
> >>---
> >>diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> >>b/drivers/gpu/drm/radeon/r600_cs.c
> >>index 01a3ec8..efa9bca 100644
> >>--- a/drivers/gpu/drm/radeon/r600_cs.c
> >>+++ b/drivers/gpu/drm/radeon/r600_cs.c
> >>@@ -2391,18 +2391,13 @@ int r600_cs_legacy(struct drm_device *dev, void
> >>*data, struct drm_file *filp,
> >>ib_chunk = &parser.chunks[parser.chunk_ib_idx];
> >>parser.ib.length_dw = ib_chunk->length_dw;
> >>*l = parser.ib.length_dw;
> >>+ memcpy(ib, ib_chunk->kdata, ib_chunk->length_dw * 4);
> >>r = r600_cs_parse(&parser);
> >>if (r) {
> >>DRM_ERROR("Invalid command stream !\n");
> >>r600_cs_parser_fini(&parser, r);
> >>return r;
> >>}
> >>- r = radeon_cs_finish_pages(&parser);
> >>- if (r) {
> >>- DRM_ERROR("Invalid command stream !\n");
> >>- r600_cs_parser_fini(&parser, r);
> >>- return r;
> >>- }
> >>r600_cs_parser_fini(&parser, r);
> >>return r;
> >> }
> >>diff --git a/drivers/gpu/drm/radeon/radeon.h
> >>b/drivers/gpu/drm/radeon/radeon.h
> >>index e067024..c52bb5e 100644
> >>--- a/drivers/gpu/drm/radeon/radeon.h
> >>+++ b/drivers/gpu/drm/radeon/radeon.h
> >>@@ -983,12 +983,7 @@ struct radeon_cs_reloc {
> >> struct radeon_cs_chunk {
> >>uint32_tchunk_id;
> >>uint32_tlength_dw;
> >>- int kpage_idx[2];
> >>- uint32_t*kpage[2];
> >>uint32_t*kdata;
> >>- void __user *user_ptr;
> >>- int last_copied_page;
> >>- int last_page_index;
> >> };
> >> struct radeon_cs_parser {
> >>@@ -1027,8 +1022,13 @@ struct radeon_cs_parser {
> >>struct radeon_sa_bo *cpu_sema;
> >> };
> >>-extern int radeon_cs_finish_pages(struct radeon_cs_parser *p);
> >>-extern u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx);
> >>+static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
> >>+{
> >>+ struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
> >>+
> >>+ return ibc->kdata[idx];
> >>+}
> >>+
> >> struct radeon_cs_packet {
> >>unsignedidx;
> >>diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> >>b/drivers/gpu/drm/radeon/radeon_cs.c
> >>index 7d7322e..98d8898 100644
> >>--- a/drivers/gpu/drm/radeon/radeon_cs.c
> >>+++ b/drivers/gpu/drm/radeon/radeon_cs.c
> >>@@ -217,9 +217,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> >>void *data)
> >>return -EFAULT;
> >>}
> >>p->chunks[i].length_dw = user_chunk.length_dw;
> >>- p->chunks[i].kdata = NULL;
> >>p->chunks[i].chunk_id = user_chunk.chunk_id;
> >>- p->chunks[i].user_ptr = (void __user *)(unsigned
> >>long)user_chunk.chunk_data;
> >>if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) {
> >>p->chunk_relocs_idx = i;
> >>}
> >>@@ -242,25 +240,22 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> >>void *data)
> >>return -EINVAL;
> >>}
> >>- cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
> >>- if ((p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) ||
> >>- (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS)) {
> >>- size = p->chunks[i].length_dw * sizeof(uint32_t);
> >>- p->chunks[i].kdata = kmalloc(size, GFP_KERNEL);
> >>- if (p->chunks[i].kdata == NULL) {
> >>- return -ENOMEM;
> >>- }
> >>- if (DRM_COPY_FROM_USER(p->chunks[i].kdata,
> >>-
Re: [Intel-gfx] [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
op 08-10-13 16:33, Jerome Glisse schreef: > On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: >> Allocate and copy all kernel memory before doing reservations. This prevents >> a locking >> inversion between mmap_sem and reservation_class, and allows us to drop the >> trylocking >> in ttm_bo_vm_fault without upsetting lockdep. >> >> Signed-off-by: Maarten Lankhorst > I would say NAK. Current code only allocate temporary page in AGP case. > So AGP case is userspace -> temp page -> cs checker -> radeon ib. > > Non AGP is directly memcpy to radeon IB. > > Your patch allocate memory memcpy userspace to it and it will then be > memcpy to IB. Which means you introduce an extra memcpy in the process > not something we want. > Can we move up the call to radeon_ib_get then to be done before calling radeon_cs_parser_relocs? ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] drm-intel-collector - review request
Thanks Paulo. Thanks for the suggestion Ben, will do this on next round! On Tue, Oct 8, 2013 at 10:57 AM, Paulo Zanoni wrote: > 2013/10/7 Rodrigo Vivi : >> >> This is another drm-intel-collector push for review: >> http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector >> >> Here goes the list in order for better reviewers assignment: >> >> Patch drm/i915: check that the i965g/gm 4G limit is really obeyed - >> Reviewer: Damien Lespiau >> Patch drm/i915: Asynchronously perform the set-base for a simple modeset >> - Reviewer: I would prefer Ville review this since he had concerns about >> sorround code. switch to fbcon is much faster with this patch so I let it >> here and will try to review by myself if I heard nothing else until next >> update. >> Patch drm/i915: implement another plane WM workaround for HSW - >> Reviewer: If no body else volunteer I'll do this review until next update. >> Patch drm/i915: Use the real cpu max frequency for ring scaling - >> Reviewed by Chris. >> >> Overall Process: >> >> drm-intel-collector - review request >> 1. Daniel pushs drm-intel-testing (every 2 weeks) >> 2. I rebase drm-intel-collector onto drm-intel-testing >> 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you >> should be assigned on a particular patch please don't get mad just tell you >> wont review or volunteer someone else. >> 4. I resubmit remaining patches for review without picking any new >> (drm-intel-collector - review request) >> >> drm-intel-collector - updated >> 5. One week later I collect all simple (1-2) patches that wasn't yet >> reviewed and not queued by Daniel from one testing update until another. >> 6. Request automated QA's PRTS automated i-g-t tests comparing >> drm-intel-testing x drm-intel-collector >> 7. If tests are ok I send the update notification or the patches as a >> series to intel-gfx mailing list for better tracking and to be reviewed. >> (drm-intel-collector - updated) >> 8. Let me know volunteers for review new patches and also let me know if >> I've picked any patch that I shouldn't. >> >> There are some reasons that some patches can be left behind: >> 1. Your patch didn't applied cleanly and I couldn't easily solve the >> conflicts. >> 2. Kernel didn't compiled with your patch. >> 3. I simply missed it. If you believe this is the case please warn me. >> >> Please help me to get these patches reviewed and queued by Daniel. >> >> Also, please let me know if you have further ideas how to improve this >> process. >> >> Thanks in advance, >> Rodrigo. >> >> >> Ben Widawsky (1): >> drm/i915: Use the real cpu max frequency for ring scaling >> >> Chris Wilson (1): >> drm/i915: Asynchronously perform the set-base for a simple modeset >> >> Daniel Vetter (1): >> drm/i915: check that the i965g/gm 4G limit is really obeyed >> >> Paulo Zanoni (1): >> drm/i915: implement another plane WM workaround for HSW > > Please just discard this one, it was replaced by other patches from > Ville, Jani and Paulo. > > > >> >> drivers/gpu/drm/i915/i915_gem.c | 3 +++ >> drivers/gpu/drm/i915/intel_display.c | 20 >> drivers/gpu/drm/i915/intel_pm.c | 17 +++-- >> 3 files changed, 30 insertions(+), 10 deletions(-) >> >> -- >> 1.8.1.4 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Paulo Zanoni -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
> Allocate and copy all kernel memory before doing reservations. This prevents
> a locking
> inversion between mmap_sem and reservation_class, and allows us to drop the
> trylocking
> in ttm_bo_vm_fault without upsetting lockdep.
>
> Signed-off-by: Maarten Lankhorst
I would say NAK. Current code only allocate temporary page in AGP case.
So AGP case is userspace -> temp page -> cs checker -> radeon ib.
Non AGP is directly memcpy to radeon IB.
Your patch allocate memory memcpy userspace to it and it will then be
memcpy to IB. Which means you introduce an extra memcpy in the process
not something we want.
Cheers,
Jerome
> ---
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> b/drivers/gpu/drm/radeon/r600_cs.c
> index 01a3ec8..efa9bca 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -2391,18 +2391,13 @@ int r600_cs_legacy(struct drm_device *dev, void
> *data, struct drm_file *filp,
> ib_chunk = &parser.chunks[parser.chunk_ib_idx];
> parser.ib.length_dw = ib_chunk->length_dw;
> *l = parser.ib.length_dw;
> + memcpy(ib, ib_chunk->kdata, ib_chunk->length_dw * 4);
> r = r600_cs_parse(&parser);
> if (r) {
> DRM_ERROR("Invalid command stream !\n");
> r600_cs_parser_fini(&parser, r);
> return r;
> }
> - r = radeon_cs_finish_pages(&parser);
> - if (r) {
> - DRM_ERROR("Invalid command stream !\n");
> - r600_cs_parser_fini(&parser, r);
> - return r;
> - }
> r600_cs_parser_fini(&parser, r);
> return r;
> }
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index e067024..c52bb5e 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -983,12 +983,7 @@ struct radeon_cs_reloc {
> struct radeon_cs_chunk {
> uint32_tchunk_id;
> uint32_tlength_dw;
> - int kpage_idx[2];
> - uint32_t*kpage[2];
> uint32_t*kdata;
> - void __user *user_ptr;
> - int last_copied_page;
> - int last_page_index;
> };
>
> struct radeon_cs_parser {
> @@ -1027,8 +1022,13 @@ struct radeon_cs_parser {
> struct radeon_sa_bo *cpu_sema;
> };
>
> -extern int radeon_cs_finish_pages(struct radeon_cs_parser *p);
> -extern u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx);
> +static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
> +{
> + struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
> +
> + return ibc->kdata[idx];
> +}
> +
>
> struct radeon_cs_packet {
> unsignedidx;
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 7d7322e..98d8898 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -217,9 +217,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> void *data)
> return -EFAULT;
> }
> p->chunks[i].length_dw = user_chunk.length_dw;
> - p->chunks[i].kdata = NULL;
> p->chunks[i].chunk_id = user_chunk.chunk_id;
> - p->chunks[i].user_ptr = (void __user *)(unsigned
> long)user_chunk.chunk_data;
> if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) {
> p->chunk_relocs_idx = i;
> }
> @@ -242,25 +240,22 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
> void *data)
> return -EINVAL;
> }
>
> - cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
> - if ((p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) ||
> - (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS)) {
> - size = p->chunks[i].length_dw * sizeof(uint32_t);
> - p->chunks[i].kdata = kmalloc(size, GFP_KERNEL);
> - if (p->chunks[i].kdata == NULL) {
> - return -ENOMEM;
> - }
> - if (DRM_COPY_FROM_USER(p->chunks[i].kdata,
> -p->chunks[i].user_ptr, size)) {
> - return -EFAULT;
> - }
> - if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS) {
> - p->cs_flags = p->chunks[i].kdata[0];
> - if (p->chunks[i].length_dw > 1)
> - ring = p->chunks[i].kdata[1];
> - if (p->chunks[i].length_dw > 2)
> - priority = (s32)p->chunks[i].kdata[2];
> - }
> + size = p->chunks[i].length_dw;
> + p->ch
[Intel-gfx] [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 01a3ec8..efa9bca 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2391,18 +2391,13 @@ int r600_cs_legacy(struct drm_device *dev, void *data,
struct drm_file *filp,
ib_chunk = &parser.chunks[parser.chunk_ib_idx];
parser.ib.length_dw = ib_chunk->length_dw;
*l = parser.ib.length_dw;
+ memcpy(ib, ib_chunk->kdata, ib_chunk->length_dw * 4);
r = r600_cs_parse(&parser);
if (r) {
DRM_ERROR("Invalid command stream !\n");
r600_cs_parser_fini(&parser, r);
return r;
}
- r = radeon_cs_finish_pages(&parser);
- if (r) {
- DRM_ERROR("Invalid command stream !\n");
- r600_cs_parser_fini(&parser, r);
- return r;
- }
r600_cs_parser_fini(&parser, r);
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e067024..c52bb5e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -983,12 +983,7 @@ struct radeon_cs_reloc {
struct radeon_cs_chunk {
uint32_tchunk_id;
uint32_tlength_dw;
- int kpage_idx[2];
- uint32_t*kpage[2];
uint32_t*kdata;
- void __user *user_ptr;
- int last_copied_page;
- int last_page_index;
};
struct radeon_cs_parser {
@@ -1027,8 +1022,13 @@ struct radeon_cs_parser {
struct radeon_sa_bo *cpu_sema;
};
-extern int radeon_cs_finish_pages(struct radeon_cs_parser *p);
-extern u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx);
+static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
+{
+ struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
+
+ return ibc->kdata[idx];
+}
+
struct radeon_cs_packet {
unsignedidx;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 7d7322e..98d8898 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -217,9 +217,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return -EFAULT;
}
p->chunks[i].length_dw = user_chunk.length_dw;
- p->chunks[i].kdata = NULL;
p->chunks[i].chunk_id = user_chunk.chunk_id;
- p->chunks[i].user_ptr = (void __user *)(unsigned
long)user_chunk.chunk_data;
if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) {
p->chunk_relocs_idx = i;
}
@@ -242,25 +240,22 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
void *data)
return -EINVAL;
}
- cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
- if ((p->chunks[i].chunk_id == RADEON_CHUNK_ID_RELOCS) ||
- (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS)) {
- size = p->chunks[i].length_dw * sizeof(uint32_t);
- p->chunks[i].kdata = kmalloc(size, GFP_KERNEL);
- if (p->chunks[i].kdata == NULL) {
- return -ENOMEM;
- }
- if (DRM_COPY_FROM_USER(p->chunks[i].kdata,
- p->chunks[i].user_ptr, size)) {
- return -EFAULT;
- }
- if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS) {
- p->cs_flags = p->chunks[i].kdata[0];
- if (p->chunks[i].length_dw > 1)
- ring = p->chunks[i].kdata[1];
- if (p->chunks[i].length_dw > 2)
- priority = (s32)p->chunks[i].kdata[2];
- }
+ size = p->chunks[i].length_dw;
+ p->chunks[i].kdata = drm_malloc_ab(size, sizeof(uint32_t));
+ size *= sizeof(uint32_t);
+ if (p->chunks[i].kdata == NULL) {
+ return -ENOMEM;
+ }
+ cdata = (void __user *)(unsigned long)user_chunk.chunk_data;
+ if (DRM_COPY_FROM_USER(p->chunks[i].kdata, cdata, size)) {
+ return -EFAULT;
+ }
+ if (p->chunks[i].chunk_id == RADEON_CHUNK_ID_FLAGS) {
+ p->cs_flags = p->c
Re: [Intel-gfx] [PATCH 0/4] drm-intel-collector - review request
2013/10/7 Rodrigo Vivi : > > This is another drm-intel-collector push for review: > http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector > > Here goes the list in order for better reviewers assignment: > > Patch drm/i915: check that the i965g/gm 4G limit is really obeyed - > Reviewer: Damien Lespiau > Patch drm/i915: Asynchronously perform the set-base for a simple modeset > - Reviewer: I would prefer Ville review this since he had concerns about > sorround code. switch to fbcon is much faster with this patch so I let it > here and will try to review by myself if I heard nothing else until next > update. > Patch drm/i915: implement another plane WM workaround for HSW - Reviewer: > If no body else volunteer I'll do this review until next update. > Patch drm/i915: Use the real cpu max frequency for ring scaling - > Reviewed by Chris. > > Overall Process: > > drm-intel-collector - review request > 1. Daniel pushs drm-intel-testing (every 2 weeks) > 2. I rebase drm-intel-collector onto drm-intel-testing > 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you > should be assigned on a particular patch please don't get mad just tell you > wont review or volunteer someone else. > 4. I resubmit remaining patches for review without picking any new > (drm-intel-collector - review request) > > drm-intel-collector - updated > 5. One week later I collect all simple (1-2) patches that wasn't yet > reviewed and not queued by Daniel from one testing update until another. > 6. Request automated QA's PRTS automated i-g-t tests comparing > drm-intel-testing x drm-intel-collector > 7. If tests are ok I send the update notification or the patches as a series > to intel-gfx mailing list for better tracking and to be reviewed. > (drm-intel-collector - updated) > 8. Let me know volunteers for review new patches and also let me know if > I've picked any patch that I shouldn't. > > There are some reasons that some patches can be left behind: > 1. Your patch didn't applied cleanly and I couldn't easily solve the > conflicts. > 2. Kernel didn't compiled with your patch. > 3. I simply missed it. If you believe this is the case please warn me. > > Please help me to get these patches reviewed and queued by Daniel. > > Also, please let me know if you have further ideas how to improve this > process. > > Thanks in advance, > Rodrigo. > > > Ben Widawsky (1): > drm/i915: Use the real cpu max frequency for ring scaling > > Chris Wilson (1): > drm/i915: Asynchronously perform the set-base for a simple modeset > > Daniel Vetter (1): > drm/i915: check that the i965g/gm 4G limit is really obeyed > > Paulo Zanoni (1): > drm/i915: implement another plane WM workaround for HSW Please just discard this one, it was replaced by other patches from Ville, Jani and Paulo. > > drivers/gpu/drm/i915/i915_gem.c | 3 +++ > drivers/gpu/drm/i915/intel_display.c | 20 > drivers/gpu/drm/i915/intel_pm.c | 17 +++-- > 3 files changed, 30 insertions(+), 10 deletions(-) > > -- > 1.8.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Prevent using uninitialized MMIO funcs
On Fri, Oct 04, 2013 at 09:22:49PM -0700, Ben Widawsky wrote: > For upcoming patches which will have GEN specific MMIO functions, we'll > need to initialize the uncore data structure earlier than we do today. > > If we do not do this, the following will be problematic: > > intel_uncore_sanitize > intel_disable_gt_powersave > gen6_disable_rps > I915_WRITE(GEN6_RC_CONTROL, 0); <--- MMIO > intel_uncore_init // initializes MMIO > > By initializing the function pointers first, we should be safe. > > Signed-off-by: Ben Widawsky For the whole series: Reviewed-by: Damien Lespiau -- Damien > --- > drivers/gpu/drm/i915/i915_dma.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c > index f221631..0a84cd5 100644 > --- a/drivers/gpu/drm/i915/i915_dma.c > +++ b/drivers/gpu/drm/i915/i915_dma.c > @@ -1621,8 +1621,8 @@ int i915_driver_load(struct drm_device *dev, unsigned > long flags) > > intel_irq_init(dev); > intel_pm_init(dev); > - intel_uncore_sanitize(dev); > intel_uncore_init(dev); > + intel_uncore_sanitize(dev); > > /* Try to make sure MCHBAR is enabled before poking at it */ > intel_setup_mchbar(dev); > -- > 1.8.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: rip out gen2 reset code
On Tue, Oct 08, 2013 at 11:29:41AM +0100, Chris Wilson wrote: > On Tue, Oct 08, 2013 at 12:25:41PM +0200, Daniel Vetter wrote: > > At least on my i830M here it reliably results in hard system hangs > > nowadays. This is much worse than falling back to software rendering, > > so I think we should simply rip this out. > > > > After all we don't have any gpu reset for gen3 either, and there are a > > lot more of those still around. > > > > Cc: Chris Wilson > > Signed-off-by: Daniel Vetter > Acked-by: Chris Wilson Merged, thanks for sanity checking and the quick testrun on your i845g. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/dvo: call ->mode_set callback only when the port is running
On Tue, Oct 08, 2013 at 12:25:42PM +0200, Daniel Vetter wrote: > The ns2501 controller seems to need the dpll and dvo port to accept > the timing update commands. Quick testing on my x30 here seems to > indicate that other dvo controllers don't mind. So let's move the > ->mode_set callback to a place where we have the port up and running > already. > > Signed-off-by: Daniel Vetter It doesn't seem to make the ch7xxx dvo LVDS any worse here. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: rip out gen2 reset code
On Tue, Oct 08, 2013 at 12:25:41PM +0200, Daniel Vetter wrote: > At least on my i830M here it reliably results in hard system hangs > nowadays. This is much worse than falling back to software rendering, > so I think we should simply rip this out. > > After all we don't have any gpu reset for gen3 either, and there are a > lot more of those still around. > > Cc: Chris Wilson > Signed-off-by: Daniel Vetter Acked-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: check that the i965g/gm 4G limit is really obeyed
On Tue, Oct 08, 2013 at 12:06:24PM +0100, Damien Lespiau wrote: > On Mon, Oct 07, 2013 at 05:15:45PM -0300, Rodrigo Vivi wrote: > > From: Daniel Vetter > > > > In truly crazy circumstances shmem might give us the wrong type of > > page. So be a bit paranoid and double check this. > > > > Reviewer: Damien Lespiau > > Cc: Rob Clark > > References: http://lkml.org/lkml/2011/7/11/238 > > Signed-off-by: Daniel Vetter > > Signed-off-by: Rodrigo Vivi > > --- > > drivers/gpu/drm/i915/i915_gem.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 19ecfa8..692ebf7 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -1903,6 +1903,9 @@ i915_gem_object_get_pages_gtt(struct > > drm_i915_gem_object *obj) > > sg->length += PAGE_SIZE; > > } > > last_pfn = page_to_pfn(page); > > + > > + /* Check that the i965g/gm workaround works. */ > > + WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x0010UL)); > > I guess we could have something like last_pfn >= (GB(4) >> PAGE_SHIFT) > but in any case: I was lazy - this is copypasta from gma500 ... > > Reviewed-by: Damien Lespiau Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Undo the PIPEA quirk for i845
On Tue, Oct 08, 2013 at 11:16:59AM +0100, Chris Wilson wrote: > The PIPEA quirk is specifically for the issue with the PIPEB PLL on > 830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA > running. i845 doesn't even have the second PLL or pipe, and enabling > the quirk results in a blank DVO LVDS. > > Signed-off-by: Chris Wilson Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: check that the i965g/gm 4G limit is really obeyed
On Mon, Oct 07, 2013 at 05:15:45PM -0300, Rodrigo Vivi wrote: > From: Daniel Vetter > > In truly crazy circumstances shmem might give us the wrong type of > page. So be a bit paranoid and double check this. > > Reviewer: Damien Lespiau > Cc: Rob Clark > References: http://lkml.org/lkml/2011/7/11/238 > Signed-off-by: Daniel Vetter > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_gem.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 19ecfa8..692ebf7 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -1903,6 +1903,9 @@ i915_gem_object_get_pages_gtt(struct > drm_i915_gem_object *obj) > sg->length += PAGE_SIZE; > } > last_pfn = page_to_pfn(page); > + > + /* Check that the i965g/gm workaround works. */ > + WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x0010UL)); I guess we could have something like last_pfn >= (GB(4) >> PAGE_SHIFT) but in any case: Reviewed-by: Damien Lespiau -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Undo the PIPEA quirk for i845
The PIPEA quirk is specifically for the issue with the PIPEB PLL on
830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA
running. i845 doesn't even have the second PLL or pipe, and enabling
the quirk results in a blank DVO LVDS.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d33b42c1c092..54cfd0ab8797 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10307,8 +10307,7 @@ static struct intel_quirk intel_quirks[] = {
/* ThinkPad T60 needs pipe A force quirk (bug #16494) */
{ 0x2782, 0x17aa, 0x201a, quirk_pipea_force },
- /* 830/845 need to leave pipe A & dpll A up */
- { 0x2562, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
+ /* 830 needs to leave pipe A & dpll A up */
{ 0x3577, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
/* Lenovo U160 cannot use SSC on LVDS */
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/dvo: call ->mode_set callback only when the port is running
The ns2501 controller seems to need the dpll and dvo port to accept
the timing update commands. Quick testing on my x30 here seems to
indicate that other dvo controllers don't mind. So let's move the
->mode_set callback to a place where we have the port up and running
already.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dvo.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 1b64145..3c77365 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -173,11 +173,16 @@ static void intel_enable_dvo(struct intel_encoder
*encoder)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_dvo *intel_dvo = enc_to_dvo(encoder);
+ struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
u32 dvo_reg = intel_dvo->dev.dvo_reg;
u32 temp = I915_READ(dvo_reg);
I915_WRITE(dvo_reg, temp | DVO_ENABLE);
I915_READ(dvo_reg);
+ intel_dvo->dev.dev_ops->mode_set(&intel_dvo->dev,
+&crtc->config.requested_mode,
+&crtc->config.adjusted_mode);
+
intel_dvo->dev.dev_ops->dpms(&intel_dvo->dev, true);
}
@@ -186,6 +191,7 @@ static void intel_dvo_dpms(struct drm_connector *connector,
int mode)
{
struct intel_dvo *intel_dvo = intel_attached_dvo(connector);
struct drm_crtc *crtc;
+ struct intel_crtc_config *config;
/* dvo supports only 2 dpms states. */
if (mode != DRM_MODE_DPMS_ON)
@@ -206,10 +212,16 @@ static void intel_dvo_dpms(struct drm_connector
*connector, int mode)
/* We call connector dpms manually below in case pipe dpms doesn't
* change due to cloning. */
if (mode == DRM_MODE_DPMS_ON) {
+ config = &to_intel_crtc(crtc)->config;
+
intel_dvo->base.connectors_active = true;
intel_crtc_update_dpms(crtc);
+ intel_dvo->dev.dev_ops->mode_set(&intel_dvo->dev,
+&config->requested_mode,
+&config->adjusted_mode);
+
intel_dvo->dev.dev_ops->dpms(&intel_dvo->dev, true);
} else {
intel_dvo->dev.dev_ops->dpms(&intel_dvo->dev, false);
@@ -296,10 +308,6 @@ static void intel_dvo_mode_set(struct intel_encoder
*encoder)
break;
}
- intel_dvo->dev.dev_ops->mode_set(&intel_dvo->dev,
-&crtc->config.requested_mode,
-adjusted_mode);
-
/* Save the data order, since I don't know what it should be set to. */
dvo_val = I915_READ(dvo_reg) &
(DVO_PRESERVE_MASK | DVO_DATA_ORDER_GBRG);
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/ns2501: Rip out the reenable hack
With the change in the modeset sequence this shouldn't be required
any more since the ->mode_set callback now gets called when the dvo
port is fully up and running.
Also limit the retry loop to 10 tries to avoid hanging the machine
while holding important modeset locks.
Cc: Thomas Richter
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/dvo_ns2501.c | 73 +++
1 file changed, 4 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns2501.c
index c4a255b..954acb2 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -87,49 +87,6 @@ struct ns2501_priv {
* when switching the resolution.
*/
-static void enable_dvo(struct intel_dvo_device *dvo)
-{
- struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
- struct i2c_adapter *adapter = dvo->i2c_bus;
- struct intel_gmbus *bus = container_of(adapter,
- struct intel_gmbus,
- adapter);
- struct drm_i915_private *dev_priv = bus->dev_priv;
-
- DRM_DEBUG_KMS("%s: Trying to re-enable the DVO\n", __FUNCTION__);
-
- ns->dvoc = I915_READ(DVO_C);
- ns->pll_a = I915_READ(_DPLL_A);
- ns->srcdim = I915_READ(DVOC_SRCDIM);
- ns->fw_blc = I915_READ(FW_BLC);
-
- I915_WRITE(DVOC, 0x10004084);
- I915_WRITE(_DPLL_A, 0xd082);
- I915_WRITE(DVOC_SRCDIM, 0x400300); // 1024x768
- I915_WRITE(FW_BLC, 0x1080304);
-
- I915_WRITE(DVOC, 0x90004084);
-}
-
-/*
- * Restore the I915 registers modified by the above
- * trigger function.
- */
-static void restore_dvo(struct intel_dvo_device *dvo)
-{
- struct i2c_adapter *adapter = dvo->i2c_bus;
- struct intel_gmbus *bus = container_of(adapter,
- struct intel_gmbus,
- adapter);
- struct drm_i915_private *dev_priv = bus->dev_priv;
- struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
-
- I915_WRITE(DVOC, ns->dvoc);
- I915_WRITE(_DPLL_A, ns->pll_a);
- I915_WRITE(DVOC_SRCDIM, ns->srcdim);
- I915_WRITE(FW_BLC, ns->fw_blc);
-}
-
/*
** Read a register from the ns2501.
** Returns true if successful, false otherwise.
@@ -300,7 +257,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
struct drm_display_mode *adjusted_mode)
{
bool ok;
- bool restore = false;
+ int retries = 10;
struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
DRM_DEBUG_KMS
@@ -476,20 +433,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
ns->reg_8_shadow |= NS2501_8_BPAS;
}
ok &= ns2501_writeb(dvo, NS2501_REG8, ns->reg_8_shadow);
-
- if (!ok) {
- if (restore)
- restore_dvo(dvo);
- enable_dvo(dvo);
- restore = true;
- }
- } while (!ok);
- /*
-* Restore the old i915 registers before
-* forcing the ns2501 on.
-*/
- if (restore)
- restore_dvo(dvo);
+ } while (!ok && retries--);
}
/* set the NS2501 power state */
@@ -510,7 +454,7 @@ static bool ns2501_get_hw_state(struct intel_dvo_device
*dvo)
static void ns2501_dpms(struct intel_dvo_device *dvo, bool enable)
{
bool ok;
- bool restore = false;
+ int retries = 10;
struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
unsigned char ch;
@@ -537,16 +481,7 @@ static void ns2501_dpms(struct intel_dvo_device *dvo, bool
enable)
ok &=
ns2501_writeb(dvo, 0x35,
enable ? 0xff : 0x00);
- if (!ok) {
- if (restore)
- restore_dvo(dvo);
- enable_dvo(dvo);
- restore = true;
- }
- } while (!ok);
-
- if (restore)
- restore_dvo(dvo);
+ } while (!ok && retries--);
}
}
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: rip out gen2 reset code
At least on my i830M here it reliably results in hard system hangs
nowadays. This is much worse than falling back to software rendering,
so I think we should simply rip this out.
After all we don't have any gpu reset for gen3 either, and there are a
lot more of those still around.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_uncore.c | 31 ---
1 file changed, 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 288a3a6..bfc1a65 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -490,36 +490,6 @@ int i915_reg_read_ioctl(struct drm_device *dev,
return 0;
}
-static int i8xx_do_reset(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- if (IS_I85X(dev))
- return -ENODEV;
-
- I915_WRITE(D_STATE, I915_READ(D_STATE) | DSTATE_GFX_RESET_I830);
- POSTING_READ(D_STATE);
-
- if (IS_I830(dev) || IS_845G(dev)) {
- I915_WRITE(DEBUG_RESET_I830,
- DEBUG_RESET_DISPLAY |
- DEBUG_RESET_RENDER |
- DEBUG_RESET_FULL);
- POSTING_READ(DEBUG_RESET_I830);
- msleep(1);
-
- I915_WRITE(DEBUG_RESET_I830, 0);
- POSTING_READ(DEBUG_RESET_I830);
- }
-
- msleep(1);
-
- I915_WRITE(D_STATE, I915_READ(D_STATE) & ~DSTATE_GFX_RESET_I830);
- POSTING_READ(D_STATE);
-
- return 0;
-}
-
static int i965_reset_complete(struct drm_device *dev)
{
u8 gdrst;
@@ -621,7 +591,6 @@ int intel_gpu_reset(struct drm_device *dev)
case 6: return gen6_do_reset(dev);
case 5: return ironlake_do_reset(dev);
case 4: return i965_do_reset(dev);
- case 2: return i8xx_do_reset(dev);
default: return -ENODEV;
}
}
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken in 3.10.10 (was: Questions on display pipes on 835GM)
On Tue, Oct 08, 2013 at 10:39:02AM +0200, Daniel Vetter wrote: > On Tue, Oct 8, 2013 at 9:24 AM, Daniel Vetter wrote: > > I guess step one is to bisect the regression in 3.11. Fixing things on > > top of 3.10 is imo pointless if later kernels break things harder ... > > btw the two SNA patches I've just submitted should improve things > quite a bit. If that gets rid of the black screen then there's not > really a need to do the bisect. No... The blank screen is still a kernel bug. :-p -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken in 3.10.10 (was: Questions on display pipes on 835GM)
On Tue, Oct 8, 2013 at 9:24 AM, Daniel Vetter wrote: > I guess step one is to bisect the regression in 3.11. Fixing things on > top of 3.10 is imo pointless if later kernels break things harder ... btw the two SNA patches I've just submitted should improve things quite a bit. If that gets rid of the black screen then there's not really a need to do the bisect. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] cpufreq: Add dummy cpufreq_cpu_get/put for CONFIG_CPU_FREQ=n
The drm/i915 driver wants to adjust it's own power policies using the
cpu policies as a guideline (we can implicitly boost the cpus through
the gpus on some platforms). To avoid a dreaded select (since a
depends will leave users wondering where where their driver has gone
too) add dummy functions.
Reported-by: kbuild test robot
Cc: kbuild test robot
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
A quick ack for merging this this through the drm-intel tree is
probably the simplest way forward.
-Daniel
---
include/linux/cpufreq.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index fcabc42..5ad9a4e 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -93,8 +93,16 @@ struct cpufreq_policy {
#define CPUFREQ_SHARED_TYPE_ALL (2) /* All dependent CPUs should set
freq */
#define CPUFREQ_SHARED_TYPE_ANY (3) /* Freq can be set from any
dependent CPU*/
+#ifdef CONFIG_CPU_FREQ
struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu);
void cpufreq_cpu_put(struct cpufreq_policy *policy);
+#else
+static inline struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+{
+ return NULL;
+}
+static inline void cpufreq_cpu_put(struct cpufreq_policy *policy) { }
+#endif
static inline bool policy_is_shared(struct cpufreq_policy *policy)
{
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] sna: use 24bit preferred depth on original gen2
In my quick testing both 16 and 15 bit rendering seems to result a lot of non-rendering in the xfce login manager (and some apparent stride-mismatches at 16 bit thrown in for added fun). Until that works better simply opt out the lower-bit modes by default. Cc: Chris Wilson Signed-off-by: Daniel Vetter --- src/sna/sna_driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/sna/sna_driver.c b/src/sna/sna_driver.c index 00d90bf..d72787e 100644 --- a/src/sna/sna_driver.c +++ b/src/sna/sna_driver.c @@ -520,6 +520,9 @@ static Bool sna_pre_init(ScrnInfoPtr scrn, int flags) } preferred_depth = sna->info->gen < 030 ? 15 : 24; + /* i830M seems to be horribly broken with 16/15 bits */ + if (sna->info->gen == 020) + preferred_depth = 24; if (!fb_supports_depth(fd, preferred_depth)) preferred_depth = 24; -- 1.8.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] sna: Disable userspace w/a for i830/845 cs incoherency
In commit c7f7dd61fd07dbf938fc6ba711de07986d35ce1f Author: Chris Wilson Date: Wed Dec 12 19:43:19 2012 + sna: Pin some batches to avoid CS incoherence on 830/845 the in-kernel w/a of pinning batches was duplicated for older kernels. Unfortunately the userspace w/a isn't as good as the kernel one - when restarting X we need to pin a new set of batch buffer objects. Those new batches could potentially have stale tlb entries still in the CS, leading to gpu hangs right after X started. The other problem is that when support for detecting the kernel-based w/a added to be able to opt out of it using the EXEC_IS_PINNED in commit 5b0572503eab235bc7eff20d369241330c41e630 Author: Chris Wilson Date: Sun Dec 16 23:04:55 2012 + sna: Enable support for opting out of the kernel CS workaround the logic in kgem_create_batch was fumbled: Since we always opt out we should unconditionally pin the batches. The end result is that we've ended up with unpinned batches if the kernel implements the w/a :( Instead of fixing the userspace w/a to work even when the kernel w/a is available I've opted to just disable the EXEC_IS_PINNED optimization completely - given the above issues around restarting X it's imo better to be safe than sorry. Cc: Chris Wilson Signed-off-by: Daniel Vetter --- src/sna/kgem.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/sna/kgem.c b/src/sna/kgem.c index 7da05dd..934ab3d 100644 --- a/src/sna/kgem.c +++ b/src/sna/kgem.c @@ -1381,8 +1381,6 @@ void kgem_init(struct kgem *kgem, int fd, struct pci_device *dev, unsigned gen) kgem->batch_flags_base |= LOCAL_I915_EXEC_NO_RELOC; if (kgem->has_handle_lut) kgem->batch_flags_base |= LOCAL_I915_EXEC_HANDLE_LUT; - if (kgem->has_pinned_batches) - kgem->batch_flags_base |= LOCAL_I915_EXEC_IS_PINNED; kgem_init_swizzling(kgem); } -- 1.8.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken in 3.10.10 (was: Questions on display pipes on 835GM)
On Mon, Oct 7, 2013 at 11:58 PM, Thomas Richter wrote: > > Actually, I was testing with the 3.10.10 kernel here. Unfortunately, I need > to tell you that 3.11.4 and 3.12.0-rc.4 does *not work at all*. All I get on > these kernel releases is a blank screen, though with a working mouse cursor. > Apparently, nothing is rendered on the screen at all. Otherwise, it does the > same as 3.10.10, namely lock up if I connect an external monitor during > bootstrap. > > For 3.12.0-rc.4, if I connect the monitor *after* bootup on the gdm login, I > first see nothing on the external screen, and the mouse pointer on the > internal TFT. Then, after logging in blindly, the cursor appears at the > external monitor, the system beeps and then crashes and hangs. > > Thus, sorry, but: broken in 3.11 and up... > > Sorry for the bad news, please try try again. I guess step one is to bisect the regression in 3.11. Fixing things on top of 3.10 is imo pointless if later kernels break things harder ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
