date:20120116

On Thu, Jan 12, 2012 at 09:33:34AM -0800, Keith Packard wrote:
 On Tue, 10 Jan 2012 13:45:19 +0800, Wu Fengguang fengguang...@intel.com 
 wrote:
 
  @@ -5943,6 +5947,7 @@ static void ironlake_write_eld(struct dr
  if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
  DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
  eld[5] |= (1  2); /* Conn_Type, 0x1 = DisplayPort */
  +   I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 = DP */
  }
 
 Do we need to clear this bit in the HDMI case? Or do we just trust the
 BIOS to either leave this bit zero or set it correctly?

I tried booting

1) with HDMI monitor plugged
2) plug HDMI monitor after BIOS boot

In both cases, I get the same AUD_CONFIG values for the host/sink matrix

RX-V1800SONY TV
ivybridge   0x  0x
ironlake0x  0x

HDMI audio is working fine in all cases. So I guess it's fine to leave
HDMI as (unconfigured) 0.

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

Re: [Intel-gfx] [Glamor] [PATCH v3] uxa/glamor: Create glamor pixmap by default.

2012-01-16 Thread Chris Wilson

On Thu, 12 Jan 2012 15:30:15 +0800, zhigang.g...@linux.intel.com wrote:
 From: Zhigang Gong zhigang.g...@linux.intel.com
 
 Chris,
 
 According to your previous comments. The X server will not die when
 fail to get a dri buffer for a glamor pixmap, instead it will return
 a BadAlloc. Your previous advice is to pass a BadMatch to the client,
 and I traced into X's dri2 module and found current code can only
 return a BadAlloc. IMHO, this should be ok. Right?

That looks to be the best solution in line with the existing failure
mechanisms along that path.
 
 Another change is to disable the reuse of bo for glamor textured
 pixmap.
 
 The last change is reduce the performance gain. ;), I just found
 another 10-20% is come from my latest glamor patchset. 

Hmm, that does suggest that non-native glamor pixmaps were still in use
and that they were not being marked non-reusable i.e. they weren't DRI
pixmaps.

The patch looks good to me, so I've pushed it to master, thanks.
-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: Fix TV Out refresh rate.

2012-01-16 Thread Rodrigo Vivi

I think we should go ahead and integrate the first and second patches
and skip the 1080 (third) for now.

We are internally discussing when and if that document will be released.

On Fri, Jan 6, 2012 at 8:02 PM, Keith Packard kei...@keithp.com wrote:
 On Wed, 14 Dec 2011 21:10:06 -0200, Rodrigo Vivi rodrigo.v...@gmail.com 
 wrote:
 TV Out refresh rate was half of the specification for almost all modes.
 Due to this reason pixel clock was so low for some modes causing
 flickering screen.

  Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com

 And

  These modes are no longer needed or are not according to TV timing 
 standards.

  Intel PRM Vol 3 - Display Registers Updated - Section 5 TV-Out
  Programming / 5.2.1 Television Standards / 5.2.1.1 Timing tables

  Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com

 I've got these two queued on my machine. Once drm-next is merged to
 master, drm-intel-fixes will be fast-forwarded to that point and these
 fixes rebased on top of that.

 There's still the 1080p modes which Chris has asked for an updated
 changelog and a comment in the source for.

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



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
GPG: 0x905BE242 @ wwwkeys.pgp.net
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/2] drm/i915: interlaced mode support (G35 VGA/SDVO)

On Sat, Jan 14, 2012 at 12:52, Peter Ross pr...@xvid.org wrote:

 This patch set enables enables interlaced mode output on the VGA
 and SDVO connectors of the G35 chipset.

 History here: https://bugs.freedesktop.org/show_bug.cgi?id=11220

 I have tested the changes on an ASUS P5E-VM-HDMI mainboard with VGA
 and HDMI CRTs attached. The G45 and SB documentation suggests that
 this will also work on those chipsets. (Wording of the vertical
 timing registers is near identical). Feedback welcome.

 Peter Ross (2):
  drm/i915: specify vertical timings in frame units for interlaced
modes (gen4+)
  drm/i915: allow interlaced mode output on the SDVO connector

  drivers/gpu/drm/i915/intel_display.c |8 
  drivers/gpu/drm/i915/intel_sdvo.c|2 +-
  2 files changed, 9 insertions(+), 1 deletions(-)


I am not very familiar with this area, but both patches look correct to me
and are according to the specs as far as I can see.

So, for both of them:
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com

Thanks!

P.S.: it would be interested to gather some Tested-by's for this though..

-- 
Eugeni Dodonov
http://eugeni.dodonov.net/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] I've got the RC6 bug

2012-01-16 Thread CC

Hi,

I've heard that you need users having the RC6 bug.

I have the following setup:
CPU: Intel Core i5-2500K
Mainboard: ASRock Z68 Pro3-M
Memory: Corsair Vengeance CMZ8GX3M2A1866C9

Although the CPU doesn't support VT-d, I disabled all virtualization
support in the UEFI setup.

I use Arch Linux and Gnome 3 in the fallback mode. The problem is more
drastic without fallback mode, however.

Whenever I enable RC6, I get the a few of these errors in dmesg:

[   48.90] WARNING: at drivers/gpu/drm/i915/i915_drv.c:387
__gen6_gt_wait_for_fifo+0x94/0xa0 [i915]()
[   48.92] Hardware name: To Be Filled By O.E.M.
[   48.92] Modules linked in: ipv6 fuse ext2 snd_hda_codec_hdmi
snd_hda_codec_realtek mei(C) joydev r8169 shpchp pci_hotplug usbhid hid
snd_hda_intel iTCO_wdt mii iTCO_vendor_support i2c_i801 snd_hda_codec
processor snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc psmouse
serio_raw pcspkr evdev ext4 mbcache jbd2 crc16 xhci_hcd ehci_hcd usbcore
i915 drm_kms_helper drm intel_agp i2c_algo_bit button intel_gtt i2c_core
video sd_mod ahci libahci libata scsi_mod
[   48.900019] Pid: 623, comm: Xorg Tainted: GWC  3.1.9-2-ARCH #1
[   48.900020] Call Trace:
[   48.900023]  [81061bef] warn_slowpath_common+0x7f/0xc0
[   48.900025]  [81061c4a] warn_slowpath_null+0x1a/0x20
[   48.900028]  [a00e0764] __gen6_gt_wait_for_fifo+0x94/0xa0
[i915]
[   48.900032]  [a015d2d5] ring_write_tail+0x65/0x120 [i915]
[   48.900036]  [a01619bc] render_ring_flush+0xbc/0xe0 [i915]
[   48.900040]  [a010b803] i915_gem_flush_ring+0x43/0x250 [i915]
[   48.900044]  [a0112b50]
i915_gem_do_execbuffer.isra.7+0x1020/0x16d0 [i915]
[   48.900048]  [a01136bb] i915_gem_execbuffer2+0x8b/0x240 [i915]
[   48.900051]  [a0098434] drm_ioctl+0x3e4/0x4c0 [drm]
[   48.900053]  [810746cb] ? recalc_sigpending+0x1b/0x50
[   48.900057]  [a0113630] ? i915_gem_execbuffer+0x430/0x430
[i915]
[   48.900059]  [8101e9b1] ? fpu_finit+0x21/0x40
[   48.900061]  [8116fddf] do_vfs_ioctl+0x8f/0x500
[   48.900063]  [81014beb] ? sys_rt_sigreturn+0x1eb/0x200
[   48.900064]  [811702e1] sys_ioctl+0x91/0xa0
[   48.900066]  [8140c3c2] system_call_fastpath+0x16/0x1b
[   48.900067] ---[ end trace 9a23b8b32b16a424 ]---

and then

