When we reset the ring control registers, including the HEAD and TAIL of
the ring, we also need to reset associated state. In this instance, we
were failing to reset the cached value of ring->last_retired_head and so
upon the first request for more space following a resume would
potentially (depend
Dear Ben,
Am Freitag, den 25.05.2012, 16:56 -0700 schrieb Ben Widawsky:
an output of a working run of `dpf_test` with some explanation pasted
into the commit message would be nice as there is no manual page.
> Signed-off-by: Ben Widawsky
> ---
> tests/dpf_test |8 +++
> tools/Mak
2012/5/28 Chris Wilson :
> On Mon, 28 May 2012 16:42:49 -0300, Paulo Zanoni wrote:
>> This patch adds the code to fix the problem, but it depends on the
>> removal of some code that can't be removed right now and will come
>> later in the patch series. The patch that we need is:
>> - drm/i915: d
On Mon, 28 May 2012 16:42:49 -0300, Paulo Zanoni wrote:
> This patch adds the code to fix the problem, but it depends on the
> removal of some code that can't be removed right now and will come
> later in the patch series. The patch that we need is:
> - drm/i915: don't write 0 to DIP control at
From: Paulo Zanoni
This function is supposed to be used at mode set time, so prevent
against future mistakes by adding a WARN().
Problems when calling it when the HDMI port is enabled:
- It may disable sending DIPs (on IVB and older), and the register
specification says we shouldn't disabl
From: Paulo Zanoni
On IVB and older, we basically have two registers: the control and the
data register. We write a few consecutitve times to the control
register, and we need these writes to arrive exactly in the specified
order.
Also, when we're changing the data register, we need to guarantee
From: Paulo Zanoni
Some HDMI registers can be used for SDVO, so saying "HDMIB" should be
the same as saying "SDVOB" for a given HW generation. This was not
true and led to confusions and even a regression.
Previously we had:
- SDVO{B,C} defined as the Gen3+ resgisters
- HDMI{B,C,D} and PCH_SDV
From: Paulo Zanoni
HSW support is now just like all the other generations: we send AVI
and SPD InfoFrames. There are other DIPs for HSW, but there are other
DIPs for the previous generations too. For each gen, we can see which
DIPs are missing by looking at the 'set_infoframes' function: we
expli
From: Paulo Zanoni
Some (but not all) of the HDMI registers can be used to control sDVO,
so these registers have two names. When we're talking about HDMI, we
really should call the HDMI control register "hdmi_reg" instead of
"sdvox_reg". So now "struct intel_hdmi" has a member called "hdmi_reg"
i
From: Paulo Zanoni
The register that controls the HDMI port can be used to control the
sDVO port. Some bits are defined only for sDVO, and SDVO_BORDER_ENABLE
is one of those: HDMI ports that can't be used in sDVO mode don't even
have this bit defined in their specifications.
Signed-off-by: Paulo
From: Paulo Zanoni
At this time, the HDMI port is enabled, and the DIP control register
specification says we need to disable the port *before* disabling the
DIPs. Also, while doing this we risk telling the HW to send the AVI
DIPs once (not every VSync), which really seems to confuse the HW and
t
From: Paulo Zanoni
The register specification says we need to do this.
V2: Only write the register if the port is enabled.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_hdmi.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/
From: Paulo Zanoni
>From this point on, the 'set_infoframe' functions always set the DIP
registers to a known state, so anything done will always be undone at
the modeset.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h |6 ++
drivers/gpu/drm/i915/intel_hdmi.c | 13
From: Paulo Zanoni
This function is called when the pipe is disabled, so it always gets
the 50ms timeout.
This function is called once for each InfoFrame, so we actually get a
100ms timeout. Will be more if we add more InfoFrames.
Also, the spec says we need to "wait for a VSync to ensure compl
From: Paulo Zanoni
So the write_infoframe function can assume the DIP is on.
V2: Be more defensive and add WARN().
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_hdmi.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gp
From: Paulo Zanoni
Not once for each InfoFrame. Now we have a function that allows us to
do this.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_hdmi.c | 56 -
1 file changed, 31 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Paulo Zanoni
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mod
From: Paulo Zanoni
We need a function that is able to fully 'set' the state of the DIP
registers to a known state.
Currently, we have the write_infoframe function that is called twice:
once for AVI and once for SPD. The problem is that write_infoframe
tries to keep the state of the DIP register
From: Paulo Zanoni
Following the comments I received and the discussions I had on IRC with Chris
and Daniel, here is the updated version. Even patch 0001 had changes, so I had
to do small adjustments on basically every single patch of the series so they
apply again.
Here is a list of changes:
0
On Sat, May 26, 2012 at 11:05 AM, Oleksij Rempel (fishor)
wrote:
> Hallo devs,
>
> i get this errors:
> [ 9.267502] [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
> GEN6_RP_INTERRUPT_LIMITS expected 1800, was 1206
> [ 28.168979] [drm:gen6_sanitize_pm] *ERROR* Power manag
Il 28/05/2012 08:14, Oliver Seitz ha scritto:
Is this true? I've seen no changes for a long time. I thought maybe
maintainers see no need to work on software that does it's job. I would
be very sorry if it was really dead.
No need? What about trying to mainline it for example? :)
Anyway I'm sti
21 matches
Mail list logo
