[Intel-gfx] Building GVT-g as a sub-module of i915
Hi Guys: I'm trying to make GVT-g as a sub-module of i915 in the next version patchset. The basic idea is to introduce a "gvt-g pre-enabled state" in i915. I think it should be a kernel option. When this kernel option is enabled by user, i915 will do GGTT partition and save HW initial MMIO snapshot for gvt-g module during loading. When GVT-g modules is loaded, first it should check if the "gvt-g pre-eanbled state" is enabled in i915. If yes, then it will use the snapshot in i915 and continue to load. If no, then bail out. Thanks, Zhi. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] vga_switcheroo: Add helper for deferred probing
On Sat, May 21, 2016 at 03:59:16PM +0100, Lukas Wunner wrote:
> So far we've got one condition when DRM drivers need to defer probing
> on a dual GPU system and it's coded separately into each of the relevant
> drivers. As suggested by Daniel Vetter, deduplicate that code in the
> drivers and move it to a new vga_switcheroo helper. This yields better
> encapsulation of concepts and lets us add further checks in a central
> place. (The existing check pertains to pre-retina MacBook Pros and an
> additional check is expected to be needed for retinas.)
>
> v2: This helper could eventually be used by audio clients as well,
> so rephrase kerneldoc to refer to "client" instead of "GPU"
> and move the single existing check in an if block specific
> to PCI_CLASS_DISPLAY_VGA devices. Move documentation on
> that check from kerneldoc to a comment. (Daniel Vetter)
>
> v3: Mandate in kerneldoc that registration of client shall only
> happen after calling this helper. (Daniel Vetter)
>
> v4: Rebase on 412c8f7de011 ("drm/radeon: Return -EPROBE_DEFER when
> amdkfd not loaded")
>
> v5: Some Optimus GPUs use PCI_CLASS_DISPLAY_3D, make sure those are
> matched as well. (Emil Velikov)
>
> Cc: Daniel Vetter
> Cc: Ben Skeggs
> Cc: Alex Deucher
> Signed-off-by: Lukas Wunner
> ---
> drivers/gpu/drm/i915/i915_drv.c | 10 +-
> drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +-
> drivers/gpu/drm/radeon/radeon_drv.c | 10 +-
> drivers/gpu/vga/vga_switcheroo.c | 34 --
> include/linux/vga_switcheroo.h| 2 ++
> 5 files changed, 37 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index d37c0a6..20d5898 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -35,11 +35,9 @@
> #include "i915_trace.h"
> #include "intel_drv.h"
>
> -#include
> #include
> #include
> #include
> -#include
> #include
> #include
>
> @@ -1025,13 +1023,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> if (PCI_FUNC(pdev->devfn))
> return -ENODEV;
>
> - /*
> - * apple-gmux is needed on dual GPU MacBook Pro
> - * to probe the panel if we're the inactive GPU.
> - */
> - if (IS_ENABLED(CONFIG_VGA_ARB) && IS_ENABLED(CONFIG_VGA_SWITCHEROO) &&
> - apple_gmux_present() && pdev != vga_default_device() &&
> - !vga_switcheroo_handler_flags())
> + if (vga_switcheroo_client_probe_defer(pdev))
> return -EPROBE_DEFER;
>
> return drm_get_pci_dev(pdev, ent, &driver);
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 11f8dd9..5c4d4df 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -22,13 +22,11 @@
> * Authors: Ben Skeggs
> */
>
> -#include
> #include
> #include
> #include
> #include
> #include
> -#include
> #include
>
> #include "drmP.h"
> @@ -315,13 +313,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> bool boot = false;
> int ret;
>
> - /*
> - * apple-gmux is needed on dual GPU MacBook Pro
> - * to probe the panel if we're the inactive GPU.
> - */
> - if (IS_ENABLED(CONFIG_VGA_ARB) && IS_ENABLED(CONFIG_VGA_SWITCHEROO) &&
> - apple_gmux_present() && pdev != vga_default_device() &&
> - !vga_switcheroo_handler_flags())
> + if (vga_switcheroo_client_probe_defer(pdev))
> return -EPROBE_DEFER;
>
> /* remove conflicting drivers (vesafb, efifb etc) */
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index b55aa74..a455dc7 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -34,11 +34,9 @@
> #include "radeon_drv.h"
>
> #include
> -#include
> #include
> #include
> #include
> -#include
> #include
> #include
>
> @@ -340,13 +338,7 @@ static int radeon_pci_probe(struct pci_dev *pdev,
> if (ret == -EPROBE_DEFER)
> return ret;
>
> - /*
> - * apple-gmux is needed on dual GPU MacBook Pro
> - * to probe the panel if we're the inactive GPU.
> - */
> - if (IS_ENABLED(CONFIG_VGA_ARB) && IS_ENABLED(CONFIG_VGA_SWITCHEROO) &&
> - apple_gmux_present() && pdev != vga_default_device() &&
> - !vga_switcheroo_handler_flags())
> + if (vga_switcheroo_client_probe_defer(pdev))
> return -EPROBE_DEFER;
>
> /* Get rid of things like offb */
> diff --git a/drivers/gpu/vga/vga_switcheroo.c
> b/drivers/gpu/vga/vga_switcheroo.c
> index cbd7c98..2df216b3 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -30,6 +30,7 @@
>
> #define pr_fmt(fmt) "vga_switcheroo: " fmt
>
> +#include
> #include
> #include
>
Re: [Intel-gfx] [PATCH v5] vga_switcheroo: Add helper for deferred probing
On Mon, 23 May 2016, Daniel Vetter wrote:
> On Sat, May 21, 2016 at 03:59:16PM +0100, Lukas Wunner wrote:
>> So far we've got one condition when DRM drivers need to defer probing
>> on a dual GPU system and it's coded separately into each of the relevant
>> drivers. As suggested by Daniel Vetter, deduplicate that code in the
>> drivers and move it to a new vga_switcheroo helper. This yields better
>> encapsulation of concepts and lets us add further checks in a central
>> place. (The existing check pertains to pre-retina MacBook Pros and an
>> additional check is expected to be needed for retinas.)
>>
>> v2: This helper could eventually be used by audio clients as well,
>> so rephrase kerneldoc to refer to "client" instead of "GPU"
>> and move the single existing check in an if block specific
>> to PCI_CLASS_DISPLAY_VGA devices. Move documentation on
>> that check from kerneldoc to a comment. (Daniel Vetter)
>>
>> v3: Mandate in kerneldoc that registration of client shall only
>> happen after calling this helper. (Daniel Vetter)
>>
>> v4: Rebase on 412c8f7de011 ("drm/radeon: Return -EPROBE_DEFER when
>> amdkfd not loaded")
>>
>> v5: Some Optimus GPUs use PCI_CLASS_DISPLAY_3D, make sure those are
>> matched as well. (Emil Velikov)
>>
>> Cc: Daniel Vetter
>> Cc: Ben Skeggs
>> Cc: Alex Deucher
>> Signed-off-by: Lukas Wunner
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 10 +-
>> drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +-
>> drivers/gpu/drm/radeon/radeon_drv.c | 10 +-
>> drivers/gpu/vga/vga_switcheroo.c | 34
>> --
>> include/linux/vga_switcheroo.h| 2 ++
>> 5 files changed, 37 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index d37c0a6..20d5898 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -35,11 +35,9 @@
>> #include "i915_trace.h"
>> #include "intel_drv.h"
>>
>> -#include
>> #include
>> #include
>> #include
>> -#include
>> #include
>> #include
>>
>> @@ -1025,13 +1023,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
>> struct pci_device_id *ent)
>> if (PCI_FUNC(pdev->devfn))
>> return -ENODEV;
>>
>> -/*
>> - * apple-gmux is needed on dual GPU MacBook Pro
>> - * to probe the panel if we're the inactive GPU.
>> - */
>> -if (IS_ENABLED(CONFIG_VGA_ARB) && IS_ENABLED(CONFIG_VGA_SWITCHEROO) &&
>> -apple_gmux_present() && pdev != vga_default_device() &&
>> -!vga_switcheroo_handler_flags())
>> +if (vga_switcheroo_client_probe_defer(pdev))
>> return -EPROBE_DEFER;
>>
>> return drm_get_pci_dev(pdev, ent, &driver);
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> index 11f8dd9..5c4d4df 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> @@ -22,13 +22,11 @@
>> * Authors: Ben Skeggs
>> */
>>
>> -#include
>> #include
>> #include
>> #include
>> #include
>> #include
>> -#include
>> #include
>>
>> #include "drmP.h"
>> @@ -315,13 +313,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
>> bool boot = false;
>> int ret;
>>
>> -/*
>> - * apple-gmux is needed on dual GPU MacBook Pro
>> - * to probe the panel if we're the inactive GPU.
>> - */
>> -if (IS_ENABLED(CONFIG_VGA_ARB) && IS_ENABLED(CONFIG_VGA_SWITCHEROO) &&
>> -apple_gmux_present() && pdev != vga_default_device() &&
>> -!vga_switcheroo_handler_flags())
>> +if (vga_switcheroo_client_probe_defer(pdev))
>> return -EPROBE_DEFER;
>>
>> /* remove conflicting drivers (vesafb, efifb etc) */
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index b55aa74..a455dc7 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -34,11 +34,9 @@
>> #include "radeon_drv.h"
>>
>> #include
>> -#include
>> #include
>> #include
>> #include
>> -#include
>> #include
>> #include
>>
>> @@ -340,13 +338,7 @@ static int radeon_pci_probe(struct pci_dev *pdev,
>> if (ret == -EPROBE_DEFER)
>> return ret;
>>
>> -/*
>> - * apple-gmux is needed on dual GPU MacBook Pro
>> - * to probe the panel if we're the inactive GPU.
>> - */
>> -if (IS_ENABLED(CONFIG_VGA_ARB) && IS_ENABLED(CONFIG_VGA_SWITCHEROO) &&
>> -apple_gmux_present() && pdev != vga_default_device() &&
>> -!vga_switcheroo_handler_flags())
>> +if (vga_switcheroo_client_probe_defer(pdev))
>> return -EPROBE_DEFER;
>>
>> /* Get rid of things like offb */
>> diff --git a/drivers/gpu/vga/vga_switcheroo.c
>> b/drivers/gpu/vga/vga_switcheroo.c
>> index cbd7c98..2df216b3 100644
>> --- a/drivers/gpu/vga/vga_switcheroo.c
>
Re: [Intel-gfx] *ERROR* Hangcheck timer elapsed... render ring idle
On Fri, 20 May 2016, Chris wrote: > I'm still seeing this periodically, previous to today it happened on > April 24th. Doesn't matter what I'm doing the video will freeze however > the cursor will still move. Only option is to SSH in to the system from > my tablet and do a reboot. > > Note: This has been going on since Sept 13, 2014. There could be as > little as a few hours between freezes or as much as 30 or more days. Your report is lacking in details... like which kernel you're running, and have you tried a recent kernel. Please file a bug at [1], and attach dmesg with drm.debug=14 on the bug. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Disable the Link training automation support
On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> Kernel does not have automation support for DP compliance Link
> training tests. So the Link Training test handler should return
> a TEST_NAK.
Is this test activated by short or long pulse? The commit message of commit
09b1eb130e43 ("drm/i915: Move Displayport test request and sink IRQ logic to
intel_dp_detect()") suggests the latter. In that case, the order of this and
patch 1 should be inverted.
Otherwise, for patches 1 and 2:
Reviewed-by: Ander Conselvan de Oliveira
>
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 19a95ed..0961f22 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4011,7 +4011,7 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8
> *sink_irq_vector)
>
> static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
> {
> - uint8_t test_result = DP_TEST_ACK;
> + uint8_t test_result = DP_TEST_NAK;
> return test_result;
> }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Fixes to support the DP Compliance EDID tests.
On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> This patch addresses a few issues from the original patch for
> DP Compliance EDID test support submitted by
> Todd Previte
Do you mean commit 559be30cb74d ("drm/i915: Implement the intel_dp_autotest_edid
function for DP EDID complaince tests")? Please see the link below on how to
refer to other commits in the commit message and how to add a Fixes: tag.
https://www.kernel.org/doc/Documentation/SubmittingPatches
>
> Video Mode requested in the EDID test handler for the EDID Read
> test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
> Intel connector status should be connected even if detect_edid is
> NULL when compliance_test flag is set. This is required to handle
> the corrupt EDID (CTS 4.2.2.6) or EDID Read Failure I2C NACK/I2C
> DEFER (CTS 4.2.2.4 and 4.2.2.5) tests from CTS spec.
What exactly do those tests test? It sounds like this patch adds a separate code
path to implement the right behavior only when running the CTS. Shouldn't the
driver handle those failures during normal operation in the same way?
>
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_dp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 0961f22..456fc17 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4023,7 +4023,7 @@ static uint8_t intel_dp_autotest_video_pattern(struct
> intel_dp *intel_dp)
>
> static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
> {
> - uint8_t test_result = DP_TEST_NAK;
> + uint8_t test_result = DP_TEST_ACK;
> struct intel_connector *intel_connector = intel_dp-
> >attached_connector;
> struct drm_connector *connector = &intel_connector->base;
>
> @@ -4058,7 +4058,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp
> *intel_dp)
> DRM_DEBUG_KMS("Failed to write EDID checksum\n");
>
> test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
> - intel_dp->compliance_test_data =
> INTEL_DP_RESOLUTION_STANDARD;
> + intel_dp->compliance_test_data =
> INTEL_DP_RESOLUTION_PREFERRED;
Is this used for anything else than logging?
> }
>
> /* Set test active flag here so userspace doesn't interrupt things */
> @@ -4650,7 +4650,7 @@ intel_dp_detect(struct drm_connector *connector, bool
> force)
>
> intel_dp->detect_done = false;
>
> - if (intel_connector->detect_edid)
> + if (intel_connector->detect_edid || intel_dp->compliance_test_active)
Should this check connector->edid_corrupt instead? I guess that would require
some logic to fallback to fail safe mode and bpc too.
I think Shubhangi had a patch for this same problem, but it also seems to create
a separate path for compliance.
Ander
> return connector_status_connected;
> else
> return connector_status_disconnected;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] Add support for forcing 6 bpc on DP pipes.
On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> From: Jim Bride
>
> For DP compliance we need to be able to control the output color
> type for the pipe associated with the DP port. To do this we rely
> on the intel_dp_test_force_bpc debugfs file and the associated value
> stored in struct intel_dp. If the debugfs file has a non-zero value
> and we're on a display port connector, then we use the value from
> debugfs to calculate the bpp for the pipe. For cases where we are
> not on DP or there has not been an overridden value then we behave
> as normal.
>
> Signed-off-by: Jim Bride
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_display.c | 32 ++--
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5ffccf6..1618d36 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12102,11 +12102,39 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
>
> /* Clamp display bpp to EDID value */
> for_each_connector_in_state(state, connector, connector_state, i) {
> + int type = 0;
> +
> + if (connector_state->best_encoder) {
> + struct intel_encoder *ienc;
> +
> + ienc = to_intel_encoder(connector_state-
> >best_encoder);
> + type = ienc->type;
> + }
> +
> if (connector_state->crtc != &crtc->base)
> continue;
>
> - connected_sink_compute_bpp(to_intel_connector(connector),
> - pipe_config);
> + /* For DP compliance we need to ensure that we can override
> + * the computed bpp for the pipe.
> + */
> + if (type == INTEL_OUTPUT_DISPLAYPORT) {
> + struct intel_dp *intel_dp =
> + enc_to_intel_dp(connector_state-
> >best_encoder);
> +
> + if (intel_dp &&
> + (intel_dp->compliance_force_bpc != 0)) {
> + pipe_config->pipe_bpp =
> + intel_dp->compliance_force_bpc*3;
> + DRM_DEBUG_KMS("JMB Setting pipe_bpp to %d\n",
> + pipe_config->pipe_bpp);
> + } else {
> + connected_sink_compute_bpp(to_intel_connector
> (connector),
> + pipe_config);
This kind of thing should be done in the encoder compute_config hook.
> + }
> + } else {
> + connected_sink_compute_bpp(to_intel_connector(connect
> or),
> + pipe_config);
> + }
> }
>
> return bpp;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e23eed7..10eaff8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -865,6 +865,7 @@ struct intel_dp {
> unsigned long compliance_test_type;
> unsigned long compliance_test_data;
> bool compliance_test_active;
> + unsigned long compliance_force_bpc; /* 0 for default or bpc to use */
There's no code for setting compliance_test_active anywhere. The commit message
mentions debugfs, but I didn't see anything related in the patch.
Ander
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Nouveau] [PATCH v4] vga_switcheroo: Add helper for deferred probing
On 21 May 2016 at 15:08, Lukas Wunner wrote:
> Hi Emil,
>
> On Fri, May 20, 2016 at 12:41:04AM +0100, Emil Velikov wrote:
>> On 19 May 2016 at 15:39, Lukas Wunner wrote:
>> > +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev)
>> > +{
>> > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
>> Not sure if we want/need this, yet at least. This changes behaviour
>> which is not what refactoring patches should be doing, right ? if
>> needed it ought to be a separate patch, imho.
>
> Well, the commit message doesn't claim "no functional change", does it?
>
It does implicitly via "vga_switcheroo: Add helper for deferred
probing". If you look through the kernel (and other projects) you'll
notice that very few patches have these three magic words. Even when
they don't have any functional changes.
> Daniel Vetter explicitly wanted the ability to use the helper in
> vga_switcheroo audio clients, and those shouldn't run the apple-gmux
> test. I think it makes sense to enclose it in the above-quoted if-block
> *now* even though it's not needed. Once someone adds a check for an
> audio client, chances are they'll forget to add this if-block.
>
Absolutely no arguments against any of that. Having a helper makes
sense even without any of the above arguments - it's a 'nasty looking'
if statement, duplicated multiple times. Speaking of which ...
shouldn't there be a similar hunk for amdgpu ?
Then again throwing everything into one patch does _not_ make sense.
Don't know why people would insist on having re-factoring and
functionality change as a single commit. Esp. in a place where hw
combinations, and thus chances of things going wrong, are pretty high.
>> Furthermore on nouveau and AMD (iirc) front, some dual-gpu/optimus
>> systems use PCI_CLASS_DISPLAY_3D. So if we add DISPLAY_VGA perhaps we
>> should also check for DISPLAY_3D ?
>
> Fair enough, I've changed it to match PCI_BASE_CLASS_DISPLAY
> and sent it out as v5 a few minutes ago.
>
Tweaking the exact class id (bitfield) is likely to end up drawn out
and obnoxious. That's why I'm suggesting to keep it separate.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix NULL pointer deference when out of PLLs in IVB
On Fri, 20 May 2016, Ander Conselvan de Oliveira
wrote:
> In commit f9476a6c6d0c ("drm/i915: Refactor platform specifics out of
> intel_get_shared_dpll()"), the ibx_get_dpll() function lacked an error
> check, that can lead to a NULL pointer dereference when trying to enable
> pipe C.
>
> BUG: unable to handle kernel NULL pointer dereference at 0068
> IP: [] intel_reference_shared_dpll+0x15/0x100 [i915]
> PGD cec87067 PUD d30ce067 PMD 0
> Oops: [#1] PREEMPT SMP
> Modules linked in: snd_hda_intel i915 drm_kms_helper drm intel_gtt
> sch_fq_codel cfg80211 binfmt_misc i2c_algo_bit cfbfillrect syscopyarea
> cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea intel_rapl iosf_mbi
> x86_pkg_temp_thermal coretemp agpgart kvm_intel snd_hda_codec_hdmi kvm
> iTCO_wdt snd_hda_codec_realtek snd_hda_codec_generic irqbypass aesni_intel
> aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse pcspkr
> snd_hda_codec i2c_i801 snd_hwdep snd_hda_core snd_pcm snd_timer lpc_ich
> mfd_core snd soundcore wmi evdev tpm_tis tpm [last unloaded: drm]
> CPU: 3 PID: 5810 Comm: kms_flip Tainted: G U W 4.6.0-test+ #3
> Hardware name: /DZ77BH-55K, BIOS
> BHZ7710H.86A.0100.2013.0517.0942 05/17/2013
> task: 8800d3908040 ti: 8801166c8000 task.ti: 8801166c8000
> RIP: 0010:[] []
> intel_reference_shared_dpll+0x15/0x100 [i915]
> RSP: 0018:8801166cba60 EFLAGS: 00010246
> RAX: RBX: RCX: 0002
> RDX: 0001 RSI: 8800d07f1bf8 RDI:
> RBP: 8801166cba88 R08: 0002 R09: 8800d32e5698
> R10: 0001 R11: 8800cc89ac88 R12: 8800d07f1bf8
> R13: R14: R15:
> FS: 7f4c3fc8d8c0() GS:88011bcc() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 0068 CR3: d3b4c000 CR4: 001406e0
> Stack:
> 8800d07f1bf8 8800d04c
> 8801166cbaa8 a04823a7 8800d07f1bf8
> 8800d32e5698 8801166cbab8 a04840cf 8801166cbaf0
> Call Trace:
> [] ibx_get_dpll+0x47/0xa0 [i915]
> [] intel_get_shared_dpll+0x1f/0x50 [i915]
> [] ironlake_crtc_compute_clock+0x280/0x430 [i915]
> [] intel_crtc_atomic_check+0x240/0x320 [i915]
> [] drm_atomic_helper_check_planes+0x14e/0x1d0
> [drm_kms_helper]
> [] intel_atomic_check+0x5dc/0x1110 [i915]
> [] drm_atomic_check_only+0x14a/0x660 [drm]
> [] ? drm_atomic_set_crtc_for_connector+0x96/0x100 [drm]
> [] drm_atomic_commit+0x17/0x60 [drm]
> [] restore_fbdev_mode+0x237/0x260 [drm_kms_helper]
> [] ? drm_modeset_lock_all_ctx+0x9a/0xb0 [drm]
> [] drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80
> [drm_kms_helper]
> [] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
> [] drm_fb_helper_hotplug_event+0xaa/0xf0 [drm_kms_helper]
> [] drm_fb_helper_restore_fbdev_mode_unlocked+0x56/0x80
> [drm_kms_helper]
> [] intel_fbdev_restore_mode+0x22/0x80 [i915]
> [] i915_driver_lastclose+0xe/0x20 [i915]
> [] drm_lastclose+0x2e/0x130 [drm]
> [] drm_release+0x2ac/0x4b0 [drm]
> [] __fput+0xed/0x1f0
> [] fput+0xe/0x10
> [] task_work_run+0x76/0xb0
> [] do_exit+0x3ab/0xc60
> [] ? trace_hardirqs_on_caller+0x12f/0x1c0
> [] do_group_exit+0x4e/0xc0
> [] SyS_exit_group+0x14/0x20
> [] entry_SYSCALL_64_fastpath+0x18/0xa8
> Code: 14 80 48 8d 34 90 b8 01 00 00 00 d3 e0 09 04 b3 5b 41 5c 5d c3 90 0f 1f
> 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 55 41 54 53 <44> 8b 67 68 48 89
> f3 48 8b be 08 02 00 00 4c 8b 2e e8 15 9d fd
> RIP [] intel_reference_shared_dpll+0x15/0x100 [i915]
> RSP
> CR2: 0068
>
> Cc: Ville Syrjälä
> Reported-by: Ville Syrjälä
> Fixes: f9476a6c6d0c ("drm/i915: Refactor platform specifics out of
> intel_get_shared_dpll()")
The scripts are dim, and don't yet handle a lone Fixes: line. Please
also add the relevant Cc. In this case,
$ dim fixes f9476a6c6d0c
Fixes: f9476a6c6d0c ("drm/i915: Refactor platform specifics out of
intel_get_shared_dpll()")
Cc: drm-intel-fi...@lists.freedesktop.org
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index f988adb..1e3d091 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -366,6 +366,9 @@ ibx_get_dpll(struct intel_crtc *crtc, struct
> intel_crtc_state *crtc_state,
>DPLL_ID_PCH_PLL_B);
> }
>
> + if (!pll)
> + return NULL;
> +
> /* reference the pll */
> intel_reference_shared_dpll(pll, crtc_state);
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] i915 kernel panic
On Mon, 23 May 2016, Oliver Leitner wrote: > I am having a problem on my HP Compaq 610 Laptop with its built in intel > graphics chip. It is causing me a kernel Panic. There is no kernel panic in your dmesg. There is a WARNING with a backtrace. What other symptoms do you have besides the warning? Is the system usable? Black screen? What? I suggest you file a bug at [1] and attach the logs there. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 06/20] drm/i915: Slaughter the thundering i915_wait_request herd
On 20/05/16 13:19, Chris Wilson wrote:
On Fri, May 20, 2016 at 01:04:13PM +0100, Tvrtko Ursulin wrote:
+ p = &b->waiters.rb_node;
+ while (*p) {
+ parent = *p;
+ if (wait->seqno == to_wait(parent)->seqno) {
+ /* We have multiple waiters on the same seqno, select
+* the highest priority task (that with the smallest
+* task->prio) to serve as the bottom-half for this
+* group.
+*/
+ if (wait->task->prio > to_wait(parent)->task->prio) {
+ p = &parent->rb_right;
+ first = false;
+ } else
+ p = &parent->rb_left;
+ } else if (i915_seqno_passed(wait->seqno,
+to_wait(parent)->seqno)) {
+ p = &parent->rb_right;
+ if (i915_seqno_passed(seqno, to_wait(parent)->seqno))
+ completed = parent;
Hm don't you need the completed handling in the equal seqno case as well?
i915_seqno_passed() returnts true if seqnoA == seqnoB
I meant in the first branch, multiple waiter on the same seqno?
+void intel_engine_remove_wait(struct intel_engine_cs *engine,
+ struct intel_wait *wait)
+{
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+
+ /* Quick check to see if this waiter was already decoupled from
+* the tree by the bottom-half to avoid contention on the spinlock
+* by the herd.
+*/
+ if (RB_EMPTY_NODE(&wait->node))
+ return;
+
+ spin_lock(&b->lock);
+
+ if (b->first_waiter == wait->task) {
+ struct rb_node *next;
+ struct task_struct *task;
+ const int priority = wait->task->prio;
+
+ /* We are the current bottom-half. Find the next candidate,
+* the first waiter in the queue on the remaining oldest
+* request. As multiple seqnos may complete in the time it
+* takes us to wake up and find the next waiter, we have to
+* wake up that waiter for it to perform its own coherent
+* completion check.
+*/
+ next = rb_next(&wait->node);
+ if (chain_wakeup(next, priority)) {
Don't get this, next waiter my be a different seqno so how is the
priority check relevant?
We only want to call try_to_wake_up() on processes at least as important
as us.
But what is the comment saying about having to wake up the following
waiter, because of multiple seqnos potentially completing? It says that
and then it may not wake up anyone depending on relative priorities.
Also, how can the next node be smaller priority anyway, if equal
seqno if has be equal or greater I thought?
Next seqno can have a smaller priority (and be complete). chain_wakeup()
just asks if the next waiter is as important as ourselves (the next
waiter may be for a different seqno).
Then since add_waiter will wake up one extra waiter to handle the
missed irq case, here you may skip checking them based simply on
task priority which seems wrong.
Correct. They will be handled by the next waiter in the qeueue, not us.
Our job is to wake as many completed (+ the potentially completed bh) as
possible without incurring undue delay for ourselves. All completed waiters
will be woken in turn as the next bh to run will look at the list and
wake up those at the the same priority as itself (+ the next potentially
completed bh).
Who will wake up the next waiter? add_waiter will wake up one, and then
the next waiter here (in remove_waiter) may not wake up any further
based on priority.
Is the assumption that it is only possible to miss one interrupt?
+static inline bool intel_engine_wakeup(struct intel_engine_cs *engine)
+{
+ bool wakeup = false;
+ struct task_struct *task = READ_ONCE(engine->breadcrumbs.first_waiter);
+ /* Note that for this not to dangerously chase a dangling pointer,
+* the caller is responsible for ensure that the task remain valid for
+* wake_up_process() i.e. that the RCU grace period cannot expire.
+*/
This gets called from hard irq context and I did not manage to
figure out what makes it safe in the remove waiter path? Why the
hard irq couldn't not sample NULL here?
Because we only need RCU access to task, which is provided by the hard
irq context.
What does the comment mean by saying callers are responsible for the RCU
period? From which point to which? I still can't tie whatever callers
might be doing with the unrelated hardirq.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/int
Re: [Intel-gfx] [CI 16/20] drm/i915: Only query timestamp when measuring elapsed time
On 20/05/16 13:20, Chris Wilson wrote:
On Thu, May 19, 2016 at 04:44:03PM +0100, Tvrtko Ursulin wrote:
On 19/05/16 12:32, Chris Wilson wrote:
Avoid the two calls to ktime_get_raw_ns() (at best it reads the TSC) as
we only need to compute the elapsed time for a timed wait.
v2: Eliminate the unused local variable reducing the function size by 64
bytes (using the storage space on the callers stack rather than adding
to our stack frame)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b48a3b46e86f..2c254cf49c15 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1215,7 +1215,6 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
int state = interruptible ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
struct intel_wait wait;
unsigned long timeout_remain;
- s64 before = 0; /* Only to silence a compiler warning. */
int ret = 0;
might_sleep();
@@ -1234,12 +1233,9 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
if (*timeout == 0)
return -ETIME;
+ /* Record current time in case interrupted, or wedged */
timeout_remain = nsecs_to_jiffies_timeout(*timeout);
-
- /*
-* Record current time in case interrupted by signal, or wedged.
-*/
- before = ktime_get_raw_ns();
+ *timeout += ktime_get_raw_ns();
}
trace_i915_gem_request_wait_begin(req);
@@ -1296,9 +1292,9 @@ complete:
trace_i915_gem_request_wait_end(req);
if (timeout) {
- s64 tres = *timeout - (ktime_get_raw_ns() - before);
-
- *timeout = tres < 0 ? 0 : tres;
+ *timeout -= ktime_get_raw_ns();
+ if (*timeout < 0)
+ *timeout = 0;
/*
* Apparently ktime isn't accurate enough and occasionally has a
I think this is bad, better have a local than play games with
callers storage.
It's smaller faster code :-)
You know I am normally all for that but this one I cannot approve.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 04/20] drm/i915: Remove the dedicated hangcheck workqueue
On 20/05/16 13:23, Chris Wilson wrote: On Fri, May 20, 2016 at 01:07:29PM +0100, Tvrtko Ursulin wrote: On 19/05/16 14:13, Chris Wilson wrote: On Thu, May 19, 2016 at 01:50:51PM +0100, Tvrtko Ursulin wrote: On 19/05/16 12:32, Chris Wilson wrote: The queue only ever contains at most one item and has no special flags. It is just a very simple wrapper around the system-wq - a complication with no benefits. How much time do we take in the reset case - is it acceptable to do that work from the system wq? Hangcheck is a handful of register reads and some pointer chasing per engine. (There is a seqno_barrier in there which may be reasonably expensive but not a cpu hog). The error capture is run from the hangcheck context - and that is no small task (especially if we ever apply the object compression patches), but for safety we need to call stop_machine() so it really doesn't matter at that point. I don't see a stop_machine? So until there is one, using the system wq is a bit impolite in the error capture state, agreed? It's in the queue to fix the odd oops we get during capture. You'd be happy with system_long_wq in the meantime? Having read the comment in include/linux/workqueue.h I think that would be more appropriate in general, so yes. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel tree
On Mon, 23 May 2016, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/gpu/drm/i915/i915_trace.h:10:0,
> from drivers/gpu/drm/i915/i915_drv.h:2735,
> from drivers/gpu/drm/i915/i915_drv.c:34:
> drivers/gpu/drm/i915/intel_drv.h:36:41: fatal error:
> drm/drm_dp_dual_mode_helper.h: No such file or directory
>
> Caused by commit
>
> 8d87410a019f ("drm/i915: Respect DP++ adaptor TMDS clock limit")
>
> I have used the drm-intel tree from next-20160520 for today.
Hi Stephen, my bad, should be fixed now, sorry for the trouble.
(Note to self, don't even dream of doing this stuff when you're out
sick. Try to remember there was a reason you were out sick and not at
the office in the first place...)
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links
On Wed, May 18, 2016 at 01:24:12PM +0300, Mika Kuoppala wrote:
> Patrik Jakobsson writes:
>
> > [ text/plain ]
> > Load specific firmware versions for the DMC instead of using symbolic
> > links. The currently recommended versions are: SKL 1.26, KBL 1.01 and
> > BXT 1.07.
> >
> > Certain DMC versions need workarounds in the driver which forces us to
> > have a tight dependency between firmware and driver. In order to be able
> > to provide a tested and known working configuration we must lock down on
> > a specific DMC firmware version.
> >
> > Cc: Rodrigo Vivi
> > Cc: Imre Deak
> > Cc: Mika Kuoppala
> > Signed-off-by: Patrik Jakobsson
>
> Reviewed-by: Mika Kuoppala
>
> We need ack from Rodrigo and/or whomever is handling
> the fw releasing side.
>
> -Mika
>
As discussed on IRC, Rodrigo is currently away but since he requested this
feature we indirectly have his ACK.
-Patrik
> > ---
> > drivers/gpu/drm/i915/intel_csr.c | 29 ++---
> > 1 file changed, 14 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index 2b3b428..ea047cd 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -41,15 +41,15 @@
> > * be moved to FW_FAILED.
> > */
> >
> > -#define I915_CSR_KBL "i915/kbl_dmc_ver1.bin"
> > +#define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
> > MODULE_FIRMWARE(I915_CSR_KBL);
> > #define KBL_CSR_VERSION_REQUIRED CSR_VERSION(1, 1)
> >
> > -#define I915_CSR_SKL "i915/skl_dmc_ver1.bin"
> > +#define I915_CSR_SKL "i915/skl_dmc_ver1_26.bin"
> > MODULE_FIRMWARE(I915_CSR_SKL);
> > -#define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 23)
> > +#define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 26)
> >
> > -#define I915_CSR_BXT "i915/bxt_dmc_ver1.bin"
> > +#define I915_CSR_BXT "i915/bxt_dmc_ver1_07.bin"
> > MODULE_FIRMWARE(I915_CSR_BXT);
> > #define BXT_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
> >
> > @@ -286,7 +286,7 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
> > *dev_priv,
> > uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
> > uint32_t i;
> > uint32_t *dmc_payload;
> > - uint32_t required_min_version;
> > + uint32_t required_version;
> >
> > if (!fw)
> > return NULL;
> > @@ -303,24 +303,23 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
> > *dev_priv,
> > csr->version = css_header->version;
> >
> > if (IS_KABYLAKE(dev_priv)) {
> > - required_min_version = KBL_CSR_VERSION_REQUIRED;
> > + required_version = KBL_CSR_VERSION_REQUIRED;
> > } else if (IS_SKYLAKE(dev_priv)) {
> > - required_min_version = SKL_CSR_VERSION_REQUIRED;
> > + required_version = SKL_CSR_VERSION_REQUIRED;
> > } else if (IS_BROXTON(dev_priv)) {
> > - required_min_version = BXT_CSR_VERSION_REQUIRED;
> > + required_version = BXT_CSR_VERSION_REQUIRED;
> > } else {
> > MISSING_CASE(INTEL_REVID(dev_priv));
> > - required_min_version = 0;
> > + required_version = 0;
> > }
> >
> > - if (csr->version < required_min_version) {
> > - DRM_INFO("Refusing to load old DMC firmware v%u.%u,"
> > -" please upgrade to v%u.%u or later"
> > - " [" FIRMWARE_URL "].\n",
> > + if (csr->version != required_version) {
> > + DRM_INFO("Refusing to load DMC firmware v%u.%u,"
> > +" please use v%u.%u [" FIRMWARE_URL "].\n",
> > CSR_VERSION_MAJOR(csr->version),
> > CSR_VERSION_MINOR(csr->version),
> > -CSR_VERSION_MAJOR(required_min_version),
> > -CSR_VERSION_MINOR(required_min_version));
> > +CSR_VERSION_MAJOR(required_version),
> > +CSR_VERSION_MINOR(required_version));
> > return NULL;
> > }
> >
> > --
> > 2.5.0
--
Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm,
Sweden Registration Number: 556189-6027
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/12] drm/i915: Rename struct intel_context
On 22/05/16 14:02, Chris Wilson wrote:
Our goal is to rename the anonymous per-engine struct beneath the
current intel_context. However, after a lively debate resolving around
the confusion between intel_context_engine and intel_engine_context, the
realisation is that the two structs target different users. The outer
struct is API / user facing, and so carries the higher level GEM
information. The inner struct is hw facing. Thus we want to name the
inner struct intel_context and the outer one i915_gem_context. As the
first step, we need to rename the current struct:
s/struct intel_context/struct i915_gem_context/
which fits much better with its constructors already conveying the
i915_gem_context prefix!
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Signed-off-by: Chris Wilson
Cc: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 10 +++---
drivers/gpu/drm/i915/i915_drv.h| 22 ++---
drivers/gpu/drm/i915/i915_gem.c| 8 ++---
drivers/gpu/drm/i915/i915_gem_context.c| 52 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +++---
drivers/gpu/drm/i915/i915_guc_submission.c | 12 +++
drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
drivers/gpu/drm/i915/i915_trace.h | 12 +++
drivers/gpu/drm/i915/intel_guc.h | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 22 ++---
drivers/gpu/drm/i915/intel_lrc.h | 10 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h| 4 +--
12 files changed, 84 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4c6b48dbd6e2..ae28e6e9d603 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -199,7 +199,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
}
-static void describe_ctx(struct seq_file *m, struct intel_context *ctx)
+static void describe_ctx(struct seq_file *m, struct i915_gem_context *ctx)
{
seq_putc(m, ctx->legacy_hw_ctx.initialized ? 'I' : 'i');
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
@@ -2000,7 +2000,7 @@ static int i915_context_status(struct seq_file *m, void
*unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
- struct intel_context *ctx;
+ struct i915_gem_context *ctx;
enum intel_engine_id id;
int ret;
@@ -2046,7 +2046,7 @@ static int i915_context_status(struct seq_file *m, void
*unused)
}
static void i915_dump_lrc_obj(struct seq_file *m,
- struct intel_context *ctx,
+ struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
struct page *page;
@@ -2094,7 +2094,7 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
- struct intel_context *ctx;
+ struct i915_gem_context *ctx;
int ret;
if (!i915.enable_execlists) {
@@ -2274,7 +2274,7 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
static int per_file_ctx(int id, void *ptr, void *data)
{
- struct intel_context *ctx = ptr;
+ struct i915_gem_context *ctx = ptr;
struct seq_file *m = data;
struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e2abd9eb352b..8380102bbdd8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -831,7 +831,7 @@ struct i915_ctx_hang_stats {
#define CONTEXT_NO_ZEROMAP (1<<0)
/**
- * struct intel_context - as the name implies, represents a context.
+ * struct i915_gem_context - as the name implies, represents a context.
* @ref: reference count.
* @user_handle: userspace tracking identity for this context.
* @remap_slice: l3 row remapping information.
@@ -849,7 +849,7 @@ struct i915_ctx_hang_stats {
* Contexts are memory images used by the hardware to store copies of their
* internal state.
*/
-struct intel_context {
+struct i915_gem_context {
struct kref ref;
int user_handle;
uint8_t remap_slice;
@@ -1710,7 +1710,7 @@ struct i915_execbuffer_params {
uint64_tbatch_obj_vm_offset;
struct intel_engine_cs *engine;
struct drm_i915_gem_object *batch_obj;
- struct intel_context*ctx;
+ struct i915_gem_context*ctx;
struct drm_i915_gem_request *request;
};
@@ -2013,7 +2013,7 @@ struct drm_i915_private {
void (*stop_engine)(struct intel_engine_cs *engine);
Re: [Intel-gfx] [PATCH 03/12] drm/i915: Apply lockdep annotations to i915_gem_context.c
On 22/05/16 14:02, Chris Wilson wrote:
Markup the functions that require the caller to hold struct_mutex with
lockdep_assert_held(). In the hopefully not-too-distant future we will
split the struct_mutex up, and in doing so we need to be sure that we
know what it protects - here the lockdep annotations are invaluable.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_context.c | 16 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8380102bbdd8..48a222ddd8b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3429,6 +3429,7 @@ static inline void i915_gem_context_reference(struct
i915_gem_context *ctx)
static inline void i915_gem_context_unreference(struct i915_gem_context *ctx)
{
+ lockdep_assert_held(&ctx->i915->dev->struct_mutex);
kref_put(&ctx->ref, i915_gem_context_free);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8484da26b5d4..af747f14522e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -153,6 +153,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
{
struct i915_gem_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
+ lockdep_assert_held(&ctx->i915->dev->struct_mutex);
trace_i915_context_free(ctx);
if (i915.enable_execlists)
@@ -181,6 +182,8 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t
size)
struct drm_i915_gem_object *obj;
int ret;
+ lockdep_assert_held(&dev->struct_mutex);
+
obj = i915_gem_object_create(dev, size);
if (IS_ERR(obj))
return obj;
@@ -368,6 +371,8 @@ void i915_gem_context_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ lockdep_assert_held(&dev->struct_mutex);
+
if (i915.enable_execlists) {
struct i915_gem_context *ctx;
@@ -433,6 +438,8 @@ void i915_gem_context_lost(struct drm_i915_private
*dev_priv)
{
struct intel_engine_cs *engine;
+ lockdep_assert_held(&dev_priv->dev->struct_mutex);
+
for_each_engine(engine, dev_priv) {
if (engine->last_context == NULL)
continue;
@@ -451,6 +458,8 @@ void i915_gem_context_fini(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct i915_gem_context *dctx = dev_priv->kernel_context;
+ lockdep_assert_held(&dev->struct_mutex);
+
if (dctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
@@ -491,6 +500,8 @@ void i915_gem_context_close(struct drm_device *dev, struct
drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
+ lockdep_assert_held(&dev->struct_mutex);
+
idr_for_each(&file_priv->context_idr, context_idr_cleanup, NULL);
idr_destroy(&file_priv->context_idr);
}
@@ -500,6 +511,8 @@ i915_gem_context_get(struct drm_i915_file_private
*file_priv, u32 id)
{
struct i915_gem_context *ctx;
+ lockdep_assert_held(&file_priv->dev_priv->dev->struct_mutex);
+
ctx = idr_find(&file_priv->context_idr, id);
if (!ctx)
return ERR_PTR(-ENOENT);
@@ -852,10 +865,9 @@ unpin_out:
int i915_switch_context(struct drm_i915_gem_request *req)
{
struct intel_engine_cs *engine = req->engine;
- struct drm_i915_private *dev_priv = req->i915;
WARN_ON(i915.enable_execlists);
- WARN_ON(!mutex_is_locked(&dev_priv->dev->struct_mutex));
+ lockdep_assert_held(&req->i915->dev->struct_mutex);
if (engine->id != RCS ||
req->ctx->legacy_hw_ctx.rcs_state == NULL) {
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Convert OpRegion ASLE irq worker into a tasklet
On Thu, 19 May 2016, Chris Wilson wrote:
> Using a tasklet for an irq bottom-half is the preferred form as it
> should ensure minimal latency from the irq to execution of the tasklet.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_opregion.c | 19 ++-
> 2 files changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3a991bfce067..ce7f30cecb1f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -438,7 +438,7 @@ struct intel_opregion {
> const void *vbt;
> u32 vbt_size;
> u32 *lid_state;
> - struct work_struct asle_work;
> + struct tasklet_struct asle_task;
> };
> #define OPREGION_SIZE(8*1024)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 8347fd8af8e4..727ca017f5b0 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -521,22 +521,15 @@ static u32 asle_isct_state(struct drm_device *dev)
> return ASLC_ISCT_STATE_FAILED;
> }
>
> -static void asle_work(struct work_struct *work)
> +static void asle_task(unsigned long data)
> {
> - struct intel_opregion *opregion =
> - container_of(work, struct intel_opregion, asle_work);
> - struct drm_i915_private *dev_priv =
> - container_of(opregion, struct drm_i915_private, opregion);
> + struct drm_i915_private *dev_priv = (struct drm_i915_private *)data;
> struct drm_device *dev = dev_priv->dev;
> struct opregion_asle *asle = dev_priv->opregion.asle;
> u32 aslc_stat = 0;
> u32 aslc_req;
>
> - if (!asle)
> - return;
> -
Mmkay.
> aslc_req = asle->aslc;
> -
> if (!(aslc_req & ASLC_REQ_MSK)) {
> DRM_DEBUG_DRIVER("No request on ASLC interrupt 0x%08x\n",
>aslc_req);
> @@ -577,7 +570,7 @@ static void asle_work(struct work_struct *work)
> void intel_opregion_asle_intr(struct drm_i915_private *dev_priv)
> {
> if (dev_priv->opregion.asle)
> - schedule_work(&dev_priv->opregion.asle_work);
> + tasklet_schedule(&dev_priv->opregion.asle_task);
> }
>
> #define ACPI_EV_DISPLAY_SWITCH (1<<0)
> @@ -814,11 +807,11 @@ void intel_opregion_fini(struct drm_device *dev)
> if (!opregion->header)
> return;
>
> + tasklet_kill(&dev_priv->opregion.asle_task);
> +
So what if you got a new asle interrupt right here?
> if (opregion->asle)
> opregion->asle->ardy = ASLE_ARDY_NOT_READY;
This is supposed to signal we're not ready to handle said interrupts
anymore. Not that we should rely on it either.
It wasn't pretty before, but I think this patch widens the window for a
race. If you kept the *other* code as it were, and just changed the work
to tasklets, I'd be willing to look in the other direction...
BR,
Jani.
>
> - cancel_work_sync(&dev_priv->opregion.asle_work);
> -
> if (opregion->acpi) {
> opregion->acpi->drdy = 0;
>
> @@ -938,7 +931,7 @@ int intel_opregion_setup(struct drm_device *dev)
> return -ENOTSUPP;
> }
>
> - INIT_WORK(&opregion->asle_work, asle_work);
> + tasklet_init(&opregion->asle_task, asle_task, (unsigned long)dev_priv);
>
> base = memremap(asls, OPREGION_SIZE, MEMREMAP_WB);
> if (!base)
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915: Rename and inline i915_gem_context_get()
On 22/05/16 14:02, Chris Wilson wrote:
i915_gem_context_get() is a very simple wrapper around idr_find(), so
simple that it would be smaller to do the lookup inline. Also we use the
verb 'lookup' to return a pointer from a handle, freeing 'get' to imply
obtaining a reference to the context.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h| 17 +++--
drivers/gpu/drm/i915/i915_gem_context.c| 22 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
3 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48a222ddd8b3..e4e3614335ec 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3417,11 +3417,24 @@ void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
int i915_switch_context(struct drm_i915_gem_request *req);
-struct i915_gem_context *
-i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id);
void i915_gem_context_free(struct kref *ctx_ref);
struct drm_i915_gem_object *
i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
+
+static inline struct i915_gem_context *
+i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
+{
+ struct i915_gem_context *ctx;
+
+ lockdep_assert_held(&file_priv->dev_priv->dev->struct_mutex);
+
+ ctx = idr_find(&file_priv->context_idr, id);
+ if (!ctx)
+ return ERR_PTR(-ENOENT);
+
+ return ctx;
+}
+
static inline void i915_gem_context_reference(struct i915_gem_context *ctx)
{
kref_get(&ctx->ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index af747f14522e..aa329175f73a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -506,20 +506,6 @@ void i915_gem_context_close(struct drm_device *dev, struct
drm_file *file)
idr_destroy(&file_priv->context_idr);
}
-struct i915_gem_context *
-i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id)
-{
- struct i915_gem_context *ctx;
-
- lockdep_assert_held(&file_priv->dev_priv->dev->struct_mutex);
-
- ctx = idr_find(&file_priv->context_idr, id);
- if (!ctx)
- return ERR_PTR(-ENOENT);
-
- return ctx;
-}
-
static inline int
mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
{
@@ -951,7 +937,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
- ctx = i915_gem_context_get(file_priv, args->ctx_id);
+ ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
return PTR_ERR(ctx);
@@ -977,7 +963,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
- ctx = i915_gem_context_get(file_priv, args->ctx_id);
+ ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
return PTR_ERR(ctx);
@@ -1020,7 +1006,7 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
if (ret)
return ret;
- ctx = i915_gem_context_get(file_priv, args->ctx_id);
+ ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
return PTR_ERR(ctx);
@@ -1072,7 +1058,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
if (ret)
return ret;
- ctx = i915_gem_context_get(file->driver_priv, args->ctx_id);
+ ctx = i915_gem_context_lookup(file->driver_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
return PTR_ERR(ctx);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index e61b92d7b0bc..84d990331abd 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1075,7 +1075,7 @@ i915_gem_validate_context(struct drm_device *dev, struct
drm_file *file,
if (engine->id != RCS && ctx_id != DEFAULT_CONTEXT_HANDLE)
return ERR_PTR(-EINVAL);
- ctx = i915_gem_context_get(file->driver_priv, ctx_id);
+ ctx = i915_gem_context_lookup(file->driver_priv, ctx_id);
if (IS_ERR(ctx))
return ctx;
Makes sense.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.or
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Rename i915_gem_context_reference/unreference()
On 22/05/16 14:02, Chris Wilson wrote:
As these are wrappers around kref_get/kref_put() it is preferable to
follow the naming convention and use the same verb get/put in our
wrapper names for manipulating a reference to the context.
Not so sure about this one. We got objects, framebuffers and requests
using (un)reference naming so don't see that making contexts different
is a good idea.
Regards,
Tvrtko
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h| 6 --
drivers/gpu/drm/i915/i915_gem.c| 7 +++
drivers/gpu/drm/i915/i915_gem_context.c| 22 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++---
drivers/gpu/drm/i915/intel_lrc.c | 4 ++--
5 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4e3614335ec..0a3442fcd93e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3435,12 +3435,14 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
-static inline void i915_gem_context_reference(struct i915_gem_context *ctx)
+static inline struct i915_gem_context *
+i915_gem_context_get(struct i915_gem_context *ctx)
{
kref_get(&ctx->ref);
+ return ctx;
}
-static inline void i915_gem_context_unreference(struct i915_gem_context *ctx)
+static inline void i915_gem_context_put(struct i915_gem_context *ctx)
{
lockdep_assert_held(&ctx->i915->dev->struct_mutex);
kref_put(&ctx->ref, i915_gem_context_free);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 728b66911840..d7ae030e5a0b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1418,7 +1418,7 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
request->engine);
}
- i915_gem_context_unreference(request->ctx);
+ i915_gem_context_put(request->ctx);
i915_gem_request_unreference(request);
}
@@ -2775,8 +2775,7 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
req->i915 = dev_priv;
req->engine = engine;
req->reset_counter = reset_counter;
- req->ctx = ctx;
- i915_gem_context_reference(req->ctx);
+ req->ctx = i915_gem_context_get(ctx);
/*
* Reserve space in the ring buffer for all the commands required to
@@ -2798,7 +2797,7 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
return 0;
err_ctx:
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
err:
kmem_cache_free(dev_priv->requests, req);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index aa329175f73a..a4c6377eea32 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -290,7 +290,7 @@ __create_hw_context(struct drm_device *dev,
return ctx;
err_out:
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
return ERR_PTR(ret);
}
@@ -351,7 +351,7 @@ err_unpin:
i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
err_destroy:
idr_remove(&file_priv->context_idr, ctx->user_handle);
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
return ERR_PTR(ret);
}
@@ -363,7 +363,7 @@ static void i915_gem_context_unpin(struct i915_gem_context
*ctx,
} else {
if (engine->id == RCS && ctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
}
}
@@ -463,7 +463,7 @@ void i915_gem_context_fini(struct drm_device *dev)
if (dctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
- i915_gem_context_unreference(dctx);
+ i915_gem_context_put(dctx);
dev_priv->kernel_context = NULL;
ida_destroy(&dev_priv->context_hw_ida);
@@ -473,7 +473,7 @@ static int context_idr_cleanup(int id, void *p, void *data)
{
struct i915_gem_context *ctx = p;
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
return 0;
}
@@ -785,10 +785,9 @@ static int do_rcs_switch(struct drm_i915_gem_request *req)
/* obj is kept alive until the next request by its active ref */
i915_gem_object_ggtt_unpin(from->legacy_hw_ctx.rcs_state);
- i915_gem_context_unreference(from);
+ i915_gem_context_put(from);
}
- i915_gem_context_reference(to);
- engine->last_context = to;
+ engine->last_context = i915_gem_context_get(to);
/*
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Convert OpRegion ASLE irq worker into a tasklet
On Mon, May 23, 2016 at 12:12:30PM +0300, Jani Nikula wrote: > > #define ACPI_EV_DISPLAY_SWITCH (1<<0) > > @@ -814,11 +807,11 @@ void intel_opregion_fini(struct drm_device *dev) > > if (!opregion->header) > > return; > > > > + tasklet_kill(&dev_priv->opregion.asle_task); > > + > > So what if you got a new asle interrupt right here? Before we call fini, we should have de-installed the irq and done synchronize_irq, so we only have to worry about the residual task. (At least that is what I expect!) > > if (opregion->asle) > > opregion->asle->ardy = ASLE_ARDY_NOT_READY; > > This is supposed to signal we're not ready to handle said interrupts > anymore. Not that we should rely on it either. > > It wasn't pretty before, but I think this patch widens the window for a > race. If you kept the *other* code as it were, and just changed the work > to tasklets, I'd be willing to look in the other direction... Considering the recent discussion about the negatives of tasklets/ksoftirqd, I think I was being too cavalier in this conversion, and we should only think about using tasklet where the post-interrupt latency is critical. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Name the inner most per-engine intel_context struct
On 22/05/16 14:02, Chris Wilson wrote:
We want to give a name to the currently anonymous per-engine struct
inside the context, so that we can assign it to a local variable and
save clumsy typing. The name we have chosen is intel_context as it
reflects the HW facing portion of the context state (the logical context
state, the registers, the ringbuffer etc).
Signed-off-by: Chris Wilson
Cc: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 15 ++---
drivers/gpu/drm/i915/intel_lrc.c | 90 +++---
3 files changed, 51 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0a3442fcd93e..e6735dc9eeb2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -869,7 +869,7 @@ struct i915_gem_context {
} legacy_hw_ctx;
/* Execlists */
- struct {
+ struct intel_context {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
int pin_count;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a292672f36d5..c29c1d19764f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -363,7 +363,6 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
struct i915_gem_context *ctx = client->owner;
struct guc_context_desc desc;
struct sg_table *sg;
- enum intel_engine_id id;
u32 gfx_addr;
memset(&desc, 0, sizeof(desc));
@@ -373,10 +372,10 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.priority = client->priority;
desc.db_id = client->doorbell_id;
- for_each_engine_id(engine, dev_priv, id) {
+ for_each_engine(engine, dev_priv) {
+ struct intel_context *ce = &ctx->engine[engine->id];
struct guc_execlist_context *lrc = &desc.lrc[engine->guc_id];
struct drm_i915_gem_object *obj;
- uint64_t ctx_desc;
/* TODO: We have a design issue to be solved here. Only when we
* receive the first batch, we know which engine is used by the
@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
* for now who owns a GuC client. But for future owner of GuC
* client, need to make sure lrc is pinned prior to enter here.
*/
- obj = ctx->engine[id].state;
- if (!obj)
+ if (!ce->state)
break; /* XXX: continue? */
- ctx_desc = intel_lr_context_descriptor(ctx, engine);
- lrc->context_desc = (u32)ctx_desc;
+ lrc->context_desc = lower_32_bits(ce->lrc_desc);
Could have kept use of intel_lr_context_descriptor for better separation.
/* The state page is after PPHWSP */
- gfx_addr = i915_gem_obj_ggtt_offset(obj);
+ gfx_addr = i915_gem_obj_ggtt_offset(ce->state);
lrc->ring_lcra = gfx_addr + LRC_STATE_PN * PAGE_SIZE;
lrc->context_id = (client->ctx_index << GUC_ELC_CTXID_OFFSET) |
(engine->guc_id << GUC_ELC_ENGINE_OFFSET);
- obj = ctx->engine[id].ringbuf->obj;
+ obj = ce->ringbuf->obj;
gfx_addr = i915_gem_obj_ggtt_offset(obj);
lrc->ring_begin = gfx_addr;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9a55478e23ac..4b7c9680b097 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -300,7 +300,7 @@ logical_ring_init_platform_invariants(struct
intel_engine_cs *engine)
* descriptor for a pinned context
*
* @ctx: Context to work on
- * @ring: Engine the descriptor will be used with
+ * @engine: Engine the descriptor will be used with
*
* The context descriptor encodes various attributes of a context,
* including its GTT address and some flags. Because it's fairly
@@ -318,16 +318,17 @@ static void
intel_lr_context_descriptor_update(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
+ struct intel_context *ce = &ctx->engine[engine->id];
u64 desc;
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1engine[engine->id].lrc_vma->node.start + /* bits 12-31 */
- LRC_PPHWSP_PN * PAGE_SIZE;
+ desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
+ /* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT; /* bits 32-52 */
- ctx->engine[engine->id].lrc_desc = desc;
+
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Rename i915_gem_context_reference/unreference()
On Mon, May 23, 2016 at 10:17:01AM +0100, Tvrtko Ursulin wrote: > > On 22/05/16 14:02, Chris Wilson wrote: > >As these are wrappers around kref_get/kref_put() it is preferable to > >follow the naming convention and use the same verb get/put in our > >wrapper names for manipulating a reference to the context. > > Not so sure about this one. We got objects, framebuffers and > requests using (un)reference naming so don't see that making > contexts different is a good idea. I've converted objects and requests in the lockless patches. So contexts were a bit of an eyesore in amongst the *_get()/*_put(). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/12] drm/i915: Move pinning of dev_priv->kernel_context into its creator
On 22/05/16 14:02, Chris Wilson wrote:
Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.
Makes sense.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 52 +++--
1 file changed, 23 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index a4c6377eea32..51e83a79ab36 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -303,9 +303,7 @@ static struct i915_gem_context *
i915_gem_create_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
{
- const bool is_global_default_ctx = file_priv == NULL;
struct i915_gem_context *ctx;
- int ret = 0;
BUG_ON(!mutex_is_locked(&dev->struct_mutex));
@@ -313,30 +311,14 @@ i915_gem_create_context(struct drm_device *dev,
if (IS_ERR(ctx))
return ctx;
- if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
- /* We may need to do things with the shrinker which
-* require us to immediately switch back to the default
-* context. This can cause a problem as pinning the
-* default context also requires GTT space which may not
-* be available. To avoid this we always pin the default
-* context.
-*/
- ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
-
get_context_alignment(to_i915(dev)), 0);
- if (ret) {
- DRM_DEBUG_DRIVER("Couldn't pin %d\n", ret);
- goto err_destroy;
- }
- }
-
if (USES_FULL_PPGTT(dev)) {
struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
- if (IS_ERR_OR_NULL(ppgtt)) {
+ if (IS_ERR(ppgtt)) {
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
- ret = PTR_ERR(ppgtt);
- goto err_unpin;
+ i915_gem_context_put(ctx);
+ return ERR_CAST(ppgtt);
}
ctx->ppgtt = ppgtt;
@@ -345,14 +327,6 @@ i915_gem_create_context(struct drm_device *dev,
trace_i915_context_create(ctx);
return ctx;
-
-err_unpin:
- if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state)
- i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
-err_destroy:
- idr_remove(&file_priv->context_idr, ctx->user_handle);
Isn't idr_remove still required in the error path above?
- i915_gem_context_put(ctx);
- return ERR_PTR(ret);
}
static void i915_gem_context_unpin(struct i915_gem_context *ctx,
@@ -426,6 +400,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
+ if (ctx->legacy_hw_ctx.rcs_state) {
+ int ret;
+
+ /* We may need to do things with the shrinker which
+* require us to immediately switch back to the default
+* context. This can cause a problem as pinning the
+* default context also requires GTT space which may not
+* be available. To avoid this we always pin the default
+* context.
+*/
+ ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+ get_context_alignment(dev_priv), 0);
+ if (ret) {
+ DRM_ERROR("Failed to pinned default global context (error
%d)\n",
+ ret);
+ i915_gem_context_put(ctx);
+ return ret;
+ }
+ }
+
dev_priv->kernel_context = ctx;
DRM_DEBUG_DRIVER("%s context support initialized\n",
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/12] drm/i915: Show i915_gem_context owner in debugfs
On 22/05/16 14:02, Chris Wilson wrote:
Print the context's owner (via the pid under file_priv) under debugfs.
Note that since this was originally introducing
dev_priv->kernel_context, there are a couple of leftover minor chunks.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ae28e6e9d603..945fe4710b37 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2014,9 +2014,22 @@ static int i915_context_status(struct seq_file *m, void
*unused)
continue;
seq_printf(m, "HW context %u ", ctx->hw_id);
+ if (IS_ERR(ctx->file_priv)) {
+ seq_puts(m, "(deleted) ");
+ } else if (ctx->file_priv) {
+ struct pid *pid = ctx->file_priv->file->pid;
Hm, can you deref file_priv after the file has been closed / client
exited? We could still have the context on the list after that point..
+ struct task_struct *task;
+
+ task = get_pid_task(pid, PIDTYPE_PID);
+ if (task) {
+ seq_printf(m, "(%s [%d]) ",
+ task->comm, task->pid);
+ put_task_struct(task);
+ }
+ } else
+ seq_puts(m, "(kernel) ");
+
describe_ctx(m, ctx);
- if (ctx == dev_priv->kernel_context)
- seq_printf(m, "(kernel context) ");
if (i915.enable_execlists) {
seq_putc(m, '\n');
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: Put the kernel_context in drm_i915_private next to its friends
On 22/05/16 14:02, Chris Wilson wrote:
Just move the kernel_context memboer of drm_i915_private next to the
engines it is associated with.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h| 3 +--
drivers/gpu/drm/i915/i915_guc_submission.c | 5 +++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e6735dc9eeb2..d3d2538d17e8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1760,6 +1760,7 @@ struct drm_i915_private {
wait_queue_head_t gmbus_wait_queue;
struct pci_dev *bridge_dev;
+ struct i915_gem_context *kernel_context;
struct intel_engine_cs engine[I915_NUM_ENGINES];
struct drm_i915_gem_object *semaphore_obj;
uint32_t last_seqno, next_seqno;
@@ -2013,8 +2014,6 @@ struct drm_i915_private {
void (*stop_engine)(struct intel_engine_cs *engine);
} gt;
- struct i915_gem_context *kernel_context;
-
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
OK bit.
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index c29c1d19764f..78b70526c197 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -912,11 +912,12 @@ int i915_guc_submission_enable(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = &dev_priv->guc;
- struct i915_gem_context *ctx = dev_priv->kernel_context;
struct i915_guc_client *client;
/* client for execbuf submission */
- client = guc_client_alloc(dev, GUC_CTX_PRIORITY_KMD_NORMAL, ctx);
+ client = guc_client_alloc(dev,
+ GUC_CTX_PRIORITY_KMD_NORMAL,
+ dev_priv->kernel_context);
if (!client) {
DRM_ERROR("Failed to create execbuf guc_client\n");
return -ENOMEM;
Churn bit. :)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/12] drm/i915: Move pinning of dev_priv->kernel_context into its creator
On Mon, May 23, 2016 at 10:33:24AM +0100, Tvrtko Ursulin wrote:
> >@@ -313,30 +311,14 @@ i915_gem_create_context(struct drm_device *dev,
> > if (IS_ERR(ctx))
> > return ctx;
> >
> >-if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
> >-/* We may need to do things with the shrinker which
> >- * require us to immediately switch back to the default
> >- * context. This can cause a problem as pinning the
> >- * default context also requires GTT space which may not
> >- * be available. To avoid this we always pin the default
> >- * context.
> >- */
> >-ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
> >-
> >get_context_alignment(to_i915(dev)), 0);
> >-if (ret) {
> >-DRM_DEBUG_DRIVER("Couldn't pin %d\n", ret);
> >-goto err_destroy;
> >-}
> >-}
> >-
> > if (USES_FULL_PPGTT(dev)) {
> > struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
> >
> >-if (IS_ERR_OR_NULL(ppgtt)) {
> >+if (IS_ERR(ppgtt)) {
> > DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
> > PTR_ERR(ppgtt));
> >-ret = PTR_ERR(ppgtt);
> >-goto err_unpin;
> >+i915_gem_context_put(ctx);
> >+return ERR_CAST(ppgtt);
> > }
> >
> > ctx->ppgtt = ppgtt;
> >@@ -345,14 +327,6 @@ i915_gem_create_context(struct drm_device *dev,
> > trace_i915_context_create(ctx);
> >
> > return ctx;
> >-
> >-err_unpin:
> >-if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state)
> >-i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
> >-err_destroy:
> >-idr_remove(&file_priv->context_idr, ctx->user_handle);
>
> Isn't idr_remove still required in the error path above?
Yes. I can blame a rebase error here since in the kernel it was
extracted upon we call context_close() here instead which does the idr
removal as well.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/12] drm/i915: Show i915_gem_context owner in debugfs
On Mon, May 23, 2016 at 10:42:42AM +0100, Tvrtko Ursulin wrote:
>
>
> On 22/05/16 14:02, Chris Wilson wrote:
> >Print the context's owner (via the pid under file_priv) under debugfs.
> >
> >Note that since this was originally introducing
> >dev_priv->kernel_context, there are a couple of leftover minor chunks.
> >
> >Signed-off-by: Chris Wilson
> >Cc: Tvrtko Ursulin
> >Cc: Joonas Lahtinen
> >---
> > drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
> > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> >b/drivers/gpu/drm/i915/i915_debugfs.c
> >index ae28e6e9d603..945fe4710b37 100644
> >--- a/drivers/gpu/drm/i915/i915_debugfs.c
> >+++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >@@ -2014,9 +2014,22 @@ static int i915_context_status(struct seq_file *m,
> >void *unused)
> > continue;
> >
> > seq_printf(m, "HW context %u ", ctx->hw_id);
> >+if (IS_ERR(ctx->file_priv)) {
> >+seq_puts(m, "(deleted) ");
> >+} else if (ctx->file_priv) {
> >+struct pid *pid = ctx->file_priv->file->pid;
>
> Hm, can you deref file_priv after the file has been closed / client
> exited? We could still have the context on the list after that
> point..
Hmm, this was extracted from after the context_close patch because I
didn't think we had that bug... We do.
That's easy enough to mark as closed when the file is, which is what we
need later anyway.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/userptr: Convert to drm_i915_private
On to, 2016-05-19 at 16:17 +0100, Chris Wilson wrote:
> -int
> -i915_gem_init_userptr(struct drm_device *dev)
> +void i915_gem_init_userptr(struct drm_i915_private *dev_priv)
> {
> - struct drm_i915_private *dev_priv = to_i915(dev);
> mutex_init(&dev_priv->mm_lock);
> hash_init(dev_priv->mm_structs);
> return 0;
You should remove the "return 0;" if you make the function void, and
maybe also make a not int he commit message.
With that,
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Nouveau] [PATCH v4] vga_switcheroo: Add helper for deferred probing
On Sat, 21 May 2016, Lukas Wunner wrote:
> Hi Emil,
>
> On Fri, May 20, 2016 at 12:41:04AM +0100, Emil Velikov wrote:
>> On 19 May 2016 at 15:39, Lukas Wunner wrote:
>> > +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev)
>> > +{
>> > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
>> Not sure if we want/need this, yet at least. This changes behaviour
>> which is not what refactoring patches should be doing, right ? if
>> needed it ought to be a separate patch, imho.
>
> Well, the commit message doesn't claim "no functional change", does it?
>
> Daniel Vetter explicitly wanted the ability to use the helper in
> vga_switcheroo audio clients, and those shouldn't run the apple-gmux
> test. I think it makes sense to enclose it in the above-quoted if-block
> *now* even though it's not needed. Once someone adds a check for an
> audio client, chances are they'll forget to add this if-block.
Please always keep functional changes separate from non-functional
refactoring. Combining them into one just makes everyone's life
harder. This may seem like a simple case here, but you should get into
the habit and stick to it.
If you do a non-functional refactoring change, it's easy for people to
review that change. I could've reviewed your patch in a few minutes;
that's what I was in fact going to do until I stumbled on the functional
change. Maybe I don't have the time to dig all the implications in that
change right now. Bummer.
If you do a non-functional refactoring change, and claim it's
non-functional in the commit message, it'll help anyone landing on that
commit as a result of bisecting a regression. Either the bisect was
bogus, or your patch was unintentionally functional after all. Either
should be easier to verify than a combined change.
If you do the functional change separately, and that regresses, you
don't have to throw out perfectly good refactoring changes when you
revert the functional change. Or maybe the refactoring change doesn't
revert anymore, and you'll have to do a more involved fix on top. It's
easy to do reverts of clearly regressing commits, even by people who
don't fully understand everything about the commit. Anything more is
harder. Not rocket science, but it just adds up to the burden of the
already swamped maintainers.
Usually, like here, you should do the non-functional refactoring first,
and then the functional change on top. The notable exception to this is
when the functional change is a fix, especially of the kind that may
need to get backported. Then you should do the fix first, even if it's
harder and more verbose that way, because you don't want to add a stable
backport dependency on a refactoring commit (which may exceed stable
patch limits) and the stable maintainers frown upon manually backported
patches.
> Fair enough, I've changed it to match PCI_BASE_CLASS_DISPLAY
> and sent it out as v5 a few minutes ago.
Please make that a v6 and split up the patch.
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Name the inner most per-engine intel_context struct
On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote: > >@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc, > > * for now who owns a GuC client. But for future owner of GuC > > * client, need to make sure lrc is pinned prior to enter here. > > */ > >-obj = ctx->engine[id].state; > >-if (!obj) > >+if (!ce->state) > > break; /* XXX: continue? */ > > > >-ctx_desc = intel_lr_context_descriptor(ctx, engine); > >-lrc->context_desc = (u32)ctx_desc; > >+lrc->context_desc = lower_32_bits(ce->lrc_desc); > > Could have kept use of intel_lr_context_descriptor for better separation. I was leaning the other way, since the code doesn't want intel_lr_context_descriptor() just happens to want to reuse some of the bits e.g. engine->ctx_desc_template | lrca i.e. lrc->context_desc != ce->lrc_desc and I would prefer it to be clarified as to exactly what the GuC expects. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Convert OpRegion ASLE irq worker into a tasklet
On Mon, 23 May 2016, Chris Wilson wrote: > On Mon, May 23, 2016 at 12:12:30PM +0300, Jani Nikula wrote: >> > #define ACPI_EV_DISPLAY_SWITCH (1<<0) >> > @@ -814,11 +807,11 @@ void intel_opregion_fini(struct drm_device *dev) >> >if (!opregion->header) >> >return; >> > >> > + tasklet_kill(&dev_priv->opregion.asle_task); >> > + >> >> So what if you got a new asle interrupt right here? > > Before we call fini, we should have de-installed the irq and done > synchronize_irq, so we only have to worry about the residual task. > (At least that is what I expect!) I'd expect that too, but looks like i915_driver_unload -> i915_driver_unregister -> intel_opregion_fini happens *before*, not after i915_driver_unload -> intel_modeset_cleanup -> intel_irq_uninstall J. > >> >if (opregion->asle) >> >opregion->asle->ardy = ASLE_ARDY_NOT_READY; >> >> This is supposed to signal we're not ready to handle said interrupts >> anymore. Not that we should rely on it either. >> >> It wasn't pretty before, but I think this patch widens the window for a >> race. If you kept the *other* code as it were, and just changed the work >> to tasklets, I'd be willing to look in the other direction... > > Considering the recent discussion about the negatives of > tasklets/ksoftirqd, I think I was being too cavalier in this conversion, > and we should only think about using tasklet where the post-interrupt > latency is critical. > -Chris -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Merge legacy+execlists context structs
On 22/05/16 14:02, Chris Wilson wrote:
struct intel_context contains two substructs, one for the legacy RCS and
one for every execlists engine. Since legacy RCS is a subset of the
execlists engine support, just combine the two substructs.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 41 +-
drivers/gpu/drm/i915/i915_drv.h | 7 ---
drivers/gpu/drm/i915/i915_gem_context.c | 75 +++--
drivers/gpu/drm/i915/intel_lrc.c| 26
drivers/gpu/drm/i915/intel_lrc.h| 1 -
5 files changed, 55 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 945fe4710b37..30cb26fe2fa9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -199,13 +199,6 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
}
-static void describe_ctx(struct seq_file *m, struct i915_gem_context *ctx)
-{
- seq_putc(m, ctx->legacy_hw_ctx.initialized ? 'I' : 'i');
- seq_putc(m, ctx->remap_slice ? 'R' : 'r');
- seq_putc(m, ' ');
-}
-
static int i915_gem_object_list_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -2001,7 +1994,6 @@ static int i915_context_status(struct seq_file *m, void
*unused)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
- enum intel_engine_id id;
int ret;
ret = mutex_lock_interruptible(&dev->struct_mutex);
@@ -2009,10 +2001,6 @@ static int i915_context_status(struct seq_file *m, void
*unused)
return ret;
list_for_each_entry(ctx, &dev_priv->context_list, link) {
- if (!i915.enable_execlists &&
- ctx->legacy_hw_ctx.rcs_state == NULL)
- continue;
-
seq_printf(m, "HW context %u ", ctx->hw_id);
if (IS_ERR(ctx->file_priv)) {
seq_puts(m, "(deleted) ");
@@ -2029,25 +2017,18 @@ static int i915_context_status(struct seq_file *m, void
*unused)
} else
seq_puts(m, "(kernel) ");
- describe_ctx(m, ctx);
+ seq_putc(m, ctx->remap_slice ? 'R' : 'r');
+ seq_putc(m, '\n');
- if (i915.enable_execlists) {
+ for_each_engine(engine, dev_priv) {
+ struct intel_context *ce = &ctx->engine[engine->id];
+ seq_printf(m, "%s: ", engine->name);
+ seq_putc(m, ce->initialised ? 'I' : 'i');
+ if (ce->state)
+ describe_obj(m, ce->state);
+ if (ce->ringbuf)
+ describe_ctx_ringbuf(m, ce->ringbuf);
seq_putc(m, '\n');
- for_each_engine_id(engine, dev_priv, id) {
- struct drm_i915_gem_object *ctx_obj =
- ctx->engine[id].state;
- struct intel_ringbuffer *ringbuf =
- ctx->engine[id].ringbuf;
-
- seq_printf(m, "%s: ", engine->name);
- if (ctx_obj)
- describe_obj(m, ctx_obj);
- if (ringbuf)
- describe_ctx_ringbuf(m, ringbuf);
- seq_putc(m, '\n');
- }
- } else {
- describe_obj(m, ctx->legacy_hw_ctx.rcs_state);
}
seq_putc(m, '\n');
@@ -2062,10 +2043,10 @@ static void i915_dump_lrc_obj(struct seq_file *m,
struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
+ struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
struct page *page;
uint32_t *reg_state;
int j;
- struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
unsigned long ggtt_offset = 0;
seq_printf(m, "CONTEXT: %s %u\n", engine->name, ctx->hw_id);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d3d2538d17e8..259a0ee7a601 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -862,13 +862,6 @@ struct i915_gem_context {
/* Unique identifier for this context, used by the hw for tracking */
unsigned hw_id;
- /* Legacy ring buffer submission */
- struct {
- struct drm_i915_gem_object *rcs_state;
- bool initialized;
- } legacy_hw_ctx;
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Rearrange i915_gem_context
On 22/05/16 14:02, Chris Wilson wrote:
Pack the integers and related types together inside the struct.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 259a0ee7a601..3b5cf15d85ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -829,7 +829,6 @@ struct i915_ctx_hang_stats {
/* This must match up with the value previously used for execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_HANDLE 0
-#define CONTEXT_NO_ZEROMAP (1<<0)
/**
* struct i915_gem_context - as the name implies, represents a context.
* @ref: reference count.
@@ -851,28 +850,31 @@ struct i915_ctx_hang_stats {
*/
struct i915_gem_context {
struct kref ref;
- int user_handle;
- uint8_t remap_slice;
struct drm_i915_private *i915;
- int flags;
struct drm_i915_file_private *file_priv;
- struct i915_ctx_hang_stats hang_stats;
struct i915_hw_ppgtt *ppgtt;
+ struct i915_ctx_hang_stats hang_stats;
+
/* Unique identifier for this context, used by the hw for tracking */
unsigned hw_id;
+ uint32_t user_handle;
+ unsigned long flags;
+#define CONTEXT_NO_ZEROMAP (1<<0)
struct intel_context {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
- int pin_count;
struct i915_vma *lrc_vma;
- u64 lrc_desc;
uint32_t *lrc_reg_state;
+ u64 lrc_desc;
+ int pin_count;
bool initialised;
} engine[I915_NUM_ENGINES];
struct list_head link;
+
+ uint8_t remap_slice;
};
enum fb_op_origin {
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Merge legacy+execlists context structs
On Mon, May 23, 2016 at 11:26:13AM +0100, Tvrtko Ursulin wrote:
> >@@ -400,7 +412,7 @@ int i915_gem_context_init(struct drm_device *dev)
> > return PTR_ERR(ctx);
> > }
> >
> >-if (ctx->legacy_hw_ctx.rcs_state) {
> >+if (ctx->engine[RCS].state) {
>
> Maybe now put a comment saying this is for legacy now, to make the
> asymmetry in ctx pinning paths between the two stick out more.
Good point. This needs the i915.enable_execlists markup. Ultimately, I
think we should move the pin/unpin into the legacy engine setup for
symmetry with execlists (and killing off one more pair of
i915.enable_execlists).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/drv_module_reload_basic: Don't use rmmod exit code when reloading the module.
On Fri, May 20, 2016 at 05:23:56PM +0100, Chris Wilson wrote:
> On Fri, May 20, 2016 at 07:00:18PM +0300, Imre Deak wrote:
> > On pe, 2016-05-20 at 18:20 +0300, Marius Vlad wrote:
> > > Either we return $IGT_EXIT_FAILURE or remove it entirely (like in
> > > this
> > > patch). If rmmod returns non-zero (i.e., Module: i915 is still in
> > > use), reload
> > > will bail with $IGT_EXIT_SKIP, making the check with lsmod useless.
> > > Also use the return value in the fault-injection loop.
> > >
> > > Signed-off-by: Marius Vlad
> > > ---
> > > tests/drv_module_reload_basic | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tests/drv_module_reload_basic
> > > b/tests/drv_module_reload_basic
> > > index 3bba796..3a8df33 100755
> > > --- a/tests/drv_module_reload_basic
> > > +++ b/tests/drv_module_reload_basic
> > > @@ -30,7 +30,7 @@ function reload() {
> > >
> > > #ignore errors in ips - gen5 only
> > > rmmod intel_ips &> /dev/null
> > > - rmmod i915 || return $IGT_EXIT_SKIP
> > > + rmmod i915
> >
> > Not sure what was the reason to bail out here, continuing seems like
> > the correct thing to do.
>
> If we can't unload, we can perform the modprobe testing. The system is
> not in a state suitable for testing so skip or fail. If we are certain
> that the rmmod failure is a bug, fail, if it merely something like the
> system doesn't support module unloading, skip.
I've seen this couple of times in the CI...and went mostly mostly
unnoticed, wanted to make it hard-fail so it easy to spot when it happens
again. Although it might be cases where the module is built-in this is
not the case in CI.
>
> Continuing on after failure to unload is not a good idea.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 01/12] drm: Add missing DP downstream port types
Add missing DisplayPort downstream port types. The introduced new port types are DP++ and Wireless. Signed-off-by: Mika Kahola --- include/drm/drm_dp_helper.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 5a848e7..e384c7f 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -211,6 +211,8 @@ # define DP_DS_PORT_TYPE_DVI 2 # define DP_DS_PORT_TYPE_HDMI 3 # define DP_DS_PORT_TYPE_NON_EDID 4 +# define DP_DS_PORT_TYPE_DP_DUALMODE5 +# define DP_DS_PORT_TYPE_WIRELESS 6 # define DP_DS_PORT_HPD(1 << 3) /* offset 1 for VGA is maximum megapixels per second / 8 */ /* offset 2 */ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 02/12] drm: Read DPCD receiver capability for DP to VGA converter
Read from DPCD receiver capability field the max allowed
pixel clock and bits per component for DP to VGA converter.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 46
drivers/gpu/drm/i915/intel_drv.h | 2 ++
include/drm/drm_dp_helper.h | 21 ++
3 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eeaf5a7..c5bec6f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -412,6 +412,52 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux, struct
drm_dp_link *link)
}
EXPORT_SYMBOL(drm_dp_link_power_down);
+/*
+ * drm_dp_bd() - read DisplayPort Receiver Capability Fields for
+ * DP branch devices
+ * @aux: DisplayPort AUX channel
+ * @bd: pointer to a structure containing DP branch device information
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
+{
+ uint8_t info[4];
+ uint8_t dfp;
+ bool detailed_cap_info;
+ int err, size;
+
+ err = drm_dp_dpcd_read(aux, DP_DOWNSTREAMPORT_PRESENT, &dfp,
sizeof(dfp));
+ if (err < 0)
+ return err;
+
+ bd->present = dfp & 0x1;
+
+ if (!bd->present)
+ return 0;
+
+ detailed_cap_info = dfp & DP_DETAILED_CAP_INFO_AVAILABLE;
+
+ size = detailed_cap_info ? 4 : 1;
+
+ err = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, info, size);
+ if (err < 0)
+ return err;
+
+ bd->type = info[0] & DP_DS_PORT_TYPE_MASK;
+ bd->hpd = info[0] & DP_DS_PORT_HPD;
+
+ if (detailed_cap_info) {
+ if (bd->type & DP_DS_PORT_TYPE_VGA) {
+ bd->dfp.vga.dot_clk = info[1] * 8 * 1000;
+ bd->dfp.vga.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_bd);
+
/**
* drm_dp_link_configure() - configure a DisplayPort link
* @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0741b2d..f85914b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -886,6 +886,8 @@ struct intel_dp {
bool train_set_valid;
+ struct drm_dp_bd bd;
+
/* Displayport compliance testing */
unsigned long compliance_test_type;
unsigned long compliance_test_data;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e384c7f..d3e78a5 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -802,10 +802,31 @@ struct drm_dp_link {
unsigned long capabilities;
};
+/*
+ * DP to VGA
+ */
+struct drm_dp_vga {
+ int dot_clk;
+ uint8_t bpc;
+};
+
+/*
+ * Branch device
+ */
+struct drm_dp_bd {
+ bool present;
+ int type;
+ bool hpd;
+ union {
+ struct drm_dp_vga vga;
+ } dfp;
+};
+
int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
+int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd);
int drm_dp_aux_register(struct drm_dp_aux *aux);
void drm_dp_aux_unregister(struct drm_dp_aux *aux);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 00/12] drm/i915: DP branch devices
Prep work for DP branch device handling This series of patches reads DPCD register 0x80h for receiver capabilities for DP branch devices. The branch device types are converters for the following standards - DP to VGA - DP to DVI - DP to HDMI - DP++ dual mode - Wireless WiGig DPCD register defines max pixel rate for VGA dongles. This check is carried out during mode validation. What's new in the series: - Readout of branch device ID, HW, and SW revisions from DPCD register Acronyms: BD Brand Device DFPDownstream-Facing Port v2: DPCD register read outs moved to drm (Ville, Daniel) v3: Max pixel rate computation moved to drm (Daniel) Mika Kahola (12): drm: Add missing DP downstream port types drm: Read DPCD receiver capability for DP to VGA converter drm: Read DPCD receiver capability for DP to DVI converter drm: Read DPCD receiver capability for DP to HDMI converter drm: Read DPCD receiver capability for DP++ drm: Read DPCD receiver capability for DP to Wireless Converter drm: Compute max pixel rate for DP sink drm/i915: Check pixel rate for DP to VGA dongle drm/i915: Read DP branch device id drm/i915: Read DP branch device HW revision drm/i915: Read DP branch device SW revision drm/i915: Add DP branch device info on debugfs drivers/gpu/drm/drm_dp_helper.c | 92 + drivers/gpu/drm/i915/i915_debugfs.c | 37 +++ drivers/gpu/drm/i915/intel_dp.c | 23 ++ drivers/gpu/drm/i915/intel_drv.h| 2 + include/drm/drm_dp_helper.h | 86 ++ 5 files changed, 240 insertions(+) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 08/12] drm/i915: Check pixel rate for DP to VGA dongle
Prep work to improve DP branch device handling.
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rate divided by 8 in MP/s.
v2: DPCD read outs and computation moved to drm (Ville, Daniel)
v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
function (Daniel)
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cccf9bc..5e16063 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -201,6 +201,8 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+ max_dotclk = drm_dp_max_sink_dotclock(max_dotclk, &intel_dp->bd);
+
if (is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
@@ -4576,6 +4578,7 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
struct drm_i915_private *dev_priv = dev->dev_private;
enum intel_display_power_domain power_domain;
enum irqreturn ret = IRQ_NONE;
+ int err;
if (intel_dig_port->base.type != INTEL_OUTPUT_EDP &&
intel_dig_port->base.type != INTEL_OUTPUT_HDMI)
@@ -4600,6 +4603,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
power_domain = intel_display_port_aux_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
+ err = drm_dp_bd(&intel_dp->aux, &intel_dp->bd);
+ if (err < 0)
+ DRM_DEBUG_KMS("error reading DPCD[0x80] for DP branch
device\n");
+
if (long_hpd) {
/* indicate that we need to restart link training */
intel_dp->train_set_valid = false;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 03/12] drm: Read DPCD receiver capability for DP to DVI converter
Read from DPCD receiver capability field for the following
features:
- max TMDS clock rate
- max bits per component
- single or dual link support
- high color depth support
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 5 +
include/drm/drm_dp_helper.h | 14 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c5bec6f..f5cf706 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -451,6 +451,11 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
if (bd->type & DP_DS_PORT_TYPE_VGA) {
bd->dfp.vga.dot_clk = info[1] * 8 * 1000;
bd->dfp.vga.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+ } else if (bd->type & DP_DS_PORT_TYPE_DVI) {
+ bd->dfp.dvi.tmds_clk = info[1] * 2500;
+ bd->dfp.dvi.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+ bd->dfp.dvi.dual_link = info[3] & DP_DS_DVI_DUAL_LINK;
+ bd->dfp.dvi.hi_color_depth = info[3] &
DP_DS_DVI_HI_COLOR_DEPTH;
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index d3e78a5..1a4e131 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -221,6 +221,9 @@
# define DP_DS_VGA_10BPC 1
# define DP_DS_VGA_12BPC 2
# define DP_DS_VGA_16BPC 3
+/* offset 3 for DVI dual link and high color depth */
+# define DP_DS_DVI_DUAL_LINK(1<<1)
+# define DP_DS_DVI_HI_COLOR_DEPTH (1<<2)
/* link configuration */
#defineDP_LINK_BW_SET 0x100
@@ -811,6 +814,16 @@ struct drm_dp_vga {
};
/*
+ * DP to DVI
+ */
+struct drm_dp_dvi {
+ int tmds_clk;
+ uint8_t bpc;
+ bool dual_link;
+ bool hi_color_depth;
+};
+
+/*
* Branch device
*/
struct drm_dp_bd {
@@ -819,6 +832,7 @@ struct drm_dp_bd {
bool hpd;
union {
struct drm_dp_vga vga;
+ struct drm_dp_dvi dvi;
} dfp;
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 06/12] drm: Read DPCD receiver capability for DP to Wireless Converter
Read from DPCD receiver capability field for the
DP to Wireless converter. The only supported wireless
technology on DP1.3 spec is WiGig display extension. If WiGig
display extension is present, then read out the
- number of wde tx on device
- the number of wde txs that can be concurrently active
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 7 +++
include/drm/drm_dp_helper.h | 13 +
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f98e4be..2c91771 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -468,6 +468,13 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
bd->dfp.dual_mode.tmds_clk = info[1] * 2500;
bd->dfp.dual_mode.bpc = info[2] &
DP_DS_VGA_MAX_BPC_MASK;
bd->dfp.dual_mode.frame_seq_to_frame_pack = info[3] &
FRAME_SEQ_TO_FRAME_PACK;
+ } else if (bd->type & DP_DS_PORT_TYPE_WIRELESS) {
+ bd->dfp.wireless.wireless_tech = info[1] &
DP_DS_WIRELESS_TECH_MASK;
+
+ if (bd->dfp.wireless.wireless_tech == 0x0) {
+ bd->dfp.wireless.number_of_wde_tx_on_device =
info[2] & WIRELESS_MASK;
+ bd->dfp.wireless.wde_tx_concurrency_cap =
(info[2]>>2) & WIRELESS_MASK;
+ }
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index adf05a1..831f944 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -230,6 +230,9 @@
# define YCBCR420_PASS_THROUGH (1<<2)
# define YCBCR444_TO_YCBCR422 (1<<3)
# define YCBCR444_TO_YCBCR420 (1<<4)
+/* offset 3 for Wireless */
+# define DP_DS_WIRELESS_TECH_MASK 0xf
+# define WIRELESS_MASK 3
/* link configuration */
#defineDP_LINK_BW_SET 0x100
@@ -851,6 +854,15 @@ struct drm_dp_dual_mode {
};
/*
+ * DP to Wireless
+ */
+struct drm_dp_wireless {
+ int wireless_tech;
+ int number_of_wde_tx_on_device;
+ int wde_tx_concurrency_cap;
+};
+
+/*
* Branch device
*/
struct drm_dp_bd {
@@ -862,6 +874,7 @@ struct drm_dp_bd {
struct drm_dp_dvi dvi;
struct drm_dp_hdmi hdmi;
struct drm_dp_dual_mode dual_mode;
+ struct drm_dp_wireless wireless;
} dfp;
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 09/12] drm/i915: Read DP branch device id
Read device ID for DisplayPort branch devices. The device
ID is defined in DPCD register 0x503 and it is mandatory field
for DP branch devices.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5e16063..2b768da 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3458,6 +3458,12 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
if (drm_dp_dpcd_read(&intel_dp->aux, DP_BRANCH_OUI, buf, 3) == 3)
DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
buf[0], buf[1], buf[2]);
+
+ if (intel_dp->bd.present) {
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_BRANCH_ID,
intel_dp->bd.id,
+sizeof(intel_dp->bd.id)) ==
sizeof(intel_dp->bd.id))
+ DRM_DEBUG_KMS("Device ID: %s\n", intel_dp->bd.id);
+ }
}
static bool
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ee4084d..f1fc4e2 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -457,6 +457,7 @@
#define DP_SOURCE_OUI 0x300
#define DP_SINK_OUI0x400
#define DP_BRANCH_OUI 0x500
+#define DP_BRANCH_ID0x503
#define DP_SET_POWER0x600
# define DP_SET_POWER_D00x1
@@ -869,6 +870,7 @@ struct drm_dp_bd {
bool present;
int type;
bool hpd;
+ uint8_t id[6];
union {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 04/12] drm: Read DPCD receiver capability for DP to HDMI converter
Read from DPCD receiver capability field for DP to HDMI
converter. The features for DP to HDMI converter are
- max TMDS characther clock rate
- max bits per component
- support for conversion from 3D frame sequential to frame pack
- support for YCBCR422 pass through
- support for YCBCR420 pass through
- support for conversion from YCBCR444 to YCBCR422
- support for conversion from YCBCR444 to YCBCR420
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 8
include/drm/drm_dp_helper.h | 19 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f5cf706..ccd0fcb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -456,6 +456,14 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
bd->dfp.dvi.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
bd->dfp.dvi.dual_link = info[3] & DP_DS_DVI_DUAL_LINK;
bd->dfp.dvi.hi_color_depth = info[3] &
DP_DS_DVI_HI_COLOR_DEPTH;
+ } else if (bd->type & DP_DS_PORT_TYPE_HDMI) {
+ bd->dfp.hdmi.tmds_clk = info[1] * 2500;
+ bd->dfp.hdmi.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+ bd->dfp.hdmi.frame_seq_to_frame_pack = info[3] &
FRAME_SEQ_TO_FRAME_PACK;
+ bd->dfp.hdmi.ycbcr422_pass_through = info[3] &
YCBCR422_PASS_THROUGH;
+ bd->dfp.hdmi.ycbcr420_pass_through = info[3] &
YCBCR420_PASS_THROUGH;
+ bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr422 =
info[3] & YCBCR444_TO_YCBCR422;
+ bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr420 =
info[3] & YCBCR444_TO_YCBCR420;
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1a4e131..b8c4960 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -224,6 +224,12 @@
/* offset 3 for DVI dual link and high color depth */
# define DP_DS_DVI_DUAL_LINK(1<<1)
# define DP_DS_DVI_HI_COLOR_DEPTH (1<<2)
+/* offset 3 for HDMI */
+# define FRAME_SEQ_TO_FRAME_PACK(1<<0)
+# define YCBCR422_PASS_THROUGH (1<<1)
+# define YCBCR420_PASS_THROUGH (1<<2)
+# define YCBCR444_TO_YCBCR422 (1<<3)
+# define YCBCR444_TO_YCBCR420 (1<<4)
/* link configuration */
#defineDP_LINK_BW_SET 0x100
@@ -822,6 +828,18 @@ struct drm_dp_dvi {
bool dual_link;
bool hi_color_depth;
};
+/*
+ * DP to HDMI
+ */
+struct drm_dp_hdmi {
+ int tmds_clk;
+ uint8_t bpc;
+ bool frame_seq_to_frame_pack;
+ bool ycbcr422_pass_through;
+ bool ycbcr420_pass_through;
+ bool conversion_from_ycbcr444_to_ycbcr422;
+ bool conversion_from_ycbcr444_to_ycbcr420;
+};
/*
* Branch device
@@ -833,6 +851,7 @@ struct drm_dp_bd {
union {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
+ struct drm_dp_hdmi hdmi;
} dfp;
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 05/12] drm: Read DPCD receiver capability for DP++
Read from DPCD receiver capability field for the
DP++ devices. The features are
- max TMDS charachter clock
- max bits per component
- support for conversion from 3D frame sequential to
frame pack
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 4
include/drm/drm_dp_helper.h | 10 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ccd0fcb..f98e4be 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -464,6 +464,10 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
bd->dfp.hdmi.ycbcr420_pass_through = info[3] &
YCBCR420_PASS_THROUGH;
bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr422 =
info[3] & YCBCR444_TO_YCBCR422;
bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr420 =
info[3] & YCBCR444_TO_YCBCR420;
+ } else if (bd->type & DP_DS_PORT_TYPE_DP_DUALMODE) {
+ bd->dfp.dual_mode.tmds_clk = info[1] * 2500;
+ bd->dfp.dual_mode.bpc = info[2] &
DP_DS_VGA_MAX_BPC_MASK;
+ bd->dfp.dual_mode.frame_seq_to_frame_pack = info[3] &
FRAME_SEQ_TO_FRAME_PACK;
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index b8c4960..adf05a1 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -842,6 +842,15 @@ struct drm_dp_hdmi {
};
/*
+ * DP to DP++
+ */
+struct drm_dp_dual_mode {
+ int tmds_clk;
+ uint8_t bpc;
+ bool frame_seq_to_frame_pack;
+};
+
+/*
* Branch device
*/
struct drm_dp_bd {
@@ -852,6 +861,7 @@ struct drm_dp_bd {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
struct drm_dp_hdmi hdmi;
+ struct drm_dp_dual_mode dual_mode;
} dfp;
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 12/12] drm/i915: Add DP branch device info on debugfs
Read DisplayPort branch device info from through debugfs
interface.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_debugfs.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4c6b48d..74c6aa2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2923,6 +2923,43 @@ static void intel_dp_info(struct seq_file *m,
seq_printf(m, "\tDPCD rev: %x\n", intel_dp->dpcd[DP_DPCD_REV]);
seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
+ seq_printf(m, "\tbranch device: %s\n", yesno(intel_dp->bd.present));
+
+ if (intel_dp->bd.present) {
+ switch (intel_dp->bd.type) {
+ case DP_DS_PORT_TYPE_DP:
+ seq_printf(m, "\ttype: DisplayPort\n");
+ break;
+ case DP_DS_PORT_TYPE_VGA:
+ seq_printf(m, "\ttype: VGA\n");
+ break;
+ case DP_DS_PORT_TYPE_DVI:
+ seq_printf(m, "\ttype: DVI\n");
+ break;
+ case DP_DS_PORT_TYPE_HDMI:
+ seq_printf(m, "\ttype: HDMI\n");
+ break;
+ case DP_DS_PORT_TYPE_NON_EDID:
+ seq_printf(m, "\ttype: others without EDID support\n");
+ break;
+ case DP_DS_PORT_TYPE_DP_DUALMODE:
+ seq_printf(m, "\ttype: DP++\n");
+ break;
+ case DP_DS_PORT_TYPE_WIRELESS:
+ seq_printf(m, "\ttype: Wireless\n");
+ break;
+ default:
+ seq_printf(m, "\ttype: N/A\n");
+ }
+
+ seq_printf(m, "\tHPD aware: %s\n", yesno(intel_dp->bd.hpd));
+ seq_printf(m, "\tDevice id: %s\n", intel_dp->bd.id);
+ seq_printf(m, "\tHW revision: %.2d.%.2d\n",
+ intel_dp->bd.hw_rev & 0xf, (intel_dp->bd.hw_rev>>4)
& 0xf);
+ seq_printf(m, "\tSW revision: %.2d.%.2d\n",
+ intel_dp->bd.sw_rev[0], intel_dp->bd.sw_rev[1]);
+ }
+
if (intel_encoder->type == INTEL_OUTPUT_EDP)
intel_panel_info(m, &intel_connector->panel);
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 07/12] drm: Compute max pixel rate for DP sink
For DP branch devices DPCD register may define the max supported
pixel rate for VGA dongles. This patch adds a check if DPCD register
value is less than current setting for pixel rate.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 22 ++
include/drm/drm_dp_helper.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2c91771..b222aa0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -413,6 +413,28 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux, struct
drm_dp_link *link)
EXPORT_SYMBOL(drm_dp_link_power_down);
/*
+ * drm_dp_max_sink_dotclock() - Compute max pixel rate
+ * @dotclk: reference pixel rate
+ * @bd: pointer to a structure containing DP branch device information
+ *
+ * Returns max supported pixel rate.
+ */
+int drm_dp_max_sink_dotclock(int dotclk, struct drm_dp_bd *bd)
+{
+ int max_dotclk = dotclk;
+
+ /* DP to VGA dongle may define max pixel rate in DPCD */
+ if (bd->present) {
+ if ((bd->type & DP_DS_PORT_TYPE_VGA) &&
+ (bd->dfp.vga.dot_clk > 0))
+ max_dotclk = min(dotclk, bd->dfp.vga.dot_clk);
+ }
+
+ return max_dotclk;
+}
+EXPORT_SYMBOL(drm_dp_max_sink_dotclock);
+
+/*
* drm_dp_bd() - read DisplayPort Receiver Capability Fields for
* DP branch devices
* @aux: DisplayPort AUX channel
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 831f944..ee4084d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -882,6 +882,7 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link);
int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
+int drm_dp_max_sink_dotclock(int dotclk, struct drm_dp_bd *bd);
int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd);
int drm_dp_aux_register(struct drm_dp_aux *aux);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 10/12] drm/i915: Read DP branch device HW revision
HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2b768da..12ab26b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3463,6 +3463,11 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
if (drm_dp_dpcd_read(&intel_dp->aux, DP_BRANCH_ID,
intel_dp->bd.id,
sizeof(intel_dp->bd.id)) ==
sizeof(intel_dp->bd.id))
DRM_DEBUG_KMS("Device ID: %s\n", intel_dp->bd.id);
+
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_BRANCH_HW_REV,
&intel_dp->bd.hw_rev,
+sizeof(intel_dp->bd.hw_rev)) ==
sizeof(intel_dp->bd.hw_rev))
+ DRM_DEBUG_KMS("HW revision: %.2d.%.2d\n",
+ intel_dp->bd.hw_rev & 0xf,
(intel_dp->bd.hw_rev>>4) & 0xf);
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f1fc4e2..d0965ca 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -458,6 +458,7 @@
#define DP_SINK_OUI0x400
#define DP_BRANCH_OUI 0x500
#define DP_BRANCH_ID0x503
+#define DP_BRANCH_HW_REV0x509
#define DP_SET_POWER0x600
# define DP_SET_POWER_D00x1
@@ -871,6 +872,7 @@ struct drm_dp_bd {
int type;
bool hpd;
uint8_t id[6];
+ uint8_t hw_rev;
union {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 11/12] drm/i915: Read DP branch device SW revision
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x50A.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 12ab26b..7e50d32 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3468,6 +3468,11 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
sizeof(intel_dp->bd.hw_rev)) ==
sizeof(intel_dp->bd.hw_rev))
DRM_DEBUG_KMS("HW revision: %.2d.%.2d\n",
intel_dp->bd.hw_rev & 0xf,
(intel_dp->bd.hw_rev>>4) & 0xf);
+
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_BRANCH_SW_REV,
intel_dp->bd.sw_rev,
+sizeof(intel_dp->bd.sw_rev)) ==
sizeof(intel_dp->bd.sw_rev))
+ DRM_DEBUG_KMS("SW revision: %.2d.%.2d\n",
+ intel_dp->bd.sw_rev[0],
intel_dp->bd.sw_rev[1]);
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index d0965ca..c0ca0c9 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -459,6 +459,7 @@
#define DP_BRANCH_OUI 0x500
#define DP_BRANCH_ID0x503
#define DP_BRANCH_HW_REV0x509
+#define DP_BRANCH_SW_REV0x50A
#define DP_SET_POWER0x600
# define DP_SET_POWER_D00x1
@@ -873,6 +874,7 @@ struct drm_dp_bd {
bool hpd;
uint8_t id[6];
uint8_t hw_rev;
+ uint8_t sw_rev[2];
union {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Name the inner most per-engine intel_context struct
On 23/05/16 11:17, Chris Wilson wrote: On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote: @@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc, * for now who owns a GuC client. But for future owner of GuC * client, need to make sure lrc is pinned prior to enter here. */ - obj = ctx->engine[id].state; - if (!obj) + if (!ce->state) break; /* XXX: continue? */ - ctx_desc = intel_lr_context_descriptor(ctx, engine); - lrc->context_desc = (u32)ctx_desc; + lrc->context_desc = lower_32_bits(ce->lrc_desc); Could have kept use of intel_lr_context_descriptor for better separation. I was leaning the other way, since the code doesn't want intel_lr_context_descriptor() just happens to want to reuse some of the bits e.g. engine->ctx_desc_template | lrca Thats true, but it was at least using an exported function with documented content, rather than directly fishing out stuff from essentially private data elsewhere. i.e. lrc->context_desc != ce->lrc_desc and I would prefer it to be clarified as to exactly what the GuC expects. Yes that would be best. Cc-ed Dave for when he is back to comment what does GuC really wants in there. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Name the inner most per-engine intel_context struct
On Mon, May 23, 2016 at 11:55:16AM +0100, Tvrtko Ursulin wrote: > > On 23/05/16 11:17, Chris Wilson wrote: > >On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote: > >>>@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc, > >>>* for now who owns a GuC client. But for future owner of GuC > >>>* client, need to make sure lrc is pinned prior to enter here. > >>>*/ > >>>- obj = ctx->engine[id].state; > >>>- if (!obj) > >>>+ if (!ce->state) > >>> break; /* XXX: continue? */ > >>> > >>>- ctx_desc = intel_lr_context_descriptor(ctx, engine); > >>>- lrc->context_desc = (u32)ctx_desc; > >>>+ lrc->context_desc = lower_32_bits(ce->lrc_desc); > >> > >>Could have kept use of intel_lr_context_descriptor for better separation. > > > >I was leaning the other way, since the code doesn't want > >intel_lr_context_descriptor() just happens to want to reuse some of the > >bits e.g. engine->ctx_desc_template | lrca > > Thats true, but it was at least using an exported function with > documented content, rather than directly fishing out stuff from > essentially private data elsewhere. It's still fishing out essentially private data though :) If engine->ctx_desc_template considers GuC for its set of flags, it is purely by happenstance. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: DP branch devices (rev3)
== Series Details == Series: drm/i915: DP branch devices (rev3) URL : https://patchwork.freedesktop.org/series/6658/ State : success == Summary == Series 6658v3 drm/i915: DP branch devices http://patchwork.freedesktop.org/api/1.0/series/6658/revisions/3/mbox Test gem_exec_flush: Subgroup basic-batch-kernel-default-cmd: fail -> PASS (ro-byt-n2820) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (ro-bdw-i7-5600u) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (ro-ivb-i7-3770) Test kms_sink_crc_basic: skip -> PASS (ro-skl-i7-6700hq) fi-bdw-i7-5557u total:209 pass:197 dwarn:0 dfail:0 fail:0 skip:12 fi-bsw-n3050 total:209 pass:167 dwarn:0 dfail:0 fail:2 skip:40 fi-hsw-i7-4770k total:209 pass:190 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-i7-4770r total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 fi-skl-i5-6260u total:209 pass:198 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-i7-6700k total:209 pass:184 dwarn:0 dfail:0 fail:0 skip:25 fi-snb-i7-2600 total:209 pass:170 dwarn:0 dfail:0 fail:0 skip:39 ro-bdw-i5-5250u total:209 pass:172 dwarn:0 dfail:0 fail:0 skip:37 ro-bdw-i7-5557U total:209 pass:197 dwarn:0 dfail:0 fail:0 skip:12 ro-bdw-i7-5600u total:209 pass:180 dwarn:0 dfail:0 fail:1 skip:28 ro-bsw-n3050 total:209 pass:168 dwarn:0 dfail:0 fail:2 skip:39 ro-byt-n2820 total:209 pass:170 dwarn:0 dfail:0 fail:2 skip:37 ro-hsw-i3-4010u total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-hsw-i7-4770r total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk-i7-620lm total:209 pass:146 dwarn:0 dfail:0 fail:1 skip:62 ro-ilk1-i5-650 total:204 pass:146 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:209 pass:177 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:209 pass:181 dwarn:0 dfail:0 fail:0 skip:28 ro-skl-i7-6700hq total:204 pass:183 dwarn:0 dfail:0 fail:0 skip:21 ro-snb-i7-2620M total:209 pass:170 dwarn:0 dfail:0 fail:1 skip:38 fi-byt-n2820 failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_968/ eaa075a drm-intel-nightly: 2016y-05m-23d-08h-23m-34s UTC integration manifest 337a561 drm/i915: Add DP branch device info on debugfs 25f58c3 drm/i915: Read DP branch device SW revision 5a103c3 drm/i915: Read DP branch device HW revision 127ce17 drm/i915: Read DP branch device id 7c53d0d drm/i915: Check pixel rate for DP to VGA dongle 595beaf drm: Compute max pixel rate for DP sink 27394e7 drm: Read DPCD receiver capability for DP to Wireless Converter 3042dee drm: Read DPCD receiver capability for DP++ 9ffd4f3 drm: Read DPCD receiver capability for DP to HDMI converter bdb3668 drm: Read DPCD receiver capability for DP to DVI converter 92548e2 drm: Read DPCD receiver capability for DP to VGA converter 722a92f drm: Add missing DP downstream port types ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/11] drm/i915: Rename i915_gem_context_reference/unreference()
As these are wrappers around kref_get/kref_put() it is preferable to
follow the naming convention and use the same verb get/put in our
wrapper names for manipulating a reference to the context.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h| 6 --
drivers/gpu/drm/i915/i915_gem.c| 7 +++
drivers/gpu/drm/i915/i915_gem_context.c| 22 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++---
drivers/gpu/drm/i915/intel_lrc.c | 4 ++--
5 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d162bf86db7e..ce5e92ce9652 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3435,12 +3435,14 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
-static inline void i915_gem_context_reference(struct i915_gem_context *ctx)
+static inline struct i915_gem_context *
+i915_gem_context_get(struct i915_gem_context *ctx)
{
kref_get(&ctx->ref);
+ return ctx;
}
-static inline void i915_gem_context_unreference(struct i915_gem_context *ctx)
+static inline void i915_gem_context_put(struct i915_gem_context *ctx)
{
lockdep_assert_held(&ctx->i915->dev->struct_mutex);
kref_put(&ctx->ref, i915_gem_context_free);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 728b66911840..d7ae030e5a0b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1418,7 +1418,7 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
request->engine);
}
- i915_gem_context_unreference(request->ctx);
+ i915_gem_context_put(request->ctx);
i915_gem_request_unreference(request);
}
@@ -2775,8 +2775,7 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
req->i915 = dev_priv;
req->engine = engine;
req->reset_counter = reset_counter;
- req->ctx = ctx;
- i915_gem_context_reference(req->ctx);
+ req->ctx = i915_gem_context_get(ctx);
/*
* Reserve space in the ring buffer for all the commands required to
@@ -2798,7 +2797,7 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
return 0;
err_ctx:
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
err:
kmem_cache_free(dev_priv->requests, req);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index aa329175f73a..a4c6377eea32 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -290,7 +290,7 @@ __create_hw_context(struct drm_device *dev,
return ctx;
err_out:
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
return ERR_PTR(ret);
}
@@ -351,7 +351,7 @@ err_unpin:
i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
err_destroy:
idr_remove(&file_priv->context_idr, ctx->user_handle);
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
return ERR_PTR(ret);
}
@@ -363,7 +363,7 @@ static void i915_gem_context_unpin(struct i915_gem_context
*ctx,
} else {
if (engine->id == RCS && ctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
}
}
@@ -463,7 +463,7 @@ void i915_gem_context_fini(struct drm_device *dev)
if (dctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
- i915_gem_context_unreference(dctx);
+ i915_gem_context_put(dctx);
dev_priv->kernel_context = NULL;
ida_destroy(&dev_priv->context_hw_ida);
@@ -473,7 +473,7 @@ static int context_idr_cleanup(int id, void *p, void *data)
{
struct i915_gem_context *ctx = p;
- i915_gem_context_unreference(ctx);
+ i915_gem_context_put(ctx);
return 0;
}
@@ -785,10 +785,9 @@ static int do_rcs_switch(struct drm_i915_gem_request *req)
/* obj is kept alive until the next request by its active ref */
i915_gem_object_ggtt_unpin(from->legacy_hw_ctx.rcs_state);
- i915_gem_context_unreference(from);
+ i915_gem_context_put(from);
}
- i915_gem_context_reference(to);
- engine->last_context = to;
+ engine->last_context = i915_gem_context_get(to);
/* GEN8 does *not* require an explicit reload if the PDPs have been
* setup, and we do not wish to move them.
@@ -873,10 +872,9 @@ int i915_switch_context(struct drm_i915_gem_request *req)
}
[Intel-gfx] Context churn
The essence of this series is to just rename the anonymous struct inside intel_context. But since it involves churn, I added some sweetner into the miex (and more churn)! [PATCH v2 04/11] drm/i915: Rename i915_gem_context_reference/unreference() Long term plan is to migrate all of our reference manipulation over to the core kref_get/kref_put idiom. Whilst I was changing contexts, adding the churn here seemed sensible. Wants somebody to second my crazy plan for consistent naming. [PATCH v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context Tvrtko spotted a missed idr_remove on an error path, v2 needs an r-b. [PATCH v2 07/11] drm/i915: Show i915_gem_context owner in debugfs Tvrtko spotted that we never mark the file_priv as closed, brought that earlier in the queue (to this v2). [PATCH v2 10/11] drm/i915: Rearrange i915_gem_context Tvrkto has r-b this, I've just managed to forget to add it. [PATCH v2 11/11] drm/i915: Show context objects in Any takers? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/11] drm/i915: Merge legacy+execlists context structs
struct intel_context contains two substructs, one for the legacy RCS and
one for every execlists engine. Since legacy RCS is a subset of the
execlists engine support, just combine the two substructs.
v2: Only pin the default context for legacy mode (the object only exists
for legacy, but adding i915.enable_execlists provides symmetry with the
cleanup functions).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 41 +-
drivers/gpu/drm/i915/i915_drv.h | 7 ---
drivers/gpu/drm/i915/i915_gem_context.c | 75 +++--
drivers/gpu/drm/i915/intel_lrc.c| 26
drivers/gpu/drm/i915/intel_lrc.h| 1 -
5 files changed, 55 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 945fe4710b37..30cb26fe2fa9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -199,13 +199,6 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
}
-static void describe_ctx(struct seq_file *m, struct i915_gem_context *ctx)
-{
- seq_putc(m, ctx->legacy_hw_ctx.initialized ? 'I' : 'i');
- seq_putc(m, ctx->remap_slice ? 'R' : 'r');
- seq_putc(m, ' ');
-}
-
static int i915_gem_object_list_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -2001,7 +1994,6 @@ static int i915_context_status(struct seq_file *m, void
*unused)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
- enum intel_engine_id id;
int ret;
ret = mutex_lock_interruptible(&dev->struct_mutex);
@@ -2009,10 +2001,6 @@ static int i915_context_status(struct seq_file *m, void
*unused)
return ret;
list_for_each_entry(ctx, &dev_priv->context_list, link) {
- if (!i915.enable_execlists &&
- ctx->legacy_hw_ctx.rcs_state == NULL)
- continue;
-
seq_printf(m, "HW context %u ", ctx->hw_id);
if (IS_ERR(ctx->file_priv)) {
seq_puts(m, "(deleted) ");
@@ -2029,25 +2017,18 @@ static int i915_context_status(struct seq_file *m, void
*unused)
} else
seq_puts(m, "(kernel) ");
- describe_ctx(m, ctx);
+ seq_putc(m, ctx->remap_slice ? 'R' : 'r');
+ seq_putc(m, '\n');
- if (i915.enable_execlists) {
+ for_each_engine(engine, dev_priv) {
+ struct intel_context *ce = &ctx->engine[engine->id];
+ seq_printf(m, "%s: ", engine->name);
+ seq_putc(m, ce->initialised ? 'I' : 'i');
+ if (ce->state)
+ describe_obj(m, ce->state);
+ if (ce->ringbuf)
+ describe_ctx_ringbuf(m, ce->ringbuf);
seq_putc(m, '\n');
- for_each_engine_id(engine, dev_priv, id) {
- struct drm_i915_gem_object *ctx_obj =
- ctx->engine[id].state;
- struct intel_ringbuffer *ringbuf =
- ctx->engine[id].ringbuf;
-
- seq_printf(m, "%s: ", engine->name);
- if (ctx_obj)
- describe_obj(m, ctx_obj);
- if (ringbuf)
- describe_ctx_ringbuf(m, ringbuf);
- seq_putc(m, '\n');
- }
- } else {
- describe_obj(m, ctx->legacy_hw_ctx.rcs_state);
}
seq_putc(m, '\n');
@@ -2062,10 +2043,10 @@ static void i915_dump_lrc_obj(struct seq_file *m,
struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
+ struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
struct page *page;
uint32_t *reg_state;
int j;
- struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
unsigned long ggtt_offset = 0;
seq_printf(m, "CONTEXT: %s %u\n", engine->name, ctx->hw_id);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 47b20069851d..9d7a088efc16 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -862,13 +862,6 @@ struct i915_gem_context {
/* Unique identifier for this context, used by the hw for tracking */
unsigned hw_id;
- /* Legacy ring b
[Intel-gfx] [PATCH v2 01/11] drm/i915: Rename struct intel_context
Our goal is to rename the anonymous per-engine struct beneath the
current intel_context. However, after a lively debate resolving around
the confusion between intel_context_engine and intel_engine_context, the
realisation is that the two structs target different users. The outer
struct is API / user facing, and so carries the higher level GEM
information. The inner struct is hw facing. Thus we want to name the
inner struct intel_context and the outer one i915_gem_context. As the
first step, we need to rename the current struct:
s/struct intel_context/struct i915_gem_context/
which fits much better with its constructors already conveying the
i915_gem_context prefix!
Signed-off-by: Chris Wilson
Cc: Dave Gordon
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 10 +++---
drivers/gpu/drm/i915/i915_drv.h| 22 ++---
drivers/gpu/drm/i915/i915_gem.c| 8 ++---
drivers/gpu/drm/i915/i915_gem_context.c| 52 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +++---
drivers/gpu/drm/i915/i915_guc_submission.c | 12 +++
drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
drivers/gpu/drm/i915/i915_trace.h | 12 +++
drivers/gpu/drm/i915/intel_guc.h | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 22 ++---
drivers/gpu/drm/i915/intel_lrc.h | 10 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h| 4 +--
12 files changed, 84 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4c6b48dbd6e2..ae28e6e9d603 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -199,7 +199,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
}
-static void describe_ctx(struct seq_file *m, struct intel_context *ctx)
+static void describe_ctx(struct seq_file *m, struct i915_gem_context *ctx)
{
seq_putc(m, ctx->legacy_hw_ctx.initialized ? 'I' : 'i');
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
@@ -2000,7 +2000,7 @@ static int i915_context_status(struct seq_file *m, void
*unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
- struct intel_context *ctx;
+ struct i915_gem_context *ctx;
enum intel_engine_id id;
int ret;
@@ -2046,7 +2046,7 @@ static int i915_context_status(struct seq_file *m, void
*unused)
}
static void i915_dump_lrc_obj(struct seq_file *m,
- struct intel_context *ctx,
+ struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
struct page *page;
@@ -2094,7 +2094,7 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
- struct intel_context *ctx;
+ struct i915_gem_context *ctx;
int ret;
if (!i915.enable_execlists) {
@@ -2274,7 +2274,7 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
static int per_file_ctx(int id, void *ptr, void *data)
{
- struct intel_context *ctx = ptr;
+ struct i915_gem_context *ctx = ptr;
struct seq_file *m = data;
struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 255d4c3e3eea..ff35e36599de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -831,7 +831,7 @@ struct i915_ctx_hang_stats {
#define CONTEXT_NO_ZEROMAP (1<<0)
/**
- * struct intel_context - as the name implies, represents a context.
+ * struct i915_gem_context - as the name implies, represents a context.
* @ref: reference count.
* @user_handle: userspace tracking identity for this context.
* @remap_slice: l3 row remapping information.
@@ -849,7 +849,7 @@ struct i915_ctx_hang_stats {
* Contexts are memory images used by the hardware to store copies of their
* internal state.
*/
-struct intel_context {
+struct i915_gem_context {
struct kref ref;
int user_handle;
uint8_t remap_slice;
@@ -1710,7 +1710,7 @@ struct i915_execbuffer_params {
uint64_tbatch_obj_vm_offset;
struct intel_engine_cs *engine;
struct drm_i915_gem_object *batch_obj;
- struct intel_context*ctx;
+ struct i915_gem_context*ctx;
struct drm_i915_gem_request *request;
};
@@ -2013,7 +2013,7 @@ struct drm_i915_private {
void (*stop_engine)(struct intel_engine_cs *engine);
} gt;
- struct intel_context *kernel_context;
+ struct i915_gem
[Intel-gfx] [PATCH v2 10/11] drm/i915: Rearrange i915_gem_context
Pack the integers and related types together inside the struct.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9d7a088efc16..5dbce15e6e4c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -829,7 +829,6 @@ struct i915_ctx_hang_stats {
/* This must match up with the value previously used for execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_HANDLE 0
-#define CONTEXT_NO_ZEROMAP (1<<0)
/**
* struct i915_gem_context - as the name implies, represents a context.
* @ref: reference count.
@@ -851,28 +850,31 @@ struct i915_ctx_hang_stats {
*/
struct i915_gem_context {
struct kref ref;
- int user_handle;
- uint8_t remap_slice;
struct drm_i915_private *i915;
- int flags;
struct drm_i915_file_private *file_priv;
- struct i915_ctx_hang_stats hang_stats;
struct i915_hw_ppgtt *ppgtt;
+ struct i915_ctx_hang_stats hang_stats;
+
/* Unique identifier for this context, used by the hw for tracking */
unsigned hw_id;
+ uint32_t user_handle;
+ unsigned long flags;
+#define CONTEXT_NO_ZEROMAP (1<<0)
struct intel_context {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
- int pin_count;
struct i915_vma *lrc_vma;
- u64 lrc_desc;
uint32_t *lrc_reg_state;
+ u64 lrc_desc;
+ int pin_count;
bool initialised;
} engine[I915_NUM_ENGINES];
struct list_head link;
+
+ uint8_t remap_slice;
};
enum fb_op_origin {
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 02/11] drm/i915: Apply lockdep annotations to i915_gem_context.c
Markup the functions that require the caller to hold struct_mutex with
lockdep_assert_held(). In the hopefully not-too-distant future we will
split the struct_mutex up, and in doing so we need to be sure that we
know what it protects - here the lockdep annotations are invaluable.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_context.c | 16 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff35e36599de..a0f5f00f552f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3429,6 +3429,7 @@ static inline void i915_gem_context_reference(struct
i915_gem_context *ctx)
static inline void i915_gem_context_unreference(struct i915_gem_context *ctx)
{
+ lockdep_assert_held(&ctx->i915->dev->struct_mutex);
kref_put(&ctx->ref, i915_gem_context_free);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8484da26b5d4..af747f14522e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -153,6 +153,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
{
struct i915_gem_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
+ lockdep_assert_held(&ctx->i915->dev->struct_mutex);
trace_i915_context_free(ctx);
if (i915.enable_execlists)
@@ -181,6 +182,8 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t
size)
struct drm_i915_gem_object *obj;
int ret;
+ lockdep_assert_held(&dev->struct_mutex);
+
obj = i915_gem_object_create(dev, size);
if (IS_ERR(obj))
return obj;
@@ -368,6 +371,8 @@ void i915_gem_context_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ lockdep_assert_held(&dev->struct_mutex);
+
if (i915.enable_execlists) {
struct i915_gem_context *ctx;
@@ -433,6 +438,8 @@ void i915_gem_context_lost(struct drm_i915_private
*dev_priv)
{
struct intel_engine_cs *engine;
+ lockdep_assert_held(&dev_priv->dev->struct_mutex);
+
for_each_engine(engine, dev_priv) {
if (engine->last_context == NULL)
continue;
@@ -451,6 +458,8 @@ void i915_gem_context_fini(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct i915_gem_context *dctx = dev_priv->kernel_context;
+ lockdep_assert_held(&dev->struct_mutex);
+
if (dctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
@@ -491,6 +500,8 @@ void i915_gem_context_close(struct drm_device *dev, struct
drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
+ lockdep_assert_held(&dev->struct_mutex);
+
idr_for_each(&file_priv->context_idr, context_idr_cleanup, NULL);
idr_destroy(&file_priv->context_idr);
}
@@ -500,6 +511,8 @@ i915_gem_context_get(struct drm_i915_file_private
*file_priv, u32 id)
{
struct i915_gem_context *ctx;
+ lockdep_assert_held(&file_priv->dev_priv->dev->struct_mutex);
+
ctx = idr_find(&file_priv->context_idr, id);
if (!ctx)
return ERR_PTR(-ENOENT);
@@ -852,10 +865,9 @@ unpin_out:
int i915_switch_context(struct drm_i915_gem_request *req)
{
struct intel_engine_cs *engine = req->engine;
- struct drm_i915_private *dev_priv = req->i915;
WARN_ON(i915.enable_execlists);
- WARN_ON(!mutex_is_locked(&dev_priv->dev->struct_mutex));
+ lockdep_assert_held(&req->i915->dev->struct_mutex);
if (engine->id != RCS ||
req->ctx->legacy_hw_ctx.rcs_state == NULL) {
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/11] drm/i915: Show i915_gem_context owner in debugfs
Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).
v2: Mark the file_priv as closed.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
drivers/gpu/drm/i915/i915_gem_context.c | 3 ++-
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ae28e6e9d603..945fe4710b37 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2014,9 +2014,22 @@ static int i915_context_status(struct seq_file *m, void
*unused)
continue;
seq_printf(m, "HW context %u ", ctx->hw_id);
+ if (IS_ERR(ctx->file_priv)) {
+ seq_puts(m, "(deleted) ");
+ } else if (ctx->file_priv) {
+ struct pid *pid = ctx->file_priv->file->pid;
+ struct task_struct *task;
+
+ task = get_pid_task(pid, PIDTYPE_PID);
+ if (task) {
+ seq_printf(m, "(%s [%d]) ",
+ task->comm, task->pid);
+ put_task_struct(task);
+ }
+ } else
+ seq_puts(m, "(kernel) ");
+
describe_ctx(m, ctx);
- if (ctx == dev_priv->kernel_context)
- seq_printf(m, "(kernel context) ");
if (i915.enable_execlists) {
seq_putc(m, '\n');
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 474174c20be2..e552c936d262 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -468,6 +468,7 @@ static int context_idr_cleanup(int id, void *p, void *data)
{
struct i915_gem_context *ctx = p;
+ ctx->file_priv = ERR_PTR(-EBADF);
i915_gem_context_put(ctx);
return 0;
}
@@ -936,7 +937,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
return PTR_ERR(ctx);
}
- idr_remove(&ctx->file_priv->context_idr, ctx->user_handle);
+ idr_remove(&file_priv->context_idr, ctx->user_handle);
i915_gem_context_put(ctx);
mutex_unlock(&dev->struct_mutex);
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context into its creator
Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.
v2: Throw away the user_handle on failure to allocate the ppgtt.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 53 +++--
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index a4c6377eea32..474174c20be2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -303,9 +303,7 @@ static struct i915_gem_context *
i915_gem_create_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
{
- const bool is_global_default_ctx = file_priv == NULL;
struct i915_gem_context *ctx;
- int ret = 0;
BUG_ON(!mutex_is_locked(&dev->struct_mutex));
@@ -313,30 +311,15 @@ i915_gem_create_context(struct drm_device *dev,
if (IS_ERR(ctx))
return ctx;
- if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
- /* We may need to do things with the shrinker which
-* require us to immediately switch back to the default
-* context. This can cause a problem as pinning the
-* default context also requires GTT space which may not
-* be available. To avoid this we always pin the default
-* context.
-*/
- ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
-
get_context_alignment(to_i915(dev)), 0);
- if (ret) {
- DRM_DEBUG_DRIVER("Couldn't pin %d\n", ret);
- goto err_destroy;
- }
- }
-
if (USES_FULL_PPGTT(dev)) {
struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
- if (IS_ERR_OR_NULL(ppgtt)) {
+ if (IS_ERR(ppgtt)) {
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
- ret = PTR_ERR(ppgtt);
- goto err_unpin;
+ idr_remove(&file_priv->context_idr, ctx->user_handle);
+ i915_gem_context_put(ctx);
+ return ERR_CAST(ppgtt);
}
ctx->ppgtt = ppgtt;
@@ -345,14 +328,6 @@ i915_gem_create_context(struct drm_device *dev,
trace_i915_context_create(ctx);
return ctx;
-
-err_unpin:
- if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state)
- i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
-err_destroy:
- idr_remove(&file_priv->context_idr, ctx->user_handle);
- i915_gem_context_put(ctx);
- return ERR_PTR(ret);
}
static void i915_gem_context_unpin(struct i915_gem_context *ctx,
@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
+ if (ctx->legacy_hw_ctx.rcs_state) {
+ int ret;
+
+ /* We may need to do things with the shrinker which
+* require us to immediately switch back to the default
+* context. This can cause a problem as pinning the
+* default context also requires GTT space which may not
+* be available. To avoid this we always pin the default
+* context.
+*/
+ ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+ get_context_alignment(dev_priv), 0);
+ if (ret) {
+ DRM_ERROR("Failed to pinned default global context
(error %d)\n",
+ ret);
+ i915_gem_context_put(ctx);
+ return ret;
+ }
+ }
+
dev_priv->kernel_context = ctx;
DRM_DEBUG_DRIVER("%s context support initialized\n",
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/11] drm/i915: Name the inner most per-engine intel_context struct
We want to give a name to the currently anonymous per-engine struct
inside the context, so that we can assign it to a local variable and
save clumsy typing. The name we have chosen is intel_context as it
reflects the HW facing portion of the context state (the logical context
state, the registers, the ringbuffer etc).
Signed-off-by: Chris Wilson
Cc: Dave Gordon
Cc: Tvrtko Ursulin
Reviewed-by Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 15 ++---
drivers/gpu/drm/i915/intel_lrc.c | 90 +++---
3 files changed, 51 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ce5e92ce9652..bb62a02f933a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -869,7 +869,7 @@ struct i915_gem_context {
} legacy_hw_ctx;
/* Execlists */
- struct {
+ struct intel_context {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
int pin_count;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a292672f36d5..c29c1d19764f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -363,7 +363,6 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
struct i915_gem_context *ctx = client->owner;
struct guc_context_desc desc;
struct sg_table *sg;
- enum intel_engine_id id;
u32 gfx_addr;
memset(&desc, 0, sizeof(desc));
@@ -373,10 +372,10 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.priority = client->priority;
desc.db_id = client->doorbell_id;
- for_each_engine_id(engine, dev_priv, id) {
+ for_each_engine(engine, dev_priv) {
+ struct intel_context *ce = &ctx->engine[engine->id];
struct guc_execlist_context *lrc = &desc.lrc[engine->guc_id];
struct drm_i915_gem_object *obj;
- uint64_t ctx_desc;
/* TODO: We have a design issue to be solved here. Only when we
* receive the first batch, we know which engine is used by the
@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
* for now who owns a GuC client. But for future owner of GuC
* client, need to make sure lrc is pinned prior to enter here.
*/
- obj = ctx->engine[id].state;
- if (!obj)
+ if (!ce->state)
break; /* XXX: continue? */
- ctx_desc = intel_lr_context_descriptor(ctx, engine);
- lrc->context_desc = (u32)ctx_desc;
+ lrc->context_desc = lower_32_bits(ce->lrc_desc);
/* The state page is after PPHWSP */
- gfx_addr = i915_gem_obj_ggtt_offset(obj);
+ gfx_addr = i915_gem_obj_ggtt_offset(ce->state);
lrc->ring_lcra = gfx_addr + LRC_STATE_PN * PAGE_SIZE;
lrc->context_id = (client->ctx_index << GUC_ELC_CTXID_OFFSET) |
(engine->guc_id << GUC_ELC_ENGINE_OFFSET);
- obj = ctx->engine[id].ringbuf->obj;
+ obj = ce->ringbuf->obj;
gfx_addr = i915_gem_obj_ggtt_offset(obj);
lrc->ring_begin = gfx_addr;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9a55478e23ac..4b7c9680b097 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -300,7 +300,7 @@ logical_ring_init_platform_invariants(struct
intel_engine_cs *engine)
* descriptor for a pinned context
*
* @ctx: Context to work on
- * @ring: Engine the descriptor will be used with
+ * @engine: Engine the descriptor will be used with
*
* The context descriptor encodes various attributes of a context,
* including its GTT address and some flags. Because it's fairly
@@ -318,16 +318,17 @@ static void
intel_lr_context_descriptor_update(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
+ struct intel_context *ce = &ctx->engine[engine->id];
u64 desc;
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1engine[engine->id].lrc_vma->node.start + /* bits 12-31 */
- LRC_PPHWSP_PN * PAGE_SIZE;
+ desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
+ /* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT; /* bits 32-52 */
- ctx->engine[engine->id].lrc_desc = desc;
+ ce->lrc_desc = desc;
}
uint64_t intel_lr_context_descriptor(struct i915_gem_context
[Intel-gfx] [PATCH v2 03/11] drm/i915: Rename and inline i915_gem_context_get()
i915_gem_context_get() is a very simple wrapper around idr_find(), so
simple that it would be smaller to do the lookup inline. Also we use the
verb 'lookup' to return a pointer from a handle, freeing 'get' to imply
obtaining a reference to the context.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 17 +++--
drivers/gpu/drm/i915/i915_gem_context.c| 22 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
3 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a0f5f00f552f..d162bf86db7e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3417,11 +3417,24 @@ void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
int i915_switch_context(struct drm_i915_gem_request *req);
-struct i915_gem_context *
-i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id);
void i915_gem_context_free(struct kref *ctx_ref);
struct drm_i915_gem_object *
i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
+
+static inline struct i915_gem_context *
+i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
+{
+ struct i915_gem_context *ctx;
+
+ lockdep_assert_held(&file_priv->dev_priv->dev->struct_mutex);
+
+ ctx = idr_find(&file_priv->context_idr, id);
+ if (!ctx)
+ return ERR_PTR(-ENOENT);
+
+ return ctx;
+}
+
static inline void i915_gem_context_reference(struct i915_gem_context *ctx)
{
kref_get(&ctx->ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index af747f14522e..aa329175f73a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -506,20 +506,6 @@ void i915_gem_context_close(struct drm_device *dev, struct
drm_file *file)
idr_destroy(&file_priv->context_idr);
}
-struct i915_gem_context *
-i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id)
-{
- struct i915_gem_context *ctx;
-
- lockdep_assert_held(&file_priv->dev_priv->dev->struct_mutex);
-
- ctx = idr_find(&file_priv->context_idr, id);
- if (!ctx)
- return ERR_PTR(-ENOENT);
-
- return ctx;
-}
-
static inline int
mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
{
@@ -951,7 +937,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
- ctx = i915_gem_context_get(file_priv, args->ctx_id);
+ ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
return PTR_ERR(ctx);
@@ -977,7 +963,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
- ctx = i915_gem_context_get(file_priv, args->ctx_id);
+ ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
return PTR_ERR(ctx);
@@ -1020,7 +1006,7 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
if (ret)
return ret;
- ctx = i915_gem_context_get(file_priv, args->ctx_id);
+ ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
return PTR_ERR(ctx);
@@ -1072,7 +1058,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
if (ret)
return ret;
- ctx = i915_gem_context_get(file->driver_priv, args->ctx_id);
+ ctx = i915_gem_context_lookup(file->driver_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
return PTR_ERR(ctx);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index e61b92d7b0bc..84d990331abd 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1075,7 +1075,7 @@ i915_gem_validate_context(struct drm_device *dev, struct
drm_file *file,
if (engine->id != RCS && ctx_id != DEFAULT_CONTEXT_HANDLE)
return ERR_PTR(-EINVAL);
- ctx = i915_gem_context_get(file->driver_priv, ctx_id);
+ ctx = i915_gem_context_lookup(file->driver_priv, ctx_id);
if (IS_ERR(ctx))
return ctx;
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/11] drm/i915: Put the kernel_context in drm_i915_private next to its friends
Just move the kernel_context member of drm_i915_private next to the
engines it is associated with.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 3 +--
drivers/gpu/drm/i915/i915_guc_submission.c | 5 +++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb62a02f933a..47b20069851d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1760,6 +1760,7 @@ struct drm_i915_private {
wait_queue_head_t gmbus_wait_queue;
struct pci_dev *bridge_dev;
+ struct i915_gem_context *kernel_context;
struct intel_engine_cs engine[I915_NUM_ENGINES];
struct drm_i915_gem_object *semaphore_obj;
uint32_t last_seqno, next_seqno;
@@ -2013,8 +2014,6 @@ struct drm_i915_private {
void (*stop_engine)(struct intel_engine_cs *engine);
} gt;
- struct i915_gem_context *kernel_context;
-
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index c29c1d19764f..78b70526c197 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -912,11 +912,12 @@ int i915_guc_submission_enable(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = &dev_priv->guc;
- struct i915_gem_context *ctx = dev_priv->kernel_context;
struct i915_guc_client *client;
/* client for execbuf submission */
- client = guc_client_alloc(dev, GUC_CTX_PRIORITY_KMD_NORMAL, ctx);
+ client = guc_client_alloc(dev,
+ GUC_CTX_PRIORITY_KMD_NORMAL,
+ dev_priv->kernel_context);
if (!client) {
DRM_ERROR("Failed to create execbuf guc_client\n");
return -ENOMEM;
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/11] drm/i915: Show context objects in debugfs/i915_gem_objects
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 30cb26fe2fa9..3d14eb3215e1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -417,6 +417,40 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
}
+static int per_file_ctx_stats(int id, void *ptr, void *data)
+{
+ struct i915_gem_context *ctx = ptr;
+ int n;
+
+ for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
+ if (ctx->engine[n].state)
+ per_file_stats(0, ctx->engine[n].state, data);
+ if (ctx->engine[n].ringbuf)
+ per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
+ }
+
+ return 0;
+}
+
+static void print_context_stats(struct seq_file *m,
+ struct drm_i915_private *dev_priv)
+{
+ struct file_stats stats;
+ struct drm_file *file;
+
+ memset(&stats, 0, sizeof(stats));
+
+ if (dev_priv->kernel_context)
+ per_file_ctx_stats(0, dev_priv->kernel_context, &stats);
+
+ list_for_each_entry(file, &dev_priv->dev->filelist, lhead) {
+ struct drm_i915_file_private *fpriv = file->driver_priv;
+ idr_for_each(&fpriv->context_idr, per_file_ctx_stats, &stats);
+ }
+
+ print_file_stats(m, "[k]contexts", stats);
+}
+
#define count_vmas(list, member) do { \
list_for_each_entry(vma, list, member) { \
size += i915_gem_obj_total_ggtt_size(vma->obj); \
@@ -521,6 +555,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
+ print_context_stats(m, dev_priv);
mutex_unlock(&dev->struct_mutex);
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/kms_flip: Check crcs during basic flip test
From: Ville Syrjälä
Allocate 8 distinct looking fbs for the basic flip test, and while
flipping, check that the crc for each frame is as expected. If we
were to present the wrong framebuffer by accident, this should catch it.
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 126 +++
1 file changed, 91 insertions(+), 35 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 6ec97d0a8534..5b4e27e49838 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -75,6 +75,7 @@
#define TEST_BO_TOOBIG (1 << 28)
#define TEST_HANG_ONCE (1 << 29)
#define TEST_BASIC (1 << 30)
+#define TEST_CRC (1U << 31)
#define EVENT_FLIP (1 << 0)
#define EVENT_VBLANK (1 << 1)
@@ -151,6 +152,8 @@ static void dump_event_state(const struct event_state *es)
es->seq_step);
}
+#define N_FRAMES 8
+
struct test_output {
int mode_valid;
drmModeModeInfo kmode[4];
@@ -160,14 +163,16 @@ struct test_output {
uint32_t _crtc[4];
int _pipe[4];
int count; /* 1:1 mapping between crtc:connector */
- int flags;
+ unsigned int flags;
int pipe; /* primary pipe for vblank */
unsigned int current_fb_id;
unsigned int fb_width;
unsigned int fb_height;
- unsigned int fb_ids[3];
+ unsigned int fb_ids[N_FRAMES];
int bpp, depth;
- struct igt_fb fb_info[3];
+ struct igt_fb fb_info[N_FRAMES];
+ igt_pipe_crc_t *pipe_crc;
+ igt_crc_t crc[N_FRAMES];
struct event_state flip_state;
struct event_state vblank_state;
@@ -853,7 +858,9 @@ static unsigned int run_test_step(struct test_output *o)
if (o->flags & TEST_DPMS_OFF_OTHERS)
dpms_off_other_outputs(o);
- if (!(o->flags & TEST_SINGLE_BUFFER))
+ if (o->flags & TEST_CRC)
+ o->current_fb_id = (o->current_fb_id + 1) % N_FRAMES;
+ else if (!(o->flags & TEST_SINGLE_BUFFER))
o->current_fb_id = !o->current_fb_id;
if (o->flags & TEST_WITH_DUMMY_BCS)
@@ -1134,7 +1141,7 @@ found:
drmModeFreeCrtc(config[1].crtc);
}
-static void paint_flip_mode(struct igt_fb *fb, bool odd_frame)
+static void paint_flip_mode(struct igt_fb *fb, int n_phases, int phase)
{
cairo_t *cr = igt_get_cairo_ctx(drm_fd, fb);
int width = fb->width;
@@ -1142,10 +1149,7 @@ static void paint_flip_mode(struct igt_fb *fb, bool
odd_frame)
igt_paint_test_pattern(cr, width, height);
- if (odd_frame)
- cairo_rectangle(cr, width/4, height/2, width/4, height/8);
- else
- cairo_rectangle(cr, width/2, height/2, width/4, height/8);
+ cairo_rectangle(cr, phase * width/n_phases, height/2, width/n_phases,
height/8);
cairo_set_source_rgb(cr, 1, 1, 1);
cairo_fill(cr);
@@ -1251,6 +1255,29 @@ static unsigned event_loop(struct test_output *o,
unsigned duration_ms)
if (o->flags & TEST_HANG_ONCE)
hang = hang_gpu(drm_fd);
+ if (o->pipe_crc) {
+ igt_pipe_crc_stop(o->pipe_crc);
+ igt_pipe_crc_free(o->pipe_crc);
+ o->pipe_crc = NULL;
+ }
+
+ if (o->flags & TEST_CRC) {
+ o->pipe_crc = igt_pipe_crc_new_nonblock(o->pipe,
INTEL_PIPE_CRC_SOURCE_AUTO);
+
+ for (int i = 0; i < N_FRAMES; i++) {
+ igt_assert_eq(set_mode(o, o->fb_ids[i], 0, 0), 0);
+ igt_pipe_crc_collect_crc(o->pipe_crc, &o->crc[i]);
+
+ /* We want each frame to have a unique crc */
+ for (int j = 0; j < i; j++)
+ igt_require(!igt_crc_equal(&o->crc[i],
&o->crc[j]));
+ }
+ igt_assert_eq(set_mode(o, o->fb_ids[0], 0, 0), 0);
+ o->current_fb_id = 0;
+
+ igt_pipe_crc_start(o->pipe_crc);
+ }
+
start = gettime_us();
while (1) {
@@ -1262,6 +1289,20 @@ static unsigned event_loop(struct test_output *o,
unsigned duration_ms)
check_all_state(o, completed_events);
update_all_state(o, completed_events);
+ if (o->flags & TEST_CRC) {
+ igt_crc_t *crcs;
+ int n_crcs;
+ int prev_fb_id = (o->current_fb_id + N_FRAMES - 1) %
N_FRAMES;
+
+ n_crcs = igt_pipe_crc_get_crcs(o->pipe_crc, 2, &crcs);
+ igt_assert_eq(n_crcs, 1);
+
+ /* crc will be for the previous frame */
+ igt_assert_crc_equal(&crcs[0], &o->crc[prev_fb_id]);
+ free(crcs);
+ }
+
+
if (count && (gettime_us() - start) / 1000 >= duration_ms)
break;
@@ -1276,6 +1317,12 @@ static unsigned event_loop(struct test_output *o,
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement intel_dp_autotest_video_pattern function for DP Video pattern compliance tests
On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> This video pattern test function gets invoked through the
> compliance test handler on a HPD short pulse if the test type is
> set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
> reads to read the requested test pattern, video pattern resolution,
> frame rate and bits per color value. The results of this analysis
> are handed off to userspace so that the userspace app can set the
> video pattern mode appropriately for the test result/response.
>
> The compliance_test_active flag is set at the end of the individual
> test handling functions. This is so that the kernel-side operations
> can be completed without the risk of interruption from the userspace
> app that is polling on that flag.
>
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 14 ++-
> drivers/gpu/drm/i915/intel_dp.c | 76
> +
> drivers/gpu/drm/i915/intel_drv.h| 9 +
> include/drm/drm_dp_helper.h | 14 ++-
> 4 files changed, 111 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 6ee69b1..c8d0805 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4458,7 +4458,19 @@ static int i915_displayport_test_data_show(struct
> seq_file *m, void *data)
> if (connector->status == connector_status_connected &&
> connector->encoder != NULL) {
> intel_dp = enc_to_intel_dp(connector->encoder);
> - seq_printf(m, "%lx", intel_dp->compliance_test_data);
> + if (intel_dp->compliance_test_type ==
> + DP_TEST_LINK_EDID_READ)
> + seq_printf(m, "%lx",
> + intel_dp->compliance_test_data);
> + else if (intel_dp->compliance_test_type ==
> + DP_TEST_LINK_VIDEO_PATTERN) {
> + seq_printf(m, "hdisplay: %lu\n",
> + intel_dp->test_data.hdisplay);
> + seq_printf(m, "vdisplay: %lu\n",
> + intel_dp->test_data.vdisplay);
> + seq_printf(m, "bpc: %u\n",
> + intel_dp->test_data.bpc);
> + }
> } else
> seq_puts(m, "0");
> }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 456fc17..134cff8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4018,6 +4018,82 @@ static uint8_t intel_dp_autotest_link_training(struct
> intel_dp *intel_dp)
> static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
> {
> uint8_t test_result = DP_TEST_NAK;
> + uint8_t test_pattern;
> + uint16_t h_width, v_height, test_misc;
> + int status = 0;
> +
> + /* Automation support for Video Pattern Tests has a dependency
> + * on Link training Automation support (CTS Test 4.3.1.11)
> + * Hence it returns a TEST NAK until the Link Training automation
> + * support is added to the kernel
> + */
> + return test_result;
We shouldn't merge this patch until this is resolved. There's no point in adding
dead code.
> +
> + /* Read the TEST_PATTERN (DP CTS 3.1.5) */
> + status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_PATTERN,
> + &test_pattern, 1);
> + if (status <= 0) {
> + DRM_DEBUG_KMS("Could not read test pattern from"
> + "refernce sink\n");
> + return 0;
> + }
> + if (test_pattern != DP_COLOR_RAMP)
> + return test_result;
> + intel_dp->test_data.video_pattern = test_pattern;
> +
> + status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_H_WIDTH,
> + &h_width, 2);
> + if (status <= 0) {
> + DRM_DEBUG_KMS("Could not read H Width from"
> + "refernce sink\n");
> + return 0;
> + }
> + intel_dp->test_data.hdisplay = (h_width & DP_TEST_MSB_MASK) >> 8 |
> + (h_width << 8);
Just use the kernel endianness helpers, i.e.:
__le16 h_width;
drm_dp_dpcd_read(..., &h_width, 2)
hdisplay = le16_to_cpu(h_width);
> +
> + status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_V_HEIGHT,
> + &v_height, 2);
> + if (status <= 0) {
> + DRM_DEBUG_KMS("Could not read V Height from"
> + "refernce sink\n");
reference
> + return 0;
> + }
> + intel_dp->test_data.vdisplay = (v_height & DP_TEST_MSB_MASK) >> 8 |
> + (v_height << 8);
Same here.
> +
> + stat
[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [v2,01/11] drm/i915: Rename struct intel_context
== Series Details == Series: series starting with [v2,01/11] drm/i915: Rename struct intel_context URL : https://patchwork.freedesktop.org/series/7564/ State : success == Summary == Series 7564v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/7564/revisions/1/mbox Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (ro-bdw-i7-5600u) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (ro-ivb-i7-3770) Test kms_sink_crc_basic: skip -> PASS (ro-skl-i7-6700hq) fi-bdw-i7-5557u total:209 pass:197 dwarn:0 dfail:0 fail:0 skip:12 fi-bsw-n3050 total:209 pass:167 dwarn:0 dfail:0 fail:2 skip:40 fi-hsw-i7-4770k total:209 pass:190 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-i7-4770r total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 fi-skl-i5-6260u total:209 pass:198 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-i7-6700k total:209 pass:184 dwarn:0 dfail:0 fail:0 skip:25 fi-snb-i7-2600 total:209 pass:170 dwarn:0 dfail:0 fail:0 skip:39 ro-bdw-i5-5250u total:209 pass:172 dwarn:0 dfail:0 fail:0 skip:37 ro-bdw-i7-5557U total:209 pass:197 dwarn:0 dfail:0 fail:0 skip:12 ro-bdw-i7-5600u total:209 pass:180 dwarn:0 dfail:0 fail:1 skip:28 ro-bsw-n3050 total:209 pass:168 dwarn:0 dfail:0 fail:2 skip:39 ro-byt-n2820 total:209 pass:169 dwarn:0 dfail:0 fail:3 skip:37 ro-hsw-i3-4010u total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-hsw-i7-4770r total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk-i7-620lm total:209 pass:146 dwarn:0 dfail:0 fail:1 skip:62 ro-ilk1-i5-650 total:204 pass:146 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:209 pass:177 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:209 pass:181 dwarn:0 dfail:0 fail:0 skip:28 ro-skl-i7-6700hq total:204 pass:183 dwarn:0 dfail:0 fail:0 skip:21 ro-snb-i7-2620M total:209 pass:170 dwarn:0 dfail:0 fail:1 skip:38 fi-byt-n2820 failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_970/ eaa075a drm-intel-nightly: 2016y-05m-23d-08h-23m-34s UTC integration manifest 86197c5 drm/i915: Show context objects in debugfs/i915_gem_objects 0b5dacb drm/i915: Rearrange i915_gem_context 039cda6 drm/i915: Merge legacy+execlists context structs 1bc5739 drm/i915: Put the kernel_context in drm_i915_private next to its friends 0db38df drm/i915: Show i915_gem_context owner in debugfs 5646bb7 drm/i915: Move pinning of dev_priv->kernel_context into its creator a7a13c2 drm/i915: Name the inner most per-engine intel_context struct 07d2480 drm/i915: Rename i915_gem_context_reference/unreference() 0c71a3e drm/i915: Rename and inline i915_gem_context_get() b987d04 drm/i915: Apply lockdep annotations to i915_gem_context.c 9f66eaa drm/i915: Rename struct intel_context ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context into its creator
On 23/05/16 12:34, Chris Wilson wrote:
Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.
v2: Throw away the user_handle on failure to allocate the ppgtt.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 53 +++--
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index a4c6377eea32..474174c20be2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -303,9 +303,7 @@ static struct i915_gem_context *
i915_gem_create_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
{
- const bool is_global_default_ctx = file_priv == NULL;
struct i915_gem_context *ctx;
- int ret = 0;
BUG_ON(!mutex_is_locked(&dev->struct_mutex));
@@ -313,30 +311,15 @@ i915_gem_create_context(struct drm_device *dev,
if (IS_ERR(ctx))
return ctx;
- if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
- /* We may need to do things with the shrinker which
-* require us to immediately switch back to the default
-* context. This can cause a problem as pinning the
-* default context also requires GTT space which may not
-* be available. To avoid this we always pin the default
-* context.
-*/
- ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
-
get_context_alignment(to_i915(dev)), 0);
- if (ret) {
- DRM_DEBUG_DRIVER("Couldn't pin %d\n", ret);
- goto err_destroy;
- }
- }
-
if (USES_FULL_PPGTT(dev)) {
struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
- if (IS_ERR_OR_NULL(ppgtt)) {
+ if (IS_ERR(ppgtt)) {
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
- ret = PTR_ERR(ppgtt);
- goto err_unpin;
+ idr_remove(&file_priv->context_idr, ctx->user_handle);
+ i915_gem_context_put(ctx);
+ return ERR_CAST(ppgtt);
}
ctx->ppgtt = ppgtt;
@@ -345,14 +328,6 @@ i915_gem_create_context(struct drm_device *dev,
trace_i915_context_create(ctx);
return ctx;
-
-err_unpin:
- if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state)
- i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
-err_destroy:
- idr_remove(&file_priv->context_idr, ctx->user_handle);
- i915_gem_context_put(ctx);
- return ERR_PTR(ret);
}
static void i915_gem_context_unpin(struct i915_gem_context *ctx,
@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
+ if (ctx->legacy_hw_ctx.rcs_state) {
+ int ret;
+
+ /* We may need to do things with the shrinker which
+* require us to immediately switch back to the default
+* context. This can cause a problem as pinning the
+* default context also requires GTT space which may not
+* be available. To avoid this we always pin the default
+* context.
+*/
+ ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+ get_context_alignment(dev_priv), 0);
+ if (ret) {
+ DRM_ERROR("Failed to pinned default global context (error
%d)\n",
+ ret);
idr_remove here as well? Maybe we should split out the idr context API
from the GEM context to make it explicit - create context, export it to
userspace and back?
+ i915_gem_context_put(ctx);
+ return ret;
+ }
+ }
+
dev_priv->kernel_context = ctx;
DRM_DEBUG_DRIVER("%s context support initialized\n",
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/12] drm: Read DPCD receiver capability for DP to VGA converter
On Mon, May 23, 2016 at 01:50:47PM +0300, Mika Kahola wrote:
> Read from DPCD receiver capability field the max allowed
> pixel clock and bits per component for DP to VGA converter.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/drm_dp_helper.c | 46
>
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> include/drm/drm_dp_helper.h | 21 ++
> 3 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index eeaf5a7..c5bec6f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -412,6 +412,52 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux,
> struct drm_dp_link *link)
> }
> EXPORT_SYMBOL(drm_dp_link_power_down);
>
> +/*
> + * drm_dp_bd() - read DisplayPort Receiver Capability Fields for
> + * DP branch devices
> + * @aux: DisplayPort AUX channel
> + * @bd: pointer to a structure containing DP branch device information
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
> +{
> + uint8_t info[4];
> + uint8_t dfp;
> + bool detailed_cap_info;
> + int err, size;
> +
> + err = drm_dp_dpcd_read(aux, DP_DOWNSTREAMPORT_PRESENT, &dfp,
> sizeof(dfp));
> + if (err < 0)
> + return err;
> +
> + bd->present = dfp & 0x1;
> +
> + if (!bd->present)
> + return 0;
> +
> + detailed_cap_info = dfp & DP_DETAILED_CAP_INFO_AVAILABLE;
> +
> + size = detailed_cap_info ? 4 : 1;
> +
> + err = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, info, size);
> + if (err < 0)
> + return err;
> +
> + bd->type = info[0] & DP_DS_PORT_TYPE_MASK;
> + bd->hpd = info[0] & DP_DS_PORT_HPD;
> +
> + if (detailed_cap_info) {
> + if (bd->type & DP_DS_PORT_TYPE_VGA) {
> + bd->dfp.vga.dot_clk = info[1] * 8 * 1000;
> + bd->dfp.vga.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_bd);
> +
> /**
> * drm_dp_link_configure() - configure a DisplayPort link
> * @aux: DisplayPort AUX channel
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0741b2d..f85914b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -886,6 +886,8 @@ struct intel_dp {
>
> bool train_set_valid;
>
> + struct drm_dp_bd bd;
> +
> /* Displayport compliance testing */
> unsigned long compliance_test_type;
> unsigned long compliance_test_data;
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index e384c7f..d3e78a5 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -802,10 +802,31 @@ struct drm_dp_link {
> unsigned long capabilities;
> };
>
> +/*
> + * DP to VGA
> + */
> +struct drm_dp_vga {
> + int dot_clk;
> + uint8_t bpc;
> +};
> +
> +/*
> + * Branch device
> + */
> +struct drm_dp_bd {
> + bool present;
> + int type;
> + bool hpd;
> + union {
> + struct drm_dp_vga vga;
> + } dfp;
I still don't see any real point in adding this thing. I'd just keep
the common dp helper style and pass the port caps to each function
that parses one thing from there. Eg.
int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4]);
int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4]);
etc.
> +};
> +
> int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
> int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
> int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
> int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
> +int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd);
>
> int drm_dp_aux_register(struct drm_dp_aux *aux);
> void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> --
> 1.9.1
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context into its creator
On Mon, May 23, 2016 at 01:09:02PM +0100, Tvrtko Ursulin wrote:
> >@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
> > return PTR_ERR(ctx);
> > }
> >
> >+if (ctx->legacy_hw_ctx.rcs_state) {
> >+int ret;
> >+
> >+/* We may need to do things with the shrinker which
> >+ * require us to immediately switch back to the default
> >+ * context. This can cause a problem as pinning the
> >+ * default context also requires GTT space which may not
> >+ * be available. To avoid this we always pin the default
> >+ * context.
> >+ */
> >+ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
> >+get_context_alignment(dev_priv), 0);
> >+if (ret) {
> >+DRM_ERROR("Failed to pinned default global context
> >(error %d)\n",
> >+ ret);
>
> idr_remove here as well? Maybe we should split out the idr context
> API from the GEM context to make it explicit - create context,
> export it to userspace and back?
No, this one is not in an idr as file_priv is NULL for the kernel
context.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/11] drm/i915: Show i915_gem_context owner in debugfs
On 23/05/16 12:34, Chris Wilson wrote:
Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).
v2: Mark the file_priv as closed.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
drivers/gpu/drm/i915/i915_gem_context.c | 3 ++-
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ae28e6e9d603..945fe4710b37 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2014,9 +2014,22 @@ static int i915_context_status(struct seq_file *m, void
*unused)
continue;
seq_printf(m, "HW context %u ", ctx->hw_id);
+ if (IS_ERR(ctx->file_priv)) {
+ seq_puts(m, "(deleted) ");
+ } else if (ctx->file_priv) {
+ struct pid *pid = ctx->file_priv->file->pid;
+ struct task_struct *task;
+
+ task = get_pid_task(pid, PIDTYPE_PID);
+ if (task) {
+ seq_printf(m, "(%s [%d]) ",
+ task->comm, task->pid);
+ put_task_struct(task);
+ }
+ } else
+ seq_puts(m, "(kernel) ");
+
describe_ctx(m, ctx);
- if (ctx == dev_priv->kernel_context)
- seq_printf(m, "(kernel context) ");
if (i915.enable_execlists) {
seq_putc(m, '\n');
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 474174c20be2..e552c936d262 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -468,6 +468,7 @@ static int context_idr_cleanup(int id, void *p, void *data)
{
struct i915_gem_context *ctx = p;
+ ctx->file_priv = ERR_PTR(-EBADF);
i915_gem_context_put(ctx);
return 0;
}
@@ -936,7 +937,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
return PTR_ERR(ctx);
}
- idr_remove(&ctx->file_priv->context_idr, ctx->user_handle);
+ idr_remove(&file_priv->context_idr, ctx->user_handle);
i915_gem_context_put(ctx);
mutex_unlock(&dev->struct_mutex);
Looks OK.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib/crc: Update doc for igt_pipe_crc_get_crcs
Noticed while discussing CRC tests with Ville that this was totally
wrong.
v2: Ville pointed out that it only does not block when opened using
igt_pipe_crc_new_nonblocking. Still different from
igt_pipe_crc_collect_crc, which will always block.
v3: Fix type (Ville).
Cc: Ville Syrjälä
Acked-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
lib/igt_debugfs.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index a32ed7849199..2ea12a049d3a 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -567,15 +567,19 @@ void igt_pipe_crc_stop(igt_pipe_crc_t *pipe_crc)
* @n_crcs: number of CRCs to capture
* @out_crcs: buffer pointer for the captured CRC values
*
- * Read @n_crcs from @pipe_crc. This function blocks until @n_crcs are
- * retrieved. @out_crcs is alloced by this function and must be released with
- * free() by the caller.
+ * Read up to @n_crcs from @pipe_crc. This function does not block, and will
+ * return early if not enough CRCs can be captured, if @pipe_crc has been
+ * opened using igt_pipe_crc_new_nonblock(). It will block until @n_crcs are
+ * retrieved if @pipe_crc has been opened using igt_pipe_crc_new(). @out_crcs
is
+ * alloced by this function and must be released with free() by the caller.
*
* Callers must start and stop the capturing themselves by calling
- * igt_pipe_crc_start() and igt_pipe_crc_stop().
+ * igt_pipe_crc_start() and igt_pipe_crc_stop(). For one-shot CRC collecting
+ * look at igt_pipe_crc_collect_crc().
*
- * Returns: The number of CRCs captured. Should be equal to @n_crcs in blocking
- * mode, but can be less (even zero) in non-blocking mode.
+ * Returns:
+ * The number of CRCs captured. Should be equal to @n_crcs in blocking mode,
but
+ * can be less (even zero) in non-blocking mode.
*/
int
igt_pipe_crc_get_crcs(igt_pipe_crc_t *pipe_crc, int n_crcs,
@@ -626,13 +630,18 @@ static void crc_sanity_checks(igt_crc_t *crc)
* @out_crc: buffer for the captured CRC values
*
* Read a single CRC from @pipe_crc. This function blocks until the CRC is
- * retrieved. @out_crc must be allocated by the caller.
+ * retrieved, irrespective of whether @pipe_crc has been opened with
+ * igt_pipe_crc_new() or igt_pipe_crc_new_nonblock(). @out_crc must be
+ * allocated by the caller.
*
* This function takes care of the pipe_crc book-keeping, it will start/stop
* the collection of the CRC.
*
* This function also calls the interactive debug with the "crc" domain, so you
* can make use of this feature to actually see the screen that is being CRC'd.
+ *
+ * For continuous CRC collection look at igt_pipe_crc_start(),
+ * igt_pipe_crc_get_crcs() and igt_pipe_crc_stop().
*/
void igt_pipe_crc_collect_crc(igt_pipe_crc_t *pipe_crc, igt_crc_t *out_crc)
{
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context into its creator
On 23/05/16 13:16, Chris Wilson wrote:
On Mon, May 23, 2016 at 01:09:02PM +0100, Tvrtko Ursulin wrote:
@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
+ if (ctx->legacy_hw_ctx.rcs_state) {
+ int ret;
+
+ /* We may need to do things with the shrinker which
+* require us to immediately switch back to the default
+* context. This can cause a problem as pinning the
+* default context also requires GTT space which may not
+* be available. To avoid this we always pin the default
+* context.
+*/
+ ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+ get_context_alignment(dev_priv), 0);
+ if (ret) {
+ DRM_ERROR("Failed to pinned default global context (error
%d)\n",
+ ret);
idr_remove here as well? Maybe we should split out the idr context
API from the GEM context to make it explicit - create context,
export it to userspace and back?
No, this one is not in an idr as file_priv is NULL for the kernel
context.
Oh right, you can claim in the commit you fixed a bug as well then! :))
- const bool is_global_default_ctx = file_priv == NULL;
...
- if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
...
- goto err_destroy;
...
- idr_remove(&file_priv->context_idr, ctx->user_handle);
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/11] drm/i915: Show context objects in debugfs/i915_gem_objects
On 23/05/16 12:34, Chris Wilson wrote:
Blah blah blah, this, for that, etc... commit message ofc. :)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 30cb26fe2fa9..3d14eb3215e1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -417,6 +417,40 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
}
+static int per_file_ctx_stats(int id, void *ptr, void *data)
+{
+ struct i915_gem_context *ctx = ptr;
+ int n;
+
+ for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
+ if (ctx->engine[n].state)
+ per_file_stats(0, ctx->engine[n].state, data);
+ if (ctx->engine[n].ringbuf)
+ per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
+ }
+
+ return 0;
+}
+
+static void print_context_stats(struct seq_file *m,
+ struct drm_i915_private *dev_priv)
+{
+ struct file_stats stats;
+ struct drm_file *file;
+
+ memset(&stats, 0, sizeof(stats));
+
+ if (dev_priv->kernel_context)
+ per_file_ctx_stats(0, dev_priv->kernel_context, &stats);
+
+ list_for_each_entry(file, &dev_priv->dev->filelist, lhead) {
Existing code which iterates this list grabs dev->filelist_mutex ?
+ struct drm_i915_file_private *fpriv = file->driver_priv;
+ idr_for_each(&fpriv->context_idr, per_file_ctx_stats, &stats);
+ }
+
+ print_file_stats(m, "[k]contexts", stats);
+}
+
#define count_vmas(list, member) do { \
list_for_each_entry(vma, list, member) { \
size += i915_gem_obj_total_ggtt_size(vma->obj); \
@@ -521,6 +555,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
+ print_context_stats(m, dev_priv);
mutex_unlock(&dev->struct_mutex);
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/11] drm/i915: Show context objects in debugfs/i915_gem_objects
On Mon, May 23, 2016 at 01:31:25PM +0100, Tvrtko Ursulin wrote:
>
> On 23/05/16 12:34, Chris Wilson wrote:
>
> Blah blah blah, this, for that, etc... commit message ofc. :)
>
> >Signed-off-by: Chris Wilson
> >Cc: Tvrtko Ursulin
> >Cc: Joonas Lahtinen
> >---
> > drivers/gpu/drm/i915/i915_debugfs.c | 35
> > +++
> > 1 file changed, 35 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> >b/drivers/gpu/drm/i915/i915_debugfs.c
> >index 30cb26fe2fa9..3d14eb3215e1 100644
> >--- a/drivers/gpu/drm/i915/i915_debugfs.c
> >+++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >@@ -417,6 +417,40 @@ static void print_batch_pool_stats(struct seq_file *m,
> > print_file_stats(m, "[k]batch pool", stats);
> > }
> >
> >+static int per_file_ctx_stats(int id, void *ptr, void *data)
> >+{
> >+struct i915_gem_context *ctx = ptr;
> >+int n;
> >+
> >+for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
> >+if (ctx->engine[n].state)
> >+per_file_stats(0, ctx->engine[n].state, data);
> >+if (ctx->engine[n].ringbuf)
> >+per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
> >+}
> >+
> >+return 0;
> >+}
> >+
> >+static void print_context_stats(struct seq_file *m,
> >+struct drm_i915_private *dev_priv)
> >+{
> >+struct file_stats stats;
> >+struct drm_file *file;
> >+
> >+memset(&stats, 0, sizeof(stats));
> >+
> >+if (dev_priv->kernel_context)
> >+per_file_ctx_stats(0, dev_priv->kernel_context, &stats);
> >+
> >+list_for_each_entry(file, &dev_priv->dev->filelist, lhead) {
>
> Existing code which iterates this list grabs dev->filelist_mutex ?
Recent invention, curses Daniel!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 i-g-t] tests/kms_flip: Check crcs during basic flip test
From: Ville Syrjälä
Allocate 8 distinct looking fbs for the basic flip test, and while
flipping, check that the crc for each frame is as expected. If we
were to present the wrong framebuffer by accident, this should catch it.
v2: Just igt_warn() instead of igt_require() for unique crc check (Daniel)
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 132 ---
1 file changed, 97 insertions(+), 35 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 6ec97d0a8534..54e47e4b7b29 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -75,6 +75,7 @@
#define TEST_BO_TOOBIG (1 << 28)
#define TEST_HANG_ONCE (1 << 29)
#define TEST_BASIC (1 << 30)
+#define TEST_CRC (1U << 31)
#define EVENT_FLIP (1 << 0)
#define EVENT_VBLANK (1 << 1)
@@ -151,6 +152,8 @@ static void dump_event_state(const struct event_state *es)
es->seq_step);
}
+#define N_FRAMES 8
+
struct test_output {
int mode_valid;
drmModeModeInfo kmode[4];
@@ -160,14 +163,16 @@ struct test_output {
uint32_t _crtc[4];
int _pipe[4];
int count; /* 1:1 mapping between crtc:connector */
- int flags;
+ unsigned int flags;
int pipe; /* primary pipe for vblank */
unsigned int current_fb_id;
unsigned int fb_width;
unsigned int fb_height;
- unsigned int fb_ids[3];
+ unsigned int fb_ids[N_FRAMES];
int bpp, depth;
- struct igt_fb fb_info[3];
+ struct igt_fb fb_info[N_FRAMES];
+ igt_pipe_crc_t *pipe_crc;
+ igt_crc_t crc[N_FRAMES];
struct event_state flip_state;
struct event_state vblank_state;
@@ -853,7 +858,9 @@ static unsigned int run_test_step(struct test_output *o)
if (o->flags & TEST_DPMS_OFF_OTHERS)
dpms_off_other_outputs(o);
- if (!(o->flags & TEST_SINGLE_BUFFER))
+ if (o->flags & TEST_CRC)
+ o->current_fb_id = (o->current_fb_id + 1) % N_FRAMES;
+ else if (!(o->flags & TEST_SINGLE_BUFFER))
o->current_fb_id = !o->current_fb_id;
if (o->flags & TEST_WITH_DUMMY_BCS)
@@ -1134,7 +1141,7 @@ found:
drmModeFreeCrtc(config[1].crtc);
}
-static void paint_flip_mode(struct igt_fb *fb, bool odd_frame)
+static void paint_flip_mode(struct igt_fb *fb, int n_phases, int phase)
{
cairo_t *cr = igt_get_cairo_ctx(drm_fd, fb);
int width = fb->width;
@@ -1142,10 +1149,7 @@ static void paint_flip_mode(struct igt_fb *fb, bool
odd_frame)
igt_paint_test_pattern(cr, width, height);
- if (odd_frame)
- cairo_rectangle(cr, width/4, height/2, width/4, height/8);
- else
- cairo_rectangle(cr, width/2, height/2, width/4, height/8);
+ cairo_rectangle(cr, phase * width/n_phases, height/2, width/n_phases,
height/8);
cairo_set_source_rgb(cr, 1, 1, 1);
cairo_fill(cr);
@@ -1251,6 +1255,35 @@ static unsigned event_loop(struct test_output *o,
unsigned duration_ms)
if (o->flags & TEST_HANG_ONCE)
hang = hang_gpu(drm_fd);
+ if (o->pipe_crc) {
+ igt_pipe_crc_stop(o->pipe_crc);
+ igt_pipe_crc_free(o->pipe_crc);
+ o->pipe_crc = NULL;
+ }
+
+ if (o->flags & TEST_CRC) {
+ bool unique_crcs = true;
+
+ o->pipe_crc = igt_pipe_crc_new_nonblock(o->pipe,
INTEL_PIPE_CRC_SOURCE_AUTO);
+
+ for (int i = 0; i < N_FRAMES; i++) {
+ igt_assert_eq(set_mode(o, o->fb_ids[i], 0, 0), 0);
+ igt_pipe_crc_collect_crc(o->pipe_crc, &o->crc[i]);
+
+ /* We want each frame to have a unique crc */
+ for (int j = 0; j < i; j++) {
+ if (igt_crc_equal(&o->crc[i], &o->crc[j]))
+ unique_crcs = false;
+ }
+ }
+ if (!unique_crcs)
+ igt_warn("CRCs not unique, unable to detect all CRC
mismatches\n");
+ igt_assert_eq(set_mode(o, o->fb_ids[0], 0, 0), 0);
+ o->current_fb_id = 0;
+
+ igt_pipe_crc_start(o->pipe_crc);
+ }
+
start = gettime_us();
while (1) {
@@ -1262,6 +1295,20 @@ static unsigned event_loop(struct test_output *o,
unsigned duration_ms)
check_all_state(o, completed_events);
update_all_state(o, completed_events);
+ if (o->flags & TEST_CRC) {
+ igt_crc_t *crcs;
+ int n_crcs;
+ int prev_fb_id = (o->current_fb_id + N_FRAMES - 1) %
N_FRAMES;
+
+ n_crcs = igt_pipe_crc_get_crcs(o->pipe_crc, 2, &crcs);
+ igt_assert_eq(n_crcs, 1);
+
+ /* crc will be for the previous
[Intel-gfx] [PATCH v3] drm/i915/debugfs: Show context objects in i915_gem_objects
One of the uses for i915_gem_objects is pin-pointing leaks. For this, we
can compare the number of allocated objects and who owns them, a
discrepancy here often indicates a kernel bug. One allocator of unreported
objects is for backing context objects, so include those in the listing.
v2: Take filelist_mutex which requires a little dance with struct_mutex
to avoid nesting filelist_mutex inside struct_mutex.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 38 -
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 30cb26fe2fa9..1300bad67f5c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -417,6 +417,42 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
}
+static int per_file_ctx_stats(int id, void *ptr, void *data)
+{
+ struct i915_gem_context *ctx = ptr;
+ int n;
+
+ for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
+ if (ctx->engine[n].state)
+ per_file_stats(0, ctx->engine[n].state, data);
+ if (ctx->engine[n].ringbuf)
+ per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
+ }
+
+ return 0;
+}
+
+static void print_context_stats(struct seq_file *m,
+ struct drm_i915_private *dev_priv)
+{
+ struct file_stats stats;
+ struct drm_file *file;
+
+ memset(&stats, 0, sizeof(stats));
+
+ mutex_lock(&dev_priv->dev->struct_mutex);
+ if (dev_priv->kernel_context)
+ per_file_ctx_stats(0, dev_priv->kernel_context, &stats);
+
+ list_for_each_entry(file, &dev_priv->dev->filelist, lhead) {
+ struct drm_i915_file_private *fpriv = file->driver_priv;
+ idr_for_each(&fpriv->context_idr, per_file_ctx_stats, &stats);
+ }
+ mutex_unlock(&dev_priv->dev->struct_mutex);
+
+ print_file_stats(m, "[k]contexts", stats);
+}
+
#define count_vmas(list, member) do { \
list_for_each_entry(vma, list, member) { \
size += i915_gem_obj_total_ggtt_size(vma->obj); \
@@ -521,10 +557,10 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
-
mutex_unlock(&dev->struct_mutex);
mutex_lock(&dev->filelist_mutex);
+ print_context_stats(m, dev_priv);
list_for_each_entry_reverse(file, &dev->filelist, lhead) {
struct file_stats stats;
struct task_struct *task;
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/7] drm/i915/guc: add enable_guc_loading parameter
On 20/05/2016 11:42, Tvrtko Ursulin wrote:
From: Dave Gordon
Split the function of "enable_guc_submission" into two separate
options. The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.
In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
-1 (default) whatever the platform default is
0 DISABLE don't load/use the GuC
1 BEST EFFORT try to load/use the GuC, fallback if not available
2 REQUIRE must load/use the GuC, else leave the GPU wedged
The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.
v4:
Changed some error-message levels, mostly ERROR->INFO, per
review comments by Tvrtko Ursulin.
v5:
Dropped one more error message, disabled GuC submission on
hypothetical firmware-free devices [Tvrtko Ursulin].
v6:
Logging tidy by Tvrtko Ursulin:
* Do not log falling back to execlists when wedging the GPU.
* Do not log fw load errors when load was disabled by user.
* Pass down some error code from fw load for log message to
make more sense.
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin (v5)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Nick Hoath (v6)
---
drivers/gpu/drm/i915/i915_gem.c| 5 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-
drivers/gpu/drm/i915/i915_params.c | 14 +++-
drivers/gpu/drm/i915/i915_params.h | 3 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 123 +
5 files changed, 89 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 88dce5482f2f..1a3a07eca0d0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4868,11 +4868,8 @@ i915_gem_init_hw(struct drm_device *dev)
/* We can't enable contexts until all firmware is loaded */
if (HAS_GUC(dev)) {
ret = intel_guc_setup(dev);
- if (ret) {
- DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
- ret = -EIO;
+ if (ret)
goto out;
- }
}
/*
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 169242a8adff..916cd6778cf3 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -969,7 +969,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
- if (!i915.enable_guc_submission)
+ if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
ctx = dev_priv->kernel_context;
@@ -995,7 +995,7 @@ int intel_guc_resume(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
- if (!i915.enable_guc_submission)
+ if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index cd74fb8e9387..21a323c01cdb 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -53,7 +53,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
- .enable_guc_submission = false,
+ .enable_guc_loading = -1,
+ .enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -193,8 +194,15 @@ MODULE_PARM_DESC(edp_vswing,
"(0=use value from vbt [default], 1=low power swing(200mV),"
"2=default swing(400mV))");
-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission
(default:false)");
+module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int,
0400);
+MODULE_PARM_DESC(enable_guc_loading,
+ "Enable GuC firmware loading "
+ "(-1=auto [default], 0=never, 1=if available, 2=required)");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
int, 0400);
+MODULE_PARM_DESC(enable_guc_submission,
+ "Enable GuC submission "
+ "(-1=auto, 0=never [default], 1=if available, 2=required)");
module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
MODULE_PARM_DESC(guc_log_level,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_pa
Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Enable GuC submission (rev3)
On 20/05/16 12:15, Patchwork wrote:
== Series Details ==
Series: Enable GuC submission (rev3)
URL : https://patchwork.freedesktop.org/series/7153/
State : failure
== Summary ==
Series 7153v3 Enable GuC submission
http://patchwork.freedesktop.org/api/1.0/series/7153/revisions/3/mbox
Test drv_module_reload_basic:
dmesg-warn -> PASS (ro-bdw-i7-5600u)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass -> FAIL (ro-byt-n2820)
Unrelated https://bugs.freedesktop.org/show_bug.cgi?id=94294
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS (ro-ivb-i7-3770)
fi-bdw-i7-5557u total:217 pass:204 dwarn:0 dfail:0 fail:0 skip:13
fi-bsw-n3050 total:216 pass:172 dwarn:0 dfail:0 fail:2 skip:42
fi-byt-n2820 total:216 pass:173 dwarn:0 dfail:0 fail:2 skip:41
fi-hsw-i7-4770r total:217 pass:191 dwarn:0 dfail:0 fail:0 skip:26
fi-skl-i7-6700k total:217 pass:189 dwarn:0 dfail:0 fail:0 skip:28
ro-bdw-i5-5250u total:217 pass:179 dwarn:0 dfail:0 fail:0 skip:38
ro-bdw-i7-5557U total:217 pass:204 dwarn:0 dfail:0 fail:0 skip:13
ro-bdw-i7-5600u total:217 pass:185 dwarn:0 dfail:0 fail:1 skip:31
ro-bsw-n3050 total:217 pass:172 dwarn:0 dfail:0 fail:3 skip:42
ro-byt-n2820 total:216 pass:171 dwarn:0 dfail:0 fail:4 skip:41
ro-hsw-i3-4010u total:216 pass:191 dwarn:0 dfail:0 fail:0 skip:25
ro-hsw-i7-4770r total:217 pass:191 dwarn:0 dfail:0 fail:0 skip:26
ro-ilk-i7-620lm total:217 pass:148 dwarn:0 dfail:0 fail:2 skip:67
ro-ilk1-i5-650 total:212 pass:150 dwarn:0 dfail:0 fail:1 skip:61
ro-ivb-i7-3770 total:217 pass:181 dwarn:0 dfail:0 fail:0 skip:36
ro-ivb2-i7-3770 total:217 pass:185 dwarn:0 dfail:0 fail:0 skip:32
ro-skl-i7-6700hq total:212 pass:188 dwarn:0 dfail:0 fail:0 skip:24
ro-snb-i7-2620M total:217 pass:175 dwarn:0 dfail:0 fail:1 skip:41
fi-snb-i7-2600 failed to connect after reboot
Results at /archive/results/CI_IGT_test/RO_Patchwork_948/
9d15199 drm-intel-nightly: 2016y-05m-20d-07h-54m-59s UTC integration manifest
c1bdfec drm/i915/guc: change default to using GuC submission if possible
429ed03 drm/i915/guc: rework guc_add_workqueue_item()
7e031c7 drm/i915/guc: don't spinwait if the GuC's workqueue is full
274cb6c drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space,
submit}()
25aa845 drm/i915/guc: add enable_guc_loading parameter
b9dc454 drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED
7bdfe0d drm/i915/guc: rename loader entry points
Merged up the next to last patch - so not enabling GuC by default yet.
Thanks for pthe atches and review!
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] drm/i915: Fix warnings from atomic nonblocking unpin.
Some small fixes to make CI more happy. First is a fix to make all blocking calls wait for update to complete, so any call done right doesn't have to block on it or return -EBUSY. pin_count was limited to 15, so many cursor updates in a single vblank would cause it to reach the limit and a warning. Bump this upwards for the time being. The proper fix is > 1 vblank depth, or passing vma in the plane_state. Maarten Lankhorst (2): drm/i915: Wait for flips to complete before returning. drm/i915: Bump pin_count to UINT_MAX. drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++-- drivers/gpu/drm/i915/intel_display.c | 26 -- 2 files changed, 22 insertions(+), 8 deletions(-) -- 2.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Bump pin_count to UINT_MAX.
With nonblocking unpin there can be many cursor pins before they're
cleared by the next page flip.
Fix this by extending pin_count to the full 32-bit to prevent a
WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
Cc: Ville Syrjälä
Reported-by: Chris Wilson
Signed-off-by: Maarten Lankhorst
Fixes: a6747b7304a9 ("drm/i915: Make unpin async.")
---
drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 62be77cac5cd..1d43cc290f71 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -218,8 +218,8 @@ struct i915_vma {
*
* In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
* bits with absolutely no headroom. So use 4 bits. */
- unsigned int pin_count:4;
-#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT 0xf
+ unsigned int pin_count;
+#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT UINT_MAX
};
struct i915_page_dma {
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Wait for flips to complete before returning.
Doing a page flip right after setcrtc would fail because part of the update is
run
asynchronously. This is a regression and is caused kms_flip to fails without
the atomic page flip patch, and kms_frontbuffer_tracking to fail on
ro-bdw-i7-5600u.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a500f08ec0ac..21c0a2f3102b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3788,7 +3788,7 @@ static void page_flip_completed(struct intel_crtc
*intel_crtc, struct intel_flip
queue_work(dev_priv->wq, &work->unpin_work);
}
-static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
+static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc, bool intr)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3796,10 +3796,15 @@ static int intel_crtc_wait_for_pending_flips(struct
drm_crtc *crtc)
WARN_ON(waitqueue_active(&dev_priv->pending_flip_queue));
- ret = wait_event_interruptible_timeout(
- dev_priv->pending_flip_queue,
- !intel_crtc_has_pending_flip(crtc),
- 60*HZ);
+ if (intr)
+ ret = wait_event_interruptible_timeout(
+ dev_priv->pending_flip_queue,
+
!intel_crtc_has_pending_flip(crtc),
+ 60*HZ);
+ else
+ ret = wait_event_timeout(dev_priv->pending_flip_queue,
+!intel_crtc_has_pending_flip(crtc),
+60*HZ);
if (ret < 0)
return ret;
@@ -12736,7 +12741,7 @@ static int intel_atomic_prepare_commit(struct
drm_device *dev,
struct intel_flip_work *work;
if (!state->legacy_cursor_update) {
- ret = intel_crtc_wait_for_pending_flips(crtc);
+ ret = intel_crtc_wait_for_pending_flips(crtc, true);
if (ret)
return ret;
@@ -13005,6 +13010,7 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_crtc_state *old_crtc_state;
struct drm_crtc *crtc;
int ret = 0, i;
+ unsigned crtc_mask = 0;
ret = intel_atomic_prepare_commit(dev, state, nonblock);
if (ret) {
@@ -13075,6 +13081,8 @@ static int intel_atomic_commit(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
+ crtc_mask |= drm_crtc_mask(crtc);
+
if (modeset && crtc->state->active) {
update_scanline_offset(to_intel_crtc(crtc));
dev_priv->display.crtc_enable(crtc);
@@ -13105,6 +13113,12 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_schedule_update(crtc, intel_state, work, nonblock);
}
+ if (!nonblock && !state->legacy_cursor_update) {
+ drm_for_each_crtc(crtc, dev)
+ if (crtc_mask & drm_crtc_mask(crtc))
+ intel_crtc_wait_for_pending_flips(crtc, false);
+ }
+
/* FIXME: add subpixel order */
drm_atomic_state_free(state);
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/debugfs: Show context objects in i915_gem_objects
Hi,
[auto build test ERROR on next-20160523]
[cannot apply to drm-intel/for-linux-next v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-debugfs-Show-context-objects-in-i915_gem_objects/20160523-210704
config: x86_64-rhel (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the
linux-review/Chris-Wilson/drm-i915-debugfs-Show-context-objects-in-i915_gem_objects/20160523-210704
HEAD 3dfdb2b9e47b5ee4dfd9a21f80014bd9de87c4cb builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
In file included from include/asm-generic/bug.h:13:0,
from arch/x86/include/asm/bug.h:35,
from include/linux/bug.h:4,
from include/linux/seq_file.h:6,
from drivers/gpu/drm/i915/i915_debugfs.c:29:
drivers/gpu/drm/i915/i915_debugfs.c: In function 'per_file_ctx_stats':
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to
>> incomplete type
for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
^
include/linux/kernel.h:54:33: note: in definition of macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to
>> incomplete type
for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
^
include/linux/kernel.h:54:48: note: in definition of macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^
In file included from include/linux/seq_file.h:6:0,
from drivers/gpu/drm/i915/i915_debugfs.c:29:
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to
>> incomplete type
for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
^
include/linux/bug.h:34:55: note: in definition of macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/compiler-gcc.h:64:46: note: in expansion of macro '__same_type'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^
drivers/gpu/drm/i915/i915_debugfs.c:432:18: note: in expansion of macro
'ARRAY_SIZE'
for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
^
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to
>> incomplete type
for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
^
include/linux/bug.h:34:55: note: in definition of macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/compiler-gcc.h:64:46: note: in expansion of macro '__same_type'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^
drivers/gpu/drm/i915/i915_debugfs.c:432:18: note: in expansion of macro
'ARRAY_SIZE'
for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
^
include/linux/bug.h:34:45: error: bit-field '' width not an
integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/compiler-gcc.h:64:28: note: in expansion of macro
'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^
drivers/gpu/drm/i915/i915_debugfs.c:432:18: note: in expansion of macro
'ARRAY_S
[Intel-gfx] [PATCH 1/2] drm/i915: Wait for flips to complete before returning.
Doing a page flip right after setcrtc would fail because part of the update is
run
asynchronously. This is a regression and is caused kms_flip to fails without
the atomic page flip patch, and kms_frontbuffer_tracking to fail on
ro-bdw-i7-5600u.
Signed-off-by: Maarten Lankhorst
---
Oops, stripped 1/2 from subject, fixed!
drivers/gpu/drm/i915/intel_display.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a500f08ec0ac..21c0a2f3102b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3788,7 +3788,7 @@ static void page_flip_completed(struct intel_crtc
*intel_crtc, struct intel_flip
queue_work(dev_priv->wq, &work->unpin_work);
}
-static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
+static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc, bool intr)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3796,10 +3796,15 @@ static int intel_crtc_wait_for_pending_flips(struct
drm_crtc *crtc)
WARN_ON(waitqueue_active(&dev_priv->pending_flip_queue));
- ret = wait_event_interruptible_timeout(
- dev_priv->pending_flip_queue,
- !intel_crtc_has_pending_flip(crtc),
- 60*HZ);
+ if (intr)
+ ret = wait_event_interruptible_timeout(
+ dev_priv->pending_flip_queue,
+
!intel_crtc_has_pending_flip(crtc),
+ 60*HZ);
+ else
+ ret = wait_event_timeout(dev_priv->pending_flip_queue,
+!intel_crtc_has_pending_flip(crtc),
+60*HZ);
if (ret < 0)
return ret;
@@ -12736,7 +12741,7 @@ static int intel_atomic_prepare_commit(struct
drm_device *dev,
struct intel_flip_work *work;
if (!state->legacy_cursor_update) {
- ret = intel_crtc_wait_for_pending_flips(crtc);
+ ret = intel_crtc_wait_for_pending_flips(crtc, true);
if (ret)
return ret;
@@ -13005,6 +13010,7 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_crtc_state *old_crtc_state;
struct drm_crtc *crtc;
int ret = 0, i;
+ unsigned crtc_mask = 0;
ret = intel_atomic_prepare_commit(dev, state, nonblock);
if (ret) {
@@ -13075,6 +13081,8 @@ static int intel_atomic_commit(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
+ crtc_mask |= drm_crtc_mask(crtc);
+
if (modeset && crtc->state->active) {
update_scanline_offset(to_intel_crtc(crtc));
dev_priv->display.crtc_enable(crtc);
@@ -13105,6 +13113,12 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_schedule_update(crtc, intel_state, work, nonblock);
}
+ if (!nonblock && !state->legacy_cursor_update) {
+ drm_for_each_crtc(crtc, dev)
+ if (crtc_mask & drm_crtc_mask(crtc))
+ intel_crtc_wait_for_pending_flips(crtc, false);
+ }
+
/* FIXME: add subpixel order */
drm_atomic_state_free(state);
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/debugfs: Show context objects in i915_gem_objects
Hi,
[auto build test ERROR on next-20160523]
[cannot apply to drm-intel/for-linux-next v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-debugfs-Show-context-objects-in-i915_gem_objects/20160523-210704
config: i386-randconfig-x011-201621 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: the
linux-review/Chris-Wilson/drm-i915-debugfs-Show-context-objects-in-i915_gem_objects/20160523-210704
HEAD 3dfdb2b9e47b5ee4dfd9a21f80014bd9de87c4cb builds fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>):
In file included from include/asm-generic/bug.h:13:0,
from arch/x86/include/asm/bug.h:35,
from include/linux/bug.h:4,
from include/linux/seq_file.h:6,
from drivers/gpu/drm/i915/i915_debugfs.c:29:
drivers/gpu/drm/i915/i915_debugfs.c: In function 'per_file_ctx_stats':
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to
>> incomplete type 'struct i915_gem_context'
for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
^
include/linux/kernel.h:54:33: note: in definition of macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^~~
In file included from include/linux/seq_file.h:6:0,
from drivers/gpu/drm/i915/i915_debugfs.c:29:
>> include/linux/bug.h:34:45: error: bit-field '' width not an
>> integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/compiler-gcc.h:64:28: note: in expansion of macro
'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
^~~
>> drivers/gpu/drm/i915/i915_debugfs.c:432:18: note: in expansion of macro
>> 'ARRAY_SIZE'
for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
^~
drivers/gpu/drm/i915/i915_debugfs.c: In function 'i915_dump_lrc':
drivers/gpu/drm/i915/i915_debugfs.c:2139:6: warning: suggest explicit braces
to avoid ambiguous 'else' [-Wparentheses]
if (ctx != dev_priv->kernel_context)
^
vim +432 drivers/gpu/drm/i915/i915_debugfs.c
426
427 static int per_file_ctx_stats(int id, void *ptr, void *data)
428 {
429 struct i915_gem_context *ctx = ptr;
430 int n;
431
> 432 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
433 if (ctx->engine[n].state)
434 per_file_stats(0, ctx->engine[n].state, data);
435 if (ctx->engine[n].ringbuf)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Enable GSE interrupt on BDW+
On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We've never actually enabled or unmasked the GSE interrupt on BDW+,
> even though the interrupt handler was always prepared for it.
> Let's enable it and see what happens.
>
> Credit to Mark Kettenis who fixed this in the OpenBSD fork of the
> driver. He reports that it fixed the "ACPI _BCM/_BCQ-based
> brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1
> Carbon" for them.
>
> Reviewed-by: Daniel Vetter
> References:
> http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.html
> Reported-by: Mark Kettenis
> Cc: Mark Kettenis
> Cc: Jani Nikula
> Signed-off-by: Ville Syrjälä
> ---
> Nothing changed, just reposted for CI.
As I noted previously, I don't think we need this, but if you insist on
having it, please add a note about it in the commit message. With that,
Acked-by: Jani Nikula
>
> drivers/gpu/drm/i915/i915_irq.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f0d941455bed..4c271ea267bb 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3799,6 +3799,7 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> uint32_t de_pipe_enables;
> u32 de_port_masked = GEN8_AUX_CHANNEL_A;
> u32 de_port_enables;
> + u32 de_misc_masked = GEN8_DE_MISC_GSE;
> enum pipe pipe;
>
> if (INTEL_INFO(dev_priv)->gen >= 9) {
> @@ -3834,6 +3835,7 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> de_pipe_enables);
>
> GEN5_IRQ_INIT(GEN8_DE_PORT_, ~de_port_masked, de_port_enables);
> + GEN5_IRQ_INIT(GEN8_DE_MISC_, ~de_misc_masked, de_misc_masked);
> }
>
> static int gen8_irq_postinstall(struct drm_device *dev)
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/opregion: Convert to using native drm_i915_private
Prefer passing struct drm_i915_private to internal interfaces as this
saves us having to dance between drm_device and our native struct. The
savings hare are small (only 70 bytes of unrequired dancing), but
progressive!
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 6 +-
drivers/gpu/drm/i915/i915_drv.c | 18 +++---
drivers/gpu/drm/i915/i915_drv.h | 20 +++
drivers/gpu/drm/i915/intel_bios.c | 2 +-
drivers/gpu/drm/i915/intel_opregion.c | 105 +-
5 files changed, 74 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 31e859bc74b1..363bd5884a56 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1307,7 +1307,7 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
intel_uncore_sanitize(dev_priv);
- intel_opregion_setup(dev);
+ intel_opregion_setup(dev_priv);
i915_gem_load_init_fences(dev_priv);
@@ -1376,7 +1376,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
if (INTEL_INFO(dev_priv)->num_pipes) {
/* Must be done after probing outputs */
- intel_opregion_init(dev);
+ intel_opregion_init(dev_priv);
acpi_video_register();
}
@@ -1395,7 +1395,7 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
i915_audio_component_cleanup(dev_priv);
intel_gpu_ips_teardown();
acpi_video_unregister();
- intel_opregion_fini(dev_priv->dev);
+ intel_opregion_fini(dev_priv);
i915_teardown_sysfs(dev_priv->dev);
i915_gem_shrinker_cleanup(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dba03c026151..7627bbec8e37 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -628,10 +628,10 @@ static int i915_drm_suspend(struct drm_device *dev)
i915_save_state(dev);
opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
- intel_opregion_notify_adapter(dev, opregion_target_state);
+ intel_opregion_notify_adapter(dev_priv, opregion_target_state);
intel_uncore_forcewake_reset(dev_priv, false);
- intel_opregion_fini(dev);
+ intel_opregion_fini(dev_priv);
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
@@ -749,7 +749,7 @@ static int i915_drm_resume(struct drm_device *dev)
mutex_unlock(&dev->struct_mutex);
i915_restore_state(dev);
- intel_opregion_setup(dev);
+ intel_opregion_setup(dev_priv);
intel_init_pch_refclk(dev);
drm_mode_config_reset(dev);
@@ -794,7 +794,7 @@ static int i915_drm_resume(struct drm_device *dev)
/* Config may have changed between suspend and resume */
drm_helper_hpd_irq_event(dev);
- intel_opregion_init(dev);
+ intel_opregion_init(dev_priv);
intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
@@ -802,7 +802,7 @@ static int i915_drm_resume(struct drm_device *dev)
dev_priv->modeset_restore = MODESET_DONE;
mutex_unlock(&dev_priv->modeset_restore_lock);
- intel_opregion_notify_adapter(dev, PCI_D0);
+ intel_opregion_notify_adapter(dev_priv, PCI_D0);
drm_kms_helper_poll_enable(dev);
@@ -1596,14 +1596,14 @@ static int intel_runtime_suspend(struct device *device)
* FIXME: We really should find a document that references the arguments
* used below!
*/
- if (IS_BROADWELL(dev)) {
+ if (IS_BROADWELL(dev_priv)) {
/*
* On Broadwell, if we use PCI_D1 the PCH DDI ports will stop
* being detected, and the call we do at intel_runtime_resume()
* won't be able to restore them. Since PCI_D3hot matches the
* actual specification and appears to be working, use it.
*/
- intel_opregion_notify_adapter(dev, PCI_D3hot);
+ intel_opregion_notify_adapter(dev_priv, PCI_D3hot);
} else {
/*
* current versions of firmware which depend on this opregion
@@ -1612,7 +1612,7 @@ static int intel_runtime_suspend(struct device *device)
* to distinguish it from notifications that might be sent via
* the suspend path.
*/
- intel_opregion_notify_adapter(dev, PCI_D1);
+ intel_opregion_notify_adapter(dev_priv, PCI_D1);
}
assert_forcewakes_inactive(dev_priv);
@@ -1636,7 +1636,7 @@ static int intel_runtime_resume(struct device *device)
WARN_ON_ONCE(atomic_read(&dev_priv->pm.wakeref_count));
disable_rpm_wakeref_asserts(dev_priv);
- intel_opregion_notify_adapter(dev, PCI_D0);
+ intel_opregion_notify_adapter(dev_priv,
[Intel-gfx] [PATCH 2/2] drm/i915/opregion: Rename init/fini functions to register/unregister
Current intel_opregion_init is called during the driver registration
phase and intel_opregion_fini from the unregistration phase. Rename the
functions show that this is clear from their names. The phases tell us
what we expect the existing hw state to be, e.g. whether interrupts are
still enabled etc.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_opregion.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 363bd5884a56..07edaed9d5a2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1376,7 +1376,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
if (INTEL_INFO(dev_priv)->num_pipes) {
/* Must be done after probing outputs */
- intel_opregion_init(dev_priv);
+ intel_opregion_register(dev_priv);
acpi_video_register();
}
@@ -1395,7 +1395,7 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
i915_audio_component_cleanup(dev_priv);
intel_gpu_ips_teardown();
acpi_video_unregister();
- intel_opregion_fini(dev_priv);
+ intel_opregion_unregister(dev_priv);
i915_teardown_sysfs(dev_priv->dev);
i915_gem_shrinker_cleanup(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7627bbec8e37..943d7b222fd4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -631,7 +631,7 @@ static int i915_drm_suspend(struct drm_device *dev)
intel_opregion_notify_adapter(dev_priv, opregion_target_state);
intel_uncore_forcewake_reset(dev_priv, false);
- intel_opregion_fini(dev_priv);
+ intel_opregion_unregister(dev_priv);
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
@@ -794,7 +794,7 @@ static int i915_drm_resume(struct drm_device *dev)
/* Config may have changed between suspend and resume */
drm_helper_hpd_irq_event(dev);
- intel_opregion_init(dev_priv);
+ intel_opregion_register(dev_priv);
intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index caf7e45ae663..17fe272e9ef8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3609,8 +3609,8 @@ bool intel_bios_is_port_hpd_inverted(struct
drm_i915_private *dev_priv,
/* intel_opregion.c */
#ifdef CONFIG_ACPI
extern int intel_opregion_setup(struct drm_i915_private *dev_priv);
-extern void intel_opregion_init(struct drm_i915_private *dev_priv);
-extern void intel_opregion_fini(struct drm_i915_private *dev_priv);
+extern void intel_opregion_register(struct drm_i915_private *dev_priv);
+extern void intel_opregion_unregister(struct drm_i915_private *dev_priv);
extern void intel_opregion_asle_intr(struct drm_i915_private *dev_priv);
extern int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,
bool enable);
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index f9cdec866e49..f6d8a21d2c49 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -778,7 +778,7 @@ static void intel_setup_cadls(struct drm_i915_private
*dev_priv)
} while (++i < 8 && disp_id != 0);
}
-void intel_opregion_init(struct drm_i915_private *dev_priv)
+void intel_opregion_register(struct drm_i915_private *dev_priv)
{
struct intel_opregion *opregion = &dev_priv->opregion;
@@ -805,7 +805,7 @@ void intel_opregion_init(struct drm_i915_private *dev_priv)
}
}
-void intel_opregion_fini(struct drm_i915_private *dev_priv)
+void intel_opregion_unregister(struct drm_i915_private *dev_priv)
{
struct intel_opregion *opregion = &dev_priv->opregion;
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/2] Revert "drm/i915: Allow nonblocking update of pageflips."
This reverts commit d55dbd06bb5e1399aba9ab5227465339d1bbefff.
It lacks a description, removes the flip trace point,
doesn't handle -EBUSY if a flip is already queued
and needs to be redone.
Signed-off-by: Maarten Lankhorst
Cc: Ville Syrjälä
---
Patch 3/2 which CI probably doesn't handle correctly,
so trybot results should be on https://patchwork.freedesktop.org/series/7570/
drivers/gpu/drm/i915/intel_display.c | 350 ++-
1 file changed, 266 insertions(+), 84 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 21c0a2f3102b..f49ef629c4a8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -108,6 +108,8 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
+static void intel_begin_crtc_commit(struct drm_crtc *, struct drm_crtc_state
*);
+static void intel_finish_crtc_commit(struct drm_crtc *, struct drm_crtc_state
*);
static void skl_init_scalers(struct drm_device *dev, struct intel_crtc
*intel_crtc,
struct intel_crtc_state *crtc_state);
static void skylake_pfit_enable(struct intel_crtc *crtc);
@@ -10984,7 +10986,7 @@ static void intel_mmio_flip_work_func(struct
work_struct *w)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_request *req;
- int i, ret;
+ int i;
if (!needs_modeset(&crtc_state->base) && crtc_state->update_pipe) {
work->put_power_domains =
@@ -11006,14 +11008,7 @@ static void intel_mmio_flip_work_func(struct
work_struct *w)
&dev_priv->rps.mmioflips));
}
- ret = drm_crtc_vblank_get(crtc);
- I915_STATE_WARN(ret < 0, "enabling vblank failed with %i\n", ret);
-
- if (work->num_planes &&
- work->old_plane_state[0]->base.plane == crtc->primary)
- intel_fbc_enable(intel_crtc, work->new_crtc_state,
work->new_plane_state[0]);
-
- intel_frontbuffer_flip_prepare(dev, work->fb_bits);
+ intel_frontbuffer_flip_prepare(dev, crtc_state->fb_bits);
intel_pipe_update_start(intel_crtc);
if (!needs_modeset(&crtc_state->base)) {
@@ -11032,15 +11027,206 @@ static void intel_mmio_flip_work_func(struct
work_struct *w)
struct intel_plane_state *new_plane_state =
work->new_plane_state[i];
struct intel_plane *plane =
to_intel_plane(new_plane_state->base.plane);
- if (new_plane_state->visible)
- plane->update_plane(&plane->base, crtc_state,
new_plane_state);
- else
- plane->disable_plane(&plane->base, crtc);
+ plane->update_plane(&plane->base, crtc_state, new_plane_state);
}
intel_pipe_update_end(intel_crtc, work);
}
+static struct fence *intel_get_excl_fence(struct drm_i915_gem_object *obj)
+{
+ struct reservation_object *resv;
+
+
+ if (!obj->base.dma_buf)
+ return NULL;
+
+ resv = obj->base.dma_buf->resv;
+
+ /* For framebuffer backed by dmabuf, wait for fence */
+ while (1) {
+ struct fence *fence_excl, *ret = NULL;
+
+ rcu_read_lock();
+
+ fence_excl = rcu_dereference(resv->fence_excl);
+ if (fence_excl)
+ ret = fence_get_rcu(fence_excl);
+
+ rcu_read_unlock();
+
+ if (ret == fence_excl)
+ return ret;
+ }
+}
+
+static int intel_crtc_page_flip(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *event,
+ uint32_t page_flip_flags)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_plane_state *old_state, *new_state = NULL;
+ struct drm_crtc_state *new_crtc_state = NULL;
+ struct drm_framebuffer *old_fb = crtc->primary->state->fb;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_plane *primary = crtc->primary;
+ struct intel_flip_work *work;
+ int ret;
+
+ old_state = crtc->primary->state;
+
+ if (!crtc->state->active)
+ return -EINVAL;
+
+ /*
+* drm_mode_page_flip_ioctl() should already catch this, but double
+* check to be safe. In the future we may enable pageflipping from
+* a disabled primary plane.
+*/
+ if (WARN_ON(intel_fb_obj(old_fb) == NULL))
+ return -EBUSY;
+
+ /* Can't change pixel format via MI
[Intel-gfx] [PATCH 1/3] drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB
From: Ville Syrjälä SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck in an infinite batch buffer loop. The GPU apparently hogs something critical and CPUs start to lose interrupts and whatnot. We can keep the system limping along by unmasking some interrupts in GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for that task, so let's never mask it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 29bdd79d9039..576e98744a2d 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4719,7 +4719,7 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv) else gen6_set_rps(dev_priv, dev_priv->rps.idle_freq); dev_priv->rps.last_adj = 0; - I915_WRITE(GEN6_PMINTRMSK, 0x); + I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, ~0)); } mutex_unlock(&dev_priv->rps.hw_lock); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] *ERROR* Hangcheck timer elapsed... render ring idle
On Mon, 2016-05-23 at 11:06 +0300, Jani Nikula wrote: > On Fri, 20 May 2016, Chris wrote: > > I'm still seeing this periodically, previous to today it happened on > > April 24th. Doesn't matter what I'm doing the video will freeze however > > the cursor will still move. Only option is to SSH in to the system from > > my tablet and do a reboot. > > > > Note: This has been going on since Sept 13, 2014. There could be as > > little as a few hours between freezes or as much as 30 or more days. > > Your report is lacking in details... like which kernel you're running, > and have you tried a recent kernel. > > Please file a bug at [1], and attach dmesg with drm.debug=14 on the bug. > > BR, > Jani. > > > [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel > Jani, I have previously filed a bug or added information to a bug on this: [1] https://bugs.freedesktop.org/show_bug.cgi?id=75394 [2] https://bugs.freedesktop.org/show_bug.cgi?id=91495 The kernel being run at the time of the freeze was when this post was made - 3.19.0-59-generic #65~14.04.1-Ubuntu SMP Tue Apr 19 18:57:09 UTC 2016 The video froze again this morning, however the 'Hangcheck..render ring idle' error was not noted in my syslog. The kernel being run at the time this happened - 3.19.0-59-generic #66~14.04.1-Ubuntu SMP Fri May 13 17:27:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I've added drm.debug=14 to my grub.cfg file to get the output you asked for in the next freeze. Do you want me to open a new bug or add to [1] or [2]? -- Chris KeyID 0xE372A7DA98E6705C 31.11°N 97.89°W (Elev. 1092 ft) 08:53:52 up 25 min, 1 user, load average: 0.42, 0.35, 0.53 Ubuntu 14.04.4 LTS, kernel 3.19.0-59-generic #66~14.04.1-Ubuntu SMP Fri May 13 17:27:10 UTC 2016 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC][PATCH 3/3] drm/i915: Make RPS enable immediate
From: Ville Syrjälä
On SNB (at least) it's dangeruopus to hang the GPU with an infinite
batch buffer loop while RPS is disabled. The only thing that keeps
the system going in such circumstances are the internal RPS timers,
so we should never feed the GPU with RPS disabled unless we want to
risk a total system hang.
Previously we didn't fully disable RPS, but that changes in
commit 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control
register")
so we probably didn't see the problem so often previously. But
even before that we were at the mercy of the BIOS for the initial
RPS state, so if the BIOS didn't enable RPS a GPU hang immediately
upon boot could have been fatal.
To avoid the problems let's just make the RPS enable immediate.
This renders the delayed_resume_work useless actually. We could perhaps
just move the ring freq table initialization to the work and do the
other stull synchronously?
Fixes: 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control
register")
Signed-off-by: Ville Syrjälä
---
This is more and RFC at this point. Perhaps we might want to keep the delayed
work but just for the ring freq table update (which is the main reson this whole
thing exists in the first place). Another factor is that wait_for() is not
exactly optiomal currently, so it makes the operation slower than it needs to
be. Would need some hard numbers to see if it's worth keeping the delayed work
or not I suppose.
drivers/gpu/drm/i915/intel_pm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 817c84c22782..e65c5c2b9b4e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6505,6 +6505,7 @@ void intel_enable_gt_powersave(struct drm_i915_private
*dev_priv)
if (schedule_delayed_work(&dev_priv->rps.delayed_resume_work,
round_jiffies_up_relative(HZ)))
intel_runtime_pm_get_noresume(dev_priv);
+ flush_delayed_work(&dev_priv->rps.delayed_resume_work);
}
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Building GVT-g as a sub-module of i915
On ma, 2016-05-23 at 07:03 +, Wang, Zhi A wrote: > Hi Guys: > I'm trying to make GVT-g as a sub-module of i915 in the next > version patchset. The basic idea is to introduce a "gvt-g pre-enabled > state" in i915. I think it should be a kernel option. > Could not the GGTT partitioning be done ad hoc by moving objects out of the memory areas to be ballooned? This way gvt module could just be loaded and it would work, instead of having to reboot and change kernel parameters. > When this kernel option is enabled by user, i915 will do GGTT > partition and save HW initial MMIO snapshot for gvt-g module during > loading. Like discussed in the F2F, I really think taking a MMIO snapshot in Dom0 at boot sounds a little suspicious to me as changing Dom0 BIOS settings could very obscurely break VM booting, especially if migration is at some point wanted. It will also leak the Dom0 boot state to a VM, which I do not like either. I would be more comfortable if the VMs are booting to a driver-fixed MMIO state. Any thoughts by others on these? Regards, Joonas > When GVT-g modules is loaded, first it should check if the "gvt-g > pre-eanbled state" is enabled in i915. If yes, then it will use the > snapshot in i915 and continue to load. If no, then bail out. > > Thanks, > Zhi.-- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Don't frob with RPS around GPU reset
From: Ville Syrjälä
Based on my observations GPU reset doesn't clobber the RPS state, so
frobbing with RPS around GPU reset seems rather pointless. Just get
rid of it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 11 ---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 9 -
3 files changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dba03c026151..3794dc67caa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -930,8 +930,6 @@ int i915_reset(struct drm_i915_private *dev_priv)
unsigned reset_counter;
int ret;
- intel_reset_gt_powersave(dev_priv);
-
mutex_lock(&dev->struct_mutex);
/* Clear any previous failed attempts at recovery. Time to try again. */
@@ -994,15 +992,6 @@ int i915_reset(struct drm_i915_private *dev_priv)
mutex_unlock(&dev->struct_mutex);
- /*
-* rps/rc6 re-init is necessary to restore state lost after the
-* reset and the re-install of gt irqs. Skip for ironlake per
-* previous concerns that it doesn't respond well to some forms
-* of re-init after reset.
-*/
- if (INTEL_INFO(dev)->gen > 5)
- intel_enable_gt_powersave(dev_priv);
-
return 0;
error:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0741b2d3aa65..ca3b69b61f06 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1652,7 +1652,6 @@ void intel_cleanup_gt_powersave(struct drm_i915_private
*dev_priv);
void intel_enable_gt_powersave(struct drm_i915_private *dev_priv);
void intel_disable_gt_powersave(struct drm_i915_private *dev_priv);
void intel_suspend_gt_powersave(struct drm_i915_private *dev_priv);
-void intel_reset_gt_powersave(struct drm_i915_private *dev_priv);
void gen6_update_ring_freq(struct drm_i915_private *dev_priv);
void gen6_rps_busy(struct drm_i915_private *dev_priv);
void gen6_rps_reset_ei(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 576e98744a2d..817c84c22782 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6508,15 +6508,6 @@ void intel_enable_gt_powersave(struct drm_i915_private
*dev_priv)
}
}
-void intel_reset_gt_powersave(struct drm_i915_private *dev_priv)
-{
- if (INTEL_INFO(dev_priv)->gen < 6)
- return;
-
- gen6_suspend_rps(dev_priv);
- dev_priv->rps.enabled = false;
-}
-
static void ibx_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Building GVT-g as a sub-module of i915
On Mon, May 23, 2016 at 4:16 PM, Joonas Lahtinen wrote: > On ma, 2016-05-23 at 07:03 +, Wang, Zhi A wrote: >> Hi Guys: >> I'm trying to make GVT-g as a sub-module of i915 in the next >> version patchset. The basic idea is to introduce a "gvt-g pre-enabled >> state" in i915. I think it should be a kernel option. >> > > Could not the GGTT partitioning be done ad hoc by moving objects out of > the memory areas to be ballooned? This way gvt module could just be > loaded and it would work, instead of having to reboot and change kernel > parameters. Yeah, if we want to make gvt loadable, then it should indeed not reserve anything if it's not loaded. Otherwise there's no point in that option, and it's no better than just a static Kconfig+ maybe i915 module option. If dynamic loading is too hard for v1, then I'd say we should postpone it to post-merging. GVT-g is already tricky to integrate as-is. >> When this kernel option is enabled by user, i915 will do GGTT >> partition and save HW initial MMIO snapshot for gvt-g module during >> loading. > > Like discussed in the F2F, I really think taking a MMIO snapshot in > Dom0 at boot sounds a little suspicious to me as changing Dom0 BIOS > settings could very obscurely break VM booting, especially if migration > is at some point wanted. It will also leak the Dom0 boot state to a VM, > which I do not like either. > > I would be more comfortable if the VMs are booting to a driver-fixed > MMIO state. > > Any thoughts by others on these? Golden MMIO state sounds like a good idea. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Bump pin_count to UINT_MAX.
On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote: > With nonblocking unpin there can be many cursor pins before they're > cleared by the next page flip. > > Fix this by extending pin_count to the full 32-bit to prevent a > WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT) This is a hack that affects non-KMS paths. Being able to process binding in a single operation on all architectures is something we want to preserve. Why is every cursor movement generating an unpin work? Should I just start poking registers from userspace to avoid a silly kerenl? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] *ERROR* Hangcheck timer elapsed... render ring idle
On Mon, 23 May 2016, Chris wrote: > On Mon, 2016-05-23 at 11:06 +0300, Jani Nikula wrote: >> On Fri, 20 May 2016, Chris wrote: >> > I'm still seeing this periodically, previous to today it happened on >> > April 24th. Doesn't matter what I'm doing the video will freeze however >> > the cursor will still move. Only option is to SSH in to the system from >> > my tablet and do a reboot. >> > >> > Note: This has been going on since Sept 13, 2014. There could be as >> > little as a few hours between freezes or as much as 30 or more days. >> >> Your report is lacking in details... like which kernel you're running, >> and have you tried a recent kernel. >> >> Please file a bug at [1], and attach dmesg with drm.debug=14 on the bug. >> >> BR, >> Jani. >> >> >> [1] >> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel >> > Jani, I have previously filed a bug or added information to a bug on > this: How was I supposed to know...? > [1] https://bugs.freedesktop.org/show_bug.cgi?id=75394 > [2] https://bugs.freedesktop.org/show_bug.cgi?id=91495 > > The kernel being run at the time of the freeze was when this post was > made - 3.19.0-59-generic #65~14.04.1-Ubuntu SMP Tue Apr 19 18:57:09 UTC > 2016 > > The video froze again this morning, however the 'Hangcheck..render ring > idle' error was not noted in my syslog. The kernel being run at the time > this happened - 3.19.0-59-generic #66~14.04.1-Ubuntu SMP Fri May 13 > 17:27:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > I've added drm.debug=14 to my grub.cfg file to get the output you asked > for in the next freeze. Do you want me to open a new bug or add to [1] > or [2]? If you keep running 3.19, neither. Please grab the latest kernel, and run that, and update your existing bug when it occurs on that one. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB
On Mon, May 23, 2016 at 05:09:41PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck > in an infinite batch buffer loop. The GPU apparently hogs something > critical and CPUs start to lose interrupts and whatnot. We can keep > the system limping along by unmasking some interrupts in > GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for > that task, so let's never mask it. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_pm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 29bdd79d9039..576e98744a2d 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4719,7 +4719,7 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv) > else > gen6_set_rps(dev_priv, dev_priv->rps.idle_freq); > dev_priv->rps.last_adj = 0; > - I915_WRITE(GEN6_PMINTRMSK, 0x); > + I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, ~0)); gen6_sanitize_rps_pm_mask() With that, Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v2,01/11] drm/i915: Rename struct intel_context (rev2)
== Series Details == Series: series starting with [v2,01/11] drm/i915: Rename struct intel_context (rev2) URL : https://patchwork.freedesktop.org/series/7564/ State : failure == Summary == Series 7564v2 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/7564/revisions/2/mbox Test gem_exec_flush: Subgroup basic-batch-kernel-default-cmd: fail -> PASS (ro-byt-n2820) fail -> PASS (fi-byt-n2820) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a-frame-sequence: pass -> FAIL (ro-snb-i7-2620M) fi-bdw-i7-5557u total:209 pass:197 dwarn:0 dfail:0 fail:0 skip:12 fi-bsw-n3050 total:209 pass:167 dwarn:0 dfail:0 fail:2 skip:40 fi-byt-n2820 total:209 pass:169 dwarn:0 dfail:0 fail:2 skip:38 fi-hsw-i7-4770k total:209 pass:190 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-i7-4770r total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 fi-skl-i5-6260u total:209 pass:196 dwarn:2 dfail:0 fail:0 skip:11 fi-skl-i7-6700k total:209 pass:182 dwarn:2 dfail:0 fail:0 skip:25 fi-snb-i7-2600 total:209 pass:170 dwarn:0 dfail:0 fail:0 skip:39 ro-bdw-i5-5250u total:209 pass:172 dwarn:0 dfail:0 fail:0 skip:37 ro-bdw-i7-5557U total:209 pass:197 dwarn:0 dfail:0 fail:0 skip:12 ro-bdw-i7-5600u total:209 pass:179 dwarn:0 dfail:0 fail:2 skip:28 ro-bsw-n3050 total:209 pass:168 dwarn:0 dfail:0 fail:2 skip:39 ro-byt-n2820 total:209 pass:170 dwarn:0 dfail:0 fail:2 skip:37 ro-hsw-i3-4010u total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-hsw-i7-4770r total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk-i7-620lm total:209 pass:146 dwarn:0 dfail:0 fail:1 skip:62 ro-ilk1-i5-650 total:204 pass:146 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:209 pass:177 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:209 pass:181 dwarn:0 dfail:0 fail:0 skip:28 ro-skl-i7-6700hq total:204 pass:180 dwarn:2 dfail:0 fail:0 skip:22 ro-snb-i7-2620M total:209 pass:169 dwarn:0 dfail:0 fail:2 skip:38 Results at /archive/results/CI_IGT_test/RO_Patchwork_974/ 54afd5a drm-intel-nightly: 2016y-05m-23d-13h-38m-05s UTC integration manifest 0d3420b drm/i915/debugfs: Show context objects in i915_gem_objects 0f5ae8c drm/i915: Rearrange i915_gem_context 82b468f drm/i915: Merge legacy+execlists context structs 1dcca1e drm/i915: Put the kernel_context in drm_i915_private next to its friends f225058 drm/i915: Show i915_gem_context owner in debugfs d5050ea drm/i915: Move pinning of dev_priv->kernel_context into its creator 3e18a92 drm/i915: Name the inner most per-engine intel_context struct ab016a4 drm/i915: Rename i915_gem_context_reference/unreference() 2358d91 drm/i915: Rename and inline i915_gem_context_get() 409ed24 drm/i915: Apply lockdep annotations to i915_gem_context.c 0616d56 drm/i915: Rename struct intel_context ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Don't frob with RPS around GPU reset
On Mon, May 23, 2016 at 05:09:42PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Based on my observations GPU reset doesn't clobber the RPS state, so > frobbing with RPS around GPU reset seems rather pointless. Just get > rid of it. > > Signed-off-by: Ville Syrjälä Testcase: igt/pm_rpm/reset ? Looks like that is the desired test. Maybe make it basic and see what CI says :) Actually it probably should be a basic test considering how often we hang. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