[   53.163526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
elapsed... GPU hung
[   53.165046] [drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[   53.177356] [drm:i915_wait_request] *ERROR* i915_wait_request returns
-11 (awaiting 1593 at 1592, next 1594)
[   53.181979] [drm:init_ring_common] *ERROR* render ring initialization
failed ctl  head  tail  start 
[   53.185522] [drm:init_ring_common] *ERROR* gen6 bsd ring initialization
failed ctl  head  tail  start 
[   53.188558] [drm:init_ring_common] *ERROR* blt ring initialization
failed ctl  head  tail  start 
[   55.330146] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
elapsed... GPU hung
[   55.332202] [drm:i915_wait_request] *ERROR* i915_wait_request returns
-11 (awaiting 1594 at 1591, next 1595)
[   55.333258] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring
wedged!
[   55.333260] [drm:i915_reset] *ERROR* Failed to reset chip.

Of course, I'd be willing to test out stuff. I'd need a bit of guide,
however.

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

Re: [Intel-gfx] I've got the RC6 bug

On Mon, Jan 16, 2012 at 05:18:17PM +0100, CC wrote:
 Hi,
 
 I've heard that you need users having the RC6 bug.
 
 I have the following setup:
 CPU: Intel Core i5-2500K
 Mainboard: ASRock Z68 Pro3-M
 Memory: Corsair Vengeance CMZ8GX3M2A1866C9
 
 Although the CPU doesn't support VT-d, I disabled all virtualization
 support in the UEFI setup.
 
 I use Arch Linux and Gnome 3 in the fallback mode. The problem is more
 drastic without fallback mode, however.
 
 Whenever I enable RC6, I get the a few of these errors in dmesg:
 
 [   48.90] WARNING: at drivers/gpu/drm/i915/i915_drv.c:387
 __gen6_gt_wait_for_fifo+0x94/0xa0 [i915]()
 [   48.92] Hardware name: To Be Filled By O.E.M.
 [   48.92] Modules linked in: ipv6 fuse ext2 snd_hda_codec_hdmi
 snd_hda_codec_realtek mei(C) joydev r8169 shpchp pci_hotplug usbhid hid
 snd_hda_intel iTCO_wdt mii iTCO_vendor_support i2c_i801 snd_hda_codec
 processor snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc psmouse
 serio_raw pcspkr evdev ext4 mbcache jbd2 crc16 xhci_hcd ehci_hcd usbcore
 i915 drm_kms_helper drm intel_agp i2c_algo_bit button intel_gtt i2c_core
 video sd_mod ahci libahci libata scsi_mod
 [   48.900019] Pid: 623, comm: Xorg Tainted: GWC  3.1.9-2-ARCH #1
 [   48.900020] Call Trace:
 [   48.900023]  [81061bef] warn_slowpath_common+0x7f/0xc0
 [   48.900025]  [81061c4a] warn_slowpath_null+0x1a/0x20
 [   48.900028]  [a00e0764] __gen6_gt_wait_for_fifo+0x94/0xa0
 [i915]
 [   48.900032]  [a015d2d5] ring_write_tail+0x65/0x120 [i915]
 [   48.900036]  [a01619bc] render_ring_flush+0xbc/0xe0 [i915]
 [   48.900040]  [a010b803] i915_gem_flush_ring+0x43/0x250 [i915]
 [   48.900044]  [a0112b50]
 i915_gem_do_execbuffer.isra.7+0x1020/0x16d0 [i915]
 [   48.900048]  [a01136bb] i915_gem_execbuffer2+0x8b/0x240 [i915]
 [   48.900051]  [a0098434] drm_ioctl+0x3e4/0x4c0 [drm]
 [   48.900053]  [810746cb] ? recalc_sigpending+0x1b/0x50
 [   48.900057]  [a0113630] ? i915_gem_execbuffer+0x430/0x430
 [i915]
 [   48.900059]  [8101e9b1] ? fpu_finit+0x21/0x40
 [   48.900061]  [8116fddf] do_vfs_ioctl+0x8f/0x500
 [   48.900063]  [81014beb] ? sys_rt_sigreturn+0x1eb/0x200
 [   48.900064]  [811702e1] sys_ioctl+0x91/0xa0
 [   48.900066]  [8140c3c2] system_call_fastpath+0x16/0x1b
 [   48.900067] ---[ end trace 9a23b8b32b16a424 ]---

This is a known side-effect of a dying gpu. It essentially means that the
gpu refuses to wake up from deep-sleep states.

 and then
 
 [   53.163526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
 elapsed... GPU hung
 [   53.165046] [drm] capturing error event; look for more information in
 /debug/dri/0/i915_error_state
 [   53.177356] [drm:i915_wait_request] *ERROR* i915_wait_request returns
 -11 (awaiting 1593 at 1592, next 1594)
 [   53.181979] [drm:init_ring_common] *ERROR* render ring initialization
 failed ctl  head  tail  start 
 [   53.185522] [drm:init_ring_common] *ERROR* gen6 bsd ring initialization
 failed ctl  head  tail  start 
 [   53.188558] [drm:init_ring_common] *ERROR* blt ring initialization
 failed ctl  head  tail  start 
 [   55.330146] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
 elapsed... GPU hung
 [   55.332202] [drm:i915_wait_request] *ERROR* i915_wait_request returns
 -11 (awaiting 1594 at 1591, next 1595)
 [   55.333258] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring
 wedged!
 [   55.333260] [drm:i915_reset] *ERROR* Failed to reset chip.
 
 Of course, I'd be willing to test out stuff. I'd need a bit of guide,
 however.

Can you please attach i915_error_state from debugfs (you need to retrigger
the issue)? It contains a gpu dump which is useful to diagnose the bug.

Yours, 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] Android port of intel-gpu-tools

2012-01-16 Thread Chad Versace

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/10/2012 08:50 AM, Kavuri, Sateesh wrote:

 -Original Message-
 From: Adam Jackson [mailto:a...@redhat.com]
 Sent: Tuesday, January 10, 2012 8:34 PM
 To: Kavuri, Sateesh
 Cc: intel-gfx@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH] Android port of intel-gpu-tools

 On 1/9/12 11:45 PM, Sateesh Kavuri wrote:
 Added support for Android. Changes include fixes for compilation issues
   related to Android using an older version of GCC compiler (ver 4.3.3)
   while the latest version of intel-gpu-tools confirms to GCC ver 4.5.2
   (C99 standard functions), using functions like getline(). Fixed such
   functions, header dependencies for android and added an Android.mk file.

 I can understand avoiding C99 functions that android doesn't have, but this 
 kind
 of thing:

 +#ifdef ANDROID
 +   int i;
 +   for (i = 1; i  len; i++) {
 +#else
 for (int i = 1; i  len; i++) {
 +#endif

 is silly.  Does gcc -std=c99 on android seriously not cope with this?

 Yes, -std=c99 would help to get rid of such silly checks (would fix it). 
 Continued 
 this, since there has to be a ANDROID definition for checks like fcntl.h 
 header path

 - ajax

 --
 Sateesh

I want to see the C99 workarounds removed.

In Mesa we enabled -std=c99 in the Android build with this hack:
# Use C99.
ifeq ($(LOCAL_CC),)
ifeq ($(LOCAL_IS_HOST_MODULE),true)
LOCAL_CC := $(HOST_CC) -std=c99
else
LOCAL_CC := $(TARGET_CC) -std=c99
endif
endif

- 
Chad Versace
chad.vers...@linux.intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPFGVPAAoJEAIvNt057x8i+6MP/iX2T5Q9z4zeQB4LlgpNKUVO
5Y6Sl/ZC/AyfWFg1u188pPZvSi6jI86wvZg6MPULzP7NVBx/xG5bsexO0zqDRJ7l
PLridgrxOzUbkreN5jzOI0vV+hVcHfJfuOz9YJ5WTq6LHskPpj/fd3sIbZJRJstg
sGPEFU9Nfp2bVteE35ci4ASYPzdisO/O6sWB5RiDkUJRa+xvBm7NrzBeA4TbxD8f
8lRhKUAcmv1AFtFVJHOUoyL+UkjJXRiI19cSnAB6mr3r6Nf+NCvrN+Kp298ze3xM
/VzLv0GdkmcmtPGzursd8VEEgWwWxWTC39QcURsQjf6+eHs57I77T6XC7YILfGOu
bwMRqCSBygVo6MnCcNlzjCPNHATITgDvRbthSiN8tX2wcrndquNKD1+qBlpoFfVg
d/m8TQD8UAravGkDWwmTxnFFeqXM9pktrTpk55gO+ZNQtkK5SbWtJ9F5O6Yn3trb
8opFiFi6rJdORzSV/4Ma8ySeTaWc7JnANzYaB4PXIJOTTTgUukX9ARWJqYIyRnj9
sBZdG1wrRt89Tlk7KGBQ7f3nXIpMwe9aLYmnajbd6xHMTnzXrEuBZ65r320uUXHo
h+mba6lzJuow3TwcyudvjK5yKPmgQ7ZOV7DmT8wW2pwhVUcIjd4xxgEQsV4xKjLk
SciBCELXKhdkHan8ucml
=fHSl
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] HDMI colour space and depth questions (YCbCr, xvYCC, Deep Colour)

On Sun, 15 Jan 2012 10:48:28 +
Andy Burns xorg.li...@burns.me.uk wrote:
 OK, enough scene-setting, here are the xorg questions ...
 
 Is there any xorg.conf setting to switch the HDMI output to YCbCr mode
 instead of RGB mode?

No, we haven't exposed that yet.  On some chipsets it may mean
configuring colorspace conversion in the pipe code.  Paulo has been
looking at some of this...

 Similarly is there any setting to indicate an xvYCC gamut, which might
 persuade the amp not to clip the colours?

There is a way to configure the gamut to be compressed (default) or
expanded (up to 255).  But that's not exposed either.

 And finally, is there any support for DeepColour (30bpp or 36bpp)?

There is some 30 bit support in place, but not 36bpp, which is what
HDMI sinks generally want.  Doing that properly involves doing gamut
expansion, since most sources aren't 36bpp unless you have very
specific kinds of source data (e.g. custom HD DVD movies or something).

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [Intel-gfx] [PATCH] Android port of intel-gpu-tools

2012-01-16 Thread Chad Versace

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/10/2012 04:47 AM, Daniel Vetter wrote:
On Tue, Jan 10, 2012 at 10:15:01AM +0530, Sateesh Kavuri wrote:
Added support for Android. Changes include fixes for compilation issues
related to Android using an older version of GCC compiler (ver 4.3.3)
while the latest version of intel-gpu-tools confirms to GCC ver 4.5.2
(C99 standard functions), using functions like getline(). Fixed such
functions, header dependencies for android and added an Android.mk file.

signed-off-by: Sateesh Kavuri sateesh.kav...@intel.com

A few comments
- It looks like you need a completely separate makefile for android. Is
there no way to let the automake tools generate that somehow? Because
this simply won't scale.

- There's too much ANDRIOD #ifdef'ery in the code. Either switch to a
construct that works on all platforms or extract things into a little
helper functions (like the get_total_ram helper that has recently been
ported to Solaris).

- You don't seem to touch the testsuite, and I think you want it on
Andriod, too.

Added xorg-devel to cc, maybe someone else has already tried this with a
different package, my buildsystem fu is not up to this.

Yours, Daniel

Daniel, the Android.mk's are the curse of every project that is ported to
Android. Android has it's own build system, and those makefiles can't be
generated with autotools. This was a contentious issue when Chia-I Wu and
I ported Mesa to Android and led to a discussion [1] on mesa-dev. Below is
quoted my key email from that discussion (the Dan I'm speaking to is a Debian
maitainer).

[1]
http://article.gmane.org/gmane.comp.video.mesa3d.devel/28881/match=add+toplevel+android+mk

To address Dan's questions, the Android build cannot be fitted into autoconf
or
configs/android. I explored this option, and discovered that it was
impossible.
The Android build system is... well... interesting. Allow me to explain.

The entirety of the Android project --- libc, webkit, the window manager,
*everything* --- exists in a single source tree [1]. And that source tree is
built with a single, non-recursive invocation of make. Every time I say that,
I
find it hard to believe myself, so I'll say it again: The entirety of the
Android OS, all core libraries and apps, are built with a single,
non-recursive
invocation of make. (The kernel is the special exception to this
all-encompassing build). The final build artifact is a bootable iso image.

[1] http://android.git.kernel.org/

Given this unified design of the Android source tree and build process, it
requires system components, such as Mesa, to be integrated into its build
system. If Mesa is going to support Android, the Android.mk's are necessary.

To address another concern of Dan's, this will not add another way to
configure
the Mesa build. Android handles the system's build configuration in a single
location which is outside of Mesa.

I'm aware that the extra set of makefiles is unwelcome, but their presence
will
be innocuous. The only people that will need to touch them are those
maintaining
the Android build.

-
Chad Versace
chad.vers...@linux.intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPFGubAAoJEAIvNt057x8iTckQAKf3DPB3zAnVwEPcmad3BacJ
+3SfLISJUJPxoNpROYXiM/50bti/xir6x68Hez3jryzgFpSUTo2jpdXT2CalXSeN
ITdScopl4p0gNu4zxXiWzIv5445RLswkf1IArvL25LABRnQ1xSLdp6qTUZcfZXTa
bpzPM27p7k2FNvWN9z0vwNI8ebtMAwapvsb2lLyFeIfiB2ldQJIsclP1iOMylRlS
wSSEdqmWm7OTzpnocAaptCFDeolNplN7zvBfzMs9/AOCs1miKo+nUlf0GUf1CN0V
xuLrIf4UZn8sNLlsw5Mnc3uBIT5q8NR/rz60IswDKgm/W4pJbjRViaaecNjpbuvL
tzUE99CUtSmK/MY6TiSqlgTzgYRFk1qGu9bGxhbWyJE76gAjOX7A1OL+DsPj+wgR
DfAEKfcfFsUCDCkm3604uhl6hJauu3lDEVxL/6jAm/jMLzvwaxBPoMdS6QFtQ3QR
tTlZ4Y13jDnp+SOar3eLjgDE+pcdsFIHaFZ0ZxYEjgCHGVhP4ye3BaqMtMopwths
HcscB47/xz4y4CmEgBvDmcuPaxw6rgNd9d8543zvWlheb/dGH9yNJcoLBq0dz3tW
P/m0A+Hnv2gfLaopbPZIAPUKdR/iqA4cgoSKQq7OI46He4CHApatPapunL4IKCpU
eSulLcm0Dqpc6fz2zL1B
=Xlzm
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Android port of intel-gpu-tools

On Mon, Jan 16, 2012 at 10:25:32AM -0800, Chad Versace wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

signed-off-by: Sateesh Kavuri sateesh.kav...@intel.com

A few comments
- It looks like you need a completely separate makefile for android. Is
there no way to let the automake tools generate that somehow? Because
this simply won't scale.

- You don't seem to touch the testsuite, and I think you want it on
Andriod, too.

Added xorg-devel to cc, maybe someone else has already tried this with a
different package, my buildsystem fu is not up to this.

Yours, Daniel

[1]
http://article.gmane.org/gmane.comp.video.mesa3d.devel/28881/match=add+toplevel+android+mk

Meh.

I've just read about androgenizer:

http://cgit.collabora.com/git/user/derek/androgenizer.git/

Would that be a useful to at least generate the Android.mk in a sensible
fashion? I don't have clue about this ...

Otherwise we'll just stick Android.mk into the root dir and I'll forget
about this (and probably break it every time I change something).
-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] Android port of intel-gpu-tools

2012-01-16 Thread Chad Versace

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2012 10:36 AM, Daniel Vetter wrote:
On Mon, Jan 16, 2012 at 10:25:32AM -0800, Chad Versace wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

signed-off-by: Sateesh Kavuri sateesh.kav...@intel.com

A few comments
- It looks like you need a completely separate makefile for android. Is
there no way to let the automake tools generate that somehow? Because
this simply won't scale.

- You don't seem to touch the testsuite, and I think you want it on
Andriod, too.

Added xorg-devel to cc, maybe someone else has already tried this with a
different package, my buildsystem fu is not up to this.

Yours, Daniel

[1]
http://article.gmane.org/gmane.comp.video.mesa3d.devel/28881/match=add+toplevel+android+mk

Meh.

I've just read about androgenizer:

http://cgit.collabora.com/git/user/derek/androgenizer.git/
Would that be a useful to at least generate the Android.mk in a sensible
fashion? I don't have clue about this ...

Never heard of androgenizer, but looks interesting. When the Mesa build gets
its overdue conversion
to autotools, I'll have to give it a try.

Otherwise we'll just stick Android.mk into the root dir and I'll forget
about this (and probably break it every time I change something).

Hah! That's expected if the Android maintainers aren't vigilant.

We've mostly fixed that problem in Mesa (when people change the real makefile,
the Android build breaks) by forcing the two build systems to share common
makefiles when sensible. But I don't suggest that intel-gpu-tools take that
approach
unless build-breakage problems become painful.

