rendering with the CPU anyway
(though cairo-gl is supposedly getting better), and leave the GL for
transition effects and such.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri
(DMI_BOARD_VENDOR, MICRO-STAR
INTERNATIONAL CO., LTD),
+ DMI_MATCH(DMI_BOARD_NAME, MS-7469),
+ },
+ },
{ } /* terminating entry */
};
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
don't check for?
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
this is a known issue with the DRM code, I thought Dave had a
fix queued a long time ago though... Dave?
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
already set to the right
value here after the change?
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri
On Tue, 10 Apr 2012 10:47:49 +0200
Jiri Slaby jsl...@suse.cz wrote:
On 04/09/2012 07:11 PM, Jesse Barnes wrote:
On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
ch...@chris-wilson.co.uk wrote:
On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby jsl...@suse.cz
wrote:
I don't know what
...
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 10 Apr 2012 20:11:29 +0200
Jiri Slaby jsl...@suse.cz wrote:
On 04/10/2012 06:26 PM, Jesse Barnes wrote:
So port hotplug is always reporting that port C has a hotplug
interrupt though... If you write 0x3 back to it does the interrupt
stop?
I'm not sure I got it right
be related to
pipelined fencing, if the fences are programmed to point at some funky
memory space).
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Wed, 11 Apr 2012 08:29:22 +0200
Michel Dänzer mic...@daenzer.net wrote:
On Die, 2012-04-10 at 11:34 -0700, Jesse Barnes wrote:
On Tue, 10 Apr 2012 20:11:29 +0200
Jiri Slaby jsl...@suse.cz wrote:
On 04/10/2012 06:26 PM, Jesse Barnes wrote:
So port hotplug is always reporting
with
ancillary data that may be needed (sprite position, z order, gamma,
etc).
This could easily spiral out of control though, given how poorly the
existing KMS API expresses the variety of display controllers out
there; hopefully we can keep things incremental.
--
Jesse Barnes, Intel Open Source Technology
be of limited
usefulness anyway since we really want to flip primary + sprite at the
same time).
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
this.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
hopefully we'll
be adding planar support back again sometime soon.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
would do the right thing in any case (both mode
sets and plane sets are privileged ops). When doing a mode set, the
plane parameters will probably need to be changed anyway...
But keeping it on with some kind of sensible behavior makes the simple
cases easier.
--
Jesse Barnes, Intel Open Source
://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jesse Barnes, Intel Open Source Technology Center
;
}
@@ -699,4 +700,3 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe)
return ret;
}
Yeah, looks fine. I just fixed the same thing in a local tree (though
by using a goto since I added another path that could fail).
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse
in to the driver...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
with the new i915-specific
modeset code.
Reported-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm
with both the
atomic state and per-property state to track and rollback in the case
of failure.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri
On Wed, 12 Sep 2012 12:35:01 -0500
Rob Clark rob.cl...@linaro.org wrote:
On Wed, Sep 12, 2012 at 11:57 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Sun, 9 Sep 2012 22:03:14 -0500
Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
The 'atomic' mechanism allows
.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
/show_bug.cgi?id=54101
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_crtc.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm
structure.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
.
The current man-pages are simply moved and their header line is adjusted to
the
new man-page headers.
Signed-off-by: David Herrmann dh.herrm...@googlemail.com
---
Yeah looks nice.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
drmModeSetPlane (3),
+.BR drmModeSetCursor (3),
+.BR drmModeMoveCursor (3),
+.BR drmSetMaster (3),
+.BR drmAvailable (3),
+.BR drmCheckModesettingSupported (3),
+.BR drmOpen (3)
Could probably include a bit more sample code here, but that's no
reason not to push.
Reviewed-by: Jesse Barnes jbar
could come up with something, maybe people would be interested in
hearing about some of our recent SoC work? I'd have to see what I
could get approval for, but I could probably find *something* that's
not still secret. :)
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 3 Oct 2012 17:12:18 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Oct 03, 2012 at 10:15:38PM +0800, Fengguang Wu wrote:
Hi Jesse,
FYI, kernel build failed on
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-fixes
head:
People keep whining about this, but no one seems to send a patch. This
*ought* to be safe now that we've dealt with the hw races in Mario's
updated code, and fixed the bugs we know about in VT switch, DPMS, and
multi-head configuraions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Cc'ing Mario in case he wants a different value than 50ms.
On Tue, 30 Oct 2012 14:09:12 -0500
Jesse Barnes jbar...@virtuousgeek.org wrote:
People keep whining about this, but no one seems to send a patch. This
*ought* to be safe now that we've dealt with the hw races in Mario's
updated code
On Tue, 30 Oct 2012 20:20:44 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
People keep whining about this, but no one seems to send a patch. This
*ought* to be safe now that we've dealt with the hw races in Mario's
of asymmetric constraints won't disappear anytime
soon, haswell definitely still has some.
Yeah that's a good point... adding a virtual crtc layer would solve
this and let us preserve the existing ABI.
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 1 Nov 2012 19:07:02 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote:
On Thu, 1 Nov 2012 12:12:35 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Oct 25, 2012 at 8:05 PM, ville.syrj...@linux.intel.com
layers working in a meaningful way if you want to support some
rather serious applications of computer graphics.
Agreed, and sorry for the breakage! piglit tests would definitely help
if you find time.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
!= connector-status)
changed = true;
}
Yeah, thanks.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
that you have a mutex. Either way:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 12 Dec 2012 23:00:34 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Dec 12, 2012 at 12:54:47PM -0800, Jesse Barnes wrote:
On Wed, 12 Dec 2012 14:06:44 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Spinning for up to 200 us with interrupts locked out is not good. So
documentation.
Other than that I only fixed typos and the small corrections you guys
mentioned.
Thanks for reviewing!
I went ahead and pushed these finally.
Can you just apply for an fdo account though so we can let you push
things in the future? :)
--
Jesse Barnes, Intel Open Source Technology
On Thu, 10 Jan 2013 22:00:20 +0100
David Herrmann dh.herrm...@googlemail.com wrote:
Hi Jesse
On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 28 Sep 2012 23:44:18 +0200
David Herrmann dh.herrm...@googlemail.com wrote:
Hi
This is revision 2
are
available locally. You can disable building manpages with
--disable-manpages so the quite expensive xsltproc procedure can be
skipped.
Signed-off-by: David Herrmann dh.herrm...@googlemail.com
---
Seems to work here, pushed. Thanks David.
--
Jesse Barnes, Intel Open Source Technology Center
. But the patch looks fine. Thanks!
Works here too. Pushed with David's reviewed-by. Thanks Thierry.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
On Fri, 25 Jan 2013 16:54:11 +0100
David Herrmann dh.herrm...@googlemail.com wrote:
Hi Jesse
On Fri, Jan 18, 2013 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 18 Jan 2013 17:01:59 +0100
David Herrmann dh.herrm...@googlemail.com wrote:
On Fri, Jan 18, 2013 at 5:00
patches.
I sent a patch yesterday for this. I'll bounce it over again.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
introduced in
commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Tue Dec 11 00:59:24 2012 +0100
drm: refcounting for sprite framebuffers
Reported-by: Jesse Barnes jbar...@virtuousgeek.org
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc
failed: %s\n, strerror(ret));
+ fprintf(stderr, clock_gettime failed: %s\n, strerror(errno));
goto out;
}
timeout.tv_sec++;
Applied, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel
of
inlines are just as easy to read. So no argument from me.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
? Is it possible that others have the same problem ?
Ouch, so a BIOS that uses the other forcewake mechanism seems to have
escaped. Is there a newer one available for your system? I'm hoping
it'll fix the issue, otherwise we may have to introduce both methods
for IVB again...
--
Jesse Barnes, Intel Open
On Sat, 22 Jun 2013 13:04:09 -0700
Guenter Roeck li...@roeck-us.net wrote:
On Sat, Jun 22, 2013 at 12:16:46PM -0700, Jesse Barnes wrote:
On Fri, 21 Jun 2013 23:58:08 -0700
Guenter Roeck li...@roeck-us.net wrote:
Hi all,
after upgrading one of my servers to 3.8, then 3.9.7
trying
to forcewake around everywhere we need it.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 12ea1a9..9152cba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915
On Tue, 16 Jul 2013 10:06:54 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 16 Jul 2013 11:34:25 +0400
Konstantin Khlebnikov khlebni...@openvz.org wrote:
I've tested that patch and it really works for me. If you want change
something for other hardware or
extend range where
On Tue, 16 Jul 2013 22:43:49 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jul 16, 2013 at 01:19:25PM -0700, Jesse Barnes wrote:
On Tue, 16 Jul 2013 10:06:54 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 16 Jul 2013 11:34:25 +0400
Konstantin Khlebnikov khlebni
to get you the NDA docs that should have the
info you need.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
the time of my old machine, but the GPU side has
been something of a step backwards...
Well we definitely don't want that...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
then update the pipesrc and pfit state, even on the flip path.
On top of that, other state like info frames and audio state needs to
be tracked and preserved for fastboot as applicable. Then we can
remove the parameter hacks.
--
Jesse Barnes, Intel Open Source Technology Center
haven't looked at how to handle server vs client side arb_sync with the
scheduler and explicit fencing in place; might need some extra work
there...
--
Jesse Barnes, Intel Open Source Technology Center
)
Reported-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/intel_display.c | 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915
From: Kristian H?gsberg <hoegsb...@gmail.com>
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
Signed-off-by: Kristian H?gsberg
Signed-off-by: Jesse
Let them eat cake.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_params.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index a66ffb6..5f81047 100644
--- a/drivers/gpu/drm/i915
As of IVB, the memory controller does internal swizzling already, so we
shouldn't need to enable these. Based on an earlier fix from Kristian.
v2: preserve swizzling if BIOS had it set (Daniel)
Reported-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h
nfoframe.
> >
> > v2: Ville's inputs incorporated. Added picture aspect ratio as part of
> > edid_cea_modes instead of DRM_MODE
> >
> > Signed-off-by: Vandana Kannan
> > Reviewed-by: Alex Deucher
>
> Reviewed-by: Ville Syrj?l?
Note this one is needed for
onditions are
> satisfied, PAR is NONE as per initialization.
>
> As a next step, create a property that would enable a user space app to set
> aspect ratio. (will be pushed as a separate patch)
>
> Signed-off-by: Vandana Kannan
> Cc: Jesse Barnes
> Cc: Vijay Purushothaman
>
https://bugs.freedesktop.org/show_bug.cgi?id=73154
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> Cc: Ville Syrj?l?
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 56 +++
> drivers/gpu/drm/drm_fb_helper.c| 64
> +
We really just want to go detect displays again and fire off a hotplug
event if things have changed, not go through full hotplug processing.
Requested-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20 +---
1 file changed, 1 insertion(+), 19
Gets the detect code (which may take awhile) out of the resume path,
speeding things up a bit.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
In some cases, the callers of this function may not need the return
value and delaying the uevent is ok. So add an async version of the
function for use in those cases.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_probe_helper.c | 8
include/drm/drm_crtc_helper.h | 2 ++
2
On Wed, 21 May 2014 08:52:34 +0200
Daniel Vetter wrote:
> On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote:
> > Gets the detect code (which may take awhile) out of the resume path,
> > speeding things up a bit.
> >
> > Signed-off-by: Jesse Barnes
> &
On Wed, 2 Jul 2014 13:35:19 -0700
St?phane Marchesin wrote:
> On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter wrote:
> > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes
> > wrote:
> >> People keep whining about this, but no one seems to send a patch. This
> >>
On Tue, 8 Jul 2014 15:56:04 +0200
Daniel Vetter wrote:
> On Wed, Jul 02, 2014 at 01:42:38PM -0700, Jesse Barnes wrote:
> > On Wed, 2 Jul 2014 13:35:19 -0700
> > St?phane Marchesin wrote:
> >
> > > On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter
> > > w
@ extern int drm_mode_create_dvi_i_properties(struct
> drm_device *dev);
> extern int drm_mode_create_tv_properties(struct drm_device *dev, int
> num_formats,
>char *formats[]);
> extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> +extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
> extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
>
--
Jesse Barnes, Intel Open Source Technology Center
gt; move towards for the near future. Jesse is working on some patches
> already.
Yeah I'd like to get some feedback from Maarten on my bits so I can get
them ready for upstream. I still need to add documentation and tests,
but I'd like to make sure the interfaces and internals get acked first.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 23 Jul 2014 11:47:15 +0200
Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes
> wrote:
> >> We don't have the code yet ready, but that's the direction i915 will
> >> move towards for the near future. Jesse is working on some patches
> >&g
RC and ia64 (iirc on
sparc anyway, maybe MIPS too): "allocate" a PASID everytime you need
one, but don't tie it to the process at all, just use it as a counter
that lets you know when you need to do a full TLB flush, then start the
allocation process over. This lets you minimize TLB flushing and
gracefully handles oversubscription.
My current code doesn't bother though; context creation will fail if we
run out of PASIDs on a given device.
--
Jesse Barnes, Intel Open Source Technology Center
de their
> own set of ioctl through their own platform.
Yeah things are different enough that a uniform ioctl doesn't make
sense. If/when all the vendors decide on a single standard, we can use
that, but until then I don't see a nice way to share our doorbell &
submission scheme with HSA, and I assume nvidia is the same.
Using HSA as a basis for non-HSA systems seems like it would add a lot
of complexity, since non-HSA hardware would have to intercept the queue
writes and manage the submission requests etc as bytecodes in the
kernel driver, or maybe as a shim layer library that wraps that stuff.
Probably not worth the effort given that the command sets themselves
are all custom as well, driven by specific user level drivers like GL,
CL, and libva.
--
Jesse Barnes, Intel Open Source Technology Center
Let them eat mincemeat pie.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index d05a2af..081ab2f 100644
--- a/drivers/gpu/drm
From: Kristian H?gsberg <hoegsb...@gmail.com>
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
Signed-off-by: Kristian H?gsberg
Signed-off-by: Jesse
From: Kristian H?gsberg <hoegsb...@gmail.com>
Like mode_equal but w/o the clock checks. Useful for checking if modes
are close enough to re-use to avoid a boot time mode set for example.
Signed-off-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_modes
)
Reported-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
)
check display swizzle setting in detect_bit_6_swizzle (Daniel)
use gen6 as cutoff point (Daniel)
Reported-by: Kristian H?gsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem.c| 3 +++
drivers/gpu/drm/i915/i915_gem_tiling.c
On Tue, 10 Jun 2014 16:02:51 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 11:24:28AM -0700, Jesse Barnes wrote:
> > Some machines (like MBAs) might use a tiled framebuffer but not enable
> > display swizzling at boot time. We want to preserve that configuration
On Tue, 10 Jun 2014 16:05:36 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 11:24:30AM -0700, Jesse Barnes wrote:
> > From: Kristian H?gsberg
> >
> > The BIOS may set a native mode that doesn't quite match the preferred
> > mode timings. It should be o
On Tue, 10 Jun 2014 16:07:44 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
> > Let them eat mincemeat pie.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i915_params.c | 4 ++--
> > 1 fil
On Tue, 10 Jun 2014 11:01:06 -0700
St?phane Marchesin wrote:
> On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes
> wrote:
> > On Tue, 10 Jun 2014 16:07:44 +0200
> > Daniel Vetter wrote:
> >
> >> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
On Tue, 10 Jun 2014 21:33:27 +0200
Daniel Vetter wrote:
> On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes
> wrote:
> > Yes, that's what I do below... I even added it to the changelog:
> > http://patchwork.freedesktop.org/patch/27223/
> >
> > Did you miss the
On Wed, 11 Jun 2014 11:23:26 +0200
Daniel Vetter wrote:
> On Tue, Jun 10, 2014 at 12:45:38PM -0700, Jesse Barnes wrote:
> > On Tue, 10 Jun 2014 21:33:27 +0200
> > Daniel Vetter wrote:
> >
> > > On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes > > virtuousgeek.
On Wed, 11 Jun 2014 17:39:29 +0200
Daniel Vetter wrote:
> On Wed, Jun 11, 2014 at 5:13 PM, Jesse Barnes
> wrote:
> >> - If you have a machine which uses tiled framebuffers and enables
> >> swizzling in the BIOS your code will a) drop the swizzle setup in
> >>
rtcs during
> suspend
Here's one that may be fixed by this series, needs testing though:
https://bugs.freedesktop.org/show_bug.cgi?id=79054
--
Jesse Barnes, Intel Open Source Technology Center
c ID %d\n",
> - plane_req->crtc_id);
> - ret = -ENOENT;
> - goto out;
> - }
> - crtc = obj_to_crtc(obj);
> -
> fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
> if (!fb) {
> DRM_DE
On Thu, 6 Nov 2014 19:35:51 -0500
Rob Clark wrote:
> On Thu, Nov 6, 2014 at 6:29 PM, Daniel Vetter wrote:
> >
> > That aside I guess I need to elaborate on what makes dpms special in
> > i915, and why there's a real difference between crtc->enable == true
> > && ->active == false and
On 12/14/2014 4:59 AM, Chris Wilson wrote:
> One of the things wbinvd is considered evil for is that it blocks the
> CPU for an indeterminate amount of time - upsetting latency critcial
> aspects of the OS. For example, the x86/mm has similar code to use
> wbinvd for large clflushes that caused a
Just like we have for connector type etc.
v2: drop static array (Chris)
v3: add kdoc (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 23 +++
include/drm/drm_crtc.h |1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm
This allows drivers to use them in custom initial_config functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c |6 --
include/drm/drm_fb_helper.h |6 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b
Begin forwarded message:
Date: Wed, 12 Feb 2014 12:26:24 -0800
From: Jesse Barnes <jbar...@virtuousgeek.org>
To: intel-gfx at lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 1/6] drm: export cmdline and preferred mode
functions from fb helper
This allows drivers to use them in
This allows drivers to use them in custom initial_config functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c |6 --
include/drm/drm_fb_helper.h |6 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b
rove fruitful,
> >either because I messed it up or there's a combination of things that
> >fix the issue. So instead I did a regular git bisect between 3.12 and
> >3.13 to see which commit _broke_ things and caused the above behavior.
> > That landed me at:
> >
> >Auth
int drm_vblank_get(struct drm_device *dev, int crtc)
> drm_update_vblank_count(dev, crtc);
> }
> }
> - spin_unlock_irqrestore(>vblank_time_lock, irqflags2);
> + spin_unlock(>vblank_time_lock);
> } else {
> if (!dev->vblank[crtc
/* Display driver is setting mode */
> + int crtc; /* crtc index */
> bool enabled; /* so we don't call enable more than
> once per disable */
> };
> @@ -1157,7 +1160,6 @@ struct drm_device {
>
> spinlock_t vblank_time_lock;/**< Protects vblank count and time
> updates during vblank enable/disable */
> spinlock_t vbl_lock;
> - struct timer_list vblank_disable_timer;
>
> u32 max_vblank_count; /**< size of vblank counter register */
>
Yeah this looks like a good fix.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
more than
> once per disable */
> + bool reject;/* reject drm_vblank_get()? */
> };
>
> /**
> @@ -1400,7 +1401,8 @@ extern void drm_send_vblank_event(struct drm_device
> *dev, int crtc,
> extern bool drm_handle_vblank(struct drm_device *dev, int crtc);
> extern int drm_vblank_get(struct drm_device *dev, int crtc);
> extern void drm_vblank_put(struct drm_device *dev, int crtc);
> -extern void drm_vblank_off(struct drm_device *dev, int crtc);
> +extern void drm_vblank_off(struct drm_device *dev, int crtc, bool reject);
> +extern void drm_vblank_on(struct drm_device *dev, int crtc);
> extern void drm_vblank_cleanup(struct drm_device *dev);
> extern u32 drm_get_last_vbltimestamp(struct drm_device *dev, int crtc,
>struct timeval *tvblank, unsigned flags);
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
on_get;
> +
> /* array of size num_crtcs */
> struct drm_vblank_crtc *vblank;
>
This seems like the sort of thing it would be good to have a test
for... I'm surprised we haven't hit it yet. But in looking at the code
I don't see where we'd re-enable things properly in this situation, so
I guess it's a real bug.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
o for another opinion too. This makes me nervous but it
seems ok.
I think you should update the docbook (with examples) as well so other
driver writers will know how to use this stuff.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
om causing grief for other GPU users. I think that's
> the minimum level that's intended also for example also for the struct
> file accounting.
>
> > My comment really was about balancing mm users under the assumption that
> > they're all unlimited.
>
> Yeah, sorry for stealing the thread. I usually bring this up now and
> again but nowadays with an exponential backoff.
Yeah I agree we're missing some good limits stuff in i915 and DRM in
general probably. Chris started looking at this awhile back, but I
haven't seen anything recently. Tying into the ulimits/rlimits might
make sense, and at the very least we need to account for things
properly so we can add new limits where needed.
--
Jesse Barnes, Intel Open Source Technology Center
301 - 400 of 836 matches
Mail list logo
