On Sun, Sep 01, 2013 at 07:01:49PM +0200, Thomas Richter wrote:
> Dear intel-gfx developers,
>
> When panning is enabled on the 830GM, horizontal panning creates a
> lot of flickering on specific pixel positions.
> After testing, I found that the reason for this is that panning
> works by altering
On Sun, Sep 01, 2013 at 12:51:24PM -0700, Ben Widawsky wrote:
> This finishes the objective in the last patch which was to actually deal
> with physical addresses, and not the PTEs.
>
> GEN6+ Provided support for physical addresses above 4GB. I'm not
> actually sure what Ironlake supported, and do
SWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and
filters out any calls that shouldn't happen. This way the callers don't
need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set PCI_SWSCI bit 0 to trigger
On Mon, Sep 02, 2013 at 08:49:01AM +0200, Daniel Vetter wrote:
> Historically we've run our own driver hotplug handling in our own
> work-queue, which then launched the drm core hotplug handling in the
> system workqueue. This is important since we flush our own driver
> workqueue in the pageflip c
On Fri, Aug 30, 2013 at 04:43:59PM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> As we plumb the code with more VM information, it has become more
> obvious that the easiest way to deal with bind and unbind is to simply
> put the function pointers in the vm, and let those choose the correct
On Mon, Sep 02, 2013 at 08:32:24AM +0200, Daniel Vetter wrote:
> On Fri, Aug 30, 2013 at 08:39:46PM -0700, Ben Widawsky wrote:
> > On Sat, Aug 31, 2013 at 12:50:30AM +0100, Chris Wilson wrote:
> > > On Fri, Aug 30, 2013 at 04:43:54PM -0700, Ben Widawsky wrote:
> > > > lifted from Daniel:
> > > > pr
Hi Daniel,
I've just looked at the docs and they only mention that the base address
must be pixel aligned. But it could very well be that the watermarks are a
bit off for your chipset. The below quick hack should test this theory.
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/
2013/9/2 Jani Nikula :
> SWSCI is a driver to bios call interface.
>
> This checks for SWSCI availability and bios requested callbacks, and
> filters out any calls that shouldn't happen. This way the callers don't
> need to do the checks all over the place.
>
> v2: silence some checkpatch nagging
>
On Fri, Aug 30, 2013 at 07:40:28PM +0300, Jani Nikula wrote:
> In preparation for followup work.
>
> Signed-off-by: Jani Nikula
> Reviewed-by: Paulo Zanoni
Maintainer-bikeshed: I don't really see the value of "export foo" patches
since there's not much to judge them by. I prefer them squashed i
On Fri, Aug 30, 2013 at 04:51:09PM -0300, Paulo Zanoni wrote:
> 2013/8/30 Jani Nikula :
> > The spec says to notify prior to power down and after power up. It is
> > unclear whether it makes a difference.
> >
> > Signed-off-by: Jani Nikula
> > Reviewed-by: Paulo Zanoni
> >
> > ---
> >
> > Paulo,
On Mon, Sep 02, 2013 at 09:10:22AM +0200, Daniel Vetter wrote:
> On Sun, Sep 01, 2013 at 07:01:49PM +0200, Thomas Richter wrote:
> > Dear intel-gfx developers,
> >
> > When panning is enabled on the 830GM, horizontal panning creates a
> > lot of flickering on specific pixel positions.
> > After te
On Mon, Sep 02, 2013 at 02:14:12PM +0100, Chris Wilson wrote:
> On Mon, Sep 02, 2013 at 08:32:24AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 30, 2013 at 08:39:46PM -0700, Ben Widawsky wrote:
> > > On Sat, Aug 31, 2013 at 12:50:30AM +0100, Chris Wilson wrote:
> > > > On Fri, Aug 30, 2013 at 04:43:
On Mon, Sep 02, 2013 at 03:58:59PM +0200, Thomas Richter wrote:
> Hi Daniel,
>
> >I've just looked at the docs and they only mention that the base address
> >must be pixel aligned. But it could very well be that the watermarks are a
> >bit off for your chipset. The below quick hack should test thi
On Mon, Sep 02, 2013 at 03:58:59PM +0200, Thomas Richter wrote:
> Hi Daniel,
>
> > I've just looked at the docs and they only mention that the base address
> > must be pixel aligned. But it could very well be that the watermarks are a
> > bit off for your chipset. The below quick hack should test
Historically we've run our own driver hotplug handling in our own
work-queue, which then launched the drm core hotplug handling in the
system workqueue. This is important since we flush our own driver
workqueue in the pageflip code while hodling modeset locks, and only
the drm hotplug code grabbed
On 02.09.2013 16:18, Daniel Vetter wrote:
Checked with the above modifications. Unfortunately, the result is
negative. With the above modifications and my changes commented out,
the screen flickers in normal state (without panning) but in a
different way: With the above enabled, you get a rather
On Sun, Sep 1, 2013 at 11:54 PM, Daniel Vetter wrote:
> On Sat, Aug 31, 2013 at 04:02:16PM -0700, Linus Torvalds wrote:
>> Hmm. I just updated my machine to a i7-4770S (kept everything else the
>> same, just switched out motherboards), and now when my display goes to
>> sleep, it seems to never co
Currently parts of our code are really confused about which mode
structure they should be looking at.
A lot of the code never got converted to look at the pipe config modes,
and for example the watermark code still managed to look at the wrong mode
(crtc->mode, not even crtc->hwmode which would ha
From: Ville Syrjälä
intel_crtc_compute_config() and i9xx_set_pipeconf() attempt to get
the current pixel clock from requested_mode. requested_mode.clock may
be totally bogus, so the clock should come from adjusted_mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 5
From: Ville Syrjälä
lpt_program_iclkip() wants to know the pixel clock. It should get that
information from adjusted_mode, not crtc->mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/
From: Ville Syrjälä
Check the mode flags from the adjusted_mode, not user requested mode.
The hdisplay/vdisplay check actually checkes the primary plane size,
so those still need to come from the user requested mode.
Extract both modes from pipe config instead of the drm_crtc.
Signed-off-by: Vi
From: Ville Syrjälä
The pixel clock should come from adjusted_mode not requested_mode.
In this case the two should be the same as we don't currently
overwrite the clock in the case of HDMI. But let's make the code
safe against such things happening in the future.
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
Currently most of the watermark code looks at crtc->mode which is the
user requested mode. The only piece of information there that is
relevant is hdisplay, the rest must come from adjusted_mode. Convert
all of the code to use requested_mode and adjusted_mode from
pipe config
From: Ville Syrjälä
The clock in crtc->mode doesn't necessarily mean anything. Let's look
at the clock in adjusted_mode instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_p
From: Ville Syrjälä
intel_edp_psr_match_conditions() currently looks at crtc->mode
when it really needs to look at adjusted_mode. Fix it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i9
From: Ville Syrjälä
adjusted_mode contains our real timings, not requested_mode. Use the
correct thing in DSI PLL code.
Also constify adjusted_mode since we don't change it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 4 ++--
1 file changed, 2 insertions(+), 2 dele
From: Ville Syrjälä
Move intel_crtc_active() to intel_display.c and make it available
elsewhere as well.
intel_edp_psr_match_conditions() already has one open coded copy,
so replace that one with a call to intel_crtc_active().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_displa
From: Ville Syrjälä
Rather that mess about with hdisplay/vdisplay from requested_mode, add
explicit pipe src size information to pipe config.
Now requested_mode is only really relevant for dvo/sdvo output timings.
For everything else either adjusted_mode or pipe src size should be
used.
Signed-
From: Ville Syrjälä
Rather than dig up the pipe source size from crtc->mode, use
intel_crtc->config.requested_mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
From: Ville Syrjälä
intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode
only partially. Notably it forgot to copy over the sync flags. The LVDS
code however programmed the hardware with the sync flags from fixed
mode, and then later the pipe config comparison obviously failed
From: Ville Syrjälä
When the cursor x coordinate is exactly -cursor_width, the cursor is
invisible. And obviously the same holds for the y coordinate and
cursor_height.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(
I was suspecting double wide to be the cause of a bug report, and so
started digging a bit. Sadly it looks like that bug is caused by something
else, but I did end up fixing a double wide related bug anyway.
The resulting series is here. It needs to be applied after the pipe config
fixes seried I
From: Ville Syrjälä
Determine the need for double wide mode already in compute_config
stage as we need that information to figure out if horizontal
coordinates need to be adjusted.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 31 ---
drive
From: Ville Syrjälä
Read the double wide pipe information from hardware in
i9xx_get_pipe_config(), and check it in intel_pipe_config_compare()
For gen4+ double_wide is always false so the comparison can be done
on all platforms.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_disp
From: Ville Syrjälä
We don't want to try to push the hardware beyond it's capabilities,
so check the pixel clock against the display core clock limit. Do
it for pre-gen4 for now since that's where we alread have the double
wide pixel clock limit check.
Let's assume that when double wide mode is
From: Ville Syrjälä
Pipe horizontal source size must be even when either LVDS dual channel
mode, DVO ganged mode, or pipe double wide mode is used.
We must round it down since we can never increase the user specified
viewport size.
The actual error from an odd pipe source width looks like a dia
From: Ville Syrjälä
Double wide mode is only available on pipe A, except on GDG where
pipe B is also double wide capable.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_d
On Mon, Sep 02, 2013 at 09:13:28PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_crtc_compute_config() and i9xx_set_pipeconf() attempt to get
> the current pixel clock from requested_mode. requested_mode.clock may
> be totally bogus, so the clock should come from adj
On Mon, Sep 02, 2013 at 09:13:30PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The pixel clock should come from adjusted_mode not requested_mode.
> In this case the two should be the same as we don't currently
> overwrite the clock in the case of HDMI. But let's make the
On Mon, Sep 02, 2013 at 09:13:35PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Move intel_crtc_active() to intel_display.c and make it available
> elsewhere as well.
>
> intel_edp_psr_match_conditions() already has one open coded copy,
> so replace that one with a call
On Mon, Sep 02, 2013 at 09:13:39PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode
> only partially. Notably it forgot to copy over the sync flags. The LVDS
> code however programmed the hardware with t
On Mon, Sep 02, 2013 at 09:13:38PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rather that mess about with hdisplay/vdisplay from requested_mode, add
> explicit pipe src size information to pipe config.
>
> Now requested_mode is only really relevant for dvo/sdvo output
On Mon, Sep 02, 2013 at 09:24:26PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We don't want to try to push the hardware beyond it's capabilities,
> so check the pixel clock against the display core clock limit. Do
> it for pre-gen4 for now since that's where we alread h
On Mon, Sep 02, 2013 at 09:24:23PM +0300, ville.syrj...@linux.intel.com wrote:
> I was suspecting double wide to be the cause of a bug report, and so
> started digging a bit. Sadly it looks like that bug is caused by something
> else, but I did end up fixing a double wide related bug anyway.
>
> T
Somehow we've lost the error handling in the patch split-up between
the internal and external patch. This regression has been introduced
in
commit 5032d871f7d300aee10c309ea004eb4f851553fe
Author: Rafael Barbalho
Date: Wed Aug 21 17:10:51 2013 +0100
drm/i915: Cleaning up the relocate entry
On Mon, Sep 02, 2013 at 12:52:05PM +0100, Chris Wilson wrote:
> On Mon, Sep 02, 2013 at 08:49:01AM +0200, Daniel Vetter wrote:
> > Historically we've run our own driver hotplug handling in our own
> > work-queue, which then launched the drm core hotplug handling in the
> > system workqueue. This is
On Mon, Sep 02, 2013 at 08:46:19PM +0200, Daniel Vetter wrote:
> On Mon, Sep 02, 2013 at 09:13:38PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Rather that mess about with hdisplay/vdisplay from requested_mode, add
> > explicit pipe src size information to pipe con
On Mon, Sep 02, 2013 at 08:39:45PM +0200, Daniel Vetter wrote:
> On Mon, Sep 02, 2013 at 09:13:30PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The pixel clock should come from adjusted_mode not requested_mode.
> > In this case the two should be the same as we don'
On Mon, Sep 02, 2013 at 08:51:41PM +0200, Daniel Vetter wrote:
> On Mon, Sep 02, 2013 at 09:24:26PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We don't want to try to push the hardware beyond it's capabilities,
> > so check the pixel clock against the display core
On Mon, Sep 02, 2013 at 08:53:01PM +0200, Daniel Vetter wrote:
> On Mon, Sep 02, 2013 at 09:24:23PM +0300, ville.syrj...@linux.intel.com wrote:
> > I was suspecting double wide to be the cause of a bug report, and so
> > started digging a bit. Sadly it looks like that bug is caused by something
> >
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_overlay.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index ddfd0ae..8d6d0a1 100644
--- a/drivers/gpu/drm/i915
From: Ville Syrjälä
Move intel_crtc_active() to intel_display.c and make it available
elsewhere as well.
intel_edp_psr_match_conditions() already has one open coded copy,
so replace that one with a call to intel_crtc_active().
v2: Copy paste a big comment from danvet's mail explaining
when
eDP 1.4 supports 4-5 extra link rates in additional to current 2 link
rate. Create a structure to store the DPLL divisor data to improve
readability.
v2: Fix the gen4_dpll/pch_dpll initialization to C99
designated initializers, and use a single loop for all platforms. (Jani and
Daniel)
Signed-o
For DP pll settings, there is only two golden configs. Instead of
running through the algorithm to determine it, hardcode the value and get it
determine in intel_dp_set_clock.
v2: Rework on the intel_limit compiler warning. (Jani)
Signed-off-by: Chon Ming Lee
---
drivers/gpu/drm/i915/intel_dis
54 matches
Mail list logo