-
Chad Versace
chad.vers...@linux.intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPFHIjAAoJEAIvNt057x8ilVAQALd5Z1TSD/SfNBGp1NRTinnz
HFN17Zp56apz2bDQgC1hftkJJXNZW83IPm9lseBvpfeKLVLfxkIsp6uklPbVputK
YJdI4G7TxDWpjDxHdh/tA45q+5H6hrtsPOBcnQwfDGq99DrAI/Pt6fZAO4c/0fbe
ZYnQ42DGeAkHK/XNxvF7zrkc9gJqwYhpUp8EyuguilYmnzyMkwR2SGu8hbDGRTmc
L0dNRuArZaaaTnFWLKAWPjgTZVXg9Ah2ZEawWOlvUNmygtOoqGqtcgIsRWdxr4QR
6hRTcbmiwc6CdmR1QsdL+hHs7MPAq1Kvj5CQjjNmCefkZBleu2W7EOnyLXZmfNDM
MbUOJ79JesS7z8wEkwLgcYgas9Qj+vaHw7tWWaqLxvxXEldFCcfub+Xjf1+Vi2X4
MoZtGAyNQQ6KHPpPS/ObI4D1Ati7eQy4ZiN7ILRgjmPWj4vy+RVwlwNbC7C9yLe2
kugwJGzRePFSl6Sagf1kFymKyK0MzIfquN/7vNh/2+Z/AOR6yISPqNkoxQveXk06
PK/ee4DngWcsUxuDpYcc1/NgNLccRfddyNINxCcbz2OuwQGbhRSa9Y8dpxJeXSIR
yaElS7FFUXCaebeXur3U9KsVq+s9mDpBRRZjaPaSsoss2tWb/F1wz93Yr96QUIIq
FOZrSKKdOxM8Q+Fj0SqP
=REOX
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] New drm-intel-next tree

Hi all,

Because Keith is routinely really busy with all kinds of things, notably
gathering fixes for drm-intel-fixes, the patch merge process for the next
release cycle sometimes falls behind. To support him and improve things I've
been volunteered to take over handling the -next tree. 

The main aim is to shift the drm/i915 -next merge process massively ahead with
the goals to:
- Reduce pressure to merge questionable patches into -rc kernels because the
  -next tree is not yet open for patches.
- Allow our QA at Intel and also the community to actually test things before
  they land in mainline. The lack of such testing has severly bitten us in the
  past few releases.
- Refocus -fixes on handling regressions with absolute top priority (as it
  should).
- And generally get a steady and predictable patch-flow towards mainline back
  into gears.

I plan to run this -next tree with a few simple rules:
- I'll open the drm/i915 -next tree around -rc1 (maybe earlier in the future)
  and cut regular new trees about every 2nd week or so. 2 weeks should be enough
  for both our qa and the community to give it some decent testing.

- I intend to send out the previous -next to Dave Airlie (assuming it tests ok)
  so that he has a good check on the stuff that's going on in i915-land. A few
  other people also asked for a better overview of what's going on on drm/i915 -
  I'll plan to announce every new -next tree with a short mail (maybe together
  with the pull request to Dave for the old one).

- -next will close about 1-2 weeks before the merge opens. No new features after
  that point for a given release cycle.

