2014-10-14 16:43 GMT-03:00 Paulo Zanoni :
> 2014-10-14 16:32 GMT-03:00 Ville Syrjälä :
>> On Tue, Oct 14, 2014 at 02:05:42PM -0300, Paulo Zanoni wrote:
>>> From: Paulo Zanoni
>>>
>>> When I look at BSpec, and at cursor_size_ok() (from the Kernel's
>>> intel_display.c), I see that only 845g and i86
Current chv spec teels we can only use either 16 or 32 bits as precision.
Although in the past VLV went from 16/32 to 32/64 and spec might not be updated,
these precision values brings stability and fixes some issues Wayne was facing.
Cc: Wayne Boyer
Cc: Ville Syrjälä
Signed-off-by: Rodrigo Viv
From: Paulo Zanoni
For some yet-undiscovered reason, when IPS gets enabled, the pipe CRC
changes. Since hsw_enable_ips() doesn't really guarantees to enable
IPS (it depends on package C-states), we can't really predict if IPS
is enabled or disabled while running our CRC tests, so let's just
compl
Just hit this while fuzz-testing, (curiously, no graphics
related stuff was happening, X isn't even loaded on that box).
dmar: DRHD: handling fault status reg 2
dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 7ff000
DMAR:[fault reason 05] PTE Write access is not set
00:02:0 is..
From: Paulo Zanoni
As far as I understand, intel_uncore_early_sanitize() was supposed to
be ran before any register access, but currently
intel_resume_prepare() is ran earlier, and it does register
access. I don't think it should be safe to be calling
I915_{READ,WRITE} without calling intel_uncor
Reorder the function calls in chv/vlv_pre_enable_dp() such that link training
is not initiated before the PHYs come up out of reset. Also check the status
of vlv_wait_port_ready() and only attempt to train if the PHYs are actually
running.
The specification lists the wait for the PHYs as one of th
V2 changes:
- Moved the intel_dp_enable_port() call out of intel_dp_enable() and placed it
before the calls to intel_dp_enable() and vlv_wait_port_ready()
- Cleaned up a spacing issues with the code indents
- Amended the commit message to be under 80 characters per line and expanded
on the des
Jani Nikula writes:
> On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> Only ports B and C have the power sequencer and backlight controls,
>> so complain if we ever try to register an eDP connector on some other
>> port.
>>
>> Signed-off-by: Ville Syrjälä
>
On 10/17/2014 1:59 AM, Ville Syrjälä wrote:
On Fri, Oct 17, 2014 at 11:43:21AM +0300, Jani Nikula wrote:
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Sometimes we seem to get utter garbage from DPCD reads. The resulting
buffer is filled with the same byte, an
On 10/17/2014 2:06 AM, Ville Syrjälä wrote:
On Thu, Oct 16, 2014 at 12:39:29PM -0700, Todd Previte wrote:
On 10/16/2014 10:46 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Sometimes we seem to get utter garbage from DPCD reads. The resulting
buffer is filled with the same byte
On 10/17/2014 1:43 AM, Jani Nikula wrote:
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Sometimes we seem to get utter garbage from DPCD reads. The resulting
buffer is filled with the same byte, and the operation completed without
errors. My HP ZR24w monitor se
On 10/17/2014 1:43 AM, Ville Syrjälä wrote:
On Thu, Oct 16, 2014 at 12:38:55PM -0700, Todd Previte wrote:
On 10/16/2014 10:46 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
to handle hpd we would need to tu
Hi Ville,
I've compiled the list of patches for which I finally have versions that
should fix your comments and still require your r-b tag. You're in luck!
there are also a few additional follow-up patches, some to address your
concerns and one to address a known issue I listed here.
On Thu, Sep
I overlooked the fact that we need to allocate a minimum 8 blocks and
that just allocating the planes depending on how much they need to fetch
from the DDB in proportion of how much memory bw is necessary for the
whole display can lead to cases where we don't respect those minima (and
thus overrun)
Signed-off-by: Damien Lespiau
---
tests/skl_ddb_allocation.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/tests/skl_ddb_allocation.c b/tests/skl_ddb_allocation.c
index ca6b892..4d8e6d1 100644
--- a/tests/skl_ddb_allocation.c
+++ b/tests/skl_ddb_alloc
On Fri, Oct 17, 2014 at 12:47:31PM +0300, Jani Nikula wrote:
> On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Only ports B and C have the power sequencer and backlight controls,
> > so complain if we ever try to register an eDP connector on some other
> >
On Wed, Oct 15, 2014 at 02:15:04PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> In its current place, it just segfaults while trying to access the
> CRTC structures:
>
> [ 9132.421681] Call Trace:
> [ 9132.421707] [] i915_get_crtc_scanoutpos+0x1e8/0x220
> [i915]
> [ 9132.421727] []
>
On Fri, 2014-10-17 at 11:13 +0100, Steven Newbury wrote:
> On Mon, 2014-09-01 at 12:09 +0100, Steven Newbury wrote:
> > I tried building the xorg intel ddx driver with only DRI3 support,
> > with DRI1 and DRI2 disabled.
> >
> > glxinfo says direct rendering is enabled, but gives no core
> > contex
On Mon, 2014-09-01 at 12:09 +0100, Steven Newbury wrote:
> I tried building the xorg intel ddx driver with only DRI3 support,
> with DRI1 and DRI2 disabled.
>
> glxinfo says direct rendering is enabled, but gives no core
> contexts*.
>
> gnome-shell appears to be using software fallback, general
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Only ports B and C have the power sequencer and backlight controls,
> so complain if we ever try to register an eDP connector on some other
> port.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/in
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I managed to fumble the per spline PCS DW11 register defines in:
> commit 9d4f193b077c1973add53e40ff9410a3371900af
Looks like commit 570e2a747bc06cd8620662c5125ec2dc964c511b in my repo.
> Author: Ville Syrjälä
On Fri, Oct 17, 2014 at 11:49:54AM +0300, Jani Nikula wrote:
> On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
> > to handle hpd we would need to turn on vdd to perform aux transfers.
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider.
>
> This is a regression from:
> commit f8bf63fdcb1f82459dae7a3f22ee5ce92f3ea727
> Author: Ville Syrjälä
> Date: Fri Jun 13 13:37:54 2014 +0
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider.
>
> This is a regression from:
> commit f8bf63fdcb1f82459dae7a3f22ee5ce92f3ea727
> Author: Ville Syrjälä
> Date: Fri Jun 13 13:37:54 2014 +0
On Fri, Oct 17, 2014 at 11:43:21AM +0300, Jani Nikula wrote:
> On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Sometimes we seem to get utter garbage from DPCD reads. The resulting
> > buffer is filled with the same byte, and the operation completed withou
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_crt_reset() resets the ADPA register on all gen5+ platforms.
> However the debug message claims it's touching the PCH ADPA register
> which is clearly not what it does on VLV. Drop the PCH part from
> the deb
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
> to handle hpd we would need to turn on vdd to perform aux transfers.
> This would lead to an endless cycle of
> "vdd off -> long hpd -> vdd
On Thu, Oct 16, 2014 at 12:38:55PM -0700, Todd Previte wrote:
>
> On 10/16/2014 10:46 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
> > to handle hpd we would need to turn on vdd to perform aux tran
On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Sometimes we seem to get utter garbage from DPCD reads. The resulting
> buffer is filled with the same byte, and the operation completed without
> errors. My HP ZR24w monitor seems particularly susceptible to this
Hi Dave -
Here's the first batch of fixes for 3.18.
BR,
Jani.
The following changes since commit ebb69c95175609990af708ec90c46530f5a2c819:
drm/i915: Enable pixel replicated modes on BDW and HSW. (2014-10-01 10:01:41
+0200)
are available in the git repository at:
git://anongit.freedeskt
30 matches
Mail list logo
