Re: [Intel-gfx] [PATCH-v2 0/3] drm/i915: interlaced mode support

[Peter Ross]

On Fri, Jan 20, 2012 at 10:24:03PM +1100, Peter Ross wrote:
> On Wed, Jan 18, 2012 at 12:55:15PM -0800, Jesse Barnes wrote:
> > On Wed, 18 Jan 2012 18:39:40 -0200
> > Paulo Zanoni  wrote:
> > 
> > > Hi
> > > 
> > > 2012/1/18 Peter Ross :
> > > > This patch set enables enables interlaced mode output on
> > > > generation 3 and above chipsets.
> > > 
> > > I just tested that on HDMI.

Hey Paul, can you confirm which chipset you tested this on. I am keeping
track of who has had successes and fails in the patch comments.

I can also confirm that the patch also works on I915_G and I945_GME
chipsets using VGA out.

> > > The "interlace_allowed=1" patch seems fine: it made xrandr list more
> > > modes. But I believe patch 1 is still not correct. I tested that and
> > > instead of getting a 1920x1080 I got a 1920x1078 mode: vtotal, vblank
> > > and vsync were wrong. If you look at the patch, you'll see that the
> > > code has some "something -= 1" statements. I believe they could be
> > > wrong.
> > > 
> > > So I removed these lines and tested again... Now the mode is actually
> > > 1920x1080, but my monitor's OSD displays it as "1080p". So I also
> > > tested my TV and it reported "1080p@25hz" too.
> > > 
> > > I guess we're still missing something... I'll try to debug.
> 
> Yep. I can confirm this problem too. With PATCH-v2, the output height
> is reduced by two lines. (I used a test bitmap to count the lines on CRT)
> 
> > Yeah for the interlaced case the -1 should be after the multiply, if
> > it's there at all...  would have to double check the docs.
> 
> The docs do suggest the timings need to be subtracted by one line.
> Performing the -1 after the *2 fixes the problem, and this has been tested
> on gen 3 and 4 chipsets.
> 
> When the -1 is removed altogether, the output is the visually identical
> to when the -1 is present. I'm erring on the side of keeping the -1,
> since that makes the implementation consistent with the documentation.

Another data point: The Intel G35 Display Driver for Windows XP does *not*
perform the -1. To determine this I dumped the G35 PCI memory region on
windows, and fed the dump file into intel_reg_dumper.

Cheers,

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fixup assert_pipe to take the pipe A quirk into account

[Keith Packard]

On Sun, 22 Jan 2012 01:36:48 +0100, Daniel Vetter  
wrote:
> This was completely spamming dmesg on my i855gm.

This comes from intel_disable_pll, which wants to turn the pll off, but
if the pipe is still active, it won't be able to. This seems bad to me.

-- 
keith.pack...@intel.com


pgpcpe8pKoTIq.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working

[Alfonso Fiore]

