On Mon, Sep 02, 2013 at 09:16:50PM +0300, ville.syrj...@linux.intel.com wrote:
> 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.
And similarly for the earlier x == fb-
On Mon, Sep 02, 2013 at 10:05:26PM +0300, Ville Syrjälä wrote:
> 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_m
On Mon, Sep 02, 2013 at 10:11:43PM +0300, Ville Syrjälä wrote:
> 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/vdispl
On Mon, Sep 02, 2013 at 10:24:18PM +0300, Ville Syrjälä wrote:
> 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 b
On Wed, Sep 04, 2013 at 01:30:38AM +0800, Chon Ming Lee wrote:
> 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.
From: Ville Syrjälä
First of all we should not be looking at fb->{width,height} as those do
not tell us what the actual pipe size is. Second of all we need to use
>= for the comparison.
So fix the comparison, and make use of the new pipe_src_{w,h} to
determine the real pipe source dimensions.
S
On Mon, Sep 02, 2013 at 08:58:03PM +0200, Daniel Vetter wrote:
> 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:
On Tue, Sep 03, 2013 at 11:04:30AM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> First of all we should not be looking at fb->{width,height} as those do
> not tell us what the actual pipe size is. Second of all we need to use
> >= for the comparison.
>
> So fix the compar
On Tue, Sep 03, 2013 at 09:52:40AM +0200, Daniel Vetter wrote:
> On Mon, Sep 02, 2013 at 10:11:43PM +0300, Ville Syrjälä wrote:
> > 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
From: Ville Syrjälä
Try to clarify the purpose of the two different modes we keep, and the
pipe source size.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915
On Mon, Sep 02, 2013 at 08:38:16PM +0200, Daniel Vetter wrote:
> 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. reque
From: Ville Syrjälä
ironlake_fdi_compute_config() already checks that we have enough
FDI bandwidth. And it doesn't just use a hardcoded value but takes
into account factors such as the actual FDI frequency, shared FDI
B/C lanes, etc.
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
On Tue, Sep 03, 2013 at 01:01:14PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 02, 2013 at 08:38:16PM +0200, Daniel Vetter wrote:
> > 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_pi
On Tue, Sep 03, 2013 at 01:31:38PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> ironlake_fdi_compute_config() already checks that we have enough
> FDI bandwidth. And it doesn't just use a hardcoded value but takes
> into account factors such as the actual FDI frequency, s
Okay, I'm not overly confident about the correctness of this series, but
here goes anyway.
Cheers,
Jani.
Jani Nikula (3):
drm/i915: move backlight enable later in vlv enable sequence
drm/i915: clean up power sequencing register port select definitions
drm/i915: add support for per-pipe pow
Follow-up to
commit 5004945f1d6c0282c0288afa89ad85d7f2bea4d5
Author: Jani Nikula
Date: Tue Jul 30 12:20:32 2013 +0300
drm/i915: move encoder->enable callback later in VLV crtc enable
Reference:
http://mid.gmane.org/cakmk7ufs9emvmw8bns24e5unm1d7jrfvg3sd5sdftveamgf...@mail.gmail.com
Signed-
Remove dupes, add VLV port B.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h |7 +--
drivers/gpu/drm/i915/intel_dp.c |4 ++--
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c7f2da3
VLV has per-pipe PP registers. Set up power sequencing on mode set. The
connector init time setup is problematic, since we don't have a pipe at
that time. Cook up something.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 139 +++
1 file chan
The cursor is disabled before crtc mode set in crtc disable, and enabled
afterwards in crtc enable. Do not update it in crtc mode set.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c |9 -
1 file changed, 9 deletions(-)
diff --git a/d
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 44 +-
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 120a004..f079475 100644
--- a/drivers/g
On Tue, Sep 03, 2013 at 02:48:13PM +0300, Jani Nikula wrote:
> The cursor is disabled before crtc mode set in crtc disable, and enabled
> afterwards in crtc enable. Do not update it in crtc mode set.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Ok, but this would be better repla
On Tue, Sep 03, 2013 at 01:23:23PM +0200, Daniel Vetter wrote:
> On Tue, Sep 03, 2013 at 01:01:14PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 02, 2013 at 08:38:16PM +0200, Daniel Vetter wrote:
> > > On Mon, Sep 02, 2013 at 09:13:28PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From
As I mentioned before, I'd like adjusted_mode.clock to be the pipe pixel clock.
So to me it looks like all we need to do to store the pixel multiplied
clock into port_clock, and then adjusted_mode.clock can stay as the
non-multiplied pixel clock.
Seems simple enough. But a big warning here, I di
From: Ville Syrjälä
We feed the non-multiplied clock to intel_link_compute_m_n(), so the
opposite operation should use the same order of operations. So we just
multiply by pixel_multiplier in the end now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 15 +++---
From: Ville Syrjälä
It would be easier if adjusted_mode.clock would be the pipe pixel clock,
and it actually is, except for the cases where pixel_multiplier > 1.
So let's change intel_sdvo to use port_clock as the multiplied clock,
and then we can leave adjusted_mode.clock as pipe pixel clock.
On Tue, Sep 3, 2013 at 10:13 AM, Chris Wilson wrote:
> On Tue, Sep 03, 2013 at 11:04:30AM +0300, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> First of all we should not be looking at fb->{width,height} as those do
>> not tell us what the actual pipe size is. Second of all we
On Tue, Sep 03, 2013 at 03:08:50PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 03, 2013 at 01:23:23PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 03, 2013 at 01:01:14PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 02, 2013 at 08:38:16PM +0200, Daniel Vetter wrote:
> > > > On Mon, Sep 02, 2013 at 09:
On Tue, Sep 03, 2013 at 04:21:04PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> It would be easier if adjusted_mode.clock would be the pipe pixel clock,
> and it actually is, except for the cases where pixel_multiplier > 1.
>
> So let's change intel_sdvo to use port_cloc
From: Ville Syrjälä
We want to do fuzzy clock checks for other things besides
adjusted_mode.clock, so just pass two two clocks to compare
to intel_fuzzy_clock_check().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 file changed, 4 insertions(+), 7 del
From: Ville Syrjälä
Add a new pipe config check macro PIPE_CONF_CHECK_CLOCK_FUZZY() to make
it trivial and error proof to compare clocks in a fuzzy manner.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 24 ++--
1 file changed, 14 insertions(+), 10
As I told you in irc I'm not sure if the best option is to use common,
raw and old, but since I don't have a better idea and while nobody
else has, just to go ahead ;)
And I liked very much the raw part, although I had to count the bytes
amount on VBT doc when reviewing following patches ;)
For t
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bfa531a..05ff91d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
As requested by Daniel. Totally untested as of now.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,
I've read carefully the xf86-video-intel 2.21.11 announce on that
mailing list with its fastboot promise.
However i don't have it on my IvyBridge system with
xserver-xorg-video-intel 2.21.15 - see my boot sequence video which
resizes here :
http://libre-ouvert.toile-libre.org/data/documents/M
Reviewed-by: Rodrigo Vivi
On Wed, Aug 28, 2013 at 12:45 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Our code makes a lot of assumptions regarding what each DDI port
> actually supports, and the VBT should tell us what is really happening
> in the hardware. So parse the information provided
On Fri, Aug 30, 2013 at 08:40:36PM -0700, Ben Widawsky wrote:
> On Sat, Aug 31, 2013 at 01:12:55AM +0100, Chris Wilson wrote:
> > 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
>
Reviewed-by: Rodrigo Vivi
On Wed, Aug 28, 2013 at 12:45 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Our code currently assumes that port X will use the DP AUX channel X
> and the DDC pin X. The VBT should tell us how things are mapped, so
> add some WARNs in case we discover our assumption
Do we really trust VBT that much?
Anyways,
Reviewed-by: Rodrigo Vivi
On Wed, Aug 28, 2013 at 12:45 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> There's no reason to init a DP connector if the encoder just supports
> HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
> A
On Wed, Aug 28, 2013 at 12:39 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We currently use the recommended values from BSpec, but the VBT
> specifies the correct value to use for the hardware we have, so use
> it. We also fall back to the recommended value in case we can't find
> the VBT.
>
On Tue, Sep 03, 2013 at 11:37:27AM -0300, Rodrigo Vivi wrote:
> On Wed, Aug 28, 2013 at 12:39 PM, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > We currently use the recommended values from BSpec, but the VBT
> > specifies the correct value to use for the hardware we have, so use
> > it. We a
On Mon, Sep 02, 2013 at 04:12:36PM +0200, Daniel Vetter wrote:
> 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
On Mon, Sep 02, 2013 at 12:02:54PM +0200, thibaut bethune wrote:
> Hi,
>
> I've read carefully the xf86-video-intel 2.21.11 announce on that
> mailing list with its fastboot promise.
>
> However i don't have it on my IvyBridge system with
> xserver-xorg-video-intel 2.21.15 - see my boot sequence
2013/9/3 Rodrigo Vivi :
> Do we really trust VBT that much?
We already trust it for some very important things, like eDP. Also, if
the VBT is wrong we'll start seeing all sorts of WARNs due to the
previous patches. Anyway, we can always revert...
Thanks for the reviews!
>
> Anyways,
> Reviewed-b
On Tue, Sep 3, 2013 at 7:37 PM, Kamal Mostafa wrote:
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
>
> Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
> ("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
> boot param to inhibit the q
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
boot param to inhibit the quirk, or force it on.
i915.disable_pch_pwm can be set to
-1:
On Tue, Sep 03, 2013 at 08:40:36PM +0200, Daniel Vetter wrote:
> The sdvo input timing needs to be the actual mode, the sdvo
> encoder automatically adjusts for the need of pixel doubling or
> quadrupling. This was lost in pipe config conversion of the
> pixel multiplier in
>
> commit 6cc5f341b583
On Tue, 2013-09-03 at 19:50 +0200, Daniel Vetter wrote:
> On Tue, Sep 3, 2013 at 7:37 PM, Kamal Mostafa wrote:
> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
> >
> > Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
> > ("drm/i915: quirk no PCH_PWM_ENABLE for
On Tue, Sep 03, 2013 at 09:53:15PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 03, 2013 at 08:40:36PM +0200, Daniel Vetter wrote:
> > The sdvo input timing needs to be the actual mode, the sdvo
> > encoder automatically adjusts for the need of pixel doubling or
> > quadrupling. This was lost in pipe
The sdvo input timing needs to be the actual mode, the sdvo
encoder automatically adjusts for the need of pixel doubling or
quadrupling. This was lost in pipe config conversion of the
pixel multiplier in
commit 6cc5f341b5830541a1b6945435ca90c69b1b8b21
Author: Daniel Vetter
Date: Wed Mar 27 00:4
The dpll actually runs at the port clock so we don't need
to multiply it again with the pixel multiplier to get the
adjusted_mode.clock. This is in contrast to the ironlake
pixel clock readout code which uses the fdi dotclock: That
one does _not_ run with multiplied pixels.
This issue goes back to
Hi Daniel,
This morning after fetching the drm-intel-fixes tree, I have discovered
that you have just added a whole set of patches on top of Dave's drm tree
and made that the drm-intel-fixes tree. I understood that this tree was
for fixes to Linus' tree for the current release cycle. Given that
On Tue, Sep 03, 2013 at 06:08:19PM +0200, Daniel Vetter wrote:
> On Mon, Sep 02, 2013 at 04:12:36PM +0200, Daniel Vetter wrote:
> > 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:3
On Mon, Sep 02, 2013 at 03:46:52PM +0300, Ville Syrjälä wrote:
> 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 simpl
53 matches
Mail list logo