- To make this really work we also need to cut down on what can go into -fixes.
  drm/i915 unfortunately has the reputation that deserves it a bunch of
  draconian rules (which are stricter than drm/* in general):

  - Only fixes for serious issues and regressions after the -next tree went to
Dave.
  - After -rc2 regression fixes only. It simply happend why too often that an
obvious patch blew up late in the -rc release cycle, my patches included.
  - After -rc4/5 only reverts and disable patches. Imo it's way too late to play
games by then, the real fix should go straight to -next (which will close
only a few weeks afterwards already).

- Regressions have top priority, if they get neglected due to ongoing work
  headed for -next I'll refuse to merge the patches.

- We have a test-suite in the intel-gpu-tools package for the kernel. Expect me
  to be annoying about patches that should have testcases for them but don't.
  This includes new features, but also bugs that can be reproduced with a
  reasonable amount of effort.

- To avoid me pushing utter crack I will only merge my own patches after they
  have gathered sufficient review on intel-gfx. Please yell at me at the top of
  your voice (and in public) if I violate this.

- The main discussion list for patches to drm/i915 is
  intel-gfx@lists.freedesktop.org - I don't keep up with lkml usually.

- I'll reserve my human right to act like an incompetent arrogant fool once in a
  while.

Last but not least, the new tree is available at

http://cgit.freedesktop.org/~danvet/drm-intel
git://people.freedesktop.org/~danvet/drm-intel

drm-intel-next is the main branch, but I expect at least a for-airlied branch
for pull requests and maybe other branches with proposed patches to show up.

Comments, flames and suggestions highly welcome.

Yours, Daniel

PS: Quick version for people with too short attentation spans:

- -next will open around -rc1, a new tree should show up about every second
  week. -next trees that are tested will regurarly be forwarded to Dave.

- No stuff in -fixes that should go into -next instead.

- -next will close for features about 1-2 weeks ahead of the upstream merge 
window.

- Regressions have top priority.

- Implementing proper tests is required.

- Hit me hard if I break these rules for my own patches.

- Sometimes I'll screw things up badly.

Now grab the tree from

git://people.freedesktop.org/~danvet/drm-intel
-- 
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] Android port of intel-gpu-tools

On Mon, Jan 16, 2012 at 16:36, Daniel Vetter dan...@ffwll.ch wrote:

 Otherwise we'll just stick Android.mk into the root dir and I'll forget
 about this (and probably break it every time I change something).


I vote for this approach. It would only be used by android build, so when
it breaks, we'll be able to notice it pretty shortly and fix it.

-- 
Eugeni Dodonov
http://eugeni.dodonov.net/
___
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: specify vertical timings in frame units for interlaced modes (gen4+)

On Sun, 15 Jan 2012 01:52:11 +1100
Peter Ross pr...@xvid.org wrote:

 The G35/G45/SandyBridge chipsets expect vertical timings in frame units,
 whereas the DRM subsystem uses field units internally for interlaced modes.
 
 Signed-off-by: Peter Ross pr...@xvid.org
 ---
  drivers/gpu/drm/i915/intel_display.c |8 
  1 files changed, 8 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 2a3f707..ae62f5f 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -5316,6 +5316,14 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
   adjusted_mode-crtc_vblank_end -= 1;
   adjusted_mode-crtc_vsync_end -= 1;
   adjusted_mode-crtc_vsync_start -= 1;
 + if (INTEL_INFO(dev)-gen = 4) {
 + adjusted_mode-crtc_vdisplay *= 2;
 + adjusted_mode-crtc_vtotal *= 2;
 + adjusted_mode-crtc_vblank_start *= 2;
 + adjusted_mode-crtc_vblank_end *= 2;
 + adjusted_mode-crtc_vsync_end *= 2;
 + adjusted_mode-crtc_vsync_start *= 2;
 + }
   } else
   pipeconf = ~PIPECONF_INTERLACE_MASK; /* progressive */

I *think* this looks ok.  It'll only affect pre-ILK chipsets though and
interlaced modes.

Do we get the ILK+ side right here?

I'm with Eugeni; I'd like to see some tested-bys on this, otherwise it
looks good.

-- 
Jesse Barnes, Intel Open Source Technology Center


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

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

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 jbar...@virtuousgeek.org
---
 drivers/gpu/drm/i915/intel_display.c |   24 +---
 1 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 29743de..e8c6af2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4521,6 +4521,7 @@ void sandybridge_update_wm(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
int latency = SNB_READ_WM0_LATENCY() * 100; /* In unit 0.1us */
+   u32 val;
int fbc_wm, plane_wm, cursor_wm;
unsigned int enabled;
 
@@ -4529,8 +4530,10 @@ void sandybridge_update_wm(struct drm_device *dev)
sandybridge_display_wm_info, latency,
sandybridge_cursor_wm_info, latency,
plane_wm, cursor_wm)) {
-   I915_WRITE(WM0_PIPEA_ILK,
-  (plane_wm  WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+   val = I915_READ(WM0_PIPEA_ILK);
+   val = ~(WM0_PIPE_PLANE_MASK | WM0_PIPE_CURSOR_MASK);
+   I915_WRITE(WM0_PIPEA_ILK, val |
+  ((plane_wm  WM0_PIPE_PLANE_SHIFT) | cursor_wm));
DRM_DEBUG_KMS(FIFO watermarks For pipe A -
   plane %d,  cursor: %d\n,
  plane_wm, cursor_wm);
@@ -4541,8 +4544,10 @@ void sandybridge_update_wm(struct drm_device *dev)
sandybridge_display_wm_info, latency,
sandybridge_cursor_wm_info, latency,
plane_wm, cursor_wm)) {
-   I915_WRITE(WM0_PIPEB_ILK,
-  (plane_wm  WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+   val = I915_READ(WM0_PIPEB_ILK);
+   val = ~(WM0_PIPE_PLANE_MASK | WM0_PIPE_CURSOR_MASK);
+   I915_WRITE(WM0_PIPEB_ILK, val |
+  ((plane_wm  WM0_PIPE_PLANE_SHIFT) | cursor_wm));
DRM_DEBUG_KMS(FIFO watermarks For pipe B -
   plane %d, cursor: %d\n,
  plane_wm, cursor_wm);
@@ -4555,8 +4560,10 @@ void sandybridge_update_wm(struct drm_device *dev)
sandybridge_display_wm_info, latency,
sandybridge_cursor_wm_info, latency,
plane_wm, cursor_wm)) {
-   I915_WRITE(WM0_PIPEC_IVB,
-  (plane_wm  WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+   val = I915_READ(WM0_PIPEC_IVB);
+   val = ~(WM0_PIPE_PLANE_MASK | WM0_PIPE_CURSOR_MASK);
+   I915_WRITE(WM0_PIPEC_IVB, val |
+  ((plane_wm  WM0_PIPE_PLANE_SHIFT) | cursor_wm));
DRM_DEBUG_KMS(FIFO watermarks For pipe C -
   plane %d, cursor: %d\n,
  plane_wm, cursor_wm);
@@ -4700,6 +4707,7 @@ static void sandybridge_update_sprite_wm(struct 
drm_device *dev, int pipe,
 {
struct drm_i915_private *dev_priv = dev-dev_private;
int latency = SNB_READ_WM0_LATENCY() * 100; /* In unit 0.1us */
+   u32 val;
int sprite_wm, reg;
int ret;
 
@@ -4726,7 +4734,9 @@ static void sandybridge_update_sprite_wm(struct 
drm_device *dev, int pipe,
return;
}
 
-   I915_WRITE(reg, I915_READ(reg) | (sprite_wm  WM0_PIPE_SPRITE_SHIFT));
+   val = I915_READ(reg);
+   val = ~WM0_PIPE_SPRITE_MASK;
+   I915_WRITE(reg, val | (sprite_wm  WM0_PIPE_SPRITE_SHIFT));
DRM_DEBUG_KMS(sprite watermarks For pipe %d - %d\n, pipe, sprite_wm);
 
 
-- 
1.7.4.1

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

Re: [Intel-gfx] New drm-intel-next tree

On Mon, Jan 16, 2012 at 17:41, Daniel Vetter dan...@ffwll.ch wrote:

 Hi all,

 Because Keith is routinely really busy with all kinds of things, notably
 gathering fixes for drm-intel-fixes, the patch merge process for the next
 release cycle sometimes falls behind. To support him and improve things I've
 been volunteered to take over handling the -next tree.

 The main aim is to shift the drm/i915 -next merge process massively ahead with
 the goals to:
 - Reduce pressure to merge questionable patches into -rc kernels because the
  -next tree is not yet open for patches.
 - Allow our QA at Intel and also the community to actually test things before
  they land in mainline. The lack of such testing has severly bitten us in the
  past few releases.
 - Refocus -fixes on handling regressions with absolute top priority (as it
  should).
 - And generally get a steady and predictable patch-flow towards mainline back
  into gears.

Following up on Daniel's mail, I discussed with him, and from now on I
intend to include the -next patches into the -drm-intel-backports [1]
as well, to simplify testing for ones of you running stable kernels
who want to test the latest breakages^w features :).

[1] http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/7961

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

Re: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

2012-01-16 Thread Paulo Zanoni

Hi

2012/1/5 Jakob Bornecrantz ja...@vmware.com:
 Couldn't this be done by just adding a property instead of a ioctl?


So I've discussed this with Jesse and it seems the best way to turn
this into a property is to add support for CRTC properties, then add a
rotation property for the i915 driver. This will actually introduce
2 new ioctls: one to list the properties and one to change them.

I'll send three Kernel patches to this list in the next minutes. One
just moves code around (so we can reuse it), another adds CRTC
properties in drm/ and the other adds the rotation property for i915.

I also wrote patches for libdrm (implement the ioctls, change
tests/modetest to call these ioctls, and some janitor work on modetest
and libdrm) and xf86-video-intel (use the rotation property). The drm
patches are applied to this tree:
http://cgit.freedesktop.org/~pzanoni/drm/ . I was only planning to
send them to the list after I get some review on the kernel patches.
The full list of patches I wrote so far is here:
http://people.freedesktop.org/~pzanoni/rotation/ .

For those asking more information about the problem: these bits are
somehow needed by the embedded VNC: it needs to know how the screen is
rotated. More information:
http://en.wikipedia.org/wiki/Intel_Active_Management_Technology#VNC-based_KVM_remote_control

Cheers,
Paulo

-- 
Paulo Zanoni
___
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: specify vertical timings in frame units for interlaced modes (gen4+)

On Mon, Jan 16, 2012 at 17:50, Jesse Barnes jbar...@virtuousgeek.orgwrote:

 Do we get the ILK+ side right here?


From the specs, looks like ILK and SNB+ share same logic for this part.

-- 
Eugeni Dodonov
 http://eugeni.dodonov.net/
___
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: specify vertical timings in frame units for interlaced modes (gen4+)

On Sun, Jan 15, 2012 at 01:52:11AM +1100, Peter Ross wrote:
 The G35/G45/SandyBridge chipsets expect vertical timings in frame units,
 whereas the DRM subsystem uses field units internally for interlaced modes.
 
 Signed-off-by: Peter Ross pr...@xvid.org

On a quick look at the patch it have a confusion about chipset
generations. We generally call g35 i965 to avoid confusion with the gen3
device g33. Also i9xx_crtc_mode_set is only used on pre-ironlake (=gen5)
and hence does not include snb. You might want to fix up
ironlake_crtc_mode_set, too.

When quickly discussing this with Jesse on irc we concluded that this is
fine if it comes with a tested-by (for both patches) attached, preferrably
with quick details on which machines this was tested on.
-Daniel
 ---
  drivers/gpu/drm/i915/intel_display.c |8 
  1 files changed, 8 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 2a3f707..ae62f5f 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -5316,6 +5316,14 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
   adjusted_mode-crtc_vblank_end -= 1;
   adjusted_mode-crtc_vsync_end -= 1;
   adjusted_mode-crtc_vsync_start -= 1;
 + if (INTEL_INFO(dev)-gen = 4) {
 + adjusted_mode-crtc_vdisplay *= 2;
 + adjusted_mode-crtc_vtotal *= 2;
 + adjusted_mode-crtc_vblank_start *= 2;
 + adjusted_mode-crtc_vblank_end *= 2;
 + adjusted_mode-crtc_vsync_end *= 2;
 + adjusted_mode-crtc_vsync_start *= 2;
 + }
   } else
   pipeconf = ~PIPECONF_INTERLACE_MASK; /* progressive */
  
 -- 
 1.7.5.4
 
 -- Peter
 (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)



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


-- 
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: Silence _DSM errors

On Mon, Oct 10, 2011 at 12:57:44PM -0700, Jesse Barnes wrote:
 On Mon, 10 Oct 2011 15:08:51 -0400
 Adam Jackson a...@redhat.com wrote:
 
  On Tue, 2011-09-13 at 14:11 -0400, Adam Jackson wrote:
   @ajax mjg59: how concerned should i be about [drm:intel_dsm_pci_probe]
   *ERROR* failed to get supported _DSM functions ?
   @mjg59 ajax: Entirely unconcerned
   
   Signed-off-by: Adam Jackson a...@redhat.com
  
  Anybody?  This makes quiet boot actually quiet again.
 
 Yeah, looks fine to me.
 
 Acked-by: Jesse Barnes jbar...@virtuousgeek.org

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] drm/i915: remove ACPI related DRM_ERRORs

On Thu, Jan 12, 2012 at 12:22:37PM -0500, Adam Jackson wrote:
 On Thu, 2012-01-12 at 09:03 -0800, Jesse Barnes wrote:
  They're not really errors (well actually I don't know; I don't
  understand _DSM and _MUX well enough to say, but I do know they spam
  people's logs and seem to be harmless).
 
 Looks familiar!
 
 http://lists.freedesktop.org/archives/intel-gfx/2011-September/011994.html
 http://lists.freedesktop.org/archives/intel-gfx/2011-October/012563.html
 
 Reviewed-by: Adam Jackson a...@redhat.com

I've picked up the old one ;-)
-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: Only look for matching clocks for LVDS downclock

On Tue, 10 Jan 2012 15:09:36 -0800
Sean Paul seanp...@chromium.org wrote:

 This patch enforces that the downclock clock source is the same as the 
 preferred
 clock source for LVDS. This fixes a bug where the driver chooses a downclock
 clock source with a different P than the preferred mode clock source. This
 happened even if the preferred clock source implemented an acceptable rate for
 the downclock. The result of this bug is that downclock is disabled.
 
 Signed-off-by: Sean Paul seanp...@chromium.org
 ---

Yeah looks like a good cleanup that also makes downclocking more likely.

Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [Intel-gfx] [PATCH] drm/i915: Only look for matching clocks for LVDS downclock

On Mon, Jan 16, 2012 at 12:20:03PM -0800, Jesse Barnes wrote:
 On Tue, 10 Jan 2012 15:09:36 -0800
 Sean Paul seanp...@chromium.org wrote:
 
  This patch enforces that the downclock clock source is the same as the 
  preferred
  clock source for LVDS. This fixes a bug where the driver chooses a downclock
  clock source with a different P than the preferred mode clock source. This
  happened even if the preferred clock source implemented an acceptable rate 
  for
  the downclock. The result of this bug is that downclock is disabled.
  
  Signed-off-by: Sean Paul seanp...@chromium.org
  ---
 
 Yeah looks like a good cleanup that also makes downclocking more likely.
 
 Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

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: set AUD_CONFIG N_value_index for DisplayPort

On Mon, Jan 16, 2012 at 04:02:53PM +0800, Wu Fengguang wrote:
 On Thu, Jan 12, 2012 at 09:33:34AM -0800, Keith Packard wrote:
  On Tue, 10 Jan 2012 13:45:19 +0800, Wu Fengguang fengguang...@intel.com 
  wrote:
  
   @@ -5943,6 +5947,7 @@ static void ironlake_write_eld(struct dr
 if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
 DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
 eld[5] |= (1  2); /* Conn_Type, 0x1 = DisplayPort */
   + I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 = DP */
 }
  
  Do we need to clear this bit in the HDMI case? Or do we just trust the
  BIOS to either leave this bit zero or set it correctly?
 
 I tried booting
 
 1) with HDMI monitor plugged
 2) plug HDMI monitor after BIOS boot
 
 In both cases, I get the same AUD_CONFIG values for the host/sink matrix
 
 RX-V1800SONY TV
 ivybridge   0x  0x
 ironlake0x  0x
 
 HDMI audio is working fine in all cases. So I guess it's fine to leave
 HDMI as (unconfigured) 0.

Keith, does this address your concern and this patch is r-b: Keith or do
we want an

} else {
I915_WRITE(aud_config, 0);
}

for paranoia?
-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/2] drm/i915: simplify pipe checking

On Sun, Jan 08, 2012 at 03:01:12AM +0100, Cyril Brulebois wrote:
 Eugeni Dodonov eugeni.dodo...@intel.com (07/01/2012):
  This is also handled by i915_reg.h, so just reuse this trick to reduce
  universe enthropy.
 
 entropy.
 
 Besides that:
 
 Reviewed-by: Cyril Brulebois k...@debian.org

Both patches queued for -next, 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] drm/i915: there is no pipe CxSR on ironlake

On Thu, Jan 05, 2012 at 09:34:29AM -0200, Eugeni Dodonov wrote:
 After checking the specs and discussing with Jesse, turns out CxSR is not
 available on Ironlake and gen5, and its advertisement on the device
 description is misleading.
 
 Acked-by: Jesse Barnes jbar...@virtuousgeek.org
 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com

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 1/2] drm: give up on edid retries when i2c bus is not responding

Hi Dave,

Is it ok if I merge this through my -next tree? Otherwise please consider
merging this for 3.4.

Yours, Daniel

On Thu, Jan 05, 2012 at 09:34:28AM -0200, Eugeni Dodonov wrote:
 This allows to avoid talking to a non-responding bus repeatedly until we
 finally timeout after 15 attempts. We can do this by catching the -ENXIO
 error, provided by i2c_algo_bit:bit_doAddress call.
 
 Within the bit_doAddress we already try 3 times to get the edid data, so
 if the routine tells us that bus is not responding, it is mostly pointless
 to keep re-trying those attempts over and over again until we reach final
 number of retries.
 
 This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
 and improve overall edid detection timing by 10-30% in most cases, and by
 a much larger margin in case of phantom outputs (up to 30x in one worst
 case).
 
 Timing results for i915-powered machines for 'time xrandr' command:
 Machine 1: from 0.840s to 0.290s
 Machine 2: from 0.315s to 0.280s
 Machine 3: from +/- 4s to 0.184s
 
 Timing results for HD5770 with 'time xrandr' command:
 Machine 4: from 3.210s to 1.060s
 
 Reviewed-by: Chris Wilson ch...@hchris-wilson.co.uk
 Reviewed-by: Keith Packard kei...@keithp.com
 Tested-by: Sean Finney sean...@seanius.net
 Tested-by: Soren Hansen so...@linux2go.dk
 Tested-by: Hernando Torque sir...@sonnenkinder.org
 Tested-by: Mike Lothian m...@fireburn.co.uk
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
 ---
  drivers/gpu/drm/drm_edid.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 3e927ce..fb6c26c 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -266,6 +266,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
 unsigned char *buf,
   }
   };
   ret = i2c_transfer(adapter, msgs, 2);
 + if (ret == -ENXIO) {
 + DRM_DEBUG_KMS(drm: skipping non-existent adapter %s\n,
 + adapter-name);
 + break;
 + }
   } while (ret != 2  --retries);
  
   return ret == 2 ? 0 : -1;
 -- 
 1.7.8
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

2012-01-16 Thread Dave Airlie

