t;HDMI dongle to my HDMI TV.
Does the HDMI HDA codec need any special parameters to work?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
ng on a new feature for the next window), and as a
downstream gfx developer I'd like to see this on the Intel side as
well, unless other developers have big objections...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 06 Jun 2011 16:24:46 -0700
Keith Packard wrote:
> On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes
> wrote:
>
> > Can you keep drm-intel-next fairly up to date with respect to the fixes
> > branch? I.e. keep it a superset of drm-intel-fixes for the most part?
>
On Mon, 6 Jun 2011 16:30:25 -0700
Jesse Barnes wrote:
> On Mon, 06 Jun 2011 16:24:46 -0700
> Keith Packard wrote:
>
> > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > virtuousgeek.org> wrote:
> >
> > > Can you keep drm-intel-next fairly up to date wi
This patchset updates the previous one, incorporating the feedback I
received:
1) uses the v4l fourcc codes to communicate pixel format
2) adds a new addfb ioctl that takes a format
3) adds working SNB support for the new code
Comments welcome. I'll be pushing intel-gpu-tools testdisplay su
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 230
drivers/gpu/drm/drm_
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +/* Planes blend with or override other bits on the CRTC */
> +struct drm_mode_set_plane {
> + __u32 plane_id;
> + __u32 crtc_id;
> + __u32 fb_id; /* contains surface format type */
> +
> +
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +#define DRM_MODE_PLANE_FORMAT_YUV422 1 /* YUV 4:2:2 packed */
> +#define DRM_MODE_PLANE_FORMAT_RGBX101010 2 /* RGB 10bpc, ign. alpha */
> +#define DRM_MODE_PLANE_FORMAT_RGBX8883 /* Standard x:8:8
On Wed, 8 Jun 2011 11:41:17 +0200
Marcus Lorentzon wrote:
> On 06/07/2011 11:01 PM, Jesse Barnes wrote:
> > On Tue, 7 Jun 2011 13:07:39 -0700
> > Jesse Barnes wrote:
> >
> >
> >> +/* Planes blend with or override other bits on the CRTC */
> >&g
On Tue, 7 Jun 2011 13:07:38 -0700
Jesse Barnes wrote:
> This patchset updates the previous one, incorporating the feedback I
> received:
> 1) uses the v4l fourcc codes to communicate pixel format
> 2) adds a new addfb ioctl that takes a format
> 3) adds working SNB supp
check_feature(dev, DRIVER_MODESET) is False.
Ouch, a non-KMS config. Any reason you can't use KMS?
This patch should help at any rate.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0defd42..a1a
(HAS_PCH_SPLIT(dev)) {
> ...
> } else
> dev_priv->display.update_wm = NULL;
> }
We'll only hit this path on non-existent hardware. Since a clock
gating routine is required I'd rather just see the panic and add a new
routine at that time (i.e. what we nor
; > gating routine is required I'd rather just see the panic and add a new
> > routine at that time (i.e. what we normally do during bringup).
>
> How about BUG_ON(!ptr) in the init-routine for a bit more grace? And/or
> a warning in the else-block? It seems to happen to users...
Yeah, a BUG_ON would be fine.
--
Jesse Barnes, Intel Open Source Technology Center
n -ENODEV in this case and propagate it to the upper
> layers.
>
> Signed-off-by: Wolfram Sang
> Cc: Jesse Barnes
> Cc: Chris Wilson
> ---
Looks good, thanks Wolfram.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
This version adds both source and dest rect params to the set_plane
ioctl, and makes the source fixed point to support hardware that needs
it.
I haven't changed the name of the SNB implementation yet (per Chris's
suggestions) but will before it gets upstream.
I'd be interested to see whether thes
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 235 +++-
drivers/gpu/drm/drm_
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52
On Tue, 21 Jun 2011 10:55:39 +0200
Marcus Lorentzon wrote:
> On 06/20/2011 10:11 PM, Jesse Barnes wrote:
> > This version adds both source and dest rect params to the set_plane
> > ioctl, and makes the source fixed point to support hardware that needs
> > it.
> >
>
On Tue, 21 Jun 2011 06:21:11 -0500
Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
> > This version adds both source and dest rect params to the set_plane
> > ioctl, and makes the source fixed point to support hardware that needs
> > it.
>
e, but it doesn't log the drm debug.
> > Is there another parameter to append at the kernel to send via ethernet
> > also the debug?
>
> I don't know how to get the drm debug sent to ethernet; perhaps someone
> else does?
Use netconsole. Documentation/networking/netconsole.txt has all the
gory details.
--
Jesse Barnes, Intel Open Source Technology Center
32becf6e51535d36b690f2a
> > bdd92c9ad287e03a2ec52f5a89c470cd5caae1c2
> >
> >
> >
> > I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> > cause. Can you check if the appended revert of that commit makes
> > things disappear?
> It seems like you guessed perfectly correct - reverting the commit makes
> those notifications go away at once.
>
Without this reverted you see messages? I missed the earlier stuff,
what message are you seeing?
--
Jesse Barnes, Intel Open Source Technology Center
interesting, didn't realize X startup was so GPU intensive. :)
The patch you reverted will definitely cause the GPU to ramp up its
frequency much faster than before, but it sounds like on your system
you might also see it with the revert if you run something GPU
intensive like nexuiz.
The CPU
On Wed, 29 Jun 2011 00:01:58 +0200
Olaf Freyer wrote:
> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> > On Tue, 28 Jun 2011 23:09:45 +0200
> > Olaf Freyer wrote:
> >>>>> I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> >>>>
Chad Versace (1):
Add attachment token DRI2BufferHiz
Jesse Barnes (2):
Revert "dri2proto: make DRI2 swap event match GLX spec"
dri2proto: add a new DRI2BufferSwapComplete struct that matches the spec
git tag: dri2proto-2.6
http://xorg.freedesktop.org/archive/indivi
On Thu, 3 Mar 2011 17:34:53 -0600 (CST)
Ilija Hadzic wrote:
> The fix/improvement I propose is to extend the request.type field
> in drmVBlank structure with additional 5 bits that I call high_crtc
> (there are lots of unused bits in that field). 5 bits covers for 32
> CRTCs, which seems to be th
On Fri, 11 Mar 2011 02:35:45 +0100 (CET)
"Indan Zupancic" wrote:
> drm/i915: Fix DPMS and suspend interaction for intel_panel.c
>
> When suspending intel_panel_disable_backlight() is never called,
> but intel_panel_enable_backlight() is called at resume. With the
> effect that if the brightness
us = connector->funcs->detect(connector, true);
> + mutex_unlock(&connector->dev->mode_config.mutex);
> +
How about adding a mutex assertion check in the detect hook as well? I
think we need a more generous sprinkling of those around the CRTC
helper code in general...
--
Jesse Barnes, Intel Open Source Technology Center
ted code in each function is begging to get pulled out into
a separate function...
--
Jesse Barnes, Intel Open Source Technology Center
param check, but I'd still prefer a new ioctl to abusing
the old one.
--
Jesse Barnes, Intel Open Source Technology Center
On Fri, 18 Mar 2011 18:13:11 -0500 (CDT)
Ilija Hadzic wrote:
>
>
> On Fri, 18 Mar 2011, Jesse Barnes wrote:
>
> >
> > I like the new param check, but I'd still prefer a new ioctl to abusing
> > the old one.
> >
>
> It's not "
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
)
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
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 Barnes
---
drivers/gp
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_
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 neede
tions 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
> C
Bugzilla: 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|
Rob's patchset goes further than that, but obviously not as far as you
propose.
OTOH, keeping things really simple and not very featureful means there
are fewer points of failure, which is what I think callers would expect
from a flip API...
So where does that leave us? I'd propose we have a very simple,
stripped down, single crtc flip ioctl, along with a big atomic mode set
ioctl, and then perhaps a fancier multi-crtc flip ioctl.
--
Jesse Barnes, Intel Open Source Technology Center
ug.cgi?id=54101
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> Cc: stable at 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/drm_crtc.c
to the current structure.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 17 Sep 2012 23:13:57 +0200
David Herrmann wrote:
> Hi Jesse
>
> On Mon, Sep 17, 2012 at 5:12 PM, Jesse Barnes
> wrote:
> > I just pushed some basic man page stuff to the libdrm repo, but won't
> > have time to do any more pages for the next week or tw
The current man-pages are simply moved and their header line is adjusted to
> the
> new man-page headers.
>
> Signed-off-by: David Herrmann
> ---
Yeah looks nice.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
ifferences between the drivers so
> +driver-depedent code is still needed. Many helpers are provided in
> +.B libgbm
> +(Graphics Buffer Manager) from the
> +.IR mesa-project .
> +For more information on DRM memory-management, see
> +.BR drm-memory (7).
> +
> +.SH REPORTING BUGS
> +Bugs in this manual should be reported to http://bugs.freedesktop.org under
> +the "Mesa" product, with "Other" or "libdrm" as the component.
> +
> +.SH "SEE ALSO"
> +.BR drm-kms (7),
> +.BR drm-memory (7),
> +.BR drmSetMaster (3),
> +.BR drmAuthMagic (3),
> +.BR drmAvailable (3),
> +.BR drmOpen (3)
Nice.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
can your list of configured
> + * connectors and CRTCs whether this CRTC is already
> + * used. If it is, then simply continue the search
> here. */
> + if (res->crtcs[j] "is unused") {
> + drmModeFreeEncoder(enc);
> + return res->crtcs[j];
> + }
> + }
> +
> + drmModeFreeEncoder(enc);
> + }
> +
> + /* cannot find a suitable CRTC */
> + return -ENOENT;
> +}
> +.fi
> +.in
> +
> +.SH REPORTING BUGS
> +Bugs in this manual should be reported to http://bugs.freedesktop.org under
> +the "Mesa" product, with "Other" or "libdrm" as the component.
> +
> +.SH "SEE ALSO"
> +.BR drm (7),
> +.BR drm-memory (7),
> +.BR drmModeGetResources (3),
> +.BR drmModeGetConnector (3),
> +.BR drmModeGetEncoder (3),
> +.BR drmModeGetCrtc (3),
> +.BR drmModeSetCrtc (3),
> +.BR drmModeGetFB (3),
> +.BR drmModeAddFB (3),
> +.BR drmModeAddFB2 (3),
> +.BR drmModeDirtyFB (3),
> +.BR drmModeRmFB (3),
> +.BR drmModePageFlip (3),
> +.BR drmModeGetPlaneResources (3),
> +.BR drmModeGetPlane (3),
> +.BR 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
--
Jesse Barnes, Intel Open Source Technology Center
sted values and can be used now. */
> +
> + /* create framebuffer object for the dumb-buffer */
> + ret = drmModeAddFB(fd, 1920, 1080, 24, 32, creq.pitch, creq.handle,
> &fb);
> + if (ret) {
> + /* frame buffer creation failed; see "errno" */
> + ...
> + }
> + /* the framebuffer "fb" can now used for scanout with KMS */
> +
> + /* prepare buffer for memory mapping */
> + memset(&mreq, 0, sizeof(mreq));
> + mreq.handle = creq.handle;
> + ret = drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, &mreq);
> + if (ret) {
> + /* DRM buffer preparation failed; see "errno" */
> + ...
> + }
> + /* mreq.offset now contains the new offset that can be used with mmap()
> */
> +
> + /* perform actual memory mapping */
> + map = mmap(0, creq.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
> mreq.offset);
> + if (map == MAP_FAILED) {
> + /* memory-mapping failed; see "errno" */
> + ...
> + }
> +
> + /* clear the framebuffer to 0 */
> + memset(map, 0, creq.size);
> +.fi
> +.in
> +
> +.SH REPORTING BUGS
> +Bugs in this manual should be reported to http://bugs.freedesktop.org under
> +the "Mesa" product, with "Other" or "libdrm" as the component.
> +
> +.SH "SEE ALSO"
> +.BR drm (7),
> +.BR drm-kms (7),
> +.BR drmAvailable (3),
> +.BR drmOpen (3),
> +.BR drm-intel (7),
> +.BR drm-radeon (7),
> +.BR drm-nouveau (7),
> +.BR drm-prime (7)
> diff --git a/man/drm-mm.7 b/man/drm-mm.7
> new file mode 100644
> index 000..258b5a3
> --- /dev/null
> +++ b/man/drm-mm.7
> @@ -0,0 +1 @@
> +.so man7/drm-memory.7
> diff --git a/man/drm-ttm.7 b/man/drm-ttm.7
> new file mode 100644
> index 000..258b5a3
> --- /dev/null
> +++ b/man/drm-ttm.7
> @@ -0,0 +1 @@
> +.so man7/drm-memory.7
Heh, this one highlights the lack of documentation we have for other
libs like Mesa and libgbm. :)
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
gt; So far there are three speakers who lined up, and my feeling is that
> Matthieu and Marc lined up just so that the deadline and requirement
> will be met. So only a single person is intending to come to fosdem and
> has a topic he wants to talk about.
>
> Come on guys. Surely we can do better than that.
I 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
mplicated, but you'll need docs for it. Charlie
Huang ought to be able to get you the NDA docs that should have the
info you need.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
> ? ? ? ? ? ? ? ?spin_lock_irqsave(&dev->event_lock, flags);
> > --
> > 1.7.3.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinf
initely better than nothing.
Acked-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
kfree(intel_plane);
> return -ENODEV;
> }
>
> @@ -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
ld a compat atomic setup, we'll need to read the
current state of any existing objects and pass them in to the driver...
--
Jesse Barnes, Intel Open Source Technology Center
kernel
> systems but not from 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
s
> happens in intel_alloc_plane_obj in intel_display.c.
>
> Since no one else uses this we can savely remove the WARN without
> repercursions.
>
> Reported-by: Ben Widawsky
> Cc: Ben Widawsky
> Cc: Jesse Barnes
> Cc: Dave Airlie
> Signed-off-by: Daniel Vetter
> ---
> dr
File your talk now, while there are still
> some useful slots available.
>
> Also, for those who have filed already but who have left their abstracts
> open, please get those filed in ASAP. Your talk will be only be ordered
> in when at least the basics are provided.
Hey Luc,
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 b
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
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 custom initial_config functions
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
.13 and 3.14-rc1 didn't prove 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.
> >
906,7 +906,7 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
> drm_update_vblank_count(dev, crtc);
> }
> }
> - spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags2);
> + spin_unlock(&dev->vblank_time_lock);
> } e
/* for wraparound handling */
> u32 last_wait; /* Last vblank seqno waited per CRTC */
> unsigned int inmodeset; /* 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
/* crtc index */
> bool enabled; /* so we don't call enable more than
> once per disable */
> + bool reject;/* reject drm_vblank_get()? */
> };
>
> /**
> @@ -1400,7 +14
t; + bool vblank_always_enable_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
k.
Cc'ing Mario 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
that work isn't ready yet either I've dropped the offending
> patches.
I sent a patch yesterday for this. I'll bounce it over again.
--
Jesse Barnes, Intel Open Source Technology Center
kage introduced in
>
> commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
> Author: Daniel Vetter
> Date: Tue Dec 11 00:59:24 2012 +0100
>
> drm: refcounting for sprite framebuffers
>
> Reported-by: Jesse Barnes
> Cc: Jesse Barnes
> Cc: Rob Clark
> Sig
tation.
>
> 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 Center
On Thu, 10 Jan 2013 22:00:20 +0100
David Herrmann wrote:
> Hi Jesse
>
> On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes
> wrote:
> > On Fri, 28 Sep 2012 23:44:18 +0200
> > David Herrmann wrote:
> >
> >> Hi
> >>
> >> This is revisio
ocally. You can disable building manpages with
> --disable-manpages so the quite expensive xsltproc procedure can be
> skipped.
>
> Signed-off-by: David Herrmann
> ---
Seems to work here, pushed. Thanks David.
--
Jesse Barnes, Intel Open Source Technology Center
y machine.
>
> Ah sorry, I now saw the "subs" => "subst" typo. Still I wonder why
> distcheck works here. But the patch looks fine. Thanks!
Works here too. Pushed with David's reviewed-by. Thanks Thierry.
--
Jesse Barnes, Intel Open Source Technology Center
On Fri, 25 Jan 2013 16:54:11 +0100
David Herrmann wrote:
> Hi Jesse
>
> On Fri, Jan 18, 2013 at 5:54 PM, Jesse Barnes
> wrote:
> > On Fri, 18 Jan 2013 17:01:59 +0100
> > David Herrmann wrote:
> >
> >> On Fri, Jan 18, 2013 at 5:00 PM, David
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
2,7 @@ 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
it may be better to just do the font 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
-- next part --
A non-text attachment was scrubbed...
I_BOARD_NAME, "AT5NM10T-I"),
> > > ? ? ? ? ? ? ? },
> > > ? ? ? },
> > > + ? ? {
> > > + ? ? ? ? ? ? .callback = intel_no_lvds_dmi_callback,
> > > + ? ? ? ? ? ? .ident = "MSI Wind Box DC500",
> > > + ? ? ? ? ? ? .matches = {
> >
s for you I guess it's ok to blacklist your
chipset until we poke some hw folks internally about this.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
kind of problem... though hopefully we'll
be adding planar support back again sometime soon.
--
Jesse Barnes, Intel Open Source Technology Center
requirement; the assumption was that
the display manager 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 th
s the only one which will have 4 lanes, pipe B&C will only
> have 2 each).
> - afaik these kind 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? 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 wrote:
> >
> > > On Thu, Oct 25, 2012 at 8:05 PM,
> > > wrote:
> >
he future.
>
> Also, i take from Chris comments about patch [1/3] above that properly
> implemented triple-buffering with correct timestamping and
> synchronisation is impossible with the current X-Servers, because the
> DRI2 invalidate event mechanism is racy and broken to the po
fprintf(stderr, "clock_gettime 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
not attached to the direct structure reference; a couple of
inlines are just as easy to read. So no argument from me.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
>
> Whoa. Broken since its introduction in
>
> commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e
> Author: Jesse Barnes
> Date: Tue Jan 3 08:05:39 2012 -0800
>
> drm/i915: add color key support v4
>
> Cc: stable at vger.kernel.org
>
> BR,
> Jani.
>
TL_I915_SET_SPRITE_COLORKEY ioctl.
>>>
>>> Signed-off-by: Tommi Rantala
>>
>> Whoa. Broken since its introduction in
>>
>> commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e
>> Author: Jesse Barnes
>> Date: Tue Jan 3 08:05:39 2012 -0800
>>
Pick up context flags, softpin, etc.
Signed-off-by: Jesse Barnes
---
include/drm/i915_drm.h | 57 ++
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..4ce1fe9 100644
--- a
On 12/12/2015 07:16 AM, Emil Velikov wrote:
> On 11 December 2015 at 21:55, Jesse Barnes
> wrote:
>> Pick up context flags, softpin, etc.
>>
>> Signed-off-by: Jesse Barnes
>> ---
>> include/drm/i915_drm.h | 57
>> +++
cted output once
> - * the mode has been programmed, along with possible test patterns.
> - */
> #ifdef HAVE_CONFIG_H
> #include "config.h"
> #endif
Yep, thanks.
Reviewed-by: Jesse Barnes
er than 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 wrote:
> On Tue, 16 Jul 2013 11:34:25 +0400
> Konstantin Khlebnikov wrote:
> > I've tested that patch and it really works for me. If you want change
> > something for other hardware or
> > extend range where forcew
On Tue, 16 Jul 2013 22:43:49 +0200
Daniel Vetter 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 wrote:
> >
> > > On Tue, 16 Jul 2013 11:34:25 +0400
> > > Konstantin Khlebnikov
://bugs.freedesktop.org/show_bug.cgi?id=54089
> References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
> Signed-off-by: Konstantin Khlebnikov
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Jesse Barnes
> ---
My hero!
So the later init change didn't work?
Eithe
801 - 900 of 905 matches
Mail list logo
