On Thu, 25 Oct 2012 17:10:01 +0100, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> HSW consolidates SPRTILEOFF and SPRLINOFF into a single SPROFFSET
> register.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_reg.h |3 +++
> drivers/gpu/drm/i915/intel_sprite.c |
On Fri, Oct 26, 2012 at 09:21:05AM +0300, Jani Nikula wrote:
> On Tue, 23 Oct 2012, Chris Wilson wrote:
> > On Mon, 22 Oct 2012 16:12:18 +0300, Jani Nikula
> > wrote:
> >> SDVOB may be multiplexed with HDMIB. If it's not SDVOB, the same i2c
> >> adapter may be used for HDMIB, with the adjusted c
From: root
---
bin/set_debug_dmesg.c | 8
1 file changed, 8 insertions(+)
create mode 100644 bin/set_debug_dmesg.c
diff --git a/bin/set_debug_dmesg.c b/bin/set_debug_dmesg.c
new file mode 100644
index 000..d61394a
--- /dev/null
+++ b/bin/set_debug_dmesg.c
@@ -0,0 +1,8 @@
+#include
According to "Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence" We need to write the TU size register
of the fdi RX unit _before_ starting to train the link.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 8 +---
1 file changed, 5
My machine here has the correct ones already, but better safe
than sorry. IBX has different settings for that register, and
on IBX the device defaults match the recommended values. Hence
I did not add the respective writes for IBX.
LPT needs the same settings, but that has been done already
commi
Hi all,
I've dug around in Bspec a bit to check out whether we're missing any
workarounds or have anything ordered the wrong way around in our setup sequence
for the fdi links. And indeed, there are a few small things. I have the illusion
that this patch series fixes fdi b/c issues for me, that wi
We need to set the timing override chicken bit after fdi link training
has completed and before we enable the dp transcoder. We also have to
clear that bit again after disabling the pch dp transcoder.
See "Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence" and "
And properly toggle the chicken bit in the pch to enable/disable fdi C
rx. If we don't set this bit correctly, the rx gets confused in link
training, which can result in an fdi link that silently fails to train
the link (since the corresponding register reports success). Note that
both fdi link B a
The debug message is only relevant on CPT/PPT PCH ports, so move
it into the correct if clause.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_d
Atm we have a few funny issues where we enable/disable shared
pll clocks. To make it clear that we are not required to enable/
disable the pch plls together with the other pch resources (and
so should keep it running when it's used by another pipe in
a shared pll configuration) add a comment.
This
Since it is one. We need to move this code to encoder specific callbacks
eventually, to kill all that inversion of control ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_d
They are all written for a specific north disaplay->pch combination.
So stop pretending otherwise.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/driv
After all relevant pipes are disabled and after we've updated all the
state with the staged state, but before we call the per-crtc
->mode_set functions there's a very natural point to set up any
shared/global resources like
- shared plls (obviously only the setup, the enabling needs to be
separat
[Dropped lkml, added intel-gfx]
Hi Yuly, here's a slightly modified version of your patch, rebased on
drm-intel-next-queued. I kept your authorship, but any new errors are
totally mine...
These are compile tested only; I'd appreciate if you could check it
still does what it says on the box!
BR,
Prepare for supporting scaling mode configuration also in eDP.
Includes a drive-by-removal of an outdated comment about fitting mode.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_lvds.c | 24 ++--
2 files changed, 11
From: Yuly Novikov
LVDS allowed changing panel fitting scaling mode, while eDP didn't. Copied
relevant code from LVDS to eDP.
Signed-off-by: Yuly Novikov
[Jani: use fitting mode in intel_panel, remove default mode change]
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 31 +
From: Yuly Novikov
Signed-off-by: Yuly Novikov
[Jani: ripped this change separate from the scaling mode change support]
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dr
On Fri, Oct 26, 2012 at 9:33 AM, Mika Kuoppala
wrote:
> I don't know if upper layers sanitize already but
> x should be < 8192 and y < 4096 in here, and both <4096 for ivb.
> Emit warning and clamp if they are not in range?
We probably need to do the same trick we're already doing in the main
pla
On Wed, 24 Oct 2012 22:31:01 -0700, Ben Widawsky wrote:
> Rodrigo Vivi wrote:
> I like the direction this patch is going but I think it does limit
> people with knowledge might want to do (for instance, I ran with rc6
> on ILK just fine for quite a while).
>
> How about we use add_taint instead,
On Fri, 26 Oct 2012 10:33:00 +0300, Mika Kuoppala
wrote:
> On Thu, 25 Oct 2012 17:10:01 +0100, Damien Lespiau
> wrote:
> > @@ -127,13 +127,21 @@ ivb_update_plane(struct drm_plane *plane, struct
> > drm_framebuffer *fb,
> >
> > I915_WRITE(SPRSTRIDE(pipe), fb->pitches[0]);
> > I915_WRI
On Thu, 25 Oct 2012 13:54:42 -0700, Ben Widawsky wrote:
> On Thu, 25 Oct 2012 21:22:25 +0200
> Daniel Vetter wrote:
>
> > On Thu, Aug 30, 2012 at 04:31:06PM +0100, Chris Wilson wrote:
> > > This will be used i915 in forthcoming patches in order to measure the
> > > largest contiguous chunk of me
Otherwise we may remove the only console for a nomodeset system.
We became more aggressive in our kicking with
commit e188719a2891f01b3100dca4ae3a055fb5a7ab52
Author: Daniel Vetter
Date: Tue Jun 12 11:28:17 2012 +0200
drm/i915: kick any firmware framebuffers before claiming the gtt
Report
On Thu, 25 Oct 2012 12:15:46 -0700, Jesse Barnes
wrote:
> So store into the scratch space of the HWS to make sure the invalidate
> occurs.
>
> v2: use GTT address space for store, clean up #defines (Chris)
>
> Signed-off-by: Jesse Barnes
> ---
> @@ -1460,10 +1467,17 @@ static int blt_ring_flus
commit 28dcc2d60cb570d9f549c329b2f51400553412a1
Author: Jani Nikula
Date: Mon Sep 3 16:25:12 2012 +0300
drm/i915: do not expose a dysfunctional backlight interface to userspace
prevents backlight interface creation if the BIOS has not set the backlight
PWM CTL registers that contain the ma
Hi
2012/10/25 Damien Lespiau :
> From: Damien Lespiau
>
> HSW consolidates SPRTILEOFF and SPRLINOFF into a single SPROFFSET
> register.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_reg.h |3 +++
> drivers/gpu/drm/i915/intel_sprite.c | 18 +-
> 2
Hi
2012/10/26 Jani Nikula :
> [Dropped lkml, added intel-gfx]
>
> Hi Yuly, here's a slightly modified version of your patch, rebased on
> drm-intel-next-queued. I kept your authorship, but any new errors are
> totally mine...
>
> These are compile tested only; I'd appreciate if you could check it
2012/10/26 Daniel Vetter :
> The debug message is only relevant on CPT/PPT PCH ports, so move
> it into the correct if clause.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_dp.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> dif
Hi
2012/10/26 Daniel Vetter :
> We need to set the timing override chicken bit after fdi link training
> has completed and before we enable the dp transcoder. We also have to
> clear that bit again after disabling the pch dp transcoder.
>
> See "Graphics BSpec: vol4g North Display Engine Registers
On Tue, 23 Oct 2012, Chris Wilson wrote:
> On Mon, 22 Oct 2012 16:12:18 +0300, Jani Nikula wrote:
>> SDVOB may be multiplexed with HDMIB. If it's not SDVOB, the same i2c
>> adapter may be used for HDMIB, with the adjusted config (i.e. with GPIO
>> bit-banging instead of gmbus). Restore i2c adapte
Hi
2012/10/26 Daniel Vetter :
> Since it is one. We need to move this code to encoder specific callbacks
> eventually, to kill all that inversion of control ...
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 4 +---
> 1 file changed,
Hi
2012/10/26 Daniel Vetter :
> They are all written for a specific north disaplay->pch combination.
> So stop pretending otherwise.
>
So how about we go deeper in this "stop pretending" thing and add some
checks inside intel_detect_pch printing loud messages in case the CPU
and the PCH are not s
On Thu, Oct 25, 2012 at 09:51:06AM +0100, Chris Wilson wrote:
> On Thu, 25 Oct 2012 10:57:38 +0300, Jani Nikula wrote:
> > commit 28dcc2d60cb570d9f549c329b2f51400553412a1
> > Author: Jani Nikula
> > Date: Mon Sep 3 16:25:12 2012 +0300
> >
> > drm/i915: do not expose a dysfunctional backlig
On Fri, Oct 26, 2012 at 12:06:41PM +0100, Chris Wilson wrote:
> Otherwise we may remove the only console for a nomodeset system.
>
> We became more aggressive in our kicking with
> commit e188719a2891f01b3100dca4ae3a055fb5a7ab52
> Author: Daniel Vetter
> Date: Tue Jun 12 11:28:17 2012 +0200
>
On Thu, 25 Oct 2012 18:06:19 +0100
Damien Lespiau wrote:
> From: Damien Lespiau
>
> Just like HSW, VLV does not have a sprite scale. Set
> intel_plane->can_scale accordingly.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_sprite.c |2 +-
> 1 files changed, 1 inserti
From: Paulo Zanoni
Also document the WA name for the previous gens that implement it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 59068be..150a
On Fri, 26 Oct 2012 09:25:21 -0700
Jesse Barnes wrote:
> On Thu, 25 Oct 2012 18:06:19 +0100
> Damien Lespiau wrote:
>
> > From: Damien Lespiau
> >
> > Just like HSW, VLV does not have a sprite scale. Set
> > intel_plane->can_scale accordingly.
> >
> > Signed-off-by: Damien Lespiau
> > ---
>
On Fri, Oct 26, 2012 at 09:25:21AM -0700, Jesse Barnes wrote:
> On Thu, 25 Oct 2012 18:06:19 +0100
> Damien Lespiau wrote:
>
> > From: Damien Lespiau
> >
> > Just like HSW, VLV does not have a sprite scale. Set
> > intel_plane->can_scale accordingly.
> >
> > Signed-off-by: Damien Lespiau
> >
On Fri, 26 Oct 2012 12:13:39 +0100
Chris Wilson wrote:
> On Thu, 25 Oct 2012 12:15:46 -0700, Jesse Barnes
> wrote:
> > So store into the scratch space of the HWS to make sure the invalidate
> > occurs.
> >
> > v2: use GTT address space for store, clean up #defines (Chris)
> >
> > Signed-off-b
Communicating via the mailbox registers with the PCU can take quite
awhile. And updating the ring frequency or enabling turbo is not
something that needs to happen synchronously, so take it out of our init
and resume paths to speed things up (~200ms on my T420).
v2: add comment about why we use a
The BIOS shouldn't be touching this memory across suspend/resume, so
just leave it alone. This saves us ~50ms on resume on my T420.
v2: change gtt restore default on pre-gen4 (Chris)
move needs_gtt_restore flag into dev_priv
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |
The console lock can be contended, so rather than prevent other drivers
after us from being held up, queue the console suspend into the global
work queue that can happen anytime. I've measured this to take around
200ms on my T420. Combined with the ring freq/turbo change, we should
save almost 1/
We should only ever go below RP1 for thermal reasons. Users can still
control this through sysfs by manually reducing the minimum frequency
(and max if they want to clamp their frequency for power reasons, e.g.
to keep fans off or something).
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915
From: Damien Lespiau
HSW consolidates SPRTILEOFF and SPRLINOFF into a single SPROFFSET
register.
v2: Remove a useless level of indentation (Paulo Zanoni)
Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni (v1)
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_s
From: Damien Lespiau
Just like in:
commit c2c75131244507c93f812862fdbd4f3a37139401
Author: Daniel Vetter
Date: Thu Jul 5 12:17:30 2012 +0200
drm/i915: adjust framebuffer base address on gen4+
but this time, for the sprite planes. This ensures that the
sprite offset are always inside the
From: Damien Lespiau
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_sprite.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 3434b6e..aa8d09b 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
On Fri, 26 Oct 2012 18:30:50 +0100
Damien Lespiau wrote:
> From: Damien Lespiau
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_spri
I'm missing some context here... but why not just run 'sysctl
kernel.printk=8' wherever this is needed?
BR,
Jani.
On Fri, 26 Oct 2012, Daniel Vetter wrote:
> From: root
>
> ---
> bin/set_debug_dmesg.c | 8
> 1 file changed, 8 insertions(+)
> create mode 100644 bin/set_debug_dmesg.c
On Fri, Oct 26, 2012 at 8:14 PM, Jani Nikula
wrote:
> I'm missing some context here... but why not just run 'sysctl
> kernel.printk=8' wherever this is needed?
It leaked from my private dotfiles repo. The reason against a cmdline
option is the need to walk over to the box ;-) This thing here is p
On Thu, Oct 25, 2012 at 11:00:32AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/10/25 Jani Nikula :
> > At some point the DPCD size was increased, but the debug print not. While
> > at it, switch to using hex dump.
> >
> > Signed-off-by: Jani Nikula
>
> Reviewed-by: Paulo Zanoni
Queued for -next, t
Jesse Barnes writes:
> We should only ever go below RP1 for thermal reasons. Users can still
> control this through sysfs by manually reducing the minimum frequency
> (and max if they want to clamp their frequency for power reasons, e.g.
> to keep fans off or something).
I think I know what the
On Fri, 26 Oct 2012 11:32:08 -0700
Eric Anholt wrote:
> Jesse Barnes writes:
>
> > We should only ever go below RP1 for thermal reasons. Users can still
> > control this through sysfs by manually reducing the minimum frequency
> > (and max if they want to clamp their frequency for power reason
On Fri, 26 Oct 2012 00:47:31 +0200
Daniel Vetter wrote:
> On Thu, Oct 25, 2012 at 03:39:08PM -0700, Jesse Barnes wrote:
> > > > It would be cool to actually remove the dep for pre-gen6. I
> > > > don't think we need this patch in either case.
> > > >
> > >
> > > Your linker is going to complai
As a quick hack we make the old intel_gtt structure mutable so we can
fool a bunch of the existing code which depends on elements in that data
structure. We can/should try to remove this in a subsequent patch.
This should preserve the old gtt init behavior which upon writing these
patches seems in
This allows us to map the PTEs WC. I've not done thorough testing or
performance measurements with this patch, but it should be decent.
This is based on a patch from Jesse with the original commit message
> I've only lightly tested this so far, but the corruption seems to be
> gone if I write the
On Mon, 22 Oct 2012 18:34:05 -0700
Ben Widawsky wrote:
> As a result of some work which I can't yet talk about, it became
> obvious that now was the time to kill AGP. As this is actually prep
> work for the interesting stuff but the interesting stuff can't be
> released yet, I serve it up here fo
From: Paulo Zanoni
Hi
Finally, the last piece of the Haswell DP enablement: after this series xrandr
should show your connected DP monitors and hopefully enable them.
The problem this series tries to solve is that both DP and HDMI share the same
registers for any given port. So you can't just "
From: Paulo Zanoni
- Replace container_of with enc_to_intel_dp.
- Walk through less structures when making assignments.
- Rename some variables to keep our naming standards.
As a bonus, this will reduce the usage of "struct intel_dp", making
the future patch that introduces intel_digital_port
From: Paulo Zanoni
When we add struct intel_digital_port, there will be no direct way of
going from intel_{dp,hdmi} to drm_device: we will need to call
container_of().
This patch adds functions to go from intel_{dp,hdmi} to drm_device.
The main goal here is to greatly reduce the size of the next
From: Paulo Zanoni
The goal is to have one single encoder capable of controlling both DP
and HDMI outputs. This patch just adds the initial infrastructure, no
functional changes.
Previously, both intel_dp and intel_hdmi were intel_encoders. Now,
these 2 structs do not have intel_encoder as membe
From: Paulo Zanoni
We want to split the HDMI connector and encoder initialization because
in the future the DDI code will have its own "encoder init" function,
but it will still call intel_hdmi_init_connector. The DDI encoder will
actually have two connectors attached to it: HDMI and DP.
The bes
From: Paulo Zanoni
Same reason as the previous HDMI commit: the DDI code will have its
own encoder init function but still use the DP and HDMI connectors.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 125 ++--
1 file changed, 68 insertio
From: Paulo Zanoni
When intel_hdmi_detect detects a monitor, set intel_encoder->type with
INTEL_OUTPUT_HDMI. Same for DP.
This should not break the current code because these variables never
change. This will be used after we create the DDI encoder because it
will have both DP and HDMI connector
From: Paulo Zanoni
Both "intel_dp" and "intel_hdmi" structs had a "port" field, which
always had the same value. It makes more sense to move this to
intel_digital_port, so we can know the port independently of the
connector type.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c
From: Paulo Zanoni
We need this since now on DDI we will have 2 connectors on each
encoder.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 40 +++
drivers/gpu/drm/i915/intel_dp.c | 6 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
d
From: Paulo Zanoni
Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it
inits the encoder and then calls the proper init_connector functions.
Notice that for non-eDP ports we call both HDMI and DP connector init,
so we have 2 connectors attached to each DDI encoder.
After this c
On Fri, 19 Oct 2012 18:03:07 +0100
Chris Wilson wrote:
> To be used later by i915 to preallocate exact blocks of space from the
> range manager.
>
> Signed-off-by: Chris Wilson
> Cc: Dave Airlie
> Cc: dri-de...@lists.freedestkop.org
With bikesheds below addressed or not:
Reviewed-by: Ben Wida
On Fri, 19 Oct 2012 18:03:09 +0100
Chris Wilson wrote:
> A few of the earlier registers where enlarged and so the Base Data of
> Stolen Memory Register (BDSM) was pushed to 0xb0.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Jesse Barnes
This patch seems irrelevant to me. I have a i915_stole
On Fri, 19 Oct 2012 18:03:10 +0100
Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Reviewed-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.h |2 ++
> drivers/gpu/drm/i915/i915_gem_gtt.c | 35
> ---
> 2 files changed, 34 insertions(+), 3 del
68 matches
Mail list logo