On Mon, Jan 16, 2012 at 7:59 PM, Paulo Zanoni przan...@gmail.com wrote:
 Hi

 2012/1/5 Jakob Bornecrantz ja...@vmware.com:
 Couldn't this be done by just adding a property instead of a ioctl?


 So I've discussed this with Jesse and it seems the best way to turn
 this into a property is to add support for CRTC properties, then add a
 rotation property for the i915 driver. This will actually introduce
 2 new ioctls: one to list the properties and one to change them.

Okay I must have missed the bit where you explain why a connector
property isn't used?

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

Re: [Intel-gfx] [PATCH] agp/intel: Add pci id for hostbridge from has/qemu

On Wed, Jan 04, 2012 at 02:04:33PM -0800, Ben Widawsky wrote:
 This is needed to run the simulator.
 
 Cc: Jesse Barnes jbar...@virtuousgeek.org
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

Queued for -next (with a small comment added), thanks for the patch.
-Daniel
 ---
  drivers/char/agp/intel-agp.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
 index b427711..f853514 100644
 --- a/drivers/char/agp/intel-agp.c
 +++ b/drivers/char/agp/intel-agp.c
 @@ -850,6 +850,7 @@ static struct pci_device_id agp_intel_pci_table[] = {
   .subvendor  = PCI_ANY_ID,   \
   .subdevice  = PCI_ANY_ID,   \
   }
 + ID(PCI_DEVICE_ID_INTEL_82441),
   ID(PCI_DEVICE_ID_INTEL_82443LX_0),
   ID(PCI_DEVICE_ID_INTEL_82443BX_0),
   ID(PCI_DEVICE_ID_INTEL_82443GX_0),
 -- 
 1.7.8.1
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] HDMI colour space and depth questions (YCbCr, xvYCC, Deep Colour)

Jesse Barnes jbar...@virtuousgeek.org wrote:

 Andy Burns xorg.li...@burns.me.uk wrote:

 Is there any xorg.conf setting to switch the HDMI output to YCbCr mode
 instead of RGB mode?

 No, we haven't exposed that yet.  On some chipsets it may mean
 configuring colorspace conversion in the pipe code.  Paulo has been
 looking at some of this...

 Similarly is there any setting to indicate an xvYCC gamut, which might
 persuade the amp not to clip the colours?

 There is a way to configure the gamut to be compressed (default) or
 expanded (up to 255).  But that's not exposed either.

OK, thanks for the info, I'll keep an eye on release notes for such
time when support might be added.  On the bright side, it defers my
hardware upgrade at least until IVB is released ...

 And finally, is there any support for DeepColour (30bpp or 36bpp)?

 There is some 30 bit support in place, but not 36bpp, which is what
 HDMI sinks generally want.  Doing that properly involves doing gamut
 expansion, since most sources aren't 36bpp unless you have very
 specific kinds of source data (e.g. custom HD DVD movies or something).

No, I don't have any high colour material, but if a wider gamut had
been available, it would have been nice to have more colour resolution
too, to see whether interpolation could reduce banding etc ...

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

Re: [Intel-gfx] [PATCH] drm/i915: set AUD_CONFIG N_value_index for DisplayPort

2012-01-16 Thread Keith Packard

On Mon, 16 Jan 2012 21:26:18 +0100, Daniel Vetter dan...@ffwll.ch wrote:

 Keith, does this address your concern and this patch is r-b: Keith or do
 we want an
 
 } else {
   I915_WRITE(aud_config, 0);
 }
 
 for paranoia?

I think we want this added, just to be sure we set the configuration
correctly in all cases; it's easy to imagine moving from DP to HDMI and
leaving this bit set.

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


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

Re: [Intel-gfx] Problem Intel i915 driver, i3 2010T, HDMI output modes problems

On Tue, Jan 03, 2012 at 08:52:39PM +, paulo louro wrote:
 
 Dear intel-gfx developers.
 After spending a huge amount of time searching for a solution for me problem 
 and haven't been able to find one, i decided to send a email to this mailing 
 list hoping someone can help me or point me on the right direction. 
 Hardware: Motherboard : ASRock H67M-GEProcessor:   Intel Core i3 2010T AV 
 Receiver: Onkyo TX-NR808TV: Panasonic 50VT20
 Software: Ubuntu 11.10 with xorg-edgers ppa.
 Problem: When starting ubuntu without the AV receiver or the TV being on, the 
 xorg start with a resolution of 720x576. When turning the TV on and selecting 
 the AV-Receiver. The AV receiver reports that there is a signal but noting is 
 display on the TV, by using my receiver Display/Information menu i can see im 
 receiving a signal with 1920x1080i@120hz. The receiver pass's this direct to 
 the television and ofc since its 120hz it cant be handled. As so only a black 
 screen is display, not even the Onkyo GUI can be displayed.
 By running the xrandr -display :0 --verbose i get:HDMI3 connected 
 1920x1080+0+0 (0x42) normal (normal left inverted right x axis y axis) 708mm 
 x 398mmIdentifier: 0x41Timestamp:  111744  Subpixel:   
 unknown Gamma:  1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 
   0   CRTCs:  0 1 Transform:  1.00 0.00 0.00  
 0.00 1.00 0.00  0.00 0.00 1.00
  filter:  EDID:   00003dcb820a
 0014010380780a0dc9a057479827
 12484c0001010101010101010101
 010101010101011d8018711c1620582c
 2500c48e219e011d80d0721c1620
 102c2580c48e219e00fc0054
 582d4e523830380a2020202000fd
 0017f00f7e11000a202020202020016c
 02033e7255850403020e0f0723241094
 1312111d1e162526011f38097f070f7f
 071707503f06c04d02005706005f7e01
 675400834f66030c002100808c0a
 d08a20e02d10103e9600c48e2118
 8c0ad090204031200c405500c48e2100
 0018011d007251d01e206e285500c48e
 211e0091Broadcast RG
 B: Fullsupported: Full Limited 16:2audio:  auto
supported: off  auto on1920x1080@60 (0x42)  
148.5MHz +HSync +VSync *current +preferredh: width  1920 start 2008 end 
2052 total 2200 skew0 clock   67.5KHzv: height 1080 start 1084 end 
1089 total 1125   clock   60.0Hz  720x576 (0x43)   27.0MHz -HSync 
-VSynch: width   720 start  732 end  796 total  864 skew0 clock   
31.2KHzv: height  576 start  581 end  586 total  625   clock   
50.0Hz  720x480 (0x44)   27.0MHz -HSync -VSynch: width   720 start  736 
end  798 total  858 skew0 clock   31.5KHzv: height  480 start  489 
end  495 total  525   clock   59.9Hz
 There i can see that the modeline is current selected to 1920x1080@60hz.  If 
 i select the mode as 720x576@50hz, them gnome desktop shows but its like the 
 screen has 2 desktops splitting the screen in half. If i move the mouse to 
 the top of the screen i can see it in the top and lower part of my TV.  The 
 funny part is my TV and Receiver now report a signal of 1920x1080@50hz.
 Once i change to this mode my xrandr -display :0 --verbose shows 2 new modes 
 that weren't there before:
 Screen 0: minimum 320 x 200, current 720 x 576, maximum 8192 x 8192HDMI3 
 connected 720x576+0+0 (0x43) normal (normal left inverted right x axis y 
 axis) 698mm x 392mm Identifier: 0x41Timestamp:  277649  Subpixel: 
   unknown Gamma:  1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC:   
 0   CRTCs:  0 1 Transform:  1.00 0.00 0.00  
 0.00 1.00 0.00  0.00 0.00 1.00
  filter:  EDID:   00003dcb820a
 0014010380780adaffa3584aa229
 17494b0001010101010101010101
 010101010101023a80d072382d40102c
 4580ba88211e023a801871382d40
 582c4500ba88211e00fc0054
 582d4e523830380a2020202000fd
 00173d0f440f000a202020202020013e
 020362725c9f90140520130412031102
 16071506011e0f1d0e1a0b190a262425
 2338097f070f7f071707503f06c04d02
 005706005f7e01675400834f7f03
 0c002100b826e08011060800
 1618002030480053580063680070e305
 1f01011d80d0721c1620102c2580ba88219e00
 ff Broadcast RGB:  Fullsupported: Full Limited 16:2
audio:  autosupported: off  auto

Re: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

2012-01-16 Thread Paulo Zanoni

2012/1/16 Dave Airlie airl...@gmail.com:

 Okay I must have missed the bit where you explain why a connector
 property isn't used?

The registers that contain the rotation information are the pipe
registers and, as far as I understood, each pipe is associated with
only one crtc. We can have more than one connector associated with one
crtc. So, in a case where we have two different connectors associated
with the same crtc, we would have to keep synchronizing the property
value between the two connectors: this doesn't sound like the best
solution and it could also create confusion (imagine the case where
connectors A and B are associated with the same crtc, and you set
connector_a.rotation to 0 and then connector_b.rotation to 180, then
you'll read connector_a.rotation and it will be 180, not what you just
set).

(and by the way, the three patches were sent just to dri-devel@)


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

Re: [Intel-gfx] [PATCH] drm/i915: kill i915_mem.c

On Thu, Dec 22, 2011 at 10:23:14PM +0100, Daniel Vetter wrote:
 Some decent history digging indicates that this was to be used for the
 GLX_MESA_allocate_memory extension but never actually implemented for
 any released i915 userspace code.
 
 So just rip it out.
 
 Cc: Dave Airlie airl...@gmail.com
 Cc: Keith Whitwell kei...@vmware.com
 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch

Can some bored soul take a look at this and do the history
double-checking? And maybe notice that the Makefile change is missing ...

/me would like to kill this cruft

Cheers, Daniel
 ---
  drivers/gpu/drm/drm_ioctl.c |2 +
  drivers/gpu/drm/i915/i915_dma.c |   13 +-
  drivers/gpu/drm/i915/i915_drv.h |   13 --
  drivers/gpu/drm/i915/i915_mem.c |  387 
 ---
  4 files changed, 6 insertions(+), 409 deletions(-)
  delete mode 100644 drivers/gpu/drm/i915/i915_mem.c
 
 diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
 index 904d7e9..6bfc5ce 100644
 --- a/drivers/gpu/drm/drm_ioctl.c
 +++ b/drivers/gpu/drm/drm_ioctl.c
 @@ -37,6 +37,7 @@
  #include drm_core.h
  
  #include linux/pci.h
 +#include linux/export.h
  
  /**
   * Get the bus id.
 @@ -353,3 +354,4 @@ int drm_noop(struct drm_device *dev, void *data,
   DRM_DEBUG(\n);
   return 0;
  }
 +EXPORT_SYMBOL(drm_noop);
 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index a9ae374..71a1946 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -2243,9 +2243,6 @@ void i915_driver_lastclose(struct drm_device * dev)
  
   i915_gem_lastclose(dev);
  
 - if (dev_priv-agp_heap)
 - i915_mem_takedown((dev_priv-agp_heap));
 -
   i915_dma_cleanup(dev);
  }
  
 @@ -2253,8 +2250,6 @@ void i915_driver_preclose(struct drm_device * dev, 
 struct drm_file *file_priv)
  {
   drm_i915_private_t *dev_priv = dev-dev_private;
   i915_gem_release(dev, file_priv);
 - if (!drm_core_check_feature(dev, DRIVER_MODESET))
 - i915_mem_release(dev, file_priv, dev_priv-agp_heap);
  }
  
  void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
 @@ -2273,11 +2268,11 @@ struct drm_ioctl_desc i915_ioctls[] = {
   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 - DRM_IOCTL_DEF_DRV(I915_ALLOC, i915_mem_alloc, DRM_AUTH),
 - DRM_IOCTL_DEF_DRV(I915_FREE, i915_mem_free, DRM_AUTH),
 - DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, i915_mem_init_heap, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 + DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
 + DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
 + DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, drm_noop, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
   DRM_IOCTL_DEF_DRV(I915_CMDBUFFER, i915_cmdbuffer, DRM_AUTH),
 - DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP,  i915_mem_destroy_heap, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 + DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP,  drm_noop, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
   DRM_IOCTL_DEF_DRV(I915_SET_VBLANK_PIPE,  i915_vblank_pipe_set, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
   DRM_IOCTL_DEF_DRV(I915_GET_VBLANK_PIPE,  i915_vblank_pipe_get, 
 DRM_AUTH),
   DRM_IOCTL_DEF_DRV(I915_VBLANK_SWAP, i915_vblank_swap, DRM_AUTH),
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 554bef7..0dceb4a 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -327,7 +327,6 @@ typedef struct drm_i915_private {
  
   int tex_lru_log_granularity;
   int allow_batchbuffer;
 - struct mem_block *agp_heap;
   unsigned int sr01, adpa, ppcr, dvob, dvoc, lvds;
   int vblank_pipe;
   int num_pipe;
 @@ -1070,18 +1069,6 @@ extern void i915_destroy_error_state(struct drm_device 
 *dev);
  #endif
  
  
 -/* i915_mem.c */
 -extern int i915_mem_alloc(struct drm_device *dev, void *data,
 -   struct drm_file *file_priv);
 -extern int i915_mem_free(struct drm_device *dev, void *data,
 -  struct drm_file *file_priv);
 -extern int i915_mem_init_heap(struct drm_device *dev, void *data,
 -   struct drm_file *file_priv);
 -extern int i915_mem_destroy_heap(struct drm_device *dev, void *data,
 -  struct drm_file *file_priv);
 -extern void i915_mem_takedown(struct mem_block **heap);
 -extern void i915_mem_release(struct drm_device * dev,
 -  struct drm_file *file_priv, struct mem_block 
 *heap);
  /* i915_gem.c */
  int i915_gem_init_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
 diff --git a/drivers/gpu/drm/i915/i915_mem.c b/drivers/gpu/drm/i915/i915_mem.c
 deleted file mode 100644
 index cc8f6d4..000
 --- a/drivers/gpu/drm/i915/i915_mem.c
 +++

