On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote:
The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.
v2: Address review comments by Jani
- adjust code for the structure changes for bdb_mipi_config
- add boundry and
On Mon, Apr 14, 2014 at 12:19:58PM +0800, Zhao Yakui wrote:
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the CPU-GPU sync for the second BSD ring. Multi drm_fd can assure that the
On Mon, Apr 14, 2014 at 12:21:39PM +0800, Zhao Yakui wrote:
V1-V2: Follow Daniel's comment to consider the stolen check for BDW in
kernel/early-quirks.c
Small style nit: We usually put the patch changelog at the end of the
commit message. That way the core commit message is clearly separated
On Mon, 2014-04-14 at 01:09 -0600, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 12:21:39PM +0800, Zhao Yakui wrote:
V1-V2: Follow Daniel's comment to consider the stolen check for BDW in
kernel/early-quirks.c
Small style nit: We usually put the patch changelog at the end of the
commit
On Mon, Apr 14, 2014 at 12:21:44PM +0800, Zhao Yakui wrote:
V1-V2: Follow Daniel's comment and use the simple ping-pong mechanism.
This is only to add the support of dual BSD rings on BDW GT3 machine.
The further optimization will be considered in another patch set.
The BDW GT3 has two
On Mon, 2014-04-14 at 01:06 -0600, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 12:19:58PM +0800, Zhao Yakui wrote:
The Broadwell GT3 machine has two independent BSD rings in kernel driver
while
it is transparent to the user-space driver. In such case it needs to check
the CPU-GPU sync
Hi,
Finally I did it. Interested parties can find it below. If anybody has
better ways to do it please suggest.
1) Revert the commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1.
With this commit DP hotplug events are not coming after doing xset dpms
force off
commit
On Mon, Apr 14, 2014 at 9:43 AM, Arun Chandran achand...@mvista.com wrote:
1) Revert the commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1.
With this commit DP hotplug events are not coming after doing xset dpms
force off
commit bfcbf45b5b458ebdc38118ca67279a1cd90e085d
Author: Arun Chandran
On Mon, 2014-04-14 at 01:06 -0600, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 12:19:58PM +0800, Zhao Yakui wrote:
The Broadwell GT3 machine has two independent BSD rings in kernel driver
while
it is transparent to the user-space driver. In such case it needs to check
the CPU-GPU sync
On 4/14/2014 12:32 PM, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote:
The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.
v2: Address review comments by Jani
- adjust code for the structure changes for
On Mon, Apr 14, 2014 at 9:32 AM, Zhao Yakui yakui.z...@intel.com wrote:
BTW: How do I update the .gitigonre?
In my test I usually use the following step to create the corresponding
patches before sending and never update the .gitignore.
a. use quilt tool to create it
b. use git am
On Mon, 2014-04-14 at 01:22 -0600, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 12:21:44PM +0800, Zhao Yakui wrote:
V1-V2: Follow Daniel's comment and use the simple ping-pong mechanism.
This is only to add the support of dual BSD rings on BDW GT3 machine.
The further optimization will be
On Mon, 2014-04-14 at 01:55 -0600, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 9:32 AM, Zhao Yakui yakui.z...@intel.com wrote:
BTW: How do I update the .gitigonre?
In my test I usually use the following step to create the corresponding
patches before sending and never update the
On Mon, 2014-04-14 at 09:47 +0200, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 9:43 AM, Arun Chandran achand...@mvista.com wrote:
1) Revert the commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1.
With this commit DP hotplug events are not coming after doing xset dpms
force off
commit
On Mon, Apr 14, 2014 at 04:05:19PM +0800, Zhao Yakui wrote:
On Mon, 2014-04-14 at 01:22 -0600, Daniel Vetter wrote:
You're still using atomic_t for no real good reason.
gen8_dispatch_bsd_ring is always called with the dev-struct_mutex lock
held, so there's really no reason for it.
If the
2014-04-09 12:08 GMT+02:00 Jörg Otte jrg.o...@gmail.com:
Kernel 3.14.0-12041-g75ff24f from 9.4.2014 introduces the following
on the console (driver is i915):
[drm:ivb_err_int_handler] *ERROR* Pipe B FIFO underrun
[drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun
On Mon, 2014-04-14 at 02:19 -0600, Chris Wilson wrote:
On Mon, Apr 14, 2014 at 04:05:19PM +0800, Zhao Yakui wrote:
On Mon, 2014-04-14 at 01:22 -0600, Daniel Vetter wrote:
You're still using atomic_t for no real good reason.
gen8_dispatch_bsd_ring is always called with the dev-struct_mutex
On Mon, Apr 14, 2014 at 01:24:43PM +0530, Kumar, Shobhit wrote:
On 4/14/2014 12:32 PM, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote:
The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.
v2: Address
On Mon, Mar 31, 2014 at 06:29:51PM +, Robert Navarro wrote:
Runyan, Arthur J arthur.j.runyan at intel.com writes:
Please check the DRAM configuration for the systems that fail. The higher
latency is more likely with
higher tRFC which is mainly found with 8 Gbit components.
From: Akash Goel akash.g...@intel.com
This workaround is needed on VLV for the HW context feature.
It is used after adding the mi_set_context command in ring buffer
for Hw context switch. As per the spec
The software must send a pipe_control with a CS stall and a post sync
operation and then a
On Fri, 2014-04-11 at 08:55 +, Daniel Vetter wrote:
On Thu, Apr 10, 2014 at 10:12:39AM +, Gupta, Sourab wrote:
On Wed, 2014-04-09 at 13:06 +, Daniel Vetter wrote:
On Tue, Apr 08, 2014 at 06:53:03AM +, Gupta, Sourab wrote:
On Tue, 2014-04-08 at 06:45 +, Chris Wilson
On 4/14/2014 2:35 PM, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 01:24:43PM +0530, Kumar, Shobhit wrote:
On 4/14/2014 12:32 PM, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 11:00:34AM +0530, Shobhit Kumar wrote:
The parser extracts the config block(#52) and sequence(#53) data
and store in
+ FILE *file;
+ int debug_fd;
+ char *line = NULL;
+ size_t line_size = 0;
+ char *dashes = NULL;
+ char *ring_name = NULL;
+ int bb_matched = 0;
+ uint32_t gtt_offset;
+ char expected_line[32];
+ int req_matched = 0;
+ int requests;
+ uint32_t
On Mon, Apr 14, 2014 at 10:01:12AM +, Mateo Lozano, Oscar wrote:
+ requests);
+ if (req_matched == 1) {
+ igt_assert(strstr(ring_name, expected_ring_name));
+ igt_assert(requests == 1);
Bad assumption. You could
On Tue, 2014-04-01 at 10:53 +0530, sourab gupta wrote:
On Tue, 2014-03-25 at 12:23 +0530, sourab gupta wrote:
On Mon, 2014-03-24 at 17:56 +, Lespiau, Damien wrote:
On Mon, Mar 24, 2014 at 11:00:07PM +0530, sourab.gu...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
+ requests);
+ if (req_matched == 1) {
+ igt_assert(strstr(ring_name,
expected_ring_name));
+ igt_assert(requests == 1);
Bad assumption. You could still have the request from
On Mon, Apr 14, 2014 at 10:23:20AM +, Mateo Lozano, Oscar wrote:
+ requests);
+ if (req_matched == 1) {
+ igt_assert(strstr(ring_name,
expected_ring_name));
+ igt_assert(requests == 1);
I would add a little more smarts to both the kernel and error-decode.
In the kernel, we can print the guilty request, which you can then use to
confirm that it is yours. That seems to me to be a stronger validation of
gem_error_capture, and a useful bit of information from hangstats that we do
Was using my machine normally, then my mouse cursor vanished. After switching
to a VT and back to X11, my cursor came back. But I did notice a nasty trace in
dmesg (below).
I have a few options specified on my command line related to i915, but these
worked fine through 3.13.9:
From: Deepak S deepa...@intel.com
Added patch to enable PM Interrupts
Ben Widawsky (1):
drm/i915/bdw: Implement a basic PM interrupt handler
Deepak S (1):
drm/i915: Enable PM Interrupts target via Display Interface.
drivers/gpu/drm/i915/i915_irq.c | 81
From: Ben Widawsky benjamin.widaw...@intel.com
Almost all of it is reusable from the existing code. The primary
difference is we need to do even less in the interrupt handler, since
interrupts are not shared in the same way.
The patch is mostly a copy-paste of the existing snb+ code, with
From: Deepak S deepa...@intel.com
In BDW, Apart from unmasking up/down threshold interrupts. we need
to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
Interface.
Signed-off-by: Deepak S deepa...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
For a description of this patchset see the previous cover letter [1].
Tested on HSW (non-ULT), VLV with igt/kms_flip and pm_pc8.
v2:
- addressed comments about getting the proper runtime PM references in
debugfs (Daniel, Paulo, Ville)
- disable RPM if RC6 is disabled for all platforms, not
These will be needed by the upcoming VLV RPM helpers.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_reg.h | 10 --
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1e83ae4..02f1b39 100644
---
The parsing was incorrect for ILK and VLV.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 75c1c76..4ebb93c 100644
There are igt tools that can read/write the DPIO registers, so having a
debugfs entry for only some of those registers is somewhat arbitrary /
redundant. Remove it.
v2:
- instead of fixing the entry by taking a power domain reference around
the register accesses, remove the entry (Ville)
While checking the error capture path I noticed that this register is
read twice for GEN2, so fix this and also move the read where it's done
for other platforms.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_gpu_error.c | 8
1 file changed, 4 insertions(+),
Getting struct_mutex around the whole intel_enable_gt_powersave()
function is not necessary, since it's only needed for the ILK path
therein.
This will make intel_enable_gt_powersave() useable on the RPM resume
path for =GEN6 (added in an upcoming patch to reset the RPS state
during RPM resume),
While checking the error capture path I noticed that we lacked the
power domain-on check for PIPESTAT so fix this by moving that to where
the rest of pipe registers are captured.
The move also revealed that we actually don't include this register in
the error report, so fix that too.
Atm, an invalid enable_rc6 module option will be silently ignored, so
emit an info message about it. Doing an early sanitization we can also
reuse intel_enable_rc6() in a follow-up patch to see if RC6 is actually
enabled. Currently the caller would have to filter a non-zero return
value based on
These debugfs entries access registers that need the D0 power state so
get an RPM ref for them.
v2:
- for all these entries we only need D0 state, so get only an RPM ref,
not a power domain ref (Daniel, Paulo)
- the dpio entry is not an issue any more as it got removed (Ville)
- restore commit
Some platforms need additional power domains to be on in addition to the
device D0 state to access the panel registers.
Suggested by Daniel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76987
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 6 +-
Atm we can end up in the GPU reset deferred work in D3 state if the last
runtime PM reference is dropped between detecting a hang/scheduling the
work and executing the work. At least one such case I could trigger is
the simulated reset via the i915_wedged debugfs entry. Fix this by
disabling RPM
Atm, we call intel_gt_powersave_enable() for GEN6 and GEN7 but disable
it for everything starting from GEN6. This is a problem in case of BDW.
Since I don't have a BDW to test if RC6 works properly, just keep it
disabled for now and fix only the disable function.
Signed-off-by: Imre Deak
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b87109c..1f88917 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++
Needed by the VLV S0ix context save/restore helpers.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 43 -
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
Atm, none of the RPM callbacks can fail, but the next patch adding
RPM support for VLV changes this, so prepare for it.
In case one of these callbacks return error RPM will get permanently
disabled until the error is explicitly cleared. In the future we could
add support for re-enabling it, for
When enabling runtime PM on VLV, GT power save enabling becomes relatively
frequent, so optimize it a bit.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 66 +
1 file changed, 41 insertions(+), 25 deletions(-)
diff
This is needed by the next patch moving the call out from platform
specific RPM callbacks to platform independent code.
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 2 --
Add runtime PM support for VLV, but leave it disabled. The next patch
enables it.
The suspend/resume sequence used is based on [1] and [2]. In practice we
depend on the GT RC6 mechanism to save the HW context depending on the
render and media power wells. By the time we run the runtime suspend
I've seen latencies up to 15msec, so increase the timeout to 20msec.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index
We need to disable the interrupts for all platforms, so make the helpers
for this platform independent and call them from them platform
independent runtime suspend/resume callbacks.
On HSW/BDW this will move interrupt disabling/re-enabling at the
beginning/end of runtime suspend/resume
On VLV we depend on RC6 to save the GT render and media HW context
before going to the D3 state via RPM, so as a preparation for the
VLV RPM support (added in an upcoming patch) disable RPM if RC6 is
disabled.
There is probably a similar dependency on other platforms too, so for
safety require
This will be needed by the VLV runtime PM helpers too, so factor it out.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 37 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 16 ++--
3
At least on VLV but probably on other platforms too we depend on RC6
being enabled for RPM, so disable RPM until the delayed RC6 enabling
completes.
v2:
- explain the reason for the _noresume version of RPM get (Daniel)
- use the simpler 'if (schedule_work()) rpm_get();' instead of
'if
We need to re-init sizzling on all platforms so move it to the
platform independent runtime resume callback. The ring frequency reinit
is also needed everywhere except on VLV, but gen6_update_ring_freq()
will be a noop on VLV, so we can move this function too to platform
independent code.
Depending on the SDVO output_flags SDVO may have multiple connectors.
These are all initialized in intel_sdvo_output_setup(). The connector
that is initialized later will override the encoder_type that has been
set up by an earlier connector type initialization. Eventually the
one that comes last
Currently the i915 driver can only handle well if only a single
SDVO output is flagged (ie output_flags has only one bit set).
If multiple outputs are flagged the side effects are only cosmetic
in most cases (ie. the encoder may have the wrong type set),
but there are situations (namely when
Depending on the SDVO output_flags SDVO may have multiple connectors
linking to the same encoder (in intel_connector-encoder-base).
Only one of those connectors should be active (ie link to the encoder
thru drm_connector-encoder.
If intel_connector_break_all_links() is called from
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[ I managed to leave out this last one, so sending it now on top of the
rest. ]
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
By mis-declaring this function, we ended up using software cursors
because the value seen by the caller was 0.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/sna/sna_display.c | 8 ++--
src/sna/sna_display_fake.c | 3 ++-
src/uxa/intel_display.c| 7 +--
3 files changed,
Steven Noonan ste...@uplinklabs.net writes:
Was using my machine normally, then my mouse cursor vanished. After switching
to a VT and back to X11, my cursor came back. But I did notice a nasty trace
in
dmesg (below).
I don't think the trace below is related to the cursor disappearing.
I
On Mon, Apr 14, 2014 at 11:22:03 -0700, Keith Packard wrote:
By mis-declaring this function, we ended up using software cursors
because the value seen by the caller was 0.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/sna/sna_display.c | 8 ++--
On Mon, Apr 14, 2014 at 11:35:05AM -0700, Keith Packard wrote:
Steven Noonan ste...@uplinklabs.net writes:
Was using my machine normally, then my mouse cursor vanished. After
switching
to a VT and back to X11, my cursor came back. But I did notice a nasty
trace in
dmesg (below).
Julien Cristau jcris...@debian.org writes:
Only since
http://cgit.freedesktop.org/xorg/xserver/commit/?id=901fbfbbbd71c0d82080957f8ba09eebbc786f2b
Which could probably have used a different name to avoid silent
breakage.
Yeah, that probably would have been a better change.
--
On Mon, Apr 14, 2014 at 10:41:15PM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
In BDW, Apart from unmasking up/down threshold interrupts. we need
to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
Interface.
Signed-off-by: Deepak S
Steven Noonan ste...@uplinklabs.net writes:
OK, good to know. Thanks for pointing those out!
As Julien points out, this bug only affects people running master from
the X server though...
--
keith.pack...@intel.com
pgpHmhnPO7B4K.pgp
Description: PGP signature
On Mon, Apr 14, 2014 at 10:41:14PM +0530, deepa...@intel.com wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
Almost all of it is reusable from the existing code. The primary
difference is we need to do even less in the interrupt handler, since
interrupts are not shared in the same way.
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the CPU-GPU sync for the second BSD ring.
V1-V2: Follow Daniel's comment to add one subtext instead of one individual
test case, which is used
This follows Daniel's advice to add the two test cases based on multi drm_fd to
test the ring sync and CPU-GPU sync.
The Broadwell GT3 machine has two independent BSD rings that can be used
to process the video commands. This is implemented in kernel driver and
transparent
to the user-space. But
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the ring sync between the two BSD rings. At the same time it also needs to
check the sync among the second BSD ring and the other rings.
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_gem_context.c between commit 691e6415c891
(drm/i915: Always use kref tracking for all contexts) from the
drm-intel-fixes tree and commit ad2ac08bf34b (drm/i915: Make contexts
non-snooped on non-LLC
73 matches
Mail list logo
