On Mon, 22 Oct 2012 17:54:26 Mark Hounschell wrote:
> Another interesting thing. I changed the boot file to only
> "video=HDMI-A-1:e" and the monitor on the DVI port complains about the
> resolution being to high. I then put the hdmi cable onto my dvi/hdmi
> adapter and plug it into the DVI port
On Tue, Oct 23, 2012 at 12:21 AM, Jesse Barnes wrote:
> On Fri, 19 Oct 2012 18:03:24 +0100
> Chris Wilson wrote:
>
>> By exporting the ability to map user address and inserting PTEs
>> representing their backing pages into the GTT, we can exploit UMA in order
>> to utilize normal application data
On Tue, Oct 23, 2012 at 12:04 AM, Jesse Barnes wrote:
> If the current field is not zero and doesn't match the VBT, we might
> add a debug statement. It could indicate a BIOS programmed value that
> didn't involve a VBT update (I can imagine some vendors might do
> this). Overwriting the current
On Mon, Oct 22, 2012 at 08:40:08PM +0300, Imre Deak wrote:
> Signed-off-by: Imre Deak
As discussed on irc, I still have a few whishlists items for this one here
left. Patches 1-4 are merged, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.
Signed-off-by: Imre Deak
---
tests/flip_test.c | 58 -
1 file changed, 48 insertions(+), 10 deletions(-)
In v2:
- Wait for the seq that just completed (current_seq) not last_seq - 1.
- Do an equality check for ts and seq instead of >=. The pr
On Mon, Oct 22, 2012 at 12:55:55PM +0200, Daniel Vetter wrote:
> The overlay on the i830M has a peculiar failure mode: It works the
> first time around after boot-up, but consistenly hangs the second time
> it's used.
>
> Chris Wilson has dug out a nice errata:
>
> "1.5.12 Clock Gating Disable fo
On Tue, 23 Oct 2012 08:36:23 +0200, Bruno Prémont
wrote:
> On Mon, 22 Oct 2012 17:54:26 Mark Hounschell wrote:
> > I'm still getting the same messages spewed into the kernel log file. So
> > this looks to me like the kernel is confused. Again, I ask, why do I have 3
> > HDMIs and 3 DPs but jus
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 adapter config before error
> return from intel_sdvo_
On Sun, 21 Oct 2012 23:26:29 +0200, Daniel Vetter
wrote:
> The bit doesn't stick, and the output is always cloned from pipe A,
> even when it's supposed to scan out from pipe B.
>
> Shuts up annoying warnings from the modeset-rework, too.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?
On Sat, 20 Oct 2012 21:13:05 +0200, Daniel Vetter
wrote:
> ... like the comment says. No idea whether this has any effect, but
> I guess it's better to not lie to the display by acking a test request
> and never following through with it.
>
> Signed-off-by: Daniel Vetter
Ha, if I've learnt any
On Tue, 23 Oct 2012 11:12:02 +0200, Daniel Vetter wrote:
> On Mon, Oct 22, 2012 at 12:55:55PM +0200, Daniel Vetter wrote:
> > The overlay on the i830M has a peculiar failure mode: It works the
> > first time around after boot-up, but consistenly hangs the second time
> > it's used.
> >
> > Chris
On 10/23/2012 02:36 AM, Bruno Prémont wrote:
On Mon, 22 Oct 2012 17:54:26 Mark Hounschell wrote:
Another interesting thing. I changed the boot file to only
"video=HDMI-A-1:e" and the monitor on the DVI port complains about the
resolution being to high. I then put the hdmi cable onto my dvi/hdmi
On Mon, 22 Oct 2012 18:34:11 -0700, Ben Widawsky wrote:
> +/*
> + * Binds an object into the global gtt with the specified cache level. The
> object
> + * will be accessible to the GPU via commands whose operands reference
> offsets
> + * within the global GTT as well as accessible by the GPU th
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 adapter config before error
> return from intel_sdvo_
On Mon, 22 Oct 2012 18:34:06 -0700, Ben Widawsky wrote:
> The mid-level cache or as it's more commonly referred to now as L3, is
> not setup this way on HSW.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletio
On Tue, Oct 23, 2012 at 12:07:52PM +0300, Imre Deak wrote:
> Signed-off-by: Imre Deak
> ---
> tests/flip_test.c | 58
> -
> 1 file changed, 48 insertions(+), 10 deletions(-)
>
> In v2:
> - Wait for the seq that just completed (current_seq) n
On Tue, Oct 23, 2012 at 10:56:46AM +0100, Chris Wilson wrote:
> On Tue, 23 Oct 2012 11:12:02 +0200, Daniel Vetter wrote:
> > On Mon, Oct 22, 2012 at 12:55:55PM +0200, Daniel Vetter wrote:
> > > The overlay on the i830M has a peculiar failure mode: It works the
> > > first time around after boot-up
On Tue, Oct 23, 2012 at 10:49:23AM +0100, Chris Wilson wrote:
> On Sun, 21 Oct 2012 23:26:29 +0200, Daniel Vetter
> wrote:
> > The bit doesn't stick, and the output is always cloned from pipe A,
> > even when it's supposed to scan out from pipe B.
> >
> > Shuts up annoying warnings from the mode
On Tue, 2012-10-09 at 01:00 +0200, Mario Kleiner wrote:
> On 08.10.12 13:35, Imre Deak wrote:
> > On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote:
> >> [...]
> >>
> >> But then Psychtoolbox checks each timestamp it gets from somewhere
> >> "outside" (OML_sync_control / INTEL_swap_events / AL
On Thu, 18 Oct 2012 13:07:17 -0500, Jesse Barnes
wrote:
> So store into the scratch space of the HWS to make sure the invalidate
> occurs.
Whoops, instant hang. Probably doesn't agree with being called FLUSH_SW
and not FLUSH_DW! ;-)
> + /*
> + * Bspec vol 1c.5 - video engine command st
On Tue, 2012-10-23 at 12:46 +0200, Daniel Vetter wrote:
> On Tue, Oct 23, 2012 at 12:07:52PM +0300, Imre Deak wrote:
> > Signed-off-by: Imre Deak
> > ---
> > tests/flip_test.c | 58
> > -
> > 1 file changed, 48 insertions(+), 10 deletions(-)
On Thu, 18 Oct 2012 13:07:18 -0500, Jesse Barnes
wrote:
> "If ENABLED, PIPE_CONTROL command will flush the in flight data written
> out by render engine to Global Observation point on flush done. Also
> Requires stall bit ([20] of DW1) set."
That quotation doesn't make sense in the context of T
Hi
2012/10/20 Daniel Vetter :
> Hi all,
>
> This is useful fallout of my futile attempts at getting the eDP panel on my
> ivb
> working without the BIOS' help. I now at least get a backlit black screen
> though
> ;-)
>
> Paulo said that this is good enough for his hsw eDP machine already, and it
On Mon, 22 Oct 2012 18:19:27 +0100
Damien Lespiau wrote:
> From: Damien Lespiau
>
> Haswell does not have a scaler in the sprite pipeline anymore, so let's
> ensure:
> 1/ We bail out of update_plate() when someone is trying to ask to
> display a scaled framebuffer,
> 2/ We never write
On Mon, 22 Oct 2012 18:34:14 -0700
Ben Widawsky wrote:
> 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
On Tue, 23 Oct 2012 09:23:00 +0200
Daniel Vetter wrote:
> On Tue, Oct 23, 2012 at 12:04 AM, Jesse Barnes
> wrote:
> > If the current field is not zero and doesn't match the VBT, we might
> > add a debug statement. It could indicate a BIOS programmed value that
> > didn't involve a VBT update (
On Tue, 23 Oct 2012 10:53:07 +0100
Chris Wilson wrote:
> On Sat, 20 Oct 2012 21:13:05 +0200, Daniel Vetter
> wrote:
> > ... like the comment says. No idea whether this has any effect, but
> > I guess it's better to not lie to the display by acking a test request
> > and never following through
On Tue, 23 Oct 2012 12:22:16 +0100
Chris Wilson wrote:
> On Thu, 18 Oct 2012 13:07:17 -0500, Jesse Barnes
> wrote:
> > So store into the scratch space of the HWS to make sure the invalidate
> > occurs.
>
> Whoops, instant hang. Probably doesn't agree with being called FLUSH_SW
> and not FLUSH_
On Tue, Oct 23, 2012 at 07:17:53AM -0700, Jesse Barnes wrote:
> On Mon, 22 Oct 2012 18:34:14 -0700
> Ben Widawsky wrote:
>
> > 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 pa
On Tue, 23 Oct 2012 16:28:53 +0200
Daniel Vetter wrote:
> On Tue, Oct 23, 2012 at 07:17:53AM -0700, Jesse Barnes wrote:
> > On Mon, 22 Oct 2012 18:34:14 -0700
> > Ben Widawsky wrote:
> >
> > > This allows us to map the PTEs WC. I've not done thorough testing or
> > > performance measurements wi
On Tue, Oct 23, 2012 at 07:25:35AM -0700, Jesse Barnes wrote:
> On Tue, 23 Oct 2012 10:53:07 +0100
> Chris Wilson wrote:
>
> > On Sat, 20 Oct 2012 21:13:05 +0200, Daniel Vetter
> > wrote:
> > > ... like the comment says. No idea whether this has any effect, but
> > > I guess it's better to not
On Tue, 23 Oct 2012 07:35:48 -0700
Jesse Barnes wrote:
> On Tue, 23 Oct 2012 16:28:53 +0200
> Daniel Vetter wrote:
>
> > On Tue, Oct 23, 2012 at 07:17:53AM -0700, Jesse Barnes wrote:
> > > On Mon, 22 Oct 2012 18:34:14 -0700
> > > Ben Widawsky wrote:
> > >
> > > > This allows us to map the PTE
On Tue, Oct 23, 2012 at 07:16:03AM -0700, Jesse Barnes wrote:
> On Mon, 22 Oct 2012 18:19:27 +0100
> Damien Lespiau wrote:
>
> > From: Damien Lespiau
> >
> > Haswell does not have a scaler in the sprite pipeline anymore, so let's
> > ensure:
> > 1/ We bail out of update_plate() when someone i
On 2012-10-23 02:59, Chris Wilson wrote:
On Mon, 22 Oct 2012 18:34:11 -0700, Ben Widawsky
wrote:
+/*
+ * Binds an object into the global gtt with the specified cache
level. The object
+ * will be accessible to the GPU via commands whose operands
reference offsets
+ * within the global GTT as
On Tue, Oct 23, 2012 at 4:57 PM, Ben Widawsky wrote:
> Actually, after we introduce the FLSH_CNTL patch from Jesse/me later in the
> series, I think we just want a POSTING_READ on that register. It is
> technically "required" by our desire to some day WC the registers, and
> should synchronize eve
Hi
2012/10/23 Daniel Vetter :
> On Tue, Oct 23, 2012 at 07:16:03AM -0700, Jesse Barnes wrote:
>> On Mon, 22 Oct 2012 18:19:27 +0100
>> Damien Lespiau wrote:
>>
>> > From: Damien Lespiau
>> >
>> > Haswell does not have a scaler in the sprite pipeline anymore, so let's
>> > ensure:
>> > 1/ We ba
From: Damien Lespiau
Haswell does not have a scaler in the sprite pipeline anymore, so let's
ensure:
1/ We bail out of update_plate() when someone is trying to ask to
display a scaled framebuffer,
2/ We never write to the nonexistent SPR_SCALE register
Signed-off-by: Damien Lespiau
---
On 10/22/2012 07:42 AM, Mark Hounschell wrote:
On 10/21/2012 03:18 PM, Bruno Prémont wrote:
Hi Mark,
On Sun, 21 October 2012 Mark Hounschell wrote:
On 10/21/2012 10:58 AM, Bruno Prémont wrote:
On Sun, 21 October 2012 Mark Hounschell wrote:
I have a TV that appears to not provide proper EDID
On Mon, Oct 22, 2012 at 03:08:38PM -0700, Jesse Barnes wrote:
> On Sat, 20 Oct 2012 20:57:45 +0200
> Daniel Vetter wrote:
>
> > That thing has grown way too big already.
> >
> > Also move around a comment to the right spot.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915
From: Damien Lespiau
A left over from:
drm/i915: Don't try to use SPR_SCALE when we don't have a sprite scaler
We also need to avoid to reset this register in _disable()
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_sprite.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletio
On Tue, Oct 23, 2012 at 06:24:25PM +0100, Damien Lespiau wrote:
> From: Damien Lespiau
>
> A left over from:
> drm/i915: Don't try to use SPR_SCALE when we don't have a sprite scaler
>
> We also need to avoid to reset this register in _disable()
>
> Signed-off-by: Damien Lespiau
Squashed in
Daniel Vetter writes:
> On Tue, Oct 23, 2012 at 12:21 AM, Jesse Barnes
> wrote:
>> On Fri, 19 Oct 2012 18:03:24 +0100
>> Chris Wilson wrote:
>>
>>> By exporting the ability to map user address and inserting PTEs
>>> representing their backing pages into the GTT, we can exploit UMA in order
>>>
This is needed to make applications using wait-for-vblank/page-flip
timestamps independent of time ajdustments other than adjustments for
HW clock jitter.
I've tested these with an updated intel-gpu-test/flip_test and will send
the update for that once there's no objection about this patchset.
Th
For measuring duration we want to avoid that our start/end timestamps
jump, so use monotonic instead of real time for that.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_irq.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b
Jumps in the vblank and page flip event timestamps cause trouble for
clients, so we should avoid them. The timestamp we get currently with
gettimeofday can jump, so use instead monotonic timestamps.
For backward compatibility use a module flag to revert back to using
gettimeofday timestamps. Add a
On Tue, 23 Oct 2012 16:58:50 +0200
Daniel Vetter wrote:
> On Tue, Oct 23, 2012 at 4:57 PM, Ben Widawsky wrote:
> > Actually, after we introduce the FLSH_CNTL patch from Jesse/me later in the
> > series, I think we just want a POSTING_READ on that register. It is
> > technically "required" by our
On Tue, Oct 23, 2012 at 9:57 PM, Ben Widawsky wrote:
>> On Tue, Oct 23, 2012 at 4:57 PM, Ben Widawsky wrote:
>> > Actually, after we introduce the FLSH_CNTL patch from Jesse/me later in the
>> > series, I think we just want a POSTING_READ on that register. It is
>> > technically "required" by our
Add a check to intel_dp_dpms() to skip setting the DP's DPMS mode if
the current mode is the same as the new one.
Signed-off-by: Simon Que
---
drivers/gpu/drm/i915/intel_dp.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gp
On Tue, 23 Oct 2012 22:03:21 +0200
Daniel Vetter wrote:
> On Tue, Oct 23, 2012 at 9:57 PM, Ben Widawsky wrote:
> >> On Tue, Oct 23, 2012 at 4:57 PM, Ben Widawsky wrote:
> >> > Actually, after we introduce the FLSH_CNTL patch from Jesse/me later in
> >> > the
> >> > series, I think we just want
From: Paulo Zanoni
Hi
Here is the third version, which is the result of the discussions I had with
Daniel both on the mailing list and on IRC.
In my discussions with Daniel we were wondering about code that would or would
not be run on VGA (the only output that requires the PCH), so what I actu
From: Paulo Zanoni
The way we enable and disable the PCH on Haswell changed considerably
since now we have only one PCH transcoder, so we can't keep the same
asserts and we also can't just unconditionally disable the PCH
transcoder for non-PCH outputs. So let's fork a Haswell version.
These new
From: Paulo Zanoni
The last commit just forked the functions, this one removes Haswell
code from the Ironlake functions and removes Ironlake code from the
Haswell functions.
It is worth noticing that we are not considering CPT possible on
Haswell anymore. So far on Haswell enablement we kept try
From: Paulo Zanoni
By forking Ironlake and Haswell functions. The only callers are
{ironlake,haswell}_crtc_enable anyway, and this way we won't need to
add other checks on the Haswell version for the next gens.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 31 +
From: Paulo Zanoni
On Ironlake we have one PCH transcoder and FDI per pipe, so we know
that if ironlake_crtc_driving_pch returns false we can disable the PCH
transcoder and we also know that when we disable the crtc we can also
disable the PCH transcoder.
On Haswell there is only 1 PCH transcode
From: Paulo Zanoni
Before Haswell we used to have the CPU pipes and the PCH transcoders.
We had the same amount of pipes and transcoders, and there was a 1:1
mapping between them. After Haswell what we used to call CPU pipe was
split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A
From: Paulo Zanoni
This register appeared in Haswell. It does not have an EDP version
because the EDP transcoder is always tied to the DDIA clock. Notice
that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder
is TRANSCODER_EDP we might introduce a bug, that's why this is a
transcod
From: Paulo Zanoni
Because there's one instance of the register per CPU transcoder and
not per CPU pipe. This is another register that appeared for the first
time on Haswell, and even though its Haswell name is
PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's
just use the new
From: Paulo Zanoni
We need to check if any of the pipes is using TRANSCODER_EDP.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/inte
From: Paulo Zanoni
Because the PIPECONF register is actually part of the CPU transcoder,
not the CPU pipe.
Ideally we would also rename PIPECONF to TRANSCONF to remind people
that they should use the transcoder instead of the pipe, but let's
keep it like this for now since most Gens still name i
From: Paulo Zanoni
Same as the other registers. This one also appeared on Haswell for the
first time, so that's why we are renaming it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 19 ++-
drivers/gpu/drm/i915/intel_ddi.c | 18 +-
2 files c
From: Paulo Zanoni
Same thing as the previous commits. Not renaming this one since it
exists since way before Haswell.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 16
drivers/gpu/drm/i915/intel_display.c | 10 +-
drivers/gpu/drm/i915/intel_dp
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 8 +---
drivers/gpu/drm/i915/i915_reg.h | 14 +++---
drivers/gpu/drm/i915/intel_display.c | 37 ++--
3 files changed, 31 insertions(+), 28 deletions(-)
di
From: Paulo Zanoni
See the documentation for the DDI_FUNC_CTL register, EDP Input Select
bits: when the EDP input selection is B, the VTOTAL_B must be
programmed with the VTOTAL_EDP value, same thing for selection C.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 3283f6f..106c375 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++
From: Paulo Zanoni
The cdclk frequency is not always the same, so the value here should
be adjusted to match it.
Version 2: call intel_ddi_get_cdclk_freq instead of reading
CDCLK_FREQ, because the register is just for earlier HW steppings.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 15 +--
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 6 --
3 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/
From: Paulo Zanoni
It's an important step :)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 18 --
drivers/gpu/drm/i915/intel_dp.c | 11 ---
drivers/gpu/drm/i915/intel_drv.h | 4
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/
From: Paulo Zanoni
Now that all the eDP enablement bits are there, we can actually try to
use the eDP.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/in
On Tue, Oct 23, 2012 at 01:18:46PM -0700, Simon Que wrote:
> Add a check to intel_dp_dpms() to skip setting the DP's DPMS mode if
> the current mode is the same as the new one.
>
> Signed-off-by: Simon Que
The modeset rework, merged into 3.7 solves this entire disaster rather
neatly ... We won't
On Tue, Oct 23, 2012 at 06:30:03PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> See the documentation for the DDI_FUNC_CTL register, EDP Input Select
> bits: when the EDP input selection is B, the VTOTAL_B must be
> programmed with the VTOTAL_EDP value, same thing for selection C.
>
> Sig
On 17 October 2012 00:43, Daniel Vetter wrote:
> On Tue, Oct 16, 2012 at 6:10 PM, Daniel J Blueman wrote:
>> [drm:intel_dp_init], cur t1_t3 0 t8 0 t9 0 t10 0 t11_t12 4000
>> [drm:intel_dp_init], vbt t1_t3 0 t8 0 t9 0 t10 0 t11_t12 0
>> [drm:intel_dp_init], panel power up delay 21, power down dela
71 matches
Mail list logo
