On Sat, Nov 02, 2013 at 09:06:58PM -0700, Ben Widawsky wrote:
It is my honor and privilege to submit basic Broadwell support on behalf
of Intel.
The patch series includes support for Broadwell which should bring it up
to feature parity with Haswell. As you'll note, the patches have
received
On Sat, Nov 02, 2013 at 09:07:34PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Just like Haswell, but with the small twist that the panel fitter for pipe A
is
now also in the always-on power well.
v2: Use the new HAS_POWER_WELL macro.
v3: Rebase on top of
On Sat, Nov 02, 2013 at 09:07:36PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
v2: Rebased onto Paulo's MHz-kHz change.
v3: Rebased on top of the Haswell pc8+ adjustements.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Paulo Zanoni
On Sat, Nov 02, 2013 at 09:07:40PM -0700, Ben Widawsky wrote:
GEN8 also needs this workaround.
Not according to the w/a database.
But the register description is the same for both HSW and BDW. Also for
HSW, the w/a doesn't actually say whether we should set or clear the bit.
the default is
On Sat, Nov 02, 2013 at 09:07:38PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
And it inherits some bits from the previous TRANS_CONF (aka PIPE_CONF
on previous gens).
v2: Rebase on to of the pipe config bpp handling rework.
v3: Rebased on top of the
On Sat, Nov 02, 2013 at 09:07:35PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The platforms we currently have all have LPT LP on them. As such, we
have no way to identify the new WPT PCH that will ship with Broadwell.
NOTE: For all purposes relevant to the
On Sat, Nov 02, 2013 at 09:07:37PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
So you can use the panel fitter while the power well is disabled and
you also don't need to set the pipe bit.
v2: Rebased on top of Jesse's pfit refactor, which moved pfit state
into
On Sun, Nov 03, 2013 at 01:05:11PM +0200, Ville Syrjälä wrote:
On Sat, Nov 02, 2013 at 09:07:34PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Just like Haswell, but with the small twist that the panel fitter for pipe
A is
now also in the always-on power
On Sun, Nov 03, 2013 at 12:24:13PM +0100, Daniel Vetter wrote:
On Sun, Nov 03, 2013 at 01:05:11PM +0200, Ville Syrjälä wrote:
On Sat, Nov 02, 2013 at 09:07:34PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Just like Haswell, but with the small twist that the
From: Ville Syrjälä ville.syrj...@linux.intel.com
Like on HSW, trickle feed should always be enabled on BDW.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Not sure this applies directly, I just put it together on top of -nightly.
Thus it's not even compile tested.
I ran into a regression in xf86-video-intel master. X would spin
for several seconds and eventually I'd see a message like:
[ 170.724] kgem_bo_write: failed to write 3600 bytes into BO handle=175: 14
in Xorg.0.log
Bisected it down to the following commit:
commit
Hi all,
New -testing cycle with cool stuff:
- Tons more improvement to the display CRC code. It works now on all
platforms supported by the i915 driver. Also there's an auto
target now for platforms where some ports require a special CRC tap
point.
- More power domain infrastructure work
Hi Chris,
I got a black screen while using your patch.
/sys/kernel/debug/dri/0/i915_gem_objects contents are shown below. The first
time is while the video is running; the second after stopping it. AFAICS,
there is no difference between them.
However, after starting a new video, there is a
Hi Daniel, dear intel experts,
again trying to get the old Fujitsu laptop to work. The problem with the
latest drm-nightly built is that
the system again locks up - if the bios is configured to show an image
only on the internal display and
nothing on the external VGA. If the bios is
On Sun, Nov 03, 2013 at 05:55:37PM +0100, Thomas Richter wrote:
Hi Daniel, dear intel experts,
again trying to get the old Fujitsu laptop to work. The problem with
the latest drm-nightly built is that
the system again locks up - if the bios is configured to show an
image only on the
On Sun, Nov 03, 2013 at 06:12:08PM +0100, Daniel Vetter wrote:
On Sun, Nov 03, 2013 at 05:55:37PM +0100, Thomas Richter wrote:
Hi Daniel, dear intel experts,
again trying to get the old Fujitsu laptop to work. The problem with
the latest drm-nightly built is that
the system again locks
On Sun, Nov 03, 2013 at 01:07:58PM +0200, Ville Syrjälä wrote:
On Sat, Nov 02, 2013 at 09:07:40PM -0700, Ben Widawsky wrote:
GEN8 also needs this workaround.
Not according to the w/a database.
But the register description is the same for both HSW and BDW. Also for
HSW, the w/a doesn't
On 03.11.2013 18:13, Daniel Vetter wrote:
Have you tried my patch to reorder the dvo sequence a bit? That /should/
get all these things right:
http://www.spinics.net/lists/intel-gfx/msg34349.html
There's also a follow-up patch for you to test:
On 03.11.2013 18:13, Daniel Vetter wrote:
Have you tried my patch to reorder the dvo sequence a bit? That /should/
get all these things right:
http://www.spinics.net/lists/intel-gfx/msg34349.html
There's also a follow-up patch for you to test:
On Sun, Nov 03, 2013 at 01:22:52PM +0100, Mark Kettenis wrote:
I ran into a regression in xf86-video-intel master. X would spin
for several seconds and eventually I'd see a message like:
[ 170.724] kgem_bo_write: failed to write 3600 bytes into BO handle=175: 14
in Xorg.0.log
On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter t...@math.tu-berlin.de wrote:
On 03.11.2013 18:13, Daniel Vetter wrote:
Have you tried my patch to reorder the dvo sequence a bit? That /should/
get all these things right:
http://www.spinics.net/lists/intel-gfx/msg34349.html
There's also a
On Sat, Nov 02, 2013 at 09:07:02PM -0700, Ben Widawsky wrote:
@@ -367,7 +385,9 @@ static const struct intel_device_info
intel_haswell_m_info = {
INTEL_HSW_D_IDS(intel_haswell_d_info), \
INTEL_HSW_M_IDS(intel_haswell_m_info), \
INTEL_VLV_M_IDS(intel_valleyview_m_info),
Date: Sun, 3 Nov 2013 19:43:48 +
From: Chris Wilson ch...@chris-wilson.co.uk
On Sun, Nov 03, 2013 at 01:22:52PM +0100, Mark Kettenis wrote:
I ran into a regression in xf86-video-intel master. X would spin
for several seconds and eventually I'd see a message like:
[ 170.724]
On 03.11.2013 22:18, Daniel Vetter wrote:
Hm, that would mean that the cursor is somehow stuck in the enabled state,
despite that we've tried to disabled it very hard. Can you please try out
the below patch? If this doesn't work please take not of the different
WARNINGs you're hitting and
Hi Daniel, dear intel experts,
just another note: I just switched the default depth from 24 to 16 bit
by adding a DefaultDepth into
the screen section of X11. Strangely enough, that gives much *less*
banding than the 24bpp output
Anyhow, 16bpp breaks the gdm login, and 8bpp breaks almost
v2: Squash in drm/i915/bdw: Add BDW to the HAS_DDI check as
suggested by Damien.
v3: Squash in VEBOX enabling from Zhao Yakui yakui.z...@intel.com
v4: Rebase on top of Jesse's patch to extract all pci ids to
include/drm/i915_pciids.h.
v4: Replace Halo by its marketing moniker Iris. Requested
On Sun, Nov 03, 2013 at 09:58:00PM +, Chris Wilson wrote:
On Sat, Nov 02, 2013 at 09:07:02PM -0700, Ben Widawsky wrote:
@@ -367,7 +385,9 @@ static const struct intel_device_info
intel_haswell_m_info = {
INTEL_HSW_D_IDS(intel_haswell_d_info), \
v2: Squash in drm/i915/bdw: Add BDW to the HAS_DDI check as
suggested by Damien.
v3: Squash in VEBOX enabling from Zhao Yakui yakui.z...@intel.com
v4: Rebase on top of Jesse's patch to extract all pci ids to
include/drm/i915_pciids.h.
v4: Replace Halo by its marketing moniker Iris. Requested
All the BARs have the ability to grow.
v2: Pulled out the simulator workaround to a separate patch.
Rebased.
v3: Rebase onto latest vlv patches from Jesse.
v4: Rebased on top of the early stolen quirk patch from Jesse.
v5: Use the new macro names.
s/INTEL_BDW_PCI_IDS_D/INTEL_BDW_D_IDS
Apparently they need the same treatment as primary planes. This fixes
modesetting failures because of stuck cursors (!) on Thomas' i830M
machine.
I've figured while at it I'll also roll it out for the ivb 3 pipe
version of this function. I didn't do this for i845/i865 since Bspec
says the update
On Mon, Nov 4, 2013 at 12:09 AM, Thomas Richter t...@math.tu-berlin.de wrote:
On 03.11.2013 22:18, Daniel Vetter wrote:
Hm, that would mean that the cursor is somehow stuck in the enabled state,
despite that we've tried to disabled it very hard. Can you please try out
the below patch? If
On Mon, Nov 4, 2013 at 12:56 AM, Thomas Richter t...@math.tu-berlin.de wrote:
just another note: I just switched the default depth from 24 to 16 bit by
adding a DefaultDepth into
the screen section of X11. Strangely enough, that gives much *less* banding
than the 24bpp output
That just
32 matches
Mail list logo
