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, thanks for
On 07/16/2015 01:27 AM, Daniel Vetter wrote:
> On Thu, Jul 09, 2015 at 11:14:43PM +0200, Daniel Vetter wrote:
>> On Thu, Jul 09, 2015 at 01:15:34PM +1000, Dave Airlie wrote:
>>> From: Dave Airlie
>>>
>>> This really doesn't seem to have much chance of working anymore,
>>>
>>> esp for irq context,
ffer, e->destroy(e);
> }
>
> - return total;
> + return total ?: -EAGAIN;
> }
> EXPORT_SYMBOL(drm_read);
I'd prefer "total" to be spelled out after the ? (is this just a GNU
thing or does recent C implicitly use the first operand too?), but
that's no biggie. Looks fine.
Reviewed-by: Jesse Barnes
On Thu, 16 Oct 2014 13:47:38 +0200
Daniel Vetter wrote:
> We need ww mutexes and need to rewrite i915 a bit fo fix this all.
> I.e. known issue. As long as your userspace isn't nasty nothing bad
> will ever happen though.
So do we already have a bug open with a good description of the issue?
_BW_5_4 || intel_dp->use_tps3)
> >> >> + if ((intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3)
> >> >> && !HAS_DDI(dev))
> >> >
> >> > CHV has pattern 3.
> >>
> >> Is "supports tps3" the same set of platforms as "supports 5.4 Gbps"? We
> >> should abstract the check from intel_dp_max_link_bw.
> >
> > Not quite. HSW-ULX supports pattern 3 even though it doesn't do 5.4 Gbps.
>
> How about [1] instead? I forgot --in-reply-to, sorry.
>
> BR,
> Jani.
>
>
> [1] http://mid.gmane.org/1414573406-17071-1-git-send-email-jani.nikula at
> intel.com
Looks like we need something like that at least, assuming we're not
hitting the link_bw == DP_LINK_BW_5_4 case.
--
Jesse Barnes, Intel Open Source Technology Center
initely better than nothing.
Acked-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
ead the
current state of any existing objects and pass them in to the driver...
--
Jesse Barnes, Intel Open Source Technology Center
ay 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...
Name: sig
ME, "AT5NM10T-I"),
> > > ? ? ? ? ? ? ? },
> > > ? ? ? },
> > > + ? ? {
> > > + ? ? ? ? ? ? .callback = intel_no_lvds_dmi_callback,
> > > + ? ? ? ? ? ? .ident = "MSI Wind Box DC500",
> > > + ? ? ? ? ? ? .matches = {
> > > + ? ?
ss it's ok to blacklist your
chipset until we poke some hw folks internally about this.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
ome kind of problem... though hopefully we'll
be adding planar support back again sometime soon.
--
Jesse Barnes, Intel Open Source Technology Center
gn 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 the simple
c
es, pipe B 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:
> >
roperly
> 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 point of not
> being fixable? Basically we would have to wait for DRI3?
>
>
On Wed, 3 Oct 2012 17:12:18 +0200
Daniel Vetter 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:
> 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
> ---
> drivers
ntf(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
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
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
---
drivers/gpu/drm
Cc'ing Mario in case he wants a different value than 50ms.
On Tue, 30 Oct 2012 14:09:12 -0500
Jesse Barnes 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, and fixed
On Tue, 30 Oct 2012 20:20:44 +0100
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
> > *ought* to be safe now that we've dealt with the hw races in Mario's
> >
w i915-specific
> modeset code.
>
> Reported-by: Jesse Barnes
> Signed-off-by: Daniel Vetter
> ---
> 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/drm_f
.
Having a transactional API just seems a little messier 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
On Wed, 12 Sep 2012 12:35:01 -0500
Rob Clark wrote:
> On Wed, Sep 12, 2012 at 11:57 AM, Jesse Barnes
> wrote:
> > On Sun, 9 Sep 2012 22:03:14 -0500
> > Rob Clark wrote:
> >
> >> From: Rob Clark
> >>
> >> The 'atomic' mechanism allows
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
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 two
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
our 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
ow. */
> +
> + /* create framebuffer object for the dumb-buffer */
> + ret = drmModeAddFB(fd, 1920, 1080, 24, 32, creq.pitch, creq.handle,
> );
> + if (ret) {
> + /* frame buffer creation failed; see "errno" */
> + ...
> + }
> + /* the framebuffer "fb" can now used for scanout with KMS */
> +
> + /* prepare buffer for memory mapping */
> + memset(, 0, sizeof(mreq));
> + mreq.handle = creq.handle;
> + ret = drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, );
> + 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
t; 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
ut 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
UX
> >
> > Signed-off-by: Todd Previte
>
> Reviewed-by: Jani Nikula
Did this ever go in?
--
Jesse Barnes, Intel Open Source Technology Center
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
reakage 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 revi
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
> 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
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/intel_display.
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 for
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
eedesktop.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?
Either way, great to
else I can do besides using a special kernel with the backed out
> commit ? 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
On Sat, 22 Jun 2013 13:04:09 -0700
Guenter Roeck 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 wrote:
> >
> > > Hi all,
> > >
> > > after upgrading one
o this stuff seems to be a nop.
>
> And if these writes can get reordered somewhere, why not everything
> else too? I'm sure we have places where we write a bunch of registers,
> and the final write enables something which requires the earlier
> writes to have landed beforehand.
Yeah we shouldn't need mmiowb() anywhere in our driver (until our
on-chip topology gets really complicated anyway).
--
Jesse Barnes, Intel Open Source Technology Center
> - dev_priv->vbt.lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
> - DREF_SSC1_ENABLE);
> -
> intel_modeset_init_hw(dev);
>
> intel_setup_overlay(dev);
>
Yeah looks good (and I'm having deja vu here; I thought I ran into the same
ordering issue at one point in a report from krh, but I guess I never fixed it;
didn't have test hw at the time).
Reviewed-by: Jesse Barnes
Thanks,
Jesse
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
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
>> +++
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
Cc'ing Maarten and Matt; I'm guessing this may be related to one of
their recent patches.
Jesse
On 09/21/2015 11:48 AM, Dave Jones wrote:
> On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> > >
> > > Hi Linus,
>
>
> 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
>>
connector->base.id,
> drm_get_connector_name(connector),
> - old_status, connector->status);
> + connector_status_str(old_status),
> + connector_status_str(connector->status));
> if (old_status != connector->status)
> changed = true;
> }
Yeah, thanks.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
lk gate prior to programming
>* the divisors, and gate it back when it is done.
>*/
> @@ -3041,6 +3024,8 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
> udelay(24);
>
> I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_UNGATE);
> +
> + mutex_unlock(_priv->dpio_lock);
> }
>
> /*
> @@ -4268,6 +4253,8 @@ static void vlv_update_pll(struct drm_crtc *crtc,
> bool is_sdvo;
> u32 temp;
>
> + mutex_lock(_priv->dpio_lock);
> +
> is_sdvo = intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
> intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
>
> @@ -4351,6 +4338,8 @@ static void vlv_update_pll(struct drm_crtc *crtc,
> temp |= (1 << 21);
> intel_dpio_write(dev_priv, DPIO_DATA_CHANNEL2, temp);
> }
> +
> + mutex_unlock(_priv->dpio_lock);
> }
>
> static void i9xx_update_pll(struct drm_crtc *crtc,
Looks fine, I guess you could convert the wait_for_atomic_us to the
non-atomic variant now that you have a mutex. Either way:
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 12 Dec 2012 23:00:34 +0100
Daniel Vetter 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 wrote:
> >
> > > Spinning for up to 200 us with interrupts locked out is not good. So
&
I've given up waiting for someone to implement support for these ioctls
on another platform before they're merged, but I have received a lot of
feedback on the interfaces, and it sounds like they're ok. I've also
fixed all the remaining issues I'm aware of on SNB platforms and things
are working
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 | 236 +++-
drivers/gpu/drm/drm_drv.c
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
This avoids the need to unpin on the error path.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay2.c
b/drivers/gpu/drm/i915/intel_overlay2.c
index 2e38b15
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
The video sprites support various video surface formats natively and can
handle scaling as 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
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f599ce..cd7e04d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
Make sure the object exists (it may not if the plane was previously disabled)
and make sure we zero it out in the disable path to avoid trouble later.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff
Split things out a little and add the IVB reg definitions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h | 59
drivers/gpu/drm/i915/intel_overlay2.c | 168 ++--
2 files changed, 216 insertions(+), 11 deletions(-)
diff --git
To avoid the object being destroyed before our disable hook is called,
take a private reference on it. This will guarantee that we can still
access the object at disable time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c | 27 ++-
1 files
If the source and destination size are different, try to scale the sprite on the
corresponding CRTC.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_overlay2.c | 14 --
2 files changed, 17 insertions(+), 2 deletions
If we try to scan a sprite outside of the parent CRTC area, the display
engine will underflow and potentially blank the framebuffer. So clamp
the position + size to the viewable area.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c | 12 +++-
1 files changed, 11
On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shim wrote:
> 10/25/2011 06:46 PM, Jesse Barnes ? ?:
> > I've given up waiting for someone to implement support for these
> > ioctls on another platform before they're merged, but I have
> > received a lot of feedback on the inte
On Tue, 25 Oct 2011 19:53:02 +0900
Joonyoung Shim wrote:
> > +/**
> > + * drm_plane - central DRM plane control structure
> > + * @dev: DRM device this plane belongs to
> > + * @kdev: kernel device
> > + * @attr: kdev attributes
> > + * @head: for list management
> > + * @base: base mode object
>
On Tue, 25 Oct 2011 11:46:55 +0200
Jesse Barnes wrote:
> I've given up waiting for someone to implement support for these
> ioctls on another platform before they're merged, but I have received
> a lot of feedback on the interfaces, and it sounds like they're ok.
> I've al
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
v2: collapse patches and fix plane disable vs unpin ordering bug
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
v2: collapse patches
v3: no really, fix disable ordering
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile
On Tue, 25 Oct 2011 13:58:55 +0200
Daniel Vetter wrote:
> On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
> > 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
&g
On Tue, 25 Oct 2011 14:26:07 +0100
Alan Cox wrote:
> > As discussed with Jesse on irc, drm fb handling is fragile. Current
> > rules:
> > - fbs are not reference counted, hence when destroying we need to
> > disable all crtcs (and now also planes) that use them.
> > drm_framebuffer_cleanup does
Here's a diff I can roll in if it looks ok. It adds the ability to
specify multiple handles for a single fb to better accommodate planar
configs. I think Rob has convinced me that this is a good idea...
comments appreciated.
Thanks,
Jesse
diff --git a/drivers/gpu/drm/drm_crtc.c
On Wed, 26 Oct 2011 14:40:07 +0900
Joonyoung Shim wrote:
> 10/25/2011 06:46 PM, Jesse Barnes ? ?:
>
> [snip]
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 8020798..d7f03aa 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/
like the DRM layer, with
authentication for rendering clients, an command submission ioctl for
acceleration, and memory management, so I expect most of the driver
growth to be in DRM in the near future.
And I totally agree with Dave about having a kmscon. I really wish
someone would imp
On Mon, 19 Sep 2011 15:22:00 -0700
Keith Packard wrote:
> The eDP panel may not be able to respond to aux channel communications
> unless it has power supplied. During mode setting, power may be
> cut-off during panel power sequencing. Make sure that any aux channel
> communications will work by
On Mon, 19 Sep 2011 15:22:03 -0700
Keith Packard wrote:
> There's no good reason to turn off the eDP force VDD bit synchronously
> while probing devices; that just sticks a huge delay into all mode
> setting paths. Instead, queue a delayed work proc to disable the VDD
> force bit and then
On Tue, 20 Sep 2011 21:45:54 -0700
Keith Packard wrote:
> On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes
> wrote:
>
> > This one mixes up lots of cleanups plus the EDID read with the power
> > changes.
>
> I think the cleanups are;
>
> 1) edp checks
On Tue, 20 Sep 2011 21:51:33 -0700
Keith Packard wrote:
> Yes, making it cleaner would help a ton. There are some basic problems
> with the DRM API that make this hard though -- intel_dp_prepare may
> not ever be followed by a call to intel_dp_commit. That's why I had
> the VDD AUX stuff get
terrupt, with chained secondary interrupt statuses.
> If IIR is 0, the interrupt wasn't raised by the GPU.
I've actually seen cases where one of the PIPE*STAT regs is stuck, and
even if IIR is 0 we still get interrupts... Jiri can you verify the
PIPE*STAT regs have bits set, maybe one or more we don
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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 83
!intel_sdvo_set_tv_format(intel_sdvo))
> return;
>
> + /* We have tried to get input timing in mode_fixup, and filled into
> + * adjusted_mode.
> + */
> + intel_sdvo_get_dtd_from_mode(_dtd, adjusted_mode);
> (void) intel_sdvo_set_input_timi
On Tue, 10 Apr 2012 10:47:49 +0200
Jiri Slaby wrote:
> On 04/09/2012 07:11 PM, Jesse Barnes wrote:
> > On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
> > wrote:
> >
> >> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
> >> wrote:
> >>> I don
use it's not
> needed).
>
> Hopefully this clears things up a bit.
Yep, thanks. Hopefully you'll get your SDVO spec access soon...
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Ty
On Tue, 10 Apr 2012 20:11:29 +0200
Jiri Slaby 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
uck (though it's possible this could be related to
pipelined fencing, if the fences are programmed to point at some funky
memory space).
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: appli
On Wed, 11 Apr 2012 08:29:22 +0200
Michel D?nzer wrote:
> On Die, 2012-04-10 at 11:34 -0700, Jesse Barnes wrote:
> > On Tue, 10 Apr 2012 20:11:29 +0200
> > Jiri Slaby wrote:
> >
> > > On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> > > > So port h
ith a given pipe, along 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 Center
didn't add it to setplane (it would be of limited
usefulness anyway since we really want to flip primary + sprite at the
same time).
--
Jesse Barnes, Intel Open Source Technology Center
wait would at least avoid the issues we are
> >> seeing. ?I will see how awful it looks.
> >
> > Just to confirm its the drm_sysfs_device_add that causes the race we care
> > about.
> >
> > it needs to happen after the driver is happy. Since it calls
> > device_register and that is what triggers udev magic to load the
> > userspace.
> >
> > If you have a userspace app banging on a static device node that might
> > need another set of fun fixes.
>
> Okay the sysfs add and the idr_replace are the things we need to delay.
Since you can still get at things with a static node, it seems like
locking is the real issue here? Is there no mutex we can take across
init to block any openers until we're done?
--
Jesse Barnes, Intel Open Source Technology Center
Many of us really want (and need) a way to set the whole display
configuration atomically, as well as test a global config.
In talking with Rob and Alex here at ELC a bit, I think this may be
enough:
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 2a2acda..2864b02 100644
---
On Wed, 15 Feb 2012 17:59:45 -0500
Adam Jackson wrote:
> On 2/15/12 5:42 PM, Jesse Barnes wrote:
>
> > +#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test
> > it for validity */
> > +
> > +struct drm_mode_set_config {
> &g
401 - 500 of 836 matches
Mail list logo
