On Thu, May 15, 2014 at 10:52:38AM +0530, Sharma, Shashank wrote:
[...]
> Please note that the color correction methods changes per platform and
> what's valid for one Intel platform may not be valid for other. So the
> atomic modeset should have a clear idea of what is supported on which
> platfor
On Wed, May 14, 2014 at 08:56:33PM -0400, Felix Miata wrote:
> On 2014-04-19 22:19 (GMT-0400) Felix Miata composed:
>
> >Has no one opened a freedesktop.org bug for this? I couldn't find one for
> >i810 changed more recently than 18 months ago.
>
> >I have an openSUSE i810E rev03 test system with
On Wed, May 14, 2014 at 08:51:09PM +0200, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
[...]
> index dd786d84daab..5ff986bd4de4 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1,6 +1,5 @@
> -/**
> - * \file drm_irq.
On Wed, May 14, 2014 at 08:51:10PM +0200, Daniel Vetter wrote:
> We need to start somewhere ... With this the only places left in i915
> where we use pipe integers is in the interrupt handling code. And
> there it actually makes some amount of sense.
Very much welcome addition. Some minor comments
Sounds good to me.
Regards
Shashank
-Original Message-
From: Thierry Reding [mailto:thierry.red...@gmail.com]
Sent: Thursday, May 15, 2014 12:36 PM
To: Sharma, Shashank
Cc: Daniel Vetter; intel-gfx; dri-devel; Purushothaman, Vijay A; Mukherjee,
Indranil; Shankar, Uma; Jindal, Sonika; K
This is pure evil. Userspace, I'm looking at you SNA, repacks batch
buffers on the fly after generation as they are being passed to the
kernel for execution. These batches also contain self-referenced
relocations as a single buffer encompasses the state commands, kernels,
vertices and sampler. Duri
On Wed, 14 May 2014, Knut Petersen wrote:
> On 13.05.2014 22:24, Jesse Barnes wrote:
>> On Tue, 13 May 2014 16:50:12 +0100
>> Chris Wilson wrote:
>>
>>> On Tue, May 13, 2014 at 04:07:37PM +0100, Chris Wilson wrote:
This matches the algorithm used by earlier kernels when selecting the
mo
On Thu, May 15, 2014 at 11:13:01AM +0300, Jani Nikula wrote:
> On Wed, 14 May 2014, Knut Petersen wrote:
> > On 13.05.2014 22:24, Jesse Barnes wrote:
> >> On Tue, 13 May 2014 16:50:12 +0100
> >> Chris Wilson wrote:
> >>
> >>> On Tue, May 13, 2014 at 04:07:37PM +0100, Chris Wilson wrote:
> Th
On Wed, 14 May 2014, Knut Petersen wrote:
> On 13.05.2014 22:24, Jesse Barnes wrote:
>> On Tue, 13 May 2014 16:50:12 +0100
>> Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 1d3f0a9cce31..05beec4badd5 100644
--- a
On Wed, 14 May 2014, Rodrigo Vivi wrote:
> We do have to continue the investigation on the link training side, but
> since 76711 is a critical I'm completely in favor of this workaround for
> now.
>
> I just tested and it worked very well here, so:
>
> Tested-by: Rodrigo Vivi
> Reviewed-by: Rodri
On Mon, 12 May 2014, Aaron Lu wrote:
> On 05/04/2014 03:22 PM, Chris Wilson wrote:
>> 32b * 32b = 32b
>>
>> n = (u64)level * freq; to avoid overflow as you claim.
>
> Updated patch to fix this problem is here, thanks!
Pushed to -fixes with Chris' IRC r-b, thanks for the patch and review.
BR,
Ja
On May-13-2014 3:10 PM, Vandana Kannan wrote:
> On May-13-2014 2:28 PM, Daniel Vetter wrote:
>> On Tue, May 13, 2014 at 01:56:04PM +0530, Vandana Kannan wrote:
>>> On May-12-2014 3:57 PM, Ville Syrjälä wrote:
On Mon, May 05, 2014 at 01:49:31PM +0530, Vandana Kannan wrote:
> Adding relevant
From: Tim Gore
The kms_fence_pin_leak test uses igt_kms.c which in turn
uses cairo. So in Android.mk add this test to the skip list
if we dont have cairo
Issue: VIZ-3894
Signed-off-by: Tim Gore
---
tests/Android.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/And
So I accidentally fixed a check when converting to the new macros and
the kernel never returned -ENOENT for invalid regs. Adjust the test.
Signed-off-by: Daniel Vetter
---
tests/gem_reg_read.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/gem_reg_read.c b/tests/gem_re
On Thu, May 15, 2014 at 02:48:02PM +0530, Vandana Kannan wrote:
> On May-13-2014 3:10 PM, Vandana Kannan wrote:
> > On May-13-2014 2:28 PM, Daniel Vetter wrote:
> >> On Tue, May 13, 2014 at 01:56:04PM +0530, Vandana Kannan wrote:
> >>> On May-12-2014 3:57 PM, Ville Syrjälä wrote:
> On Mon, May
More fallout from
commit c8725f3dc0911d4354315a65150aecd8b7d0d74a
Author: Chris Wilson
Date: Mon Mar 17 12:21:55 2014 +
drm/i915: Do not call retire_requests from wait_for_rendering
is that we can completely fill all of memory using small objects, such
that we exhaust the filp space,
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line mode
is first parsed
On May-15-2014 3:01 PM, Ville Syrjälä wrote:
> On Thu, May 15, 2014 at 02:48:02PM +0530, Vandana Kannan wrote:
>> On May-13-2014 3:10 PM, Vandana Kannan wrote:
>>> On May-13-2014 2:28 PM, Daniel Vetter wrote:
On Tue, May 13, 2014 at 01:56:04PM +0530, Vandana Kannan wrote:
> On May-12-2014
On Thu, May 15, 2014 at 01:44:04PM +0900, Michel Dänzer wrote:
> On 15.05.2014 03:51, Daniel Vetter wrote:
> > @@ -964,8 +1005,13 @@ EXPORT_SYMBOL(drm_vblank_off);
> >
> > /**
> > * drm_vblank_on - enable vblank events on a CRTC
> > - * @dev: DRM device
> > + * @dev: drm device
> > * @crtc:
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config that tries to enable a connector (disabling is easy!).
Based on earlier patches b
On Wed, 14 May 2014, Chris Wilson wrote:
> A single object may be referenced by multiple registers fundamentally
> breaking the static allotment of ids in the current design. When the
> object is used the second time, the physical address of the first
> assignment is relinquished and a second one
From: Deepak S
v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
v3: Fix PCBR condition check during CHV RC6 Enable flag set
v4: Fixup PCBR comment msg. (Chris)
Rebase against latest code (Deak)
Fixup Spurious hunk (Ben)
v5: Fix PCBR and commentis msg (mika)
Signed-off-by: Deepa
Hi Mika,
On the PCBR check comment. I will create a separate patch to address both VLV
and CHV
Thanks
Deepak
On Thursday 15 May 2014 03:27 PM, deepa...@linux.intel.com wrote:
From: Deepak S
v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
v3: Fix PCBR condition check during CHV RC
On Thu, May 15, 2014 at 10:04 AM, Daniel Vetter wrote:
> So I accidentally fixed a check when converting to the new macros and
> the kernel never returned -ENOENT for invalid regs. Adjust the test.
>
> Signed-off-by: Daniel Vetter
Aside: I'm waiting for the QA regression report before pushing t
On Thu, May 15, 2014 at 12:56:48PM +0300, Jani Nikula wrote:
> On Wed, 14 May 2014, Chris Wilson wrote:
> > A single object may be referenced by multiple registers fundamentally
> > breaking the static allotment of ids in the current design. When the
> > object is used the second time, the physica
On Thu, May 15, 2014 at 9:34 AM, Thierry Reding
wrote:
> This seems slightly backwards. Since drm_vblank_get() is what's being
> deprecated here, wouldn't it make more sense to write
> drm_crtc_vblank_get() in terms of struct drm_crtc and make
> drm_vblank_get() call that instead? I can't seem to
On Thu, 08 May 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On SNB the BIOS provided WM memory latency values seem insufficient to
> handle high resolution displays.
>
> In this particular case the display mode was a 2560x1440@60Hz, which
> makes the pixel clock 241.5 MHz.
On Thu, May 15, 2014 at 01:13:21PM +0300, Jani Nikula wrote:
> On Thu, 08 May 2014, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> > +static void snb_wm_latency_quirk(struct drm_device *dev)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + bool changed;
deepa...@linux.intel.com writes:
> From: Deepak S
>
> v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
>
> v3: Fix PCBR condition check during CHV RC6 Enable flag set
>
> v4: Fixup PCBR comment msg. (Chris)
> Rebase against latest code (Deak)
> Fixup Spurious hunk (Ben)
>
> v5: Fix
Mika Kuoppala writes:
> deepa...@linux.intel.com writes:
>
>> From: Deepak S
>>
>> v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
>>
>> v3: Fix PCBR condition check during CHV RC6 Enable flag set
>>
>> v4: Fixup PCBR comment msg. (Chris)
>> Rebase against latest code (Deak)
>> F
On Thu, 15 May 2014, Chris Wilson wrote:
> On Thu, May 15, 2014 at 01:13:21PM +0300, Jani Nikula wrote:
>> On Thu, 08 May 2014, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä
>> > +static void snb_wm_latency_quirk(struct drm_device *dev)
>> > +{
>> > + struct drm_i915_private *dev
On Wed, May 14, 2014 at 01:53:17PM +0100, Chris Wilson wrote:
> A single object may be referenced by multiple registers fundamentally
> breaking the static allotment of ids in the current design. When the
> object is used the second time, the physical address of the first
> assignment is relinquish
On Thu, May 15, 2014 at 12:10:16PM +0200, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 9:34 AM, Thierry Reding
> wrote:
> > This seems slightly backwards. Since drm_vblank_get() is what's being
> > deprecated here, wouldn't it make more sense to write
> > drm_crtc_vblank_get() in terms of struct
On Thu, May 15, 2014 at 01:34:44PM +0300, Jani Nikula wrote:
> On Thu, 15 May 2014, Chris Wilson wrote:
> > On Thu, May 15, 2014 at 01:13:21PM +0300, Jani Nikula wrote:
> >> On Thu, 08 May 2014, ville.syrj...@linux.intel.com wrote:
> >> > From: Ville Syrjälä
> >> > +static void snb_wm_latency_qui
On Thu, 15 May 2014, Ville Syrjälä wrote:
> On Thu, May 15, 2014 at 01:34:44PM +0300, Jani Nikula wrote:
>> On Thu, 15 May 2014, Chris Wilson wrote:
>> > On Thu, May 15, 2014 at 01:13:21PM +0300, Jani Nikula wrote:
>> >> On Thu, 08 May 2014, ville.syrj...@linux.intel.com wrote:
>> >> > From: Vill
On Thu, May 15, 2014 at 12:42 PM, Thierry Reding
wrote:
> On Thu, May 15, 2014 at 12:10:16PM +0200, Daniel Vetter wrote:
>> On Thu, May 15, 2014 at 9:34 AM, Thierry Reding
>> wrote:
>> > This seems slightly backwards. Since drm_vblank_get() is what's being
>> > deprecated here, wouldn't it make m
This is pure evil. Userspace, I'm looking at you SNA, repacks batch
buffers on the fly after generation as they are being passed to the
kernel for execution. These batches also contain self-referenced
relocations as a single buffer encompasses the state commands, kernels,
vertices and sampler. Duri
On Thu, May 15, 2014 at 11:47:37AM +0530, sourab.gu...@intel.com wrote:
> From: Sourab Gupta
>
> Using MMIO based flips on Gen5+ for Media power well residency optimization.
> The blitter ring is currently being used just for command streamer based
> flip calls. For pure 3D workloads, with MMIO f
From: Deepak S
v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
v3: Fix PCBR condition check during CHV RC6 Enable flag set
v4: Fixup PCBR comment msg. (Chris)
Rebase against latest code (Deak)
Fixup Spurious hunk (Ben)
v5: Fix PCBR and commentis msg (mika)
Signed-off-by: Deepa
On Thu, May 15, 2014 at 01:17:12PM +0100, Chris Wilson wrote:
> This is pure evil. Userspace, I'm looking at you SNA, repacks batch
> buffers on the fly after generation as they are being passed to the
> kernel for execution. These batches also contain self-referenced
> relocations as a single buff
On Thu, May 15, 2014 at 10:25:48AM +0100, tim.g...@intel.com wrote:
> From: Tim Gore
>
> The kms_fence_pin_leak test uses igt_kms.c which in turn
> uses cairo. So in Android.mk add this test to the skip list
> if we dont have cairo
>
> Issue: VIZ-3894
> Signed-off-by: Tim Gore
Merged, thanks f
On Thu, May 15, 2014 at 02:46:32PM +0200, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 01:17:12PM +0100, Chris Wilson wrote:
> > This is pure evil. Userspace, I'm looking at you SNA, repacks batch
> > buffers on the fly after generation as they are being passed to the
> > kernel for execution. Th
Leftover from the old days of ums and should be used any longer. Since
commit 29935554b384b1b3a7377d6f0b03b21d18a61683
Author: Laurent Pinchart
Date: Wed May 30 00:58:09 2012 +0200
drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers
it is a complete no-Op for kms drivers.
v2: Fix up mang
- Integrate into the drm DocBook
- Disable kerneldoc for functions not exported to drivers.
- Properly document the new drm_vblank_on|off and add cautious
comments explaining when drm_vblank_pre|post_modesets shouldn't be
used.
- General polish and OCD.
v2: Polish as suggested by Thierry.
Cc:
> > But looking at the code a better way should be:
> > 1. Create new bo, wrap it in a kms fb.
> > 2. Slap busy load onto that bo, e.g. reapeatedly fill it with the blitter.
> > 3. Enable evil interruptor (igt_fork_signal_helper).
> > 4. Submit pageflip
> >
> > -> Boom since the set_cache_level wil
On Thu, May 15, 2014 at 01:14:54PM +, Mateo Lozano, Oscar wrote:
> > > But looking at the code a better way should be:
> > > 1. Create new bo, wrap it in a kms fb.
> > > 2. Slap busy load onto that bo, e.g. reapeatedly fill it with the blitter.
> > > 3. Enable evil interruptor (igt_fork_signal_
We need to start somewhere ... With this the only places left in i915
where we use pipe integers is in the interrupt handling code. And
there it actually makes some amount of sense.
v2:
- Polish kerneldoc a bit (Thierry).
- Drop "dev" parameter since it's unecessary.
- Split out i915 changes (Thie
Only the low-level irq handling functions still use integer crtc
indices with this. But fixing that will require a lot more sugery
and some good ideas for backwards compat with old ums userspace.
Both in drivers and in the drm core.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dis
On Thu, May 15, 2014 at 01:14:54PM +, Mateo Lozano, Oscar wrote:
> > > But looking at the code a better way should be:
> > > 1. Create new bo, wrap it in a kms fb.
> > > 2. Slap busy load onto that bo, e.g. reapeatedly fill it with the blitter.
> > > 3. Enable evil interruptor (igt_fork_signal_
On Fri, May 02, 2014 at 06:48:52PM -0700, Ben Widawsky wrote:
> On Fri, May 02, 2014 at 09:35:20PM +0100, Chris Wilson wrote:
> > On Fri, May 02, 2014 at 10:00:01AM -0700, Ben Widawsky wrote:
> > > On Fri, May 02, 2014 at 04:00:25PM +0300, Ville Syrjälä wrote:
> > > > On Fri, May 02, 2014 at 09:38:
> I've done a very cursory read of this, and my original comment from my
> original high-level review on the internal list still stands: I'm freaked out
> by how
> invasive this is into the existing ring code. All the changes in i915_dma.c
> look
> very suspicious, since that code is for the lega
> -Original Message-
> From: Lespiau, Damien
> Sent: Wednesday, May 14, 2014 2:26 PM
> To: Daniel Vetter
> Cc: Mateo Lozano, Oscar; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
> s/intel_ring_buffer/intel_engine
>
> On Tue, May 13, 2014 at 03:28:27PM +
Robert Navarro gmail.com> writes:
>
> Finally got around to compiling this for my system, there were a few issues
> with the build scripts on the latest Ubuntu.
>
> Currently running 3.15.0-rc3-custom-drm-intel-nightly-bug70254+ with no
> issues thus far.
>
> I'll give a few more days just to
On Thu, May 15, 2014 at 05:05:05PM +0300, Ville Syrjälä wrote:
> > I must be missing something important. The FBC buffer is the only one
> > requiring a non-zero offset from the base of stolen memory.
>
> Nothing important can be placed there since the CS apparently writes
> there without anyone e
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On Tue, Apr 29, 2014 at 4:05 PM, wrote:
> From: Ville Syrjälä
>
> Currently the logic to fix up the frame counter on gen3/4 assumes that
> start of vblank occurs at vblank_start*htotal pixels, when in fact
> it occurs htotal-hsync_s
Reviewed the patch & it looks good.
Just to confirm, this patch tries to address the case of a tiny window of
transition, i.e. from the 1st field (last half line) to 2nd field (first
half line).
Reviewed-by: "Akash Goel "
On Tue, Apr 29, 2014 at 4:05 PM, wrote:
> From: Ville Syrjälä
>
> In in
On Wed, Apr 30, 2014 at 10:07:02AM -0700, Matt Roper wrote:
> In a future patch, we'll allow the primary plane to be disabled by
> userspace via the universal plane API. If a modeset is requested while
> the primary plane is disabled, crtc->primary->fb will be NULL which
> generally triggers a ful
More pretty!
Signed-off-by: Daniel Vetter
---
tests/pm_pc8.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/pm_pc8.c b/tests/pm_pc8.c
index d36350370ba2..323e0729b9e6 100644
--- a/tests/pm_pc8.c
+++ b/tests/pm_pc8.c
@@ -605,8 +605,7 @@ static void test_i2c(struct mod
On Mon, Apr 14, 2014 at 11:18:24AM +0530, Shobhit Kumar wrote:
> In VBT fields operation mode is 0 for Video mode and 1 for command mode.
> This field will be directly used as is in generic panel driver. So
> adjust accordingly.
>
> Signed-off-by: Shobhit Kumar
Reviewed-by: Damien Lespiau
--
On Mon, Apr 14, 2014 at 11:18:25AM +0530, Shobhit Kumar wrote:
> Signed-off-by: Shobhit Kumar
Reviewed-by: Damien Lespiau
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Apr 14, 2014 at 11:18:26AM +0530, Shobhit Kumar wrote:
> Added as generic parameters which will be initialized in the panel
> driver and are specific to panels.
>
> Backlight delays have also kept as placeholders and will be used used
> once we have MIPI backlight enabling support
>
> Sig
Nice illustration of the various events in a Video signal.
Reviewed-by: "Akash Goel "
On Tue, Apr 29, 2014 at 4:05 PM, wrote:
> From: Ville Syrjälä
>
> The docs are a bit lacking when it comes to describing when certain
> timing related events occur in the hardware. Draw a picture which
> tri
On Thu, May 15, 2014 at 5:29 PM, Jiri Kosina wrote:
>> > Note that X do work somehow after resume (I can't switch virtual
>> > desktops and dialog is stuck on screen, but it is not complete
>> > failure). I can do ctrl-alt-f1 and get to useful prompt.
>>
>> Oops. You were right. It seems it is dup
Hi Team:
I work for AAEON an Asus company who makes embedded, long life, motherboards. I
am running into a situation with a large customer of mine that wants to use a
15.6" LCD Panel,
https://dl.dropboxusercontent.com/u/52392/TFT-LCD%2BPreliminary%2BSpecification%2BG156BGE-L01%2Bver%2B1.0.pdf
On Wed, Apr 30, 2014 at 10:07:03AM -0700, Matt Roper wrote:
> Intel hardware allows the primary plane to be disabled independently of
> the CRTC. Provide custom primary plane handling to allow this.
>
> v6:
> - Pass rectangles to primary helper check function and get plane
>visibility back.
This is pure evil. Userspace, I'm looking at you SNA, repacks batch
buffers on the fly after generation as they are being passed to the
kernel for execution. These batches also contain self-referenced
relocations as a single buffer encompasses the state commands, kernels,
vertices and sampler. Duri
With ppgtt, it is no longer correct to mark an object as
map_and_fenceable if we simply unbind it from the global gtt. This has
consequences during execbuffer where we simply use
obj->map_and_fenceable in use_cpu_reloc() to decide which access method
to use for writing into the object. Now for a pp
Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make
We kinda have testdisplay for this ... and doing this tends to take
forever.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77709
Signed-off-by: Daniel Vetter
---
tests/kms_render.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/tests/kms_render.c b/test
In a future patch, we'll allow the primary plane to be disabled by
userspace via the universal plane API. If a modeset is requested while
the primary plane is disabled, crtc->primary->fb will be NULL which
generally triggers a full modeset (except in fastboot situations). If
we detect that the cr
On Thu, May 15, 2014 at 06:52:28PM +0300, Ville Syrjälä wrote:
...
>
> > + };
> > + bool visible;
> > + int ret;
> > +
> > + ret = drm_primary_helper_check_update(plane, crtc, fb,
> > + &src, &dest, &clip,
> > +
On Mon, Apr 14, 2014 at 11:18:27AM +0530, Shobhit Kumar wrote:
> This driver makes use of the generic panel information from the VBT.
> Panel information is classified into two - panel configuration and panel
> power sequence which is unique to each panel. The generic driver uses the
> panel config
On Thu, May 15, 2014 at 09:37:55AM -0700, Matt Roper wrote:
> On Thu, May 15, 2014 at 06:52:28PM +0300, Ville Syrjälä wrote:
> ...
> >
> > > + };
> > > + bool visible;
> > > + int ret;
> > > +
> > > + ret = drm_primary_helper_check_update(plane, crtc, fb,
> > > +
From: Ville Syrjälä
The docs are a bit lacking when it comes to describing when certain
timing related events occur in the hardware. Draw a picture which
tries to capture the most important ones.
v2: Clarify a few details (Imre)
v3: Add HSW+ HDMI scanline counter numbers
Acked-by: Imre Deak
Re
From: Ville Syrjälä
On gen2 the scanline counter behaves a bit differently from the
later generations. Instead of adding one to the raw scanline
counter value, we must subtract one.
On HSW/BDW the scanline counter requires a +2 adjustment on HDMI
outputs. DP outputs on the on the other require t
by correctly displaying result and requested.
Suggested-by: Imre Deak
Reviewed-by: Ville Syrjälä
Signed-off-by: Mika Kuoppala
---
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/drm/i915/intel_
From: Deepak S
In BDW, Apart from unmasking up/down threshold interrupts. we need
to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
Interface.
v2: Add (1<<31) mask (Ville)
v3: Add Gen check for the mask (ville)
Reviewed-by: Ville Syrjälä
Signed-off-by: Deepak S
---
dr
From: Ben Widawsky
Almost all of it is reusable from the existing code. The primary
difference is we need to do even less in the interrupt handler, since
interrupts are not shared in the same way.
The patch is mostly a copy-paste of the existing snb+ code, with updates
to the relevant parts requ
If we dont have semaphores enabled, we allocate 4
dwords for signalling. But end up emitting more regardless.
Fix this by bailing out early if semaphores are not enabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78274
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78283
Sign
Everything should be in place so enable rc6/rps for bdw.
Reviewed-by: Ville Syrjälä
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
i
On Thu, May 15, 2014 at 08:58:07PM +0300, Mika Kuoppala wrote:
> If we dont have semaphores enabled, we allocate 4
> dwords for signalling. But end up emitting more regardless.
>
> Fix this by bailing out early if semaphores are not enabled.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
To Domonik,
Your dmesg log confirms that you have a KMS issue (you booted this with
KMS right)? I've extracted the important parts (stack traces) below.
I'll be looking into the issue, I am also cc'ing this to the Intel
mailing list.
From,
Mark
[
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
v7:
- Clip primary plane to invisible when crtc is disabled since
intel_crtc->config.pipe_src_{w,h} may be garbage otherwise.
- Unpin old fb before pinning n
On Thu, May 15, 2014 at 08:00:48PM +0300, Ville Syrjälä wrote:
> On Thu, May 15, 2014 at 09:37:55AM -0700, Matt Roper wrote:
> > On Thu, May 15, 2014 at 06:52:28PM +0300, Ville Syrjälä wrote:
> > ...
> > >
> > > > + };
> > > > + bool visible;
> > > > + int ret;
> > > > +
> > > >
Add a simple test to exercise universal plane support.
v3:
- For testing while crtc is off, switch between several different
primary plane fb's before reenabling the crtc. This will help
catch pin/unpin mistakes.
v2:
- Test that pageflips error out gracefully when the primary plane
is
On Thu, 15 May 2014 10:54:36 +0100
Chris Wilson wrote:
> i915.ko has a custom fbdev initialisation routine that aims to preserve
> the current mode set by the BIOS, unless overruled by the user. The
> user's wishes are determined by what, if any, mode is specified on the
> command line (via the v
On Thu, 15 May 2014 10:55:41 +0100
Chris Wilson wrote:
> In the move over to use BIOS connector configs, we lost the ability to
> force a specific set of connectors on or off. Try to remedy that by
> dropping back to the old behavior if we detect a hard coded connector
> config that tries to ena
On Thu, May 15, 2014 at 12:38:01PM -0700, Jesse Barnes wrote:
> On Thu, 15 May 2014 10:55:41 +0100
> Chris Wilson wrote:
>
> > In the move over to use BIOS connector configs, we lost the ability to
> > force a specific set of connectors on or off. Try to remedy that by
> > dropping back to the o
Hi Daniel,
Thank you for the patch.
On Thursday 15 May 2014 15:00:08 Daniel Vetter wrote:
> Leftover from the old days of ums and should be used any longer. Since
>
> commit 29935554b384b1b3a7377d6f0b03b21d18a61683
> Author: Laurent Pinchart
> Date: Wed May 30 00:58:09 2012 +0200
>
> drm
On Thu, May 15, 2014 at 04:06:56PM +0100, Damien Lespiau wrote:
> On Mon, Apr 14, 2014 at 11:18:26AM +0530, Shobhit Kumar wrote:
> > Added as generic parameters which will be initialized in the panel
> > driver and are specific to panels.
> >
> > Backlight delays have also kept as placeholders and
On Thu, May 15, 2014 at 12:35:17PM -0700, Matt Roper wrote:
> On Thu, May 15, 2014 at 08:00:48PM +0300, Ville Syrjälä wrote:
> > On Thu, May 15, 2014 at 09:37:55AM -0700, Matt Roper wrote:
> > > On Thu, May 15, 2014 at 06:52:28PM +0300, Ville Syrjälä wrote:
> > > ...
> > > >
> > > > > + };
> >
On Thu, May 15, 2014 at 02:17:23PM +, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Lespiau, Damien
> > Sent: Wednesday, May 14, 2014 2:26 PM
> > To: Daniel Vetter
> > Cc: Mateo Lozano, Oscar; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i
On Thu, May 15, 2014 at 10:49:52PM +0200, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 12:35:17PM -0700, Matt Roper wrote:
> > On Thu, May 15, 2014 at 08:00:48PM +0300, Ville Syrjälä wrote:
> > > On Thu, May 15, 2014 at 09:37:55AM -0700, Matt Roper wrote:
> > > > On Thu, May 15, 2014 at 06:52:28P
On Thu, May 15, 2014 at 02:15:44PM +, Mateo Lozano, Oscar wrote:
> > I've done a very cursory read of this, and my original comment from my
> > original high-level review on the internal list still stands: I'm freaked
> > out by how
> > invasive this is into the existing ring code. All the cha
On Thu, May 15, 2014 at 04:55:25PM +0100, Chris Wilson wrote:
> With ppgtt, it is no longer correct to mark an object as
> map_and_fenceable if we simply unbind it from the global gtt. This has
> consequences during execbuffer where we simply use
> obj->map_and_fenceable in use_cpu_reloc() to decid
On Thu, May 15, 2014 at 08:58:11PM +0300, Mika Kuoppala wrote:
> Everything should be in place so enable rc6/rps for bdw.
>
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Mika Kuoppala
Merged all 5 patches, thanks. Now that we have the prerequisites it's time
to give runtime pm on bdw another sh
On Thu, May 15, 2014 at 01:59:39PM -0700, Matt Roper wrote:
> On Thu, May 15, 2014 at 10:49:52PM +0200, Daniel Vetter wrote:
> > On Thu, May 15, 2014 at 12:35:17PM -0700, Matt Roper wrote:
> > > On Thu, May 15, 2014 at 08:00:48PM +0300, Ville Syrjälä wrote:
> > > > On Thu, May 15, 2014 at 09:37:55A
On Mon, May 05, 2014 at 06:17:29PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Squashed some of the patches and created a new patch series. Addressed review
> comments on most of the patches.
>
> Ben Widawsky (1):
> drm/i915/bdw: Implement a basic PM interrupt handler
>
> Dee
On Thu, May 15, 2014 at 11:20:39PM +0200, Daniel Vetter wrote:
> > > > Ah, you're right. I was conflating explicit disables (fb=0) with
> > > > implicit disables (clipped to invisible). I think the v7 I just sent
> > > > should handle this properly...for the implicit disable case we leave the
> >
On Mon, 2014-05-12 at 21:38 +0200, Daniel Vetter wrote:
> On Mon, May 12, 2014 at 01:30:39PM -0600, Alex Williamson wrote:
> > On Mon, 2014-05-12 at 21:08 +0200, Daniel Vetter wrote:
> > > On Fri, May 09, 2014 at 02:20:41PM -0600, Alex Williamson wrote:
> > > > Commit 81b5c7bc found that the curren
1 - 100 of 131 matches
Mail list logo
