Re: [Intel-gfx] [PATCH] drm/i915: Don't write DSPSURF for old chips

2012-02-29 Thread Takashi Iwai
At Wed, 29 Feb 2012 23:54:46 +, Chris Wilson wrote: > > On Tue, 28 Feb 2012 07:43:55 +0100, Takashi Iwai wrote: > > At Mon, 27 Feb 2012 14:08:28 +0100, > > Takashi Iwai wrote: > > > > > > At Mon, 27 Feb 2012 12:17:57 +, > > > Chris Wilson wrote: > > > > > > > > On Mon, 27 Feb 2012 12:39

[Intel-gfx] Muhammad Jamil invites you to connect

2012-02-29 Thread Muhammad Jamil via Yahoo!
Join Muhammad Jamil on Yahoo! Messenger. Come chat with me, share files and more. Stay in the loop with all your friends. Get started : http://invite.msg.yahoo.com/invite?op=accept&intl=us&sig=kWBCvshIMGDauR4TZmRlPvf7B_vw5St_DE_.NxtguEHV3f7JstsazUHYieZW * Stay connected at home, at work, or on

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

2012-02-29 Thread Paul Owen
On 29 February 2012 18:36, Jesse Barnes wrote: > > Can you file a bug with the findings above just so we don't lose it?  I > expect the fix should be pretty easy, but I don't want to lose track of > this. Done - hope that I submitted to the right place in the right way! Thanks again. https://bug

Re: [Intel-gfx] [PATCH] drm/i915: Don't write DSPSURF for old chips

2012-02-29 Thread Chris Wilson
On Tue, 28 Feb 2012 07:43:55 +0100, Takashi Iwai wrote: > At Mon, 27 Feb 2012 14:08:28 +0100, > Takashi Iwai wrote: > > > > At Mon, 27 Feb 2012 12:17:57 +, > > Chris Wilson wrote: > > > > > > On Mon, 27 Feb 2012 12:39:24 +0100, Takashi Iwai wrote: > > > > It seems that writing DSPSURF in in

Re: [Intel-gfx] [PATCH] mm: extend prefault helpers to fault in more than PAGE_SIZE

2012-02-29 Thread Andrew Morton
On Thu, 1 Mar 2012 00:14:53 +0100 Daniel Vetter wrote: > I'll redo this patch by adding _multipage versions of these 2 functions > for i915. OK, but I hope "for i915" doesn't mean "private to"! Put 'em in pagemap.h, for maintenance reasons and because they are generic. Making them inline is a

Re: [Intel-gfx] [PATCH] mm: extend prefault helpers to fault in more than PAGE_SIZE

2012-02-29 Thread Daniel Vetter
On Wed, Feb 29, 2012 at 03:01:46PM -0800, Andrew Morton wrote: > On Wed, 29 Feb 2012 15:03:31 +0100 > Daniel Vetter wrote: > > > drm/i915 wants to read/write more than one page in its fastpath > > and hence needs to prefault more than PAGE_SIZE bytes. > > > > I've checked the callsites and they

Re: [Intel-gfx] [PATCH] mm: extend prefault helpers to fault in more than PAGE_SIZE

2012-02-29 Thread Andrew Morton
On Wed, 29 Feb 2012 15:03:31 +0100 Daniel Vetter wrote: > drm/i915 wants to read/write more than one page in its fastpath > and hence needs to prefault more than PAGE_SIZE bytes. > > I've checked the callsites and they all already clamp size when > calling fault_in_pages_* to the same as for the

Re: [Intel-gfx] [PATCH 1/7] drm/i915: add dev_priv to intel_gmbus

2012-02-29 Thread Daniel Vetter
On Mon, Feb 27, 2012 at 02:53:37PM -0300, Eugeni Dodonov wrote: > On Tue, Feb 14, 2012 at 19:37, Daniel Vetter wrote: > > > This way we can free up the bus->adaptor.algo_data pointer and make it > > available for use with the bitbanging fallback algo. > > > > Signed-Off-by: Daniel Vetter > > >

Re: [Intel-gfx] [PATCH] i2c: export bit-banging algo functions

2012-02-29 Thread Daniel Vetter
On Tue, Feb 28, 2012 at 09:08:17AM +0100, Jean Delvare wrote: > On Tue, 28 Feb 2012 00:39:39 +0100, Daniel Vetter wrote: > > i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons > > we need to be able to fall back to the bit-banging algo on gpio pins. > > > > The current code set

Re: [Intel-gfx] [PATCH] drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo

2012-02-29 Thread Daniel Vetter
On Tue, Feb 28, 2012 at 12:42:19AM +0100, Daniel Vetter wrote: > I'd like to export the corresponding functions from the i2c core > so that I can use them in fallback bit-banging in i915.ko > > v2: Adapt to new i2c export patch. > > Cc: nouv...@lists.freedesktop.org > Signed-off-by: Daniel Vetter

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

2012-02-29 Thread Jesse Barnes
On Wed, 29 Feb 2012 15:38:44 + Paul Owen wrote: > On 28 February 2012 17:59, Jesse Barnes > wrote: > > > > There are several places we need to set extended vs normal range: > > DSP*CNTR (bit 25) > > PIPE*CONF (bits 26 and 13) > > TRANS*CONF (bit 10, for xvYCC DP configs) > > DVS*CNTR (for sp

[Intel-gfx] [PATCH 3/3] intel_reg_read: add a flag to simplify bit decoding

2012-02-29 Thread Eugeni Dodonov
This allows to specify '-d' parameter which will decode individual bits in each register being read. The register bits are printed horizontally for space reasons. This requires more than 80x25 terminal to see them all. An alternative solution would be to print them vertically, but this will become

[Intel-gfx] [PATCH 2/3] intel_reg_read: support reading multiple registers

2012-02-29 Thread Eugeni Dodonov
The registers must be passed on the command line and will be read sequentially, one at a time. Signed-off-by: Eugeni Dodonov --- tools/intel_reg_read.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/tools/intel_reg_read.c b/tools/intel_reg_read.c index 95d28c5

[Intel-gfx] [PATCH 1/3] intel_reg_read: add support for getopt

2012-02-29 Thread Eugeni Dodonov
This will allow us to pass more options to it in the future. v2: fix whitespacing issues and improve scary warning text as suggested by Paul Menzel. Reviewed-by: Paul Menzel Signed-off-by: Eugeni Dodonov --- tools/intel_reg_read.c | 44 +++- 1 file cha

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

2012-02-29 Thread Paul Owen
On 28 February 2012 17:59, Jesse Barnes wrote: > > There are several places we need to set extended vs normal range: > DSP*CNTR (bit 25) > PIPE*CONF (bits 26 and 13) > TRANS*CONF (bit 10, for xvYCC DP configs) > DVS*CNTR (for sprites, bit 21) Okay - good learning exercise for me this! So by defau

[Intel-gfx] [PATCH] mm: extend prefault helpers to fault in more than PAGE_SIZE

2012-02-29 Thread Daniel Vetter
drm/i915 wants to read/write more than one page in its fastpath and hence needs to prefault more than PAGE_SIZE bytes. I've checked the callsites and they all already clamp size when calling fault_in_pages_* to the same as for the subsequent __copy_to|from_user and hence don't rely on the implicit