Eric Anholt writes:
> There's a minor behavior change that the event now gets sent to the
> drawable owner rather than the caller of DRI2SwapBuffers.
Yeah, probably not ideal, especially when the GLX drawable is created
using the window XID (as is the case for some older GLX clients). I
don't
Eric Anholt writes:
> I'd prefer to see sbc stay with its current name, since that's its name
> in the specs we're trying to implement (GLX_OML_sync_control,
> GLX_INTEL_swap_event). If you drop the rename from the patch,
>
> Reviewed-by: Eric Anholt
Sounds good.
> I read that as "SBC is
checks for prime buffers in the flink case.
Signed-off-by: Keith Packard
---
intel/intel_bufmgr_gem.c | 50 +---
1 file changed, 43 insertions(+), 7 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index df6fcec..2b7fe07 100644
Daniel Vetter writes:
> Yeah, it unfortunately took a few rounds of kernel fixes and other
> haggling to get the semantics right on this one. The kernel atm promises
> to userspace (minus one big in a racy corner case no one should care
> about, still need to fix that one) that it'll return the
Ville Syrj?l? writes:
> What is this format anyway? -ENODOCS
Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
> If its just an srgb version of ARGB, then I wouldn't really want it
> in drm_fourcc.h. I expect colorspacy stuff will be handled by various
> crtc/plane properties in
Kristian H?gsberg writes:
> I already explained to Keith why we use different sets of format codes
> in the DRI interface, but it's always fun to slam other peoples code.
As we discussed, my complaint isn't so much about __DRI_IMAGE_FOURCC,
but the fact that the __DRIimage interfaces use *both*
Just copying code from the dri2 path to set up the fast color clear state.
This also removes a couple of bogus intel_region_reference calls.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff
.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i965/brw_context.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index bee98e3..64ff855 100644
--- a/src/mesa/drivers
While debugging the libdrm duplicate buffer object adventure, I managed to
temporarily understand object lifetimes in the __DRIimage getBuffers path, and
also to compare that to the DRI2 getBuffers path. Here are a couple of small
fixes.
I haven't looked at the i915 code, but I suspect the first
-off-by: Keith Packard
---
This one took a while to find -- multiple bo_gem structs pointing at
the same gem handle would either cause the object to be destroyed
before we were done using it, or we'd end up sending the same
gem_handle for multiple buffers.
This looks a lot like the named object
Daniel Vetter writes:
> Hm, where do we have the canonical source for all these fourcc codes? I'm
> asking since we have our own copy in the kernel as drm_fourcc.h, and that
> one is part of the userspace ABI since we use it to pass around
> framebuffer formats and format lists.
I think it's
that we send in the
PresentPixmap requests, and that's done by using the same variable for both
roles.
Signed-off-by: Keith Packard
---
This passes the piglet glx-swap-event test.
src/glx/dri3_glx.c | 27 ++-
src/glx/dri3_priv.h | 3 +--
2 files changed, 7 insertions
This allows GL to support the GLX_INTEL_swap_event extension
Signed-off-by: Keith Packard
---
This is the X server side; the mesa patch will be sent shortly (it's tiny)
glx/Makefile.am | 3 ++-
glx/glxcmds.c | 69 +
glx
Always nice to clean up after ourselves.
Signed-off-by: Keith Packard
---
v2: Include changes to dri3_priv.h as well
src/glx/dri3_glx.c | 17 -
src/glx/dri3_priv.h | 5 -
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx
Always nice to clean up after ourselves.
Signed-off-by: Keith Packard
---
Ok, so not having this in the dri3 code led to a bit of extra memory
usage in apps and the X server.
src/glx/dri3_glx.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/glx
, which
works with both the int32_t* and struct xshmfence* versions.
Signed-off-by: Keith Packard
---
libxshmfence will also be providing a HAVE_STRUCT_XSHMFENCE define, so
we could actually check for that and use struct xshmfence when
available. Just using 'void *' avoids a bunch of clutter
ked will get updated by the XCB special event queue used by
DRI3.
Signed-off-by: Keith Packard
---
This patch makes sure that drawables get invalidated when the window
changes size or when SwapBuffers is called; dri3 has only a single
location to smite when things change, so we need to make sure the
up
* to
__IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.
I'll refrain from comments on whether I think having two separate sets of
format defines in dri_interface.h is a good idea or not...
Signed-off-by: Keith Packard
---
This gets iceweasel running with the GL compositor enabled.
include/GL
Eric Anholt writes:
> Keith Packard writes:
>
>> libudev doesn't have a stable API/ABI, and if the application wants to use
>> one
>> version, we'd best not load another into libGL.
>>
>> Signed-off-by: Keith Packard
>
> This looks so simple it's de
Emil Velikov writes:
> On 18/11/13 01:08, Keith Packard wrote:
>> libudev doesn't have a stable API/ABI, and if the application wants to use
>> one
>> version, we'd best not load another into libGL.
>>
>> Signed-off-by: Keith Packard
>> ---
>>
&
Kenneth Graunke writes:
> For non-API facing stuff, you can just use stdbool.h's
> bool/true/false.
tnx. I pushed that to my dri3 branch. Btw, that branch also has some
gallium support for __DRIimageDriverExtension. I don't have any hardware
to test with, so it's surely broken in some major
Emil Velikov writes:
> On 18/11/13 01:08, Keith Packard wrote:
>> libudev doesn't have a stable API/ABI, and if the application wants to use
>> one
>> version, we'd best not load another into libGL.
>>
>> Signed-off-by: Keith Packard
>> ---
&g
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard
---
Sorry for the patch spam; I hadn't rebased in a while and there was a
configure.ac conflict. Here's a version which should apply
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard
---
configure.ac | 5 +--
src/glx/dri3_common.c | 106 +++---
2 files changed, 94
I'm getting some weird results when using vblank_count on my Ivybridge
machine across suspend/resume.
With glxgears running, I suspend the machine. At resume, I see
vblank_count temporarily jump back by a fairly large amount (usually
between 1 and 2 frames). After a short while, it
Christopher James Halse Rogers
writes:
> You've presumably noticed this already, but this is the wrong way round
> - you're passing height * stride as pitch, and stride as size. This
> makes for awesome rendering.
Thanks for catching this; I've flipped them around, and also fixed the
fact that
Eric Anholt writes:
> Keith Packard writes:
>
>> This exposes the kernel API for performing asynchronous flips
>>
>> Signed-off-by: Keith Packard
>
> Reviewed-by: Eric Anholt
I've pushed this to master.
--
keith.packard at intel.com
-- next
This exposes the kernel API for performing asynchronous flips
Signed-off-by: Keith Packard
---
include/drm/drm.h | 1 +
include/drm/drm_mode.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 725bf51..f0b4c16 100644
Kristian H?gsberg writes:
> I'm OK with either approach. It does seem like cleaning up the DRI
> driver interface is orthogonal to enabling the __DRIimage based
> getBuffer callout though.
We should probably not merge what we don't want to maintain though;
let's decide over lunch. I don't think
Kristian H?gsberg writes:
> It just the two older create context functions (which fall back to
> calling driCreateContextAtribs) and allocateBuffer and releaseBuffer.
> The two buffer functions are __DRIbuffer specific of course, but we
> can implement them in terms of __DRIimage in dri_util.c
Kristian H?gsberg writes:
> Having written the GBM and Wayland suport for this, it's pretty clear
> that we just want to use __DRIdri2Extension instead of duplicating
> these functions. Support for the __DRIimage based getBuffers is a
> small incremental patch to src/egl/drivers/dri2:
That
Eric Anholt writes:
I've pushed a patch responding to these comments to my dri3 branch and
will send that out shortly. I will merge those changes with the original
DRI3+Present loader patch so that there is only one commit when the
review process is complete.
> I think I'm going to be griping
Kristian H?gsberg writes:
> We can drop width and height now and just get it from either of the
> returned images. Format is a function of the __DRIconfig and doesn't
> change, so we could make that something you can query from the config
> in the interest of further reducing the number of
Kristian H?gsberg writes:
> I'll take the bait... before the i915/i965 split, this code was only
> needed in this one place. All other drivers are gallium drivers which
> need to convert to galliums enum pipe_format instead of the gl_format
> enum. Anyway, the code certainly looks more at home
Kristian H?gsberg writes:
> The 3.12 kernel let's you get the bo size from lseek on the dma_buf
> fd. I added libdrm support for getting the size that, and if that
> works, it overrides the user provided size:
Yeah, I'm happy just sending the size and not trusting that the kernel
will have the
Eric Anholt writes:
> It seems like we could just stick these things in __DRI_CORE as opposed
> to having another new extension to look up.
Having the driver expose this new extension is how I tell that the
driver is going to actually call the __DRIimage-based loader; the
alternative to a new
Eric Anholt writes:
> Most of my review was going to be whining about yet another (broken)
> copy of dri2CreateNewScreen2. Sounds like you've fixed that.
Yup, figured that out all on my own after I re-read the code -- the only
difference was that I need to look for the DRIimageLoader hooks,
Keith Packard writes:
> This sequence first adds a a couple of new DRIimage extensions to the
> dri/common, dri/i915 and dri/i965 directories which define a
> loader-independent API for managing window system operations.
>
> The last patch adds a new DRI3000 loader using those
Jordan Justen writes:
> After patch 6, this will add SARGB8, right? So, maybe add this to the
> commit message, or separate out adding SARGB8 into a separate commit?
I added the SARGB8 define in patch 4; is there some other separation you
think would be warranted?
Oh, just so everyone knows
Uses the __DRIimage loader interfaces.
Signed-off-by: Keith Packard
---
configure.ac | 12 +-
src/glx/Makefile.am |2 +
src/glx/dri3_common.c | 146 +
src/glx/dri3_glx.c| 1722 +
src/glx/dri3_priv.h | 199 ++
src
, as long as they provide this image interface.
Signed-off-by: Keith Packard
---
include/GL/internal/dri_interface.h | 112 +
src/mesa/drivers/dri/common/dri_util.c| 113 +
src/mesa/drivers/dri/common/dri_util.h| 6
Remove private versions of these functions
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i915/intel_screen.c | 53 ++-
src/mesa/drivers/dri/i965/intel_screen.c | 63 ++--
2 files changed, 8 insertions(+), 108 deletions(-)
diff --git
The __DRI_IMAGE_FORMAT codes are used by the image extension, drivers need to
be able to translate between them. Instead of duplicating this translation in
each driver, create a shared version.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/common/dri_util.c | 62
This format will be used by the i965 driver
Signed-off-by: Keith Packard
---
include/GL/internal/dri_interface.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 48993b9..907aeca 100644
--- a/include/GL/internal
Instead of assuming that the size will be height * pitch, have the caller pass
in the size explicitly.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i915/intel_regions.c | 4 ++--
src/mesa/drivers/dri/i915/intel_regions.h | 2 +-
src/mesa/drivers/dri/i915/intel_screen.c | 2 +-
src
Make an easy place to splice in a DRI3 version of this function
Signed-off-by: Keith Packard
Reviewed-by: Kristian H?gsberg
---
src/mesa/drivers/dri/i915/intel_context.c | 90 +--
src/mesa/drivers/dri/i965/brw_context.c | 22 ++--
2 files changed, 68
This just renames them so that they can be used with the DRI3 extension
without causing too much confusion.
Signed-off-by: Keith Packard
Reviewed-by: Kristian H?gsberg
---
src/mesa/drivers/dri/common/dri_util.c | 58 +-
1 file changed, 29 insertions(+), 29
This sequence first adds a a couple of new DRIimage extensions to the
dri/common, dri/i915 and dri/i965 directories which define a
loader-independent API for managing window system operations.
The last patch adds a new DRI3000 loader using those new interfaces.
Kristian H?gsberg writes:
> I sent a reply to the sourceforge addresses in the original emails,
> but I didn't see it show up in the archives. Trying again with the
> freedesktop addresses.
(sorry for having an ancient shell script with sourceforge addresses in
it)
>> +typedef uint32_t *
>>
This uses the Present extension with DRI3, which includes OML_Sync extension
support.
Signed-off-by: Keith Packard
---
configure.ac| 4 +-
include/GL/internal/dri_interface.h | 1 +
src/glx/dri3_glx.c | 421 ++--
src
This hooks DRI3 support into the GLX layer, the DRI common layer and the Intel
driver.
Signed-off-by: Keith Packard
---
configure.ac | 10 +-
include/GL/internal/dri_interface.h | 158 +++
src/glx/Makefile.am |2 +
src
Returns a prime file descriptor for the specified region.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i915/intel_regions.c | 13 +
src/mesa/drivers/dri/i915/intel_regions.h | 4
src/mesa/drivers/dri/i965/intel_regions.c | 13 +
src/mesa/drivers/dri/i965
Make an easy place to splice in a DRI3 version of this function
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i915/intel_context.c | 90 +--
src/mesa/drivers/dri/i965/brw_context.c | 22 ++--
2 files changed, 68 insertions(+), 44 deletions(-)
diff
This just renames them so that they can be used with the DRI3 extension
without causing too much confusion.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/common/dri_util.c | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/src/mesa
The first four patches prepare the library for DRI3, then the final two
patches add DRI3 and Present support.
Minor changes:
[PATCH 1/6] drivers/dri/common: A few dri2 functions are not actually
[PATCH 2/6] dri/intel: Split out DRI2 buffer update code to separate
[PATCH 3/6] dri/intel: Add
Just copies the IVB code
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 166aa2c..4a118c3 100644
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 37
> Generally I think checking our current sw state instead of reading hw
> registers would be safer, e.g. in case we start to queue up more than
> one pageflip. For async pageflips in benchmark mode "flip as fast as
> you can queue" would be a sensible mode.
Ok, I've moved the tiling checks to the
Daniel Vetter writes:
> On Wed, Jul 24, 2013 at 06:40:16PM -0700, Keith Packard wrote:
>> Daniel Vetter writes:
>>
>> > We could just unconditionally increase the alignement in
>> > intel_pin_and_fence_fb_obj - we already have more strict requirements due
>&
Daniel Vetter dan...@ffwll.ch writes:
On Wed, Jul 24, 2013 at 06:40:16PM -0700, Keith Packard wrote:
Daniel Vetter dan...@ffwll.ch writes:
We could just unconditionally increase the alignement in
intel_pin_and_fence_fb_obj - we already have more strict requirements due
to a bunch of w
Generally I think checking our current sw state instead of reading hw
registers would be safer, e.g. in case we start to queue up more than
one pageflip. For async pageflips in benchmark mode flip as fast as
you can queue would be a sensible mode.
Ok, I've moved the tiling checks to the
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 37
Just copies the IVB code
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 166aa2c
Daniel Vetter writes:
> We could just unconditionally increase the alignement in
> intel_pin_and_fence_fb_obj - we already have more strict requirements due
> to a bunch of w/a in other places. So shouldn't hurt at all really.
That seems like a fine plan; 32kB isn't that onerous. Do you want
Daniel Vetter writes:
> Matching tiling modes is actually already a requirement on gen4+ (since
> the tiling bit and the linear/tiled offset registers can't be changed with
> a MI_DISPLAY_FLIP command).
Async flip has a harder requirement -- you must use X tiling, both
before and after the
Daniel Vetter dan...@ffwll.ch writes:
Matching tiling modes is actually already a requirement on gen4+ (since
the tiling bit and the linear/tiled offset registers can't be changed with
a MI_DISPLAY_FLIP command).
Async flip has a harder requirement -- you must use X tiling, both
before and
Daniel Vetter dan...@ffwll.ch writes:
We could just unconditionally increase the alignement in
intel_pin_and_fence_fb_obj - we already have more strict requirements due
to a bunch of w/a in other places. So shouldn't hurt at all really.
That seems like a fine plan; 32kB isn't that onerous. Do
Daniel Vetter writes:
> Quick comments on the i915 kernel part:
> - Iirc the w/a database has a bunch of entries about async flips. Those
> need to be addressed and annoted with the new w/a tag comment format
> Damien recently created.
Where does this database live?
> - kms_flip needs to
Just copies the IVB code
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 39
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1bcc6b4
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 40
Let applications know whether the kernel supports asynchronous page
flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc.c | 3 +++
drivers/gpu/drm/drm_ioctl.c | 3 +++
include/drm/drm_crtc.h | 3 +++
include/uapi/drm/drm.h | 1 +
4 files changed, 10 insertions
This requests that the driver perform the page flip as soon as
possible, not necessarily waiting for vblank.
Signed-off-by: Keith Packard
---
include/uapi/drm/drm_mode.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include
This lets drivers see the flags requested by the application
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 +++--
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_display.c
Here's a sequence of five patches that exposes an interface to request
of the driver that the page flipping request be executed without
waiting for vblank. It's optional, and drivers can expose whether it
is supported through the existing GETCAP ioctl.
This supports only Ivybridge and Sandybridge
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 6 +
drivers/gpu/drm/i915/intel_display.c | 46
This requests that the driver perform the page flip as soon as
possible, not necessarily waiting for vblank.
Signed-off-by: Keith Packard kei...@keithp.com
---
include/uapi/drm/drm_mode.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/uapi/drm
Here's a sequence of five patches that exposes an interface to request
of the driver that the page flipping request be executed without
waiting for vblank. It's optional, and drivers can expose whether it
is supported through the existing GETCAP ioctl.
This supports only Ivybridge and Sandybridge
This lets drivers see the flags requested by the application
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/drm_crtc.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 +++--
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915
Let applications know whether the kernel supports asynchronous page
flipping.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/drm_crtc.c | 3 +++
drivers/gpu/drm/drm_ioctl.c | 3 +++
include/drm/drm_crtc.h | 3 +++
include/uapi/drm/drm.h | 1 +
4 files changed, 10
Just copies the IVB code
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 39
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 40
Thierry Reding writes:
> That doesn't sound right. Maybe drmIoctl() needs fixing instead. Looking
> at the history, drmIoctl() was introduced to automatically loop if a
> signal was received (commit 8b9ab108ec1f2ba2b503f713769c4946849b3cb2).
> However the ioctl(3p) manpage doesn't mention that
Thierry Reding thierry.red...@gmail.com writes:
That doesn't sound right. Maybe drmIoctl() needs fixing instead. Looking
at the history, drmIoctl() was introduced to automatically loop if a
signal was received (commit 8b9ab108ec1f2ba2b503f713769c4946849b3cb2).
However the ioctl(3p) manpage
"Lespiau, Damien" writes:
> I can't see anything in the docs about an order requirement for those.
Right, the docs don't say anything, which is a bit disconcerting.
> Not sure why the other way does not make sense. Somehow disabling TX
> before RX makes some sense to me (TX enabled without a
"Lespiau, Damien" writes:
> On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard wrote:
>
> @@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct
> drm_i915_private *dev_priv)
> */
> static bool intel_choose_pipe_bpp_
Lespiau, Damien damien.lesp...@intel.com writes:
On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard kei...@keithp.com wrote:
@@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct
drm_i915_private *dev_priv)
*/
static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc
Lespiau, Damien damien.lesp...@intel.com writes:
I can't see anything in the docs about an order requirement for those.
Right, the docs don't say anything, which is a bit disconcerting.
Not sure why the other way does not make sense. Somehow disabling TX
before RX makes some sense to me (TX
Need to turn on the error correction when enabling training or it
might not get enabled in time.
This seems to fix the FDI-B/FDI-C link training problem.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions
Doesn't make sense to disable in the other order.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b099a17
These should probably all look like
enabled |= (1 << pipe)
so that the intent is clear...
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/dr
display_bpc might not have been set before comparing with the
requested mode, so wait until afterwards before comparing with the
supported fdi bandwidth. Not a significant change as any case that
mattered would have worked; this just makes the debug messages look nicer.
Signed-off-by: Keith
Just a bit of cleanup; it appears to have no effect.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7106807
IVB shares 4 lanes between FDI B and FDI C. When sharing, compute the
maximum BPC based on the available bandwidth.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 101 +++---
1 file changed, 94 insertions(+), 7 deletions(-)
diff --git
This is left over from the old PLL sharing code and isn't useful now
that PLLs are shared when possible.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_crt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm
This is the complete set of patches that yield a working 3-pipe mode
setting configuration on my test machines. It does not make DPMS work,
so I still need to figure that out. As the DPMS paths are almost
entirely different from mode setting (whose crazy idea was that,
anyway?), that may take a
display_bpc might not have been set before comparing with the
requested mode, so wait until afterwards before comparing with the
supported fdi bandwidth. Not a significant change as any case that
mattered would have worked; this just makes the debug messages look nicer.
Signed-off-by: Keith
This is the complete set of patches that yield a working 3-pipe mode
setting configuration on my test machines. It does not make DPMS work,
so I still need to figure that out. As the DPMS paths are almost
entirely different from mode setting (whose crazy idea was that,
anyway?), that may take a
These should probably all look like
enabled |= (1 pipe)
so that the intent is clear...
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers
IVB shares 4 lanes between FDI B and FDI C. When sharing, compute the
maximum BPC based on the available bandwidth.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 101 +++---
1 file changed, 94 insertions(+), 7 deletions
This is left over from the old PLL sharing code and isn't useful now
that PLLs are shared when possible.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_crt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b
301 - 400 of 1027 matches
Mail list logo
