[PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Russell King - ARM Linux
On Mon, Nov 12, 2012 at 05:33:41PM -0600, Rob Clark wrote:
> I'm sort of thinking maybe we want to change 'switch (sizeof(*(__p)))'
> with 'switch (sizeof(typeof(x)))' in case someone ignores the compiler
> warning when they try something like:

Definitely not.  Ttype of access is controlled by the pointer, not by the
size of what it's being assigned to.  Switching that around is likely to
break stuff hugely.  Consider this:

unsigned char __user *p;
int val;

get_user(val, p);

If the pointer type is used to determine the access size, a char will be
accessed.  This is legal - because we end up assigning an unsigned character
to an int.

If the size of the destination was used, we'd access an int instead, which
is larger than the pointer, and probably the wrong thing to do anyway.

Think of get_user(a, b) as being a special accessor having the ultimate
semantics of: "a = *b;" but done in a safe way with error checking.

>uint32_t x;
>uint64_t *p = ...;
>get_user(x, p);
> 
> that was my one concern about 'register typeof(x) __r2 ...', but I
> think just changing the switch condition is enough.  But maybe good to
> have some eyes on in case there is something else I'm not thinking of.

And what should happen in the above is exactly the same as what happens
if you do:

x = *p;

with those types.  For ARM, that would be a 64-bit access (if the
compiler decides not to optimize away the upper 32-bit access) followed
by a narrowing cast down to 32-bit.  With get_user() of course, there's
no option not to optimize it away.

However, this _does_ reveal a bug with your approach.  With sizeof(*p)
being 8, and the type of __r2 being a 32-bit quantity, the compiler will
choose the 64-bit accessor, which will corrupt r3 - and the compiler
won't know that r3 has been corrupted.

That's too unsafe.

I just tried a variant of your approach, but got lots of warnings again:
register unsigned long long __r2 asm("r2");
__get_user_x(__r2, __p, __e, 8, "lr");
x = (typeof(*(__p))) ((typeof(x))__r2);
because typeof(x) in the test_ptr() case ends up being a pointer itself.

So, back to the drawing board, and I think back to the original position
of "we don't support this".


i915 hang and large allocation (~3.7-rc4)

2012-11-12 Thread Daniel Vetter
On Mon, Nov 12, 2012 at 02:44:46PM -0800, Dave Hansen wrote:
> I've been seeing a little goofiness with i915 video under the 3.7-rc's.
> It looks like I'm seeing two separate issues.  One, that the video
> hardware hangs, spits some errors in dmesg, and then video acceleration
> seems to stop working.  Two, when it does this, apport goes digging in
> debugfs for information about the hang.  When it does this, something
> does an order-9 (2MB) kmalloc() which fails.
> 
> While debugfs is expected to be a _bit_ rickety, I do think order-9
> is a bit excessive for an in-kernel allocation, even a temporary
> one.  I'm not quite sure if it has done this for a long time, and I'm
> only hitting it now since I'm seeing a _separate_ i915 hang.
> 
> Relevant parts of dmesg, lspci, and kernel config are here:
> 
>   http://sr71.net/~dave/linux/i915-wonky/

Ironlake gpu, so if this is a regression introduced in 3.7 and things work
normally in 3.6, it's likely that you're hitting a variant of

https://bugs.freedesktop.org/show_bug.cgi?id=55984

It'd be best if you can subscribe yourselfes there, so that all potential
testers are at the same place.

For the 2MB allocation, this is a known problem, unfortunately reworking
the dump code will be major work. Which is why it hasn't been done yet.
But fixing that is somewhere on our giant todo list.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: [PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Russell King - ARM Linux
On Mon, Nov 12, 2012 at 05:33:41PM -0600, Rob Clark wrote:
> I'm sort of thinking maybe we want to change 'switch (sizeof(*(__p)))'
> with 'switch (sizeof(typeof(x)))' in case someone ignores the compiler
> warning when they try something like:

Definitely not.  Ttype of access is controlled by the pointer, not by the
size of what it's being assigned to.  Switching that around is likely to
break stuff hugely.  Consider this:

unsigned char __user *p;
int val;

get_user(val, p);

If the pointer type is used to determine the access size, a char will be
accessed.  This is legal - because we end up assigning an unsigned character
to an int.

If the size of the destination was used, we'd access an int instead, which
is larger than the pointer, and probably the wrong thing to do anyway.

Think of get_user(a, b) as being a special accessor having the ultimate
semantics of: "a = *b;" but done in a safe way with error checking.

>uint32_t x;
>uint64_t *p = ...;
>get_user(x, p);
> 
> that was my one concern about 'register typeof(x) __r2 ...', but I
> think just changing the switch condition is enough.  But maybe good to
> have some eyes on in case there is something else I'm not thinking of.

And what should happen in the above is exactly the same as what happens
if you do:

x = *p;

with those types.  For ARM, that would be a 64-bit access (if the
compiler decides not to optimize away the upper 32-bit access) followed
by a narrowing cast down to 32-bit.  With get_user() of course, there's
no option not to optimize it away.

However, this _does_ reveal a bug with your approach.  With sizeof(*p)
being 8, and the type of __r2 being a 32-bit quantity, the compiler will
choose the 64-bit accessor, which will corrupt r3 - and the compiler
won't know that r3 has been corrupted.

That's too unsafe.

I just tried a variant of your approach, but got lots of warnings again:
register unsigned long long __r2 asm("r2");
__get_user_x(__r2, __p, __e, 8, "lr");
x = (typeof(*(__p))) ((typeof(x))__r2);
because typeof(x) in the test_ptr() case ends up being a pointer itself.

So, back to the drawing board, and I think back to the original position
of "we don't support this".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Russell King - ARM Linux
On Mon, Nov 12, 2012 at 01:58:32PM -0600, Rob Clark wrote:
> On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
>  wrote:
> > On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
> >> From: Rob Clark 
> >>
> >> A new atomic modeset/pageflip ioctl being developed in DRM requires
> >> get_user() to work for 64bit types (in addition to just put_user()).
> >
> > NAK.
> >
> > (I did write a better email explaining all the ins and outs of why this
> > won't work and why 64-bit get_user isn't possible, but my editor crapped
> > out and lost all that well written message; I don't fancy typing it all
> > out again.)
> >
> > Nevertheless,
> > int test_ptr(unsigned int **v, unsigned int **p)
> > {
> > return get_user(*v, p);
> > }
> >
> > produces a warning, and you can't get away from that if you stick 64-bit
> > support into get_user().
> 
> Actually, it seems like using 'register typeof(x) __r2 asm("r2");'
> does avoid that warning..

That seems to pass the checks I've done on it so far, and seems rather
obvious (there's been a number of people looking at this, none of whom
have come up with that solution).  Provided the final cast is kept
(which is there to ensure proper typechecking), it seems like it might
be a solution.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


i915 hang and large allocation (~3.7-rc4)

2012-11-12 Thread Dave Hansen
I've been seeing a little goofiness with i915 video under the 3.7-rc's.
It looks like I'm seeing two separate issues.  One, that the video
hardware hangs, spits some errors in dmesg, and then video acceleration
seems to stop working.  Two, when it does this, apport goes digging in
debugfs for information about the hang.  When it does this, something
does an order-9 (2MB) kmalloc() which fails.

While debugfs is expected to be a _bit_ rickety, I do think order-9
is a bit excessive for an in-kernel allocation, even a temporary
one.  I'm not quite sure if it has done this for a long time, and I'm
only hitting it now since I'm seeing a _separate_ i915 hang.

Relevant parts of dmesg, lspci, and kernel config are here:

http://sr71.net/~dave/linux/i915-wonky/

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: Fix for vblank on nvc0

2012-11-12 Thread Kelly Doran
I had Sven test this patch... he said it works.  I think chipset
number test was executing code that we thought was only either 0x50 or
0xc0, but was actually more specific with things like 0x92.

On Sun, Nov 11, 2012 at 2:25 PM, Maarten Lankhorst
 wrote:
> Op 11-11-12 19:35, Marcin Slusarz schreef:
>> On Sun, Nov 11, 2012 at 07:26:17PM +0100, Marcin Slusarz wrote:
>>> On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote:

 Op 06-11-12 15:48, Kelly Doran schreef:
> The vblank on nvc0 was not working correctly and would freeze X, I managed
> to track it down and fix it with some help from m.b.lankhorst, see
> https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.
>
 Reviewed-by: Maarten Lankhorst 

 I recommended the bar flush since nvd0 does as well, and there might be a 
 small race
 otherwise.

 Can this still get in before final 3.7 release?
>>> This patch breaks vblank here (nv92) completely.
> Does removing the bar flush help?
>
> ~Maarte


vblank-fix1.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Russell King - ARM Linux
On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
> From: Rob Clark 
> 
> A new atomic modeset/pageflip ioctl being developed in DRM requires
> get_user() to work for 64bit types (in addition to just put_user()).

NAK.

(I did write a better email explaining all the ins and outs of why this
won't work and why 64-bit get_user isn't possible, but my editor crapped
out and lost all that well written message; I don't fancy typing it all
out again.)

Nevertheless,
int test_ptr(unsigned int **v, unsigned int **p)
{
return get_user(*v, p);
}

produces a warning, and you can't get away from that if you stick 64-bit
support into get_user().

Sorry, 64-bit get_user() is a no-no.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 2/6] video: add of helper for videomode

2012-11-12 Thread Alexey Klimov
Hello Steffen,

On Mon, Nov 12, 2012 at 7:37 PM, Steffen Trumtrar
 wrote:
> This adds support for reading display timings from DT or/and convert one of 
> those
> timings to a videomode.
> The of_display_timing implementation supports multiple children where each
> property can have up to 3 values. All children are read into an array, that
> can be queried.
> of_get_videomode converts exactly one of that timings to a struct videomode.
>
> Signed-off-by: Steffen Trumtrar 
> Signed-off-by: Philipp Zabel 
> ---
>  .../devicetree/bindings/video/display-timings.txt  |  107 +++
>  drivers/video/Kconfig  |   13 ++
>  drivers/video/Makefile |2 +
>  drivers/video/of_display_timing.c  |  186 
> 
>  drivers/video/of_videomode.c   |   47 +
>  include/linux/of_display_timings.h |   19 ++
>  include/linux/of_videomode.h   |   15 ++
>  7 files changed, 389 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/video/display-timings.txt
>  create mode 100644 drivers/video/of_display_timing.c
>  create mode 100644 drivers/video/of_videomode.c
>  create mode 100644 include/linux/of_display_timings.h
>  create mode 100644 include/linux/of_videomode.h
>
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
> index 000..e22e2fd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> @@ -0,0 +1,107 @@
> +display-timings bindings
> +
> +
> +display-timings-node
> +
> +
> +required properties:
> + - none
> +
> +optional properties:
> + - native-mode: the native mode for the display, in case multiple modes are
> +   provided. When omitted, assume the first node is the native.
> +
> +timings-subnode
> +---
> +
> +required properties:
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> +   in pixels
> +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
> in
> +   lines
> + - clock-frequency: displayclock in Hz
> +
> +optional properties:
> + - hsync-active : Hsync pulse is active low/high/ignored
> + - vsync-active : Vsync pulse is active low/high/ignored
> + - de-active : Data-Enable pulse is active low/high/ignored
> + - pixelclk-inverted : pixelclock is inverted/non-inverted/ignored
> + - interlaced (bool)
> + - doublescan (bool)
> +
> +All the optional properties that are not bool follow the following logic:
> +<1> : high active
> +<0> : low active
> +omitted : not used on hardware
> +
> +There are different ways of describing the capabilities of a display. The 
> devicetree
> +representation corresponds to the one commonly found in datasheets for 
> displays.
> +If a display supports multiple signal timings, the native-mode can be 
> specified.
> +
> +The parameters are defined as
> +
> +struct display_timing
> +=
> +
> +  
> +--+-+--+---+
> +  |  |↑|  |  
>  |
> +  |  ||vback_porch |  |  
>  |
> +  |  |↓|  |  
>  |
> +  
> +--###--+---+
> +  |  #↑#  |  
>  |
> +  |  #|#  |  
>  |
> +  |  hback   #|#  hfront  | 
> hsync |
> +  |   porch  #|   hactive  #  porch   |  len 
>  |
> +  
> |<>#<---+--->#<>|<->|
> +  |  #|#  |  
>  |
> +  |  #|vactive #  |  
>  |
> +  |  #|#  |  
>  |
> +  |  #↓#  |  
>  |
> +  
> +--###--+---+
> +  |  |↑|  |  
>  |
> +  |  ||vfront_porch|  |  
>  |
> +  |  |↓|  |  
>  |
> +  
> +--+-+--+---+
> +  |  |↑|  |  
>  |
> +  |  ||vsync_len   |  |  
>  |
> +  |  |   

Re: [PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Will Deacon
On Mon, Nov 12, 2012 at 01:46:57PM +, Rob Clark wrote:
> On Mon, Nov 12, 2012 at 4:46 AM, Will Deacon  wrote:
> > On Fri, Nov 09, 2012 at 09:17:33PM +, Rob Clark wrote:
> >> @@ -122,22 +124,35 @@ extern int __get_user_4(void *);
> >>   ({  \
> >>   unsigned long __limit = current_thread_info()->addr_limit - 
> >> 1; \
> >>   register const typeof(*(p)) __user *__p asm("r0") = (p);\
> >> - register unsigned long __r2 asm("r2");  \
> >>   register unsigned long __l asm("r1") = __limit; \
> >>   register int __e asm("r0"); \
> >>   switch (sizeof(*(__p))) {   \
> >> - case 1: \
> >> + case 1: {   \
> >> + register unsigned long __r2 asm("r2");  \
> >>   __get_user_x(__r2, __p, __e, __l, 1);   \
> >> + x = (typeof(*(p))) __r2;\
> >>   break;  \
> >> - case 2: \
> >> + }   \
> >> + case 2: {   \
> >> + register unsigned long __r2 asm("r2");  \
> >>   __get_user_x(__r2, __p, __e, __l, 2);   \
> >> + x = (typeof(*(p))) __r2;\
> >>   break;  \
> >> - case 4: \
> >> + }   \
> >> + case 4: {   \
> >> + register unsigned long __r2 asm("r2");  \
> >>   __get_user_x(__r2, __p, __e, __l, 4);   \
> >> + x = (typeof(*(p))) __r2;\
> >> + break;  \
> >> + }   \
> >> + case 8: {   \
> >> + register unsigned long long __r2 asm("r2"); \
> >
> > Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
> > asm, so the compiler shouldn't care much. For OABI, I think you may have to
> > do some more work to get the two words where you want them.
> 
> Is the question whether the compiler is guaranteed to allocate r2 and
> r3 in all cases?  I'm not quite sure, I confess to usually trying to
> avoid inline asm.  But from looking at the disassembly (for little
> endian EABI build) it seemed to do the right thing.

I can't recall how OABI represents 64-bit values and particularly whether this
differs between little and big-endian, so I wondered whether you may have to
do some marshalling when you assign x. However, a few quick experiments with
GCC suggest that the register representation matches EABI in regards to word
ordering (it just doesn't require an even base register), although it would
be good to find this written down somewhere...

> The only other idea I had was to explicitly declare two 'unsigned
> long's and then shift them into a 64bit x, although I'm open to
> suggestions if there is a better way.

Can't you just use register unsigned long long for all cases? Even better,
follow what put_user does and use typeof(*(p))?

> >> diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
> >> index 9b06bb4..d05285c 100644
> >> --- a/arch/arm/lib/getuser.S
> >> +++ b/arch/arm/lib/getuser.S
> >> @@ -18,7 +18,7 @@
> >>   * Inputs:   r0 contains the address
> >>   *   r1 contains the address limit, which must be preserved
> >>   * Outputs:  r0 is the error code
> >> - *   r2 contains the zero-extended value
> >> + *   r2, r3 contains the zero-extended value
> >>   *   lr corrupted
> >>   *
> >>   * No other registers must be altered.  (see 
> >> @@ -66,6 +66,19 @@ ENTRY(__get_user_4)
> >>   mov pc, lr
> >>  ENDPROC(__get_user_4)
> >>
> >> +ENTRY(__get_user_8)
> >> + check_uaccess r0, 4, r1, r2, __get_user_bad
> >
> > Shouldn't you be passing 8 here, so that we validate the correct range?
> 
> yes, sorry, I'll fix that
> 
> >> +#ifdef CONFIG_THUMB2_KERNEL
> >> +5: TUSER(ldr)r2, [r0]
> >> +6: TUSER(ldr)r3, [r0, #4]
> >> +#else
> >> +5: TUSER(ldr)r2, [r0], #4
> >> +6: TUSER(ldr)r3, [r0]
> >> +#endif
> >
> > This doesn't work for EABI big-endian systems.
> 
> Hmm, is that true?  Wouldn't put_user() then have the same problem?

I dug up the P

[PATCH] drm: fix drm_framebuffer cleanup.

2012-11-12 Thread Inki Dae
 drm
> > > > > > > framework missed so specific drivers is processing this
> instead.
> > > And
> > > > with
> > > > > > > this patch, couldn't some codes you mentioned be removed from
> > > specific
> > > > > > > drivers? because it doesn't need to track the pending page
> flips
> > > and
> > > > > > > relevant things anymore.
> > > > > > >
> > > > > > > There may be my missing point. I'd welcome to any comments and
> > > > advices.
> > > > > >
> > > > > > If you don't track the page flips somehow, you can't safely free
> the
> > > > > > previous buffer. It's that simple. You can of course make some of
> > > > > > that code generic enough to be shared between drivers. That is
> > > > > > actually what the drm_flip mechanism that I wrote for atomic page
> > > > > > flips is; a reasonably generic helper for tracking page flips.
> > > > > >
> > > > > >
> > > > > Thanks for comments. Right, now Exynos driver doesn't consider
> tracking
> > > > > page flips yet. This is my TODO. Anyway couldn't we improve this
> patch
> > > so
> > > > > that drm framework considers such thing?
> > > >
> > > > > No, because it depends on hardware specific information. The drm
> core
> > > > > code doesn't have a crystall ball, so it can't just magically know
> when
> > > > > a page flip completes.
> > > > >
> > > > > > I think with this patch, we could avoid invald memory access
> issue
> > > > > without
> > > > > > tracking page flips. In this case, pended page flips would be
> just
> > > > > ignored.
> > > > >
> > > > > I still don't understand how the patch is supposed to help. If you
> make
> > > > > the proposed change to rmfb() so that it doesn't disable the crtc
> when
> > > > > you remove a non-current fb, then this would happen:
> > > > >
> > > > > setcrtc(crtc0, fb0)
> > > > >  -> crtc0.fb = fb0, fb0.crtc = crtc0
> > > > > pageflip(crtc0, fb1);
> > > > >  -> crtc0.fb = fb1, fb1.crtc = crtc0
> > > > > rmfb(fb0);
> > > > >  -> fb0.crtc = NULL;
> > > > > destroy(fb0);
> > > > >
> > > > > That is exactly the same behaviour we have today, so you still get
> > > > > the invalid memory access to fb0 if the page flip hasn't occured
> yet.
> > > > > And that means the fb.crtc pointer is entirely pointless.
> > > > >
> > > > >
> > > > I don't think so. let's see it again. below is my idea AND the
> reason I
> > > > posted this patch.
> > > > Original codes,
> > > > gem alloc(gem0);
> > > > -> gem0 refcount = 1
> > > > gem0 mmap
> > > > -> gem0 refcount = 2
> > > > gem alloc(gem1);
> > > > -> gem1 refcount =1
> > > > gem1 mmap
> > > > -> gem1 refcount =2
> > > > addfb(fb0, gem0);
> > > > -> gem0 refcount=3
> > > > addfb(fb1,gem1);
> > > > -> gem1 refcount = 3
> > > > setcrtc(fb0, crtc0)
> > > > -> crtc0.fb = fb0
> > > > pageflip(crtc0, fb1);
> > > > -> crtc0.fb = fb1.
> > > > and pageflip is repeated
> > > >
> > > > close(gem0)
> > > > -> gem0 refcount = 2
> > > > close(gem1)
> > > > ->gem1 refcount = 2
> > > > munmap(gem0)
> > > > ->gem0 refcount = 1
> > > > munmap(gem1)
> > > > ->gem1 refcount = 1
> > > >
> > > > close(drm)
> > > > 1. fb release
> > > > -> check if crtc->fb is same as fb0 but current crtc is pointing to
> fb1
> > > > 2. so free fb0 without disabling current crtc.
> > > > -> gem0 refcount = 0 so released. At this time, dma access invalid
> memory
> > > > region unfortunately* *if the dma is accessing gem0.
> > > >
> > > >
> > > >
> > > > With my patch,
> > > > ...
> > > > setcrtc(fb0, crtc0)
> > > > -> crtc0.fb = fb0, fb0.crtc = crtc0
> > > > pageflip(crtc0, fb1);
> > > > -> crtc0.fb = fb1, fb1.crtc = crtc0.
> > > > and pageflip is repeated
> > > >
> > > > close(gem0)
> > > > -> gem0 refcount = 2
> > > > close(gem1)
> > > > ->gem1 refcount = 2
> > > > munmap(gem0)
> > > > ->gem0 refcount = 1
> > > > munmap(gem1)
> > > > ->gem1 refcount = 1
> > > > close(drm)
> > > > 1. fb release
> > > > -> fb0->crtc is same as crtc so disable crtc (dma stop)
> > >
> > > No, that's wrong. The current fb is fb1, so destroying fb0 must not
> > > disable the crtc.
> > >
> > >
> > Do you think this is wrong that when fb0 is destroyed, the crtc also is
> > disabled and crtc is pointing to fb1?
>
> Yes. You must disable the crtc if and only if you destroy the current
> fb. Current fb means the fb specified by the latest setcrtc or pageflip
> ioctl. Destroying any other fb must not affect the crtc. And this is
> exactly what the current code does.
>
>
Right, I realized that there was my missing point though your comment. I
thought that current fb would be set to crtc->fb only if setmode request.
But page flip request also did it(by specific driver's page flip
function). Now Exynos driver has one problem. that is to set current fb to
crtc->fb after drm_vblank_get call . This could induce invalid memory
access like below,

crtc0's current fb is fb0

page flip request(crtc0, fb1)
1. drm_vblank_get call
2. vsync occurs and the dma access memory region to fb0 yet.
3. crtc0->fb = fb1
3. drm is released
4. crtc's current fb is fb1 but the dma is accessing memory region to fb0
yet because vsync doesn't occur so fb0 doesn't disable crtc and releses its
own gem buffer. This would induce the problem and definitely is a bug.

For this, I will fix it as soon as possible after testing.



> > And in case of Exynos driver,
> > disabling the crtc would disable hardware overlay so other overlays would
> > be holded on as is. This is just Exynos case so I don't know how other
> SoCs
> > are operated. Could you explain how Desktop side is operated? Maybe there
> > is my missing point here.
>
> I'm not sure what you're asking.
>
>

> Are you asking how other drivers know know when it's safe to free the
> memory? Well, the usual method is to track the page flips via some
> suitable interrupts. A reference is kept to the memory until it's safe
> to get rid of it.
>
> Or are you asking what should happen when a crtc is disabled? Then my
> answer is that when a crtc is disabled, there must be no output signal
> whatsoever.
>
> It's an unfortunate design bug that we even have the fb->crtc link.
> Ideally it would not exist, and all scanout duties would be handled
> by planes. Then destroying fbs would never disable the crtc completely,
> just the planes scanning from those fbs.
>
>
Understood. And I'd like to say thank you again. Your comment is very
helpful to me.

Thanks,
Inki Dae


> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121112/97b898d4/attachment-0001.html>


[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)

2012-11-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #28 from Alexandre Demers  ---
Alex, a simple question: you said bit 0 in EVERGREEN_CRTC_CONTROL stops the
CRTC sync. With the culprit commit, when is it set? I mean, I had a quick look
in the driver's code and I couldn't find it. When going in suspend state,
shouldn't it be set to 0? Then, on resume, shouldn't it be set to 1? I may just
have missed it, but could this be something missing? Same questions goes for
GPU soft reset.

Before the culprit commit, we were setting bit 0 to 0 on stop and setting it
back to 1 on resume, which was working great. Why aren't we doing it anymore
when suspending and resuming?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121112/28b0f9a9/attachment.html>


[PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Russell King - ARM Linux
On Mon, Nov 12, 2012 at 01:58:32PM -0600, Rob Clark wrote:
> On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
>  wrote:
> > On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
> >> From: Rob Clark 
> >>
> >> A new atomic modeset/pageflip ioctl being developed in DRM requires
> >> get_user() to work for 64bit types (in addition to just put_user()).
> >
> > NAK.
> >
> > (I did write a better email explaining all the ins and outs of why this
> > won't work and why 64-bit get_user isn't possible, but my editor crapped
> > out and lost all that well written message; I don't fancy typing it all
> > out again.)
> >
> > Nevertheless,
> > int test_ptr(unsigned int **v, unsigned int **p)
> > {
> > return get_user(*v, p);
> > }
> >
> > produces a warning, and you can't get away from that if you stick 64-bit
> > support into get_user().
> 
> Actually, it seems like using 'register typeof(x) __r2 asm("r2");'
> does avoid that warning..

That seems to pass the checks I've done on it so far, and seems rather
obvious (there's been a number of people looking at this, none of whom
have come up with that solution).  Provided the final cast is kept
(which is there to ensure proper typechecking), it seems like it might
be a solution.


[PATCH v8 2/6] video: add of helper for videomode

2012-11-12 Thread Alexey Klimov
Hello Steffen,

On Mon, Nov 12, 2012 at 7:37 PM, Steffen Trumtrar
 wrote:
> This adds support for reading display timings from DT or/and convert one of 
> those
> timings to a videomode.
> The of_display_timing implementation supports multiple children where each
> property can have up to 3 values. All children are read into an array, that
> can be queried.
> of_get_videomode converts exactly one of that timings to a struct videomode.
>
> Signed-off-by: Steffen Trumtrar 
> Signed-off-by: Philipp Zabel 
> ---
>  .../devicetree/bindings/video/display-timings.txt  |  107 +++
>  drivers/video/Kconfig  |   13 ++
>  drivers/video/Makefile |2 +
>  drivers/video/of_display_timing.c  |  186 
> 
>  drivers/video/of_videomode.c   |   47 +
>  include/linux/of_display_timings.h |   19 ++
>  include/linux/of_videomode.h   |   15 ++
>  7 files changed, 389 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/video/display-timings.txt
>  create mode 100644 drivers/video/of_display_timing.c
>  create mode 100644 drivers/video/of_videomode.c
>  create mode 100644 include/linux/of_display_timings.h
>  create mode 100644 include/linux/of_videomode.h
>
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
> index 000..e22e2fd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> @@ -0,0 +1,107 @@
> +display-timings bindings
> +
> +
> +display-timings-node
> +
> +
> +required properties:
> + - none
> +
> +optional properties:
> + - native-mode: the native mode for the display, in case multiple modes are
> +   provided. When omitted, assume the first node is the native.
> +
> +timings-subnode
> +---
> +
> +required properties:
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> +   in pixels
> +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
> in
> +   lines
> + - clock-frequency: displayclock in Hz
> +
> +optional properties:
> + - hsync-active : Hsync pulse is active low/high/ignored
> + - vsync-active : Vsync pulse is active low/high/ignored
> + - de-active : Data-Enable pulse is active low/high/ignored
> + - pixelclk-inverted : pixelclock is inverted/non-inverted/ignored
> + - interlaced (bool)
> + - doublescan (bool)
> +
> +All the optional properties that are not bool follow the following logic:
> +<1> : high active
> +<0> : low active
> +omitted : not used on hardware
> +
> +There are different ways of describing the capabilities of a display. The 
> devicetree
> +representation corresponds to the one commonly found in datasheets for 
> displays.
> +If a display supports multiple signal timings, the native-mode can be 
> specified.
> +
> +The parameters are defined as
> +
> +struct display_timing
> +=
> +
> +  
> +--+-+--+---+
> +  |  |?|  |  
>  |
> +  |  ||vback_porch |  |  
>  |
> +  |  |?|  |  
>  |
> +  
> +--###--+---+
> +  |  #?#  |  
>  |
> +  |  #|#  |  
>  |
> +  |  hback   #|#  hfront  | 
> hsync |
> +  |   porch  #|   hactive  #  porch   |  len 
>  |
> +  
> |<>#<---+--->#<>|<->|
> +  |  #|#  |  
>  |
> +  |  #|vactive #  |  
>  |
> +  |  #|#  |  
>  |
> +  |  #?#  |  
>  |
> +  
> +--###--+---+
> +  |  |?|  |  
>  |
> +  |  ||vfront_porch|  |  
>  |
> +  |  |?|  |  
>  |
> +  
> +--+-+--+---+
> +  |  |?|  |  
>  |
> +  |  ||vsync_len   |  |  
>  |
> +  |  |   

[PATCH v2 2/2] drm: tegra: Add HDMI support

2012-11-12 Thread Thierry Reding
This commit adds support for the HDMI output on the Tegra20 SoC. Only
one such output is available, but it can be driven by either of the two
display controllers.

A lot of work on this patch has been contributed by NVIDIA's Mark Zhang
 and many other people at NVIDIA were very helpful in
getting the HDMI support and surrounding infrastructure to work.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- reuse debugfs infrastructure provided by the DRM core

 drivers/gpu/drm/tegra/Makefile |2 +-
 drivers/gpu/drm/tegra/drm.h|2 +
 drivers/gpu/drm/tegra/hdmi.c   | 1324 
 drivers/gpu/drm/tegra/hdmi.h   |  575 +
 drivers/gpu/drm/tegra/host1x.c |8 +
 5 files changed, 1910 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/tegra/hdmi.c
 create mode 100644 drivers/gpu/drm/tegra/hdmi.h

diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 624a807..80f73d1 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -2,6 +2,6 @@ ccflags-y := -Iinclude/drm
 ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG

 tegra-drm-y := drm.o fb.o dc.o host1x.o
-tegra-drm-y += output.o rgb.o
+tegra-drm-y += output.o rgb.o hdmi.o

 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index a1a891e..c2c4d16 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -131,6 +131,7 @@ struct tegra_output_ops {

 enum tegra_output_type {
TEGRA_OUTPUT_RGB,
+   TEGRA_OUTPUT_HDMI,
 };

 struct tegra_output {
@@ -225,6 +226,7 @@ extern int tegra_drm_fb_init(struct drm_device *drm);
 extern void tegra_drm_fb_exit(struct drm_device *drm);

 extern struct platform_driver tegra_host1x_driver;
+extern struct platform_driver tegra_hdmi_driver;
 extern struct platform_driver tegra_dc_driver;
 extern struct drm_driver tegra_drm_driver;

diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
new file mode 100644
index 000..61a1d14
--- /dev/null
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -0,0 +1,1324 @@
+/*
+ * Copyright (C) 2012 Avionic Design GmbH
+ * Copyright (C) 2012 NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "hdmi.h"
+#include "drm.h"
+#include "dc.h"
+
+struct tegra_hdmi {
+   struct host1x_client client;
+   struct tegra_output output;
+   struct device *dev;
+
+   struct regulator *vdd;
+   struct regulator *pll;
+
+   void __iomem *regs;
+   unsigned int irq;
+
+   struct clk *clk_parent;
+   struct clk *clk;
+
+   unsigned int audio_source;
+   unsigned int audio_freq;
+   bool stereo;
+   bool dvi;
+
+   struct drm_info_list *debugfs_files;
+   struct drm_minor *minor;
+   struct dentry *debugfs;
+};
+
+static inline struct tegra_hdmi *
+host1x_client_to_hdmi(struct host1x_client *client)
+{
+   return container_of(client, struct tegra_hdmi, client);
+}
+
+static inline struct tegra_hdmi *to_hdmi(struct tegra_output *output)
+{
+   return container_of(output, struct tegra_hdmi, output);
+}
+
+#define HDMI_AUDIOCLK_FREQ 21600
+#define HDMI_REKEY_DEFAULT 56
+
+enum {
+   AUTO = 0,
+   SPDIF,
+   HDA,
+};
+
+static inline unsigned long tegra_hdmi_readl(struct tegra_hdmi *hdmi,
+unsigned long reg)
+{
+   return readl(hdmi->regs + (reg << 2));
+}
+
+static inline void tegra_hdmi_writel(struct tegra_hdmi *hdmi, unsigned long 
val,
+unsigned long reg)
+{
+   writel(val, hdmi->regs + (reg << 2));
+}
+
+struct tegra_hdmi_audio_config {
+   unsigned int pclk;
+   unsigned int n;
+   unsigned int cts;
+   unsigned int aval;
+};
+
+static const struct tegra_hdmi_audio_config tegra_hdmi_audio_32k[] = {
+   {  2520, 4096,  25200, 24000 },
+   {  2700, 4096,  27000, 24000 },
+   {  7425, 4096,  74250, 24000 },
+   { 14850, 4096, 148500, 24000 },
+   { 0,0,  0, 0 },
+};
+
+static const struct tegra_hdmi_audio_config tegra_hdmi_audio_44_1k[] = {
+   {  2520, 5880,  26250, 25000 },
+   {  2700, 5880,  28125, 25000 },
+   {  7425, 4704,  61875, 2 },
+   { 14850, 4704, 123750, 2 },
+   { 0,0,  0, 0 },
+};
+
+static const struct tegra_hdmi_audio_config tegra_hdmi_audio_48k[] = {
+   {  2520, 6144,  25200, 24000 },
+   {  2700, 6144,  27000, 24000 },
+   {  7425, 6144,  74250, 24000 },
+   { 14850, 6144, 148500, 24000 },
+   { 0,0,  0, 0 },
+};
+
+static const struct t

[PATCH v2 1/2] drm: Add NVIDIA Tegra20 support

2012-11-12 Thread Thierry Reding
This commit adds a KMS driver for the Tegra20 SoC. This includes basic
support for host1x and the two display controllers found on the Tegra20
SoC. Each display controller can drive a separate RGB/LVDS output.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- drop Linux-specific drm subdirectory for DT bindings documentation
- remove display helper leftovers that belong in a later patch
- reuse debugfs infrastructure provided by the DRM core
- move vblank syncpoint defines to dc.h
- use drm_compat_ioctl()

 .../bindings/gpu/nvidia,tegra20-host1x.txt | 191 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/tegra/Kconfig  |  23 +
 drivers/gpu/drm/tegra/Makefile |   7 +
 drivers/gpu/drm/tegra/dc.c | 846 +
 drivers/gpu/drm/tegra/dc.h | 388 ++
 drivers/gpu/drm/tegra/drm.c| 115 +++
 drivers/gpu/drm/tegra/drm.h| 231 ++
 drivers/gpu/drm/tegra/fb.c |  56 ++
 drivers/gpu/drm/tegra/host1x.c | 313 
 drivers/gpu/drm/tegra/output.c | 262 +++
 drivers/gpu/drm/tegra/rgb.c| 200 +
 13 files changed, 2635 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
 create mode 100644 drivers/gpu/drm/tegra/Kconfig
 create mode 100644 drivers/gpu/drm/tegra/Makefile
 create mode 100644 drivers/gpu/drm/tegra/dc.c
 create mode 100644 drivers/gpu/drm/tegra/dc.h
 create mode 100644 drivers/gpu/drm/tegra/drm.c
 create mode 100644 drivers/gpu/drm/tegra/drm.h
 create mode 100644 drivers/gpu/drm/tegra/fb.c
 create mode 100644 drivers/gpu/drm/tegra/host1x.c
 create mode 100644 drivers/gpu/drm/tegra/output.c
 create mode 100644 drivers/gpu/drm/tegra/rgb.c

diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt 
b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
new file mode 100644
index 000..b4fa934
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
@@ -0,0 +1,191 @@
+NVIDIA Tegra host1x
+
+Required properties:
+- compatible: "nvidia,tegra-host1x"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The interrupt outputs from the controller.
+- #address-cells: The number of cells used to represent physical base addresses
+  in the host1x address space. Should be 1.
+- #size-cells: The number of cells used to represent the size of an address
+  range in the host1x address space. Should be 1.
+- ranges: The mapping of the host1x address space to the CPU address space.
+
+The host1x top-level node defines a number of children, each representing one
+of the following host1x client modules:
+
+- mpe: video encoder
+
+  Required properties:
+  - compatible: "nvidia,tegra-mpe"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- vi: video input
+
+  Required properties:
+  - compatible: "nvidia,tegra-vi"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- epp: encoder pre-processor
+
+  Required properties:
+  - compatible: "nvidia,tegra-epp"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- isp: image signal processor
+
+  Required properties:
+  - compatible: "nvidia,tegra-isp"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- gr2d: 2D graphics engine
+
+  Required properties:
+  - compatible: "nvidia,tegra-gr2d"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- gr3d: 3D graphics engine
+
+  Required properties:
+  - compatible: "nvidia,tegra-gr3d"
+  - reg: Physical base address and length of the controller's registers.
+
+- dc: display controller
+
+  Required properties:
+  - compatible: "nvidia,tegra-dc"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+  Each display controller node has a child node, named "rgb", that represents
+  the RGB output associated with the controller. It can take the following
+  optional properties:
+  - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+  - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+  - nvidia,edid: supplies a binary EDID blob
+
+- hdmi: High Definition Multimedia Interface
+
+  Required properties:
+  - compatible: "nvidia,tegra-hdmi"
+  - reg: Physical base address and length of the controller's registers.
+  - interr

[PATCH v2 0/2] NVIDIA Tegra DRM driver

2012-11-12 Thread Thierry Reding
This second version of this patch series addresses all the comments
received so far. Most notably it takes advantage of the debugfs helpers
provided by the DRM core. Oddly enough this actually increases the line
count, but that's because the helpers don't fit with the subdevices
approach as implemented by this driver. However some quick discussions
with Rob Clark showed that Tegra DRM is not special in this respect but
other drivers may need the same functionality. Eventually the debugfs
code could be reworked on top of helpers that are better suited at the
design of embedded, multi-device DRM drivers.

Other than that there is some removal of code that was actually supposed
to go into a later patch because it has dependencies that haven't been
merged yet and some moving around of #defines and the device tree
bindings documentation. Finally the driver now uses the DRM core's
drm_compat_ioctl() instead of a custom and unimplemented (!) version.

Thierry

Thierry Reding (2):
  drm: Add NVIDIA Tegra20 support
  drm: tegra: Add HDMI support

 .../bindings/gpu/nvidia,tegra20-host1x.txt |  191 +++
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/tegra/Kconfig  |   23 +
 drivers/gpu/drm/tegra/Makefile |7 +
 drivers/gpu/drm/tegra/dc.c |  846 +
 drivers/gpu/drm/tegra/dc.h |  388 ++
 drivers/gpu/drm/tegra/drm.c|  115 ++
 drivers/gpu/drm/tegra/drm.h|  233 
 drivers/gpu/drm/tegra/fb.c |   56 +
 drivers/gpu/drm/tegra/hdmi.c   | 1324 
 drivers/gpu/drm/tegra/hdmi.h   |  575 +
 drivers/gpu/drm/tegra/host1x.c |  321 +
 drivers/gpu/drm/tegra/output.c |  262 
 drivers/gpu/drm/tegra/rgb.c|  200 +++
 15 files changed, 4544 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
 create mode 100644 drivers/gpu/drm/tegra/Kconfig
 create mode 100644 drivers/gpu/drm/tegra/Makefile
 create mode 100644 drivers/gpu/drm/tegra/dc.c
 create mode 100644 drivers/gpu/drm/tegra/dc.h
 create mode 100644 drivers/gpu/drm/tegra/drm.c
 create mode 100644 drivers/gpu/drm/tegra/drm.h
 create mode 100644 drivers/gpu/drm/tegra/fb.c
 create mode 100644 drivers/gpu/drm/tegra/hdmi.c
 create mode 100644 drivers/gpu/drm/tegra/hdmi.h
 create mode 100644 drivers/gpu/drm/tegra/host1x.c
 create mode 100644 drivers/gpu/drm/tegra/output.c
 create mode 100644 drivers/gpu/drm/tegra/rgb.c

-- 
1.8.0



Fix for vblank on nvc0

2012-11-12 Thread Maarten Lankhorst
Op 12-11-12 22:30, Kelly Doran schreef:
> I had Sven test this patch... he said it works.  I think chipset
> number test was executing code that we thought was only either 0x50 or
> 0xc0, but was actually more specific with things like 0x92.
>
Oh right vblank is busted anyway... needs to be nv_device(priv-)>card_type == 
NV_50 to work.

Your patch is the correct fix.

~Maarten


WARNING: at drivers/gpu/drm/i915/intel_display.c:1009 ironlake_crtc_disable+0xaf/0x8e0

2012-11-12 Thread Meelis Roos
I tried 3.7-rc5 on an ironlale PC and got the warning in subject. The 
computer last ran 3.6.0 without any warnings. Second reboot showed the 
same warning plus a couple of EDID warnings (also below).


[0.00] Linux version 3.7.0-rc5 (mroos at prometheus) (gcc version 4.7.2 
(Debian 4.7.2-4) ) #70 SMP Mon Nov 12 18:20:25 EET 2012
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc5 root=/dev/sda1 
ro
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xdb7ac43f] usable
[0.00] BIOS-e820: [mem 0xdb7ac440-0xdb7ae49f] ACPI NVS
[0.00] BIOS-e820: [mem 0xdb7ae4a0-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xf400-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfed3] reserved
[0.00] BIOS-e820: [mem 0xfed45000-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x000117ff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 
786H1 v01.13 07/14/2011
[0.00] e820: update [mem 0x-0x] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x118000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-E3FFF write-protect
[0.00]   E4000-E write-back
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask E write-back
[0.00]   1 base 0DB80 mask FFF80 uncachable
[0.00]   2 base 0DC00 mask FFC00 uncachable
[0.00]   3 base 0E000 mask FE000 uncachable
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] e820: update [mem 0xdb80-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xdb7ac max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000f9bf0-0x000f9bff] mapped at 
[880f9bf0]
[0.00] initial memory mapped: [mem 0x-0x1fff]
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] init_memory_mapping: [mem 0x-0xdb7abfff]
[0.00]  [mem 0x-0xdb5f] page 2M
[0.00]  [mem 0xdb60-0xdb7abfff] page 4k
[0.00] kernel direct mapping tables up to 0xdb7abfff @ [mem 
0x1fffa000-0x1fff]
[0.00] init_memory_mapping: [mem 0x1-0x117ff]
[0.00]  [mem 0x1-0x117ff] page 2M
[0.00] kernel direct mapping tables up to 0x117ff @ [mem 
0xdb7aa000-0xdb7abfff]
[0.00] ACPI: RSDP 000e5210 00014 (v00 COMPAQ)
[0.00] ACPI: RSDT db7d0540 00040 (v01 HPQOEM SLIC-BPC 20110714  
)
[0.00] ACPI: FACP db7d05e8 00074 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has 
zero address or length: 0x0050/0x0 (20120913/tbfadt-598)
[0.00] ACPI BIOS Bug: Warning: Invalid length for FADT/Pm2ControlBlock: 
0, using default 8 (20120913/tbfadt-648)
[0.00] ACPI: DSDT db7d0a4f 0A69E (v01 COMPAQ DSDT_PRJ 0001 
MSFT 010E)
[0.00] ACPI: FACS db7d0500 00040
[0.00] ACPI: APIC db7d065c 000BC (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: ASF! db7d0718 00063 (v32 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: MCFG db7d077b 0003C (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: TCPA db7d07b7 00032 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: SLIC db7d07e9 00176 (v01 HPQOEM SLIC-BPC 0001  
)
[0.00] ACPI: HPET db7d095f 00038 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: Local APIC address 0xfee0
[0.00]  [ea00-ea00045f] PMD -> 
[88011380-8801175f] on node 0
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x0001-0x00ff]
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x1-0x117ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.

[Bug 56878] FireGL Mobility T2: WebGL under firefox16 freezes system

2012-11-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56878

--- Comment #9 from Alex Deucher  ---
(In reply to comment #8)
> The computer used to work quite nicely for a lot of OpenGL programs back
> then when I could still use fglrx, so I find it hard to believe that buggy
> hardware is at fault here.

There are probably ways to make your system work better, but due to the nature
of AGP and the fact that the hw is so old, I'm just saying it's not likely
anyone is going to put much time into it at this point.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121112/41143a98/attachment.html>


[PATCH v8 2/6] video: add of helper for videomode

2012-11-12 Thread Sascha Hauer
Hi Steffen,

You lose memory in several places:

On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote:
> +static struct display_timing *of_get_display_timing(struct device_node *np)
> +{
> + struct display_timing *dt;
> + int ret = 0;
> +
> + dt = kzalloc(sizeof(*dt), GFP_KERNEL);
> + if (!dt) {
> + pr_err("%s: could not allocate display_timing struct\n", 
> __func__);
> + return NULL;
> + }
> +
> + ret |= parse_property(np, "hback-porch", &dt->hback_porch);
> + ret |= parse_property(np, "hfront-porch", &dt->hfront_porch);
> + ret |= parse_property(np, "hactive", &dt->hactive);
> + ret |= parse_property(np, "hsync-len", &dt->hsync_len);
> + ret |= parse_property(np, "vback-porch", &dt->vback_porch);
> + ret |= parse_property(np, "vfront-porch", &dt->vfront_porch);
> + ret |= parse_property(np, "vactive", &dt->vactive);
> + ret |= parse_property(np, "vsync-len", &dt->vsync_len);
> + ret |= parse_property(np, "clock-frequency", &dt->pixelclock);
> +
> + of_property_read_u32(np, "vsync-active", &dt->vsync_pol_active);
> + of_property_read_u32(np, "hsync-active", &dt->hsync_pol_active);
> + of_property_read_u32(np, "de-active", &dt->de_pol_active);
> + of_property_read_u32(np, "pixelclk-inverted", &dt->pixelclk_pol);
> + dt->interlaced = of_property_read_bool(np, "interlaced");
> + dt->doublescan = of_property_read_bool(np, "doublescan");
> +
> + if (ret) {
> + pr_err("%s: error reading timing properties\n", __func__);
> + return NULL;

Here

> + }
> +
> + return dt;
> +}
> +
> +/**
> + * of_get_display_timings - parse all display_timing entries from a 
> device_node
> + * @np: device_node with the subnodes
> + **/
> +struct display_timings *of_get_display_timings(struct device_node *np)
> +{
> + struct device_node *timings_np;
> + struct device_node *entry;
> + struct device_node *native_mode;
> + struct display_timings *disp;
> +
> + if (!np) {
> + pr_err("%s: no devicenode given\n", __func__);
> + return NULL;
> + }
> +
> + timings_np = of_find_node_by_name(np, "display-timings");
> + if (!timings_np) {
> + pr_err("%s: could not find display-timings node\n", __func__);
> + return NULL;
> + }
> +
> + disp = kzalloc(sizeof(*disp), GFP_KERNEL);
> + if (!disp)
> + return -ENOMEM;
> +
> + entry = of_parse_phandle(timings_np, "native-mode", 0);
> + /* assume first child as native mode if none provided */
> + if (!entry)
> + entry = of_get_next_child(np, NULL);
> + if (!entry) {
> + pr_err("%s: no timing specifications given\n", __func__);
> + return NULL;

Here

> + }
> +
> + pr_info("%s: using %s as default timing\n", __func__, entry->name);
> +
> + native_mode = entry;
> +
> + disp->num_timings = of_get_child_count(timings_np);
> + disp->timings = kzalloc(sizeof(struct display_timing 
> *)*disp->num_timings,
> + GFP_KERNEL);
> + if (!disp->timings)
> + return -ENOMEM;

Here

> +
> + disp->num_timings = 0;
> + disp->native_mode = 0;
> +
> + for_each_child_of_node(timings_np, entry) {
> + struct display_timing *dt;
> +
> + dt = of_get_display_timing(entry);
> + if (!dt) {
> + /* to not encourage wrong devicetrees, fail in case of 
> an error */
> + pr_err("%s: error in timing %d\n", __func__, 
> disp->num_timings+1);
> + return NULL;

Here

> + }
> +
> + if (native_mode == entry)
> + disp->native_mode = disp->num_timings;
> +
> + disp->timings[disp->num_timings] = dt;
> + disp->num_timings++;
> + }
> + of_node_put(timings_np);
> +
> + if (disp->num_timings > 0)
> + pr_info("%s: got %d timings. Using timing #%d as default\n", 
> __func__,
> + disp->num_timings , disp->native_mode + 1);
> + else {
> + pr_err("%s: no valid timings specified\n", __func__);
> + return NULL;

and here

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

2012-11-12 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=49981





--- Comment #3 from nudelsuppe1982 at gmx.de  2012-11-12 19:43:50 ---
Created an attachment (id=86191)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=86191)
3.7rc5 dmesg

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.


[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

2012-11-12 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=49981


nudelsuppe1982 at gmx.de changed:

   What|Removed |Added

 CC||nudelsuppe1982 at gmx.de




--- Comment #2 from nudelsuppe1982 at gmx.de  2012-11-12 19:42:26 ---
I can confirm the error up to 3.7 rc5 on my AMD E-350 Board (Asus E35M1-I
DELUXE).  Also the radeon HDMI output and audio is broken. 

$ dmesg | grep drm
[3.600771] [drm] Initialized drm 1.1.0 20060810
[3.626262] [drm] radeon defaulting to kernel modesetting.
[3.626278] [drm] radeon kernel modesetting enabled.
[3.626340] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing
generic driver
[3.629912] [drm] initializing kernel modesetting (PALM 0x1002:0x9802
0x1043:0x84A5).
[3.630029] [drm] register mmio base: 0xFEB0
[3.630032] [drm] register mmio size: 262144
[3.631497] [drm] Detected VRAM RAM=512M, BAR=256M
[3.631506] [drm] RAM width 32bits DDR
[3.632779] [drm] radeon: 512M of VRAM memory ready
[3.632783] [drm] radeon: 512M of GTT memory ready.
[3.632815] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[3.632817] [drm] Driver supports precise vblank timestamp query.
[3.632938] [drm] radeon: irq initialized.
[3.632948] [drm] GART: num cpu pages 131072, num gpu pages 131072
[3.636126] [drm] Loading PALM Microcode
[3.677830] [drm] PCIE GART of 512M enabled (table at 0x0004).
[3.695673] [drm] ring test on 0 succeeded in 1 usecs
[3.696601] [drm] Enabling audio support
[3.696650] [drm] ib test on ring 0 succeeded in 0 usecs
[3.697914] [drm] Radeon Display Connectors
[3.697921] [drm] Connector 0:
[3.697924] [drm]   HDMI-A-1
[3.697926] [drm]   HPD1
[3.697930] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c
0x643c
[3.697933] [drm]   Encoders:
[3.697935] [drm] DFP1: INTERNAL_UNIPHY
[3.697937] [drm] Connector 1:
[3.697939] [drm]   DVI-D-1
[3.697941] [drm]   HPD2
[3.697944] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c
0x644c
[3.697946] [drm]   Encoders:
[3.697948] [drm] DFP2: INTERNAL_UNIPHY
[3.697950] [drm] Connector 2:
[3.697994] [drm]   VGA-1
[3.697998] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c
0x644c
[3.698000] [drm]   Encoders:
[3.698002] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[3.698114] [drm] Internal thermal controller without fan control
[3.698186] [drm] radeon: power management initialized
[3.843505] [drm] fb mappable at 0xC0142000
[3.843512] [drm] vram apper at 0xC000
[3.843514] [drm] size 8294400
[3.843516] [drm] fb depth is 24
[3.843518] [drm]pitch is 7680
[3.843875] fbcon: radeondrmfb (fb0) is primary device
[3.930599] fb0: radeondrmfb frame buffer device
[3.930604] drm: registered panic notifier
[3.930645] [drm] Initialized radeon 2.24.0 20080528 for :00:01.0 on
minor 0
[   28.434143] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

$ dmesg | grep HDMI
[3.697924] [drm]   HDMI-A-1
[7.623087] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[7.623106] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[7.623243] input: HD-Audio Generic HDMI/DP,pcm=3 as
/devices/pci:00/:00:01.1/sound/card0/input5
[   43.190709] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[   43.190729] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[   43.192872] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[   43.192892] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[   43.491778] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[   43.491797] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[   43.792731] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[   43.792751] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[   44.095763] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[   44.095782] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[   44.396786] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[   44.396806] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[   44.697950] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[   44.697971] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[   44.998701] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[   44.998722] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[   45.299729] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size is 0, force
128
[   45.299750] ALSA sound/pci/hda/hda_eld.c:356 HDMI: invalid ELD data byte 0
[   45.600669] ALSA sound/pci/hda/hda_eld.c:337 HDMI: ELD buf size 

[Bug 56878] FireGL Mobility T2: WebGL under firefox16 freezes system

2012-11-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56878

--- Comment #8 from miri at turboprinzessin.de ---
The computer used to work quite nicely for a lot of OpenGL programs back then
when I could still use fglrx, so I find it hard to believe that buggy hardware
is at fault here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121112/f0d31d8b/attachment.html>


[PATCH 22/22] drm/i915: Add debug print for flip queue length

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Print some information on how many flips are in the queue waiting for
the GPU. There's no limit on the queue length currently.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/i915_drv.h |1 +
 drivers/gpu/drm/i915/intel_atomic.c |4 
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 87f5cba..5c089b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -892,6 +892,7 @@ typedef struct drm_i915_private {
struct work_struct work;
struct workqueue_struct *wq;
unsigned int next_flip_seq;
+   unsigned int queue_len;
} flip;
 } drm_i915_private_t;

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index d3aa566..d7cc978 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -2106,6 +2106,7 @@ static void intel_atomic_postpone_flip(struct drm_device 
*dev,
intel_flip->busy = ring != NULL;

list_move_tail(&intel_flip->base.list, &dev_priv->flip.list);
+   dev_priv->flip.queue_len++;

if (!ring)
return;
@@ -2186,6 +2187,7 @@ static void intel_atomic_process_flips_work(struct 
work_struct *work)
if (intel_flip->flip_seq != flip_seq)
break;
list_move_tail(&intel_flip->base.list, &flips);
+   dev_priv->flip.queue_len--;
}
}

@@ -2197,6 +2199,8 @@ static void intel_atomic_process_flips_work(struct 
work_struct *work)
mutex_lock(&dev->mode_config.mutex);
intel_atomic_schedule_flips(dev_priv, intel_crtc, &flips);
mutex_unlock(&dev->mode_config.mutex);
+
+   DRM_DEBUG_KMS("flip queue length = %u\n", 
dev_priv->flip.queue_len);
}
 }

-- 
1.7.8.6



[PATCH 21/22] HACK: drm/i915: Make non-blocking GPU synchronization optional

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Add a module parameter that allows one to easily change between blocking
and non-blocking GPU synchronization with atomic page flips.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_stub.c  |5 +
 drivers/gpu/drm/i915/intel_atomic.c |   10 +-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index c236fd2..52d5750 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -46,16 +46,21 @@ EXPORT_SYMBOL(drm_vblank_offdelay);
 unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 EXPORT_SYMBOL(drm_timestamp_precision);

+unsigned int drm_async_gpu = 0;/* 1 to enable async gpu wait */
+EXPORT_SYMBOL(drm_async_gpu);
+
 MODULE_AUTHOR(CORE_AUTHOR);
 MODULE_DESCRIPTION(CORE_DESC);
 MODULE_LICENSE("GPL and additional rights");
 MODULE_PARM_DESC(debug, "Enable debug output");
 MODULE_PARM_DESC(vblankoffdelay, "Delay until vblank irq auto-disable 
[msecs]");
 MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on timestamps [usecs]");
+MODULE_PARM_DESC(async_gpu, "Async GPU wait");

 module_param_named(debug, drm_debug, int, 0600);
 module_param_named(vblankoffdelay, drm_vblank_offdelay, int, 0600);
 module_param_named(timestamp_precision_usec, drm_timestamp_precision, int, 
0600);
+module_param_named(async_gpu, drm_async_gpu, int, 0600);

 struct idr drm_minors_idr;

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index bfa6da6..d3aa566 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -801,11 +801,13 @@ static void unpin_fbs(struct drm_device *dev,
}
 }

+extern unsigned int drm_async_gpu;
+
 static int pin_fbs(struct drm_device *dev,
   struct intel_atomic_state *s)
 {
int i, ret;
-   bool nonblock = s->flags & DRM_MODE_ATOMIC_NONBLOCK;
+   bool nonblock = drm_async_gpu && (s->flags & DRM_MODE_ATOMIC_NONBLOCK);

for (i = 0; i < dev->mode_config.num_crtc; i++) {
struct intel_crtc_state *st = &s->crtc[i];
@@ -2359,6 +2361,12 @@ static void atomic_pipe_commit(struct drm_device *dev,
if (list_empty(&flips))
return;

+   if (!drm_async_gpu) {
+   struct intel_crtc *intel_crtc = 
to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
+   intel_atomic_schedule_flips(dev_priv, intel_crtc, &flips);
+   return;
+   }
+
spin_lock_irqsave(&dev_priv->flip.lock, flags);
list_for_each_entry_safe(intel_flip, next, &flips, base.list)
intel_atomic_postpone_flip(dev, intel_flip);
-- 
1.7.8.6



[PATCH 20/22] drm/i915: Implement a non-blocking GPU synchronization mechanism for atomic page flips

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

After the atomic flip has been split up into individual flip requests
for each scanout engine, put each such request into a FIFO. Then for
each flip request add new request to the ring(s) in order to get an
interrupt once the GPU has finished whatever it was doing with the
new front buffer. Once the flip requests associated with the same
atomic flip and the same pipe at the head of the queue are ready,
pull them from the queue and issue the flips to the hardware.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/i915_drv.h |8 ++
 drivers/gpu/drm/i915/i915_irq.c |2 +
 drivers/gpu/drm/i915/intel_atomic.c |  187 ---
 drivers/gpu/drm/i915/intel_drv.h|1 +
 4 files changed, 182 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4cf0e15..87f5cba 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -885,6 +885,14 @@ typedef struct drm_i915_private {
uint32_t hw_context_size;

struct drm_flip_driver flip_driver;
+
+   struct {
+   struct list_head list;
+   spinlock_t lock;
+   struct work_struct work;
+   struct workqueue_struct *wq;
+   unsigned int next_flip_seq;
+   } flip;
 } drm_i915_private_t;

 /* Iterate over initialised rings */
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ee22e97..cec1ea6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -343,6 +343,8 @@ static void notify_ring(struct drm_device *dev,
 {
struct drm_i915_private *dev_priv = dev->dev_private;

+   intel_atomic_notify_ring(dev, ring);
+
if (ring->obj == NULL)
return;

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index b795cb2..bfa6da6 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -42,6 +42,10 @@ struct intel_flip {
struct drm_pending_atomic_event *event;
uint32_t old_fb_id;
struct list_head pending_head;
+   struct intel_ring_buffer *ring;
+   u32 seqno;
+   bool busy;
+   unsigned int flip_seq;
 };

 struct intel_plane_state {
@@ -801,6 +805,7 @@ static int pin_fbs(struct drm_device *dev,
   struct intel_atomic_state *s)
 {
int i, ret;
+   bool nonblock = s->flags & DRM_MODE_ATOMIC_NONBLOCK;

for (i = 0; i < dev->mode_config.num_crtc; i++) {
struct intel_crtc_state *st = &s->crtc[i];
@@ -816,7 +821,7 @@ static int pin_fbs(struct drm_device *dev,
obj = to_intel_framebuffer(crtc->fb)->obj;

mutex_lock(&dev->struct_mutex);
-   ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
+   ret = intel_pin_and_fence_fb_obj(dev, obj, nonblock ? obj->ring 
: NULL);
mutex_unlock(&dev->struct_mutex);

if (ret)
@@ -839,7 +844,7 @@ static int pin_fbs(struct drm_device *dev,
obj = to_intel_framebuffer(plane->fb)->obj;

mutex_lock(&dev->struct_mutex);
-   ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
+   ret = intel_pin_and_fence_fb_obj(dev, obj, nonblock ? obj->ring 
: NULL);
mutex_unlock(&dev->struct_mutex);

if (ret)
@@ -2047,6 +2052,8 @@ static const struct drm_flip_driver_funcs 
intel_flip_driver_funcs = {
.flush = intel_flip_driver_flush,
 };

+static void intel_atomic_process_flips_work(struct work_struct *work);
+
 static void intel_flip_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -2065,6 +2072,11 @@ static void intel_flip_init(struct drm_device *dev)
list_for_each_entry(intel_plane, &dev->mode_config.plane_list, 
base.head)
drm_flip_helper_init(&intel_plane->flip_helper,
 &dev_priv->flip_driver, &intel_flip_funcs);
+
+   INIT_LIST_HEAD(&dev_priv->flip.list);
+   spin_lock_init(&dev_priv->flip.lock);
+   INIT_WORK(&dev_priv->flip.work, intel_atomic_process_flips_work);
+   dev_priv->flip.wq = create_singlethread_workqueue("intel_flip");
 }

 static void intel_flip_fini(struct drm_device *dev)
@@ -2082,6 +2094,145 @@ static void intel_flip_fini(struct drm_device *dev)
drm_flip_driver_fini(&dev_priv->flip_driver);
 }

+static void intel_atomic_postpone_flip(struct drm_device *dev,
+  struct intel_flip *intel_flip)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_ring_buffer *ring = intel_flip->ring;
+   int ret;
+
+   intel_flip->busy = ring != NULL;
+
+   list_move_tail(&intel_flip->base.list, &dev_priv->flip.list);
+
+   if (!ring)
+   return;
+
+   if (WARN_ON(!ring->irq_get(rin

[PATCH 19/22] drm: Reject addfb2 with undefined flags bits

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9836755..5f8dda8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2348,6 +2348,11 @@ int drm_mode_addfb2(struct drm_device *dev,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

+   if (r->flags & ~DRM_MODE_FB_INTERLACED) {
+   DRM_DEBUG_KMS("bad framebuffer flags %x\n", r->flags);
+   return -EINVAL;
+   }
+
if ((config->min_width > r->width) || (r->width > config->max_width)) {
DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= 
%d\n",
  r->width, config->min_width, config->max_width);
-- 
1.7.8.6



[PATCH 18/22] drm/i915: Unpin old fbs only when appropriate

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Don't unpin the old fb after flips, unless a new fb was pinned, or we're
disabling the plane/crtc.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index a119896..b795cb2 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -2133,8 +2133,10 @@ static void atomic_pipe_commit(struct drm_device *dev,
intel_flip->old_cursor_bo = st->old.cursor_bo;
}

-   if (st->old.fb) {
+   if (st->old.fb)
intel_flip->old_fb_id = st->old.fb->base.id;
+
+   if (st->fb_dirty && st->old.fb) {
intel_flip->old_bo = 
to_intel_framebuffer(st->old.fb)->obj;

mutex_lock(&dev->struct_mutex);
@@ -2177,8 +2179,10 @@ static void atomic_pipe_commit(struct drm_device *dev,

intel_plane->calc(plane, plane->fb, &st->coords);

-   if (st->old.fb) {
+   if (st->old.fb)
intel_flip->old_fb_id = st->old.fb->base.id;
+
+   if (st->dirty && st->old.fb) {
intel_flip->old_bo = 
to_intel_framebuffer(st->old.fb)->obj;

mutex_lock(&dev->struct_mutex);
-- 
1.7.8.6



[PATCH 17/22] drm/i915: Send atomic completion events even if nothing changed

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index bfc0563..a119896 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -1641,13 +1641,15 @@ static int intel_atomic_commit(struct drm_device *dev, 
void *state)
struct intel_atomic_state *s = state;
int ret;

-   if (!s->dirty)
-   return 0;
-
ret = alloc_flip_data(dev, s);
if (ret)
return ret;

+   if (!s->dirty) {
+   queue_remaining_events(dev, s);
+   return 0;
+   }
+
ret = pin_fbs(dev, s);
if (ret)
return ret;
-- 
1.7.8.6



[PATCH 16/22] drm/i915: Fix plane src rectangle dirty check

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index c4cec40..bfc0563 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -555,9 +555,9 @@ static void plane_compute_dirty(struct intel_atomic_state 
*s,
return;

if (plane->src_x != state->old.src_x ||
-   plane->src_y != state->old.src_x ||
-   plane->src_w != state->old.src_x ||
-   plane->src_h != state->old.src_x ||
+   plane->src_y != state->old.src_y ||
+   plane->src_w != state->old.src_w ||
+   plane->src_h != state->old.src_h ||
plane->crtc_x != state->old.crtc_x ||
plane->crtc_y != state->old.crtc_y ||
plane->crtc_w != state->old.crtc_w ||
-- 
1.7.8.6



[PATCH 15/22] drm/i915: Fix hiding the cursor with atomic ioctl

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ander Conselvan de Oliveira 

intel_crtc->cursor_visible is only changed on the commit phase, so the
check for visibility was considering the previous state. Change this to
intel_crtc->cursor_handle instead.
---
 drivers/gpu/drm/i915/intel_atomic.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 98af0ae..c4cec40 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -1304,7 +1304,7 @@ static int check_crtc(struct intel_crtc_state *s)
}
}

-   if (intel_crtc->cursor_visible &&
+   if (intel_crtc->cursor_handle &&
(intel_crtc->cursor_width != 64 ||
 intel_crtc->cursor_height != 64)) {
return -EINVAL;
-- 
1.7.8.6



[PATCH 14/22] drm/i915: Fix sprite_scaling_enabled for multiple sprites

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

We have more than one sprite, so a boolean simply won't cut it.
Turn sprite_scaling_enabled into a bitmask and track the state
of sprite scaler for each sprite independently.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/i915_drv.h |2 +-
 drivers/gpu/drm/i915/intel_sprite.c |   11 ++-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 51b36c1..4cf0e15 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -473,7 +473,7 @@ typedef struct drm_i915_private {

/* overlay */
struct intel_overlay *overlay;
-   bool sprite_scaling_enabled;
+   unsigned int sprite_scaling_enabled;

/* LVDS info */
int backlight_level;  /* restore backlight to this value */
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 88fdd0d..97740ee 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -315,15 +315,16 @@ ivb_prepare_plane(struct drm_plane *plane)
 */
if (regs->scale & SPRITE_SCALE_ENABLE) {
if (!dev_priv->sprite_scaling_enabled) {
-   dev_priv->sprite_scaling_enabled = true;
+   dev_priv->sprite_scaling_enabled |= 1 << pipe;
intel_update_watermarks(dev);
intel_wait_for_vblank(dev, pipe);
}
} else {
-   if (dev_priv->sprite_scaling_enabled) {
-   dev_priv->sprite_scaling_enabled = false;
+   if (dev_priv->sprite_scaling_enabled & (1 << pipe)) {
+   dev_priv->sprite_scaling_enabled &= ~(1 << pipe);
/* potentially re-enable LP watermarks */
-   intel_update_watermarks(dev);
+   if (!dev_priv->sprite_scaling_enabled)
+   intel_update_watermarks(dev);
}
}
 }
@@ -359,7 +360,7 @@ ivb_disable_plane(struct drm_plane *plane)
ivb_commit_plane(plane);
POSTING_READ(SPRSURF(pipe));

-   dev_priv->sprite_scaling_enabled = false;
+   dev_priv->sprite_scaling_enabled &= ~(1 << pipe);
intel_update_watermarks(dev);
 }

-- 
1.7.8.6



[PATCH 13/22] drm/i915: Don't mark cursor as pinned, when we don't have a cursor bo

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Avoids a NULL pointer dereference if the atomic modeset fails.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index ac7fe88..98af0ae 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -726,7 +726,8 @@ static int pin_cursors(struct drm_device *dev,
if (ret)
goto unpin;

-   st->cursor_pinned = true;
+   if (intel_crtc->cursor_bo)
+   st->cursor_pinned = true;
}

return 0;
-- 
1.7.8.6



[PATCH 12/22] drm/i915: Kill the pending_flip counter manipulations

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

The pending_flip counter is probably going to be remove entirely,
along with i915_gem_execbuffer_wait_for_flips() so don't even try to
use it.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c |   74 +--
 1 files changed, 2 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 1fce359..ac7fe88 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -1536,45 +1536,9 @@ static void atomic_pipe_commit(struct drm_device *dev,
   struct intel_atomic_state *state,
   int pipe);

-static int apply_nonblocking(struct drm_device *dev, struct intel_atomic_state 
*s)
+static void apply_nonblocking(struct drm_device *dev, struct 
intel_atomic_state *s)
 {
struct intel_crtc *intel_crtc;
-   int i;
-
-   for (i = 0; i < dev->mode_config.num_crtc; i++) {
-   struct intel_crtc_state *st = &s->crtc[i];
-   struct intel_crtc *intel_crtc = to_intel_crtc(st->crtc);
-   struct drm_i915_gem_object *obj;
-
-   if (!st->old.fb)
-   continue;
-
-   obj = to_intel_framebuffer(st->old.fb)->obj;
-
-   /* Only one bit per plane in pending_flips */
-   if (atomic_read(&obj->pending_flip) & (1 << intel_crtc->plane))
-   return -EBUSY;
-   }
-
-   for (i = 0; i < dev->mode_config.num_plane; i++) {
-   struct intel_plane_state *st = &s->plane[i];
-   struct intel_plane *intel_plane = to_intel_plane(st->plane);
-   struct drm_i915_gem_object *obj;
-
-   if (!st->old.fb)
-   continue;
-
-   obj = to_intel_framebuffer(st->old.fb)->obj;
-
-   if (!st->old.fb)
-   continue;
-
-   obj = to_intel_framebuffer(st->old.fb)->obj;
-
-   /* Only one bit per plane in pending_flips */
-   if (atomic_read(&obj->pending_flip) & (1 << (16 + 
intel_plane->pipe)))
-   return -EBUSY;
-   }

list_for_each_entry(intel_crtc, &dev->mode_config.crtc_list, base.head)
atomic_pipe_commit(dev, s, intel_crtc->pipe);
@@ -1582,8 +1546,6 @@ static int apply_nonblocking(struct drm_device *dev, 
struct intel_atomic_state *
/* don't restore the old state in end() */
s->dirty = false;
s->restore_state = false;
-
-   return 0;
 }

 static int alloc_flip_data(struct drm_device *dev, struct intel_atomic_state 
*s)
@@ -1695,12 +1657,7 @@ static int intel_atomic_commit(struct drm_device *dev, 
void *state)

/* try to apply in a non blocking manner */
if (s->flags & DRM_MODE_ATOMIC_NONBLOCK) {
-   ret = apply_nonblocking(dev, s);
-   if (ret) {
-   unpin_cursors(dev, s);
-   unpin_fbs(dev, s);
-   return ret;
-   }
+   apply_nonblocking(dev, s);
} else {
/* apply in a blocking manner */
ret = apply_config(dev, s);
@@ -1823,7 +1780,6 @@ static void intel_flip_complete(struct drm_flip *flip)
struct intel_flip *intel_flip =
container_of(flip, struct intel_flip, base);
struct drm_device *dev = intel_flip->crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc = intel_flip->crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
@@ -1841,18 +1797,6 @@ static void intel_flip_complete(struct drm_flip *flip)

if (intel_flip->vblank_ref)
drm_vblank_put(dev, pipe);
-
-   /* Possibly allow rendering to old_bo again */
-   if (intel_flip->old_bo) {
-   if (intel_flip->plane) {
-   struct intel_plane *intel_plane = 
to_intel_plane(intel_flip->plane);
-   atomic_clear_mask(1 << (16 + intel_plane->pipe), 
&intel_flip->old_bo->pending_flip.counter);
-   } else
-   atomic_clear_mask(1 << intel_crtc->plane, 
&intel_flip->old_bo->pending_flip.counter);
-
-   if (atomic_read(&intel_flip->old_bo->pending_flip) == 0)
-   wake_up(&dev_priv->pending_flip_queue);
-   }
 }

 static void intel_flip_finish(struct drm_flip *flip)
@@ -2193,13 +2137,6 @@ static void atomic_pipe_commit(struct drm_device *dev,
mutex_lock(&dev->struct_mutex);
drm_gem_object_reference(&intel_flip->old_bo->base);
mutex_unlock(&dev->struct_mutex);
-
-   /*
-* Block clients from rendering to the new back buffer 
until
-* the flip occurs and the object is no lon

[PATCH 11/22] drm/i915: Update connector DPMS state after an atomic modeset

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Update the connector DPMS state after atomic modeset operations.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c |   31 +++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index c5558cc..1fce359 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -1475,6 +1475,36 @@ static void update_props(struct drm_device *dev,
}
 }

+/*
+ * FIXME
+ * Perhaps atomic modeset shouldn't actually change the DPMS state,
+ * unless explicitly asked to do so. That's the way we treat everything
+ * else, so it makes sense. Although the dpms property is already a bit
+ * special in the legacy codepaths, so maybe we should follow the same
+ * pattern. Ie. a modeset forces DPMS to on (which is what we do here).
+ */
+static void update_connector_dpms(struct drm_device *dev, struct drm_crtc 
*crtc)
+{
+   struct drm_connector *connector;
+
+   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+   int dpms = connector->dpms;
+
+   if (connector->encoder && connector->encoder->crtc == crtc)
+   dpms = DRM_MODE_DPMS_ON;
+   else if (!connector->encoder || !connector->encoder->crtc)
+   dpms = DRM_MODE_DPMS_OFF;
+
+   if (connector->dpms == dpms)
+   continue;
+
+   connector->dpms = dpms;
+   drm_connector_property_set_value(connector,
+dev->mode_config.dpms_property,
+dpms);
+   }
+}
+
 static void update_crtc(struct drm_device *dev,
struct intel_atomic_state *s)
 {
@@ -1494,6 +1524,7 @@ static void update_crtc(struct drm_device *dev,
if (st->mode_dirty) {
drm_calc_timestamping_constants(crtc);
intel_crtc_update_sarea(crtc, crtc->enabled);
+   update_connector_dpms(dev, crtc);
}

if (st->fb_dirty)
-- 
1.7.8.6



[PATCH 10/22] drm/i915: Update new_crtc and new_encoder fields after atomic modeset

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

The i915 modeset logic requires that these be kept in sync with
the other crtc and encoder pointers.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c  |2 ++
 drivers/gpu/drm/i915/intel_display.c |2 +-
 drivers/gpu/drm/i915/intel_drv.h |2 ++
 3 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index e58ec3f..c5558cc 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -1701,6 +1701,8 @@ static int intel_atomic_commit(struct drm_device *dev, 
void *state)

update_props(dev, s);

+   intel_modeset_update_staged_output_state(dev);
+
return 0;
 }

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0eccef3..d310529 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6845,7 +6845,7 @@ static bool intel_encoder_crtc_ok(struct drm_encoder 
*encoder,
  * Updates the staged output configuration state, e.g. after we've read out the
  * current hw state.
  */
-static void intel_modeset_update_staged_output_state(struct drm_device *dev)
+void intel_modeset_update_staged_output_state(struct drm_device *dev)
 {
struct intel_encoder *encoder;
struct intel_connector *connector;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a229680..4847170 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -644,4 +644,6 @@ extern void intel_disable_primary(struct drm_crtc *crtc);
 extern void intel_crtc_attach_properties(struct drm_crtc *crtc);
 extern void intel_crtc_update_properties(struct drm_crtc *crtc);

+extern void intel_modeset_update_staged_output_state(struct drm_device *dev);
+
 #endif /* __INTEL_DRV_H__ */
-- 
1.7.8.6



[PATCH 09/22] drm/i915: Use intel_best_encoder() directly

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

All connectors use intel_best_encoder() as their best_encoder() func, so
just call it directly w/o the indirection.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c |   10 ++
 1 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 6dd07fb..e58ec3f 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -152,8 +152,6 @@ static int process_connectors(struct intel_crtc_state *s, 
const uint32_t *ids, i
int i;

for (i = 0; i < count_ids; i++) {
-   struct drm_encoder *encoder;
-   const struct drm_connector_helper_funcs *connector_funcs;
struct drm_mode_object *obj;
int j;

@@ -169,9 +167,8 @@ static int process_connectors(struct intel_crtc_state *s, 
const uint32_t *ids, i
}

connector = obj_to_connector(obj);
-   connector_funcs = connector->helper_private;

-   encoder = connector_funcs->best_encoder(connector);
+   encoder = intel_best_encoder(connector);

if (!drm_encoder_crtc_ok(encoder, crtc))
return -EINVAL;
@@ -180,9 +177,6 @@ static int process_connectors(struct intel_crtc_state *s, 
const uint32_t *ids, i
}

list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-   const struct drm_connector_helper_funcs *connector_funcs =
-   connector->helper_private;
-
for (i = 0; i < count_ids; i++) {
if (connector == connectors[i])
break;
@@ -196,7 +190,7 @@ static int process_connectors(struct intel_crtc_state *s, 
const uint32_t *ids, i
continue;
}

-   encoder = connector_funcs->best_encoder(connector);
+   encoder = intel_best_encoder(connector);

connector->encoder = encoder;
encoder->crtc = crtc;
-- 
1.7.8.6



[PATCH 08/22] drm: Move standard crtc/plane prop handling to drm_crtc.c

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Move some of the property code to drm_crtc.c since it should be shared
by everyone.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c   |  235 +++
 drivers/gpu/drm/i915/intel_atomic.c  |  256 --
 drivers/gpu/drm/i915/intel_display.c |   29 
 3 files changed, 264 insertions(+), 256 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f1fcb5e..9836755 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4388,3 +4388,238 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,

return ret;
 }
+
+static void drm_crtc_update_connector_ids_property(struct drm_crtc *crtc)
+{
+   struct drm_mode_config *config = &crtc->dev->mode_config;
+   struct drm_connector *connector;
+   uint64_t value = 0;
+   int i = 0;
+   uint32_t connector_ids[config->num_connector];
+
+   list_for_each_entry(connector, &config->connector_list, head) {
+   if (connector->encoder && connector->encoder->crtc == crtc)
+   connector_ids[i++] = connector->base.id;
+   }
+
+   if (i) {
+   drm_property_blob_replace_data(crtc->connector_ids_blob,
+  i * sizeof connector_ids[0], 
connector_ids);
+   value = crtc->connector_ids_blob->base.id;
+   } else
+   drm_property_blob_replace_data(crtc->connector_ids_blob, 0, 
NULL);
+
+   drm_object_property_set_value(&crtc->base, config->connector_ids_prop, 
value);
+}
+
+static void drm_crtc_update_mode_property(struct drm_crtc *crtc)
+{
+   struct drm_mode_config *config = &crtc->dev->mode_config;
+   uint64_t value = 0;
+
+   if (crtc->enabled) {
+   struct drm_mode_modeinfo umode;
+
+   drm_crtc_convert_to_umode(&umode, &crtc->mode);
+   drm_property_blob_replace_data(crtc->mode_blob, sizeof umode, 
&umode);
+   value = crtc->mode_blob->base.id;
+   } else
+   drm_property_blob_replace_data(crtc->mode_blob, 0, NULL);
+
+   drm_object_property_set_value(&crtc->base, config->mode_prop, value);
+}
+
+void drm_crtc_update_properties(struct drm_crtc *crtc)
+{
+   struct drm_mode_object *obj = &crtc->base;
+   struct drm_mode_config *config = &crtc->dev->mode_config;
+
+   drm_object_property_set_value(obj, config->src_x_prop, crtc->x);
+   drm_object_property_set_value(obj, config->src_y_prop, crtc->y);
+   drm_object_property_set_value(obj, config->fb_id_prop, crtc->fb ? 
crtc->fb->base.id : 0);
+
+   drm_crtc_update_mode_property(crtc);
+   drm_crtc_update_connector_ids_property(crtc);
+}
+EXPORT_SYMBOL(drm_crtc_update_properties);
+
+void drm_plane_update_properties(struct drm_plane *plane)
+{
+   struct drm_mode_object *obj = &plane->base;
+   struct drm_mode_config *config = &plane->dev->mode_config;
+
+   drm_object_property_set_value(obj, config->src_x_prop, plane->src_x);
+   drm_object_property_set_value(obj, config->src_y_prop, plane->src_y);
+   drm_object_property_set_value(obj, config->src_w_prop, plane->src_w);
+   drm_object_property_set_value(obj, config->src_h_prop, plane->src_h);
+
+   drm_object_property_set_value(obj, config->crtc_x_prop, plane->crtc_x);
+   drm_object_property_set_value(obj, config->crtc_y_prop, plane->crtc_y);
+   drm_object_property_set_value(obj, config->crtc_w_prop, plane->crtc_w);
+   drm_object_property_set_value(obj, config->crtc_h_prop, plane->crtc_h);
+
+   drm_object_property_set_value(obj, config->fb_id_prop, plane->fb ? 
plane->fb->base.id : 0);
+   drm_object_property_set_value(obj, config->crtc_id_prop, plane->crtc ? 
plane->crtc->base.id : 0);
+}
+EXPORT_SYMBOL(drm_plane_update_properties);
+
+int drm_crtc_create_blobs(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+
+   crtc->mode_blob = drm_property_create_blob(dev, 0, sizeof(struct 
drm_mode_modeinfo), NULL);
+   if (!crtc->mode_blob)
+   return -ENOMEM;
+
+   crtc->connector_ids_blob = drm_property_create_blob(dev, 0, 
dev->mode_config.num_connector * sizeof(uint32_t), NULL);
+   if (!crtc->connector_ids_blob)
+   return -ENOMEM;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_crtc_create_blobs);
+
+void drm_crtc_destroy_blobs(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+
+   drm_property_destroy_blob(dev, crtc->mode_blob);
+   drm_property_destroy_blob(dev, crtc->connector_ids_blob);
+}
+EXPORT_SYMBOL(drm_crtc_destroy_blobs);
+
+static void drm_property_destroy_null(struct drm_device *dev, struct 
drm_property **prop)
+{
+   drm_property_destroy(dev, *prop);
+   *prop = NULL;
+}
+
+void drm_mode_destroy_properties(struct drm_device *dev)
+{
+   struct drm_mode_config *config = &dev->mode_config;
+
+   drm_property_destroy_

[PATCH 07/22] drm/i915: Update CRTC properties after modeset

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Update cursor related CRTC properties after a modeset. The cursor
properties aren't handled by the drm core since not all CRTCs have
cursors.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_display.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 958b21b..12d4e02 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5802,6 +5802,8 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
if (old_obj)
intel_crtc_cursor_bo_unref(crtc, old_obj);

+   intel_crtc_update_properties(crtc);
+
return 0;
 }

@@ -5814,6 +5816,8 @@ static int intel_crtc_cursor_move(struct drm_crtc *crtc, 
int x, int y)

intel_crtc_update_cursor(crtc, true);

+   intel_crtc_update_properties(crtc);
+
return 0;
 }

@@ -6763,6 +6767,8 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,

trace_i915_flip_request(intel_crtc->plane, obj);

+   intel_crtc_update_properties(crtc);
+
return 0;

 cleanup_pending:
@@ -7490,6 +7496,7 @@ next_encoder:
 static int intel_crtc_set_config(struct drm_mode_set *set)
 {
struct drm_device *dev;
+   struct drm_crtc *crtc;
struct drm_mode_set save_set;
struct intel_set_config *config;
int ret;
@@ -7563,6 +7570,10 @@ static int intel_crtc_set_config(struct drm_mode_set 
*set)

intel_set_config_free(config);

+   /* changes in one CRTC can affect the others */
+   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
+   intel_crtc_update_properties(crtc);
+
return 0;

 fail:
@@ -7574,6 +7585,10 @@ fail:
save_set.x, save_set.y, save_set.fb))
DRM_ERROR("failed to restore config after modeset failure\n");

+   /* changes in one CRTC can affect the others */
+   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
+   intel_crtc_update_properties(crtc);
+
 out_config:
intel_set_config_free(config);
return ret;
-- 
1.7.8.6



[PATCH 06/22] drm: Update standard plane properties after update_plane/disable_plane

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Keep the new plane properties when doing operations through the legacy
code paths.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4736cfe..f1fcb5e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -407,6 +407,8 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
/* disconnect the plane from the fb and crtc: */
plane->fb = NULL;
plane->crtc = NULL;
+
+   drm_plane_update_properties(plane);
}
}

@@ -1781,6 +1783,8 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
plane->funcs->disable_plane(plane);
plane->crtc = NULL;
plane->fb = NULL;
+
+   drm_plane_update_properties(plane);
goto out;
}

@@ -1864,6 +1868,8 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
plane->src_y = plane_req->src_y;
plane->src_w = plane_req->src_w;
plane->src_h = plane_req->src_h;
+
+   drm_plane_update_properties(plane);
}

 out:
-- 
1.7.8.6



[PATCH 05/22] drm_crtc_helper: Update standard crtc properties after modeset

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Keep the new CRTC properties when doing modeset through the legacy code
paths.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc_helper.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 80bbbda..4507aed 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -743,6 +743,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
kfree(save_connectors);
kfree(save_encoders);
kfree(save_crtcs);
+
+   /* changes in one CRTC can affect the others */
+   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
+   drm_crtc_update_properties(crtc);
+
return 0;

 fail:
@@ -771,6 +776,11 @@ fail:
kfree(save_connectors);
kfree(save_encoders);
kfree(save_crtcs);
+
+   /* changes in one CRTC can affect the others */
+   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
+   drm_crtc_update_properties(crtc);
+
return ret;
 }
 EXPORT_SYMBOL(drm_crtc_helper_set_config);
-- 
1.7.8.6



[PATCH 04/22] drm/i915: Move standard properties under mode_config

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Standard connector properties are kept in the mode_config structure.
Move the CRTC and plane properties there as well.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c |  295 +++
 include/drm/drm_crtc.h  |   19 +++
 2 files changed, 176 insertions(+), 138 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 0e37cf5..0def947 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -30,24 +30,6 @@

 #include "intel_drv.h"

-static struct drm_property *prop_src_x;
-static struct drm_property *prop_src_y;
-static struct drm_property *prop_src_w;
-static struct drm_property *prop_src_h;
-static struct drm_property *prop_crtc_x;
-static struct drm_property *prop_crtc_y;
-static struct drm_property *prop_crtc_w;
-static struct drm_property *prop_crtc_h;
-static struct drm_property *prop_fb_id;
-static struct drm_property *prop_crtc_id;
-static struct drm_property *prop_mode;
-static struct drm_property *prop_connector_ids;
-static struct drm_property *prop_cursor_id;
-static struct drm_property *prop_cursor_x;
-static struct drm_property *prop_cursor_y;
-static struct drm_property *prop_cursor_w;
-static struct drm_property *prop_cursor_h;
-
 struct intel_flip {
struct drm_flip base;
u32 vbl_count;
@@ -368,27 +350,28 @@ static int plane_set(struct intel_atomic_state *s,
 uint64_t value)
 {
struct drm_plane *plane = state->plane;
+   struct drm_mode_config *config = &plane->dev->mode_config;
struct drm_mode_object *obj;

state->changed = true;

-   if (prop == prop_src_x) {
+   if (prop == config->src_x_prop) {
plane->src_x = value;
-   } else if (prop == prop_src_y) {
+   } else if (prop == config->src_y_prop) {
plane->src_y = value;
-   } else if (prop == prop_src_w) {
+   } else if (prop == config->src_w_prop) {
plane->src_w = value;
-   } else if (prop == prop_src_h) {
+   } else if (prop == config->src_h_prop) {
plane->src_h = value;
-   } else if (prop == prop_crtc_x) {
+   } else if (prop == config->crtc_x_prop) {
plane->crtc_x = value;
-   } else if (prop == prop_crtc_y) {
+   } else if (prop == config->crtc_y_prop) {
plane->crtc_y = value;
-   } else if (prop == prop_crtc_w) {
+   } else if (prop == config->crtc_w_prop) {
plane->crtc_w = value;
-   } else if (prop == prop_crtc_h) {
+   } else if (prop == config->crtc_h_prop) {
plane->crtc_h = value;
-   } else if (prop == prop_crtc_id) {
+   } else if (prop == config->crtc_id_prop) {
if (value) {
obj = drm_mode_object_find(plane->dev, value, 
DRM_MODE_OBJECT_CRTC);
if (!obj) {
@@ -398,7 +381,7 @@ static int plane_set(struct intel_atomic_state *s,
plane->crtc = obj_to_crtc(obj);
} else
plane->crtc = NULL;
-   } else if (prop == prop_fb_id) {
+   } else if (prop == config->fb_id_prop) {
if (value) {
obj = drm_mode_object_find(plane->dev, value, 
DRM_MODE_OBJECT_FB);
if (!obj) {
@@ -422,16 +405,17 @@ static int crtc_set(struct intel_atomic_state *s,
uint64_t value, const void *blob_data)
 {
struct drm_crtc *crtc = state->crtc;
+   struct drm_mode_config *config = &crtc->dev->mode_config;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_mode_object *obj;

state->changed = true;

-   if (prop == prop_src_x) {
+   if (prop == config->src_x_prop) {
crtc->x = value;
-   } else if (prop == prop_src_y) {
+   } else if (prop == config->src_y_prop) {
crtc->y = value;
-   } else if (prop == prop_mode) {
+   } else if (prop == config->mode_prop) {
const struct drm_mode_modeinfo *umode = blob_data;

if (value != 0 && value != sizeof *umode) {
@@ -462,7 +446,7 @@ static int crtc_set(struct intel_atomic_state *s,
drm_mode_destroy(crtc->dev, mode);
} else
crtc->enabled = false;
-   } else if (prop == prop_fb_id) {
+   } else if (prop == config->fb_id_prop) {
if (value) {
obj = drm_mode_object_find(crtc->dev, value, 
DRM_MODE_OBJECT_FB);
if (!obj) {
@@ -472,7 +456,7 @@ static int crtc_set(struct intel_atomic_state *s,
crtc->fb = obj_to_fb(obj);
} else
crtc->fb = NULL;
-   } else if (prop == prop_connector_ids) {
+   } else if (prop == config->connector_ids_prop) {
c

[PATCH 03/22] drm/i915: Refactor property handling in atomic code

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Move the property code around a bit to make it easier to move it out to
the drm core later.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c |  423 ---
 drivers/gpu/drm/i915/intel_drv.h|3 +
 include/drm/drm_crtc.h  |   12 +
 3 files changed, 252 insertions(+), 186 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 41fd0d5..0e37cf5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -1473,87 +1473,6 @@ static int intel_atomic_check(struct drm_device *dev, 
void *state)
return 0;
 }

-static void update_plane_props(struct drm_plane *plane)
-{
-   struct drm_mode_object *obj = &plane->base;
-
-   drm_object_property_set_value(obj, prop_src_x, plane->src_x);
-   drm_object_property_set_value(obj, prop_src_y, plane->src_y);
-   drm_object_property_set_value(obj, prop_src_w, plane->src_w);
-   drm_object_property_set_value(obj, prop_src_h, plane->src_h);
-
-   drm_object_property_set_value(obj, prop_crtc_x, plane->crtc_x);
-   drm_object_property_set_value(obj, prop_crtc_y, plane->crtc_y);
-   drm_object_property_set_value(obj, prop_crtc_w, plane->crtc_w);
-   drm_object_property_set_value(obj, prop_crtc_h, plane->crtc_h);
-
-   drm_object_property_set_value(obj, prop_fb_id, plane->fb ? 
plane->fb->base.id : 0);
-   drm_object_property_set_value(obj, prop_crtc_id, plane->crtc ? 
plane->crtc->base.id : 0);
-}
-
-static int update_prop_connector_ids(struct drm_crtc *crtc)
-{
-   struct drm_device *dev = crtc->dev;
-   struct drm_connector *connector;
-   uint64_t value = 0;
-   int i = 0;
-   uint32_t connector_ids[dev->mode_config.num_connector];
-
-   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-   if (connector->encoder && connector->encoder->crtc == crtc)
-   connector_ids[i++] = connector->base.id;
-   }
-
-   if (i) {
-   drm_property_blob_replace_data(crtc->connector_ids_blob,
-  i * sizeof connector_ids[0], 
connector_ids);
-   value = crtc->connector_ids_blob->base.id;
-   } else
-   drm_property_blob_replace_data(crtc->connector_ids_blob, 0, 
NULL);
-
-   drm_object_property_set_value(&crtc->base, prop_connector_ids, value);
-
-   return 0;
-}
-
-static int update_prop_mode(struct drm_crtc *crtc)
-{
-   uint64_t value = 0;
-
-   if (crtc->enabled) {
-   struct drm_mode_modeinfo umode;
-
-   drm_crtc_convert_to_umode(&umode, &crtc->mode);
-   drm_property_blob_replace_data(crtc->mode_blob, sizeof umode, 
&umode);
-   value = crtc->mode_blob->base.id;
-   } else
-   drm_property_blob_replace_data(crtc->mode_blob, 0, NULL);
-
-   drm_object_property_set_value(&crtc->base, prop_mode, value);
-
-   return 0;
-}
-
-static void update_crtc_props(struct drm_crtc *crtc)
-{
-   struct drm_mode_object *obj = &crtc->base;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
-   drm_object_property_set_value(obj, prop_src_x, crtc->x);
-   drm_object_property_set_value(obj, prop_src_y, crtc->y);
-
-   drm_object_property_set_value(obj, prop_fb_id, crtc->fb ? 
crtc->fb->base.id : 0);
-
-   drm_object_property_set_value(obj, prop_cursor_id, 
intel_crtc->cursor_handle);
-   drm_object_property_set_value(obj, prop_cursor_x, intel_crtc->cursor_x);
-   drm_object_property_set_value(obj, prop_cursor_y, intel_crtc->cursor_y);
-   drm_object_property_set_value(obj, prop_cursor_w, 
intel_crtc->cursor_width);
-   drm_object_property_set_value(obj, prop_cursor_h, 
intel_crtc->cursor_height);
-
-   update_prop_mode(crtc);
-   update_prop_connector_ids(crtc);
-}
-
 static void update_props(struct drm_device *dev,
 struct intel_atomic_state *s)
 {
@@ -1565,7 +1484,7 @@ static void update_props(struct drm_device *dev,
if (!st->fb_dirty && !st->mode_dirty)
continue;

-   update_crtc_props(st->crtc);
+   intel_crtc_update_properties(st->crtc);
}

for (i = 0; i < dev->mode_config.num_plane; i++) {
@@ -1574,7 +1493,7 @@ static void update_props(struct drm_device *dev,
if (!st->dirty)
continue;

-   update_plane_props(st->plane);
+   drm_plane_update_properties(st->plane);
}
 }

@@ -1829,32 +1748,6 @@ static const struct drm_atomic_funcs intel_atomic_funcs 
= {
.end = intel_atomic_end,
 };

-static struct {
-   struct drm_property **prop;
-   const char *name;
-   uint64_t min;
-   uint64_t max;
-} props[] = {
-   { &prop_src_x, "SRC_X", 0, UINT_MAX },
-   { &prop_src_y, "SRC_Y"

[PATCH 02/22] drm/i915: Clear flip helpers for sprites too

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Don't leave stale flips hanging around the sprites' flip helpers
when the crtc is being disabled.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c  |   15 +++
 drivers/gpu/drm/i915/intel_display.c |4 ++--
 drivers/gpu/drm/i915/intel_drv.h |1 +
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 41885fa..41fd0d5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -2449,3 +2449,18 @@ void intel_atomic_handle_vblank(struct drm_device *dev, 
int pipe)
drm_flip_helper_vblank(&intel_plane->flip_helper);
}
 }
+
+void intel_atomic_clear_flips(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_plane *intel_plane;
+   int pipe = intel_crtc->pipe;
+
+   drm_flip_helper_clear(&intel_crtc->flip_helper);
+
+   list_for_each_entry(intel_plane, &dev->mode_config.plane_list, 
base.head) {
+   if (intel_plane->pipe == pipe)
+   drm_flip_helper_clear(&intel_plane->flip_helper);
+   }
+}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 43cff11..958b21b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3368,7 +3368,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
encoder->disable(encoder);

intel_crtc_wait_for_pending_flips(crtc);
-   drm_flip_helper_clear(&intel_crtc->flip_helper);
+   intel_atomic_clear_flips(crtc);
drm_vblank_off(dev, pipe);
intel_crtc_update_cursor(crtc, false);

@@ -3506,7 +3506,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)

/* Give the overlay scaler a chance to disable if it's on this pipe */
intel_crtc_wait_for_pending_flips(crtc);
-   drm_flip_helper_clear(&intel_crtc->flip_helper);
+   intel_atomic_clear_flips(crtc);
drm_vblank_off(dev, pipe);
intel_crtc_dpms_overlay(intel_crtc, false);
intel_crtc_update_cursor(crtc, false);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b9b96d3..8580ddd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -636,6 +636,7 @@ extern int intel_atomic_init(struct drm_device *dev);
 extern void intel_atomic_fini(struct drm_device *dev);
 extern void intel_atomic_free_events(struct drm_device *dev, struct drm_file 
*file);
 extern void intel_atomic_handle_vblank(struct drm_device *dev, int pipe);
+extern void intel_atomic_clear_flips(struct drm_crtc *crtc);

 extern void intel_enable_primary(struct drm_crtc *crtc);
 extern void intel_disable_primary(struct drm_crtc *crtc);
-- 
1.7.8.6



[PATCH 01/22] drm: Add missing EXPORT_SYMBOL()s for drm_flip

2012-11-12 Thread ville.syrj...@linux.intel.com
From: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/drm_flip.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_flip.c b/drivers/gpu/drm/drm_flip.c
index 6ccc3f8..a20e6a4 100644
--- a/drivers/gpu/drm/drm_flip.c
+++ b/drivers/gpu/drm/drm_flip.c
@@ -24,6 +24,7 @@
  * Ville Syrj?l? 
  */

+#include 
 #include 

 static void drm_flip_driver_cleanup(struct work_struct *work)
@@ -141,6 +142,7 @@ void drm_flip_helper_init(struct drm_flip_helper *helper,
helper->driver = driver;
helper->funcs = funcs;
 }
+EXPORT_SYMBOL(drm_flip_helper_init);

 void drm_flip_helper_clear(struct drm_flip_helper *helper)
 {
@@ -176,6 +178,7 @@ void drm_flip_helper_clear(struct drm_flip_helper *helper)
if (need_cleanup)
queue_work(driver->wq, &driver->cleanup_work);
 }
+EXPORT_SYMBOL(drm_flip_helper_clear);

 void drm_flip_helper_fini(struct drm_flip_helper *helper)
 {
@@ -186,6 +189,7 @@ void drm_flip_helper_fini(struct drm_flip_helper *helper)
flush_work_sync(&driver->finish_work);
flush_work_sync(&driver->cleanup_work);
 }
+EXPORT_SYMBOL(drm_flip_helper_fini);

 void drm_flip_helper_vblank(struct drm_flip_helper *helper)
 {
@@ -223,6 +227,7 @@ void drm_flip_helper_vblank(struct drm_flip_helper *helper)
if (need_cleanup)
queue_work(driver->wq, &driver->cleanup_work);
 }
+EXPORT_SYMBOL(drm_flip_helper_vblank);

 void drm_flip_driver_init(struct drm_flip_driver *driver,
  const struct drm_flip_driver_funcs *funcs)
@@ -239,6 +244,7 @@ void drm_flip_driver_init(struct drm_flip_driver *driver,

driver->wq = create_singlethread_workqueue("drm_flip");
 }
+EXPORT_SYMBOL(drm_flip_driver_init);

 void drm_flip_driver_fini(struct drm_flip_driver *driver)
 {
@@ -248,6 +254,7 @@ void drm_flip_driver_fini(struct drm_flip_driver *driver)
WARN_ON(!list_empty(&driver->finish_list));
WARN_ON(!list_empty(&driver->cleanup_list));
 }
+EXPORT_SYMBOL(drm_flip_driver_fini);

 void drm_flip_driver_schedule_flips(struct drm_flip_driver *driver,
struct list_head *flips)
@@ -298,6 +305,7 @@ void drm_flip_driver_schedule_flips(struct drm_flip_driver 
*driver,
if (need_cleanup)
queue_work(driver->wq, &driver->cleanup_work);
 }
+EXPORT_SYMBOL(drm_flip_driver_schedule_flips);

 void drm_flip_driver_prepare_flips(struct drm_flip_driver *driver,
   struct list_head *flips)
@@ -311,6 +319,7 @@ void drm_flip_driver_prepare_flips(struct drm_flip_driver 
*driver,
helper->funcs->prepare(flip);
}
 }
+EXPORT_SYMBOL(drm_flip_driver_prepare_flips);

 void drm_flip_driver_complete_flips(struct drm_flip_driver *driver,
struct list_head *flips)
@@ -365,6 +374,7 @@ void drm_flip_driver_complete_flips(struct drm_flip_driver 
*driver,
if (need_cleanup)
queue_work(driver->wq, &driver->cleanup_work);
 }
+EXPORT_SYMBOL(drm_flip_driver_complete_flips);

 void drm_flip_init(struct drm_flip *flip,
   struct drm_flip_helper *helper)
@@ -374,3 +384,4 @@ void drm_flip_init(struct drm_flip *flip,
flip->finished = false;
INIT_LIST_HEAD(&flip->list);
 }
+EXPORT_SYMBOL(drm_flip_init);
-- 
1.7.8.6



[PATCH 00/22] Atomic page flip: fixes, refactoring and non-blocking GPU sync

2012-11-12 Thread ville.syrj...@linux.intel.com

Here's a bunch of new stuff on top of my last atomic modeset/pageflip
posting.

Highlights:
- some bug fixes
- started moving common property bits out of intel_atomic.c
- hooked up the properties to some legacy code paths
- non-blocking GPU synchronization

The GPU sync part could surely use some experienced peoples'
attention. I didn't spend too much time on it, but based on some initial
testing it seems to be working. Haven't stressed it that much though.

Oh and in patch 22 I left the default to blocking GPU sync, so if you
want to try it, you actually have to go and poke
/sys/module/drm/parameters/async_gpu to make it use the non-blocking
sync code.

As usual my git repo has all the goods:
https://gitorious.org/vsyrjala/linux/commits/drm_atomic_19

No changes to libdrm since the last time. Code is still here:
https://gitorious.org/vsyrjala/drm/commits/drm_atomic_7

I also pushed a reasonably clean test app. It uses gbm to manage the buffers
and GLES2 to render funky triangles. You can get it here:
https://gitorious.org/vsyrjala/glplane


[PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Russell King - ARM Linux
On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
> From: Rob Clark 
> 
> A new atomic modeset/pageflip ioctl being developed in DRM requires
> get_user() to work for 64bit types (in addition to just put_user()).

NAK.

(I did write a better email explaining all the ins and outs of why this
won't work and why 64-bit get_user isn't possible, but my editor crapped
out and lost all that well written message; I don't fancy typing it all
out again.)

Nevertheless,
int test_ptr(unsigned int **v, unsigned int **p)
{
return get_user(*v, p);
}

produces a warning, and you can't get away from that if you stick 64-bit
support into get_user().

Sorry, 64-bit get_user() is a no-no.


[PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Rob Clark
On Mon, Nov 12, 2012 at 5:53 PM, Russell King - ARM Linux
 wrote:
> On Mon, Nov 12, 2012 at 05:33:41PM -0600, Rob Clark wrote:
>> I'm sort of thinking maybe we want to change 'switch (sizeof(*(__p)))'
>> with 'switch (sizeof(typeof(x)))' in case someone ignores the compiler
>> warning when they try something like:
>
> Definitely not.  Ttype of access is controlled by the pointer, not by the
> size of what it's being assigned to.  Switching that around is likely to
> break stuff hugely.  Consider this:
>
> unsigned char __user *p;
> int val;
>
> get_user(val, p);
>
> If the pointer type is used to determine the access size, a char will be
> accessed.  This is legal - because we end up assigning an unsigned character
> to an int.
>
> If the size of the destination was used, we'd access an int instead, which
> is larger than the pointer, and probably the wrong thing to do anyway.
>
> Think of get_user(a, b) as being a special accessor having the ultimate
> semantics of: "a = *b;" but done in a safe way with error checking.
>
>>uint32_t x;
>>uint64_t *p = ...;
>>get_user(x, p);
>>
>> that was my one concern about 'register typeof(x) __r2 ...', but I
>> think just changing the switch condition is enough.  But maybe good to
>> have some eyes on in case there is something else I'm not thinking of.
>
> And what should happen in the above is exactly the same as what happens
> if you do:
>
> x = *p;
>
> with those types.  For ARM, that would be a 64-bit access (if the
> compiler decides not to optimize away the upper 32-bit access) followed
> by a narrowing cast down to 32-bit.  With get_user() of course, there's
> no option not to optimize it away.
>
> However, this _does_ reveal a bug with your approach.  With sizeof(*p)
> being 8, and the type of __r2 being a 32-bit quantity, the compiler will
> choose the 64-bit accessor, which will corrupt r3 - and the compiler
> won't know that r3 has been corrupted.

right, that is what I was worried about..  but what about something
along the lines of:

case 8: {   \
if (sizeof(x) < 8)  \
__get_user_x(__r2, __p, __e, __l, 4);   \
else\
__get_user_x(__r2, __p, __e, __l, 8);   \
break;  \
}   \

maybe we need a special variant of __get_user_8() instead to get the
right 32bits on big vs little endian systems, but I think something
roughly along these lines could work.

Or maybe in sizeof(x)<8 case, we just __get_user_bad()..  I'm not 100%
sure on whether this is supposed to be treated as an error case at
compile time or not.

BR,
-R

> That's too unsafe.
>
> I just tried a variant of your approach, but got lots of warnings again:
> register unsigned long long __r2 asm("r2");
> __get_user_x(__r2, __p, __e, 8, "lr");
> x = (typeof(*(__p))) ((typeof(x))__r2);
> because typeof(x) in the test_ptr() case ends up being a pointer itself.
>
> So, back to the drawing board, and I think back to the original position
> of "we don't support this".
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Fix for vblank on nvc0

2012-11-12 Thread Sven Joachim
On 2012-11-11 21:25 +0100, Maarten Lankhorst wrote:

> Op 11-11-12 19:35, Marcin Slusarz schreef:
>> On Sun, Nov 11, 2012 at 07:26:17PM +0100, Marcin Slusarz wrote:
>>> On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote:

 Op 06-11-12 15:48, Kelly Doran schreef:
> The vblank on nvc0 was not working correctly and would freeze X, I managed
> to track it down and fix it with some help from m.b.lankhorst, see
> https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.
>
 Reviewed-by: Maarten Lankhorst 

 I recommended the bar flush since nvd0 does as well, and there might be a 
 small race
 otherwise.

 Can this still get in before final 3.7 release?
>>> This patch breaks vblank here (nv92) completely.

Same here on nv86.

> Does removing the bar flush help?

No, it does not.

Cheers,
   Sven


[PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Rob Clark
On Mon, Nov 12, 2012 at 5:08 PM, Russell King - ARM Linux
 wrote:
> On Mon, Nov 12, 2012 at 01:58:32PM -0600, Rob Clark wrote:
>> On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
>>  wrote:
>> > On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
>> >> From: Rob Clark 
>> >>
>> >> A new atomic modeset/pageflip ioctl being developed in DRM requires
>> >> get_user() to work for 64bit types (in addition to just put_user()).
>> >
>> > NAK.
>> >
>> > (I did write a better email explaining all the ins and outs of why this
>> > won't work and why 64-bit get_user isn't possible, but my editor crapped
>> > out and lost all that well written message; I don't fancy typing it all
>> > out again.)
>> >
>> > Nevertheless,
>> > int test_ptr(unsigned int **v, unsigned int **p)
>> > {
>> > return get_user(*v, p);
>> > }
>> >
>> > produces a warning, and you can't get away from that if you stick 64-bit
>> > support into get_user().
>>
>> Actually, it seems like using 'register typeof(x) __r2 asm("r2");'
>> does avoid that warning..
>
> That seems to pass the checks I've done on it so far, and seems rather
> obvious (there's been a number of people looking at this, none of whom
> have come up with that solution).  Provided the final cast is kept
> (which is there to ensure proper typechecking), it seems like it might
> be a solution.

I'm sort of thinking maybe we want to change 'switch (sizeof(*(__p)))'
with 'switch (sizeof(typeof(x)))' in case someone ignores the compiler
warning when they try something like:

   uint32_t x;
   uint64_t *p = ...;
   get_user(x, p);

that was my one concern about 'register typeof(x) __r2 ...', but I
think just changing the switch condition is enough.  But maybe good to
have some eyes on in case there is something else I'm not thinking of.

BR,
-R

> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/2] NVIDIA Tegra DRM driver

2012-11-12 Thread Stephen Warren
On 11/12/2012 02:55 PM, Thierry Reding wrote:
> This second version of this patch series addresses all the comments
> received so far. Most notably it takes advantage of the debugfs helpers
> provided by the DRM core. Oddly enough this actually increases the line
> count, but that's because the helpers don't fit with the subdevices
> approach as implemented by this driver. However some quick discussions
> with Rob Clark showed that Tegra DRM is not special in this respect but
> other drivers may need the same functionality. Eventually the debugfs
> code could be reworked on top of helpers that are better suited at the
> design of embedded, multi-device DRM drivers.
> 
> Other than that there is some removal of code that was actually supposed
> to go into a later patch because it has dependencies that haven't been
> merged yet and some moving around of #defines and the device tree
> bindings documentation. Finally the driver now uses the DRM core's
> drm_compat_ioctl() instead of a custom and unimplemented (!) version.

The series,

Tested-by: Stephen Warren 

(on the Harmony board's HDMI output; I'll test other boards/outputs later).


[Bug 56405] Distorted graphics on Radeon HD 6620G

2012-11-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #18 from Michel D?nzer  ---
(In reply to comment #17)
> Can I just stop gdm set the environment and start gdm with systemctl?

I don't think so. It mainly needs to be in gnome-shell's environment, but I'm
not sure offhand how best to achieve that with your setup.


> --with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast \

You only need r600 and maybe swrast here.

> --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \

You can set this to an empty string.

> --enable-egl \
> --enable-gallium-egl \
> --with-egl-platforms=x11,drm \

Shouldn't need these.

> --enable-gbm \

Shouldn't need this.

> --enable-osmesa \

Don't need this.

> --enable-gles1 \
> --enable-gles2 \

Shouldn't need these.

> --enable-xa \
> --enable-vdpau "

Don't need these.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121112/0e8155af/attachment.html>


[PATCH v8 6/6] drm_modes: add of_videomode helpers

2012-11-12 Thread Steffen Trumtrar
Add helper to get drm_display_mode from devicetree.

Signed-off-by: Steffen Trumtrar 
---
 drivers/gpu/drm/drm_modes.c |   41 +
 include/drm/drmP.h  |5 +
 2 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 049624d..c77da59 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 /**
@@ -540,6 +541,46 @@ int videomode_to_display_mode(struct videomode *vm, struct 
drm_display_mode *dmo
 EXPORT_SYMBOL_GPL(videomode_to_display_mode);
 #endif

+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static void dump_drm_displaymode(struct drm_display_mode *m)
+{
+   pr_debug("drm_displaymode = %d %d %d %d %d %d %d %d %d\n",
+m->hdisplay, m->hsync_start, m->hsync_end, m->htotal,
+m->vdisplay, m->vsync_start, m->vsync_end, m->vtotal,
+m->clock);
+}
+
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ * 
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode 
*dmode,
+   int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, &vm, index);
+   if (ret)
+   return ret;
+
+   videomode_to_display_mode(&vm, dmode);
+
+   pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+   vm.vactive, np->name);
+   dump_drm_displaymode(dmode);
+
+   return 0;
+
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e9fa1e3..4f9c44e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #if defined(__alpha__) || defined(__powerpc__)
 #include/* For pte_wrprotect */
@@ -1457,6 +1458,10 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,

 extern int videomode_to_display_mode(struct videomode *vm,
 struct drm_display_mode *dmode);
+extern int of_get_drm_display_mode(struct device_node *np,
+  struct drm_display_mode *dmode,
+  int index);
+
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
 extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4



[PATCH v8 5/6] drm_modes: add videomode helpers

2012-11-12 Thread Steffen Trumtrar
Add conversion from videomode to drm_display_mode

Signed-off-by: Steffen Trumtrar 
---
 drivers/gpu/drm/drm_modes.c |   36 
 include/drm/drmP.h  |3 +++
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..049624d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 

 /**
  * drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int 
vdisplay, int vrefresh,
 }
 EXPORT_SYMBOL(drm_gtf_mode);

+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode 
*dmode)
+{
+   dmode->hdisplay = vm->hactive;
+   dmode->hsync_start = dmode->hdisplay + vm->hfront_porch;
+   dmode->hsync_end = dmode->hsync_start + vm->hsync_len;
+   dmode->htotal = dmode->hsync_end + vm->hback_porch;
+
+   dmode->vdisplay = vm->vactive;
+   dmode->vsync_start = dmode->vdisplay + vm->vfront_porch;
+   dmode->vsync_end = dmode->vsync_start + vm->vsync_len;
+   dmode->vtotal = dmode->vsync_end + vm->vback_porch;
+
+   dmode->clock = vm->pixelclock / 1000;
+
+   dmode->flags = 0;
+   if (vm->hah)
+   dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+   else
+   dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+   if (vm->vah)
+   dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+   else
+   dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+   if (vm->interlaced)
+   dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+   if (vm->doublescan)
+   dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+   drm_mode_set_name(dmode);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_display_mode);
+#endif
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..e9fa1e3 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 #if defined(__alpha__) || defined(__powerpc__)
 #include/* For pte_wrprotect */
 #endif
@@ -1454,6 +1455,8 @@ extern struct drm_display_mode *
 drm_mode_create_from_cmdline_mode(struct drm_device *dev,
  struct drm_cmdline_mode *cmd);

+extern int videomode_to_display_mode(struct videomode *vm,
+struct drm_display_mode *dmode);
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
 extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4



[PATCH v8 4/6] fbmon: add of_videomode helpers

2012-11-12 Thread Steffen Trumtrar
Add helper to get fb_videomode from devicetree.

Signed-off-by: Steffen Trumtrar 
---
 drivers/video/fbmon.c |   40 
 include/linux/fb.h|3 +++
 2 files changed, 43 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index d46ecef..c95be79 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1409,6 +1409,46 @@ int videomode_to_fb_videomode(struct videomode *vm, 
struct fb_videomode *fbmode)
 EXPORT_SYMBOL_GPL(videomode_to_fb_videomode);
 #endif

+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static void dump_fb_videomode(struct fb_videomode *m)
+{
+   pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u 
%u\n",
+m->xres, m->yres, m->refresh, m->pixclock, m->left_margin,
+m->right_margin, m->upper_margin, m->lower_margin,
+m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+   int index)
+{
+   struct videomode vm;
+   int ret;
+
+   ret = of_get_videomode(np, &vm, index);
+   if (ret)
+   return ret;
+
+   videomode_to_fb_videomode(&vm, fb);
+
+   pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+   vm.vactive, np->name);
+   dump_fb_videomode(fb);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif

 #else
 int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 46c665b..9892fd6 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 struct vm_area_struct;
 struct fb_info;
@@ -714,6 +716,7 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);

+extern int of_get_fb_videomode(struct device_node *np, struct fb_videomode 
*fb, int index);
 extern int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode 
*fbmode);

 /* drivers/video/modedb.c */
-- 
1.7.10.4



[PATCH v8 3/6] fbmon: add videomode helpers

2012-11-12 Thread Steffen Trumtrar
Add a function to convert from the generic videomode to a fb_videomode.

Signed-off-by: Steffen Trumtrar 
---
 drivers/video/fbmon.c |   37 +
 include/linux/fb.h|2 ++
 2 files changed, 39 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..d46ecef 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1373,6 +1373,43 @@ int fb_get_mode(int flags, u32 val, struct 
fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
 }
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode 
*fbmode)
+{
+   fbmode->xres = vm->hactive;
+   fbmode->left_margin = vm->hback_porch;
+   fbmode->right_margin = vm->hfront_porch;
+   fbmode->hsync_len = vm->hsync_len;
+
+   fbmode->yres = vm->vactive;
+   fbmode->upper_margin = vm->vback_porch;
+   fbmode->lower_margin = vm->vfront_porch;
+   fbmode->vsync_len = vm->vsync_len;
+
+   fbmode->pixclock = KHZ2PICOS(vm->pixelclock / 1000);
+
+   fbmode->sync = 0;
+   fbmode->vmode = 0;
+   if (vm->hah)
+   fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
+   if (vm->vah)
+   fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+   if (vm->interlaced)
+   fbmode->vmode |= FB_VMODE_INTERLACED;
+   if (vm->doublescan)
+   fbmode->vmode |= FB_VMODE_DOUBLE;
+   if (vm->de)
+   fbmode->sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT;
+   fbmode->refresh = 60;
+   fbmode->flag = 0;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_fb_videomode);
+#endif
+
+
 #else
 int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
 {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..46c665b 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -714,6 +714,8 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);

+extern int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode 
*fbmode);
+
 /* drivers/video/modedb.c */
 #define VESA_MODEDB_SIZE 34
 extern void fb_var_to_videomode(struct fb_videomode *mode,
-- 
1.7.10.4



[PATCH v8 2/6] video: add of helper for videomode

2012-11-12 Thread Steffen Trumtrar
This adds support for reading display timings from DT or/and convert one of 
those
timings to a videomode.
The of_display_timing implementation supports multiple children where each
property can have up to 3 values. All children are read into an array, that
can be queried.
of_get_videomode converts exactly one of that timings to a struct videomode.

Signed-off-by: Steffen Trumtrar 
Signed-off-by: Philipp Zabel 
---
 .../devicetree/bindings/video/display-timings.txt  |  107 +++
 drivers/video/Kconfig  |   13 ++
 drivers/video/Makefile |2 +
 drivers/video/of_display_timing.c  |  186 
 drivers/video/of_videomode.c   |   47 +
 include/linux/of_display_timings.h |   19 ++
 include/linux/of_videomode.h   |   15 ++
 7 files changed, 389 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 include/linux/of_display_timings.h
 create mode 100644 include/linux/of_videomode.h

diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
b/Documentation/devicetree/bindings/video/display-timings.txt
new file mode 100644
index 000..e22e2fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timings.txt
@@ -0,0 +1,107 @@
+display-timings bindings
+
+
+display-timings-node
+
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: the native mode for the display, in case multiple modes are
+   provided. When omitted, assume the first node is the native.
+
+timings-subnode
+---
+
+required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
+   in pixels
+   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
+   lines
+ - clock-frequency: displayclock in Hz
+
+optional properties:
+ - hsync-active : Hsync pulse is active low/high/ignored
+ - vsync-active : Vsync pulse is active low/high/ignored
+ - de-active : Data-Enable pulse is active low/high/ignored
+ - pixelclk-inverted : pixelclock is inverted/non-inverted/ignored
+ - interlaced (bool)
+ - doublescan (bool)
+
+All the optional properties that are not bool follow the following logic:
+<1> : high active
+<0> : low active
+omitted : not used on hardware
+
+There are different ways of describing the capabilities of a display. The 
devicetree
+representation corresponds to the one commonly found in datasheets for 
displays.
+If a display supports multiple signal timings, the native-mode can be 
specified.
+
+The parameters are defined as
+
+struct display_timing
+=
+
+  +--+-+--+---+
+  |  |?|  |   |
+  |  ||vback_porch |  |   |
+  |  |?|  |   |
+  +--###--+---+
+  |  #?#  |   |
+  |  #|#  |   |
+  |  hback   #|#  hfront  | hsync |
+  |   porch  #|   hactive  #  porch   |  len  |
+  |<>#<---+--->#<>|<->|
+  |  #|#  |   |
+  |  #|vactive #  |   |
+  |  #|#  |   |
+  |  #?#  |   |
+  +--###--+---+
+  |  |?|  |   |
+  |  ||vfront_porch|  |   |
+  |  |?|  |   |
+  +--+-+--+---+
+  |  |?|  |   |
+  |  ||vsync_len   |  |   |
+  |  |?|  |   |
+  +--+-+--+---+
+
+
+Example:
+
+   display-timings {
+   native-mode = <&timing0>;
+   timing0: 1920p24 {
+   /* 1920x1080p24 */
+   clock-frequency = <52000

[PATCH v8 1/6] video: add display_timing and videomode

2012-11-12 Thread Steffen Trumtrar
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.

Every timing parameter can be specified as a single value or a range
.

Also, add helper functions to convert from display timings to a generic 
videomode
structure. This videomode can then be converted to the corresponding subsystem
mode representation (e.g. fb_videomode).

Signed-off-by: Steffen Trumtrar 
---
 drivers/video/Kconfig  |6 
 drivers/video/Makefile |2 ++
 drivers/video/display_timing.c |   22 +
 drivers/video/videomode.c  |   45 ++
 include/linux/display_timing.h |   69 
 include/linux/videomode.h  |   39 +++
 6 files changed, 183 insertions(+)
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/linux/display_timing.h
 create mode 100644 include/linux/videomode.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
  This framework adds support for low-level control of the video 
  output switch.

+config DISPLAY_TIMING
+   bool
+
+config VIDEOMODE
+   bool
+
 menuconfig FB
tristate "Support for frame buffer devices"
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL)  += vfb.o

 #video output switch sysfs driver
 obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..04b7b69
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,22 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , 
Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include 
+#include 
+
+void display_timings_release(struct display_timings *disp)
+{
+   if (disp->timings) {
+   unsigned int i;
+
+   for (i = 0; i < disp->num_timings; i++)
+   kfree(disp->timings[i]);
+   kfree(disp->timings);
+   }
+   kfree(disp);
+}
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..087374a
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,45 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , 
Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
+ unsigned int index)
+{
+   struct display_timing *dt;
+
+   dt = display_timings_get(disp, index);
+   if (!dt)
+   return -EINVAL;
+
+   vm->pixelclock = display_timing_get_value(&dt->pixelclock, 0);
+   vm->hactive = display_timing_get_value(&dt->hactive, 0);
+   vm->hfront_porch = display_timing_get_value(&dt->hfront_porch, 0);
+   vm->hback_porch = display_timing_get_value(&dt->hback_porch, 0);
+   vm->hsync_len = display_timing_get_value(&dt->hsync_len, 0);
+
+   vm->vactive = display_timing_get_value(&dt->vactive, 0);
+   vm->vfront_porch = display_timing_get_value(&dt->vfront_porch, 0);
+   vm->vback_porch = display_timing_get_value(&dt->vback_porch, 0);
+   vm->vsync_len = display_timing_get_value(&dt->vsync_len, 0);
+
+   vm->vah = dt->vsync_pol_active;
+   vm->hah = dt->hsync_pol_active;
+   vm->de = dt->de_pol_active;
+   vm->pixelclk_pol = dt->pixelclk_pol;
+
+   vm->interlaced = dt->interlaced;
+   vm->doublescan = dt->doublescan;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_from_timing);
diff --git a/include/linux/display_timing.h b/include/linux/display_timing.h
new file mode 100644
index 000..0ed2a1e
--- /dev/null
+++ b/include/linux/display_timing.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2012 Steffen Trumtrar 
+ *
+ * description of display timings
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_DISPLAY_TIMINGS_H
+#define __LINUX_DISPLAY_TIMINGS_H
+
+#include 
+
+struct timing_entry {
+   u32 min;
+   u32 typ;
+   u32 max;
+};
+
+struct display_timing {
+   struct timing_entry pixelclock;
+
+   struct timing_entry hactive;
+   struct timing_entry hfront_porch;
+   struct timing_entry hback_porch;
+   struct timing_entry hsync_len;
+
+   struct timing_entry vactive;
+   struct timing_entry vfront_porch;
+   struct timing_entry vback_porch;
+   struct timing_entry

[PATCH v8 0/6] of: add display helper

2012-11-12 Thread Steffen Trumtrar
Hi!

This is v8 of the display helper series

Changes since v7:
- move of_xxx to drivers/video
- remove non-binding documentation from display-timings.txt
- squash display_timings and videomode in one patch
- misc minor fixes

Regards,
Steffen


Steffen Trumtrar (6):
  video: add display_timing and videomode
  video: add of helper for videomode
  fbmon: add videomode helpers
  fbmon: add of_videomode helpers
  drm_modes: add videomode helpers
  drm_modes: add of_videomode helpers

 .../devicetree/bindings/video/display-timings.txt  |  107 +++
 drivers/gpu/drm/drm_modes.c|   77 
 drivers/video/Kconfig  |   19 ++
 drivers/video/Makefile |4 +
 drivers/video/display_timing.c |   22 +++
 drivers/video/fbmon.c  |   77 
 drivers/video/of_display_timing.c  |  186 
 drivers/video/of_videomode.c   |   47 +
 drivers/video/videomode.c  |   45 +
 include/drm/drmP.h |8 +
 include/linux/display_timing.h |   69 
 include/linux/fb.h |5 +
 include/linux/of_display_timings.h |   19 ++
 include/linux/of_videomode.h   |   15 ++
 include/linux/videomode.h  |   39 
 15 files changed, 739 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/linux/display_timing.h
 create mode 100644 include/linux/of_display_timings.h
 create mode 100644 include/linux/of_videomode.h
 create mode 100644 include/linux/videomode.h

-- 
1.7.10.4



Re: [PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Rob Clark
On Mon, Nov 12, 2012 at 5:53 PM, Russell King - ARM Linux
 wrote:
> On Mon, Nov 12, 2012 at 05:33:41PM -0600, Rob Clark wrote:
>> I'm sort of thinking maybe we want to change 'switch (sizeof(*(__p)))'
>> with 'switch (sizeof(typeof(x)))' in case someone ignores the compiler
>> warning when they try something like:
>
> Definitely not.  Ttype of access is controlled by the pointer, not by the
> size of what it's being assigned to.  Switching that around is likely to
> break stuff hugely.  Consider this:
>
> unsigned char __user *p;
> int val;
>
> get_user(val, p);
>
> If the pointer type is used to determine the access size, a char will be
> accessed.  This is legal - because we end up assigning an unsigned character
> to an int.
>
> If the size of the destination was used, we'd access an int instead, which
> is larger than the pointer, and probably the wrong thing to do anyway.
>
> Think of get_user(a, b) as being a special accessor having the ultimate
> semantics of: "a = *b;" but done in a safe way with error checking.
>
>>uint32_t x;
>>uint64_t *p = ...;
>>get_user(x, p);
>>
>> that was my one concern about 'register typeof(x) __r2 ...', but I
>> think just changing the switch condition is enough.  But maybe good to
>> have some eyes on in case there is something else I'm not thinking of.
>
> And what should happen in the above is exactly the same as what happens
> if you do:
>
> x = *p;
>
> with those types.  For ARM, that would be a 64-bit access (if the
> compiler decides not to optimize away the upper 32-bit access) followed
> by a narrowing cast down to 32-bit.  With get_user() of course, there's
> no option not to optimize it away.
>
> However, this _does_ reveal a bug with your approach.  With sizeof(*p)
> being 8, and the type of __r2 being a 32-bit quantity, the compiler will
> choose the 64-bit accessor, which will corrupt r3 - and the compiler
> won't know that r3 has been corrupted.

right, that is what I was worried about..  but what about something
along the lines of:

case 8: {   \
if (sizeof(x) < 8)  \
__get_user_x(__r2, __p, __e, __l, 4);   \
else\
__get_user_x(__r2, __p, __e, __l, 8);   \
break;  \
}   \

maybe we need a special variant of __get_user_8() instead to get the
right 32bits on big vs little endian systems, but I think something
roughly along these lines could work.

Or maybe in sizeof(x)<8 case, we just __get_user_bad()..  I'm not 100%
sure on whether this is supposed to be treated as an error case at
compile time or not.

BR,
-R

> That's too unsafe.
>
> I just tried a variant of your approach, but got lots of warnings again:
> register unsigned long long __r2 asm("r2");
> __get_user_x(__r2, __p, __e, 8, "lr");
> x = (typeof(*(__p))) ((typeof(x))__r2);
> because typeof(x) in the test_ptr() case ends up being a pointer itself.
>
> So, back to the drawing board, and I think back to the original position
> of "we don't support this".
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 6/6] staging: drm/imx: Remove 300ms delay after memory reset

2012-11-12 Thread Sascha Hauer
From: Philipp Zabel 

This has been added once, but does not seem to be necessary. Tested
on i.MX51 and i.MX6.

Signed-off-by: Philipp Zabel 
Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/ipu-v3/ipu-common.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index d871bb6..147c3e9 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -673,8 +673,6 @@ static int ipu_reset(struct ipu_soc *ipu)
cpu_relax();
}

-   mdelay(300);
-
return 0;
 }

-- 
1.7.10.4



[PATCH 5/6] staging: drm/imx: Add pinctrl support to parallel display driver

2012-11-12 Thread Sascha Hauer
To allow the iomux to be configured for the display.

Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/parallel-display.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index 9b51d73..324283c 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "imx-drm.h"

@@ -195,11 +196,20 @@ static int __devinit imx_pd_probe(struct platform_device 
*pdev)
struct imx_parallel_display *imxpd;
int ret;
const char *fmt;
+   struct pinctrl *pinctrl;

imxpd = devm_kzalloc(&pdev->dev, sizeof(*imxpd), GFP_KERNEL);
if (!imxpd)
return -ENOMEM;

+   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+   if (IS_ERR(pinctrl)) {
+   ret = PTR_ERR(pinctrl);
+   dev_warn(&pdev->dev, "pinctrl_get_select_default failed with 
%d",
+   ret);
+   return ret;
+   }
+
edidp = of_get_property(np, "edid", &imxpd->edid_len);
if (edidp)
imxpd->edid = kmemdup(edidp, imxpd->edid_len, GFP_KERNEL);
-- 
1.7.10.4



[PATCH 4/6] staging: drm/imx: Add ipu_cpmem_set_yuv_interleaved()

2012-11-12 Thread Sascha Hauer
From: Philipp Zabel 

For configuring interleaved formats.

Signed-off-by: Philipp Zabel 
Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |1 +
 drivers/staging/imx-drm/ipu-v3/ipu-common.c |   17 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h 
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
index 74158dd..22c1196 100644
--- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -293,6 +293,7 @@ static inline void ipu_cpmem_interlaced_scan(struct 
ipu_ch_param *p,

 void ipu_cpmem_set_yuv_planar(struct ipu_ch_param __iomem *p, u32 pixel_format,
int stride, int height);
+void ipu_cpmem_set_yuv_interleaved(struct ipu_ch_param *p, u32 pixel_format);
 void ipu_cpmem_set_yuv_planar_full(struct ipu_ch_param __iomem *p,
u32 pixel_format, int stride, int u_offset, int v_offset);
 int ipu_cpmem_set_fmt(struct ipu_ch_param __iomem *cpmem, u32 pixelformat);
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index a5cec0e..d871bb6 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -225,6 +225,23 @@ int ipu_cpmem_set_format_passthrough(struct ipu_ch_param 
__iomem *p,
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_format_passthrough);

+void ipu_cpmem_set_yuv_interleaved(struct ipu_ch_param *p, u32 pixel_format)
+{
+   switch (pixel_format) {
+   case V4L2_PIX_FMT_UYVY:
+   ipu_ch_param_write_field(p, IPU_FIELD_BPP, 3);/* bits/pixel 
*/
+   ipu_ch_param_write_field(p, IPU_FIELD_PFS, 0xA);  /* pix format 
*/
+   ipu_ch_param_write_field(p, IPU_FIELD_NPB, 31);   /* burst size 
*/
+   break;
+   case V4L2_PIX_FMT_YUYV:
+   ipu_ch_param_write_field(p, IPU_FIELD_BPP, 3);/* bits/pixel 
*/
+   ipu_ch_param_write_field(p, IPU_FIELD_PFS, 0x8);  /* pix format 
*/
+   ipu_ch_param_write_field(p, IPU_FIELD_NPB, 31);   /* burst size 
*/
+   break;
+   }
+}
+EXPORT_SYMBOL_GPL(ipu_cpmem_set_yuv_interleaved);
+
 void ipu_cpmem_set_yuv_planar_full(struct ipu_ch_param __iomem *p,
u32 pixel_format, int stride, int u_offset, int v_offset)
 {
-- 
1.7.10.4



[PATCH 3/6] staging: drm/imx: silence ipu_crtc_dpms debug message

2012-11-12 Thread Sascha Hauer
From: Philipp Zabel 

It's for debugging only, so use dev_dbg.

Signed-off-by: Philipp Zabel 
Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/ipuv3-crtc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 78d3eda..7e85c59 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -116,7 +116,7 @@ static void ipu_crtc_dpms(struct drm_crtc *crtc, int mode)
 {
struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);

-   dev_info(ipu_crtc->dev, "%s mode: %d\n", __func__, mode);
+   dev_dbg(ipu_crtc->dev, "%s mode: %d\n", __func__, mode);

switch (mode) {
case DRM_MODE_DPMS_ON:
-- 
1.7.10.4



[PATCH 2/6] staging: drm/imx: Add YVU420 support to i.MX IPUv3 base driver

2012-11-12 Thread Sascha Hauer
From: Philipp Zabel 

Signed-off-by: Philipp Zabel 
Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/ipu-v3/ipu-common.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index 04f6aba..a5cec0e 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -234,6 +234,11 @@ void ipu_cpmem_set_yuv_planar_full(struct ipu_ch_param 
__iomem *p,
ipu_ch_param_write_field(p, IPU_FIELD_UBO, u_offset / 8);
ipu_ch_param_write_field(p, IPU_FIELD_VBO, v_offset / 8);
break;
+   case V4L2_PIX_FMT_YVU420:
+   ipu_ch_param_write_field(p, IPU_FIELD_SLUV, (stride / 2) - 1);
+   ipu_ch_param_write_field(p, IPU_FIELD_UBO, v_offset / 8);
+   ipu_ch_param_write_field(p, IPU_FIELD_VBO, u_offset / 8);
+   break;
}
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_yuv_planar_full);
@@ -246,10 +251,11 @@ void ipu_cpmem_set_yuv_planar(struct ipu_ch_param __iomem 
*p, u32 pixel_format,

switch (pixel_format) {
case V4L2_PIX_FMT_YUV420:
+   case V4L2_PIX_FMT_YVU420:
uv_stride = stride / 2;
u_offset = stride * height;
v_offset = u_offset + (uv_stride * height / 2);
-   ipu_cpmem_set_yuv_planar_full(p, V4L2_PIX_FMT_YUV420, stride,
+   ipu_cpmem_set_yuv_planar_full(p, pixel_format, stride,
u_offset, v_offset);
break;
}
@@ -307,6 +313,7 @@ int ipu_cpmem_set_fmt(struct ipu_ch_param __iomem *cpmem, 
u32 pixelformat)
 {
switch (pixelformat) {
case V4L2_PIX_FMT_YUV420:
+   case V4L2_PIX_FMT_YVU420:
/* pix format */
ipu_ch_param_write_field(cpmem, IPU_FIELD_PFS, 2);
/* burst size */
@@ -369,6 +376,7 @@ int ipu_cpmem_set_image(struct ipu_ch_param __iomem *cpmem,

switch (pix->pixelformat) {
case V4L2_PIX_FMT_YUV420:
+   case V4L2_PIX_FMT_YVU420:
y_offset = Y_OFFSET(pix, image->rect.left, image->rect.top);
u_offset = U_OFFSET(pix, image->rect.left,
image->rect.top) - y_offset;
@@ -414,6 +422,7 @@ enum ipu_color_space ipu_pixelformat_to_colorspace(u32 
pixelformat)
 {
switch (pixelformat) {
case V4L2_PIX_FMT_YUV420:
+   case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YUYV:
return IPUV3_COLORSPACE_YUV;
-- 
1.7.10.4



[PATCH 1/6] staging: drm/imx: Fix YUYV support in i.MX IPUv3 base driver

2012-11-12 Thread Sascha Hauer
From: Michael Olbrich 

YVYU is not supported by the IPU, so remove partial handling
of this format and replace it with YUYV which is supported.

Signed-off-by: Michael Olbrich 
Signed-off-by: Philipp Zabel 
Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/ipu-v3/ipu-common.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index f381960..04f6aba 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -380,6 +380,7 @@ int ipu_cpmem_set_image(struct ipu_ch_param __iomem *cpmem,
ipu_cpmem_set_buffer(cpmem, 0, image->phys + y_offset);
break;
case V4L2_PIX_FMT_UYVY:
+   case V4L2_PIX_FMT_YUYV:
ipu_cpmem_set_buffer(cpmem, 0, image->phys +
image->rect.left * 2 +
image->rect.top * image->pix.bytesperline);
@@ -414,7 +415,7 @@ enum ipu_color_space ipu_pixelformat_to_colorspace(u32 
pixelformat)
switch (pixelformat) {
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_UYVY:
-   case V4L2_PIX_FMT_YVYU:
+   case V4L2_PIX_FMT_YUYV:
return IPUV3_COLORSPACE_YUV;
case V4L2_PIX_FMT_RGB32:
case V4L2_PIX_FMT_BGR32:
-- 
1.7.10.4



[PATCH] staging drm/imx: updates

2012-11-12 Thread Sascha Hauer
The following contains some assorted updates to the i.MX drm driver
for the next merge window.

Sascha


Michael Olbrich (1):
  staging: drm/imx: Fix YUYV support in i.MX IPUv3 base driver

Philipp Zabel (4):
  staging: drm/imx: Add YVU420 support to i.MX IPUv3 base driver
  staging: drm/imx: silence ipu_crtc_dpms debug message
  staging: drm/imx: Add ipu_cpmem_set_yuv_interleaved()
  staging: drm/imx: Remove 300ms delay after memory reset

Sascha Hauer (1):
  staging: drm/imx: Add pinctrl support to parallel display driver

 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |1 +
 drivers/staging/imx-drm/ipu-v3/ipu-common.c |   33 +++
 drivers/staging/imx-drm/ipuv3-crtc.c|2 +-
 drivers/staging/imx-drm/parallel-display.c  |   10 
 4 files changed, 41 insertions(+), 5 deletions(-)


Re: [PATCH v2 0/2] NVIDIA Tegra DRM driver

2012-11-12 Thread Stephen Warren
On 11/12/2012 02:55 PM, Thierry Reding wrote:
> This second version of this patch series addresses all the comments
> received so far. Most notably it takes advantage of the debugfs helpers
> provided by the DRM core. Oddly enough this actually increases the line
> count, but that's because the helpers don't fit with the subdevices
> approach as implemented by this driver. However some quick discussions
> with Rob Clark showed that Tegra DRM is not special in this respect but
> other drivers may need the same functionality. Eventually the debugfs
> code could be reworked on top of helpers that are better suited at the
> design of embedded, multi-device DRM drivers.
> 
> Other than that there is some removal of code that was actually supposed
> to go into a later patch because it has dependencies that haven't been
> merged yet and some moving around of #defines and the device tree
> bindings documentation. Finally the driver now uses the DRM core's
> drm_compat_ioctl() instead of a custom and unimplemented (!) version.

The series,

Tested-by: Stephen Warren 

(on the Harmony board's HDMI output; I'll test other boards/outputs later).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Rob Clark
On Mon, Nov 12, 2012 at 5:08 PM, Russell King - ARM Linux
 wrote:
> On Mon, Nov 12, 2012 at 01:58:32PM -0600, Rob Clark wrote:
>> On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
>>  wrote:
>> > On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
>> >> From: Rob Clark 
>> >>
>> >> A new atomic modeset/pageflip ioctl being developed in DRM requires
>> >> get_user() to work for 64bit types (in addition to just put_user()).
>> >
>> > NAK.
>> >
>> > (I did write a better email explaining all the ins and outs of why this
>> > won't work and why 64-bit get_user isn't possible, but my editor crapped
>> > out and lost all that well written message; I don't fancy typing it all
>> > out again.)
>> >
>> > Nevertheless,
>> > int test_ptr(unsigned int **v, unsigned int **p)
>> > {
>> > return get_user(*v, p);
>> > }
>> >
>> > produces a warning, and you can't get away from that if you stick 64-bit
>> > support into get_user().
>>
>> Actually, it seems like using 'register typeof(x) __r2 asm("r2");'
>> does avoid that warning..
>
> That seems to pass the checks I've done on it so far, and seems rather
> obvious (there's been a number of people looking at this, none of whom
> have come up with that solution).  Provided the final cast is kept
> (which is there to ensure proper typechecking), it seems like it might
> be a solution.

I'm sort of thinking maybe we want to change 'switch (sizeof(*(__p)))'
with 'switch (sizeof(typeof(x)))' in case someone ignores the compiler
warning when they try something like:

   uint32_t x;
   uint64_t *p = ...;
   get_user(x, p);

that was my one concern about 'register typeof(x) __r2 ...', but I
think just changing the switch condition is enough.  But maybe good to
have some eyes on in case there is something else I'm not thinking of.

BR,
-R

> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)

2012-11-12 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #28 from Alexandre Demers  ---
Alex, a simple question: you said bit 0 in EVERGREEN_CRTC_CONTROL stops the
CRTC sync. With the culprit commit, when is it set? I mean, I had a quick look
in the driver's code and I couldn't find it. When going in suspend state,
shouldn't it be set to 0? Then, on resume, shouldn't it be set to 1? I may just
have missed it, but could this be something missing? Same questions goes for
GPU soft reset.

Before the culprit commit, we were setting bit 0 to 0 on stop and setting it
back to 1 on resume, which was working great. Why aren't we doing it anymore
when suspending and resuming?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Fix for vblank on nvc0

2012-11-12 Thread Kelly Doran
I had Sven test this patch... he said it works.  I think chipset
number test was executing code that we thought was only either 0x50 or
0xc0, but was actually more specific with things like 0x92.

On Sun, Nov 11, 2012 at 2:25 PM, Maarten Lankhorst
 wrote:
> Op 11-11-12 19:35, Marcin Slusarz schreef:
>> On Sun, Nov 11, 2012 at 07:26:17PM +0100, Marcin Slusarz wrote:
>>> On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote:
>>>>
>>>> Op 06-11-12 15:48, Kelly Doran schreef:
>>>>> The vblank on nvc0 was not working correctly and would freeze X, I managed
>>>>> to track it down and fix it with some help from m.b.lankhorst, see
>>>>> https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.
>>>>>
>>>> Reviewed-by: Maarten Lankhorst 
>>>>
>>>> I recommended the bar flush since nvd0 does as well, and there might be a 
>>>> small race
>>>> otherwise.
>>>>
>>>> Can this still get in before final 3.7 release?
>>> This patch breaks vblank here (nv92) completely.
> Does removing the bar flush help?
>
> ~Maarte
-- next part --
A non-text attachment was scrubbed...
Name: vblank-fix1.patch
Type: application/octet-stream
Size: 1474 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121112/827f06ae/attachment-0001.obj>


[PATCH] HACK: drm: Allow encoders to be reenabled

2012-11-12 Thread Daniel Vetter
On Mon, Nov 12, 2012 at 3:25 PM, Rob Clark  wrote:
> On Mon, Nov 12, 2012 at 8:17 AM, Daniel Vetter  wrote:
>> On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark  wrote:
>>> I do prefer that, at least on lastclose, that we revert properties
>>> back to default/initial state, so that userspace unaware of some new
>>> or driver specific properties doesn't get confused.
>>>
>>> But dpms is a bit of an odd-duck property.  Probably we need to split
>>> out the property value "what userspace wants it to be" from the
>>> current state which could change temporarily as the modeset is
>>> applied.  At the end of the modeset the driver should somehow try to
>>> put things back to the state that userspace wants according to the
>>> dpms property.
>>
>> That could result into some serious flicker if e.g. we enable things
>> but dpms is off, so we switch things off. Then userspace does a dpms
>> on again after all modesets have completed. iirc some desktops do this
>> to fake less flickery modeset, but it seems to only result in more
>> (since userspace doesn't know which outputs to disable and which are
>> unaffected by a given modeset changes). Imo simply updating the dpms
>> property (both the internal tracking in the helper, but also the
>> userspace visible part) is the best option. At least it's what intel
>> now does with it's own modeset code ...
>
> no, I mean at the end of modeset we should replace dpms(ON) w/
> dpms(what_userspace_set_connector_property_to)

Oh, for atomic modeset that's definitely the better option (we simply
need code to be clever enought to not enable stuff if it's not
required). But there's the pesky problem of what should happen with
the legacy modeset stuff, which I've thought is the topic here ...

> well, that works unless userspace assumes that the modeset implicitly
> turns dpms(ON).. then we have problems.

Presume it does assume that, since that's how the code currently
works. Save that the userspace visible dpms property doesn't reflect
reality at all.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[PATCH] HACK: drm: Allow encoders to be reenabled

2012-11-12 Thread Daniel Vetter
On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark  wrote:
> I do prefer that, at least on lastclose, that we revert properties
> back to default/initial state, so that userspace unaware of some new
> or driver specific properties doesn't get confused.
>
> But dpms is a bit of an odd-duck property.  Probably we need to split
> out the property value "what userspace wants it to be" from the
> current state which could change temporarily as the modeset is
> applied.  At the end of the modeset the driver should somehow try to
> put things back to the state that userspace wants according to the
> dpms property.

That could result into some serious flicker if e.g. we enable things
but dpms is off, so we switch things off. Then userspace does a dpms
on again after all modesets have completed. iirc some desktops do this
to fake less flickery modeset, but it seems to only result in more
(since userspace doesn't know which outputs to disable and which are
unaffected by a given modeset changes). Imo simply updating the dpms
property (both the internal tracking in the helper, but also the
userspace visible part) is the best option. At least it's what intel
now does with it's own modeset code ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[PATCH] drm/i915: Optimize DIV_ROUND_CLOSEST call

2012-11-12 Thread Jean Delvare
On Mon, 12 Nov 2012 15:02:26 +0100, Daniel Vetter wrote:
> On Mon, Nov 12, 2012 at 02:18:02PM +0100, Jean Delvare wrote:
> > DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
> > dealing with unsigned dividends. This optimization rips 32 bytes of
> > binary code on x86_64.
> > 
> > Signed-off-by: Jean Delvare 
> > Cc: Guenter Roeck 
> > Cc: Andrew Morton 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > ---
> > Already sent on: 2012-09-03.
> > 
> > Daniel, I think we can safely assume ia_freq can't be negative?
> 
> Queued for -next, thanks for the patch. Sorry that I've missed it on first
> submission.

No problem, thanks :)

-- 
Jean Delvare


[PATCH 01/10] drm/radeon: allow move_notify to be called without reservation

2012-11-12 Thread Maarten Lankhorst
Op 12-11-12 15:00, Maarten Lankhorst schreef:
> The few places that care should have those checks instead.
> This allow destruction of bo backed memory without a reservation.
Forgot to add, this patch series depends on the previous sync_obj_arg removal 
patches, and cpu_writers -EBUSY change.

~Maarten


Re: Fix for vblank on nvc0

2012-11-12 Thread Marcin Slusarz
On Mon, Nov 12, 2012 at 06:14:05AM -0600, Kelly Doran wrote:
> Okay I have added two patches, one of them should fix the problem...
> 

vblank-fix1.patch works, thanks.

Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/i915: Optimize DIV_ROUND_CLOSEST call

2012-11-12 Thread Daniel Vetter
On Mon, Nov 12, 2012 at 02:18:02PM +0100, Jean Delvare wrote:
> DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
> dealing with unsigned dividends. This optimization rips 32 bytes of
> binary code on x86_64.
> 
> Signed-off-by: Jean Delvare 
> Cc: Guenter Roeck 
> Cc: Andrew Morton 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> ---
> Already sent on: 2012-09-03.
> 
> Daniel, I think we can safely assume ia_freq can't be negative?

Queued for -next, thanks for the patch. Sorry that I've missed it on first
submission.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[PATCH 10/10] drm/ttm: remove reliance on ttm_bo_wait_unreserved

2012-11-12 Thread Maarten Lankhorst
Slightly makes things more complicated, but instead of testing for
unreserved and starting over, try to block and acquire reservation
first, then start over.

This maps a lot better to a blocking acquire operation.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c  | 19 +---
 drivers/gpu/drm/ttm/ttm_bo.c   | 33 +++--
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 53 --
 include/drm/ttm/ttm_bo_driver.h| 24 +++
 4 files changed, 89 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 7b9364b..6f58604 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -321,6 +321,7 @@ validate_init(struct nouveau_channel *chan, struct drm_file 
*file_priv,
uint32_t sequence;
int trycnt = 0;
int ret, i;
+   struct nouveau_bo *res_bo = NULL;

sequence = atomic_add_return(1, &drm->ttm.validate_sequence);
 retry:
@@ -341,6 +342,11 @@ retry:
return -ENOENT;
}
nvbo = gem->driver_private;
+   if (nvbo == res_bo) {
+   res_bo = NULL;
+   drm_gem_object_unreference_unlocked(gem);
+   continue;
+   }

if (nvbo->reserved_by && nvbo->reserved_by == file_priv) {
NV_ERROR(drm, "multiple instances of buffer %d on "
@@ -353,15 +359,18 @@ retry:
ret = ttm_bo_reserve(&nvbo->bo, true, false, true, sequence);
if (ret) {
validate_fini(op, NULL);
-   if (unlikely(ret == -EAGAIN))
-   ret = ttm_bo_wait_unreserved(&nvbo->bo, true);
-   drm_gem_object_unreference_unlocked(gem);
+   if (unlikely(ret == -EAGAIN)) {
+   ret = ttm_bo_reserve_slowpath(&nvbo->bo, true,
+ sequence);
+   if (!ret)
+   res_bo = nvbo;
+   }
if (unlikely(ret)) {
+   drm_gem_object_unreference_unlocked(gem);
if (ret != -ERESTARTSYS)
NV_ERROR(drm, "fail reserve\n");
return ret;
}
-   goto retry;
}

b->user_priv = (uint64_t)(unsigned long)nvbo;
@@ -383,6 +392,8 @@ retry:
validate_fini(op, NULL);
return -EINVAL;
}
+   if (nvbo == res_bo)
+   goto retry;
}

return 0;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e57dae5..bc90f6b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -166,7 +166,8 @@ static void ttm_bo_release_list(struct kref *list_kref)
ttm_mem_global_free(bdev->glob->mem_glob, acc_size);
 }

-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, bool interruptible)
+static int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo,
+ bool interruptible)
 {
if (interruptible) {
return wait_event_interruptible(bo->event_queue,
@@ -176,7 +177,6 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, 
bool interruptible)
return 0;
}
 }
-EXPORT_SYMBOL(ttm_bo_wait_unreserved);

 void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
 {
@@ -320,6 +320,35 @@ int ttm_bo_reserve(struct ttm_buffer_object *bo,
return ret;
 }

+int ttm_bo_reserve_slowpath(struct ttm_buffer_object *bo,
+   bool interruptible, uint32_t sequence)
+{
+   struct ttm_bo_global *glob = bo->glob;
+   int put_count = 0;
+   int ret;
+
+   WARN_ON(!list_empty_careful(&bo->ddestroy));
+
+   ret = ttm_bo_reserve_nolru(bo, interruptible, false, false, 0);
+   if (likely(ret == 0)) {
+   /**
+* Wake up waiters that may need to recheck for deadlock,
+* since we unset seq_valid in ttm_bo_reserve_nolru
+*/
+   bo->val_seq = sequence;
+   bo->seq_valid = true;
+   wake_up_all(&bo->event_queue);
+
+   spin_lock(&glob->lru_lock);
+   put_count = ttm_bo_del_from_lru(bo);
+   spin_unlock(&glob->lru_lock);
+   ttm_bo_list_ref_sub(bo, put_count, true);
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL(ttm_bo_reserve_slowpath);
+
 void ttm_bo_unreserve_locked(struct ttm_buffer_object *bo)
 {
ttm_bo_add_to_lru(bo);
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm

[PATCH 09/10] drm/ttm: remove lru_lock around ttm_bo_reserve

2012-11-12 Thread Maarten Lankhorst
There should no longer be assumptions that reserve will always succeed
with the lru lock held, so we can safely break the whole atomic
reserve/lru thing. As a bonus this fixes most lockdep annotations for
reservations.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_bo.c   | 50 ++
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  2 +-
 include/drm/ttm/ttm_bo_driver.h| 17 ++--
 3 files changed, 37 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a760178..e57dae5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -221,14 +221,13 @@ int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
return put_count;
 }

-int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
+int ttm_bo_reserve_nolru(struct ttm_buffer_object *bo,
  bool interruptible,
  bool no_wait, bool use_sequence, uint32_t sequence)
 {
-   struct ttm_bo_global *glob = bo->glob;
int ret;

-   while (unlikely(atomic_cmpxchg(&bo->reserved, 0, 1) != 0)) {
+   while (unlikely(atomic_xchg(&bo->reserved, 1) != 0)) {
/**
 * Deadlock avoidance for multi-bo reserving.
 */
@@ -249,25 +248,36 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
if (no_wait)
return -EBUSY;

-   spin_unlock(&glob->lru_lock);
ret = ttm_bo_wait_unreserved(bo, interruptible);
-   spin_lock(&glob->lru_lock);

if (unlikely(ret))
return ret;
}

if (use_sequence) {
+   bool wake_up = false;
/**
 * Wake up waiters that may need to recheck for deadlock,
 * if we decreased the sequence number.
 */
if (unlikely((bo->val_seq - sequence < (1 << 31))
 || !bo->seq_valid))
-   wake_up_all(&bo->event_queue);
+   wake_up = true;

+   /*
+* In the worst case with memory ordering these values can be
+* seen in the wrong order. However since we call wake_up_all
+* in that case, this will hopefully not pose a problem,
+* and the worst case would only cause someone to accidentally
+* hit -EAGAIN in ttm_bo_reserve when they see old value of
+* val_seq. However this would only happen if seq_valid was
+* written before val_seq was, and just means some slightly
+* increased cpu usage
+*/
bo->val_seq = sequence;
bo->seq_valid = true;
+   if (wake_up)
+   wake_up_all(&bo->event_queue);
} else {
bo->seq_valid = false;
}
@@ -298,14 +308,14 @@ int ttm_bo_reserve(struct ttm_buffer_object *bo,

WARN_ON(!atomic_read(&bo->kref.refcount));

-   spin_lock(&glob->lru_lock);
-   ret = ttm_bo_reserve_locked(bo, interruptible, no_wait, use_sequence,
+   ret = ttm_bo_reserve_nolru(bo, interruptible, no_wait, use_sequence,
sequence);
-   if (likely(ret == 0))
+   if (likely(ret == 0)) {
+   spin_lock(&glob->lru_lock);
put_count = ttm_bo_del_from_lru(bo);
-   spin_unlock(&glob->lru_lock);
-
-   ttm_bo_list_ref_sub(bo, put_count, true);
+   spin_unlock(&glob->lru_lock);
+   ttm_bo_list_ref_sub(bo, put_count, true);
+   }

return ret;
 }
@@ -486,7 +496,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
int ret;

spin_lock(&glob->lru_lock);
-   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
if (!ret) {
spin_lock(&bdev->fence_lock);
ret = ttm_bo_wait(bo, false, false, true);
@@ -631,8 +641,14 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
kref_get(&nentry->list_kref);
}

-   ret = ttm_bo_reserve_locked(entry, false, !remove_all,
-   false, 0);
+   ret = ttm_bo_reserve_nolru(entry, false, true, false, 0);
+   if (remove_all && ret) {
+   spin_unlock(&glob->lru_lock);
+   ret = ttm_bo_reserve_nolru(entry, false, false,
+  false, 0);
+   spin_lock(&glob->lru_lock);
+   }
+
if (ret)
spin_unlock(&glob->lru_lock);
else
@@ -783,7 +799,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,

s

[PATCH 08/10] drm/ttm: cope with reserved buffers on lru list in ttm_mem_evict_first

2012-11-12 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b9c26a5..a760178 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -779,26 +779,21 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
struct ttm_buffer_object *bo;
-   int ret, put_count = 0;
+   int ret = -EBUSY, put_count = 0;

spin_lock(&glob->lru_lock);
-   if (list_empty(&man->lru)) {
-   spin_unlock(&glob->lru_lock);
-   return -EBUSY;
+   list_for_each_entry(bo, &man->lru, lru) {
+   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+   if (!ret)
+   break;
}

-   bo = list_first_entry(&man->lru, struct ttm_buffer_object, lru);
-   kref_get(&bo->list_kref);
-
-   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
-
-   if (WARN_ON_ONCE(ret == -EBUSY)) {
+   if (ret) {
spin_unlock(&glob->lru_lock);
-
-   kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
}

+   kref_get(&bo->list_kref);
if (!list_empty(&bo->ddestroy)) {
ret = ttm_bo_cleanup_refs_and_unlock(bo, interruptible,
 no_wait_gpu);
-- 
1.8.0



[PATCH 07/10] drm/ttm: cope with reserved buffers on swap list in ttm_bo_swapout

2012-11-12 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 27 ++-
 1 file changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1d77ad1..b9c26a5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1761,16 +1761,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
uint32_t swap_placement = (TTM_PL_FLAG_CACHED | TTM_PL_FLAG_SYSTEM);

spin_lock(&glob->lru_lock);
-   while (ret == -EBUSY) {
-   if (unlikely(list_empty(&glob->swap_lru))) {
-   spin_unlock(&glob->lru_lock);
-   return -EBUSY;
-   }
-
-   bo = list_first_entry(&glob->swap_lru,
- struct ttm_buffer_object, swap);
-   kref_get(&bo->list_kref);
-
+   list_for_each_entry(bo, &glob->swap_lru, swap) {
/**
 * Reserve buffer. Since we unlock while sleeping, we need
 * to re-check that nobody removed us from the swap-list while
@@ -1778,21 +1769,23 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
 */

ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
-   if (unlikely(ret == -EBUSY)) {
-   spin_unlock(&glob->lru_lock);
-   ttm_bo_wait_unreserved(bo, false);
-   kref_put(&bo->list_kref, ttm_bo_release_list);
-   spin_lock(&glob->lru_lock);
-   }
+   if (!ret)
+   break;
}

+   if (ret) {
+   spin_unlock(&glob->lru_lock);
+   return ret;
+   }
+
+   kref_get(&bo->list_kref);
+
if (!list_empty(&bo->ddestroy)) {
ret = ttm_bo_cleanup_refs_and_unlock(bo, false, false);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
}

-   BUG_ON(ret != 0);
put_count = ttm_bo_del_from_lru(bo);
spin_unlock(&glob->lru_lock);

-- 
1.8.0



[PATCH 06/10] drm/ttm: remove no_wait_reserve, v2

2012-11-12 Thread Maarten Lankhorst
All items on the lru list are always reservable, so this is a stupid
thing to keep. Not only that, it is used in a way which would
guarantee deadlocks if it were ever to be set to block on reserve.

This is a lot of churn, but mostly because of the removal of the
argument which can be nested arbitrarily deeply in many places.

Only 1 place changed meaningfully, the rest is just churn that through
an arbitrarily complex chain that can end up calling ttm_mem_evict_first.
The change is simply that ttm_mem_evict_first always assumes
no_wait_reserve is true.

This should work since currently ttm guarantees items on the lru are
always reservable, and reserving items blockingly with some bo held
are enough to cause you to run into a deadlock.

v2:
 - Warn if -EBUSY is returned on reservation, all objects on the list
   should be reservable. Adjusted patch slightly due to conflicts.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ast/ast_ttm.c| 10 +++---
 drivers/gpu/drm/cirrus/cirrus_ttm.c  | 10 +++---
 drivers/gpu/drm/mgag200/mgag200_ttm.c| 10 +++---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 55 ++---
 drivers/gpu/drm/nouveau/nouveau_bo.h |  2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c|  2 +-
 drivers/gpu/drm/radeon/radeon_object.c   |  8 ++---
 drivers/gpu/drm/radeon/radeon_ttm.c  | 31 +
 drivers/gpu/drm/ttm/ttm_bo.c | 60 ++--
 drivers/gpu/drm/ttm/ttm_bo_util.c|  6 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c   | 13 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |  5 ++-
 include/drm/ttm/ttm_bo_api.h |  3 +-
 include/drm/ttm/ttm_bo_driver.h  | 19 --
 15 files changed, 110 insertions(+), 128 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 1a026ac..adcac90 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -186,11 +186,11 @@ static void ast_ttm_io_mem_free(struct ttm_bo_device 
*bdev, struct ttm_mem_reg *

 static int ast_bo_move(struct ttm_buffer_object *bo,
   bool evict, bool interruptible,
-  bool no_wait_reserve, bool no_wait_gpu,
+  bool no_wait_gpu,
   struct ttm_mem_reg *new_mem)
 {
int r;
-   r = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, no_wait_gpu, 
new_mem);
+   r = ttm_bo_move_memcpy(bo, evict, no_wait_gpu, new_mem);
return r;
 }

@@ -383,7 +383,7 @@ int ast_bo_pin(struct ast_bo *bo, u32 pl_flag, u64 
*gpu_addr)
ast_ttm_placement(bo, pl_flag);
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i] |= TTM_PL_FLAG_NO_EVICT;
-   ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false, false);
+   ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false);
if (ret)
return ret;

@@ -406,7 +406,7 @@ int ast_bo_unpin(struct ast_bo *bo)

for (i = 0; i < bo->placement.num_placement ; i++)
bo->placements[i] &= ~TTM_PL_FLAG_NO_EVICT;
-   ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false, false);
+   ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false);
if (ret)
return ret;

@@ -431,7 +431,7 @@ int ast_bo_push_sysram(struct ast_bo *bo)
for (i = 0; i < bo->placement.num_placement ; i++)
bo->placements[i] |= TTM_PL_FLAG_NO_EVICT;

-   ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false, false);
+   ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false);
if (ret) {
DRM_ERROR("pushing to VRAM failed\n");
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index bc83f83..b0e0365 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -186,11 +186,11 @@ static void cirrus_ttm_io_mem_free(struct ttm_bo_device 
*bdev, struct ttm_mem_re

 static int cirrus_bo_move(struct ttm_buffer_object *bo,
   bool evict, bool interruptible,
-  bool no_wait_reserve, bool no_wait_gpu,
+  bool no_wait_gpu,
   struct ttm_mem_reg *new_mem)
 {
int r;
-   r = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, no_wait_gpu, 
new_mem);
+   r = ttm_bo_move_memcpy(bo, evict, no_wait_gpu, new_mem);
return r;
 }

@@ -388,7 +388,7 @@ int cirrus_bo_pin(struct cirrus_bo *bo, u32 pl_flag, u64 
*gpu_addr)
cirrus_ttm_placement(bo, pl_flag);
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i] |= TTM_PL_FLAG_NO_EVICT;
-   ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false, false);
+   ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false);
if (ret)
ret

[PATCH 05/10] drm/ttm: add sense to ttm_bo_cleanup_refs, v4

2012-11-12 Thread Maarten Lankhorst
Require lru_lock and reservation to be held, kill off the loop, no
new sync objects should be attached at this point any more.

v2:
 - moved upwards in patch list and fixed conflicts.
v3:
 - rebase for fence lock, and rename to ttm_bo_cleanup_refs_and_unlock
   for clarity that it unlocks lru.
v4:
 - add WARN_ON(!atomic_read(&bo->kref.refcount)) in reserve to ensure
   that nobody accidentally reserves a dead buffer.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_bo.c   | 123 -
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |   1 +
 2 files changed, 62 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 70285ff..e6df086 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -296,6 +296,8 @@ int ttm_bo_reserve(struct ttm_buffer_object *bo,
int put_count = 0;
int ret;

+   WARN_ON(!atomic_read(&bo->kref.refcount));
+
spin_lock(&glob->lru_lock);
ret = ttm_bo_reserve_locked(bo, interruptible, no_wait, use_sequence,
sequence);
@@ -522,82 +524,78 @@ queue:
 }

 /**
- * function ttm_bo_cleanup_refs
+ * function ttm_bo_cleanup_refs_and_unlock
  * If bo idle, remove from delayed- and lru lists, and unref.
  * If not idle, do nothing.
  *
+ * Must be called with lru_lock and reservation held, this function
+ * will drop both before returning.
+ *
  * @interruptible Any sleeps should occur interruptibly.
- * @no_wait_reserve   Never wait for reserve. Return -EBUSY instead.
  * @no_wait_gpu   Never wait for gpu. Return -EBUSY instead.
  */

-static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
-  bool interruptible,
-  bool no_wait_reserve,
-  bool no_wait_gpu)
+static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo,
+ bool interruptible,
+ bool no_wait_gpu)
 {
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_bo_driver *driver = bdev->driver;
struct ttm_bo_global *glob = bo->glob;
int put_count;
int ret = 0;
-   void *sync_obj;
-
-retry:
-   spin_lock(&glob->lru_lock);
-
-   ret = ttm_bo_reserve_locked(bo, interruptible,
-   no_wait_reserve, false, 0);

-   if (unlikely(ret)) {
-   spin_unlock(&glob->lru_lock);
-   return ret;
-   }
+   spin_lock(&bdev->fence_lock);
+   ret = ttm_bo_wait(bo, false, false, true);

-   if (unlikely(list_empty(&bo->ddestroy))) {
+   if (ret && no_wait_gpu) {
+   spin_unlock(&bdev->fence_lock);
atomic_set(&bo->reserved, 0);
wake_up_all(&bo->event_queue);
spin_unlock(&glob->lru_lock);
-   return 0;
-   }
-
-   spin_lock(&bdev->fence_lock);
-   ret = ttm_bo_wait(bo, false, false, true);
-   if (ret) {
-   if (no_wait_gpu) {
-   spin_unlock(&bdev->fence_lock);
-   atomic_set(&bo->reserved, 0);
-   wake_up_all(&bo->event_queue);
-   spin_unlock(&glob->lru_lock);
-   return ret;
-   }
+   return ret;
+   } else if (ret) {
+   void *sync_obj;

/**
-* Take a reference to the fence and unreserve, if the wait
-* was succesful and no new sync_obj was attached,
-* ttm_bo_wait in retry will return ret = 0, and end the loop.
+* Take a reference to the fence and unreserve,
+* at this point the buffer should be dead, so
+* no new sync objects can be attached.
 */
-
sync_obj = driver->sync_obj_ref(&bo->sync_obj);
spin_unlock(&bdev->fence_lock);
atomic_set(&bo->reserved, 0);
wake_up_all(&bo->event_queue);
spin_unlock(&glob->lru_lock);

-   ret = driver->sync_obj_wait(bo->sync_obj, false, interruptible);
+   ret = driver->sync_obj_wait(sync_obj, false, interruptible);
driver->sync_obj_unref(&sync_obj);
if (ret)
return ret;
-   goto retry;
+   spin_lock(&glob->lru_lock);
+
+   /* remove sync_obj with ttm_bo_wait */
+   spin_lock(&bdev->fence_lock);
+   ret = ttm_bo_wait(bo, false, false, true);
+   spin_unlock(&bdev->fence_lock);
+
+   WARN_ON(ret);
+
+   } else {
+   spin_unlock(&bdev->fence_lock);
+   atomic_set(&bo->reserved, 0);
+   wake_up_all(&bo->event_queue);
+   }
+
+   if (unlikely(list_empty(&bo->ddestroy))) {
+ 

[PATCH 04/10] drm/ttm: change fence_lock to inner lock, v3

2012-11-12 Thread Maarten Lankhorst
I changed the hierarchy to make fence_lock the most inner lock,
instead of outer lock. This will simplify things slightly, and
hopefully makes it easier to make fence_lock global at one point
should it be needed.

To make things clearer, I change the order around in ttm_bo_cleanup_refs
and ttm_bo_cleanup_refs_or_queue.

A reservation is taken first, then fence lock is taken and a wait is attempted.

Signed-off-by: Maarten Lankhorst 

v2:
 - fix conflict with upstream race fix, simplifies ttm_bo_cleanup_refs
v3:
 - change removal of fence_lock to making it a inner lock instead
---
 drivers/gpu/drm/ttm/ttm_bo.c   | 95 --
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  4 +-
 2 files changed, 48 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a3383a7..70285ff 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -478,28 +478,26 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
 {
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_bo_global *glob = bo->glob;
-   struct ttm_bo_driver *driver;
+   struct ttm_bo_driver *driver = bdev->driver;
void *sync_obj = NULL;
int put_count;
int ret;

-   spin_lock(&bdev->fence_lock);
-   (void) ttm_bo_wait(bo, false, false, true);
-   if (!bo->sync_obj) {
-
-   spin_lock(&glob->lru_lock);
-
-   /**
-* Lock inversion between bo:reserve and bdev::fence_lock here,
-* but that's OK, since we're only trylocking.
-*/
-
-   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+   spin_lock(&glob->lru_lock);
+   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+   if (!ret) {
+   spin_lock(&bdev->fence_lock);
+   ret = ttm_bo_wait(bo, false, false, true);

-   if (unlikely(ret == -EBUSY))
+   if (unlikely(ret == -EBUSY)) {
+   sync_obj = driver->sync_obj_ref(bo->sync_obj);
+   spin_unlock(&bdev->fence_lock);
+   atomic_set(&bo->reserved, 0);
+   wake_up_all(&bo->event_queue);
goto queue;
-
+   }
spin_unlock(&bdev->fence_lock);
+
put_count = ttm_bo_del_from_lru(bo);

atomic_set(&bo->reserved, 0);
@@ -509,18 +507,11 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
ttm_bo_list_ref_sub(bo, put_count, true);

return;
-   } else {
-   spin_lock(&glob->lru_lock);
}
 queue:
-   driver = bdev->driver;
-   if (bo->sync_obj)
-   sync_obj = driver->sync_obj_ref(bo->sync_obj);
-
kref_get(&bo->list_kref);
list_add_tail(&bo->ddestroy, &bdev->ddestroy);
spin_unlock(&glob->lru_lock);
-   spin_unlock(&bdev->fence_lock);

if (sync_obj) {
driver->sync_obj_flush(sync_obj);
@@ -546,54 +537,60 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object 
*bo,
   bool no_wait_gpu)
 {
struct ttm_bo_device *bdev = bo->bdev;
+   struct ttm_bo_driver *driver = bdev->driver;
struct ttm_bo_global *glob = bo->glob;
int put_count;
int ret = 0;
+   void *sync_obj;

 retry:
-   spin_lock(&bdev->fence_lock);
-   ret = ttm_bo_wait(bo, false, interruptible, no_wait_gpu);
-   spin_unlock(&bdev->fence_lock);
+   spin_lock(&glob->lru_lock);

-   if (unlikely(ret != 0))
-   return ret;
+   ret = ttm_bo_reserve_locked(bo, interruptible,
+   no_wait_reserve, false, 0);

-retry_reserve:
-   spin_lock(&glob->lru_lock);
+   if (unlikely(ret)) {
+   spin_unlock(&glob->lru_lock);
+   return ret;
+   }

if (unlikely(list_empty(&bo->ddestroy))) {
+   atomic_set(&bo->reserved, 0);
+   wake_up_all(&bo->event_queue);
spin_unlock(&glob->lru_lock);
return 0;
}

-   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
-
-   if (unlikely(ret == -EBUSY)) {
-   spin_unlock(&glob->lru_lock);
-   if (likely(!no_wait_reserve))
-   ret = ttm_bo_wait_unreserved(bo, interruptible);
-   if (unlikely(ret != 0))
+   spin_lock(&bdev->fence_lock);
+   ret = ttm_bo_wait(bo, false, false, true);
+   if (ret) {
+   if (no_wait_gpu) {
+   spin_unlock(&bdev->fence_lock);
+   atomic_set(&bo->reserved, 0);
+   wake_up_all(&bo->event_queue);
+   spin_unlock(&glob->lru_lock);
return ret;
+   }

-   goto retry_reserve;
-   }
-
-   BUG

[PATCH 03/10] drm/ttm: do not check if list is empty in ttm_bo_force_list_clean

2012-11-12 Thread Maarten Lankhorst
Just use the return error from ttm_mem_evict_first instead.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 27 ---
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 74d6e7c..a3383a7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1302,29 +1302,18 @@ EXPORT_SYMBOL(ttm_bo_create);
 static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
unsigned mem_type, bool allow_errors)
 {
-   struct ttm_mem_type_manager *man = &bdev->man[mem_type];
-   struct ttm_bo_global *glob = bdev->glob;
-   int ret;
-
-   /*
-* Can't use standard list traversal since we're unlocking.
-*/
+   int ret = 0;

-   spin_lock(&glob->lru_lock);
-   while (!list_empty(&man->lru)) {
-   spin_unlock(&glob->lru_lock);
+   while (!ret) {
ret = ttm_mem_evict_first(bdev, mem_type, false, false, false);
-   if (ret) {
-   if (allow_errors) {
-   return ret;
-   } else {
-   pr_err("Cleanup eviction failed\n");
-   }
+   if (ret == -EBUSY)
+   return 0;
+   else if (ret && !allow_errors) {
+   pr_err("Cleanup eviction failed\n");
+   ret = 0;
}
-   spin_lock(&glob->lru_lock);
}
-   spin_unlock(&glob->lru_lock);
-   return 0;
+   return ret;
 }

 int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned mem_type)
-- 
1.8.0



[PATCH 02/10] drm/ttm: remove ttm_bo_cleanup_memtype_use

2012-11-12 Thread Maarten Lankhorst
move to release_list instead

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 47 +---
 1 file changed, 14 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9c48e8f..74d6e7c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -143,12 +143,20 @@ static void ttm_bo_release_list(struct kref *list_kref)
BUG_ON(atomic_read(&bo->kref.refcount));
BUG_ON(atomic_read(&bo->cpu_writers));
BUG_ON(bo->sync_obj != NULL);
-   BUG_ON(bo->mem.mm_node != NULL);
BUG_ON(!list_empty(&bo->lru));
BUG_ON(!list_empty(&bo->ddestroy));

-   if (bo->ttm)
+   if (bo->bdev->driver->move_notify)
+   bo->bdev->driver->move_notify(bo, NULL);
+
+   if (bo->ttm) {
+   ttm_tt_unbind(bo->ttm);
ttm_tt_destroy(bo->ttm);
+   bo->ttm = NULL;
+   }
+   ttm_bo_mem_put(bo, &bo->mem);
+   BUG_ON(bo->mem.mm_node != NULL);
+
atomic_dec(&bo->glob->bo_count);
if (bo->destroy)
bo->destroy(bo);
@@ -466,35 +474,6 @@ out_err:
return ret;
 }

-/**
- * Call bo::reserved.
- * Will release GPU memory type usage on destruction.
- * This is the place to put in driver specific hooks to release
- * driver private resources.
- * Will release the bo::reserved lock.
- */
-
-static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo)
-{
-   if (bo->bdev->driver->move_notify)
-   bo->bdev->driver->move_notify(bo, NULL);
-
-   if (bo->ttm) {
-   ttm_tt_unbind(bo->ttm);
-   ttm_tt_destroy(bo->ttm);
-   bo->ttm = NULL;
-   }
-   ttm_bo_mem_put(bo, &bo->mem);
-
-   atomic_set(&bo->reserved, 0);
-
-   /*
-* Make processes trying to reserve really pick it up.
-*/
-   smp_mb__after_atomic_dec();
-   wake_up_all(&bo->event_queue);
-}
-
 static void ttm_bo_cleanup_refs_or_queue(struct ttm_buffer_object *bo)
 {
struct ttm_bo_device *bdev = bo->bdev;
@@ -523,8 +502,9 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
spin_unlock(&bdev->fence_lock);
put_count = ttm_bo_del_from_lru(bo);

+   atomic_set(&bo->reserved, 0);
+   wake_up_all(&bo->event_queue);
spin_unlock(&glob->lru_lock);
-   ttm_bo_cleanup_memtype_use(bo);

ttm_bo_list_ref_sub(bo, put_count, true);

@@ -619,8 +599,9 @@ retry_reserve:
list_del_init(&bo->ddestroy);
++put_count;

+   atomic_set(&bo->reserved, 0);
+   wake_up_all(&bo->event_queue);
spin_unlock(&glob->lru_lock);
-   ttm_bo_cleanup_memtype_use(bo);

ttm_bo_list_ref_sub(bo, put_count, true);

-- 
1.8.0



[PATCH 01/10] drm/radeon: allow move_notify to be called without reservation

2012-11-12 Thread Maarten Lankhorst
The few places that care should have those checks instead.
This allow destruction of bo backed memory without a reservation.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/radeon_gart.c   | 1 -
 drivers/gpu/drm/radeon/radeon_object.c | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 8690be7..6e24f84 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -1237,7 +1237,6 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev,
 {
struct radeon_bo_va *bo_va;

-   BUG_ON(!radeon_bo_is_reserved(bo));
list_for_each_entry(bo_va, &bo->va, bo_list) {
bo_va->valid = false;
}
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 65c..50aa508 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -520,7 +520,7 @@ void radeon_bo_get_tiling_flags(struct radeon_bo *bo,
 int radeon_bo_check_tiling(struct radeon_bo *bo, bool has_moved,
bool force_drop)
 {
-   BUG_ON(!radeon_bo_is_reserved(bo));
+   BUG_ON(!radeon_bo_is_reserved(bo) && !force_drop);

if (!(bo->tiling_flags & RADEON_TILING_SURFACE))
return 0;
-- 
1.8.0



Re: i915 hang and large allocation (~3.7-rc4)

2012-11-12 Thread Daniel Vetter
On Mon, Nov 12, 2012 at 02:44:46PM -0800, Dave Hansen wrote:
> I've been seeing a little goofiness with i915 video under the 3.7-rc's.
> It looks like I'm seeing two separate issues.  One, that the video
> hardware hangs, spits some errors in dmesg, and then video acceleration
> seems to stop working.  Two, when it does this, apport goes digging in
> debugfs for information about the hang.  When it does this, something
> does an order-9 (2MB) kmalloc() which fails.
> 
> While debugfs is expected to be a _bit_ rickety, I do think order-9
> is a bit excessive for an in-kernel allocation, even a temporary
> one.  I'm not quite sure if it has done this for a long time, and I'm
> only hitting it now since I'm seeing a _separate_ i915 hang.
> 
> Relevant parts of dmesg, lspci, and kernel config are here:
> 
>   http://sr71.net/~dave/linux/i915-wonky/

Ironlake gpu, so if this is a regression introduced in 3.7 and things work
normally in 3.6, it's likely that you're hitting a variant of

https://bugs.freedesktop.org/show_bug.cgi?id=55984

It'd be best if you can subscribe yourselfes there, so that all potential
testers are at the same place.

For the 2MB allocation, this is a known problem, unfortunately reworking
the dump code will be major work. Which is why it hasn't been done yet.
But fixing that is somewhere on our giant todo list.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


i915 hang and large allocation (~3.7-rc4)

2012-11-12 Thread Dave Hansen
I've been seeing a little goofiness with i915 video under the 3.7-rc's.
It looks like I'm seeing two separate issues.  One, that the video
hardware hangs, spits some errors in dmesg, and then video acceleration
seems to stop working.  Two, when it does this, apport goes digging in
debugfs for information about the hang.  When it does this, something
does an order-9 (2MB) kmalloc() which fails.

While debugfs is expected to be a _bit_ rickety, I do think order-9
is a bit excessive for an in-kernel allocation, even a temporary
one.  I'm not quite sure if it has done this for a long time, and I'm
only hitting it now since I'm seeing a _separate_ i915 hang.

Relevant parts of dmesg, lspci, and kernel config are here:

http://sr71.net/~dave/linux/i915-wonky/



[PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Will Deacon
On Mon, Nov 12, 2012 at 01:46:57PM +, Rob Clark wrote:
> On Mon, Nov 12, 2012 at 4:46 AM, Will Deacon  wrote:
> > On Fri, Nov 09, 2012 at 09:17:33PM +, Rob Clark wrote:
> >> @@ -122,22 +124,35 @@ extern int __get_user_4(void *);
> >>   ({  \
> >>   unsigned long __limit = current_thread_info()->addr_limit - 
> >> 1; \
> >>   register const typeof(*(p)) __user *__p asm("r0") = (p);\
> >> - register unsigned long __r2 asm("r2");  \
> >>   register unsigned long __l asm("r1") = __limit; \
> >>   register int __e asm("r0"); \
> >>   switch (sizeof(*(__p))) {   \
> >> - case 1: \
> >> + case 1: {   \
> >> + register unsigned long __r2 asm("r2");  \
> >>   __get_user_x(__r2, __p, __e, __l, 1);   \
> >> + x = (typeof(*(p))) __r2;\
> >>   break;  \
> >> - case 2: \
> >> + }   \
> >> + case 2: {   \
> >> + register unsigned long __r2 asm("r2");  \
> >>   __get_user_x(__r2, __p, __e, __l, 2);   \
> >> + x = (typeof(*(p))) __r2;\
> >>   break;  \
> >> - case 4: \
> >> + }   \
> >> + case 4: {   \
> >> + register unsigned long __r2 asm("r2");  \
> >>   __get_user_x(__r2, __p, __e, __l, 4);   \
> >> + x = (typeof(*(p))) __r2;\
> >> + break;  \
> >> + }   \
> >> + case 8: {   \
> >> + register unsigned long long __r2 asm("r2"); \
> >
> > Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
> > asm, so the compiler shouldn't care much. For OABI, I think you may have to
> > do some more work to get the two words where you want them.
> 
> Is the question whether the compiler is guaranteed to allocate r2 and
> r3 in all cases?  I'm not quite sure, I confess to usually trying to
> avoid inline asm.  But from looking at the disassembly (for little
> endian EABI build) it seemed to do the right thing.

I can't recall how OABI represents 64-bit values and particularly whether this
differs between little and big-endian, so I wondered whether you may have to
do some marshalling when you assign x. However, a few quick experiments with
GCC suggest that the register representation matches EABI in regards to word
ordering (it just doesn't require an even base register), although it would
be good to find this written down somewhere...

> The only other idea I had was to explicitly declare two 'unsigned
> long's and then shift them into a 64bit x, although I'm open to
> suggestions if there is a better way.

Can't you just use register unsigned long long for all cases? Even better,
follow what put_user does and use typeof(*(p))?

> >> diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
> >> index 9b06bb4..d05285c 100644
> >> --- a/arch/arm/lib/getuser.S
> >> +++ b/arch/arm/lib/getuser.S
> >> @@ -18,7 +18,7 @@
> >>   * Inputs:   r0 contains the address
> >>   *   r1 contains the address limit, which must be preserved
> >>   * Outputs:  r0 is the error code
> >> - *   r2 contains the zero-extended value
> >> + *   r2, r3 contains the zero-extended value
> >>   *   lr corrupted
> >>   *
> >>   * No other registers must be altered.  (see 
> >> @@ -66,6 +66,19 @@ ENTRY(__get_user_4)
> >>   mov pc, lr
> >>  ENDPROC(__get_user_4)
> >>
> >> +ENTRY(__get_user_8)
> >> + check_uaccess r0, 4, r1, r2, __get_user_bad
> >
> > Shouldn't you be passing 8 here, so that we validate the correct range?
> 
> yes, sorry, I'll fix that
> 
> >> +#ifdef CONFIG_THUMB2_KERNEL
> >> +5: TUSER(ldr)r2, [r0]
> >> +6: TUSER(ldr)r3, [r0, #4]
> >> +#else
> >> +5: TUSER(ldr)r2, [r0], #4
> >> +6: TUSER(ldr)r3, [r0]
> >> +#endif
> >
> > This doesn't work for EABI big-endian systems.
> 
> Hmm, is that true?  Wouldn't put_user() then have the same problem?

I dug up the P

[PATCH] drm: fix drm_framebuffer cleanup.

2012-11-12 Thread Ville Syrjälä
On Sat, Nov 10, 2012 at 10:09:02AM +0900, Inki Dae wrote:
> 2012/11/10 Ville Syrj?l? 
> 
> > On Sat, Nov 10, 2012 at 01:50:53AM +0900, Inki Dae wrote:
> > > 2012/11/9 Ville Syrj?l? 
> > >
> > > > On Fri, Nov 09, 2012 at 11:04:58PM +0900, Inki Dae wrote:
> > > > > 2012/11/9 Ville Syrj?l? 
> > > > >
> > > > > > On Fri, Nov 09, 2012 at 09:41:19PM +0900, Inki Dae wrote:
> > > > > > > 2012/11/9 Ville Syrj?l? 
> > > > > > >
> > > > > > > > On Fri, Nov 09, 2012 at 04:39:30PM +0900, Inki Dae wrote:
> > > > > > > > > This patch fixes access issue to invalid memory region.
> > > > > > > > >
> > > > > > > > > crtc had only one drm_framebuffer object so when framebuffer
> > > > > > > > > cleanup was requested after page flip, it'd try to disable
> > > > > > > > > hardware overlay to current crtc.
> > > > > > > > > But if current crtc points to another drm_framebuffer,
> > > > > > > > > This may induce invalid memory access.
> > > > > > > > >
> > > > > > > > > Assume that some application are doing page flip with two
> > > > > > > > > drm_framebuffer objects. At this time, if second
> > drm_framebuffer
> > > > > > > > > is set to current crtc and the cleanup to first
> > drm_framebuffer
> > > > > > > > > is requested once drm release is requested, then first
> > > > > > > > > drm_framebuffer would be cleaned up without disabling
> > > > > > > > > hardware overlay because current crtc points to second
> > > > > > > > > drm_framebuffer. After that, gem buffer to first
> > drm_framebuffer
> > > > > > > > > would be released and this makes dma access invalid memory
> > > > region.
> > > > > > > > >
> > > > > > > > > This patch adds drm_framebuffer to drm_crtc structure as
> > member
> > > > > > > >
> > > > > > > > That is exactly the reverse of what you're doing in the patch.
> > > > > > > > We already have crtc.fb, and you're adding fb.crtc.
> > > > > > > >
> > > > > > > > > and makes drm_framebuffer_cleanup function check if fb->crtc
> > is
> > > > > > > > > same as desired fb. And also when setcrtc and pageflip are
> > > > > > > > > requested, it makes each drm_framebuffer point to current
> > crtc.
> > > > > > > >
> > > > > > > > Looks like you're just setting the crtc.fb and fb.crtc
> > pointers to
> > > > > > > > exactly mirror each other in the page flip ioctl. That can't
> > fix
> > > > > > > > anything.
> > > > > > > >
> > > > > > > >
> > > > > > > At least, when drm is released, the crtc to framebuffer that was
> > > > recently
> > > > > > > used for scanout can be disabled correctly.
> > > > > >
> > > > > > Let's take this scenario:
> > > > > >
> > > > > > setcrtc(crtc0, fb0)
> > > > > >  -> crtc0.fb = fb0, fb0.crtc = crtc0
> > > > > > page_flip(crtc0, fb1)
> > > > > >  -> crtc0.fb = fb1, fb1.crtc = crtc0
> > > > > > rmfb(fb0)
> > > > > >  -> ?
> > > > > >
> > > > > > The rmfb() will now disable crtc0 because fb0.crtc == crtc0, but
> > > > > > let's consider this just a bug and ignore it for now. So let's
> > assume
> > > > > > that crtc0 won't be disabled when we call rmfb(fb0).
> > > > > >
> > > > > >
> > > > > Ok, Please assume that my patch includes the below codes. when we
> > call
> > > > > rmfb(fb0), fb0->crtc is NULL. so fb0 will be freed without disabling
> > > > crtc.
> > > > >
> > > > > int drm_mode_rmfb(struct drm_device *dev, void *data, struct drm_file
> > > > > *file_priv) {
> > > > > 
> > > > > fb->crtc = NULL;
> > > > > fb->funcs->destroy(fb);
> > > > > out:
> > > > > ...
> > > > > }
> > > >
> > > > As stated above, I already assumed that.
> > > >
> > > > > > The real question is, how would your patch help? You can't free fb0
> > > > > > until the page flip has occured, and your patch doesn't track page
> > > > > > flips, so how can it do anything useful?
> > > > > >
> > > > > > > > First of all multiple crtcs can scan out from the same fb, so a
> > > > single
> > > > > > > > fb.crtc pointer is clearly not enough to represent the
> > relationship
> > > > > > > > between fbs and crtcs.
> > > > > > > >
> > > > > > > > Also you're not clearing the fb.crtc pointer anywhere, so now
> > > > > > > > destroying any framebuffer that was once used for scanout,
> > would
> > > > > > disable
> > > > > > > > some crtc.
> > > > > > > >
> > > > > > > >
> > > > > > > It looks like that you missed my previous comment. Plaese, see
> > the
> > > > > > previous
> > > > > > > comment. And that was already pointed out by Prathyush. fb.crtc
> > will
> > > > be
> > > > > > > cleared at drm_mode_rmfb(). With this, is there my missing
> > point?  I
> > > > > > really
> > > > > > > wonder that with this patch, drm framwork could be faced with any
> > > > > > problem.
> > > > > >
> > > > > > If you clear the fb.crtc pointer before destroying the fb, then you
> > > > > > never disable any crtcs in response to removing a framebuffer.
> > > > > > That's not what we want when the fb is the current fb for the crtc.
> > > > > >
> > > > >
> > > > > Right, there is my missing point. How about this then? Couldn't  we
> > check

[PATCH] drm/i915: Optimize DIV_ROUND_CLOSEST call

2012-11-12 Thread Jean Delvare
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends. This optimization rips 32 bytes of
binary code on x86_64.

Signed-off-by: Jean Delvare 
Cc: Guenter Roeck 
Cc: Andrew Morton 
Cc: Daniel Vetter 
Cc: David Airlie 
---
Already sent on: 2012-09-03.

Daniel, I think we can safely assume ia_freq can't be negative?

 drivers/gpu/drm/i915/intel_pm.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-3.7-rc5.orig/drivers/gpu/drm/i915/intel_pm.c  2012-11-12 
09:30:56.796836818 +0100
+++ linux-3.7-rc5/drivers/gpu/drm/i915/intel_pm.c   2012-11-12 
10:49:38.241676096 +0100
@@ -2547,7 +2547,8 @@ static void gen6_update_ring_freq(struct
 {
struct drm_i915_private *dev_priv = dev->dev_private;
int min_freq = 15;
-   int gpu_freq, ia_freq, max_ia_freq;
+   int gpu_freq;
+   unsigned int ia_freq, max_ia_freq;
int scaling_factor = 180;

WARN_ON(!mutex_is_locked(&dev->struct_mutex));


-- 
Jean Delvare


[patch] vmwgfx: return an -EFAULT if copy_to_user() fails

2012-11-12 Thread Dan Carpenter
copy_to_user() returns the number of bytes remaining to be copied, but
we want to return a negative error code here.  I fixed a couple of these
last year, but I missed this one.

Signed-off-by: Dan Carpenter 
---
I think there were only three copy_to/from_user() functions in this
file and they're all fixed now.

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index b07ca2e..7290811 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
@@ -110,6 +110,8 @@ int vmw_get_cap_3d_ioctl(struct drm_device *dev, void *data,
memcpy_fromio(bounce, &fifo_mem[SVGA_FIFO_3D_CAPS], size);

ret = copy_to_user(buffer, bounce, size);
+   if (ret)
+   ret = -EFAULT;
vfree(bounce);

if (unlikely(ret != 0))


[PATCH] ARM: add get_user() support for 8 byte types

2012-11-12 Thread Rob Clark
On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
 wrote:
> On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
>> From: Rob Clark 
>>
>> A new atomic modeset/pageflip ioctl being developed in DRM requires
>> get_user() to work for 64bit types (in addition to just put_user()).
>
> NAK.
>
> (I did write a better email explaining all the ins and outs of why this
> won't work and why 64-bit get_user isn't possible, but my editor crapped
> out and lost all that well written message; I don't fancy typing it all
> out again.)
>
> Nevertheless,
> int test_ptr(unsigned int **v, unsigned int **p)
> {
> return get_user(*v, p);
> }
>
> produces a warning, and you can't get away from that if you stick 64-bit
> support into get_user().

Actually, it seems like using 'register typeof(x) __r2 asm("r2");'
does avoid that warning..

I don't know if that was the only argument against 64-bit get_user().
But it will at least be inconvenient that get_user() works for 64bit
on x86 but not arm..

BR,
-R

> Sorry, 64-bit get_user() is a no-no.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/2] NVIDIA Tegra DRM driver

2012-11-12 Thread Thierry Reding
This second version of this patch series addresses all the comments
received so far. Most notably it takes advantage of the debugfs helpers
provided by the DRM core. Oddly enough this actually increases the line
count, but that's because the helpers don't fit with the subdevices
approach as implemented by this driver. However some quick discussions
with Rob Clark showed that Tegra DRM is not special in this respect but
other drivers may need the same functionality. Eventually the debugfs
code could be reworked on top of helpers that are better suited at the
design of embedded, multi-device DRM drivers.

Other than that there is some removal of code that was actually supposed
to go into a later patch because it has dependencies that haven't been
merged yet and some moving around of #defines and the device tree
bindings documentation. Finally the driver now uses the DRM core's
drm_compat_ioctl() instead of a custom and unimplemented (!) version.

Thierry

Thierry Reding (2):
  drm: Add NVIDIA Tegra20 support
  drm: tegra: Add HDMI support

 .../bindings/gpu/nvidia,tegra20-host1x.txt |  191 +++
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/tegra/Kconfig  |   23 +
 drivers/gpu/drm/tegra/Makefile |7 +
 drivers/gpu/drm/tegra/dc.c |  846 +
 drivers/gpu/drm/tegra/dc.h |  388 ++
 drivers/gpu/drm/tegra/drm.c|  115 ++
 drivers/gpu/drm/tegra/drm.h|  233 
 drivers/gpu/drm/tegra/fb.c |   56 +
 drivers/gpu/drm/tegra/hdmi.c   | 1324 
 drivers/gpu/drm/tegra/hdmi.h   |  575 +
 drivers/gpu/drm/tegra/host1x.c |  321 +
 drivers/gpu/drm/tegra/output.c |  262 
 drivers/gpu/drm/tegra/rgb.c|  200 +++
 15 files changed, 4544 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
 create mode 100644 drivers/gpu/drm/tegra/Kconfig
 create mode 100644 drivers/gpu/drm/tegra/Makefile
 create mode 100644 drivers/gpu/drm/tegra/dc.c
 create mode 100644 drivers/gpu/drm/tegra/dc.h
 create mode 100644 drivers/gpu/drm/tegra/drm.c
 create mode 100644 drivers/gpu/drm/tegra/drm.h
 create mode 100644 drivers/gpu/drm/tegra/fb.c
 create mode 100644 drivers/gpu/drm/tegra/hdmi.c
 create mode 100644 drivers/gpu/drm/tegra/hdmi.h
 create mode 100644 drivers/gpu/drm/tegra/host1x.c
 create mode 100644 drivers/gpu/drm/tegra/output.c
 create mode 100644 drivers/gpu/drm/tegra/rgb.c

-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: Fix for vblank on nvc0

2012-11-12 Thread Maarten Lankhorst
Op 12-11-12 22:30, Kelly Doran schreef:
> I had Sven test this patch... he said it works.  I think chipset
> number test was executing code that we thought was only either 0x50 or
> 0xc0, but was actually more specific with things like 0x92.
>
Oh right vblank is busted anyway... needs to be nv_device(priv-)>card_type == 
NV_50 to work.

Your patch is the correct fix.

~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v8 2/6] video: add of helper for videomode

2012-11-12 Thread Stephen Warren
On 11/12/2012 08:37 AM, Steffen Trumtrar wrote:
> This adds support for reading display timings from DT or/and convert one of 
> those
> timings to a videomode.
> The of_display_timing implementation supports multiple children where each
> property can have up to 3 values. All children are read into an array, that
> can be queried.
> of_get_videomode converts exactly one of that timings to a struct videomode.

> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> b/Documentation/devicetree/bindings/video/display-timings.txt

The device tree bindings look reasonable to me, so,

Acked-by: Stephen Warren 


[Bug 5092] Unichrome (K8M800) locks up when working with textures

2012-11-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=5092

James Simmons  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #42 from James Simmons  ---
Mesa is no longer support.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121112/7d5dae37/attachment-0001.html>


[Bug 17270] OpenChrome & KDE Screen Savers

2012-11-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=17270

James Simmons  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from James Simmons  ---
Old bug. If it still a problem please reopen.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121112/fb37115b/attachment.html>


[Bug 17269] KPDF & OpenChrome 0.2.309

2012-11-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=17269

James Simmons  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from James Simmons  ---
Outdated bug. If it is still a problem please reopen this ticket

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121112/3e77194f/attachment.html>


  1   2   3   >