ady, but that's the direction i915 will
> 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
&
ly the
same trick Linux uses for ASID management on SPARC 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
they should provide 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
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/gpu/drm
From: Kristian H?gsberg
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.c | 8
include/drm
)
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
framebuffer (Daniel)
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/i9
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
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 mis
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
> >>
enabled while disabling crtcs 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
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Gwenole or Sean may be able to help.
> Because my shiny new 65W haswell is really nice and does a "make
> allmodconfig" in half the time of my old machine, but the GPU side has
> been something of a step backwards...
Well we definitely don't want that
nd pfit state, we'll end up with a big fb scanned out into the
wrong sized surface.
To fix this properly, we need to hoist the checks up into
compute_mode_changes (or above), check the actual pfit state and
whether the platform allows pfit disable with pipe active, and only
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 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 crtc->enabl
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,
BX(dev) || HAS_PCH_CPT(dev))
> - 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
= DP_LINK_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
Though in Mesa I still
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
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,
> >
> >
> > Signed-off-by: Todd Previte
>
> Reviewed-by: Jani Nikula
Did this ever go in?
--
Jesse Barnes, Intel Open Source Technology Center
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: 2cb47a9c6d49f2961dcf57f69ff968e
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
---
drive
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
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
y callbacks.
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 al
nyway, please test these out and let me know if they work for you.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Needed for panic and kdb, since we need to avoid taking the mode_config
mutex.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c | 42 +-
1 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers
This allows us to draw to the fbcon buffer in a panic situation, in case
the low level driver can flip to it at panic time.
Signed-off-by: Jesse Barnes
---
drivers/video/console/fbcon.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/console/fbcon.c b
At panic time (i.e. when oops_in_progress is set) we should try a bit
harder to update the screen and make sure output gets to the VT, since
some drivers are capable of flipping back to it.
So make sure we try to unblank and update the display if called from a
panic context.
Signed-off-by: Jesse
On Mon, 12 Apr 2010 10:05:00 +1000
Dave Airlie wrote:
> On Sat, Apr 10, 2010 at 8:11 AM, Jesse Barnes
> wrote:
> > Needed for panic and kdb, since we need to avoid taking the mode_config
> > mutex.
>
> One comment below.
>
> >
> > Signed-off-by: Jes
On Mon, 12 Apr 2010 10:05:00 +1000
Dave Airlie wrote:
> On Sat, Apr 10, 2010 at 8:11 AM, Jesse Barnes
> wrote:
> > Needed for panic and kdb, since we need to avoid taking the mode_config
> > mutex.
>
> One comment below.
Updated patch below.
--
Jesse Barnes, Inte
connector->base.id,
> drm_get_connector_name(connector),
> - old_status, connector->status);
> + connector_status_str(old_status),
> + connector_status_str(connector-&g
*/
> @@ -3041,6 +3024,8 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
> udelay(24);
>
> I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_UNGATE);
> +
> + mutex_unlock(&dev_priv->dpio_lock);
> }
>
> /*
> @@ -4268,6 +4253,8 @@ static void vlv_update_pll(struct drm_crtc *crtc,
> bool is_sdvo;
> u32 temp;
>
> + mutex_lock(&dev_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(&dev_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
___
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 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
&
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
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
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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
y callbacks.
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 al
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ug.cgi?id=54101
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> 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/drm_crtc.c
> ind
to the current 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
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 REPORTI
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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: 2cb47a9c6d49f2961dcf57f69ff968e
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
---
drive
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
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
>
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
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:
> > > > From: Vill
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
ic one's lack register addresses
> for PCH regs ...
> Reviewed-by: Daniel Vetter
Yep, I like it too:
Reviewed-by: Jesse Barnes
--
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 hardware when
> the driver starts and use that if present. But, that might mean that
> you'd get different modes depending on whether the machine booted with
> the lid closed or open, which seems like a bad plan.
More than that, I think eDP *requires* an EDID, and it sounds like even
pp_status,
> + I915_READ(PCH_PP_CONTROL));
> + }
> +}
I'd call it "intel_dp_assert_dp_power" or something more descriptive
(or just assert_panel_power to match the other asserts in
intel_display.c), but other than that this is a nice sanity c
> /* Returns true if the panel was already on when called */
> -static bool ironlake_edp_panel_on (struct intel_dp *intel_dp)
> +static void ironlake_edp_panel_on (struct intel_dp *intel_dp)
> {
Remove the comment too?
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 29 Sep 2011 18:09:42 -0700
Keith Packard wrote:
> Talking to the eDP DDC channel requires that the panel be powered
> up. Wrap both the EDID and modes fetch code with calls to turn the vdd
> power on and back off.
>
These VDD AUX changes look good, ack on all of them.
--
ems pretty much the
> same as people are getting under Mac OS.
As long as you enable RC6. :)
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
nicer; did you get confirmation that the
"wavy VGA" bug was fixed with this series? Overall seems like a good
improvement over our old PCH refclk code...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ver is ruining things, but I believe patch 7
> includes whitespace errors.
Yay excellent.
Now... is keeping the various refclks enabled costing us any power?
IOW, should we be trying to disable them when everything has been
DPMS'd off too?
--
Jesse Barnes, Intel Open Source Technology Center
__
On Mon, 03 Oct 2011 16:18:48 -0700
Keith Packard wrote:
> On Mon, 3 Oct 2011 14:14:23 -0700, Jesse Barnes
> wrote:
>
> > Now... is keeping the various refclks enabled costing us any power?
> > IOW, should we be trying to disable them when everything has been
> >
On Thu, 15 Sep 2011 01:31:00 +0200
Mario Kleiner wrote:
> On Sep 15, 2011, at 12:54 AM, Francisco Jerez wrote:
>
> > Mario Kleiner writes:
> >
> >> On Sep 14, 2011, at 6:02 PM, Keith Packard wrote:
> >>
> >>> On Wed, 14 Sep 2011 10:05:29 -0500, J
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 w
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_
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
+++ b/drivers/gpu/drm/i9
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 a
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 o
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.
&
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
From 13efc0a405d522aad8250fce2dbd05fefb8b8ab0 Mon Sep 17 00:00:00 2001
From: Jesse Barnes
Date: Fri, 22 Apr 2011 14:55:33 -0700
Subject: [PATCH] drm/i915: add SNB video sprite support
The video sprites support various video surface formats natively and can
handle scaling as well. So add support
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 t
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 t
1 - 100 of 905 matches
Mail list logo
