Use helper functions to simplify _DSM related code in i915 driver.
Function intel_dsm() is used to check functions supported by ACPI _DSM
method, but it has strange check for special value 0x8002. After
digging into nouveau driver, I think the check is copied from nouveau
driver and is useless
The ring will emit too many if semaphores are disabled since we do not
add the correct number to num_dwords anymore.
This was introduced:
commit 52ed23253b68e1cf154b03d91bed619504cf955b
Author: Ben Widawsky
Date: Mon Dec 16 20:50:38 2013 -0800
drm/i915: Don't emit mbox updates without sema
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_pm.c between commit fec8cba306f9 ("drm/i915:
use crtc_htotal in watermark calculations to match fastboot v2") from
Linus' tree and commit 96f90c5421aa ("drm/i915: Move ILK/SNB/IVB over to
the HSW WM
On Tue, Dec 17, 2013 at 10:14 PM, Chris Wilson wrote:
> On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote:
>> On Mon, 16 Dec 2013, Chris Wilson wrote:
>> > If we fail to remove a conflicting fb driver, we need to abort the
>> > loading of the second driver to avoid likely kernel panics.
Chris Wilson writes:
> Ok, so as no vgaarb_clients have yet been registered and so the call to
> grab the IO resource does not actually disable VGA IO routing to the
> nvidia card.
Yikes! This explains a lot.
> If you care to update the changelog to explain the problem is that
> vgaarb is ineff
On Tue, Dec 17, 2013 at 11:42:11PM +0100, Daniel Vetter wrote:
> But only when we indeed set up a gtt mapping. We need this since the
> vma also holds a pages_pin_count, on top of the unconditional
> pages_pin_count we grab for all stolen objects (to avoid swap-out).
>
> This should avoid a pages_
On Tue, Dec 17, 2013 at 07:14:27PM +, Chris Wilson wrote:
> On Mon, Dec 16, 2013 at 08:50:48PM -0800, Ben Widawsky wrote:
>
> Refactoring semaphore error state capture in preparation for future
> hardware support.
>
> > Signed-off-by: Ben Widawsky
>
> A trivial explanation for a trivial pat
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
wait on is all well defined by the table in the previous patch. There is
nothing else different from previous GEN's semaphore synchronization
code.
v2: Update macros to not require the other ring's ring->id (Chris)
v3: Use a c
A couple patches in the upcoming rework of semaphores will break if
semaphores are toggled by the user at various times. Since the code
cleanups there seem to be an overall win, and toggling semaphores at
runtime is not a terribly useful thing to do, simply make the module
parameter read-only.
Cc:
Semaphore signalling works similarly to previous GENs with the exception
that the per ring mailboxes no longer exist. Instead you must define
your own space, somewhere in the GTT.
The comments in the code define the layout I've opted for, which should
be fairly future proof. Ie. I tried to define
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fi
The BIOS or boot loader will generally create an initial display
configuration for us that includes some set of active pipes and
displays. This routine tries to figure out which pipes and connectors
are active and stuffs them into the crtcs and modes array given to us by
the drm_fb_helper code.
S
On Tue, Dec 17, 2013 at 10:58:51PM +0100, Daniel Vetter wrote:
> On Tue, Dec 17, 2013 at 10:30 PM, Jesse Barnes
> wrote:
> > So in the unlikely event that the fb helper code fails I don't want to
> > fall over.
> >
> > But that shouldn't happen in practice. I only have the checks in place
> > to
On Tue, Dec 17, 2013 at 02:02:23PM -0800, Ben Widawsky wrote:
> On Tue, Dec 17, 2013 at 07:24:41PM +, Chris Wilson wrote:
> > On Mon, Dec 16, 2013 at 08:50:38PM -0800, Ben Widawsky wrote:
> > > Aside from the fact that it leaves confusing dumps on error capture, it
> > > is entirely unnecessary
Allocate this struct instead, so we can re-use another allocated
elsewhere if needed.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 27 +++
3 files chang
Along with refcounting changes and breakage.
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 39 ++
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_fbdev.c | 19 -
4 files cha
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
v2: update for new pitch_for_width function (Jesse)
comment how
For use by get_plane_config.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0b8a058a..367d64d 100644
--- a
We only need to init the reg offset for DPIO once, but we need to reset
DPIO at resume time and at init time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
Just add an early init since we may need to access DPIO regs early on.
The init call in modeset_init_hw is also needed for the resume case,
when we need to reset DPIO to keep things happy.
v2: split reset and reg init
v3: split patches (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i9
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2d20390..f91cb12 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2119,9 +2119,9
We want to do this early on before we try to fetch the plane config,
which depends on some of the pipe config state.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_disp
But only when we indeed set up a gtt mapping. We need this since the
vma also holds a pages_pin_count, on top of the unconditional
pages_pin_count we grab for all stolen objects (to avoid swap-out).
This should avoid a pages_pin_count underrun when cleaning up
framebuffers objects taken over from
On Tue, Dec 17, 2013 at 07:24:41PM +, Chris Wilson wrote:
> On Mon, Dec 16, 2013 at 08:50:38PM -0800, Ben Widawsky wrote:
> > Aside from the fact that it leaves confusing dumps on error capture, it
> > is entirely unnecessary, and potentially harmful in cases like BDW,
> > where the instruction
On Tue, Dec 17, 2013 at 10:30 PM, Jesse Barnes wrote:
>> On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes
>> wrote:
>> >> On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
>> >> > @@ -333,7 +535,8 @@ MODULE_LICENSE("GPL and additional rights");
>> >> > void intel_fbdev_output_poll_cha
On Mon, Dec 16, 2013 at 08:50:38PM -0800, Ben Widawsky wrote:
> Aside from the fact that it leaves confusing dumps on error capture, it
> is entirely unnecessary, and potentially harmful in cases like BDW,
> where the instruction has changed.
>
> In reality (seemingly), this will have no behaviora
On Tue, Dec 17, 2013 at 10:04 PM, Jesse Barnes wrote:
>> > Hm yeah the ownership is less clear in the CONFIG_FB=n case. I think
>> > the driver will own the buffer, and it'll get dropped on the first mode
>> > set with a new buffer. But even then there will be no process to deref
>> > the object
On Tue, 17 Dec 2013 19:29:00 +
Chris Wilson wrote:
> On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
> > int intel_fbdev_init(struct drm_device *dev)
> > @@ -268,17 +461,25 @@ int intel_fbdev_init(struct drm_device *dev)
> > struct drm_i915_private *dev_priv = dev->dev_priv
On Tue, 17 Dec 2013 22:17:22 +0100
Daniel Vetter wrote:
> On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes
> wrote:
> >> On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
> >> > @@ -333,7 +535,8 @@ MODULE_LICENSE("GPL and additional rights");
> >> > void intel_fbdev_output_poll_chang
On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes wrote:
>> On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
>> > @@ -333,7 +535,8 @@ MODULE_LICENSE("GPL and additional rights");
>> > void intel_fbdev_output_poll_changed(struct drm_device *dev)
>> > {
>> > struct drm_i915_private *
On Tue, 17 Dec 2013 10:34:39 +
Chris Wilson wrote:
> On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
> > @@ -333,7 +535,8 @@ MODULE_LICENSE("GPL and additional rights");
> > void intel_fbdev_output_poll_changed(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev
On Tue, 17 Dec 2013 10:03:12 +
Chris Wilson wrote:
> On Mon, Dec 16, 2013 at 04:34:26PM -0800, Jesse Barnes wrote:
> > + if (INTEL_INFO(dev)->gen >= 4) {
> > + if (plane_config->tiled)
> > + offset = I915_READ(DSPTILEOFF(plane));
> > + else
> > +
On Tue, 17 Dec 2013 09:38:36 +0100
Daniel Vetter wrote:
> On Mon, Dec 16, 2013 at 04:01:41PM -0800, Jesse Barnes wrote:
> > On Sat, 14 Dec 2013 12:01:47 +0100
> > Daniel Vetter wrote:
> > > But I still think the fb lifetime management is a bit broken here and we
> > > need a few small changes:
>
VGA detection requires the reference clock to be on, so make sure this
is the case.
This fixes VGA hotplug/manual detection where all pipes are off and so
we would normally disable all clocks.
v2:
- Instead of disabling PSR clock gating, force the reference clock on
through the DPLL_A register.
On Tue, Dec 17, 2013 at 6:06 PM, Paulo Zanoni wrote:
> 2013/12/17 Rodrigo Vivi :
>> Signed-off-by: Rodrigo Vivi
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_dp.c | 6 +++---
>> drivers/gpu/drm/i915/intel_drv.h | 1 -
>> 3 files changed, 4 insertions(+), 4 dele
On Mon, Dec 16, 2013 at 08:50:45PM -0800, Ben Widawsky wrote:
> Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
> wait on is all well defined by the table in the previous patch. There is
> nothing else different from previous GEN's semaphore synchronization
> code.
>
> v2: U
On Tue, Dec 17, 2013 at 10:17:24AM -0800, Keith Packard wrote:
> Chris Wilson writes:
>
> > The bspec still says we must assert SR01 bit5 prior to disabling the VGA
> > plane.
> >
> > Perhaps the test should be whether (vga_reg & VGA_DISP_DISABLE) == 0 and
> > do nothing if the plane is already o
On Sat, 2013-12-14 at 20:38 -0200, Rodrigo Vivi wrote:
> From: Imre Deak
>
> At least on my VLV stepping VGA detection doesn't work in certain cases.
> One such case is when all pipes are off and VGA is plugged in. Another
> case reported by Joonas Lahtinen (also on the same stepping) is booting
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
> int intel_fbdev_init(struct drm_device *dev)
> @@ -268,17 +461,25 @@ int intel_fbdev_init(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> int ret;
>
> - ifbdev = kzalloc(sizeof(*ifbd
On Mon, Dec 16, 2013 at 08:50:44PM -0800, Ben Widawsky wrote:
> +static int gen8_rcs_signal(struct intel_ring_buffer *signaller,
> +unsigned int num_dwords)
> +{
> +#define MBOX_UPDATE_DWORDS 8
> + struct drm_device *dev = signaller->dev;
> + struct drm_i915_private
This patch adds PSR Support to Baytrail.
Baytrail cannot easily detect screen updates and force PSR exit.
So we inactivate it on busy_ioctl and update to get it back
on next display mark_idle.
v2: Also inactivate PSR on cursor update.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_d
On Mon, Dec 16, 2013 at 08:50:48PM -0800, Ben Widawsky wrote:
Refactoring semaphore error state capture in preparation for future
hardware support.
> Signed-off-by: Ben Widawsky
A trivial explanation for a trivial patch is better than none. :)
-Chris
--
Chris Wilson, Intel Open Source Technol
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53288
This patch adds PSR Support to Baytrail.
Baytrail cannot easily detect screen updates and force PSR exit.
So we inactivate it on busy_ioctl and update to get it back
on next display mark_idle.
The current issue with this implementation is the cursor updates.
(Yet to be fixed).
Signed-off-by: Rodr
On Mon, 07 Oct 2013 11:05:57 +0300
Jani Nikula wrote:
> On Fri, 04 Oct 2013, Todd Previte wrote:
> > - DP_TEST_LINK_PATTERN is ambiguous, rename to DP_TEST_LINK_VIDEO_PATTERN
> > to clarify
> > - Added DP_TEST_LINK_FAUX_PATTERN to support automated testing of Fast AUX
> >
> > Signed-off-by:
On Mon, Dec 16, 2013 at 08:50:47PM -0800, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
Can you source this recommendation, even if just personal communication?
Is this likely to be temporary? Will a difference (power, latency)
ever be measurable?
-Chris
--
Chris Wilson, Intel Open Source T
2013/12/17 Rodrigo Vivi :
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_dp.c | 6 +++---
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/dr
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53288
On Tue, Dec 17, 2013 at 04:29:56PM +, Damien Lespiau wrote:
> On Tue, Dec 17, 2013 at 10:17:38AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote:
> > > Reposting this as a new series since two of the patches dropped off
> > > since last time.
> > >
Chris Wilson writes:
> The bspec still says we must assert SR01 bit5 prior to disabling the VGA
> plane.
>
> Perhaps the test should be whether (vga_reg & VGA_DISP_DISABLE) == 0 and
> do nothing if the plane is already off.
The problem is that for some reason we're smashing *some other video
car
On Mon, Dec 16, 2013 at 06:07:14PM -0200, Paulo Zanoni wrote:
> 2013/12/16 Daniel Vetter :
> > On Mon, Dec 16, 2013 at 05:19:25PM +, Chris Wilson wrote:
> >> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> >> we then kick out the efifb. Ouch.
>
> Please take a look at
On Tue, Dec 17, 2013 at 09:12:10AM -0800, Keith Packard wrote:
> We want to disable the (unused) VGA plane on the intel hardware, which
> should be a simple matter of writing the vga control register. However,
> in 2009 (commit 24f119c769bacac5729297b682fec7811a983cc6), that simple
> code was chang
We want to disable the (unused) VGA plane on the intel hardware, which
should be a simple matter of writing the vga control register. However,
in 2009 (commit 24f119c769bacac5729297b682fec7811a983cc6), that simple
code was changed to also smash the SR01 VGA register to fix "random
crash and lockups
On 17/12/13 16:30, Jesse Barnes wrote:
> On Tue, 17 Dec 2013 10:52:06 +0100
> Daniel Vetter wrote:
>
>> On Mon, Dec 16, 2013 at 7:52 PM, Colin Ian King
>> wrote:
>>> Hi there,
>>>
>>> There is a S3 resume issue that affects HP Mini Atom N270 with Intel
>>> Mobile 945GSE on Linux 3.9.0 upwards.
>
On Tue, Dec 17, 2013 at 10:17:38AM +0100, Daniel Vetter wrote:
> On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote:
> > Reposting this as a new series since two of the patches dropped off
> > since last time.
> >
> > Functionally it's the same as before. Like before, the patch "drm/i915
On Tue, 17 Dec 2013 10:52:06 +0100
Daniel Vetter wrote:
> On Mon, Dec 16, 2013 at 7:52 PM, Colin Ian King
> wrote:
> > Hi there,
> >
> > There is a S3 resume issue that affects HP Mini Atom N270 with Intel
> > Mobile 945GSE on Linux 3.9.0 upwards.
> >
> > Device:
> > 00:02.0 VGA compatible contr
On Tue, 17 Dec 2013, Chris Wilson wrote:
> The GMCH_CTRL register (or MGCC in the spec) is at a different address
> on Sandybridge, and the address to which we currently write to is
> undefined. These stray writes appear to upset (hard hang) my Ivybridge
> machine whilst it is in UEFI mode.
>
> No
On Tue, Dec 17, 2013 at 08:35:40PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> When current delay is already at max delay, Let's disable the PM UP
> THRESHOLD INTRRUPTS, so that we will not get further interrupts until
> current delay is less than max delay, Also request for the PM DOWN
On Tue, Dec 17, 2013 at 08:35:39PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> We use RPe here since it should match the Vmin we were shooting for.
> That should give us better perf than if we used the min freq available.
> System thermal can take the system to lowest possible freq (RPn
From: Deepak S
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPe, it might fail since the
Gfx clocks are down.
So to fix this in Gfx idel,Bring the GFX clock up and set the freq to
RPe then move GFx down.
v2: remove vlv_update_rps_
From: Deepak S
This patch includes
1. set min delay to rpe delay (Efficient frequency) for better
performace.
2. Disable/Enable PM Intrrupts based on the current freq.
3. WA to fix Voltage is not getting dropped to Vmin when Gfx is power
gated
Deepak S (5):
drm/i915:
From: Deepak S
When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and
viceversa for
From: Deepak S
We use RPe here since it should match the Vmin we were shooting for.
That should give us better perf than if we used the min freq available.
System thermal can take the system to lowest possible freq (RPn). We are
making sure, we calmp the freq to min_delay (RPe).
Signed-off-by: D
From: Deepak S
we're doing forcewake before Disabling RC6, This what the BIOS expects
when going into suspend.
v2: updated commit message (Daniel)
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_p
From: Deepak S
RC6 should be enabled only if the PCBR register is programmed properly by
either BIOS or Gfx. This patches address the case where PCBR allocation
fails due buggy BIOS or due to stolen memory allocation fails.
v2: Add #define for magic numbers (Daniel)
Signed-off-by: Deepak S
---
The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is in UEFI mode.
Note that the register is still marked as locked RO on
We attempt to reschedule an active work which can itself corrupt the
workqueue lists, and we may then free the work item whilst the task is
still pending. Both of these may lead to a system deadlock and an
unresponsive machine without any outputs for a panic to even be shown.
[7.372961] WARNIN
2013/12/17 Imre Deak :
> We use this hook starting from ILK onwards, so change the prefix
> accordingly. Also rename functions/struct names used from
> haswell_update_wm that are relevant to ILK already.
>
> No functional change.
>
As I mentioned on IRC, my only worry is how many conflicts we're g
We use this hook starting from ILK onwards, so change the prefix
accordingly. Also rename functions/struct names used from
haswell_update_wm that are relevant to ILK already.
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_p
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_reg.h | 36
1 file changed, 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9548b1..a699efd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_pm.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c12767c..f402c16 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
On Tue, Dec 17, 2013 at 10:58:27AM +0530, Vandana Kannan wrote:
> For Broadwell, there is one instance of Transcoder MN values per transcoder.
> For dynamic switching between multiple refreshr rates, M/N values may be
> reprogrammed on the fly. Link N programming triggers update of all data and
> l
On Tue, Dec 17, 2013 at 10:58:26AM +0530, Vandana Kannan wrote:
> Adding support to detect display idleness by tracking page flip from
> user space. Switch to low refresh rate is triggered after 2 seconds of
> idleness. The delay is configurable. If there is a page flip or call to
> update the plan
On Tue, Dec 17, 2013 at 10:58:24AM +0530, Vandana Kannan wrote:
> From: Pradeep Bhat
>
> This patch and finds out the lowest refresh rate supported for the resolution
> same as the fixed_mode, based on the implementaion find_panel_downclock.
> It also checks the VBT fields to see if panel support
On Tue, Dec 17, 2013 at 10:58:23AM +0530, Vandana Kannan wrote:
> From: Pradeep Bhat
>
> This patch reads the DRRS support and Mode type from VBT fields.
> The read information will be stored in VBT struct during BIOS
> parsing. The above functionality is needed for decision making
> whether DRRS
On Tue, Dec 17, 2013 at 12:17 PM, Damien Lespiau
wrote:
> On Tue, Dec 17, 2013 at 10:38:48AM +0100, Daniel Vetter wrote:
>> On Thu, Dec 12, 2013 at 02:36:36PM +, Damien Lespiau wrote:
>> > Signed-off-by: Damien Lespiau
>>
>> Merged this one here, not really sure what to do with the rest.
>
>
On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote:
> On Mon, 16 Dec 2013, Chris Wilson wrote:
> > If we fail to remove a conflicting fb driver, we need to abort the
> > loading of the second driver to avoid likely kernel panics.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Jean-Christoph
On Tue, Dec 17, 2013 at 11:45:45AM +, Chris Wilson wrote:
> On Tue, Dec 17, 2013 at 11:21:27AM +0200, Jani Nikula wrote:
> > On Mon, 16 Dec 2013, Chris Wilson wrote:
> > > Touching the VGA registers risks a hard machine hang, at least on this
> > > ivb machine after removing a conflicting efif
On Tue, Dec 17, 2013 at 11:21:27AM +0200, Jani Nikula wrote:
> On Mon, 16 Dec 2013, Chris Wilson wrote:
> > Touching the VGA registers risks a hard machine hang, at least on this
> > ivb machine after removing a conflicting efifb. This is more than likely
> > related to the discovery that VGA IO d
On Tue, Dec 17, 2013 at 10:38:48AM +0100, Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 02:36:36PM +, Damien Lespiau wrote:
> > Signed-off-by: Damien Lespiau
>
> Merged this one here, not really sure what to do with the rest.
So, apparently, there's some unhappiness with INTEL_INFO, which i
On Tue, 17 Dec 2013, Daniel Vetter wrote:
> Noticed while reviewing a patch and couldn't resist the OCD.
Reviewed-by: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/d
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
> @@ -333,7 +535,8 @@ MODULE_LICENSE("GPL and additional rights");
> void intel_fbdev_output_poll_changed(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - drm_fb_helper_hotplug_event(&de
On Mon, Dec 16, 2013 at 11:38:38PM +0200, Imre Deak wrote:
> On Thu, 2013-12-05 at 15:51 +0200, ville.syrj...@linux.intel.com wrote:
> > Back on the watermark horse. This series moves ILK/SNB/IVB over to the HSW
> > watermark code.
> >
> > This series still has some underrun issues since the safe
On Mon, Dec 16, 2013 at 04:34:26PM -0800, Jesse Barnes wrote:
> + if (INTEL_INFO(dev)->gen >= 4) {
> + if (plane_config->tiled)
> + offset = I915_READ(DSPTILEOFF(plane));
> + else
> + offset = I915_READ(DSPLINOFF(plane));
> +
On Mon, Dec 16, 2013 at 7:52 PM, Colin Ian King
wrote:
> Hi there,
>
> There is a S3 resume issue that affects HP Mini Atom N270 with Intel
> Mobile 945GSE on Linux 3.9.0 upwards.
>
> Device:
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
> 945GSE Express Integrated Graphics
On Mon, Dec 16, 2013 at 08:50:42PM -0800, Ben Widawsky wrote:
> @@ -2054,7 +2052,8 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
> gen6_ring_dispatch_execbuffer;
> }
> ring->semaphore.sync_to = gen6_ring_sync;
> - rin
On Thu, Dec 12, 2013 at 02:36:36PM +, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
Merged this one here, not really sure what to do with the rest.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_pm.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drive
Hi all,
Thanks to Carl Worth we now have a nice pachwork instance for intel-gfx:
http://patchwork.freedesktop.org/project/intel-gfx/list/
We also have a git hook for i-g-t, xf86-video-intel and my drm-intel
repo which will automatically set patches to "Accepted" when they're
merged.
I'll manual
On Tue, 17 Dec 2013, Daniel Vetter wrote:
> Otherwise we don't kick out firmware framebuffers like vesafb and
> efifb when CONFIG_DRM_I915_FBDEV=n but CONFIG_FB=y.
>
> There's still the pesky issue with vgacon which we should somehow
> replace with the dummy console at least. We have a similar iss
On Mon, 16 Dec 2013, Chris Wilson wrote:
> Touching the VGA registers risks a hard machine hang, at least on this
> ivb machine after removing a conflicting efifb. This is more than likely
> related to the discovery that VGA IO decode on the more recent PCH
> platforms is terminally broken.
Pleas
On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote:
> Reposting this as a new series since two of the patches dropped off
> since last time.
>
> Functionally it's the same as before. Like before, the patch "drm/i915:
> unleash semaphores on gen8" should probably not be merged as it's not
On Mon, 16 Dec 2013, Chris Wilson wrote:
> This has very little effect other than log the errors in case of failure,
> and we then hope for the best.
Reviewed-by: Jani Nikula
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_display.c | 13 +++--
> 1 file changed, 11 in
Otherwise we don't kick out firmware framebuffers like vesafb and
efifb when CONFIG_DRM_I915_FBDEV=n but CONFIG_FB=y.
There's still the pesky issue with vgacon which we should somehow
replace with the dummy console at least. We have a similar issue at
module un/reload, since vgacon state is termin
Noticed while reviewing a patch and couldn't resist the OCD.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aea909b2f22e..31ffe39d2b
On Mon, Dec 16, 2013 at 08:50:43PM -0800, Ben Widawsky wrote:
> Gen8 has already had some differentiation with how it handles rings.
> Semaphores bring yet more differences, and now is as good a time as any
> to do the split.
>
> Also, since gen8 doesn't actually use semaphores up until this point
On Mon, Dec 16, 2013 at 04:34:25PM -0800, Jesse Barnes wrote:
> We want to do this early on before we try to fetch the plane config,
> which depends on some of the pipe config state.
>
> Signed-off-by: Jesse Barnes
I've merged patches 2&3 from this series. This one here needs a backmerge
which a
On Mon, Dec 16, 2013 at 04:01:41PM -0800, Jesse Barnes wrote:
> On Sat, 14 Dec 2013 12:01:47 +0100
> Daniel Vetter wrote:
> > But I still think the fb lifetime management is a bit broken here and we
> > need a few small changes:
> >
> > 1. Right here in this loop we need to assign the fb from the
On Mon, Dec 16, 2013 at 04:35:40PM -0800, Jesse Barnes wrote:
> On Thu, 12 Dec 2013 14:44:33 -0800
> Jesse Barnes wrote:
>
> > On Thu, 12 Dec 2013 23:39:39 +0100
> > Daniel Vetter wrote:
> >
> > > On Thu, Dec 12, 2013 at 01:29:39PM -0800, Jesse Barnes wrote:
> > > > On Thu, 12 Dec 2013 22:21:29
98 matches
Mail list logo