On Sat, Jan 21, 2012 at 10:09 PM, Daniel Vetter  wrote:
>
> Ok, from the above it looks like the VGA input on your TV is dirt-cheap
> and it barely manages to sync at 800x600 and fails already at 1024x768 -
> not even the bios manages to put a picture on your TV :(
>
> To make sure that this is not an issue with the intel gpu, can you maybe
> test the vga input with another machine with different gpu?

Hi Daniel,

I used this TV for the last 3 years connecting each and all my laptops
and I never had a problem running 1024x768 with Windows over VGA (as
an extension of my laptop).
However cheap my VGA input might be, Windows handles it just fine.
My current GPU is ATI mobility radeon HD 3400.
If you want, I can try to run Ubuntu from USB on my laptop and see if
Ubuntu can control my monitor over VGA.
Let me know if this test helps at all (I would prefer to skip it if
the info I provided are enough).

I don't have other desktops.
The only box I can try for POST over VGA is an ALIX
(http://pcengines.ch/) and it also doesn't work very well with my TV
but at least it shows a flickering image.

Again, with laptops and Windows it has been running fine for ages over VGA.

Also: I'm sure you are looking at the big picture, but my goal is for
sure HDMI, not VGA.

> The overscan is expected because your other output HDMI is still at
> 1024x768 and hence your desktop is large enough to fit both.
>
> See the first line starting with "Screen 0:" in the xrandr output for
> current the size of your desktop.

gotcha. Thanks. I didn't know that (but I could have thought about it...)

> Yep, excellent test descriptions! I still need to look at the register
> dumps, but I think another test might be useful:
>
> Only HDMI with nomodeset, then again grab the intel_reg_dump. Iirc that
> works, so it could be useful to see how the bios sets things up with just
> the hdmi cable.

is there a typo? Or maybe I don't understand what you are asking?
"grab the intel_reg_dump. Iirc that works" 
is that intel_reg_dumper?

So you want me to run the same script over HDMI (with only HDMI cable)
with nomeset with all the available resolutions?

> Another thing to try with VGA is whether the higher refresh-rate helps.
> You can select that with --rate, i.e.
>
> xrandr --output VGA1 --mode 1024x768 --rate 60.0

Should I try just with 60? Or also with other values?
Is this test with or without nomodeset (I guess w/o, but better check)?
Only VGA cable? or also HDMI connected? or both cases?

Please detail case conditions.

I'll try maybe tomorrow night.

thank you for your help,
alfonso
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: fixup assert_pipe to take the pipe A quirk into account

[Daniel Vetter]

This was completely spamming dmesg on my i855gm.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5ba19df..1709e67 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -936,6 +936,10 @@ void assert_pipe(struct drm_i915_private *dev_priv,
u32 val;
bool cur_state;
 
+   /* if we need the pipe A quirk it must be always on */
+   if (pipe == PIPE_A && dev_priv->quirks & QUIRK_PIPEA_FORCE)
+   state = true;
+
reg = PIPECONF(pipe);
val = I915_READ(reg);
cur_state = !!(val & PIPECONF_ENABLE);
-- 
1.7.8.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] intel_audio_dump: show more AUD_CONFIG bits

[Daniel Vetter]

On Sat, Jan 21, 2012 at 08:06:38PM -0200, Eugeni Dodonov wrote:
> On Mon, Jan 16, 2012 at 21:19, Wu Fengguang  wrote:
> 
> >
> > Signed-off-by: Wu Fengguang 
> > ---
> >  tools/intel_audio_dump.c |   35 +++
> >  1 file changed, 35 insertions(+)
> >
> 
> Everything looks fine to me, so:
> Reviewed-by: Eugeni Dodonov 

Slurped into i-g-t, thanks.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] intel_audio_dump: show more AUD_CONFIG bits

[Eugeni Dodonov]

On Mon, Jan 16, 2012 at 21:19, Wu Fengguang  wrote:

>
> Signed-off-by: Wu Fengguang 
> ---
>  tools/intel_audio_dump.c |   35 +++
>  1 file changed, 35 insertions(+)
>

Everything looks fine to me, so:
Reviewed-by: Eugeni Dodonov 

-- 
Eugeni Dodonov

___
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: Remove the MI_FLUSH_ENABLE setting.

[Ben Widawsky]

On 01/19/2012 10:50 AM, Eric Anholt wrote:
> We have always been using the wrong bit -- it's bit 12.  However, the
> bit also doesn't do anything -- hardware has always accepted the
> MI_FLUSH command even when it was specced not to.
> 
> Given that there is only one MI_FLUSH emitted in all of the driver
> stack on gen6+ (in i965_video.c of the 2d driver, and it should be
> using other code to do its flush instead), just remove the MI_FLUSH
> enable instead of trying to fix it.
> 
> Signed-off-by: Eric Anholt 
> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c |2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 2df35e3..d21346b 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -389,8 +389,6 @@ static int init_render_ring(struct intel_ring_buffer 
> *ring)
>  
>   if (INTEL_INFO(dev)->gen > 3) {
>   int mode = VS_TIMER_DISPATCH << 16 | VS_TIMER_DISPATCH;
> - if (IS_GEN6(dev) || IS_GEN7(dev))
> - mode |= MI_FLUSH_ENABLE << 16 | MI_FLUSH_ENABLE;
>   I915_WRITE(MI_MODE, mode);
>   if (IS_GEN7(dev))
>   I915_WRITE(GFX_MODE_GEN7,

I'd like to see a tested-by on this with old userspace before pulling
this in. IFF someone does that, r-b me.

Patch 2/2 I still have some gripe with as detailed in that thread.

~Ben
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working

[Daniel Vetter]

On Sat, Jan 21, 2012 at 10:09:16PM +0100, Daniel Vetter wrote:
> On Fri, Jan 20, 2012 at 12:37:25AM +0100, Alfonso Fiore wrote:
> > On Thu, Jan 19, 2012 at 9:50 PM, Daniel Vetter  wrote:
> > >
> > > Ok, please make this _really_ precise, we need to know exactly when things
> > > work and when not. I presume this was showing a perfect screen over the
> > > HDMI cable?
> > 
> > Yes, I was referring to HDMI. In fact, I was never able to see anything 
> > over VGA
> > with this MB + CPU (I never tried VGA with H55 + i3 550 cause HDMI worked
> > but I used VGA from my laptop with the same cable and the same TV).
> > Interestingly, I can always see BIOS and BIOS menu over HDMI
> > but when I connect only VGA I can't see anything also at the BIOS level.
> > So maybe the VGA problem has nothing to do with the driver?
> > [I was wrong, I managed to see something over VGA during these tests]
> > 
> > I'll try to be as precise as I can.
> > 
> > so I created a little script that I will run at each test.
> > 
> > $ cat run_me.sh
> > #!/bin/bash
> > WHEN="`date +%Y%m%d_%H%M%S`"
> > xrandr -q > ./xrand-q.$WHEN.output
> > xrandr --verbose > ./xrand--verbose.$WHEN.output
> > dmesg > ./dmesg.$WHEN.output
> > cp /var/log/Xorg.0.log ./Xorg.0.$WHEN.output
> > cp /sys/devices/pci:00/:00:02.0/drm/card0/card0-VGA-1/edid
> > ./EDID_VGA.$WHEN.output
> > cp /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid
> > ./EDID_HDMI.$WHEN.output
> > $HOME/test_GPU/intel_gpu_tools/intel-gpu-tools-1.1/tools/intel_reg_dumper
> > > ./intel_reg_dumper.$WHEN.output
> > 
> > And attached you can find the whole tgz. Here I simply walk you
> > through my tests.
> > 
> > TEST-01
> > 
> > Only VGA (DVI-I) connected.
> > Changing TV source to VGA.
> > Reboot.
> > Nothing shows on the screen (not even BIOS).
> > But LightDM started (I can connect with VNC).
> > FOLDER=VGA_cable_VGA_source_1024_768
> > 
> > TEST-02
> > 
> > NO reboot
> > NO cable change (Only VGA (DVI-I) connected and TV source to VGA)
> > xrandr --output VGA1 --mode 800x600 (from VNC)
> > well... amazing. I can see the screen. I get no overscan left/right
> > but a bit up/down
> > FOLDER=VGA_cable_VGA_source_800_600
> 
> Ok, from the above it looks like the VGA input on your TV is dirt-cheap
> and it barely manages to sync at 800x600 and fails already at 1024x768 -
> not even the bios manages to put a picture on your TV :(
> 
> To make sure that this is not an issue with the intel gpu, can you maybe
> test the vga input with another machine with different gpu?

Another thing to try with VGA is whether the higher refresh-rate helps.
You can select that with --rate, i.e.

xrandr --output VGA1 --mode 1024x768 --rate 60.0

-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working

[Daniel Vetter]

On Fri, Jan 20, 2012 at 12:37:25AM +0100, Alfonso Fiore wrote:
> On Thu, Jan 19, 2012 at 9:50 PM, Daniel Vetter  wrote:
> >
> > Ok, please make this _really_ precise, we need to know exactly when things
> > work and when not. I presume this was showing a perfect screen over the
> > HDMI cable?
> 
> Yes, I was referring to HDMI. In fact, I was never able to see anything over 
> VGA
> with this MB + CPU (I never tried VGA with H55 + i3 550 cause HDMI worked
> but I used VGA from my laptop with the same cable and the same TV).
> Interestingly, I can always see BIOS and BIOS menu over HDMI
> but when I connect only VGA I can't see anything also at the BIOS level.
> So maybe the VGA problem has nothing to do with the driver?
> [I was wrong, I managed to see something over VGA during these tests]
> 
> I'll try to be as precise as I can.
> 
> so I created a little script that I will run at each test.
> 
> $ cat run_me.sh
> #!/bin/bash
> WHEN="`date +%Y%m%d_%H%M%S`"
> xrandr -q > ./xrand-q.$WHEN.output
> xrandr --verbose > ./xrand--verbose.$WHEN.output
> dmesg > ./dmesg.$WHEN.output
> cp /var/log/Xorg.0.log ./Xorg.0.$WHEN.output
> cp /sys/devices/pci:00/:00:02.0/drm/card0/card0-VGA-1/edid
> ./EDID_VGA.$WHEN.output
> cp /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid
> ./EDID_HDMI.$WHEN.output
> $HOME/test_GPU/intel_gpu_tools/intel-gpu-tools-1.1/tools/intel_reg_dumper
> > ./intel_reg_dumper.$WHEN.output
> 
> And attached you can find the whole tgz. Here I simply walk you
> through my tests.
> 
> TEST-01
> 
> Only VGA (DVI-I) connected.
> Changing TV source to VGA.
> Reboot.
> Nothing shows on the screen (not even BIOS).
> But LightDM started (I can connect with VNC).
> FOLDER=VGA_cable_VGA_source_1024_768
> 
> TEST-02
> 
> NO reboot
> NO cable change (Only VGA (DVI-I) connected and TV source to VGA)
> xrandr --output VGA1 --mode 800x600 (from VNC)
> well... amazing. I can see the screen. I get no overscan left/right
> but a bit up/down
> FOLDER=VGA_cable_VGA_source_800_600

Ok, from the above it looks like the VGA input on your TV is dirt-cheap
and it barely manages to sync at 800x600 and fails already at 1024x768 -
not even the bios manages to put a picture on your TV :(

To make sure that this is not an issue with the intel gpu, can you maybe
test the vga input with another machine with different gpu?

> TEST-03
> 
> connecting both VGA and HDMI
> reboot
> TV source still on VGA so I don't see anything (blue screen)
> connecting over VNC I can see screen is 1024x768
> FOLDER=VGA_HDMI_cables_VGA_source_1024x768
> 
> TEST-04
> 
> NO reboot
> NO cable change
> NO TV source change
> xrandr --output VGA1 --mode 800x600 (from VNC)
> the screen goes from blue to the actual desktop,
> but the TV shows 800x600 while the resolution stays at 1024x768
> so there is huge overscan at bottom and right plus a bit on the top.
> FOLDER=VGA_HDMI_cables_VGA_source_800x600

The overscan is expected because your other output HDMI is still at
1024x768 and hence your desktop is large enough to fit both.

See the first line starting with "Screen 0:" in the xrandr output for
current the size of your desktop.

> since you said "Please ensure that you use the same resolution for both"
> (but I have a feeling I didn't understand you)
> I'll put this back to 1024x768 before running tests on HDMI
> xrandr --output VGA1 --mode 1024x768 (from VNC)
> the screen goes back to blue
> 
> TEST-05
> 
> NO reboot
> NO cable change
> TV source change from TV to HDMI
> the screen is as expected perfect with not a pixel of overscan
> FOLDER=VGA_HDMI_cables_HDMI_source_1024x768
> 
> TEST-06
> 
> NO reboot
> NO cable change
> NO TV source change
> xrandr --output HDMI2 --mode 1280x720 (from VNC)
> the screen shows but with overscan on all four edges
> FOLDER=VGA_HDMI_cables_HDMI_source_1280x720
> 
> TEST-07
> 
> NO reboot
> NO cable change
> NO TV source change
> xrandr --output HDMI2 --mode 800x600 (from VNC)
> this is similar to what happened over VGA:
> the desktop stays 1024x768 but the TV only shows 800x600
> so huge overscan bottom and right
> FOLDER=VGA_HDMI_cables_HDMI_source_800x600

Same as above I suspect.

> when I removed the VGA cable for the next tests the screen
> automatically switched to 1024x768
> I run the script again just in case it gives you some good info:
> FOLDER=HDMI_cable_HDMI_source_1024x768_after_disconnect_VGA
> 
> TEST-08
> 
> connecting only HDMI
> reboot
> login screen is "weird" (I sent the photo already)
> Ah, I didn't realize this earlier! From VNC I see that
> lightDM is running at 1280x720 when it looks "weird"
> when I type my password the screen goes to 1024x768 and now it's black
> (used to be cut in half)
> FOLDER=HDMI_cable_HDMI_source_1024x768
> 
> TEST-09
> 
> NO reboot
> NO cable change
> NO TV source change
> xrandr --output HDMI2 --mode 1280x720 (from VNC)
> weird! The screen stays black (so it doesn't look like 

Re: [Intel-gfx] Updated -next

[Alan W. Irwin]

On 2012-01-21 15:12+0100 Daniel Vetter wrote:


drm-intel-testing is drm-intel-next and drm-intel-fixes merged together
(as the time of when I've pushed things out). Gordon Jin said that he
prefers to qa one single branch and that qa will take the job of finding
out whether an issue has been introduced in -fixes or in -next. I agree
that it makes more sense to test everything together, otherwise you'll
miss some of the bugfixes in -fixes.


As an Intel graphics user whose number-one concern is stability, I
have to make a comment here.  I fully appreciate that the top priority
for qa should be the cutting edge so that Intel developers get quick
feedback on their changes.  But that leaves the -fixes branch untested
_on its own_ by qa, and I urge Gordon Jin to rethink that decision.
After all, the -fixes branch is quite important to the end user of
Intel graphics since it generally propagates sooner than
-intel-testing to the users. Also, doing qa for both -intel-testing
and -fixes should not double the burden on the qa group since -fixes
is much less volatile so doesn't have to be tested nearly as often as
-intel-testing.

In sum, my feeling is that if the -fixes branch is to have any
separate meaning at all, it has to go through the same qa process
(although not as often) as drm-intel-testing.

My $0.02.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
___
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: Correct the bit number for the MI_FLUSH_ENABLE.

[Daniel Vetter]

On Thu, Jan 19, 2012 at 10:50:06AM -0800, Eric Anholt wrote:
> Older specs claimed this was bit 11, but newer specs and the actual
> simulator code say it was bit 12.  Regardless, we don't use MI_FLUSH,
> or try to enable it any more.
> 
> Signed-off-by: Eric Anholt 

I'd like to amend this with the following (on this patch instead of the
other, so that ppl actually can find it with git blame):

"Furthermore actually setting bit12 results in gpu hangs both on snb and
ivb. Ben Widawsky discovered a ppt that claims that both bit12 and bit11
must be set, but that doesn't help either. And last but not least,
MI_FLUSH seems to work regardless of the setting of these bits."

Eric, Ben, is that ok?
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: print out which pixel format we do not support

[Daniel Vetter]

On Tue, Jan 17, 2012 at 03:25:45PM -0200, Eugeni Dodonov wrote:
> Otherwise, we are left with pretty bogus message saying that the pixel
> format is not supported while leaving the details to the telepatic powers.
> 
> v2: use DRM_DEBUG_KMS instead of DRM_ERROR
> 
> Signed-off-by: Eugeni Dodonov 
Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: properly mask and or watermark values for sprites

[Daniel Vetter]

On Thu, Jan 19, 2012 at 04:48:52PM -0800, Keith Packard wrote:
> On Mon, 16 Jan 2012 11:57:54 -0800, Jesse Barnes  
> wrote:
> 
> > Now that we're using the sprite WM fields, we need to take care not to
> > clobber them in the main update_wm functions.  While we're at it, make
> > sure we mask out the old sprite wm value before or'ing in the new one
> > when the sprite wm is updated.
> 
> > 
> > Signed-off-by: Jesse Barnes 
> 
> Reviewed-by: Keith Packard 
Queued for -next, thanks for the patch and review
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: clarify gen2 pageflip cmd

[Daniel Vetter]

On Fri, Jan 20, 2012 at 11:47:59AM -0800, Eric Anholt wrote:
> On Fri, 20 Jan 2012 10:43:44 +0100, Daniel Vetter  
> wrote:
> > I've reviewed gen2 pageflip code do hunt down multple prepare pageflip
> > issues. The only thing I've found is a slight but functionally
> > meaningless confusion about the length of the mi cmd.
> > 
> > Fix it up and add a comment about what this dword should be (according
> > to docs at least).
> > 
> > Signed-Off-by: Daniel Vetter 
> 
> Reviewed-by: Eric Anholt 
Queued for -next (with slightly less spelling fail), thanks for the review.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Updated -next

[Daniel Vetter]

On Sat, Jan 21, 2012 at 04:15:40AM +, Sun, Yi wrote:
> > Hi all,
> > 
> > Not much in the first -next update under the new process, I'd like to
> > tests the qa process first. Highligths:
> > - first part of i9xx_crtc_mode_set refactor from Jesse
> > - quite a few ajax-is-paranoid patches
> > - HAS_LLC param from Eugeni
> > - kill i915_mem.c
> > 
> > For easier testing there's also an updated drm-intel-testing branch with
> > the latest -fixes merged in (i.e. the missed irq patches). Testing
> > feedback highly welcome.
> > 
> > Hi Yi,
> > 
> > Please put the -testing branch through the kernel qa process. Btw I've
> > noticed that the nightly tests are missing a few recent i-g-t tests,
> > please upgrade that.
> > 
> 
> I'm confused about branch drm-intel-testing. Does it mean drm-intel-next
> branch when you said branch drm-intel-testing?

drm-intel-testing is drm-intel-next and drm-intel-fixes merged together
(as the time of when I've pushed things out). Gordon Jin said that he
prefers to qa one single branch and that qa will take the job of finding
out whether an issue has been introduced in -fixes or in -next. I agree
that it makes more sense to test everything together, otherwise you'll
miss some of the bugfixes in -fixes.

-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Second Life / HD Graphics 3000 / Linux / OpenGL

[AW]

i just hacked the file /usr/lib/dri/i965_dri.so
so that it claims to be "Intel HD3000"...
but secondlife crashed after opening a window,
although "Intel Graphics HD 3000" is supported by SL.

isnt there an open source reference implementation of OpenGL?
then Mesa could do it on the CPU until Intel supports linux...

how r they doing it on MacOS?

-arne
___
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: Remove the MI_FLUSH_ENABLE setting.

[Kenneth Graunke]

On 01/19/2012 10:50 AM, Eric Anholt wrote:

We have always been using the wrong bit -- it's bit 12.  However, the
bit also doesn't do anything -- hardware has always accepted the
MI_FLUSH command even when it was specced not to.

Given that there is only one MI_FLUSH emitted in all of the driver
stack on gen6+ (in i965_video.c of the 2d driver, and it should be
using other code to do its flush instead), just remove the MI_FLUSH
enable instead of trying to fix it.

Signed-off-by: Eric Anholt
---
  drivers/gpu/drm/i915/intel_ringbuffer.c |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2df35e3..d21346b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -389,8 +389,6 @@ static int init_render_ring(struct intel_ring_buffer *ring)

if (INTEL_INFO(dev)->gen>  3) {
int mode = VS_TIMER_DISPATCH<<  16 | VS_TIMER_DISPATCH;
-   if (IS_GEN6(dev) || IS_GEN7(dev))
-   mode |= MI_FLUSH_ENABLE<<  16 | MI_FLUSH_ENABLE;
I915_WRITE(MI_MODE, mode);
if (IS_GEN7(dev))
I915_WRITE(GFX_MODE_GEN7,


Everything using MI_FLUSH on SNB+ ought to be converted to PIPE_CONTROL. 
 It sounds like everything except i965_video is there already.  There's 
still the issue of old userspace, but...given that we were setting the 
wrong bit and _not_ setting the actual MI_FLUSH enable bit...it seems 
like this patch shouldn't break things.


I'm all in favor of removing this code, as it's definitely a lie.

For both patches:
Reviewed-by: Kenneth Graunke 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx