Re: [Intel-gfx] i915 DVI resolution regression (3.13.7+)

On 9 April 2014 15:08, Jani Nikula wrote: > On Wed, 09 Apr 2014, Dave Airlie wrote: >> On Wed, Apr 9, 2014 at 4:07 PM, Daniel J Blueman wrote: >>> On 9 April 2014 11:41, Dave Airlie wrote: On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman wrote: > On 8 April 2014 15:14, Jani Nikula wr

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the tree

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-LL

[Intel-gfx] [PATCH I-g-t V2 1/2] tests: Add one ring sync case based on multi drm_fd to test ring semaphore sync under multi BSD rings

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. Signed-

[Intel-gfx] [PATCH I-g-t V2 2/2] tests/gem_dummy_reloc_loop: Add one subtest based on multi drm_fd to test CPU<->GPU sync under multi BSD rings

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 use

[Intel-gfx] [PATCH I-g-t V2 0/2] Tests: Add test cases based on multi drm_fd to test sync

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. Bu

Re: [Intel-gfx] [PATCH 1/2] drm/i915/bdw: Implement a basic PM interrupt handler

On Mon, Apr 14, 2014 at 10:41:14PM +0530, deepa...@intel.com wrote: > From: Ben Widawsky > > 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 most

Re: [Intel-gfx] REGRESSION 3.14 i915 warning & mouse cursor vanishing

Steven Noonan 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 ___ Intel

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable PM Interrupts target via Display Interface.

On Mon, Apr 14, 2014 at 10:41:15PM +0530, deepa...@intel.com wrote: > From: Deepak S > > 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 > --- > drivers/gpu/dr

Re: [Intel-gfx] [PATCH] load_cursor_argb is supposed to return a Bool, not void

Julien Cristau 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. -- keith.pack...@intel.com p

Re: [Intel-gfx] REGRESSION 3.14 i915 warning & mouse cursor vanishing

On Mon, Apr 14, 2014 at 11:35:05AM -0700, Keith Packard wrote: > Steven Noonan 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

Re: [Intel-gfx] [PATCH] load_cursor_argb is supposed to return a Bool, not void

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 > --- > src/sna/sna_display.c | 8 ++-- > src/sna/sna_display_fake.c | 3 ++-

Re: [Intel-gfx] REGRESSION 3.14 i915 warning & mouse cursor vanishing

Steven Noonan 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 found a pair of bugs

[Intel-gfx] [PATCH] load_cursor_argb is supposed to return a Bool, not void

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 --- src/sna/sna_display.c | 8 ++-- src/sna/sna_display_fake.c | 3 ++- src/uxa/intel_display.c| 7 +-- 3 files changed, 13 insertions(+),

[Intel-gfx] [PATCH v2 26/25] drm/i915: vlv: enable runtime PM

Signed-off-by: Imre Deak --- 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 index 77cb7fc..3a98

[Intel-gfx] [PATCH 1/2] drm/i915: Only break encoder linked when linked to connector

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 intel_sanitize

[Intel-gfx] [PATCH 0/2] Fix if multiple SDVO outputs are flagged

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 intel_

[Intel-gfx] [PATCH 2/2] drm/i915: Set up SDVO encoder type only at detect

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 w

[Intel-gfx] [PATCH v2 08/25] drm/i915: get a runtime PM ref for the deferred GT powersave enabling

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 (!cancel_

[Intel-gfx] [PATCH v2 15/25] drm/i915: disable runtime PM if RC6 is disabled

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 RC6

[Intel-gfx] [PATCH v2 21/25] drm/i915: vlv: factor out vlv_force_gfx_clock

This will be needed by the VLV runtime PM helpers too, so factor it out. Signed-off-by: Imre Deak --- 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 files changed, 40 ins

[Intel-gfx] [PATCH v2 16/25] drm/i915: make runtime PM interrupt enable/disable platform independent

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 respectivel

[Intel-gfx] [PATCH v2 17/25] drm/i915: factor out gen6_update_ring_freq

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 --- drivers/gpu/drm/i915/i915_drv.c | 2 -- drivers/gpu/drm/i915/intel_display.c | 2 -- drivers/gpu/drm/i915/intel_pm.c

[Intel-gfx] [PATCH v2 25/25] drm/i915: vlv: add runtime PM support

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 cal

[Intel-gfx] [PATCH v2 22/25] drm/i915: vlv: increase timeout when forcing on the GFX clock

I've seen latencies up to 15msec, so increase the timeout to 20msec. Signed-off-by: Imre Deak --- 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 0609f77..845e1e1 10064

[Intel-gfx] [PATCH v2 18/25] drm/i915: make runtime PM swizzling/ring_freq init platform independent

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. Signed-o

[Intel-gfx] [PATCH v2 24/25] drm/i915: propagate the error code from runtime PM callbacks

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 ex

[Intel-gfx] [PATCH v2 20/25] drm/i915: vlv: setup RPS min/max frequencies once during init time

When enabling runtime PM on VLV, GT power save enabling becomes relatively frequent, so optimize it a bit. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_pm.c | 66 + 1 file changed, 41 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/

[Intel-gfx] [PATCH v2 23/25] drm/i915: add various missing GTI/Gunit register definitions

Needed by the VLV S0ix context save/restore helpers. Signed-off-by: Imre Deak --- 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 b/drivers/gpu/drm/i915/i915_reg.h index

[Intel-gfx] [PATCH v2 19/25] drm/i915: reinit GT power save during resume

Signed-off-by: Imre Deak --- 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 +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -920,6

[Intel-gfx] [PATCH v2 09/25] drm/i915: get a runtime PM ref for the deferred GPU reset work

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 be

[Intel-gfx] [PATCH v2 12/25] drm/i915: vlv: check port power domain instead of only D0 for eDP VDD on

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 --- drivers/gpu/drm/i915/intel_dp.c | 6 +- 1 file changed, 5 in

[Intel-gfx] [PATCH v2 14/25] drm/i915: sanitize enable_rc6 option

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 th

[Intel-gfx] [PATCH v2 06/25] drm/i915: get a runtime PM ref for debugfs entries where needed

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 m

[Intel-gfx] [PATCH v2 13/25] drm/i915: fix unbalanced GT powersave enable / disable calls

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 --- dri

[Intel-gfx] [PATCH v2 10/25] drm/i915: gen2: move error capture of IER to its correct place

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 --- drivers/gpu/drm/i915/i915_gpu_error.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) dif

[Intel-gfx] [PATCH v2 11/25] drm/i915: add missing error capturing of the PIPESTAT reg

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. Signed-off-b

[Intel-gfx] [PATCH v2 05/25] drm/i915: remove the i915_dpio debugfs entry

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) Signed

[Intel-gfx] [PATCH v2 07/25] drm/i915: move getting struct_mutex lower in the callstack during GPU reset

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),

[Intel-gfx] [PATCH v2 03/25] drm/i915: vlv: add RC6 residency counters

Signed-off-by: Imre Deak --- 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 --- a/drivers/gpu/drm/i9

[Intel-gfx] [PATCH v2 04/25] drm/i915: fix the RC6 status debug print

The parsing was incorrect for ILK and VLV. Signed-off-by: Imre Deak --- 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 --- a/drivers/gpu/drm

[Intel-gfx] [PATCH v2 01/25] drm/i915: vlv: clean up GTLC wake control/status register macros

These will be needed by the upcoming VLV RPM helpers. Signed-off-by: Imre Deak --- 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 b/drivers/gpu/drm/i915/i

[Intel-gfx] [PATCH v2 02/25] drm/i915: vlv: clear master interrupt flag when disabling interrupts

Not clearing this flag causes spurious interrupts at least in D3 state, so before enabling RPM we need to fix this. We were already setting this flag when enabling interrupts, only clearing it was missing. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_irq.c | 2 ++ 1 file changed, 2 ins

[Intel-gfx] [PATCH v2 00/25] vlv: add support for RPM

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 just

[Intel-gfx] [PATCH 1/2] drm/i915/bdw: Implement a basic PM interrupt handler

From: Ben Widawsky 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 updates to the relevant parts requ

[Intel-gfx] [PATCH 2/2] drm/i915: Enable PM Interrupts target via Display Interface.

From: Deepak S 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 --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 2 ++ 2 files changed, 3 in

[Intel-gfx] [PATCH 0/2] Enable PM Interrupts for BDW

From: Deepak S 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 +--- drivers/gpu

[Intel-gfx] REGRESSION 3.14 i915 warning & mouse cursor vanishing

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: i915.lvds_downc

Re: [Intel-gfx] [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump

> 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

Re: [Intel-gfx] [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump

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_

Re: [Intel-gfx] [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump

> > > > + &requests); > > > > + if (req_matched == 1) { > > > > + igt_assert(strstr(ring_name, > > > > expected_ring_name)); > > > > + igt_assert(requests == 1); > > > > > > Bad assumption. You could still have

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/vlv: Modifying WA 'WaDisableL3Bank2xClockGate for vlv

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 > > > > > > > > For

Re: [Intel-gfx] [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump

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 assumpt

Re: [Intel-gfx] [PATCH v2] tests/gem_error_capture: Initial testcase for error state capture/dump

> > + 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;

Re: [Intel-gfx] [PATCH v3] drm/i915: Add parsing support for new MIPI blocks in VBT

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 pr

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Add support for stealing purgable stolen pages

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

[Intel-gfx] [PATCH v5 2/6] drm/i915/vlv: Added a rendering specific Hw WA 'WaSendDummy3dPrimitveAfterSetContext'

From: Akash Goel 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 dummy DRAW after every

Re: [Intel-gfx] [PATCH] drm/i915: Increase WM memory latency values on SNB with high pixel clock

On Mon, Mar 31, 2014 at 06:29:51PM +, Robert Navarro wrote: > Runyan, Arthur J 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. > > > > What o

Re: [Intel-gfx] [PATCH v3] drm/i915: Add parsing support for new MIPI blocks in VBT

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:

Re: [Intel-gfx] [PATCH V2 6/6] drm/i915:Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3

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->str

Re: [Intel-gfx] [ 3.14.0-12041-g75ff24f ] regression: drm warning

2014-04-09 12:08 GMT+02:00 Jörg Otte : > 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 > [drm:cpt_serr_int_handler]

Re: [Intel-gfx] [PATCH V2 6/6] drm/i915:Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3

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. >

Re: [Intel-gfx] Power saving using Display port HPD

On Mon, 2014-04-14 at 09:47 +0200, Daniel Vetter wrote: > On Mon, Apr 14, 2014 at 9:43 AM, Arun Chandran wrote: > > 1) Revert the commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1. > > With this commit DP hotplug events are not coming after doing "xset dpms > > force off" > > > > commit bfcbf45b5b4

Re: [Intel-gfx] [PATCH I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU<->GPU sync under multi BSD rings

On Mon, 2014-04-14 at 01:55 -0600, Daniel Vetter wrote: > On Mon, Apr 14, 2014 at 9:32 AM, Zhao Yakui 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.

Re: [Intel-gfx] [PATCH V2 6/6] drm/i915:Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3

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 wi

Re: [Intel-gfx] [PATCH I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU<->GPU sync under multi BSD rings

On Mon, Apr 14, 2014 at 9:32 AM, Zhao Yakui 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 to apply the corr

Re: [Intel-gfx] [PATCH v3] drm/i915: Add parsing support for new MIPI blocks in VBT

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

Re: [Intel-gfx] [PATCH I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU<->GPU sync under multi BSD rings

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<->

Re: [Intel-gfx] Power saving using Display port HPD

On Mon, Apr 14, 2014 at 9:43 AM, Arun Chandran 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 > Date: Fri

Re: [Intel-gfx] Power saving using Display port HPD

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 bfcbf45b5b458ebdc38118ca6727

Re: [Intel-gfx] [PATCH I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU<->GPU sync under multi BSD rings

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<->

Re: [Intel-gfx] [PATCH V2 6/6] drm/i915:Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3

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

Re: [Intel-gfx] [PATCH V2 1/6] drm/i915: Split the BDW device definition to prepare for dual BSD rings on BDW GT3

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 > co

Re: [Intel-gfx] [PATCH V2 1/6] drm/i915: Split the BDW device definition to prepare for dual BSD rings on BDW GT3

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

Re: [Intel-gfx] [PATCH I-g-t 2/2] tests: Add dummy_reloc test case based on multi drm_fd to test CPU<->GPU sync under multi BSD rings

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 >

Re: [Intel-gfx] [PATCH v3] drm/i915: Add parsing support for new MIPI blocks in VBT

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 an