On Mon, Nov 4, 2013 at 12:56 AM, Thomas Richter 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 means we dither d
On Mon, Nov 4, 2013 at 12:09 AM, Thomas Richter 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 this doesn't wo
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 m
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
s/INTEL_B
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
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 by Ben.
v5: Switch
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), \
> > INTEL_HSW_M_IDS(&intel_
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
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 by Ben.
v5: Switch
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 almos
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 whethe
> Date: Sun, 3 Nov 2013 19:43:48 +
> From: Chris Wilson
>
> 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
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)
On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter 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 foll
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 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:
http://www.spinics.net/lists/intel-gfx/msg34350.h
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:
http://www.spinics.net/lists/intel-gfx/msg34350.ht
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 doe
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 a
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 in
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 configured
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 diff
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 f
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 4f41bf3de059c4e0a03fb161fb
From: Ville Syrjälä
Like on HSW, trickle feed should always be enabled on BDW.
Signed-off-by: Ville Syrjälä
---
Not sure this applies directly, I just put it together on top of -nightly.
Thus it's not even compile tested.
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel
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
> > >
> > > Just like Haswell, but with the small twist that the panel fitter
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
> >
> > 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:
On Sat, Nov 02, 2013 at 09:07:37PM -0700, Ben Widawsky wrote:
> From: Paulo Zanoni
>
> 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 the pipe_config.
On Sat, Nov 02, 2013 at 09:07:35PM -0700, Ben Widawsky wrote:
> From: Paulo Zanoni
>
> 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 driver that this point,
On Sat, Nov 02, 2013 at 09:07:38PM -0700, Ben Widawsky wrote:
> From: Paulo Zanoni
>
> 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 pipe_config->dither refact
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 list
On Sat, Nov 02, 2013 at 09:07:36PM -0700, Ben Widawsky wrote:
> From: Paulo Zanoni
>
> v2: Rebased onto Paulo's MHz->kHz change.
>
> v3: Rebased on top of the Haswell pc8+ adjustements.
>
> Reviewed-by: Jani Nikula
> Signed-off-by: Paulo Zanoni (v1)
> Signed-off-by: Daniel Vetter
> ---
> dr
On Sat, Nov 02, 2013 at 09:07:34PM -0700, Ben Widawsky wrote:
> From: Paulo Zanoni
>
> 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 intel_using_power_
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
> rec
32 matches
Mail list logo