Re: [Intel-gfx] [PATCH 3/3] drm/i915: split out DPLL update code from i9xx_crtc_mode_set

On Thu, Dec 15, 2011 at 12:30:38PM -0800, Jesse Barnes wrote:
 More i9xx mode set cleanups, further simplifying the mode set path and
 making it easier to extend.
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org

This is imo too much refactoring for just one patch. I'd like the extract
intel_update_lvds in a separate patch. That one intermingled with the
update_pll extraction makes things hard to follow.

Patches 12 of this series are queued for -next. Also, can we _please_
have the same treatment for ironlake_crtc_mode_set? That monstrositiy is
already around 450 lines and growing ...

Yours, Daniel
 ---
  drivers/gpu/drm/i915/intel_display.c |  402 
 --
  1 files changed, 236 insertions(+), 166 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index b08089c..0eff163 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -4848,7 +4848,7 @@ static void i9xx_update_pll_dividers(struct drm_crtc 
 *crtc,
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
   int pipe = intel_crtc-pipe;
 - u32 fp, fp2;
 + u32 fp, fp2 = 0;
  
   if (IS_PINEVIEW(dev)) {
   fp = (1  clock-n)  16 | clock-m1  8 | clock-m2;
 @@ -4874,6 +4874,233 @@ static void i9xx_update_pll_dividers(struct drm_crtc 
 *crtc,
   }
  }
  
 +static void intel_update_lvds(struct drm_crtc *crtc, intel_clock_t *clock,
 +   struct drm_display_mode *adjusted_mode)
 +{
 + struct drm_device *dev = crtc-dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 + int pipe = intel_crtc-pipe;
 + u32 temp, lvds_sync = 0;
 +
 + temp = I915_READ(LVDS);
 + temp |= LVDS_PORT_EN | LVDS_A0A2_CLKA_POWER_UP;
 + if (pipe == 1) {
 + temp |= LVDS_PIPEB_SELECT;
 + } else {
 + temp = ~LVDS_PIPEB_SELECT;
 + }
 + /* set the corresponsding LVDS_BORDER bit */
 + temp |= dev_priv-lvds_border_bits;
 + /* Set the B0-B3 data pairs corresponding to whether we're going to
 +  * set the DPLLs for dual-channel mode or not.
 +  */
 + if (clock-p2 == 7)
 + temp |= LVDS_B0B3_POWER_UP | LVDS_CLKB_POWER_UP;
 + else
 + temp = ~(LVDS_B0B3_POWER_UP | LVDS_CLKB_POWER_UP);
 +
 + /* It would be nice to set 24 vs 18-bit mode (LVDS_A3_POWER_UP)
 +  * appropriately here, but we need to look more thoroughly into how
 +  * panels behave in the two modes.
 +  */
 + /* set the dithering flag on LVDS as needed */
 + if (INTEL_INFO(dev)-gen = 4) {
 + if (dev_priv-lvds_dither)
 + temp |= LVDS_ENABLE_DITHER;
 + else
 + temp = ~LVDS_ENABLE_DITHER;
 + }
 + if (adjusted_mode-flags  DRM_MODE_FLAG_NHSYNC)
 + lvds_sync |= LVDS_HSYNC_POLARITY;
 + if (adjusted_mode-flags  DRM_MODE_FLAG_NVSYNC)
 + lvds_sync |= LVDS_VSYNC_POLARITY;
 + if ((temp  (LVDS_HSYNC_POLARITY | LVDS_VSYNC_POLARITY))
 + != lvds_sync) {
 + char flags[2] = -+;
 + DRM_INFO(Changing LVDS panel from 
 +  (%chsync, %cvsync) to (%chsync, %cvsync)\n,
 +  flags[!(temp  LVDS_HSYNC_POLARITY)],
 +  flags[!(temp  LVDS_VSYNC_POLARITY)],
 +  flags[!(lvds_sync  LVDS_HSYNC_POLARITY)],
 +  flags[!(lvds_sync  LVDS_VSYNC_POLARITY)]);
 + temp = ~(LVDS_HSYNC_POLARITY | LVDS_VSYNC_POLARITY);
 + temp |= lvds_sync;
 + }
 + I915_WRITE(LVDS, temp);
 +}
 +
 +static void i9xx_update_pll(struct drm_crtc *crtc,
 + struct drm_display_mode *mode,
 + struct drm_display_mode *adjusted_mode,
 + intel_clock_t *clock, intel_clock_t *reduced_clock,
 + int num_connectors)
 +{
 + struct drm_device *dev = crtc-dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 + int pipe = intel_crtc-pipe;
 + u32 dpll;
 + bool is_sdvo;
 +
 + is_sdvo = intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
 + intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
 +
 + dpll = DPLL_VGA_MODE_DIS;
 +
 + if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS))
 + dpll |= DPLLB_MODE_LVDS;
 + else
 + dpll |= DPLLB_MODE_DAC_SERIAL;
 + if (is_sdvo) {
 + int pixel_multiplier = 
 intel_mode_get_pixel_multiplier(adjusted_mode);
 + if (pixel_multiplier  1) {
 + if (IS_I945G(dev) || IS_I945GM(dev) || IS_G33(dev))
 + dpll |= (pixel_multiplier - 1)  
 SDVO_MULTIPLIER_SHIFT_HIRES;
 + }
 +

Re: [Intel-gfx] HDMI colour space and depth questions (YCbCr, xvYCC, Deep Colour)

Jesse Barnes jbar...@virtuousgeek.org wrote:

 Andy Burns xorg.li...@burns.me.uk wrote:

 Similarly is there any setting to indicate an xvYCC gamut, which might
 persuade the amp not to clip the colours?

 There is a way to configure the gamut to be compressed (default) or
 expanded (up to 255).  But that's not exposed either.

I see the following from the man page

DVI/HDMI outputs. Avaliable common properties include:
BROADCAST_RGB - method used to set RGB color range(full range 0-255,
not full range 16-235)
Adjusting this propertie allows you to set RGB color range on each
channel in order to match HDTV requirment(default 0 for full range).
Setting 1 means RGB color range is 16-235, 0 means RGB color range is
0-255 on each channel.
SDVO and DVO TV outputs are not supported by the driver at this time.

Does that mean I *can* toggle the studio colour range on the fly, or
is the doc wrong?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [RFC] drm/i915: read-read semaphore optimization

On Tue, Dec 13, 2011 at 10:36:15AM -0800, Ben Widawsky wrote:
 On 12/13/2011 09:22 AM, Eric Anholt wrote:
 On Mon, 12 Dec 2011 19:52:08 -0800, Ben Widawskyb...@bwidawsk.net  wrote:
 Since we don't differentiate on the different GPU read domains, it
 should be safe to allow back to back reads to occur without issuing a
 wait (or flush in the non-semaphore case).
 
 This has the unfortunate side effect that we need to keep track of all
 the outstanding buffer reads so that we can synchronize on a write, to
 another ring (since we don't know which read finishes first). In other
 words, the code is quite simple for two rings, but gets more tricky for
 2 rings.
 
 Here is a picture of the solution to the above problem
 
 Ring 0Ring 1 Ring 2
 batch 0   batch 1batch 2
read buffer A read buffer A  wait batch 0
 wait batch 1
 write buffer A
 
 This code is really untested. I'm hoping for some feedback if this is
 worth cleaning up, and testing more thoroughly.
 
 You say it's an optimization -- do you have performance numbers?
 
 33% improvement on a hacked version of gem_ring_sync_loop with.
 
 It's not really a valid test as it's not coherent, but this is
 approximately the best case improvement.
 
 Oddly semaphores doesn't make much difference in this test, which
 was surprising.

Our domain tracking is already complicated in unfunny ways. And (at least
without a use-case showing gains with hard numbers in either perf or power
usage) I think this patch is the kind of this looks cool stuff that
added a lot to the current problem.

So before adding more complexity on top I'd like to remove some of the
superflous stuff we already have. I.e. all the flushing_list stuff and
maybe other things ...

Cheers, 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: add a LLC feature flag in device description

On Tue, Dec 13, 2011 at 07:05:41PM -0200, Eugeni Dodonov wrote:
 From: Eugeni Dodonov eugeni.dodo...@intel.com
 
 LLC is not SNB-specific, so we should check for it in a more generic way.
 
 v2: export LLC support status via debugfs and DRM GETPARAM.
 
 v3: rebase on newer kernel version which says that IVB supports LLC as
 well.
 
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
 Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com

The patch now conflicts with gen7 sol reset stuff. Care to rebase? Also
can you create a quick libdrm helper to check for llc support that returns
true for gen6gen7 in the absence of this ioctl?
-Daniel

 ---
  drivers/gpu/drm/i915/i915_debugfs.c |1 +
  drivers/gpu/drm/i915/i915_dma.c |3 +++
  drivers/gpu/drm/i915/i915_drv.c |4 
  drivers/gpu/drm/i915/i915_drv.h |2 ++
  drivers/gpu/drm/i915/i915_gem.c |4 ++--
  include/drm/i915_drm.h  |1 +
  6 files changed, 13 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index d09a6e0..cb8a153 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -82,6 +82,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
   B(supports_tv);
   B(has_bsd_ring);
   B(has_blt_ring);
 + B(has_llc);
  #undef B
  
   return 0;
 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index a9533c5..938ad57 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -781,6 +781,9 @@ static int i915_getparam(struct drm_device *dev, void 
 *data,
   case I915_PARAM_HAS_RELAXED_DELTA:
   value = 1;
   break;
 + case I915_PARAM_HAS_LLC:
 + value = HAS_LLC(dev);
 + break;
   default:
   DRM_DEBUG_DRIVER(Unknown parameter %d\n,
param-param);
 diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
 index 15bfa91..19fb7a4 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ b/drivers/gpu/drm/i915/i915_drv.c
 @@ -214,6 +214,7 @@ static const struct intel_device_info 
 intel_sandybridge_d_info = {
   .need_gfx_hws = 1, .has_hotplug = 1,
   .has_bsd_ring = 1,
   .has_blt_ring = 1,
 + .has_llc = 1,
  };
  
  static const struct intel_device_info intel_sandybridge_m_info = {
 @@ -222,6 +223,7 @@ static const struct intel_device_info 
 intel_sandybridge_m_info = {
   .has_fbc = 1,
   .has_bsd_ring = 1,
   .has_blt_ring = 1,
 + .has_llc = 1,
  };
  
  static const struct intel_device_info intel_ivybridge_d_info = {
 @@ -229,6 +231,7 @@ static const struct intel_device_info 
 intel_ivybridge_d_info = {
   .need_gfx_hws = 1, .has_hotplug = 1,
   .has_bsd_ring = 1,
   .has_blt_ring = 1,
 + .has_llc = 1,
  };
  
  static const struct intel_device_info intel_ivybridge_m_info = {
 @@ -237,6 +240,7 @@ static const struct intel_device_info 
 intel_ivybridge_m_info = {
   .has_fbc = 0,   /* FBC is not enabled on Ivybridge mobile yet */
   .has_bsd_ring = 1,
   .has_blt_ring = 1,
 + .has_llc = 1,
  };
  
  static const struct pci_device_id pciidlist[] = {/* aka */
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 4a9c1b9..abbbf32 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -250,6 +250,7 @@ struct intel_device_info {
   u8 supports_tv:1;
   u8 has_bsd_ring:1;
   u8 has_blt_ring:1;
 + u8 has_llc:1;
  };
  
  enum no_fbc_reason {
 @@ -961,6 +962,7 @@ struct drm_i915_file_private {
  
  #define HAS_BSD(dev)(INTEL_INFO(dev)-has_bsd_ring)
  #define HAS_BLT(dev)(INTEL_INFO(dev)-has_blt_ring)
 +#define HAS_LLC(dev)(INTEL_INFO(dev)-has_llc)
  #define I915_NEED_GFX_HWS(dev)   (INTEL_INFO(dev)-need_gfx_hws)
  
  #define HAS_OVERLAY(dev) (INTEL_INFO(dev)-has_overlay)
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 60ff1b6..fb69337 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -3620,8 +3620,8 @@ struct drm_i915_gem_object 
 *i915_gem_alloc_object(struct drm_device *dev,
   obj-base.write_domain = I915_GEM_DOMAIN_CPU;
   obj-base.read_domains = I915_GEM_DOMAIN_CPU;
  
 - if (IS_GEN6(dev) || IS_GEN7(dev)) {
 - /* On Gen6, we can have the GPU use the LLC (the CPU
 + if (HAS_LLC(dev)) {
 + /* On some devices, we can have the GPU use the LLC (the CPU
* cache) for about a 10% performance improvement
* compared to uncached.  Graphics requests other than
* display scanout are coherent with the CPU in
 diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
 index

Re: [Intel-gfx] [PATCH] drm/i915: Only look for matching clocks for LVDS downclock

2012-01-16 Thread Keith Packard

On Mon, 16 Jan 2012 21:21:45 +0100, Daniel Vetter dan...@ffwll.ch wrote:
 On Mon, Jan 16, 2012 at 12:20:03PM -0800, Jesse Barnes wrote:

  Yeah looks like a good cleanup that also makes downclocking more likely.
  
  Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
 
 Queued for -next, thanks for the patch.

Jesse -- do you think this patch should go into -fixes for 3.3? Or
should we leave it for 3.4?

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


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

Re: [Intel-gfx] HDMI colour space and depth questions (YCbCr, xvYCC, Deep Colour)

On 16 January 2012 18:03, Jesse Barnes jbar...@virtuousgeek.org wrote:

 There is some 30 bit support in place, but not 36bpp, which is what
 HDMI sinks generally want.

I did a little experiment, adding a Depth 30 setting to the Display
SubSection for the Screen (and removing all lower depth entries) also
a DefaultDepth 30

Judging by the scrambled wallpaper, this did at least change the
memory buffer layout! But the AV amp still reported the colour depth
as 8 bit, not 10bit, any other knobs I should have played with?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/sdvo: Enforce more timing requirements

On Tue, Dec 13, 2011 at 02:09:28PM -0200, Paulo Zanoni wrote:
 Hi
 
 2011/12/13 Adam Jackson a...@redhat.com:
  +       if (mode-vtotal - mode-vdisplay  3)
  +               return MODE_VBLANK_NARROW;
  +
  +       if (mode-vsync_end - mode-vsync_start  1)
  +               return MODE_VSYNC_NARROW;
  +
  +       if (mode-htotal - mode-hdisplay  16)
  +               return MODE_HBLANK_NARROW;
  +
  +       if (mode-hsync_end - mode-hsync_start  16)
 
 I believe in this line above it should be 2 instead of 16.
 
  +               return MODE_HSYNC_NARROW;
  +
         return MODE_OK;
   }

Anything up with this patch or is this one for the bitbucket in the binary
heavens?
-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] Problem Intel i915 driver, i3 2010T, HDMI output modes problems

[apologies for munged threading, I subscribed after the original
message was sent]

paulo louro wrote:

 When starting ubuntu without the AV receiver or the TV being on, the xorg 
 start with a resolution of 720x576.

Have you tried forcing an initial mode in the Monitor section of your xorg.conf?

Option PreferredMode whatever

presumably whatever is something like 1920x1080x60.0 in your case ...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Only look for matching clocks for LVDS downclock

On Mon, 16 Jan 2012 13:56:34 -0800
Keith Packard kei...@keithp.com wrote:

 On Mon, 16 Jan 2012 21:21:45 +0100, Daniel Vetter dan...@ffwll.ch wrote:
  On Mon, Jan 16, 2012 at 12:20:03PM -0800, Jesse Barnes wrote:
 
   Yeah looks like a good cleanup that also makes downclocking more likely.
   
   Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
  
  Queued for -next, thanks for the patch.
 
 Jesse -- do you think this patch should go into -fixes for 3.3? Or
 should we leave it for 3.4?

I'd say leave it for 3.4.  Downclocking is disabled by default anyway
so I don't think this one is urgent.

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [Intel-gfx] HDMI colour space and depth questions (YCbCr, xvYCC, Deep Colour)

On Mon, 16 Jan 2012 21:50:22 +
Andy Burns xorg.li...@burns.me.uk wrote:

 Jesse Barnes jbar...@virtuousgeek.org wrote:
 
  Andy Burns xorg.li...@burns.me.uk wrote:
 
  Similarly is there any setting to indicate an xvYCC gamut, which might
  persuade the amp not to clip the colours?
 
  There is a way to configure the gamut to be compressed (default) or
  expanded (up to 255).  But that's not exposed either.
 
 I see the following from the man page
 
 DVI/HDMI outputs. Avaliable common properties include:
 BROADCAST_RGB - method used to set RGB color range(full range 0-255,
 not full range 16-235)
 Adjusting this propertie allows you to set RGB color range on each
 channel in order to match HDTV requirment(default 0 for full range).
 Setting 1 means RGB color range is 16-235, 0 means RGB color range is
 0-255 on each channel.
 SDVO and DVO TV outputs are not supported by the driver at this time.
 
 Does that mean I *can* toggle the studio colour range on the fly, or
 is the doc wrong?

Ah maybe we do expose it; I'm out of date.  Yeah that should change the
color range handling...

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [Intel-gfx] HDMI colour space and depth questions (YCbCr, xvYCC, Deep Colour)

On Mon, 16 Jan 2012 21:57:29 +
Andy Burns xorg.li...@burns.me.uk wrote:

 On 16 January 2012 18:03, Jesse Barnes jbar...@virtuousgeek.org wrote:
 
  There is some 30 bit support in place, but not 36bpp, which is what
  HDMI sinks generally want.
 
 I did a little experiment, adding a Depth 30 setting to the Display
 SubSection for the Screen (and removing all lower depth entries) also
 a DefaultDepth 30
 
 Judging by the scrambled wallpaper, this did at least change the
 memory buffer layout! But the AV amp still reported the colour depth
 as 8 bit, not 10bit, any other knobs I should have played with?

I think we still dither down to 8 for HDMI sinks, since they generally
only report 8bpc or 12bpc.  So unless you want to add 12bpc support
(mostly mechanical as far as the kernel goes) you'll be stuck with 8bpc
on HDMI.

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [Intel-gfx] [PATCH] [RFC] drm/i915: read-read semaphore optimization

2012-01-16 Thread Ben Widawsky

On 01/16/2012 01:50 PM, Daniel Vetter wrote:
 On Tue, Dec 13, 2011 at 10:36:15AM -0800, Ben Widawsky wrote:
 On 12/13/2011 09:22 AM, Eric Anholt wrote:
 On Mon, 12 Dec 2011 19:52:08 -0800, Ben Widawskyb...@bwidawsk.net  wrote:
 Since we don't differentiate on the different GPU read domains, it
 should be safe to allow back to back reads to occur without issuing a
 wait (or flush in the non-semaphore case).

 This has the unfortunate side effect that we need to keep track of all
 the outstanding buffer reads so that we can synchronize on a write, to
 another ring (since we don't know which read finishes first). In other
 words, the code is quite simple for two rings, but gets more tricky for
 2 rings.

 Here is a picture of the solution to the above problem

 Ring 0Ring 1 Ring 2
 batch 0   batch 1batch 2
   read buffer A read buffer A  wait batch 0
wait batch 1
write buffer A

 This code is really untested. I'm hoping for some feedback if this is
 worth cleaning up, and testing more thoroughly.

 You say it's an optimization -- do you have performance numbers?

 33% improvement on a hacked version of gem_ring_sync_loop with.

 It's not really a valid test as it's not coherent, but this is
 approximately the best case improvement.

 Oddly semaphores doesn't make much difference in this test, which
 was surprising.
 
 Our domain tracking is already complicated in unfunny ways. And (at least
 without a use-case showing gains with hard numbers in either perf or power
 usage) I think this patch is the kind of this looks cool stuff that
 added a lot to the current problem.
 
 So before adding more complexity on top I'd like to remove some of the
 superflous stuff we already have. I.e. all the flushing_list stuff and
 maybe other things ...

Can you be more clear on what exactly you want done before taking a
patch like this? Maybe I can work on it during some down time.

 
 Cheers, Daniel

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

Re: [Intel-gfx] [PATCH 4/8] drm/i915: fix typo in function name

On Mon, Nov 28, 2011 at 04:15:17PM -0200, Eugeni Dodonov wrote:
 Fix function name in comments, a left-over from when i965_reset was
 renamed to i915_reset.
 
 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com

Queued for -next, thanks for the patch. The drm core i2c is pending an ack
from Dave, everything else should be merged already afaics.
-Daniel
 ---
  drivers/gpu/drm/i915/i915_drv.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
 index ea0aa20..cc752dd 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ b/drivers/gpu/drm/i915/i915_drv.c
 @@ -581,7 +581,7 @@ static int gen6_do_reset(struct drm_device *dev, u8 flags)
  }
  
  /**
 - * i965_reset - reset chip after a hang
 + * i915_reset - reset chip after a hang
   * @dev: drm device to reset
   * @flags: reset domains
   *
 -- 
 1.7.7.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: Check that plane/pipe is disabled before removing the fb

On Thu, Nov 24, 2011 at 06:22:18PM +, Chris Wilson wrote:
 Staring at an error state such as:
 
 PGTBL_ER: 0x0400
 Display B: Invalid tiling
 fence[0] = 05001001
 valid, x-tiled, pitch: 512, start: 0x0500, size: 1048576
 Pinned [2]:
      131072 0001 0001  P uncached
   0002  4096000 0041   P uncached (name: 1)
 Plane [1]:
   CNTR: c000 # enabled | gamma
   STRIDE: 1400
   SIZE: 03ff04ff
   POS: 
   ADDR: 0500
 
 Suggests that we did not clear the DSPBCNTR prior to unpinning the
 framebuffer and reusing the GTT space. Impossible! Unless our DPMS
 bookkeeping ran afoul again...
 
 In the meantime add an assertion that the plane is decoupled from the
 framebuffer prior to release.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

Jesse acked this on irc, but it doesn't apply anymore. Care to rebase?
-Daniel

 ---
  drivers/gpu/drm/i915/intel_display.c |   17 -
  1 files changed, 12 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 5d4cbff..800b36e 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -932,19 +932,24 @@ static void assert_pipe(struct drm_i915_private 
 *dev_priv,
  #define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
  #define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
  
 -static void assert_plane_enabled(struct drm_i915_private *dev_priv,
 -  enum plane plane)
 +static void assert_plane(struct drm_i915_private *dev_priv,
 +  enum plane plane, bool state)
  {
   int reg;
   u32 val;
 + bool cur_state;
  
   reg = DSPCNTR(plane);
   val = I915_READ(reg);
 - WARN(!(val  DISPLAY_PLANE_ENABLE),
 -  plane %c assertion failure, should be active but is disabled\n,
 -  plane_name(plane));
 + cur_state = !!(val  DISPLAY_PLANE_ENABLE);
 + WARN(cur_state != state,
 +  plane %c assertion failure (expected %s, current %s)\n,
 +  plane_name(plane), state_string(state), state_string(cur_state));
  }
  
 +#define assert_plane_enabled(d, p) assert_plane(d, p, true)
 +#define assert_plane_disabled(d, p) assert_plane(d, p, false)
 +
  static void assert_planes_disabled(struct drm_i915_private *dev_priv,
  enum pipe pipe)
  {
 @@ -3320,6 +3325,8 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
   struct drm_device *dev = crtc-dev;
  
   crtc_funcs-dpms(crtc, DRM_MODE_DPMS_OFF);
 + assert_plane_disabled(dev-dev_private, to_intel_crtc(crtc)-plane);
 + assert_pipe_disabled(dev-dev_private, to_intel_crtc(crtc)-pipe);
  
   if (crtc-fb) {
   mutex_lock(dev-struct_mutex);
 -- 
 1.7.7.3
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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

[Intel-gfx] [PATCH] drm/i915: Check that plane/pipe is disabled before removing the fb

2012-01-16 Thread Chris Wilson

Staring at an error state such as:

PGTBL_ER: 0x0400
Display B: Invalid tiling
fence[0] = 05001001
valid, x-tiled, pitch: 512, start: 0x0500, size: 1048576
Pinned [2]:
     131072 0001 0001  P uncached
  0002  4096000 0041   P uncached (name: 1)
Plane [1]:
  CNTR: c000 # enabled | gamma
  STRIDE: 1400
  SIZE: 03ff04ff
  POS: 
  ADDR: 0500

Suggests that we did not clear the DSPBCNTR prior to unpinning the
framebuffer and reusing the GTT space. Impossible! Unless our DPMS
bookkeeping ran afoul again...

In the meantime add an assertion that the plane is decoupled from the
framebuffer prior to release.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
Cc: Daniel Vetter dan...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_display.c |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 29743de..708a181 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -930,19 +930,24 @@ void assert_pipe(struct drm_i915_private *dev_priv,
 pipe_name(pipe), state_string(state), state_string(cur_state));
 }
 
-static void assert_plane_enabled(struct drm_i915_private *dev_priv,
-enum plane plane)
+static void assert_plane(struct drm_i915_private *dev_priv,
+enum plane plane, bool state)
 {
int reg;
u32 val;
+   bool cur_state;
 
reg = DSPCNTR(plane);
val = I915_READ(reg);
-   WARN(!(val  DISPLAY_PLANE_ENABLE),
-plane %c assertion failure, should be active but is disabled\n,
-plane_name(plane));
+   cur_state = !!(val  DISPLAY_PLANE_ENABLE);
+   WARN(cur_state != state,
+plane %c assertion failure (expected %s, current %s)\n,
+plane_name(plane), state_string(state), state_string(cur_state));
 }
 
+#define assert_plane_enabled(d, p) assert_plane(d, p, true)
+#define assert_plane_disabled(d, p) assert_plane(d, p, false)
+
 static void assert_planes_disabled(struct drm_i915_private *dev_priv,
   enum pipe pipe)
 {
@@ -3321,6 +3326,8 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
struct drm_device *dev = crtc-dev;
 
crtc_funcs-dpms(crtc, DRM_MODE_DPMS_OFF);
+   assert_plane_disabled(dev-dev_private, to_intel_crtc(crtc)-plane);
+   assert_pipe_disabled(dev-dev_private, to_intel_crtc(crtc)-pipe);
 
if (crtc-fb) {
mutex_lock(dev-struct_mutex);
-- 
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] drm/i915: set AUD_CONFIG N_value_index for DisplayPort

On Mon, Jan 16, 2012 at 12:44:43PM -0800, Keith Packard wrote:
 On Mon, 16 Jan 2012 21:26:18 +0100, Daniel Vetter dan...@ffwll.ch wrote:
 
  Keith, does this address your concern and this patch is r-b: Keith or do
  we want an
  
  } else {
  I915_WRITE(aud_config, 0);
  }
  
  for paranoia?
 
 I think we want this added, just to be sure we set the configuration
 correctly in all cases; it's easy to imagine moving from DP to HDMI and
 leaving this bit set.

Ah good point! Here is the updated patch.

---
Subject: drm/i915: set AUD_CONFIG N_value_index for DisplayPort
Date: Fri Jan 06 14:41:31 CST 2012

It should be programmed to 0 for HDMI or 1 for DisplayPort.

This enables DisplayPort audio for

- HP EliteBook 8460p
  (whose BIOS does not set the N_value_index bit for us)

- DisplayPort monitor hot plugged after boot
  (otherwise most BIOS will fill the N_value_index bit for us)

Tested-by: Robert Lemaire rlema...@suse.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
 drivers/gpu/drm/i915/i915_reg.h  |   12 
 drivers/gpu/drm/i915/intel_display.c |8 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

--- linux.orig/drivers/gpu/drm/i915/i915_reg.h  2012-01-07 23:11:10.0 
+0800
+++ linux/drivers/gpu/drm/i915/i915_reg.h   2012-01-10 13:20:17.0 
+0800
@@ -3582,4 +3582,16 @@
 #define CPT_AUD_CNTL_ST_A  0xE50B4
 #define CPT_AUD_CNTRL_ST2  0xE50C0
 
+#define IBX_AUD_CONFIG_A   0xe2000
+#define CPT_AUD_CONFIG_A   0xe5000
+#define   AUD_CONFIG_N_VALUE_INDEX (1  29)
+#define   AUD_CONFIG_N_PROG_ENABLE (1  28)
+#define   AUD_CONFIG_UPPER_N_SHIFT 20
+#define   AUD_CONFIG_UPPER_N_VALUE (0xff  20)
+#define   AUD_CONFIG_LOWER_N_SHIFT 4
+#define   AUD_CONFIG_LOWER_N_VALUE (0xfff  4)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_SHIFT16
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI  (0xf  16)
+#define   AUD_CONFIG_DISABLE_NCTS  (1  3)
+
 #endif /* _I915_REG_H_ */
--- linux.orig/drivers/gpu/drm/i915/intel_display.c 2012-01-07 
23:11:10.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_display.c  2012-01-17 07:06:29.0 
+0800
@@ -5908,15 +5908,18 @@ static void ironlake_write_eld(struct dr
uint32_t i;
int len;
int hdmiw_hdmiedid;
+   int aud_config;
int aud_cntl_st;
int aud_cntrl_st2;
 
if (HAS_PCH_IBX(connector-dev)) {
hdmiw_hdmiedid = IBX_HDMIW_HDMIEDID_A;
+   aud_config = IBX_AUD_CONFIG_A;
aud_cntl_st = IBX_AUD_CNTL_ST_A;
aud_cntrl_st2 = IBX_AUD_CNTL_ST2;
} else {
hdmiw_hdmiedid = CPT_HDMIW_HDMIEDID_A;
+   aud_config = CPT_AUD_CONFIG_A;
aud_cntl_st = CPT_AUD_CNTL_ST_A;
aud_cntrl_st2 = CPT_AUD_CNTRL_ST2;
}
@@ -5924,6 +5927,7 @@ static void ironlake_write_eld(struct dr
i = to_intel_crtc(crtc)-pipe;
hdmiw_hdmiedid += i * 0x100;
aud_cntl_st += i * 0x100;
+   aud_config += i * 0x100;
 
DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(i));
 
@@ -5943,7 +5947,9 @@ static void ironlake_write_eld(struct dr
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
eld[5] |= (1  2); /* Conn_Type, 0x1 = DisplayPort */
-   }
+   I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 = DP */
+   } else
+   I915_WRITE(aud_config, 0);
 
if (intel_eld_uptodate(connector,
   aud_cntrl_st2, eldv,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] intel_audio_dump: fix missing Audio DIP tabs

This makes the SNB/IVY Audio DIP values aligned with others.

Signed-off-by: Wu Fengguang fengguang...@intel.com
---
 tools/intel_audio_dump.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- intel-gpu-tools.orig/tools/intel_audio_dump.c   2012-01-16 
15:33:11.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2012-01-16 15:33:18.0 
+0800
@@ -1207,7 +1207,7 @@ static void dump_cpt(void)
 dword = INREG(AUD_CNTL_ST_A);
 printf(AUD_CNTL_ST_A  DIP_Port_Select\t\t\t\t[%#lx] %s\n,
BITS(dword, 30, 29), 
dip_port[BITS(dword, 30, 29)]);
-printf(AUD_CNTL_ST_A  DIP_type_enable_status Audio DIP\t%lu\n, 
BIT(dword, 21));
+printf(AUD_CNTL_ST_A  DIP_type_enable_status Audio DIP\t\t%lu\n, 
BIT(dword, 21));
 printf(AUD_CNTL_ST_A  DIP_type_enable_status ACP DIP\t\t%lu\n, 
BIT(dword, 22));
 printf(AUD_CNTL_ST_A  DIP_type_enable_status Generic 2 DIP\t%lu\n, 
BIT(dword, 23));
 printf(AUD_CNTL_ST_A  DIP_transmission_frequency\t\t[0x%lx] %s\n,
@@ -1218,7 +1218,7 @@ static void dump_cpt(void)
 dword = INREG(AUD_CNTL_ST_B);
 printf(AUD_CNTL_ST_B  DIP_Port_Select\t\t\t\t[%#lx] %s\n,
BITS(dword, 30, 29), 
dip_port[BITS(dword, 30, 29)]);
-printf(AUD_CNTL_ST_B  DIP_type_enable_status Audio DIP\t%lu\n, 
BIT(dword, 21));
+printf(AUD_CNTL_ST_B  DIP_type_enable_status Audio DIP\t\t%lu\n, 
BIT(dword, 21));
 printf(AUD_CNTL_ST_B  DIP_type_enable_status ACP DIP\t\t%lu\n, 
BIT(dword, 22));
 printf(AUD_CNTL_ST_B  DIP_type_enable_status Generic 2 DIP\t%lu\n, 
BIT(dword, 23));
 printf(AUD_CNTL_ST_B  DIP_transmission_frequency\t\t[0x%lx] %s\n,
@@ -1229,7 +1229,7 @@ static void dump_cpt(void)
 dword = INREG(AUD_CNTL_ST_C);
 printf(AUD_CNTL_ST_C  DIP_Port_Select\t\t\t\t[%#lx] %s\n,
BITS(dword, 30, 29), 
dip_port[BITS(dword, 30, 29)]);
-printf(AUD_CNTL_ST_C  DIP_type_enable_status Audio DIP\t%lu\n, 
BIT(dword, 21));
+printf(AUD_CNTL_ST_C  DIP_type_enable_status Audio DIP\t\t%lu\n, 
BIT(dword, 21));
 printf(AUD_CNTL_ST_C  DIP_type_enable_status ACP DIP\t\t%lu\n, 
BIT(dword, 22));
 printf(AUD_CNTL_ST_C  DIP_type_enable_status Generic 2 DIP\t%lu\n, 
BIT(dword, 23));
 printf(AUD_CNTL_ST_C  DIP_transmission_frequency\t\t[0x%lx] %s\n,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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