Re: [Intel-gfx] Problem with emgd on fedora 18
Thanks Matt, Device is builded for emdedded use and with specific embedded functionality ( camera ) ... I know that I need to configure EMGD but I don't know how, I try something but it was bad idea. Best regards, Anteja On Thu, Oct 13, 2016 at 10:45 PM, Matt Roper wrote: > On Thu, Oct 13, 2016 at 03:28:05PM +0300, Jani Nikula wrote: > > On Thu, 13 Oct 2016, Anteja Vuk Macek wrote: > > > Hi, > > > I work with Fedora 18 and I'm new in linux world. I have problem with > emgd > > > driver. I put emgd driver in kernel and build kernel. Moduled is build > like > > > loadable module. But problem is when I load driver , you can see photo > > > https://my.syncplicity.com/share/skvhanon0sxj5f8/IMG_20161011_104347 > . What > > > I need to do to fix my problem with driver ? > > > > This list is for the upstream Linux drm/i915 driver and related > > stuff. We don't support the emgd driver on this list. Generally we don't > > even have a clue here about emgd, but perhaps Matt can give you pointers > > if and where you can get support for it. > > > > BR, > > Jani. > > Hi Anteja, > > It's hard to tell what's wrong just from the screenshot, but my first > guess would be a panel (monitor) timing misconfiguration. EMGD isn't > really intended for traditional PC-style operation, but rather for use > in "embedded" devices (i.e., specialized appliance-like devices like > store kiosks, automobiles, casino gaming machines, etc.). Embedded > devices generally have a permanently fixed hardware and software > configuration so EMGD defaults to pulling all kinds of configuration > information (including monitor timing data and such) from a special > configuration file rather than autoprobing; if that config file has the > wrong information, you can easily wind up with corrupt or > non-functioning displays. > > You mentioned that you're new to Linux...are you building an embedded > device which you need EMGD's specific embedded functionality for? If > so, I'll try to find you an appropriate support channel for you to get > help (I haven't worked with EMGD for a few years, so I probably can't > help with any specifics at this point). If you're not building an > embedded device, then you'd probably be better off using the standard > opensource drivers that come as part of your Linux distribution (and > using as new of a distribution as possible to ensure that the drivers > that come with it are the latest, most up-to-date versions). > > > Matt > > > > > > > > > > > Emgd driver version : 36.1.25_3900 > > > > > > Best regards, > > > > > > Anteja Vuk - Macek > > > Software Engineer > > > > > > Dolotron d.o.o. > > > Ziskovec 141 > > > HR-4 Cakovec > > > Croatia > > > Tel: ++385 (40) 865 205 > > > Fax: ++385 (40) 865 732 > > > mailto: anteja...@dolotron.com > > > _ > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > > Jani Nikula, Intel Open Source Technology Center > > -- > Matt Roper > Graphics Software Engineer > IoTG Platform Enabling & Development > Intel Corporation > (916) 356-2795 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)
> > > > == Series Details == > > > > > > > > Series: drm/i915: Allocate intel_engine_cs structure only for the > > > > enabled > > > engines (rev3) > > > > URL : https://patchwork.freedesktop.org/series/13435/ > > > > State : warning > > > > > > > > == Summary == > > > > > > > > Series 13435v3 drm/i915: Allocate intel_engine_cs structure only > > > > for the enabled engines > > > > https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/3 > > > > /mbo > > > > x/ > > > > > > > > Test vgem_basic: > > > > Subgroup unload: > > > > pass -> SKIP (fi-skl-6260u) > > > > pass -> SKIP (fi-skl-6700hq) > > > > skip -> PASS (fi-skl-6700k) > > > > > > > Checked with Chris about the above failure. > > > He said that the above unload failure for vgem module can't be > > > attributed to the patch, most likely a CI framework issue. > > Yes, this test is still behaving badly especially with SKL systems but also > > with > bdw and kbl. > > Are the test run in the order defined by fast-feedback.testlist ? > I intended the vgem unload test to be run as the first vgem testcase to > minimise the chance of a stray module leak. Can we define the order within > CI? Can we put comments into fast-feedback.testlist ? My understanding, yes, we are running on that order. Adding comment, no I think no, Petri, Tomi? > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid: Only print the bad edid when aborting
> == Summary == > > Series 13747v1 drm/edid: Only print the bad edid when aborting > https://patchwork.freedesktop.org/api/1.0/series/13747/revisions/1/mbox/ > > Test drv_module_reload_basic: > skip -> PASS (fi-skl-6770hq) > Test kms_busy: > Subgroup basic-flip-default-b: > pass -> DMESG-WARN (fi-skl-6700k) Same still: [ 427.065188] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun I suppose this still? https://bugs.freedesktop.org/show_bug.cgi?id=98041 > Test kms_pipe_crc_basic: > Subgroup read-crc-pipe-b-frame-sequence: > dmesg-warn -> PASS (fi-ilk-650) > Test vgem_basic: > Subgroup unload: > skip -> PASS (fi-skl-6770hq) > skip -> PASS (fi-hsw-4770) > > fi-bdw-5557u total:246 pass:231 dwarn:0 dfail:0 fail:0 skip:15 > fi-bsw-n3050 total:246 pass:204 dwarn:0 dfail:0 fail:0 skip:42 > fi-bxt-t5700 total:246 pass:216 dwarn:0 dfail:0 fail:0 skip:30 > fi-byt-n2820 total:246 pass:210 dwarn:0 dfail:0 fail:1 skip:35 > fi-hsw-4770 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 > fi-hsw-4770r total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 > fi-ilk-650 total:246 pass:184 dwarn:0 dfail:0 fail:2 skip:60 > fi-ivb-3520m total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 > fi-ivb-3770 total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 > fi-kbl-7200u total:246 pass:222 dwarn:0 dfail:0 fail:0 skip:24 > fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 > fi-skl-6700hqtotal:246 pass:223 dwarn:0 dfail:0 fail:0 skip:23 > fi-skl-6700k total:246 pass:220 dwarn:2 dfail:0 fail:0 skip:24 > fi-skl-6770hqtotal:246 pass:230 dwarn:1 dfail:0 fail:1 skip:14 > fi-snb-2520m total:246 pass:210 dwarn:0 dfail:0 fail:0 skip:36 > fi-snb-2600 total:246 pass:209 dwarn:0 dfail:0 fail:0 skip:37 > > Results at /archive/results/CI_IGT_test/Patchwork_2710/ > > dbcf6fbb541e70fac7db669631958eab2e4e0d9c drm-intel-nightly: 2016y-10m- > 13d-15h-31m-19s UTC integration manifest > 88e63c4 drm/edid: Only print the bad edid when aborting > Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC
On Thu, Oct 13, 2016 at 08:45:45AM -0700, Jeff McGee wrote: > On Mon, Oct 03, 2016 at 11:42:56AM -0700, Anusha Srivatsa wrote: > > From: Peter Antoine > > > > HuC firmware css header has almost exactly same definition as GuC > > firmware except for the sw_version. Also, add a new member fw_type > > into intel_uc_fw to indicate what kind of fw it is. So, the loader > > will pull right sw_version from header. > > > > v2: rebased on-top of drm-intel-nightly > > v3: rebased on-top of drm-intel-nightly (again). > > v4: rebased + spaces. > > v7: rebased. > > v8: rebased. > > > > Tested-by: Xiang Haihao > > Signed-off-by: Anusha Srivatsa > > Signed-off-by: Alex Dai > > Signed-off-by: Peter Antoine > > Reviewed-by: Dave Gordon > > --- > > drivers/gpu/drm/i915/intel_guc.h| 4 > > drivers/gpu/drm/i915/intel_guc_fwif.h | 16 ++--- > > drivers/gpu/drm/i915/intel_guc_loader.c | 41 > > ++--- > > 3 files changed, 45 insertions(+), 16 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_guc.h > > b/drivers/gpu/drm/i915/intel_guc.h > > index b134a41..812e4ca 100644 > > --- a/drivers/gpu/drm/i915/intel_guc.h > > +++ b/drivers/gpu/drm/i915/intel_guc.h > > @@ -98,6 +98,9 @@ enum intel_uc_fw_status { > > UC_FIRMWARE_SUCCESS > > }; > > > > +#define UC_FW_TYPE_GUC 0 > > +#define UC_FW_TYPE_HUC 1 > > + > > /* > > * This structure encapsulates all the data needed during the process > > * of fetching, caching, and loading the firmware image into the GuC. > > @@ -115,6 +118,7 @@ struct intel_uc_fw { > > uint16_t major_ver_found; > > uint16_t minor_ver_found; > > > > + uint32_t fw_type; > > uint32_t header_size; > > uint32_t header_offset; > > uint32_t rsa_size; > > diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h > > b/drivers/gpu/drm/i915/intel_guc_fwif.h > > index e40db2d..b38b6b4 100644 > > --- a/drivers/gpu/drm/i915/intel_guc_fwif.h > > +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h > > @@ -154,7 +154,7 @@ > > * The GuC firmware layout looks like this: > > * > > * +---+ > > - * |guc_css_header | > > + * | uc_css_header | > > * | | > > * | contains major/minor version | > > * +---+ > > @@ -181,9 +181,16 @@ > > * 3. Length info of each component can be found in header, in dwords. > > * 4. Modulus and exponent key are not required by driver. They may not > > appear > > *in fw. So driver will load a truncated firmware in this case. > > + * > > + * HuC firmware layout is same as GuC firmware. > > + * > > + * HuC firmware css header is different. However, the only difference is > > where > > + * the version information is saved. The uc_css_header is unified to > > support > > + * both. Driver should get HuC version from uc_css_header.huc_sw_version, > > while > > + * uc_css_header.guc_sw_version for GuC. > > */ > > > > -struct guc_css_header { > > +struct uc_css_header { > > uint32_t module_type; > > /* header_size includes all non-uCode bits, including css_header, rsa > > * key, modulus key and exponent data. */ > > @@ -214,7 +221,10 @@ struct guc_css_header { > > > > char username[8]; > > char buildnumber[12]; > > - uint32_t device_id; > > + union { > > + uint32_t device_id; > > + uint32_t huc_sw_version; > > + }; > > uint32_t guc_sw_version; > > uint32_t prod_preprod_fw; > > uint32_t reserved[12]; > > I propose renaming the device_id field in this union to > 'guc_client_branch_version'. GuC uses this position to store a client > version and branch version. I'm not sure where the 'device_id' term came > from. We don't reference this currently but may need to in the future > so might as well name it properly. At the very least we should probably > make it guc_device_id, to help indicate that it applies to guc fw only. > > In that same vein, can we make guc_sw_version into a union as below to > reinforce the difference to huc? > > union { > uint32_t guc_sw_version; > uint32_t huc_reserved; > }; > > Jeff > One correction. The branch version is considered the "major" and the client version the "minor", so the better name for this field is 'guc_branch_client_version'. > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c > > b/drivers/gpu/drm/i915/intel_guc_loader.c > > index 493295d..0b863a1 100644 > > --- a/drivers/gpu/drm/i915/intel_guc_loader.c > > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c > > @@ -586,7 +586,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct > > intel_uc_fw *uc_fw) > > struct pci_dev *pdev = dev->pdev; > > struct drm_i915_gem_object *obj; > > const struct firmware *fw; > > - struct guc_css_header *css; > > + struct uc_css_header *css; > > size_t size; > > int err; > >
Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2
Tested-by: Libin Yang Regards, Libin > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Dhinakaran Pandiyan > Sent: Friday, October 14, 2016 2:04 AM > To: intel-...@freedesktop.org > Cc: Nikula, Jani ; Kp, Jeeja ; > Libin Yang ; Pandiyan, Dhinakaran > > Subject: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is > enabled with 4 lanes and HBR2 > > According to BSpec, cdclk has to be not less than 432 MHz with DP audio > enabled, port width x4, and link rate HBR2 (5.4 GHz) > > Having a lower cdclk triggers pipe underruns, which then lead to displays > continuously cycling off and on. This is essential for DP MST audio as the > link > is trained at HBR2 and 4 lanes by default. > > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907 > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_display.c | 47 > +--- > 1 file changed, 43 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index cfcb03f..6a05183 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct > drm_atomic_state *state) > return 0; > } > > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state) { > + > + struct drm_crtc_state *crtc_state; > + struct drm_crtc *crtc; > + int i; > + > + /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz, > + * audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else > + * there may be audio corruption or screen corruption." > + */ > + > + for_each_crtc_in_state(state, crtc, crtc_state, i) { > + struct intel_crtc_state *pipe_config = > + to_intel_crtc_state(crtc_state); > + > + return (intel_crtc_has_dp_encoder(pipe_config) && > + pipe_config->has_audio && > + pipe_config->port_clock == 54 && > + pipe_config->lane_count == 4); > + } > + > + return false; > +} > + > static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state) { > int max_pixclk = ilk_max_pixel_rate(state); > + int cdclk, min_cdclk = 0; > struct intel_atomic_state *intel_state = > to_intel_atomic_state(state); > > - intel_state->cdclk = intel_state->dev_cdclk = > - bxt_calc_cdclk(max_pixclk); > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = bxt_calc_cdclk(432000); > + > + cdclk = bxt_calc_cdclk(max_pixclk); > + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk); > > if (!intel_state->active_crtcs) > intel_state->dev_cdclk = bxt_calc_cdclk(0); @@ -10374,7 > +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct > drm_atomic_state *state) > struct drm_i915_private *dev_priv = to_i915(state->dev); > struct intel_atomic_state *intel_state = to_intel_atomic_state(state); > int max_pixclk = ilk_max_pixel_rate(state); > - int cdclk; > + int cdclk, min_cdclk = 0; > + > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = broadwell_calc_cdclk(432000); > > /* >* FIXME should also account for plane ratio @@ -10382,6 +10414,8 > @@ static int broadwell_modeset_calc_cdclk(struct drm_atomic_state *state) >*/ > cdclk = broadwell_calc_cdclk(max_pixclk); > > + cdclk = max(min_cdclk, cdclk); > + > if (cdclk > dev_priv->max_cdclk_freq) { > DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max > (%d kHz)\n", > cdclk, dev_priv->max_cdclk_freq); @@ -10411,7 > +10445,10 @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state > *state) > struct drm_i915_private *dev_priv = to_i915(state->dev); > const int max_pixclk = ilk_max_pixel_rate(state); > int vco = intel_state->cdclk_pll_vco; > - int cdclk; > + int cdclk, min_cdclk = 0; > + > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = skl_calc_cdclk(432000, vco); > > /* >* FIXME should also account for plane ratio @@ -10419,6 +10456,8 > @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state *state) >*/ > cdclk = skl_calc_cdclk(max_pixclk, vco); > > + cdclk = max(min_cdclk, cdclk); > + > /* >* FIXME move the cdclk caclulation to >* compute_config() so we can fail gracegully. > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams
On Mon, Oct 03, 2016 at 11:43:02AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > This patch will allow for getparams to return the status of the HuC. > As the HuC has to be validated by the GuC this patch uses the validated > status to show when the HuC is loaded and ready for use. You cannot use > the loaded status as with the GuC as the HuC is verified after it is > loaded and is not usable until it is verified. > > v2: removed the forewakes as the registers are already force-woken. > (T.Ursulin) > v4: rebased. > v5: rebased. > > Tested-by: Xiang Haihao > Signed-off-by: Anusha Srivatsa > Signed-off-by: Peter Antoine > --- > drivers/gpu/drm/i915/i915_drv.c | 4 > drivers/gpu/drm/i915/intel_huc.h| 2 +- > drivers/gpu/drm/i915/intel_huc_loader.c | 14 ++ > include/uapi/drm/i915_drm.h | 1 + > 4 files changed, 20 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index ff1c18d..0d7b290 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -49,6 +49,7 @@ > #include "i915_trace.h" > #include "i915_vgpu.h" > #include "intel_drv.h" > +#include "intel_huc.h" > #include "intel_guc.h" > > static struct drm_driver driver; > @@ -343,6 +344,9 @@ static int i915_getparam(struct drm_device *dev, void > *data, > case I915_PARAM_HAS_GUC: > value = intel_is_guc_valid(dev_priv); > break; > + case I915_PARAM_HAS_HUC: > + value = intel_is_huc_valid(dev_priv); > + break; > default: > DRM_DEBUG("Unknown parameter %d\n", param->param); > return -EINVAL; > diff --git a/drivers/gpu/drm/i915/intel_huc.h > b/drivers/gpu/drm/i915/intel_huc.h > index 946caa7..5eac625 100644 > --- a/drivers/gpu/drm/i915/intel_huc.h > +++ b/drivers/gpu/drm/i915/intel_huc.h > @@ -40,5 +40,5 @@ extern void intel_huc_init(struct drm_device *dev); > extern int intel_huc_load(struct drm_device *dev); > extern void intel_huc_auth(struct drm_device *dev); > extern void intel_huc_fini(struct drm_device *dev); > - > +extern int intel_is_huc_valid(struct drm_i915_private *dev_priv); > #endif > diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c > b/drivers/gpu/drm/i915/intel_huc_loader.c > index 87a6948..d574183 100644 > --- a/drivers/gpu/drm/i915/intel_huc_loader.c > +++ b/drivers/gpu/drm/i915/intel_huc_loader.c > @@ -273,3 +273,17 @@ void intel_huc_fini(struct drm_device *dev) > > huc_fw->fetch_status = UC_FIRMWARE_NONE; > } > + > +/** > + * intel_is_huc_valid() - Check to see if the HuC is fully loaded. > + * @dev_priv:drm device to check. > + * > + * This function will return true if the guc has been loaded and > + * has valid firmware. The simplest way of doing this is to check > + * if the HuC has been validated, if so it must have been loaded. > + */ > +int intel_is_huc_valid(struct drm_i915_private *dev_priv) I'm still unclear on the 'intel' vs. 'i915' prefix usage. But it seems that intel prefixed functions accept drm_device instead of drm_i915_private. Also, need to see the userspace usage of this new GETPARAM. > +{ > + return ((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) != 0); > +} > + > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index 629fb5e..d236520 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -389,6 +389,7 @@ typedef struct drm_i915_irq_wait { > #define I915_PARAM_MIN_EU_IN_POOL 39 > #define I915_PARAM_MMAP_GTT_VERSION 40 > #define I915_PARAM_HAS_GUC41 > +#define I915_PARAM_HAS_HUC42 > > typedef struct drm_i915_getparam { > __s32 param; > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915/get_params: Add GuC status to getparams
On Fri, Oct 07, 2016 at 09:11:03AM +0200, Daniel Vetter wrote: > On Wed, Oct 05, 2016 at 01:51:14PM -0700, Rodrigo Vivi wrote: > > > > > > Reviewed-by: Rodrigo Vivi > > This is new uabi. Where's the userspace? > > Checking this is part of the review. > -Daniel > I'm not sure that GuC status is strictly needed by userspace. No direct dependencies that I am aware of. HuC status is needed and that is the subsequent patch. -Jeff > > > > On Mon, Oct 03, 2016 at 11:43:01AM -0700, Anusha Srivatsa wrote: > > > From: Peter Antoine > > > > > > This patch returns the GuC status to the caller. It is used so > > > that the userspace knows if the GuC has been loaded. > > > > > > v4: rebase. > > > v5: rebased. > > > > > > Signed-off-by: Anusha Srivatsa > > > Signed-off-by: Peter Antoine > > > --- > > > drivers/gpu/drm/i915/i915_drv.c | 4 > > > drivers/gpu/drm/i915/intel_guc.h| 2 +- > > > drivers/gpu/drm/i915/intel_guc_loader.c | 18 ++ > > > include/uapi/drm/i915_drm.h | 1 + > > > 4 files changed, 24 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > b/drivers/gpu/drm/i915/i915_drv.c > > > index 7af7bd6..ff1c18d 100644 > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > @@ -49,6 +49,7 @@ > > > #include "i915_trace.h" > > > #include "i915_vgpu.h" > > > #include "intel_drv.h" > > > +#include "intel_guc.h" > > > > > > static struct drm_driver driver; > > > > > > @@ -339,6 +340,9 @@ static int i915_getparam(struct drm_device *dev, void > > > *data, > > >*/ > > > value = 1; > > > break; > > > + case I915_PARAM_HAS_GUC: > > > + value = intel_is_guc_valid(dev_priv); > > > + break; > > > default: > > > DRM_DEBUG("Unknown parameter %d\n", param->param); > > > return -EINVAL; > > > diff --git a/drivers/gpu/drm/i915/intel_guc.h > > > b/drivers/gpu/drm/i915/intel_guc.h > > > index af76ffe..3a7fa7e 100644 > > > --- a/drivers/gpu/drm/i915/intel_guc.h > > > +++ b/drivers/gpu/drm/i915/intel_guc.h > > > @@ -168,5 +168,5 @@ int i915_guc_submission_enable(struct > > > drm_i915_private *dev_priv); > > > int i915_guc_wq_reserve(struct drm_i915_gem_request *rq); > > > void i915_guc_submission_disable(struct drm_i915_private *dev_priv); > > > void i915_guc_submission_fini(struct drm_i915_private *dev_priv); > > > - > > > +int intel_is_guc_valid(struct drm_i915_private *dev_priv); > > > #endif > > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c > > > b/drivers/gpu/drm/i915/intel_guc_loader.c > > > index 31a2b0a..5d2a703 100644 > > > --- a/drivers/gpu/drm/i915/intel_guc_loader.c > > > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c > > > @@ -801,3 +801,21 @@ void intel_guc_fini(struct drm_device *dev) > > > > > > guc_fw->fetch_status = UC_FIRMWARE_NONE; > > > } > > > + > > > +/** > > > + * intel_is_guc_valid() - Check to see if the GuC is fully loaded. > > > + * @dev: drm dedvice to check. > > > + * > > > + * This function will return true if the guc has been loaded and > > > + * has valid firmware. > > > + */ > > > +int intel_is_guc_valid(struct drm_i915_private *dev_priv) > > > +{ > > > + struct intel_uc_fw *guc_fw = &dev_priv->guc.guc_fw; > > > + > > > + if (guc_fw->load_status == UC_FIRMWARE_SUCCESS) > > > + return 1; > > > + else > > > + return 0; > > > +} > > > + > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > > index 03725fe..629fb5e 100644 > > > --- a/include/uapi/drm/i915_drm.h > > > +++ b/include/uapi/drm/i915_drm.h > > > @@ -388,6 +388,7 @@ typedef struct drm_i915_irq_wait { > > > #define I915_PARAM_HAS_POOLED_EU 38 > > > #define I915_PARAM_MIN_EU_IN_POOL 39 > > > #define I915_PARAM_MMAP_GTT_VERSION 40 > > > +#define I915_PARAM_HAS_GUC41 > > > > > > typedef struct drm_i915_getparam { > > > __s32 param; > > > -- > > > 2.7.4 > > > > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915/huc: Add BXT HuC Loading Support
On Mon, Oct 03, 2016 at 11:43:00AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > This patch adds the HuC Loading for the BXT. > Version 1.7 of the HuC firmware. > > v2: rebased. > v3: rebased. > changed file name to match the install package format. > v7: rebased. > v8: rebased. > > Signed-off-by: Anusha Srivatsa > Signed-off-by: Peter Antoine > Reviewed-by: David Gordon > --- > drivers/gpu/drm/i915/intel_huc_loader.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c > b/drivers/gpu/drm/i915/intel_huc_loader.c > index 1aaff67..87a6948 100644 > --- a/drivers/gpu/drm/i915/intel_huc_loader.c > +++ b/drivers/gpu/drm/i915/intel_huc_loader.c > @@ -50,6 +50,9 @@ > #define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin" > MODULE_FIRMWARE(I915_SKL_HUC_UCODE); > > +#define I915_BXT_HUC_UCODE "i915/bxt_huc_ver01_07_1398.bin" > +MODULE_FIRMWARE(I915_BXT_HUC_UCODE); > + This will need updating if the newer firmware version/name macros in intel_guc_loader.c are adopted. > /** > * intel_huc_load_ucode() - DMA's the firmware > * @dev: the drm device > @@ -158,6 +161,10 @@ void intel_huc_init(struct drm_device *dev) > fw_path = I915_SKL_HUC_UCODE; > huc_fw->major_ver_wanted = 1; > huc_fw->minor_ver_wanted = 7; > + } else if (IS_BROXTON(dev_priv)) { > + fw_path = I915_BXT_HUC_UCODE; > + huc_fw->major_ver_wanted = 1; > + huc_fw->minor_ver_wanted = 7; > } > > if (fw_path == NULL) > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915/huc: Support HuC authentication
On Mon, Oct 03, 2016 at 11:42:59AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > The HuC authentication is done by host2guc call. The HuC RSA keys > are sent to GuC for authentication. > > v2: rebased on top of drm-intel-nightly. > changed name format and upped version 1.7. > v3: rebased on top of drm-intel-nightly. > v4: changed wait_for_automic to wait_for > v5: rebased. > v7: rebased. > v8: rebased. > > Tested-by: Xiang Haihao > Signed-off-by: Anusha Srivatsa > Signed-off-by: Alex Dai > Signed-off-by: Peter Antoine > Reviewed-by: Dave Gordon > --- > drivers/gpu/drm/i915/i915_guc_submission.c | 65 > ++ > drivers/gpu/drm/i915/intel_guc_fwif.h | 1 + > drivers/gpu/drm/i915/intel_guc_loader.c| 2 + > 3 files changed, 68 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c > b/drivers/gpu/drm/i915/i915_guc_submission.c > index 4b92943..984b529 100644 > --- a/drivers/gpu/drm/i915/i915_guc_submission.c > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c > @@ -25,6 +25,7 @@ > #include > #include "i915_drv.h" > #include "intel_guc.h" > +#include "intel_huc.h" > > /** > * DOC: GuC-based command submission > @@ -1110,3 +,67 @@ int intel_guc_resume(struct drm_device *dev) > > return host2guc_action(guc, data, ARRAY_SIZE(data)); > } > + > +/** > + * intel_huc_auth() - authenticate ucode > + * @dev: the drm device > + * > + * Triggers a HuC fw authentication request to the GuC via host-2-guc > + * interface. > + */ > +void intel_huc_auth(struct drm_device *dev) This function is primarily a guc action and must be in i915_guc_submission.c to use the static host2guc call. I think it would be clearer to name the function intel_guc_auth_huc and place the prototype in intel_guc.h instead of intel_huc.h where other wrappers of host2guc are prototyped. > +{ > + struct drm_i915_private *dev_priv = dev->dev_private; > + struct intel_guc *guc = &dev_priv->guc; > + struct intel_huc *huc = &dev_priv->huc; > + struct i915_vma *vma; > + int ret; > + u32 data[2]; > + > + /* Bypass the case where there is no HuC firmware */ > + if (huc->huc_fw.fetch_status == UC_FIRMWARE_NONE || > + huc->huc_fw.load_status == UC_FIRMWARE_NONE) > + return; > + > + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) { > + DRM_ERROR("HuC: GuC fw wasn't loaded. Can't authenticate"); > + return; > + } > + > + if (huc->huc_fw.load_status != UC_FIRMWARE_SUCCESS) { > + DRM_ERROR("HuC: fw wasn't loaded. Nothing to authenticate"); > + return; > + } > + > + vma = i915_gem_object_ggtt_pin(huc->huc_fw.uc_fw_obj, NULL, 0, 0, 0); > + if (IS_ERR(vma)) { > + DRM_DEBUG_DRIVER("pin failed %d\n", (int)PTR_ERR(vma)); > + return; > + } > + > + > + /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */ > + I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE); > + > + /* Specify auth action and where public signature is. It's stored > + * at the beginning of the gem object, before the fw bits Second sentence is wrong. RSA offset is after header and ucode. Please just remove this sentence. > + */ > + data[0] = HOST2GUC_ACTION_AUTHENTICATE_HUC; > + data[1] = i915_ggtt_offset(vma) + huc->huc_fw.rsa_offset; > + > + ret = host2guc_action(guc, data, ARRAY_SIZE(data)); > + if (ret) { > + DRM_ERROR("HuC: GuC did not ack Auth request\n"); > + goto out; > + } > + > + /* Check authentication status, it should be done by now */ > + ret = wait_for((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) > 0, 50); > + if (ret) { > + DRM_ERROR("HuC: Authentication failed\n"); > + goto out; > + } > + > +out: > + i915_vma_unpin(vma); > +} > diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h > b/drivers/gpu/drm/i915/intel_guc_fwif.h > index b38b6b4..57e6466 100644 > --- a/drivers/gpu/drm/i915/intel_guc_fwif.h > +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h > @@ -438,6 +438,7 @@ enum host2guc_action { > HOST2GUC_ACTION_ENTER_S_STATE = 0x501, > HOST2GUC_ACTION_EXIT_S_STATE = 0x502, > HOST2GUC_ACTION_SLPC_REQUEST = 0x3003, > + HOST2GUC_ACTION_AUTHENTICATE_HUC = 0x4000, > HOST2GUC_ACTION_LIMIT > }; > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c > b/drivers/gpu/drm/i915/intel_guc_loader.c > index 0d214b4..31a2b0a 100644 > --- a/drivers/gpu/drm/i915/intel_guc_loader.c > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c > @@ -527,6 +527,8 @@ int intel_guc_setup(struct drm_device *dev) > intel_uc_fw_status_repr(guc_fw->fetch_status), > intel_uc_fw_status_repr(guc_fw->load_status)); > > + intel_huc_auth(dev); > + > if (i915.enable_guc_submission) { > err = i915_guc_submission_enable(dev_priv); > if (err) > -- > 2.7.4 > > __
Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values
Your is SAGV related, and when we don't make the SAGV happy people's machines usually hang. So I'm definitely for your patches getting merged first On Thu, 2016-10-13 at 17:07 -0300, Paulo Zanoni wrote: > Em Qui, 2016-10-13 às 17:04 -0300, Paulo Zanoni escreveu: > > > > Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu: > > > > > > > > > Op 08-10-16 om 02:11 schreef Lyude: > > > > > > > > > > > > > > > > Now that we've make skl_wm_levels make a little more sense, we > > > > can > > > > remove all of the redundant wm information. Up until now we'd > > > > been > > > > storing two copies of all of the skl watermarks: one being the > > > > skl_pipe_wm structs, the other being the global wm struct in > > > > drm_i915_private containing the raw register values. This is > > > > confusing > > > > and problematic, since it means we're prone to accidentally > > > > letting > > > > the > > > > two copies go out of sync. So, get rid of all of the functions > > > > responsible for computing the register values and just use a > > > > single > > > > helper, skl_write_wm_level(), to convert and write the new > > > > watermarks on > > > > the fly. > > > > > > > > Changes since v1: > > > > - Fixup skl_write_wm_level() > > > > - Fixup skl_wm_level_from_reg_val() > > > > - Don't forget to copy *active to intel_crtc->wm.active.skl > > > > > > > > Signed-off-by: Lyude > > > > Reviewed-by: Maarten Lankhorst > > > om > > > > > > > > > > > > > > Cc: Ville Syrjälä > > > > Cc: Paulo Zanoni > > > > --- > > > > drivers/gpu/drm/i915/i915_drv.h | 2 - > > > > drivers/gpu/drm/i915/intel_display.c | 14 ++- > > > > drivers/gpu/drm/i915/intel_drv.h | 6 +- > > > > drivers/gpu/drm/i915/intel_pm.c | 204 --- > > > > -- > > > > -- > > > > > > > > drivers/gpu/drm/i915/intel_sprite.c | 8 +- > > > > 5 files changed, 90 insertions(+), 144 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > > > b/drivers/gpu/drm/i915/i915_drv.h > > > > index 0287c93..76583b2 100644 > > > > --- a/drivers/gpu/drm/i915/i915_drv.h > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > > > @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation { > > > > struct skl_wm_values { > > > > unsigned dirty_pipes; > > > > struct skl_ddb_allocation ddb; > > > > - uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8]; > > > > - uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES]; > > > > }; > > > > > > > > struct skl_wm_level { > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > > b/drivers/gpu/drm/i915/intel_display.c > > > > index a71d05a..39400a0 100644 > > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > > @@ -3378,6 +3378,8 @@ static void > > > > skylake_update_primary_plane(struct drm_plane *plane, > > > > struct intel_crtc *intel_crtc = > > > > to_intel_crtc(crtc_state- > > > > > > > > > > > > > > > base.crtc); > > > > struct drm_framebuffer *fb = plane_state->base.fb; > > > > const struct skl_wm_values *wm = &dev_priv- > > > > > > > > > > > > > > > wm.skl_results; > > > > + const struct skl_plane_wm *p_wm = > > > > + &crtc_state->wm.skl.optimal.planes[0]; > > > > int pipe = intel_crtc->pipe; > > > > u32 plane_ctl; > > > > unsigned int rotation = plane_state->base.rotation; > > > > @@ -3414,7 +3416,7 @@ static void > > > > skylake_update_primary_plane(struct drm_plane *plane, > > > > intel_crtc->adjusted_y = src_y; > > > > > > > > if (wm->dirty_pipes & drm_crtc_mask(&intel_crtc- > > > > >base)) > > > > - skl_write_plane_wm(intel_crtc, wm, 0); > > > > + skl_write_plane_wm(intel_crtc, p_wm, &wm->ddb, > > > > 0); > > > > > > > > I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl); > > > > I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | > > > > src_x); > > > > @@ -3448,6 +3450,8 @@ static void > > > > skylake_disable_primary_plane(struct drm_plane *primary, > > > > struct drm_device *dev = crtc->dev; > > > > struct drm_i915_private *dev_priv = to_i915(dev); > > > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > > > + struct intel_crtc_state *cstate = > > > > to_intel_crtc_state(crtc->state); > > > > + const struct skl_plane_wm *p_wm = &cstate- > > > > > > > > > > > > > > > wm.skl.optimal.planes[0]; > > > > int pipe = intel_crtc->pipe; > > > > > > > > /* > > > > @@ -3455,7 +3459,8 @@ static void > > > > skylake_disable_primary_plane(struct drm_plane *primary, > > > > * plane's visiblity isn't actually changing neither > > > > is > > > > its watermarks. > > > > */ > > > > if (!crtc->primary->state->visible) > > > > - skl_write_plane_wm(intel_crtc, &dev_priv- > > > > > > > > > > > > > > > wm.skl_results, 0); > > > > + skl_write_plane_wm(intel
Re: [Intel-gfx] [PATCH 09/10] drm/i915/gen9: Actually verify WM levels in verify_wm_state()
Em Qui, 2016-10-13 às 18:15 -0300, Paulo Zanoni escreveu: > Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > > > > Thanks to Paulo Zanoni for indirectly pointing this out. > > > > Looks like we never actually added any code for checking whether or > > not > > we actually wrote watermark levels properly. Let's fix that. > > Thanks for doing this! > > Reviewed-by: Paulo Zanoni > > A check that would have prevented one of the bugs I solved would be > "if > plane is active, then level 0 must be enabled, and DDB partitioning > size must be non-zero". I'll put this in my TODO list, but I won't > complain if somebody does it first :) Also, bikeshed: use %u instead of %d for the unsigned types (plane_res_b, plane_res_l). > > > > > > > Signed-off-by: Lyude > > Cc: Maarten Lankhorst > > Cc: Ville Syrjälä > > Cc: Paulo Zanoni > > --- > > drivers/gpu/drm/i915/intel_display.c | 100 > > +-- > > 1 file changed, 84 insertions(+), 16 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 39400a0..2c682bc 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -13444,30 +13444,66 @@ static void verify_wm_state(struct > > drm_crtc > > *crtc, > > struct drm_device *dev = crtc->dev; > > struct drm_i915_private *dev_priv = to_i915(dev); > > struct skl_ddb_allocation hw_ddb, *sw_ddb; > > - struct skl_ddb_entry *hw_entry, *sw_entry; > > + struct skl_pipe_wm hw_wm, *sw_wm; > > + struct skl_plane_wm *hw_plane_wm, *sw_plane_wm; > > + struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry; > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > const enum pipe pipe = intel_crtc->pipe; > > - int plane; > > + int plane, level, max_level = ilk_wm_max_level(dev); > > > > if (INTEL_INFO(dev)->gen < 9 || !new_state->active) > > return; > > > > + skl_pipe_wm_get_hw_state(crtc, &hw_wm); > > + sw_wm = &intel_crtc->wm.active.skl; > > + > > skl_ddb_get_hw_state(dev_priv, &hw_ddb); > > sw_ddb = &dev_priv->wm.skl_hw.ddb; > > > > /* planes */ > > for_each_plane(dev_priv, pipe, plane) { > > - hw_entry = &hw_ddb.plane[pipe][plane]; > > - sw_entry = &sw_ddb->plane[pipe][plane]; > > + hw_plane_wm = &hw_wm.planes[plane]; > > + sw_plane_wm = &sw_wm->planes[plane]; > > > > - if (skl_ddb_entry_equal(hw_entry, sw_entry)) > > - continue; > > + /* Watermarks */ > > + for (level = 0; level <= max_level; level++) { > > + if (skl_wm_level_equals(&hw_plane_wm- > > > > > > wm[level], > > + &sw_plane_wm- > > > > > > wm[level])) > > + continue; > > + > > + DRM_ERROR("mismatch in WM pipe %c plane %d > > level %d (expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n", > > + pipe_name(pipe), plane + 1, > > level, > > + sw_plane_wm->wm[level].plane_en, > > + sw_plane_wm- > > > > > > wm[level].plane_res_b, > > + sw_plane_wm- > > > > > > wm[level].plane_res_l, > > + hw_plane_wm->wm[level].plane_en, > > + hw_plane_wm- > > > > > > wm[level].plane_res_b, > > + hw_plane_wm- > > > > > > wm[level].plane_res_l); > > + } > > > > - DRM_ERROR("mismatch in DDB state pipe %c plane %d > > " > > - "(expected (%u,%u), found (%u,%u))\n", > > - pipe_name(pipe), plane + 1, > > - sw_entry->start, sw_entry->end, > > - hw_entry->start, hw_entry->end); > > + if (!skl_wm_level_equals(&hw_plane_wm->trans_wm, > > + &sw_plane_wm->trans_wm)) > > { > > + DRM_ERROR("mismatch in trans WM pipe %c > > plane %d (expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n", > > + pipe_name(pipe), plane + 1, > > + sw_plane_wm->trans_wm.plane_en, > > + sw_plane_wm- > > >trans_wm.plane_res_b, > > + sw_plane_wm- > > >trans_wm.plane_res_l, > > + hw_plane_wm->trans_wm.plane_en, > > + hw_plane_wm- > > >trans_wm.plane_res_b, > > + hw_plane_wm- > > > > > > trans_wm.plane_res_l); > > + } > > + > > + /* DDB */ > > + hw_ddb_entry = &hw_ddb.plane[pipe][plane]; > > + sw_ddb_entry = &sw_ddb->plane[pipe][plane]; > > + > > + if (!skl_ddb_entry_equal(hw_ddb_entry, > > sw_ddb_entry)) { > > + DRM_ERROR("mismatch in DDB state pipe %c > > plane %d " > > + "(expec
Re: [Intel-gfx] [PATCH 10/10] drm/i915/gen9: Don't wrap strings in verify_wm_state()
Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: Bikesheding: it would be nice to write a commit message explaining why, even if the message just tells the user to read Documentation/CodingStyle. Reviewed-by: Paulo Zanoni > Signed-off-by: Lyude > Cc: Maarten Lankhorst > Cc: Ville Syrjälä > Cc: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_display.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 2c682bc..6191baf 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -13498,8 +13498,7 @@ static void verify_wm_state(struct drm_crtc > *crtc, > sw_ddb_entry = &sw_ddb->plane[pipe][plane]; > > if (!skl_ddb_entry_equal(hw_ddb_entry, > sw_ddb_entry)) { > - DRM_ERROR("mismatch in DDB state pipe %c > plane %d " > - "(expected (%u,%u), found > (%u,%u))\n", > + DRM_ERROR("mismatch in DDB state pipe %c > plane %d (expected (%u,%u), found (%u,%u))\n", > pipe_name(pipe), plane + 1, > sw_ddb_entry->start, sw_ddb_entry- > >end, > hw_ddb_entry->start, hw_ddb_entry- > >end); > @@ -13549,8 +13548,7 @@ static void verify_wm_state(struct drm_crtc > *crtc, > sw_ddb_entry = &sw_ddb->plane[pipe][PLANE_CURSOR]; > > if (!skl_ddb_entry_equal(hw_ddb_entry, > sw_ddb_entry)) { > - DRM_ERROR("mismatch in DDB state pipe %c > cursor " > - "(expected (%u,%u), found > (%u,%u))\n", > + DRM_ERROR("mismatch in DDB state pipe %c > cursor (expected (%u,%u), found (%u,%u))\n", > pipe_name(pipe), > sw_ddb_entry->start, sw_ddb_entry- > >end, > hw_ddb_entry->start, hw_ddb_entry- > >end); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/10] drm/i915/gen9: Actually verify WM levels in verify_wm_state()
Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > Thanks to Paulo Zanoni for indirectly pointing this out. > > Looks like we never actually added any code for checking whether or > not > we actually wrote watermark levels properly. Let's fix that. Thanks for doing this! Reviewed-by: Paulo Zanoni A check that would have prevented one of the bugs I solved would be "if plane is active, then level 0 must be enabled, and DDB partitioning size must be non-zero". I'll put this in my TODO list, but I won't complain if somebody does it first :) > > Signed-off-by: Lyude > Cc: Maarten Lankhorst > Cc: Ville Syrjälä > Cc: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_display.c | 100 > +-- > 1 file changed, 84 insertions(+), 16 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 39400a0..2c682bc 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -13444,30 +13444,66 @@ static void verify_wm_state(struct drm_crtc > *crtc, > struct drm_device *dev = crtc->dev; > struct drm_i915_private *dev_priv = to_i915(dev); > struct skl_ddb_allocation hw_ddb, *sw_ddb; > - struct skl_ddb_entry *hw_entry, *sw_entry; > + struct skl_pipe_wm hw_wm, *sw_wm; > + struct skl_plane_wm *hw_plane_wm, *sw_plane_wm; > + struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > const enum pipe pipe = intel_crtc->pipe; > - int plane; > + int plane, level, max_level = ilk_wm_max_level(dev); > > if (INTEL_INFO(dev)->gen < 9 || !new_state->active) > return; > > + skl_pipe_wm_get_hw_state(crtc, &hw_wm); > + sw_wm = &intel_crtc->wm.active.skl; > + > skl_ddb_get_hw_state(dev_priv, &hw_ddb); > sw_ddb = &dev_priv->wm.skl_hw.ddb; > > /* planes */ > for_each_plane(dev_priv, pipe, plane) { > - hw_entry = &hw_ddb.plane[pipe][plane]; > - sw_entry = &sw_ddb->plane[pipe][plane]; > + hw_plane_wm = &hw_wm.planes[plane]; > + sw_plane_wm = &sw_wm->planes[plane]; > > - if (skl_ddb_entry_equal(hw_entry, sw_entry)) > - continue; > + /* Watermarks */ > + for (level = 0; level <= max_level; level++) { > + if (skl_wm_level_equals(&hw_plane_wm- > >wm[level], > + &sw_plane_wm- > >wm[level])) > + continue; > + > + DRM_ERROR("mismatch in WM pipe %c plane %d > level %d (expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n", > + pipe_name(pipe), plane + 1, level, > + sw_plane_wm->wm[level].plane_en, > + sw_plane_wm- > >wm[level].plane_res_b, > + sw_plane_wm- > >wm[level].plane_res_l, > + hw_plane_wm->wm[level].plane_en, > + hw_plane_wm- > >wm[level].plane_res_b, > + hw_plane_wm- > >wm[level].plane_res_l); > + } > > - DRM_ERROR("mismatch in DDB state pipe %c plane %d " > - "(expected (%u,%u), found (%u,%u))\n", > - pipe_name(pipe), plane + 1, > - sw_entry->start, sw_entry->end, > - hw_entry->start, hw_entry->end); > + if (!skl_wm_level_equals(&hw_plane_wm->trans_wm, > + &sw_plane_wm->trans_wm)) { > + DRM_ERROR("mismatch in trans WM pipe %c > plane %d (expected e=%d b=%d l=%d, got e=%d b=%d l=%d)\n", > + pipe_name(pipe), plane + 1, > + sw_plane_wm->trans_wm.plane_en, > + sw_plane_wm->trans_wm.plane_res_b, > + sw_plane_wm->trans_wm.plane_res_l, > + hw_plane_wm->trans_wm.plane_en, > + hw_plane_wm->trans_wm.plane_res_b, > + hw_plane_wm- > >trans_wm.plane_res_l); > + } > + > + /* DDB */ > + hw_ddb_entry = &hw_ddb.plane[pipe][plane]; > + sw_ddb_entry = &sw_ddb->plane[pipe][plane]; > + > + if (!skl_ddb_entry_equal(hw_ddb_entry, > sw_ddb_entry)) { > + DRM_ERROR("mismatch in DDB state pipe %c > plane %d " > + "(expected (%u,%u), found > (%u,%u))\n", > + pipe_name(pipe), plane + 1, > + sw_ddb_entry->start, sw_ddb_entry- > >end, > + hw_ddb_entry->start, hw_ddb_entry- > >end); > + } > } > > /* > @@ -13477,15 +13513,47 @@ static void verify_wm_state(str
Re: [Intel-gfx] Problem with emgd on fedora 18
On Thu, Oct 13, 2016 at 03:28:05PM +0300, Jani Nikula wrote: > On Thu, 13 Oct 2016, Anteja Vuk Macek wrote: > > Hi, > > I work with Fedora 18 and I'm new in linux world. I have problem with emgd > > driver. I put emgd driver in kernel and build kernel. Moduled is build like > > loadable module. But problem is when I load driver , you can see photo > > https://my.syncplicity.com/share/skvhanon0sxj5f8/IMG_20161011_104347 . What > > I need to do to fix my problem with driver ? > > This list is for the upstream Linux drm/i915 driver and related > stuff. We don't support the emgd driver on this list. Generally we don't > even have a clue here about emgd, but perhaps Matt can give you pointers > if and where you can get support for it. > > BR, > Jani. Hi Anteja, It's hard to tell what's wrong just from the screenshot, but my first guess would be a panel (monitor) timing misconfiguration. EMGD isn't really intended for traditional PC-style operation, but rather for use in "embedded" devices (i.e., specialized appliance-like devices like store kiosks, automobiles, casino gaming machines, etc.). Embedded devices generally have a permanently fixed hardware and software configuration so EMGD defaults to pulling all kinds of configuration information (including monitor timing data and such) from a special configuration file rather than autoprobing; if that config file has the wrong information, you can easily wind up with corrupt or non-functioning displays. You mentioned that you're new to Linux...are you building an embedded device which you need EMGD's specific embedded functionality for? If so, I'll try to find you an appropriate support channel for you to get help (I haven't worked with EMGD for a few years, so I probably can't help with any specifics at this point). If you're not building an embedded device, then you'd probably be better off using the standard opensource drivers that come as part of your Linux distribution (and using as new of a distribution as possible to ensure that the drivers that come with it are the latest, most up-to-date versions). Matt > > > > > > Emgd driver version : 36.1.25_3900 > > > > Best regards, > > > > Anteja Vuk - Macek > > Software Engineer > > > > Dolotron d.o.o. > > Ziskovec 141 > > HR-4 Cakovec > > Croatia > > Tel: ++385 (40) 865 205 > > Fax: ++385 (40) 865 732 > > mailto: anteja...@dolotron.com > > _ > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Technology Center -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support
On Thu, Oct 13, 2016 at 10:42:42AM -0700, Jeff McGee wrote: > On Mon, Oct 03, 2016 at 11:42:57AM -0700, Anusha Srivatsa wrote: > > From: Peter Antoine > > > > The HuC loading process is similar to GuC. The intel_uc_fw_fetch() > > is used for both cases. > > > > HuC loading needs to be before GuC loading. The WOPCM setting must > > be done early before loading any of them. > > > > v2: rebased on-top of drm-intel-nightly. > > removed if(HAS_GUC()) before the guc call. (D.Gordon) > > update huc_version number of format. > > v3: rebased to drm-intel-nightly, changed the file name format to > > match the one in the huc package. > > Changed dev->dev_private to to_i915() > > v4: moved function back to where it was. > > change wait_for_atomic to wait_for. > > v5: rebased + comment changes. > > v7: rebased. > > v8: rebased. > > > > Tested-by: Xiang Haihao > > Signed-off-by: Anusha Srivatsa > > Signed-off-by: Alex Dai > > Signed-off-by: Peter Antoine > > Reviewed-by: Dave Gordon > > --- > > drivers/gpu/drm/i915/Makefile | 1 + > > drivers/gpu/drm/i915/i915_drv.c | 3 + > > drivers/gpu/drm/i915/i915_drv.h | 3 + > > drivers/gpu/drm/i915/i915_guc_reg.h | 3 + > > drivers/gpu/drm/i915/intel_guc.h| 1 + > > drivers/gpu/drm/i915/intel_guc_loader.c | 6 +- > > drivers/gpu/drm/i915/intel_huc.h| 44 ++ > > drivers/gpu/drm/i915/intel_huc_loader.c | 268 > > > > 8 files changed, 327 insertions(+), 2 deletions(-) > > create mode 100644 drivers/gpu/drm/i915/intel_huc.h > > create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c > > > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > > index e6fe004..6e99c51 100644 > > --- a/drivers/gpu/drm/i915/Makefile > > +++ b/drivers/gpu/drm/i915/Makefile > > @@ -53,6 +53,7 @@ i915-y += i915_cmd_parser.o \ > > > > # general-purpose microcontroller (GuC) support > > i915-y += intel_guc_loader.o \ > > + intel_huc_loader.o \ > > i915_guc_submission.o > > > > # autogenerated null render state > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c > > index 31b2b63..7af7bd6 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -613,6 +613,7 @@ static int i915_load_modeset_init(struct drm_device > > *dev) > > * working irqs for e.g. gmbus and dp aux transfers. */ > > intel_modeset_init(dev); > > > > + intel_huc_init(dev); > > intel_guc_init(dev); > > > > ret = i915_gem_init(dev); > > @@ -638,6 +639,7 @@ static int i915_load_modeset_init(struct drm_device > > *dev) > > cleanup_gem: > > i915_gem_fini(dev); > > cleanup_irq: > > + intel_huc_fini(dev); > > intel_guc_fini(dev); > > drm_irq_uninstall(dev); > > intel_teardown_gmbus(dev); > > @@ -1315,6 +1317,7 @@ void i915_driver_unload(struct drm_device *dev) > > /* Flush any outstanding unpin_work. */ > > drain_workqueue(dev_priv->wq); > > > > + intel_huc_fini(dev); > > intel_guc_fini(dev); > > i915_gem_fini(dev); > > intel_fbc_cleanup_cfb(dev_priv); > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > > index e0cb71c..625aa92 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -55,6 +55,7 @@ > > #include "intel_bios.h" > > #include "intel_dpll_mgr.h" > > #include "intel_guc.h" > > +#include "intel_huc.h" > > #include "intel_lrc.h" > > #include "intel_ringbuffer.h" > > > > @@ -1766,6 +1767,7 @@ struct drm_i915_private { > > > > struct intel_gvt gvt; > > > > + struct intel_huc huc; > > struct intel_guc guc; > > > > struct intel_csr csr; > > @@ -2822,6 +2824,7 @@ struct drm_i915_cmd_table { > > #define HAS_GUC(dev) (INTEL_INFO(dev)->has_guc) > > #define HAS_GUC_UCODE(dev) (HAS_GUC(dev)) > > #define HAS_GUC_SCHED(dev) (HAS_GUC(dev)) > > +#define HAS_HUC_UCODE(dev) (HAS_GUC(dev)) > > > > #define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)->has_resource_streamer) > > > > diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h > > b/drivers/gpu/drm/i915/i915_guc_reg.h > > index a47e1e4..64e942a 100644 > > --- a/drivers/gpu/drm/i915/i915_guc_reg.h > > +++ b/drivers/gpu/drm/i915/i915_guc_reg.h > > @@ -61,9 +61,12 @@ > > #define DMA_ADDRESS_SPACE_GTT (8 << 16) > > #define DMA_COPY_SIZE _MMIO(0xc310) > > #define DMA_CTRL _MMIO(0xc314) > > +#define HUC_UKERNEL(1<<9) > > #define UOS_MOVE (1<<4) > > #define START_DMA (1<<0) > > #define DMA_GUC_WOPCM_OFFSET _MMIO(0xc340) > > +#define HUC_LOADING_AGENT_VCR (0<<1) > > +#define HUC_LOADING_AGENT_GUC (1<<1) > > #define GUC_WOPCM_OFFSET_VALUE 0x8 /* 512KB */ > > #define GUC_MAX_IDLE_COU
Re: [Intel-gfx] [PATCH 08/10] drm/i915/gen9: Add skl_wm_level_equals()
Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > Helper we're going to be using for implementing verification of the > wm > levels in skl_verify_wm_level(). > > Signed-off-by: Lyude Reviewed-by: Paulo Zanoni > Cc: Maarten Lankhorst > Cc: Ville Syrjälä > Cc: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > drivers/gpu/drm/i915/intel_pm.c | 14 ++ > 2 files changed, 16 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index 73a2d16d..3e6e9af 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -1761,6 +1761,8 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc > *crtc, > bool intel_can_enable_sagv(struct drm_atomic_state *state); > int intel_enable_sagv(struct drm_i915_private *dev_priv); > int intel_disable_sagv(struct drm_i915_private *dev_priv); > +bool skl_wm_level_equals(const struct skl_wm_level *l1, > + const struct skl_wm_level *l2); > bool skl_ddb_allocation_equals(const struct skl_ddb_allocation *old, > const struct skl_ddb_allocation *new, > enum pipe pipe); > diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index 27a520ce..6af1587 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3853,6 +3853,20 @@ void skl_write_cursor_wm(struct intel_crtc > *intel_crtc, > &ddb->plane[pipe][PLANE_CURSOR]); > } > > +bool skl_wm_level_equals(const struct skl_wm_level *l1, > + const struct skl_wm_level *l2) > +{ > + if (l1->plane_en != l2->plane_en) > + return false; > + > + /* If both planes aren't enabled, the rest shouldn't matter > */ > + if (!l1->plane_en) > + return true; > + > + return (l1->plane_res_l == l2->plane_res_l && > + l1->plane_res_b == l2->plane_res_b); > +} > + > static inline bool skl_ddb_entries_overlap(const struct > skl_ddb_entry *a, > const struct > skl_ddb_entry *b) > { ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/10] drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable
Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > There's not much of a reason this should have the locations to read > out > the hardware state hardcoded, so allow the caller to specify the > location and add this function to intel_drv.h. As well, we're going > to > need this function to be reusable for the next patch. > > Signed-off-by: Lyude > Cc: Maarten Lankhorst > Cc: Ville Syrjälä > Cc: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > drivers/gpu/drm/i915/intel_pm.c | 27 +-- > 2 files changed, 19 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index 958dc72..73a2d16d 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -1756,6 +1756,8 @@ void ilk_wm_get_hw_state(struct drm_device > *dev); > void skl_wm_get_hw_state(struct drm_device *dev); > void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv, > struct skl_ddb_allocation *ddb /* out */); > +void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc, > + struct skl_pipe_wm *out); > bool intel_can_enable_sagv(struct drm_atomic_state *state); > int intel_enable_sagv(struct drm_i915_private *dev_priv); > int intel_disable_sagv(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 9e53ff7..27a520ce 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4287,15 +4287,13 @@ static inline void > skl_wm_level_from_reg_val(uint32_t val, > PLANE_WM_LINES_MASK; > } > > -static void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc) > +void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc, > + struct skl_pipe_wm *out) > { > struct drm_device *dev = crtc->dev; > struct drm_i915_private *dev_priv = to_i915(dev); > - struct skl_wm_values *hw = &dev_priv->wm.skl_hw; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - struct intel_crtc_state *cstate = to_intel_crtc_state(crtc- > >state); > struct intel_plane *intel_plane; > - struct skl_pipe_wm *active = &cstate->wm.skl.optimal; > struct skl_plane_wm *wm; > enum pipe pipe = intel_crtc->pipe; > int level, id, max_level = ilk_wm_max_level(dev); > @@ -4303,7 +4301,7 @@ static void skl_pipe_wm_get_hw_state(struct > drm_crtc *crtc) > > for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) { > id = skl_wm_plane_id(intel_plane); > - wm = &cstate->wm.skl.optimal.planes[id]; > + wm = &out->planes[id]; > > for (level = 0; level <= max_level; level++) { > if (id != PLANE_CURSOR) > @@ -4325,20 +4323,29 @@ static void skl_pipe_wm_get_hw_state(struct > drm_crtc *crtc) > if (!intel_crtc->active) > return; > > - hw->dirty_pipes |= drm_crtc_mask(crtc); > - active->linetime = I915_READ(PIPE_WM_LINETIME(pipe)); > - intel_crtc->wm.active.skl = *active; > + out->linetime = I915_READ(PIPE_WM_LINETIME(pipe)); > } > > void skl_wm_get_hw_state(struct drm_device *dev) > { > struct drm_i915_private *dev_priv = to_i915(dev); > + struct skl_wm_values *hw = &dev_priv->wm.skl_hw; > struct skl_ddb_allocation *ddb = &dev_priv->wm.skl_hw.ddb; > struct drm_crtc *crtc; > + struct intel_crtc *intel_crtc; > + struct intel_crtc_state *cstate; > > skl_ddb_get_hw_state(dev_priv, ddb); > - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) > - skl_pipe_wm_get_hw_state(crtc); > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) > { > + intel_crtc = to_intel_crtc(crtc); > + cstate = to_intel_crtc_state(crtc->state); > + > + skl_pipe_wm_get_hw_state(crtc, &cstate- > >wm.skl.optimal); > + intel_crtc->wm.active.skl = cstate->wm.skl.optimal; We're changing how the code behaves regarding intel_crtc- >wm.active.skl. Previously we would only set it if intel_crtc->active is true due to that return in skl_pipe_wm_get_hw_state(). Now we're always setting it. If this is some sort of fix it probably deserves to be in a separate commit with a nice commit message. > + > + if (!intel_crtc->active) > + hw->dirty_pipes |= drm_crtc_mask(crtc); Same here: previously we would not set dirty_pipes in case !intel_crtc- >active. Now we're doing the opposite. Didn't you mean "if (intel_crtc- >active)" here? > + } > > if (dev_priv->active_crtcs) { > /* Fully recompute DDB on first atomic commit */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid: Only print the bad edid when aborting
== Series Details == Series: drm/edid: Only print the bad edid when aborting URL : https://patchwork.freedesktop.org/series/13747/ State : warning == Summary == Series 13747v1 drm/edid: Only print the bad edid when aborting https://patchwork.freedesktop.org/api/1.0/series/13747/revisions/1/mbox/ Test drv_module_reload_basic: skip -> PASS (fi-skl-6770hq) Test kms_busy: Subgroup basic-flip-default-b: pass -> DMESG-WARN (fi-skl-6700k) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (fi-ilk-650) Test vgem_basic: Subgroup unload: skip -> PASS (fi-skl-6770hq) skip -> PASS (fi-hsw-4770) fi-bdw-5557u total:246 pass:231 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:246 pass:204 dwarn:0 dfail:0 fail:0 skip:42 fi-bxt-t5700 total:246 pass:216 dwarn:0 dfail:0 fail:0 skip:30 fi-byt-n2820 total:246 pass:210 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-hsw-4770r total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-ilk-650 total:246 pass:184 dwarn:0 dfail:0 fail:2 skip:60 fi-ivb-3520m total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-kbl-7200u total:246 pass:222 dwarn:0 dfail:0 fail:0 skip:24 fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:246 pass:223 dwarn:0 dfail:0 fail:0 skip:23 fi-skl-6700k total:246 pass:220 dwarn:2 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:246 pass:230 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:246 pass:210 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:246 pass:209 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2710/ dbcf6fbb541e70fac7db669631958eab2e4e0d9c drm-intel-nightly: 2016y-10m-13d-15h-31m-19s UTC integration manifest 88e63c4 drm/edid: Only print the bad edid when aborting ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/10] drm/i915/gen9: Add ddb changes to atomic debug output
Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu: > Finally, add some debugging output for ddb changes in the atomic > debug > output. This makes it a lot easier to spot bugs from incorrect ddb > allocations. > > Signed-off-by: Lyude > Reviewed-by: Maarten Lankhorst > Cc: Ville Syrjälä > Cc: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_pm.c | 57 > + > 1 file changed, 57 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index 5cb537c..9e53ff7 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4040,6 +4040,61 @@ skl_copy_wm_for_pipe(struct skl_wm_values > *dst, > sizeof(dst->ddb.plane[pipe])); > } > > +static void > +skl_print_wm_changes(const struct drm_atomic_state *state) > +{ > + const struct drm_device *dev = state->dev; > + const struct drm_i915_private *dev_priv = to_i915(dev); > + const struct intel_atomic_state *intel_state = > + to_intel_atomic_state(state); > + const struct drm_crtc *crtc; > + const struct drm_crtc_state *cstate; > + const struct drm_plane *plane; > + const struct intel_plane *intel_plane; > + const struct drm_plane_state *pstate; > + const struct skl_ddb_allocation *old_ddb = &dev_priv- > >wm.skl_hw.ddb; > + const struct skl_ddb_allocation *new_ddb = &intel_state- > >wm_results.ddb; > + enum pipe pipe; > + int id; > + int i, j; > + > + for_each_crtc_in_state(state, crtc, cstate, i) { > + if (!crtc->state) > + continue; Why exactly do we have this check? Everything else looks good. So with either an explanation or the check removed in case it's not needed: Reviewed-by: Paulo Zanoni > + > + pipe = to_intel_crtc(crtc)->pipe; > + > + for_each_plane_in_state(state, plane, pstate, j) { > + const struct skl_ddb_entry *old, *new; > + > + intel_plane = to_intel_plane(plane); > + id = skl_wm_plane_id(intel_plane); > + old = &old_ddb->plane[pipe][id]; > + new = &new_ddb->plane[pipe][id]; > + > + if (intel_plane->pipe != pipe) > + continue; > + > + if (skl_ddb_entry_equal(old, new)) > + continue; > + > + if (id != PLANE_CURSOR) { > + DRM_DEBUG_ATOMIC("[PLANE:%d:plane > %d%c] ddb (%d - %d) -> (%d - %d)\n", > + plane->base.id, id > + 1, > + pipe_name(pipe), > + old->start, old- > >end, > + new->start, new- > >end); > + } else { > + DRM_DEBUG_ATOMIC("[PLANE:%d:cursor > %c] ddb (%d - %d) -> (%d - %d)\n", > + plane->base.id, > + pipe_name(pipe), > + old->start, old- > >end, > + new->start, new- > >end); > + } > + } > + } > +} > + > static int > skl_compute_wm(struct drm_atomic_state *state) > { > @@ -4101,6 +4156,8 @@ skl_compute_wm(struct drm_atomic_state *state) > intel_cstate->update_wm_pre = true; > } > > + skl_print_wm_changes(state); > + > return 0; > } > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values
Em Qui, 2016-10-13 às 17:04 -0300, Paulo Zanoni escreveu: > Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu: > > > > Op 08-10-16 om 02:11 schreef Lyude: > > > > > > > > > Now that we've make skl_wm_levels make a little more sense, we > > > can > > > remove all of the redundant wm information. Up until now we'd > > > been > > > storing two copies of all of the skl watermarks: one being the > > > skl_pipe_wm structs, the other being the global wm struct in > > > drm_i915_private containing the raw register values. This is > > > confusing > > > and problematic, since it means we're prone to accidentally > > > letting > > > the > > > two copies go out of sync. So, get rid of all of the functions > > > responsible for computing the register values and just use a > > > single > > > helper, skl_write_wm_level(), to convert and write the new > > > watermarks on > > > the fly. > > > > > > Changes since v1: > > > - Fixup skl_write_wm_level() > > > - Fixup skl_wm_level_from_reg_val() > > > - Don't forget to copy *active to intel_crtc->wm.active.skl > > > > > > Signed-off-by: Lyude > > > Reviewed-by: Maarten Lankhorst > > > > > > Cc: Ville Syrjälä > > > Cc: Paulo Zanoni > > > --- > > > drivers/gpu/drm/i915/i915_drv.h | 2 - > > > drivers/gpu/drm/i915/intel_display.c | 14 ++- > > > drivers/gpu/drm/i915/intel_drv.h | 6 +- > > > drivers/gpu/drm/i915/intel_pm.c | 204 - > > > -- > > > > > > drivers/gpu/drm/i915/intel_sprite.c | 8 +- > > > 5 files changed, 90 insertions(+), 144 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > > b/drivers/gpu/drm/i915/i915_drv.h > > > index 0287c93..76583b2 100644 > > > --- a/drivers/gpu/drm/i915/i915_drv.h > > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > > @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation { > > > struct skl_wm_values { > > > unsigned dirty_pipes; > > > struct skl_ddb_allocation ddb; > > > - uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8]; > > > - uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES]; > > > }; > > > > > > struct skl_wm_level { > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > b/drivers/gpu/drm/i915/intel_display.c > > > index a71d05a..39400a0 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -3378,6 +3378,8 @@ static void > > > skylake_update_primary_plane(struct drm_plane *plane, > > > struct intel_crtc *intel_crtc = > > > to_intel_crtc(crtc_state- > > > > > > > > base.crtc); > > > struct drm_framebuffer *fb = plane_state->base.fb; > > > const struct skl_wm_values *wm = &dev_priv- > > > > > > > > wm.skl_results; > > > + const struct skl_plane_wm *p_wm = > > > + &crtc_state->wm.skl.optimal.planes[0]; > > > int pipe = intel_crtc->pipe; > > > u32 plane_ctl; > > > unsigned int rotation = plane_state->base.rotation; > > > @@ -3414,7 +3416,7 @@ static void > > > skylake_update_primary_plane(struct drm_plane *plane, > > > intel_crtc->adjusted_y = src_y; > > > > > > if (wm->dirty_pipes & drm_crtc_mask(&intel_crtc->base)) > > > - skl_write_plane_wm(intel_crtc, wm, 0); > > > + skl_write_plane_wm(intel_crtc, p_wm, &wm->ddb, > > > 0); > > > > > > I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl); > > > I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | > > > src_x); > > > @@ -3448,6 +3450,8 @@ static void > > > skylake_disable_primary_plane(struct drm_plane *primary, > > > struct drm_device *dev = crtc->dev; > > > struct drm_i915_private *dev_priv = to_i915(dev); > > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > > + struct intel_crtc_state *cstate = > > > to_intel_crtc_state(crtc->state); > > > + const struct skl_plane_wm *p_wm = &cstate- > > > > > > > > wm.skl.optimal.planes[0]; > > > int pipe = intel_crtc->pipe; > > > > > > /* > > > @@ -3455,7 +3459,8 @@ static void > > > skylake_disable_primary_plane(struct drm_plane *primary, > > > * plane's visiblity isn't actually changing neither is > > > its watermarks. > > > */ > > > if (!crtc->primary->state->visible) > > > - skl_write_plane_wm(intel_crtc, &dev_priv- > > > > > > > > wm.skl_results, 0); > > > + skl_write_plane_wm(intel_crtc, p_wm, > > > + &dev_priv- > > > >wm.skl_results.ddb, > > > 0); > > > > > > I915_WRITE(PLANE_CTL(pipe, 0), 0); > > > I915_WRITE(PLANE_SURF(pipe, 0), 0); > > > @@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct > > > drm_crtc *crtc, u32 base, > > > struct drm_device *dev = crtc->dev; > > > struct drm_i915_private *dev_priv = to_i915(dev); > > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > > + struct intel_crtc_state *cstate = > > > to_intel_crtc_state(crtc->state); > > > const struct skl_wm_values *wm = &dev_priv- > > > > > > > > wm.skl_results; > > > + const struct skl_plane_wm *p_wm = > > > + &cstate->wm.skl.optimal.planes[PLANE_CURSOR]
Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values
Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu: > Op 08-10-16 om 02:11 schreef Lyude: > > > > Now that we've make skl_wm_levels make a little more sense, we can > > remove all of the redundant wm information. Up until now we'd been > > storing two copies of all of the skl watermarks: one being the > > skl_pipe_wm structs, the other being the global wm struct in > > drm_i915_private containing the raw register values. This is > > confusing > > and problematic, since it means we're prone to accidentally letting > > the > > two copies go out of sync. So, get rid of all of the functions > > responsible for computing the register values and just use a single > > helper, skl_write_wm_level(), to convert and write the new > > watermarks on > > the fly. > > > > Changes since v1: > > - Fixup skl_write_wm_level() > > - Fixup skl_wm_level_from_reg_val() > > - Don't forget to copy *active to intel_crtc->wm.active.skl > > > > Signed-off-by: Lyude > > Reviewed-by: Maarten Lankhorst > > Cc: Ville Syrjälä > > Cc: Paulo Zanoni > > --- > > drivers/gpu/drm/i915/i915_drv.h | 2 - > > drivers/gpu/drm/i915/intel_display.c | 14 ++- > > drivers/gpu/drm/i915/intel_drv.h | 6 +- > > drivers/gpu/drm/i915/intel_pm.c | 204 --- > > > > drivers/gpu/drm/i915/intel_sprite.c | 8 +- > > 5 files changed, 90 insertions(+), 144 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > > index 0287c93..76583b2 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation { > > struct skl_wm_values { > > unsigned dirty_pipes; > > struct skl_ddb_allocation ddb; > > - uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8]; > > - uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES]; > > }; > > > > struct skl_wm_level { > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index a71d05a..39400a0 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -3378,6 +3378,8 @@ static void > > skylake_update_primary_plane(struct drm_plane *plane, > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state- > > >base.crtc); > > struct drm_framebuffer *fb = plane_state->base.fb; > > const struct skl_wm_values *wm = &dev_priv- > > >wm.skl_results; > > + const struct skl_plane_wm *p_wm = > > + &crtc_state->wm.skl.optimal.planes[0]; > > int pipe = intel_crtc->pipe; > > u32 plane_ctl; > > unsigned int rotation = plane_state->base.rotation; > > @@ -3414,7 +3416,7 @@ static void > > skylake_update_primary_plane(struct drm_plane *plane, > > intel_crtc->adjusted_y = src_y; > > > > if (wm->dirty_pipes & drm_crtc_mask(&intel_crtc->base)) > > - skl_write_plane_wm(intel_crtc, wm, 0); > > + skl_write_plane_wm(intel_crtc, p_wm, &wm->ddb, 0); > > > > I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl); > > I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x); > > @@ -3448,6 +3450,8 @@ static void > > skylake_disable_primary_plane(struct drm_plane *primary, > > struct drm_device *dev = crtc->dev; > > struct drm_i915_private *dev_priv = to_i915(dev); > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > + struct intel_crtc_state *cstate = > > to_intel_crtc_state(crtc->state); > > + const struct skl_plane_wm *p_wm = &cstate- > > >wm.skl.optimal.planes[0]; > > int pipe = intel_crtc->pipe; > > > > /* > > @@ -3455,7 +3459,8 @@ static void > > skylake_disable_primary_plane(struct drm_plane *primary, > > * plane's visiblity isn't actually changing neither is > > its watermarks. > > */ > > if (!crtc->primary->state->visible) > > - skl_write_plane_wm(intel_crtc, &dev_priv- > > >wm.skl_results, 0); > > + skl_write_plane_wm(intel_crtc, p_wm, > > + &dev_priv->wm.skl_results.ddb, > > 0); > > > > I915_WRITE(PLANE_CTL(pipe, 0), 0); > > I915_WRITE(PLANE_SURF(pipe, 0), 0); > > @@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct > > drm_crtc *crtc, u32 base, > > struct drm_device *dev = crtc->dev; > > struct drm_i915_private *dev_priv = to_i915(dev); > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > > + struct intel_crtc_state *cstate = > > to_intel_crtc_state(crtc->state); > > const struct skl_wm_values *wm = &dev_priv- > > >wm.skl_results; > > + const struct skl_plane_wm *p_wm = > > + &cstate->wm.skl.optimal.planes[PLANE_CURSOR]; > > int pipe = intel_crtc->pipe; > > uint32_t cntl = 0; > > > > if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes & > > drm_crtc_mask(crtc)) > > - skl_write_cursor_wm(intel_crtc, wm); > > + skl_write_cursor_wm(intel_crtc, p_wm, &wm->ddb); > > > > if (plane_state && plane_state->base.visi
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)
On Thu, Oct 13, 2016 at 06:47:24PM +, Saarinen, Jani wrote: > > > == Series Details == > > > > > > Series: drm/i915: Allocate intel_engine_cs structure only for the enabled > > engines (rev3) > > > URL : https://patchwork.freedesktop.org/series/13435/ > > > State : warning > > > > > > == Summary == > > > > > > Series 13435v3 drm/i915: Allocate intel_engine_cs structure only for > > > the enabled engines > > > https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/3/mbo > > > x/ > > > > > > Test vgem_basic: > > > Subgroup unload: > > > pass -> SKIP (fi-skl-6260u) > > > pass -> SKIP (fi-skl-6700hq) > > > skip -> PASS (fi-skl-6700k) > > > > > Checked with Chris about the above failure. > > He said that the above unload failure for vgem module can't be attributed to > > the patch, most likely a CI framework issue. > Yes, this test is still behaving badly especially with SKL systems but also > with bdw and kbl. Are the test run in the order defined by fast-feedback.testlist ? I intended the vgem unload test to be run as the first vgem testcase to minimise the chance of a stray module leak. Can we define the order within CI? Can we put comments into fast-feedback.testlist ? -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] drm/edid: Only print the bad edid when aborting
Currently, if drm.debug is enabled, we get a DRM_ERROR message on the intermediate edid reads. This causes transient failures in CI which flags up the sporadic EDID read failures, which are recovered by rereading the EDID automatically. This patch combines the reporting done by drm_do_get_edid() itself with the bad block printing from get_edid_block(), into a single warning associated with the connector once all attempts to retrieve the EDID fail. References: https://bugs.freedesktop.org/show_bug.cgi?id=98228 Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_edid.c | 82 +- 1 file changed, 44 insertions(+), 38 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index ec77bd3e1f08..51dd10c65b53 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1260,6 +1260,26 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int block, size_t len) return ret == xfers ? 0 : -1; } +static void connector_add_bad_edid(struct drm_connector *connector, + u8 *block, int num) +{ + if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS)) + return; + + if (drm_edid_is_zero(block, EDID_LENGTH)) { + dev_warn(connector->dev->dev, +"%s: EDID block %d is all zeroes.\n", +connector->name, num); + } else { + dev_warn(connector->dev->dev, +"%s: EDID block %d invalid:\n", +connector->name, num); + print_hex_dump(KERN_WARNING, + " \t", DUMP_PREFIX_NONE, 16, 1, + block, EDID_LENGTH, false); + } +} + /** * drm_do_get_edid - get EDID data using a custom EDID block read function * @connector: connector we're probing @@ -1282,20 +1302,19 @@ struct edid *drm_do_get_edid(struct drm_connector *connector, void *data) { int i, j = 0, valid_extensions = 0; - u8 *block, *new; - bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & DRM_UT_KMS); + u8 *edid, *new; - if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL) + if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL) return NULL; /* base block fetch */ for (i = 0; i < 4; i++) { - if (get_edid_block(data, block, 0, EDID_LENGTH)) + if (get_edid_block(data, edid, 0, EDID_LENGTH)) goto out; - if (drm_edid_block_valid(block, 0, print_bad_edid, + if (drm_edid_block_valid(edid, 0, false, &connector->edid_corrupt)) break; - if (i == 0 && drm_edid_is_zero(block, EDID_LENGTH)) { + if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) { connector->null_edid_counter++; goto carp; } @@ -1304,58 +1323,45 @@ struct edid *drm_do_get_edid(struct drm_connector *connector, goto carp; /* if there's no extensions, we're done */ - if (block[0x7e] == 0) - return (struct edid *)block; + if (edid[0x7e] == 0) + return (struct edid *)edid; - new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL); + new = krealloc(edid, (edid[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL); if (!new) goto out; - block = new; + edid = new; + + for (j = 1; j <= edid[0x7e]; j++) { + u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH; - for (j = 1; j <= block[0x7e]; j++) { for (i = 0; i < 4; i++) { - if (get_edid_block(data, - block + (valid_extensions + 1) * EDID_LENGTH, - j, EDID_LENGTH)) + if (get_edid_block(data, block, j, EDID_LENGTH)) goto out; - if (drm_edid_block_valid(block + (valid_extensions + 1) -* EDID_LENGTH, j, -print_bad_edid, -NULL)) { + if (drm_edid_block_valid(block, j, false, NULL)) { valid_extensions++; break; } } - if (i == 4 && print_bad_edid) { - dev_warn(connector->dev->dev, -"%s: Ignoring invalid EDID block %d.\n", -connector->name, j); - - connector->bad_edid_counter++; - } + if (i == 4) + connector_add_bad_edid(connector, block, j); } - if
Re: [Intel-gfx] [RFC PATCH v2 4/8] drm/i915: Add support for enabling/disabling hdmi audio interrupts
+/* Added for HDMI Audio */ +int i915_enable_hdmi_audio_int(struct drm_i915_private *dev_priv) +{ + unsigned long irqflags; + u32 imr, int_bit; + int pipe = -1; + + spin_lock_irqsave(&dev_priv->irq_lock, irqflags); + + imr = I915_READ(VLV_IMR); + + if (IS_CHERRYVIEW(&dev_priv->drm)) { + pipe = PIPE_C; + int_bit = (pipe ? (I915_LPE_PIPE_B_INTERRUPT >> + ((pipe - 1) * 9)) : + I915_LPE_PIPE_A_INTERRUPT); Either parametrize the I915_LPE_PIPE_INTERRUPT macro, or just have eg. a switch here. ok But the bigger issue here is the mess with selecting the right bit. I assume it should either depend on the pipe or port. I can't figure out what is going on here. And actually I don't understand why we even need this function. The irqchip should take care to unmask all the interrupts when the audio device does its request_irq. agree, it's not clear to me either. I'll work with Jerome to figure out if/how this can be removed. @@ -3364,6 +3425,14 @@ static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv) WARN_ON(dev_priv->irq_mask != ~0); + if (IS_LPE_AUDIO_ENABLED(dev_priv)) { + u32 val = (I915_LPE_PIPE_A_INTERRUPT | + I915_LPE_PIPE_B_INTERRUPT | + I915_LPE_PIPE_C_INTERRUPT); 'val' seems like a rather pointless local variable. + + enable_mask |= val; indeed, will fix. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH v2 1/8] drm/i915: setup bridge for HDMI LPE audio driver
Thanks Ville for the review. A lot of the comments are related to the initial VED code we took pretty much as is, no issues to clean-up further. BTW, it looks like Jerome's patches were stuck for 10+ days on the intel-gfx server for some reason so not everyone saw the initial post? @@ -1141,7 +1141,13 @@ static void i915_driver_register(struct drm_i915_private *dev_priv) if (IS_GEN5(dev_priv)) intel_gpu_ips_init(dev_priv); - i915_audio_component_init(dev_priv); + if (intel_lpe_audio_detect(dev_priv)) { + if (intel_lpe_audio_setup(dev_priv) < 0) + DRM_ERROR("failed to setup LPE Audio bridge\n"); + } I'd move all that into the lpe audio code. No need to have anything here but a single function call IMO. something like intel_lpe_audio_init() for symmetry with the hda component stuff, with both detection and setup handled internally? + + if (!IS_LPE_AUDIO_ENABLED(dev_priv)) I don't like that too much. I think I would just make that HAS_LPE_AUDIO(). The current IS_VLV||IS_CHV check can just be inlined into the init function. ok #define HAS_POOLED_EU(dev) (INTEL_INFO(dev)->has_pooled_eu) +#define HAS_LPE_AUDIO(dev) (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) +#define IS_LPE_AUDIO_ENABLED(dev_priv) \ + (__I915__(dev_priv)->lpe_audio.platdev != NULL) +#define IS_LPE_AUDIO_IRQ_VALID(dev_priv) \ + (__I915__(dev_priv)->lpe_audio.irq >= 0) Seems useless. We should just not register the lpe audio thing if we have no irq. ok --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1827,6 +1827,13 @@ static irqreturn_t valleyview_irq_handler(int irq, void *arg) * signalled in iir */ valleyview_pipestat_irq_ack(dev_priv, iir, pipe_stats); + if (IS_LPE_AUDIO_ENABLED(dev_priv)) + if (IS_LPE_AUDIO_IRQ_VALID(dev_priv)) I think both of these checks can be removed. We won't unmask the interrupts unless lpe is enabled, so the IIR bits will never be set in that case. + if (iir & (I915_LPE_PIPE_A_INTERRUPT | + I915_LPE_PIPE_B_INTERRUPT | + I915_LPE_PIPE_C_INTERRUPT)) + intel_lpe_audio_irq_handler(dev_priv); + ok. /* * VLV_IIR is single buffered, and reflects the level * from PIPESTAT/PORT_HOTPLUG_STAT, hence clear it last. @@ -1907,6 +1914,13 @@ static irqreturn_t cherryview_irq_handler(int irq, void *arg) * signalled in iir */ valleyview_pipestat_irq_ack(dev_priv, iir, pipe_stats); + if (IS_LPE_AUDIO_ENABLED(dev_priv)) + if (IS_LPE_AUDIO_IRQ_VALID(dev_priv)) + if (iir & (I915_LPE_PIPE_A_INTERRUPT | + I915_LPE_PIPE_B_INTERRUPT | + I915_LPE_PIPE_C_INTERRUPT)) + intel_lpe_audio_irq_handler(dev_priv); + ditto ok + platdev = platform_device_alloc("hdmi-lpe-audio", -1); + if (!platdev) { + ret = -ENOMEM; + DRM_ERROR("Failed to allocate LPE audio platform device\n"); + goto err; + } + + /* to work-around check_addr in nommu_map_sg() */ What's this about? Dunno, this was in the original VED series that we used as a baseline. Unless someone has memories from that time, i'll just remove this comment. + DRM_DEBUG("%s: HDMI_AUDIO rsc.start[0] = 0x%x\n", + __func__, (int)(rsc[0].start)); __func__ pointless since DRM_DEBUG alreay adds it. Also saying "rsc.start[0]" in the message doesn't tell anyone anything useful. And I think irq numbers are usually printed in decimal. Same, this was taken from the VED series, no issue to clean-up. + + rsc[1].start= pci_resource_start(dev->pdev, 0) + + I915_HDMI_LPE_AUDIO_BASE; + rsc[1].end = pci_resource_start(dev->pdev, 0) + + I915_HDMI_LPE_AUDIO_BASE + I915_HDMI_LPE_AUDIO_SIZE - 1; + rsc[1].flags= IORESOURCE_MEM; + rsc[1].name = "hdmi-lpe-audio-mmio"; + + DRM_DEBUG("%s: HDMI_AUDIO rsc.start[1] = 0x%x\n", + __func__, (int)(rsc[1].start)); Again "rsc[0].start" doesn't seem like anything useful to print in a debug message. Don't see much point in the whole debug message TBH since the start/end are fixed. so are you saying we should remove the code or move the level to DRM_INFO - for extra verbose debug? + + ret = platform_device_add_resources(platdev, rsc, 2); + if (ret) { + DRM_ERROR("Failed to add resource for platform device: %d\n", + ret); + goto err_put_de
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2
== Series Details == Series: drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2 URL : https://patchwork.freedesktop.org/series/13745/ State : success == Summary == Series 13745v1 drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2 https://patchwork.freedesktop.org/api/1.0/series/13745/revisions/1/mbox/ Test drv_module_reload_basic: skip -> PASS (fi-skl-6770hq) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (fi-ilk-650) Test vgem_basic: Subgroup unload: skip -> PASS (fi-hsw-4770) skip -> PASS (fi-skl-6770hq) fi-bdw-5557u total:246 pass:231 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:246 pass:204 dwarn:0 dfail:0 fail:0 skip:42 fi-bxt-t5700 total:246 pass:216 dwarn:0 dfail:0 fail:0 skip:30 fi-byt-j1900 total:246 pass:212 dwarn:2 dfail:0 fail:1 skip:31 fi-byt-n2820 total:246 pass:210 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-hsw-4770r total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-ilk-650 total:246 pass:184 dwarn:0 dfail:0 fail:2 skip:60 fi-ivb-3520m total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-kbl-7200u total:246 pass:222 dwarn:0 dfail:0 fail:0 skip:24 fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:246 pass:223 dwarn:0 dfail:0 fail:0 skip:23 fi-skl-6700k total:246 pass:221 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:246 pass:230 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:246 pass:210 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:246 pass:209 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2709/ dbcf6fbb541e70fac7db669631958eab2e4e0d9c drm-intel-nightly: 2016y-10m-13d-15h-31m-19s UTC integration manifest 36d0d8d drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)
> > == Series Details == > > > > Series: drm/i915: Allocate intel_engine_cs structure only for the enabled > engines (rev3) > > URL : https://patchwork.freedesktop.org/series/13435/ > > State : warning > > > > == Summary == > > > > Series 13435v3 drm/i915: Allocate intel_engine_cs structure only for > > the enabled engines > > https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/3/mbo > > x/ > > > > Test vgem_basic: > > Subgroup unload: > > pass -> SKIP (fi-skl-6260u) > > pass -> SKIP (fi-skl-6700hq) > > skip -> PASS (fi-skl-6700k) > > > Checked with Chris about the above failure. > He said that the above unload failure for vgem module can't be attributed to > the patch, most likely a CI framework issue. Yes, this test is still behaving badly especially with SKL systems but also with bdw and kbl. > > Best regards > Akash > > > fi-bdw-5557u total:248 pass:231 dwarn:0 dfail:0 fail:0 skip:17 > > fi-bsw-n3050 total:248 pass:204 dwarn:0 dfail:0 fail:0 skip:44 > > fi-bxt-t5700 total:248 pass:217 dwarn:0 dfail:0 fail:0 skip:31 > > fi-byt-j1900 total:248 pass:214 dwarn:1 dfail:0 fail:1 skip:32 > > fi-byt-n2820 total:248 pass:210 dwarn:0 dfail:0 fail:1 skip:37 > > fi-hsw-4770 total:248 pass:224 dwarn:0 dfail:0 fail:0 skip:24 > > fi-hsw-4770r total:248 pass:224 dwarn:0 dfail:0 fail:0 skip:24 > > fi-ilk-650 total:248 pass:185 dwarn:0 dfail:0 fail:2 skip:61 > > fi-ivb-3520m total:248 pass:221 dwarn:0 dfail:0 fail:0 skip:27 > > fi-ivb-3770 total:248 pass:207 dwarn:0 dfail:0 fail:0 skip:41 > > fi-kbl-7200u total:248 pass:222 dwarn:0 dfail:0 fail:0 skip:26 > > fi-skl-6260u total:248 pass:232 dwarn:0 dfail:0 fail:0 skip:16 > > fi-skl-6700hqtotal:248 pass:223 dwarn:1 dfail:0 fail:0 skip:24 > > fi-skl-6700k total:248 pass:222 dwarn:1 dfail:0 fail:0 skip:25 > > fi-skl-6770hqtotal:248 pass:231 dwarn:1 dfail:0 fail:1 skip:15 > > fi-snb-2520m total:248 pass:211 dwarn:0 dfail:0 fail:0 skip:37 > > fi-snb-2600 total:248 pass:209 dwarn:0 dfail:0 fail:0 skip:39 > > > > Results at /archive/results/CI_IGT_test/Patchwork_2652/ > > > > f35ed31aea66b3230c366fcba5f3456ae2cb956e drm-intel-nightly: > > 2016y-10m-10d-11h-28m-51s UTC integration manifest 401facf drm/i915: > > Allocate intel_engine_cs structure only for the enabled engines > > Jani Saarinen ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2
On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote: > According to BSpec, cdclk has to be not less than 432 MHz with DP audio > enabled, port width x4, and link rate HBR2 (5.4 GHz) > > Having a lower cdclk triggers pipe underruns, which then lead to displays > continuously cycling off and on. This is essential for DP MST audio as the > link is trained at HBR2 and 4 lanes by default. > > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907 > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_display.c | 47 > +--- > 1 file changed, 43 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index cfcb03f..6a05183 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct > drm_atomic_state *state) > return 0; > } > > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state) > +{ > + > + struct drm_crtc_state *crtc_state; > + struct drm_crtc *crtc; > + int i; > + > + /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz, > + * audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else > + * there may be audio corruption or screen corruption." > + */ > + > + for_each_crtc_in_state(state, crtc, crtc_state, i) { > + struct intel_crtc_state *pipe_config = > + to_intel_crtc_state(crtc_state); > + > + return (intel_crtc_has_dp_encoder(pipe_config) && > + pipe_config->has_audio && > + pipe_config->port_clock == 54 && > + pipe_config->lane_count == 4); > + } That's not good enough on account of crtcs not part of the state potentially needing the workaround as well. However, since we only do this when there's a modeset, I think we'll be covered by the connection_mutex, and so we should be able to peek at the current state of all crtcs without grabbing the corresponding crtc locks. So I think we'd be OK with something like: WARN_ON(!locked(connection_mutex)); for_each_intel_crtc() { /* * Peeking at the current state is safe since * we can only get here while holding the * connection_mutex. */ crtc_state = intel_get_existing_crtc_state(); if (!crtc_state) crtc_state = to_intel_crtc_state(crtc->base.state); ... } The other option would be to track the min cdclk for each pipe in the top level state I suppose. We already do that for the pixel rate actually so that we can calculate the cdclk to begin with. Hmm. Maybe we should just switch to tracking the min cdclk per pipe instead of the pixel rate. Or did we need to the pixel rate itself for something else, Maarten? Or we could perhaps replace the pixel rate/pixclk tracking with the peek approach entirely. Not quite sure. Would have to read the entire thing through. > + > + return false; > +} > + > static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state) > { > int max_pixclk = ilk_max_pixel_rate(state); > + int cdclk, min_cdclk = 0; > struct intel_atomic_state *intel_state = > to_intel_atomic_state(state); > > - intel_state->cdclk = intel_state->dev_cdclk = > - bxt_calc_cdclk(max_pixclk); > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = bxt_calc_cdclk(432000); > + > + cdclk = bxt_calc_cdclk(max_pixclk); > + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk); > > if (!intel_state->active_crtcs) > intel_state->dev_cdclk = bxt_calc_cdclk(0); > @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct > drm_atomic_state *state) > struct drm_i915_private *dev_priv = to_i915(state->dev); > struct intel_atomic_state *intel_state = to_intel_atomic_state(state); > int max_pixclk = ilk_max_pixel_rate(state); > - int cdclk; > + int cdclk, min_cdclk = 0; > + > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = broadwell_calc_cdclk(432000); > > /* >* FIXME should also account for plane ratio > @@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct > drm_atomic_state *state) >*/ > cdclk = broadwell_calc_cdclk(max_pixclk); > > + cdclk = max(min_cdclk, cdclk); > + > if (cdclk > dev_priv->max_cdclk_freq) { > DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n", > cdclk, dev_priv->max_cdclk_freq); > @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct > drm_atomic_state *state) > struct drm_i915_private *dev_priv = to_i915(state->dev); > const int max_pixclk = ilk_max_pixel_rate(state); > int vco = intel_state->cdclk
Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2
On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote: > According to BSpec, cdclk has to be not less than 432 MHz with DP audio > enabled, port width x4, and link rate HBR2 (5.4 GHz) > > Having a lower cdclk triggers pipe underruns, which then lead to displays > continuously cycling off and on. This is essential for DP MST audio as the > link is trained at HBR2 and 4 lanes by default. > > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907 > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_display.c | 47 > +--- > 1 file changed, 43 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index cfcb03f..6a05183 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct > drm_atomic_state *state) > return 0; > } > > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state) > +{ > + > + struct drm_crtc_state *crtc_state; > + struct drm_crtc *crtc; > + int i; > + > + /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz, > + * audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else > + * there may be audio corruption or screen corruption." > + */ It's probably worth mentioning that this limitation really only applies for SKL (at least that I can see) and BXT A (which I don't think we even care about anymore since it's not a production part.) Were we seeing underruns on non-SKL platforms that increasing CDCLK fixed? In any event, I'd rather see this only implemented for SKL (see BDW code below) unless we've empirically noticed a similar problem on BDW (or the B-Spec says something about this and I missed it.) Jim > + > + for_each_crtc_in_state(state, crtc, crtc_state, i) { > + struct intel_crtc_state *pipe_config = > + to_intel_crtc_state(crtc_state); > + > + return (intel_crtc_has_dp_encoder(pipe_config) && > + pipe_config->has_audio && > + pipe_config->port_clock == 54 && > + pipe_config->lane_count == 4); > + } > + > + return false; > +} > + > static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state) > { > int max_pixclk = ilk_max_pixel_rate(state); > + int cdclk, min_cdclk = 0; > struct intel_atomic_state *intel_state = > to_intel_atomic_state(state); > > - intel_state->cdclk = intel_state->dev_cdclk = > - bxt_calc_cdclk(max_pixclk); > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = bxt_calc_cdclk(432000); > + > + cdclk = bxt_calc_cdclk(max_pixclk); > + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk); > > if (!intel_state->active_crtcs) > intel_state->dev_cdclk = bxt_calc_cdclk(0); > @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct > drm_atomic_state *state) > struct drm_i915_private *dev_priv = to_i915(state->dev); > struct intel_atomic_state *intel_state = to_intel_atomic_state(state); > int max_pixclk = ilk_max_pixel_rate(state); > - int cdclk; > + int cdclk, min_cdclk = 0; > + > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = broadwell_calc_cdclk(432000); > > /* >* FIXME should also account for plane ratio > @@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct > drm_atomic_state *state) >*/ > cdclk = broadwell_calc_cdclk(max_pixclk); > > + cdclk = max(min_cdclk, cdclk); > + > if (cdclk > dev_priv->max_cdclk_freq) { > DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n", > cdclk, dev_priv->max_cdclk_freq); > @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct > drm_atomic_state *state) > struct drm_i915_private *dev_priv = to_i915(state->dev); > const int max_pixclk = ilk_max_pixel_rate(state); > int vco = intel_state->cdclk_pll_vco; > - int cdclk; > + int cdclk, min_cdclk = 0; > + > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = skl_calc_cdclk(432000, vco); > > /* >* FIXME should also account for plane ratio > @@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct > drm_atomic_state *state) >*/ > cdclk = skl_calc_cdclk(max_pixclk, vco); > > + cdclk = max(min_cdclk, cdclk); > + > /* >* FIXME move the cdclk caclulation to >* compute_config() so we can fail gracegully. > -- > 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports
On Thu, Oct 13, 2016 at 11:06:55AM -0700, Jim Bride wrote: > On Tue, Oct 11, 2016 at 08:52:46PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > The VBT provides the platform a way to mix and match the DDI ports vs. > > GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose > > has no standard GMBUS pin assignment. However, there are machines out > > there that use a non-standard mapping for the other ports as well. > > Let's start trusting the VBT on this one for all ports on DDI platforms. > > > > I've structured the code such that other platforms could easily start > > using this as well, by simply filling in the ddi_port_info. IIRC there > > may be CHV system that might actually need this. > > > > v2: Include a commit message, include a debug message during init > > > > Cc: sta...@vger.kernel.org > > Cc: Maarten Maathuis > > Tested-by: Maarten Maatt show huis > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877 > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/intel_hdmi.c | 84 > > ++- > > 1 file changed, 48 insertions(+), 36 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > > b/drivers/gpu/drm/i915/intel_hdmi.c > > index 8d46f5836746..9ca86e901fc8 100644 > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > @@ -1799,6 +1799,50 @@ intel_hdmi_add_properties(struct intel_hdmi > > *intel_hdmi, struct drm_connector *c > > intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > > } > > > > +static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv, > > +enum port port) > > +{ > > + const struct ddi_vbt_port_info *info = > > + &dev_priv->vbt.ddi_port_info[port]; > > + u8 ddc_pin; > > + > > + if (info->alternate_ddc_pin) { > > + DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (VBT)\n", > > + info->alternate_ddc_pin, port_name(port)); > > + return info->alternate_ddc_pin; > > + } > > + > > + switch (port) { > > + case PORT_B: > > + if (IS_BROXTON(dev_priv)) > > + ddc_pin = GMBUS_PIN_1_BXT; > > + else > > + ddc_pin = GMBUS_PIN_DPB; > > + break; > > + case PORT_C: > > + if (IS_BROXTON(dev_priv)) > > + ddc_pin = GMBUS_PIN_2_BXT; > > + else > > + ddc_pin = GMBUS_PIN_DPC; > > + break; > > + case PORT_D: > > + if (IS_CHERRYVIEW(dev_priv)) > > + ddc_pin = GMBUS_PIN_DPD_CHV; > > + else > > + ddc_pin = GMBUS_PIN_DPD; > > In the code removed below there's a specific case covering Broxton that > isn't accounted for here. Are we sure that we don't need that logic here? Yeah, BXT doesn't have port D. I guess we could split this up into a few platform specific functions that could then have the MISSING_CASE() for the impossible ports. A bit like the AUX ctl/data register setup functions we have. Do pople want that level of paranoia here? > > Jim > > > + break; > > + default: > > + MISSING_CASE(port); > > + ddc_pin = GMBUS_PIN_DPB; > > + break; > > + } > > + > > + DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (platform default)\n", > > + ddc_pin, port_name(port)); > > + > > + return ddc_pin; > > +} > > + > > void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, > >struct intel_connector *intel_connector) > > { > > @@ -1808,7 +1852,6 @@ void intel_hdmi_init_connector(struct > > intel_digital_port *intel_dig_port, > > struct drm_device *dev = intel_encoder->base.dev; > > struct drm_i915_private *dev_priv = to_i915(dev); > > enum port port = intel_dig_port->port; > > - uint8_t alternate_ddc_pin; > > > > DRM_DEBUG_KMS("Adding HDMI connector on port %c\n", > > port_name(port)); > > @@ -1826,12 +1869,10 @@ void intel_hdmi_init_connector(struct > > intel_digital_port *intel_dig_port, > > connector->doublescan_allowed = 0; > > connector->stereo_allowed = 1; > > > > + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); > > + > > switch (port) { > > case PORT_B: > > - if (IS_BROXTON(dev_priv)) > > - intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT; > > - else > > - intel_hdmi->ddc_bus = GMBUS_PIN_DPB; > > /* > > * On BXT A0/A1, sw needs to activate DDIA HPD logic and > > * interrupts to check the external panel connection. > > @@ -1842,46 +1883,17 @@ void intel_hdmi_init_connector(struct > > intel_digital_port *intel_dig_port, > > intel_encoder->hpd_pin = HPD_PORT_B; > > break; > > case PORT_C: > > - if (IS_BROXTON(dev_priv)) > > - intel_hdmi->d
Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2
Em Qui, 2016-10-13 às 11:04 -0700, Dhinakaran Pandiyan escreveu: > According to BSpec, cdclk has to be not less than 432 MHz with DP > audio > enabled, port width x4, and link rate HBR2 (5.4 GHz) This is just for pre-production hardware, and we don't implement workarounds for pre-prod. A quick research seems to indicate that our CDCLK must be at least twice the frequency of the audio BCLK. Maybe this is what we need to investigate/check? Anyway, it looks like we're getting closer to the final bug fix. > > Having a lower cdclk triggers pipe underruns, which then lead to > displays > continuously cycling off and on. This is essential for DP MST audio > as the > link is trained at HBR2 and 4 lanes by default. > > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907 Please use the "Bugzilla:" tag since there are some scripts and robots that parse it and do stuff with it. > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_display.c | 47 > +--- > 1 file changed, 43 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index cfcb03f..6a05183 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -6603,14 +6603,43 @@ static int > valleyview_modeset_calc_cdclk(struct drm_atomic_state *state) > return 0; > } > > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state) > +{ > + > + struct drm_crtc_state *crtc_state; > + struct drm_crtc *crtc; > + int i; > + > + /* BSpec says "Do not use DisplayPort with CDCLK less than > 432 MHz, > + * audio enabled, port width x4, and link rate HBR2 (5.4 > GHz), or else > + * there may be audio corruption or screen corruption." > + */ > + > + for_each_crtc_in_state(state, crtc, crtc_state, i) { > + struct intel_crtc_state *pipe_config = > + to_intel_crtc_state(crtc_state); > + > + return (intel_crtc_has_dp_encoder(pipe_config) && > + pipe_config->has_audio && > + pipe_config->port_clock == 54 && > + pipe_config->lane_count == 4); > + } > + > + return false; > +} > + > static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state) > { > int max_pixclk = ilk_max_pixel_rate(state); > + int cdclk, min_cdclk = 0; > struct intel_atomic_state *intel_state = > to_intel_atomic_state(state); > > - intel_state->cdclk = intel_state->dev_cdclk = > - bxt_calc_cdclk(max_pixclk); > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = bxt_calc_cdclk(432000); > + > + cdclk = bxt_calc_cdclk(max_pixclk); > + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, > cdclk); > > if (!intel_state->active_crtcs) > intel_state->dev_cdclk = bxt_calc_cdclk(0); > @@ -10374,7 +10403,10 @@ static int > broadwell_modeset_calc_cdclk(struct drm_atomic_state *state) > struct drm_i915_private *dev_priv = to_i915(state->dev); > struct intel_atomic_state *intel_state = > to_intel_atomic_state(state); > int max_pixclk = ilk_max_pixel_rate(state); > - int cdclk; > + int cdclk, min_cdclk = 0; > + > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = broadwell_calc_cdclk(432000); > > /* > * FIXME should also account for plane ratio > @@ -10382,6 +10414,8 @@ static int > broadwell_modeset_calc_cdclk(struct drm_atomic_state *state) > */ > cdclk = broadwell_calc_cdclk(max_pixclk); > > + cdclk = max(min_cdclk, cdclk); > + > if (cdclk > dev_priv->max_cdclk_freq) { > DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max > (%d kHz)\n", > cdclk, dev_priv->max_cdclk_freq); > @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct > drm_atomic_state *state) > struct drm_i915_private *dev_priv = to_i915(state->dev); > const int max_pixclk = ilk_max_pixel_rate(state); > int vco = intel_state->cdclk_pll_vco; > - int cdclk; > + int cdclk, min_cdclk = 0; > + > + if (cdclk_min_for_dp_audio(state)) > + min_cdclk = skl_calc_cdclk(432000, vco); > > /* > * FIXME should also account for plane ratio > @@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct > drm_atomic_state *state) > */ > cdclk = skl_calc_cdclk(max_pixclk, vco); > > + cdclk = max(min_cdclk, cdclk); > + > /* > * FIXME move the cdclk caclulation to > * compute_config() so we can fail gracegully. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Fix whitespace issues
On Tue, Oct 11, 2016 at 08:52:48PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Fix the poorly indented port parameters to the aux ctl and data > reg functions. This was fallout from the s/i915_mmio_reg_t/i915_reg_t/ > that happened during the review of commit f0f59a00a1c9 ("drm/i915: > Type safe register read/write") > > Signed-off-by: Ville Syrjälä Reviewed-by: Jim Bride > --- > drivers/gpu/drm/i915/intel_dp.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index b0753b272101..25cde7356b59 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1147,7 +1147,7 @@ static enum port intel_aux_port(struct drm_i915_private > *dev_priv, > } > > static i915_reg_t g4x_aux_ctl_reg(struct drm_i915_private *dev_priv, > -enum port port) > + enum port port) > { > switch (port) { > case PORT_B: > @@ -1161,7 +1161,7 @@ static i915_reg_t g4x_aux_ctl_reg(struct > drm_i915_private *dev_priv, > } > > static i915_reg_t g4x_aux_data_reg(struct drm_i915_private *dev_priv, > - enum port port, int index) > +enum port port, int index) > { > switch (port) { > case PORT_B: > @@ -1175,7 +1175,7 @@ static i915_reg_t g4x_aux_data_reg(struct > drm_i915_private *dev_priv, > } > > static i915_reg_t ilk_aux_ctl_reg(struct drm_i915_private *dev_priv, > -enum port port) > + enum port port) > { > switch (port) { > case PORT_A: > @@ -1191,7 +1191,7 @@ static i915_reg_t ilk_aux_ctl_reg(struct > drm_i915_private *dev_priv, > } > > static i915_reg_t ilk_aux_data_reg(struct drm_i915_private *dev_priv, > - enum port port, int index) > +enum port port, int index) > { > switch (port) { > case PORT_A: > @@ -1207,7 +1207,7 @@ static i915_reg_t ilk_aux_data_reg(struct > drm_i915_private *dev_priv, > } > > static i915_reg_t skl_aux_ctl_reg(struct drm_i915_private *dev_priv, > -enum port port) > + enum port port) > { > switch (port) { > case PORT_A: > @@ -1222,7 +1222,7 @@ static i915_reg_t skl_aux_ctl_reg(struct > drm_i915_private *dev_priv, > } > > static i915_reg_t skl_aux_data_reg(struct drm_i915_private *dev_priv, > - enum port port, int index) > +enum port port, int index) > { > switch (port) { > case PORT_A: > @@ -1237,7 +1237,7 @@ static i915_reg_t skl_aux_data_reg(struct > drm_i915_private *dev_priv, > } > > static i915_reg_t intel_aux_ctl_reg(struct drm_i915_private *dev_priv, > - enum port port) > + enum port port) > { > if (INTEL_INFO(dev_priv)->gen >= 9) > return skl_aux_ctl_reg(dev_priv, port); > @@ -1248,7 +1248,7 @@ static i915_reg_t intel_aux_ctl_reg(struct > drm_i915_private *dev_priv, > } > > static i915_reg_t intel_aux_data_reg(struct drm_i915_private *dev_priv, > - enum port port, int index) > + enum port port, int index) > { > if (INTEL_INFO(dev_priv)->gen >= 9) > return skl_aux_data_reg(dev_priv, port, index); > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation
On Tue, Oct 11, 2016 at 08:52:47PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Now that we use the AUX and GMBUS assignment from VBT for all ports, > let's clean up the sanitization of the port information a bit. > Previosuly we only did this for port E, and only complained about a > non-standard assignment for the other ports. But as we know that > non-standard assignments are a fact of life, let's expand the > sanitization to all the ports. > > v2: Include a commit message, fix up the comments a bit > > Cc: sta...@vger.kernel.org > Cc: Maarten Maathuis > Tested-by: Maarten Maathuis > References: https://bugs.freedesktop.org/show_bug.cgi?id=97877 > Signed-off-by: Ville Syrjälä Reviewed-by: Jim Bride > --- > drivers/gpu/drm/i915/intel_bios.c | 116 > +++--- > 1 file changed, 71 insertions(+), 45 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_bios.c > b/drivers/gpu/drm/i915/intel_bios.c > index 83667e8cdd6b..6d1ffa815e97 100644 > --- a/drivers/gpu/drm/i915/intel_bios.c > +++ b/drivers/gpu/drm/i915/intel_bios.c > @@ -1035,6 +1035,71 @@ static u8 translate_iboost(u8 val) > return mapping[val]; > } > > +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv, > + enum port port) > +{ > + const struct ddi_vbt_port_info *info = > + &dev_priv->vbt.ddi_port_info[port]; > + enum port p; > + > + for_each_port_masked(p, (1 << port) - 1) { > + struct ddi_vbt_port_info *i = &dev_priv->vbt.ddi_port_info[p]; > + > + if (info->alternate_ddc_pin != i->alternate_ddc_pin) > + continue; > + > + DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) as > port %c, " > + "disabling port %c DVI/HDMI support\n", > + port_name(p), i->alternate_ddc_pin, > + port_name(port), port_name(p)); > + > + /* > + * If we have multiple ports supposedly sharing the > + * pin, then dvi/hdmi couldn't exist on the shared > + * port. Otherwise they share the same ddc bin and > + * system couldn't communicate with them separately. > + * > + * Due to parsing the ports in alphabetical order, > + * a higher port will always clobber a lower one. > + */ > + i->supports_dvi = false; > + i->supports_hdmi = false; > + i->alternate_ddc_pin = 0; > + } > +} > + > +static void sanitize_aux_ch(struct drm_i915_private *dev_priv, > + enum port port) > +{ > + const struct ddi_vbt_port_info *info = > + &dev_priv->vbt.ddi_port_info[port]; > + enum port p; > + > + for_each_port_masked(p, (1 << port) - 1) { > + struct ddi_vbt_port_info *i = &dev_priv->vbt.ddi_port_info[p]; > + > + if (info->alternate_aux_channel != i->alternate_aux_channel) > + continue; > + > + DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as > port %c, " > + "disabling port %c DP support\n", > + port_name(p), i->alternate_aux_channel, > + port_name(port), port_name(p)); > + > + /* > + * If we have multiple ports supposedlt sharing the > + * aux channel, then DP couldn't exist on the shared > + * port. Otherwise they share the same aux channel > + * and system couldn't communicate with them separately. > + * > + * Due to parsing the ports in alphabetical order, > + * a higher port will always clobber a lower one. > + */ > + i->supports_dp = false; > + i->alternate_aux_channel = 0; > + } > +} > + > static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port, > const struct bdb_header *bdb) > { > @@ -1109,54 +1174,15 @@ static void parse_ddi_port(struct drm_i915_private > *dev_priv, enum port port, > DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port)); > > if (is_dvi) { > - if (port == PORT_E) { > - info->alternate_ddc_pin = ddc_pin; > - /* if DDIE share ddc pin with other port, then > - * dvi/hdmi couldn't exist on the shared port. > - * Otherwise they share the same ddc bin and system > - * couldn't communicate with them seperately. */ > - if (ddc_pin == DDC_PIN_B) { > - > dev_priv->vbt.ddi_port_info[PORT_B].supports_dvi = 0; > - > dev_priv->vbt.ddi_port_info[PORT_B].supports_hdmi = 0; > - } else if (ddc_pin == DDC_PIN_C) { > -
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports
On Tue, Oct 11, 2016 at 08:52:46PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The VBT provides the platform a way to mix and match the DDI ports vs. > GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose > has no standard GMBUS pin assignment. However, there are machines out > there that use a non-standard mapping for the other ports as well. > Let's start trusting the VBT on this one for all ports on DDI platforms. > > I've structured the code such that other platforms could easily start > using this as well, by simply filling in the ddi_port_info. IIRC there > may be CHV system that might actually need this. > > v2: Include a commit message, include a debug message during init > > Cc: sta...@vger.kernel.org > Cc: Maarten Maathuis > Tested-by: Maarten Maatt show huis > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877 > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_hdmi.c | 84 > ++- > 1 file changed, 48 insertions(+), 36 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index 8d46f5836746..9ca86e901fc8 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1799,6 +1799,50 @@ intel_hdmi_add_properties(struct intel_hdmi > *intel_hdmi, struct drm_connector *c > intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > } > > +static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv, > + enum port port) > +{ > + const struct ddi_vbt_port_info *info = > + &dev_priv->vbt.ddi_port_info[port]; > + u8 ddc_pin; > + > + if (info->alternate_ddc_pin) { > + DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (VBT)\n", > + info->alternate_ddc_pin, port_name(port)); > + return info->alternate_ddc_pin; > + } > + > + switch (port) { > + case PORT_B: > + if (IS_BROXTON(dev_priv)) > + ddc_pin = GMBUS_PIN_1_BXT; > + else > + ddc_pin = GMBUS_PIN_DPB; > + break; > + case PORT_C: > + if (IS_BROXTON(dev_priv)) > + ddc_pin = GMBUS_PIN_2_BXT; > + else > + ddc_pin = GMBUS_PIN_DPC; > + break; > + case PORT_D: > + if (IS_CHERRYVIEW(dev_priv)) > + ddc_pin = GMBUS_PIN_DPD_CHV; > + else > + ddc_pin = GMBUS_PIN_DPD; In the code removed below there's a specific case covering Broxton that isn't accounted for here. Are we sure that we don't need that logic here? Jim > + break; > + default: > + MISSING_CASE(port); > + ddc_pin = GMBUS_PIN_DPB; > + break; > + } > + > + DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (platform default)\n", > + ddc_pin, port_name(port)); > + > + return ddc_pin; > +} > + > void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, > struct intel_connector *intel_connector) > { > @@ -1808,7 +1852,6 @@ void intel_hdmi_init_connector(struct > intel_digital_port *intel_dig_port, > struct drm_device *dev = intel_encoder->base.dev; > struct drm_i915_private *dev_priv = to_i915(dev); > enum port port = intel_dig_port->port; > - uint8_t alternate_ddc_pin; > > DRM_DEBUG_KMS("Adding HDMI connector on port %c\n", > port_name(port)); > @@ -1826,12 +1869,10 @@ void intel_hdmi_init_connector(struct > intel_digital_port *intel_dig_port, > connector->doublescan_allowed = 0; > connector->stereo_allowed = 1; > > + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); > + > switch (port) { > case PORT_B: > - if (IS_BROXTON(dev_priv)) > - intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT; > - else > - intel_hdmi->ddc_bus = GMBUS_PIN_DPB; > /* >* On BXT A0/A1, sw needs to activate DDIA HPD logic and >* interrupts to check the external panel connection. > @@ -1842,46 +1883,17 @@ void intel_hdmi_init_connector(struct > intel_digital_port *intel_dig_port, > intel_encoder->hpd_pin = HPD_PORT_B; > break; > case PORT_C: > - if (IS_BROXTON(dev_priv)) > - intel_hdmi->ddc_bus = GMBUS_PIN_2_BXT; > - else > - intel_hdmi->ddc_bus = GMBUS_PIN_DPC; > intel_encoder->hpd_pin = HPD_PORT_C; > break; > case PORT_D: > - if (WARN_ON(IS_BROXTON(dev_priv))) > - intel_hdmi->ddc_bus = GMBUS_PIN_DISABLED; > - else if (IS_CHERRYVIEW(dev_priv)) > - intel_hdmi->ddc_bus = GMBUS_PIN_DPD_CHV; > -
Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
[Adding Matt] On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote: > Bisecting the offending commit between v4.8 and v4.8.1 would be a good > start. 0) Why use a personal notebook when one can just post any half baked idea to lkml? 1) I stumbled on https://bugzilla.redhat.com/show_bug.cgi?id=1361357 (s ame hardware, rather similar trace). 2) That report was about the first Fedora (rawhide) kernel release after this commit http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/co mmit/?h=f25&id=7d2c2f2d91793b5da452bee9bea4fa32051c8608 ("Bring in patch-series from drm-next to fix skl_update_other_pipe_wm issues"). 3) That seventeen part series ended up in v4.8. The last commit of that series is commit 5b483747a925 ("drm/i915: Remove wm_config from dev_priv/intel_atomic_state"). 4) So, with a little bit of luck, my bisect might only need to look at those seventeen commits. Still, it will probably be next week before I have a day or two to actually perform that bisect. To be continued, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2
According to BSpec, cdclk has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz) Having a lower cdclk triggers pipe underruns, which then lead to displays continuously cycling off and on. This is essential for DP MST audio as the link is trained at HBR2 and 4 lanes by default. This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907 Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_display.c | 47 +--- 1 file changed, 43 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index cfcb03f..6a05183 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct drm_atomic_state *state) return 0; } +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state) +{ + + struct drm_crtc_state *crtc_state; + struct drm_crtc *crtc; + int i; + + /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz, +* audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else +* there may be audio corruption or screen corruption." +*/ + + for_each_crtc_in_state(state, crtc, crtc_state, i) { + struct intel_crtc_state *pipe_config = + to_intel_crtc_state(crtc_state); + + return (intel_crtc_has_dp_encoder(pipe_config) && + pipe_config->has_audio && + pipe_config->port_clock == 54 && + pipe_config->lane_count == 4); + } + + return false; +} + static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state) { int max_pixclk = ilk_max_pixel_rate(state); + int cdclk, min_cdclk = 0; struct intel_atomic_state *intel_state = to_intel_atomic_state(state); - intel_state->cdclk = intel_state->dev_cdclk = - bxt_calc_cdclk(max_pixclk); + if (cdclk_min_for_dp_audio(state)) + min_cdclk = bxt_calc_cdclk(432000); + + cdclk = bxt_calc_cdclk(max_pixclk); + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk); if (!intel_state->active_crtcs) intel_state->dev_cdclk = bxt_calc_cdclk(0); @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct drm_atomic_state *state) struct drm_i915_private *dev_priv = to_i915(state->dev); struct intel_atomic_state *intel_state = to_intel_atomic_state(state); int max_pixclk = ilk_max_pixel_rate(state); - int cdclk; + int cdclk, min_cdclk = 0; + + if (cdclk_min_for_dp_audio(state)) + min_cdclk = broadwell_calc_cdclk(432000); /* * FIXME should also account for plane ratio @@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct drm_atomic_state *state) */ cdclk = broadwell_calc_cdclk(max_pixclk); + cdclk = max(min_cdclk, cdclk); + if (cdclk > dev_priv->max_cdclk_freq) { DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n", cdclk, dev_priv->max_cdclk_freq); @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state *state) struct drm_i915_private *dev_priv = to_i915(state->dev); const int max_pixclk = ilk_max_pixel_rate(state); int vco = intel_state->cdclk_pll_vco; - int cdclk; + int cdclk, min_cdclk = 0; + + if (cdclk_min_for_dp_audio(state)) + min_cdclk = skl_calc_cdclk(432000, vco); /* * FIXME should also account for plane ratio @@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state *state) */ cdclk = skl_calc_cdclk(max_pixclk, vco); + cdclk = max(min_cdclk, cdclk); + /* * FIXME move the cdclk caclulation to * compute_config() so we can fail gracegully. -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Respect alternate_aux_channel for all DDI ports
On Tue, Oct 11, 2016 at 08:52:45PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The VBT provides the platform a way to mix and match the DDI ports vs. > AUX channels. Currently we only trust the VBT for DDI E, which has no > corresponding AUX channel of its own. However it is possible that some > board might use some non-standard DDI vs. AUX port routing even for > the other ports. Perhaps for signal routing reasons or something, > So let's generalize this and trust the VBT for all ports. > > For now we'll limit this to DDI platforms, as we trust the VBT a bit > more there anyway when it comes to the DDI ports. I've structured > the code in a way that would allow us to easily expand this to > other platforms as well, by simply filling in the ddi_port_info. > > v2: Drop whitespace changes, keep MISSING_CASE() for unknown > aux ch assignment, include a commit message, include debug > message during init > > Cc: sta...@vger.kernel.org > Cc: Maarten Maathuis > Tested-by: Maarten Maathuis > References: https://bugs.freedesktop.org/show_bug.cgi?id=97877 > Signed-off-by: Ville Syrjälä Reviewed-by: Jim Bride > --- > drivers/gpu/drm/i915/intel_dp.c | 71 > +++-- > 1 file changed, 40 insertions(+), 31 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 5992093e1814..b0753b272101 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1108,6 +1108,44 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct > drm_dp_aux_msg *msg) > return ret; > } > > +static enum port intel_aux_port(struct drm_i915_private *dev_priv, > + enum port port) > +{ > + const struct ddi_vbt_port_info *info = > + &dev_priv->vbt.ddi_port_info[port]; > + enum port aux_port; > + > + if (!info->alternate_aux_channel) { > + DRM_DEBUG_KMS("using AUX %c for port %c (platform default)\n", > + port_name(port), port_name(port)); > + return port; > + } > + > + switch (info->alternate_aux_channel) { > + case DP_AUX_A: > + aux_port = PORT_A; > + break; > + case DP_AUX_B: > + aux_port = PORT_B; > + break; > + case DP_AUX_C: > + aux_port = PORT_C; > + break; > + case DP_AUX_D: > + aux_port = PORT_D; > + break; > + default: > + MISSING_CASE(info->alternate_aux_channel); > + aux_port = PORT_A; > + break; > + } > + > + DRM_DEBUG_KMS("using AUX %c for port %c (VBT)\n", > + port_name(aux_port), port_name(port)); > + > + return aux_port; > +} > + > static i915_reg_t g4x_aux_ctl_reg(struct drm_i915_private *dev_priv, > enum port port) > { > @@ -1168,36 +1206,9 @@ static i915_reg_t ilk_aux_data_reg(struct > drm_i915_private *dev_priv, > } > } > > -/* > - * On SKL we don't have Aux for port E so we rely > - * on VBT to set a proper alternate aux channel. > - */ > -static enum port skl_porte_aux_port(struct drm_i915_private *dev_priv) > -{ > - const struct ddi_vbt_port_info *info = > - &dev_priv->vbt.ddi_port_info[PORT_E]; > - > - switch (info->alternate_aux_channel) { > - case DP_AUX_A: > - return PORT_A; > - case DP_AUX_B: > - return PORT_B; > - case DP_AUX_C: > - return PORT_C; > - case DP_AUX_D: > - return PORT_D; > - default: > - MISSING_CASE(info->alternate_aux_channel); > - return PORT_A; > - } > -} > - > static i915_reg_t skl_aux_ctl_reg(struct drm_i915_private *dev_priv, > enum port port) > { > - if (port == PORT_E) > - port = skl_porte_aux_port(dev_priv); > - > switch (port) { > case PORT_A: > case PORT_B: > @@ -1213,9 +1224,6 @@ static i915_reg_t skl_aux_ctl_reg(struct > drm_i915_private *dev_priv, > static i915_reg_t skl_aux_data_reg(struct drm_i915_private *dev_priv, > enum port port, int index) > { > - if (port == PORT_E) > - port = skl_porte_aux_port(dev_priv); > - > switch (port) { > case PORT_A: > case PORT_B: > @@ -1253,7 +1261,8 @@ static i915_reg_t intel_aux_data_reg(struct > drm_i915_private *dev_priv, > static void intel_aux_reg_init(struct intel_dp *intel_dp) > { > struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp)); > - enum port port = dp_to_dig_port(intel_dp)->port; > + enum port port = intel_aux_port(dev_priv, > + dp_to_dig_port(intel_dp)->port); > int i; > > intel_dp->aux_ch_ctl_reg = intel_aux_ctl_reg(dev_priv, port); > -- > 2.7.4 > > ___
Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add debugfs for HuC loading status check
Reviewed-by: Jeff McGee On Mon, Oct 03, 2016 at 11:42:58AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > Add debugfs entry for HuC loading status check. > > v2: rebase on-top of drm-intel-nightly. > v3: rebased again. > v7: rebased. > v8: rebased. > > Tested-by: Xiang Haihao > Signed-off-by: Anusha Srivatsa > Signed-off-by: Alex Dai > Signed-off-by: Peter Antoine > Reviewed-by: Dave Gordon > --- > drivers/gpu/drm/i915/i915_debugfs.c | 31 +++ > 1 file changed, 31 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 44258a8..7bd0e23 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -2413,6 +2413,36 @@ static int i915_llc(struct seq_file *m, void *data) > return 0; > } > > +static int i915_huc_load_status_info(struct seq_file *m, void *data) > +{ > + struct drm_i915_private *dev_priv = node_to_i915(m->private); > + struct intel_uc_fw *huc_fw = &dev_priv->huc.huc_fw; > + > + if (!HAS_HUC_UCODE(dev_priv)) > + return 0; > + > + seq_puts(m, "HuC firmware status:\n"); > + seq_printf(m, "\tpath: %s\n", huc_fw->uc_fw_path); > + seq_printf(m, "\tfetch: %s\n", > + intel_uc_fw_status_repr(huc_fw->fetch_status)); > + seq_printf(m, "\tload: %s\n", > + intel_uc_fw_status_repr(huc_fw->load_status)); > + seq_printf(m, "\tversion wanted: %d.%d\n", > + huc_fw->major_ver_wanted, huc_fw->minor_ver_wanted); > + seq_printf(m, "\tversion found: %d.%d\n", > + huc_fw->major_ver_found, huc_fw->minor_ver_found); > + seq_printf(m, "\theader: offset is %d; size = %d\n", > + huc_fw->header_offset, huc_fw->header_size); > + seq_printf(m, "\tuCode: offset is %d; size = %d\n", > + huc_fw->ucode_offset, huc_fw->ucode_size); > + seq_printf(m, "\tRSA: offset is %d; size = %d\n", > + huc_fw->rsa_offset, huc_fw->rsa_size); > + > + seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2)); > + > + return 0; > +} > + > static int i915_guc_load_status_info(struct seq_file *m, void *data) > { > struct drm_i915_private *dev_priv = node_to_i915(m->private); > @@ -4427,6 +4457,7 @@ static const struct drm_info_list i915_debugfs_list[] = > { > {"i915_guc_info", i915_guc_info, 0}, > {"i915_guc_load_status", i915_guc_load_status_info, 0}, > {"i915_guc_log_dump", i915_guc_log_dump, 0}, > + {"i915_huc_load_status", i915_huc_load_status_info, 0}, > {"i915_frequency_info", i915_frequency_info, 0}, > {"i915_hangcheck_info", i915_hangcheck_info, 0}, > {"i915_drpc_info", i915_drpc_info, 0}, > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support
On Mon, Oct 03, 2016 at 11:42:57AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > The HuC loading process is similar to GuC. The intel_uc_fw_fetch() > is used for both cases. > > HuC loading needs to be before GuC loading. The WOPCM setting must > be done early before loading any of them. > > v2: rebased on-top of drm-intel-nightly. > removed if(HAS_GUC()) before the guc call. (D.Gordon) > update huc_version number of format. > v3: rebased to drm-intel-nightly, changed the file name format to > match the one in the huc package. > Changed dev->dev_private to to_i915() > v4: moved function back to where it was. > change wait_for_atomic to wait_for. > v5: rebased + comment changes. > v7: rebased. > v8: rebased. > > Tested-by: Xiang Haihao > Signed-off-by: Anusha Srivatsa > Signed-off-by: Alex Dai > Signed-off-by: Peter Antoine > Reviewed-by: Dave Gordon > --- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/i915_drv.c | 3 + > drivers/gpu/drm/i915/i915_drv.h | 3 + > drivers/gpu/drm/i915/i915_guc_reg.h | 3 + > drivers/gpu/drm/i915/intel_guc.h| 1 + > drivers/gpu/drm/i915/intel_guc_loader.c | 6 +- > drivers/gpu/drm/i915/intel_huc.h| 44 ++ > drivers/gpu/drm/i915/intel_huc_loader.c | 268 > > 8 files changed, 327 insertions(+), 2 deletions(-) > create mode 100644 drivers/gpu/drm/i915/intel_huc.h > create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index e6fe004..6e99c51 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -53,6 +53,7 @@ i915-y += i915_cmd_parser.o \ > > # general-purpose microcontroller (GuC) support > i915-y += intel_guc_loader.o \ > + intel_huc_loader.o \ > i915_guc_submission.o > > # autogenerated null render state > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 31b2b63..7af7bd6 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -613,6 +613,7 @@ static int i915_load_modeset_init(struct drm_device *dev) >* working irqs for e.g. gmbus and dp aux transfers. */ > intel_modeset_init(dev); > > + intel_huc_init(dev); > intel_guc_init(dev); > > ret = i915_gem_init(dev); > @@ -638,6 +639,7 @@ static int i915_load_modeset_init(struct drm_device *dev) > cleanup_gem: > i915_gem_fini(dev); > cleanup_irq: > + intel_huc_fini(dev); > intel_guc_fini(dev); > drm_irq_uninstall(dev); > intel_teardown_gmbus(dev); > @@ -1315,6 +1317,7 @@ void i915_driver_unload(struct drm_device *dev) > /* Flush any outstanding unpin_work. */ > drain_workqueue(dev_priv->wq); > > + intel_huc_fini(dev); > intel_guc_fini(dev); > i915_gem_fini(dev); > intel_fbc_cleanup_cfb(dev_priv); > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index e0cb71c..625aa92 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -55,6 +55,7 @@ > #include "intel_bios.h" > #include "intel_dpll_mgr.h" > #include "intel_guc.h" > +#include "intel_huc.h" > #include "intel_lrc.h" > #include "intel_ringbuffer.h" > > @@ -1766,6 +1767,7 @@ struct drm_i915_private { > > struct intel_gvt gvt; > > + struct intel_huc huc; > struct intel_guc guc; > > struct intel_csr csr; > @@ -2822,6 +2824,7 @@ struct drm_i915_cmd_table { > #define HAS_GUC(dev) (INTEL_INFO(dev)->has_guc) > #define HAS_GUC_UCODE(dev) (HAS_GUC(dev)) > #define HAS_GUC_SCHED(dev) (HAS_GUC(dev)) > +#define HAS_HUC_UCODE(dev) (HAS_GUC(dev)) > > #define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)->has_resource_streamer) > > diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h > b/drivers/gpu/drm/i915/i915_guc_reg.h > index a47e1e4..64e942a 100644 > --- a/drivers/gpu/drm/i915/i915_guc_reg.h > +++ b/drivers/gpu/drm/i915/i915_guc_reg.h > @@ -61,9 +61,12 @@ > #define DMA_ADDRESS_SPACE_GTT(8 << 16) > #define DMA_COPY_SIZE_MMIO(0xc310) > #define DMA_CTRL _MMIO(0xc314) > +#define HUC_UKERNEL (1<<9) > #define UOS_MOVE (1<<4) > #define START_DMA(1<<0) > #define DMA_GUC_WOPCM_OFFSET _MMIO(0xc340) > +#define HUC_LOADING_AGENT_VCR(0<<1) > +#define HUC_LOADING_AGENT_GUC(1<<1) > #define GUC_WOPCM_OFFSET_VALUE 0x8 /* 512KB */ > #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4) > > diff --git a/drivers/gpu/drm/i915/intel_guc.h > b/drivers/gpu/drm/i915/intel_guc.h > index 812e4ca..af76ffe 100644 > --- a/drivers/gpu/drm/i915/intel_guc.h > +++ b/drivers/gpu/drm/i915/intel_guc.h > @@ -160,6 +160,7 @@ extern const char *intel_uc_f
Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs
On 13 October 2016 at 15:13, Daniel Vetter wrote: > I was a bit over-eager in my cleanup in > > commit 95c081c17f284de50eaca60d4d55643a64d39019 > Author: Daniel Vetter > Date: Tue Jun 21 10:54:12 2016 +0200 > > drm: Move master pointer from drm_minor to drm_device > > Noticed by Chris Wilson. > > Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device") > Cc: Chris Wilson > Cc: Chris Wilson > Cc: Daniel Vetter > Cc: Emil Velikov > Cc: Julia Lawall > Signed-off-by: Daniel Vetter Oops ;-) Worth updating/dropping the "Called when ..." comment above the function ? How about the rest of the file ? Either way, Reviewed-by: Emil Velikov -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm: Add and handle new aspect ratios in DRM layer
On Tue, Aug 09, 2016 at 08:25:50PM +0530, Shashank Sharma wrote: > HDMI 2.0/CEA-861-F introduces two new aspect ratios: > - 64:27 > - 256:135 > > This patch: > - Adds new DRM flags for to represent these new aspect ratios. > - Adds new cases to handle these aspect ratios while converting > from user->kernel mode or vise versa. > > V2: Rebase > > Signed-off-by: Shashank Sharma > Reviewed-by: Sean Paul > Cc: Daniel Vetter > Cc: Emil Velikov > --- > drivers/gpu/drm/drm_modes.c | 12 > include/uapi/drm/drm_mode.h | 6 ++ > 2 files changed, 18 insertions(+) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index 9d8f00d..ed1b07b 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -1481,6 +1481,12 @@ void drm_mode_convert_to_umode(struct > drm_mode_modeinfo *out, > case HDMI_PICTURE_ASPECT_16_9: > out->flags |= DRM_MODE_FLAG_PIC_AR_16_9; > break; > + case HDMI_PICTURE_ASPECT_64_27: > + out->flags |= DRM_MODE_FLAG_PIC_AR_64_27; > + break; > + case DRM_MODE_PICTURE_ASPECT_256_135: > + out->flags |= DRM_MODE_FLAG_PIC_AR_256_135; > + break; > case HDMI_PICTURE_ASPECT_RESERVED: > default: > out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; > @@ -1542,6 +1548,12 @@ int drm_mode_convert_umode(struct drm_display_mode > *out, > case DRM_MODE_FLAG_PIC_AR_16_9: > out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; > break; > + case DRM_MODE_FLAG_PIC_AR_64_27: > + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27; > + break; > + case DRM_MODE_FLAG_PIC_AR_256_135: > + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135; > + break; > default: > out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > break; > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index 77c869d6..4d3429b 100644 > --- a/include/uapi/drm/drm_mode.h > +++ b/include/uapi/drm/drm_mode.h > @@ -81,6 +81,8 @@ extern "C" { > #define DRM_MODE_PICTURE_ASPECT_NONE 0 > #define DRM_MODE_PICTURE_ASPECT_4_3 1 > #define DRM_MODE_PICTURE_ASPECT_16_9 2 > +#define DRM_MODE_PICTURE_ASPECT_64_273 > +#define DRM_MODE_PICTURE_ASPECT_256_135 4 Minor nit here, but in my tree the '4' above doesn't line up with the three previous definitions. I downloaded the series as a mbox from patchwork. Jim > > /* Aspect ratio flag bitmask (4 bits 22:19) */ > #define DRM_MODE_FLAG_PIC_AR_MASK(0x0F<<19) > @@ -90,6 +92,10 @@ extern "C" { > (DRM_MODE_PICTURE_ASPECT_4_3<<19) > #define DRM_MODE_FLAG_PIC_AR_16_9 \ > (DRM_MODE_PICTURE_ASPECT_16_9<<19) > +#define DRM_MODE_FLAG_PIC_AR_64_27 \ > + (DRM_MODE_PICTURE_ASPECT_64_27<<19) > +#define DRM_MODE_FLAG_PIC_AR_256_135 \ > + (DRM_MODE_PICTURE_ASPECT_256_135<<19) > > /* DPMS flags */ > /* bit compatible with the xorg definitions. */ > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm: Add aspect ratio parsing in DRM layer
On Tue, Aug 09, 2016 at 08:25:48PM +0530, Shashank Sharma wrote: > Current DRM layer functions don't parse aspect ratio information > while converting a user mode->kernel mode or vice versa. This > causes modeset to pick mode with wrong aspect ratio, eventually > causing failures in HDMI compliance test cases, due to wrong VIC. > > This patch adds aspect ratio information in DRM's mode conversion > and mode comparision functions, to make sure kernel picks mode > with right aspect ratio (as per the VIC). > > V2: Addressed review comments from Sean: > - Fix spellings/typo > - No need to handle aspect ratio none > - Add a break, for default case too > > Signed-off-by: Shashank Sharma > Signed-off-by: Lin, Jia > Signed-off-by: Akashdeep Sharma Reviewed-by: Jim Bride > > Cc: Daniel Vetter > Cc: Emil Velikov > --- > drivers/gpu/drm/drm_modes.c | 31 +++ > 1 file changed, 31 insertions(+) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index fc5040a..9d8f00d 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -969,6 +969,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct > drm_display_mode *mode1, > mode1->vsync_end == mode2->vsync_end && > mode1->vtotal == mode2->vtotal && > mode1->vscan == mode2->vscan && > + mode1->picture_aspect_ratio == mode2->picture_aspect_ratio && > (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) == >(mode2->flags & ~DRM_MODE_FLAG_3D_MASK)) > return true; > @@ -1471,6 +1472,21 @@ void drm_mode_convert_to_umode(struct > drm_mode_modeinfo *out, > out->vrefresh = in->vrefresh; > out->flags = in->flags; > out->type = in->type; > + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK; > + > + switch (in->picture_aspect_ratio) { > + case HDMI_PICTURE_ASPECT_4_3: > + out->flags |= DRM_MODE_FLAG_PIC_AR_4_3; > + break; > + case HDMI_PICTURE_ASPECT_16_9: > + out->flags |= DRM_MODE_FLAG_PIC_AR_16_9; > + break; > + case HDMI_PICTURE_ASPECT_RESERVED: > + default: > + out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; > + break; > + } > + > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN); > out->name[DRM_DISPLAY_MODE_LEN-1] = 0; > } > @@ -1516,6 +1532,21 @@ int drm_mode_convert_umode(struct drm_display_mode > *out, > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN); > out->name[DRM_DISPLAY_MODE_LEN-1] = 0; > > + /* Clearing picture aspect ratio bits from out flags */ > + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK; > + > + switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) { > + case DRM_MODE_FLAG_PIC_AR_4_3: > + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3; > + break; > + case DRM_MODE_FLAG_PIC_AR_16_9: > + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; > + break; > + default: > + out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > + break; > + } > + > out->status = drm_mode_validate_basic(out); > if (out->status != MODE_OK) > goto out; > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/4] drm: add picture aspect ratio flags
On Tue, Aug 09, 2016 at 08:25:47PM +0530, Shashank Sharma wrote: > This patch adds drm flag bits for aspect ratio information > > Currently drm flag bits don't have field for mode's picture > aspect ratio. This field will help the driver to pick mode with > right aspect ratio, and help in setting right VIC field in avi > infoframes. > > Signed-off-by: Shashank Sharma The changes make sense according to the relevant specs, and although I don't have the HW to test them the code looks right. Reviewed-by: Jim Bride > > V2: Addressed review comments from Sean > - Changed PAR-> PIC_AR > > Cc: Daniel Vetter > Cc: Emil Velikov > --- > include/uapi/drm/drm_mode.h | 18 +- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index 49a7265..77c869d6 100644 > --- a/include/uapi/drm/drm_mode.h > +++ b/include/uapi/drm/drm_mode.h > @@ -77,6 +77,19 @@ extern "C" { > #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14) > #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (8<<14) > > +/* Picture aspect ratio options */ > +#define DRM_MODE_PICTURE_ASPECT_NONE 0 > +#define DRM_MODE_PICTURE_ASPECT_4_3 1 > +#define DRM_MODE_PICTURE_ASPECT_16_9 2 > + > +/* Aspect ratio flag bitmask (4 bits 22:19) */ > +#define DRM_MODE_FLAG_PIC_AR_MASK(0x0F<<19) > +#define DRM_MODE_FLAG_PIC_AR_NONE \ > + (DRM_MODE_PICTURE_ASPECT_NONE<<19) > +#define DRM_MODE_FLAG_PIC_AR_4_3 \ > + (DRM_MODE_PICTURE_ASPECT_4_3<<19) > +#define DRM_MODE_FLAG_PIC_AR_16_9 \ > + (DRM_MODE_PICTURE_ASPECT_16_9<<19) > > /* DPMS flags */ > /* bit compatible with the xorg definitions. */ > @@ -92,11 +105,6 @@ extern "C" { > #define DRM_MODE_SCALE_CENTER2 /* Centered, no scaling */ > #define DRM_MODE_SCALE_ASPECT3 /* Full screen, preserve > aspect */ > > -/* Picture aspect ratio options */ > -#define DRM_MODE_PICTURE_ASPECT_NONE 0 > -#define DRM_MODE_PICTURE_ASPECT_4_3 1 > -#define DRM_MODE_PICTURE_ASPECT_16_9 2 > - > /* Dithering mode options */ > #define DRM_MODE_DITHERING_OFF 0 > #define DRM_MODE_DITHERING_ON1 > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4)
== Series Details == Series: drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4) URL : https://patchwork.freedesktop.org/series/13435/ State : warning == Summary == Series 13435v4 drm/i915: Allocate intel_engine_cs structure only for the enabled engines https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/4/mbox/ Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b: pass -> DMESG-WARN (fi-ilk-650) Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (fi-ilk-650) Test vgem_basic: Subgroup unload: skip -> PASS (fi-skl-6770hq) fi-bdw-5557u total:246 pass:231 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:246 pass:204 dwarn:0 dfail:0 fail:0 skip:42 fi-bxt-t5700 total:246 pass:216 dwarn:0 dfail:0 fail:0 skip:30 fi-byt-j1900 total:246 pass:212 dwarn:2 dfail:0 fail:1 skip:31 fi-byt-n2820 total:246 pass:210 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770 total:246 pass:223 dwarn:0 dfail:0 fail:0 skip:23 fi-hsw-4770r total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-ilk-650 total:246 pass:183 dwarn:1 dfail:0 fail:2 skip:60 fi-ivb-3520m total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-kbl-7200u total:246 pass:222 dwarn:0 dfail:0 fail:0 skip:24 fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:246 pass:223 dwarn:0 dfail:0 fail:0 skip:23 fi-skl-6700k total:246 pass:221 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:246 pass:229 dwarn:1 dfail:0 fail:1 skip:15 fi-snb-2520m total:246 pass:210 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:246 pass:209 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2708/ dbcf6fbb541e70fac7db669631958eab2e4e0d9c drm-intel-nightly: 2016y-10m-13d-15h-31m-19s UTC integration manifest 391ff6c drm/i915: Allocate intel_engine_cs structure only for the enabled engines ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatched INIT power domain disabling during suspend
On to, 2016-10-13 at 15:21 +0300, Jani Nikula wrote: > On Thu, 13 Oct 2016, Imre Deak wrote: > > Currently the display INIT power domain disabling/enabling happens in a > > mismatched way in the suspend/resume_early hooks respectively. This can > > leave display power wells incorrectly disabled in the resume hook if the > > suspend sequence is aborted for some reason resulting in the > > suspend/resume hooks getting called but the suspend_late/resume_early > > hooks being skipped. In particular this change fixes "Unclaimed read > > from register 0x1e1204" on BYT/BSW triggered from i915_drm_resume()-> > > intel_pps_unlock_regs_wa() when suspending with /sys/power/pm_test set > > to devices. > > > > Cc: Ville Syrjälä > > Cc: David Weinehall > > Signed-off-by: Imre Deak > > Fixes: ? Fixes: 85e90679335f ("drm/i915: disable power wells on suspend") > Cc: sta...@vger.kernel.org ? It matters only for an error path which is rare (another device needs to fail suspending between its suspend and suspend_late steps) and pm_test. So I'd say this isn't for fixes or stable. --Imre > > > --- > > drivers/gpu/drm/i915/i915_drv.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c > > index e9b3bfc..5adabac 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -1430,8 +1430,6 @@ static int i915_drm_suspend(struct drm_device > > *dev) > > > > dev_priv->suspend_count++; > > > > - intel_display_set_init_power(dev_priv, false); > > - > > intel_csr_ucode_suspend(dev_priv); > > > > out: > > @@ -1449,6 +1447,8 @@ static int i915_drm_suspend_late(struct > > drm_device *dev, bool hibernation) > > > > disable_rpm_wakeref_asserts(dev_priv); > > > > + intel_display_set_init_power(dev_priv, false); > > + > > fw_csr = !IS_BROXTON(dev_priv) && > > suspend_to_idle(dev_priv) && dev_priv- > > >csr.dmc_payload; > > /* > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11] drm/i915: Allocate intel_engine_cs structure only for the enabled engines
From: Akash Goel With the possibility of addition of many more number of rings in future, the drm_i915_private structure could bloat as an array, of type intel_engine_cs, is embedded inside it. struct intel_engine_cs engine[I915_NUM_ENGINES]; Though this is still fine as generally there is only a single instance of drm_i915_private structure used, but not all of the possible rings would be enabled or active on most of the platforms. Some memory can be saved by allocating intel_engine_cs structure only for the enabled/active engines. Currently the engine/ring ID is kept static and dev_priv->engine[] is simply indexed using the enums defined in intel_engine_id. To save memory and continue using the static engine/ring IDs, 'engine' is defined as an array of pointers. struct intel_engine_cs *engine[I915_NUM_ENGINES]; dev_priv->engine[engine_ID] will be NULL for disabled engine instances. There is a text size reduction of 928 bytes, from 1028200 to 1027272, for i915.o file (but for i915.ko file text size remain same as 1193131 bytes). v2: - Remove the engine iterator field added in drm_i915_private structure, instead pass a local iterator variable to the for_each_engine** macros. (Chris) - Do away with intel_engine_initialized() and instead directly use the NULL pointer check on engine pointer. (Chris) v3: - Remove for_each_engine_id() macro, as the updated macro for_each_engine() can be used in place of it. (Chris) - Protect the access to Render engine Fault register with a NULL check, as engine specific init is done later in Driver load sequence. v4: - Use !!dev_priv->engine[VCS] style for the engine check in getparam. (Chris) - Kill the superfluous init_engine_lists(). v5: - Cleanup the intel_engines_init() & intel_engines_setup(), with respect to allocation of intel_engine_cs structure. (Chris) v6: - Rebase. v7: - Optimize the for_each_engine_masked() macro. (Chris) - Change the type of 'iter' local variable to enum intel_engine_id. (Chris) - Rebase. v8: Rebase. v9: Rebase. v10: - For index calculation use engine ID instead of pointer based arithmetic in intel_engine_sync_index() as engine pointers are not contiguous now (Chris) - For appropriateness, rename local enum variable 'iter' to 'id'. (Joonas) - Use for_each_engine macro for cleanup in intel_engines_init() and remove check for NULL engine pointer in cleanup() routines. (Joonas) v11: Rebase. Cc: Chris Wilson Signed-off-by: Akash Goel Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_cmd_parser.c | 3 +- drivers/gpu/drm/i915/i915_debugfs.c| 59 ++ drivers/gpu/drm/i915/i915_drv.c| 11 +++--- drivers/gpu/drm/i915/i915_drv.h| 22 --- drivers/gpu/drm/i915/i915_gem.c| 29 +++ drivers/gpu/drm/i915/i915_gem_context.c| 15 +--- drivers/gpu/drm/i915/i915_gem_evict.c | 3 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +-- drivers/gpu/drm/i915/i915_gem_gtt.c| 14 +-- drivers/gpu/drm/i915/i915_gem_request.c| 5 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 28 +++--- drivers/gpu/drm/i915/i915_guc_submission.c | 12 +++--- drivers/gpu/drm/i915/i915_irq.c| 46 --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 6 ++- drivers/gpu/drm/i915/intel_display.c | 8 ++-- drivers/gpu/drm/i915/intel_engine_cs.c | 26 + drivers/gpu/drm/i915/intel_guc_loader.c| 6 ++- drivers/gpu/drm/i915/intel_lrc.c | 11 +++--- drivers/gpu/drm/i915/intel_overlay.c | 2 +- drivers/gpu/drm/i915/intel_pm.c| 17 ++--- drivers/gpu/drm/i915/intel_ringbuffer.c| 15 drivers/gpu/drm/i915/intel_ringbuffer.h| 8 +--- 22 files changed, 194 insertions(+), 158 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c index 70980f8..f191d7b 100644 --- a/drivers/gpu/drm/i915/i915_cmd_parser.c +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c @@ -1308,10 +1308,11 @@ int intel_engine_cmd_parser(struct intel_engine_cs *engine, int i915_cmd_parser_get_version(struct drm_i915_private *dev_priv) { struct intel_engine_cs *engine; + enum intel_engine_id id; bool active = false; /* If the command parser is not enabled, report 0 - unsupported */ - for_each_engine(engine, dev_priv) { + for_each_engine(engine, dev_priv, id) { if (intel_engine_needs_cmd_parser(engine)) { active = true; break; diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 2e312e0..b20c1cc 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -150,7 +150,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj) obj->base.size / 1024, obj->base.read_domains,
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Print device information again in debugfs
== Series Details == Series: drm: Print device information again in debugfs URL : https://patchwork.freedesktop.org/series/13731/ State : warning == Summary == Series 13731v1 drm: Print device information again in debugfs https://patchwork.freedesktop.org/api/1.0/series/13731/revisions/1/mbox/ Test drv_module_reload_basic: skip -> PASS (fi-skl-6770hq) Test kms_pipe_crc_basic: Subgroup bad-source: pass -> DMESG-WARN (fi-ilk-650) Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (fi-ilk-650) Test vgem_basic: Subgroup unload: skip -> PASS (fi-skl-6770hq) skip -> PASS (fi-hsw-4770) pass -> SKIP (fi-bdw-5557u) fi-bdw-5557u total:246 pass:230 dwarn:0 dfail:0 fail:0 skip:16 fi-bsw-n3050 total:246 pass:204 dwarn:0 dfail:0 fail:0 skip:42 fi-bxt-t5700 total:246 pass:216 dwarn:0 dfail:0 fail:0 skip:30 fi-byt-j1900 total:246 pass:213 dwarn:1 dfail:0 fail:1 skip:31 fi-byt-n2820 total:246 pass:210 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-hsw-4770r total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-ilk-650 total:246 pass:183 dwarn:1 dfail:0 fail:2 skip:60 fi-ivb-3520m total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-kbl-7200u total:246 pass:222 dwarn:0 dfail:0 fail:0 skip:24 fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:246 pass:223 dwarn:0 dfail:0 fail:0 skip:23 fi-skl-6700k total:246 pass:221 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:246 pass:230 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:246 pass:210 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:246 pass:209 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2707/ dbcf6fbb541e70fac7db669631958eab2e4e0d9c drm-intel-nightly: 2016y-10m-13d-15h-31m-19s UTC integration manifest 3d9d112 drm: Print device information again in debugfs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)
On 13/10/2016 17:10, Goel, Akash wrote: On 10/10/2016 6:03 PM, Patchwork wrote: == Series Details == Series: drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3) URL : https://patchwork.freedesktop.org/series/13435/ State : warning == Summary == Series 13435v3 drm/i915: Allocate intel_engine_cs structure only for the enabled engines https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/3/mbox/ Test vgem_basic: Subgroup unload: pass -> SKIP (fi-skl-6260u) pass -> SKIP (fi-skl-6700hq) skip -> PASS (fi-skl-6700k) Checked with Chris about the above failure. He said that the above unload failure for vgem module can't be attributed to the patch, most likely a CI framework issue. I tried to merge it but due recent changes to error capture it doesn't apply any longer. Can you please rebase and resend? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)
On 10/10/2016 6:03 PM, Patchwork wrote: == Series Details == Series: drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3) URL : https://patchwork.freedesktop.org/series/13435/ State : warning == Summary == Series 13435v3 drm/i915: Allocate intel_engine_cs structure only for the enabled engines https://patchwork.freedesktop.org/api/1.0/series/13435/revisions/3/mbox/ Test vgem_basic: Subgroup unload: pass -> SKIP (fi-skl-6260u) pass -> SKIP (fi-skl-6700hq) skip -> PASS (fi-skl-6700k) Checked with Chris about the above failure. He said that the above unload failure for vgem module can't be attributed to the patch, most likely a CI framework issue. Best regards Akash fi-bdw-5557u total:248 pass:231 dwarn:0 dfail:0 fail:0 skip:17 fi-bsw-n3050 total:248 pass:204 dwarn:0 dfail:0 fail:0 skip:44 fi-bxt-t5700 total:248 pass:217 dwarn:0 dfail:0 fail:0 skip:31 fi-byt-j1900 total:248 pass:214 dwarn:1 dfail:0 fail:1 skip:32 fi-byt-n2820 total:248 pass:210 dwarn:0 dfail:0 fail:1 skip:37 fi-hsw-4770 total:248 pass:224 dwarn:0 dfail:0 fail:0 skip:24 fi-hsw-4770r total:248 pass:224 dwarn:0 dfail:0 fail:0 skip:24 fi-ilk-650 total:248 pass:185 dwarn:0 dfail:0 fail:2 skip:61 fi-ivb-3520m total:248 pass:221 dwarn:0 dfail:0 fail:0 skip:27 fi-ivb-3770 total:248 pass:207 dwarn:0 dfail:0 fail:0 skip:41 fi-kbl-7200u total:248 pass:222 dwarn:0 dfail:0 fail:0 skip:26 fi-skl-6260u total:248 pass:232 dwarn:0 dfail:0 fail:0 skip:16 fi-skl-6700hqtotal:248 pass:223 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6700k total:248 pass:222 dwarn:1 dfail:0 fail:0 skip:25 fi-skl-6770hqtotal:248 pass:231 dwarn:1 dfail:0 fail:1 skip:15 fi-snb-2520m total:248 pass:211 dwarn:0 dfail:0 fail:0 skip:37 fi-snb-2600 total:248 pass:209 dwarn:0 dfail:0 fail:0 skip:39 Results at /archive/results/CI_IGT_test/Patchwork_2652/ f35ed31aea66b3230c366fcba5f3456ae2cb956e drm-intel-nightly: 2016y-10m-10d-11h-28m-51s UTC integration manifest 401facf drm/i915: Allocate intel_engine_cs structure only for the enabled engines ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Save megabytes of wasted sg entries
On 13/10/2016 16:33, Daniel Vetter wrote: On Thu, Oct 13, 2016 at 11:24:46AM +, Saarinen, Jani wrote: == Series Details == Series: Save megabytes of wasted sg entries URL : https://patchwork.freedesktop.org/series/13706/ State : failure == Summary == Series 13706v1 Save megabytes of wasted sg entries https://patchwork.freedesktop.org/api/1.0/series/13706/revisions/1/mbox/ Test gem_cs_tlb: Subgroup basic-default: pass -> INCOMPLETE (fi-bsw-n3050) pass -> INCOMPLETE (fi-byt-n2820) pass -> INCOMPLETE (fi-hsw-4770r) pass -> INCOMPLETE (fi-skl-6260u) pass -> INCOMPLETE (fi-ivb-3770) pass -> INCOMPLETE (fi-kbl-7200u) pass -> INCOMPLETE (fi-skl-6700hq) pass -> INCOMPLETE (fi-bdw-5557u) pass -> INCOMPLETE (fi-ilk-650) pass -> INCOMPLETE (fi-hsw-4770) pass -> INCOMPLETE (fi-byt-j1900) pass -> INCOMPLETE (fi-snb-2520m) pass -> INCOMPLETE (fi-bxt-t5700) pass -> INCOMPLETE (fi-ivb-3520m) running: igt/gem_cs_tlb/basic-default [014/246] pass: 14 - Build timed out (after 18 minutes). Marking the build as aborted. [ 96.771613] gem_cs_tlb: starting subtest basic-default [ 96.773567] general protection fault: [#1] PREEMPT SMP [ 96.773599] Modules linked in: snd_hda_intel i915 cdc_ncm usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915] [ 96.773775] CPU: 1 PID: 8922 Comm: gem_cs_tlb Tainted: G U 4.8.0-CI-Patchwork_2698+ #1 [ 96.773806] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012 [ 96.773833] task: 8801311ace40 task.stack: 880137654000 [ 96.773854] RIP: 0010:[] [] kfree+0x72/0x2e0 ... Please paste the full backtrace, it might throw a hint on what's going on. It was just a RFC, I even labelled it as broken. Just wanted to send it out for feedback on the general approach since I was unsure when I will get back to debugging it. It is most certainly a bug in my sg_table_trim implementation. :) [ 67.205081] general protection fault: [#1] PREEMPT SMP [ 67.205115] Modules linked in: snd_hda_intel i915 intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei lpc_ich e1000e ptp pps_core [last unloaded: i915] [ 67.205284] CPU: 2 PID: 7725 Comm: gem_cs_tlb Tainted: G U 4.8.0-CI-Patchwork_2698+ #1 [ 67.205315] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.05 06/09/2010 [ 67.205347] task: 88020a68a600 task.stack: 880207708000 [ 67.205370] RIP: 0010:[] [] kfree+0x72/0x2e0 [ 67.205404] RSP: 0018:88020770bc30 EFLAGS: 00010203 [ 67.205425] RAX: ea00 RBX: 6b6b6b6b6b6b6b68 RCX: 0002 [ 67.205450] RDX: 8002 RSI: 81c595f0 RDI: 88020a68ae28 [ 67.205476] RBP: 88020770bc58 R08: ea0008239c20 R09: 0001 [ 67.205501] R10: R11: R12: 87654321 [ 67.205527] R13: 814392a6 R14: 01ad998dadadad80 R15: [ 67.205553] FS: 7ff7454d4740() GS:88021bc8() knlGS: [ 67.205581] CS: 0010 DS: ES: CR0: 80050033 [ 67.205602] CR2: 019273f8 CR3: 0002102a2000 CR4: 06e0 [ 67.205627] Stack: [ 67.205638] 88020cc062c8 87654321 012f 0036 [ 67.205678] 88020770bc90 814392a6 88020cc062c8 [ 67.205717] 880208d8a420 00021292 880209a35dc0 [ 67.205757] Call Trace: [ 67.205772] [] sg_trim_table+0x96/0xe0 [ 67.205808] [] i915_sg_complete+0x38/0x40 [i915] [ 67.205844] [] i915_gem_object_get_pages_gtt+0xe5/0x340 [i915] [ 67.205884] [] i915_gem_object_get_pages+0x3c/0xb0 [i915] [ 67.205922] [] i915_gem_object_set_to_gtt_domain+0x3b/0x290 [i915] [ 67.205963] [] i915_gem_set_domain_ioctl+0x108/0x130 [i915] [ 67.205991] [] drm_ioctl+0x1f6/0x480 [ 67.206024] [] ? i915_gem_obj_prepare_shmem_write+0x170/0x170 [i915] [ 67.206054] [] ? debug_lockdep_rcu_enabled+0x1d/0x20 [ 67.206080] [] do_vfs_ioctl+0x8e/0x690 [ 67.206102] [] ? trace_hardirqs_on_caller+0x122/0x1b0 [ 67.206126] [] SyS_ioctl+0x3c/0x70 [ 67.206150] [] entry_SYSCALL_64_fastpath+0x1c/0xac [ 67.206173] Code: 00 00 00 80 ff 77 00 00 49 01 de 48 0f 42 05 f6 db c3 00 49 0
Re: [Intel-gfx] [PATCH v4 8/8] drm/i915/bxt: Enable IPC support
On Thu, Oct 13, 2016 at 06:31:37PM +0530, Mahesh Kumar wrote: > Hi, > > > On Thursday 13 October 2016 04:49 PM, Maarten Lankhorst wrote: > > Op 13-10-16 om 12:58 schreef Kumar, Mahesh: > > > From: Mahesh Kumar > > > > > > This patch adds IPC support for platforms. This patch enables IPC > > > only for BXT/KBL platform as for SKL recommendation is to keep is > > > disabled. > > > IPC (Isochronous Priority Control) is the hardware feature, which > > > dynamically controles the memory read priority of Display. > > > > > > When IPC is enabled, plane read requests are sent at high priority until > > > filling above the transition watermark, then the requests are sent at > > > lower priority until dropping below the level 0 watermark. > > > The lower priority requests allow other memory clients to have better > > > memory access. When IPC is disabled, all plane read requests are sent at > > > high priority. > > > > > > Changes since V1: > > > - Remove commandline parameter to disable ipc > > > - Address Paulo's comments > > > > > > Signed-off-by: Mahesh Kumar > > > --- > > > drivers/gpu/drm/i915/i915_drv.c | 2 ++ > > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > > drivers/gpu/drm/i915/intel_pm.c | 15 +++ > > > 4 files changed, 19 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > b/drivers/gpu/drm/i915/i915_drv.c > > > index b5f601c..58abbaa 100644 > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > @@ -1415,6 +1415,8 @@ int i915_driver_load(struct pci_dev *pdev, const > > > struct pci_device_id *ent) > > > intel_runtime_pm_enable(dev_priv); > > > + intel_enable_ipc(dev_priv); > > > + > > > /* Everything is in place, we can now relax! */ > > > DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n", > > >driver.name, driver.major, driver.minor, > > > driver.patchlevel, > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > > b/drivers/gpu/drm/i915/i915_reg.h > > > index a9c467c..c9ebf23 100644 > > > --- a/drivers/gpu/drm/i915/i915_reg.h > > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > > @@ -6144,6 +6144,7 @@ enum { > > > #define DISP_FBC_WM_DIS(1<<15) > > > #define DISP_ARB_CTL2 _MMIO(0x45004) > > > #define DISP_DATA_PARTITION_5_6(1<<6) > > > +#define DISP_IPC_ENABLE (1<<3) > > > #define DBUF_CTL_MMIO(0x45008) > > > #define DBUF_POWER_REQUEST (1<<31) > > > #define DBUF_POWER_STATE (1<<30) > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > > b/drivers/gpu/drm/i915/intel_drv.h > > > index 2c1897b..45b0fa4 100644 > > > --- a/drivers/gpu/drm/i915/intel_drv.h > > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > > @@ -1766,6 +1766,7 @@ void skl_write_plane_wm(struct intel_crtc > > > *intel_crtc, > > > uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state > > > *pipe_config); > > > bool ilk_disable_lp_wm(struct drm_device *dev); > > > int sanitize_rc6_option(struct drm_i915_private *dev_priv, int > > > enable_rc6); > > > +void intel_enable_ipc(struct drm_i915_private *dev_priv); > > > static inline int intel_enable_rc6(void) > > > { > > > return i915.enable_rc6; > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > > b/drivers/gpu/drm/i915/intel_pm.c > > > index 4263212..543aa5d 100644 > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > @@ -4833,6 +4833,21 @@ void intel_update_watermarks(struct drm_crtc *crtc) > > > dev_priv->display.update_wm(crtc); > > > } > > > +void intel_enable_ipc(struct drm_i915_private *dev_priv) > > > +{ > > > + u32 val; > > > + > > > + /* enable IPC only for Broxton for now*/ > > > + if (!IS_BROXTON(dev_priv) || !IS_KABYLAKE(dev_priv)) > > > + return; > > > + > > This comment doesn't match the code. > > Is it ok to enable IPC right away? Not when the driver is writing the first > > watermarks? (distrust_bios_wm) > > And what about suspend/resume, should this flag be set again after resume? > > > > ~Maarten > hmm.. comment should have been Broxton/Kabylake. > Yes we can enable IPC at any time. In future BIOS itself may enable IPC. > (though I'm not sure about the behavior if WM programmed by BIOS are not > correct) > We don't reset (save/restore) this during suspend/resume, it's onetime > programming. The comment is also not really useful, since it's obvious from the code what's going on. If you add a comment, explain _why_ you're doing something. The _what_ should be clear from the code flow, if not you need to refactor. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 1/5] drm/i915: Use fence_write() from rpm resume
On Thu, Oct 13, 2016 at 05:28:13PM +0200, Daniel Vetter wrote: > On Thu, Oct 13, 2016 at 04:25:18PM +0100, Chris Wilson wrote: > > On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote: > > > On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote: > > > > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device > > > > *dev) > > > > * Commit delayed tiling changes if we have an object > > > > still > > > > * attached to the fence, otherwise just clear the > > > > fence. > > > > */ > > > > - if (vma && !i915_gem_object_is_tiled(vma->obj)) > > > > + if (vma && !i915_gem_object_is_tiled(vma->obj)) { > > > > + GEM_BUG_ON(!reg->dirty); > > > > + > > > > GEM_BUG_ON(!list_empty(&vma->obj->userfault_link)); > > > > + > > > > + list_move(®->link, &dev_priv->mm.fence_list); > > > > + vma->fence = NULL; > > > > vma = NULL; > > > > + } > > > > > > > > - fence_update(reg, vma); > > > > + fence_write(reg, vma); > > > > + reg->vma = vma; > > > > > > Same comments as with the userfault_list: Using rpm ordering to enforce > > > consistency causes mild panic attacks here with me ;-) > > > > > > Is the above (delayed tiling change commit) even possible here, at least > > > for rpm resume? Same for system s/r (both s3 and s4) since the pagetables > > > won't survive anyway. Can't we simply make this an impossibility? > > > > We also use this from reset to rewrite the old fences, and we know there > > we can hit the delayed fence write [4fc788f5ee3d]. It would also be > > possible to hit it on suspend as well. > > > > I've been thinking about whether we should be bothering to write the > > fence registers with the correct value or just cancel the fences. But we > > have to restore anything that is pinned, and we have to write something > > into the fences (just to be safe), and if we have to write something we > > may as well use the most recent information we have as that has a good > > chance of being used again. > > > > Long story short, I don't have a better idea for restoring or avoiding > > the restore of fences. > > What about a rpm_resume only version that just does a blind fence_write? > It is something, and we can update the book-keeping once we do get to one > of the real synchronization points again. > > With that we can leave the versions for reset and system s/r alone ... Or > is there trickery even with rpm going on? For rpm suspend, we only zap the user's mmap and not mark the fence as lost. I think that's the missing piece as to why this is not as simple as it could be for rpm-resume. On rpm-resume we only need to restore pinned fences, and fences should only be pinned for hw access, and so there should never be any if we were rpm-suspended. (Assuming that all pinned fences are active, which on the surface seems a reasonable assumption.) If that holds true, we do not need this at all for runtime pm (we still need it across full system suspend/reset) and just need to doctor the existing scary i915_gem_release_all_mmaps() (aka i915_gem_runtime_suspend()!) to both release the mmap and throw away the fence tracing. At least then we only have one dragon nest. -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 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC
On Mon, Oct 03, 2016 at 11:42:56AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > HuC firmware css header has almost exactly same definition as GuC > firmware except for the sw_version. Also, add a new member fw_type > into intel_uc_fw to indicate what kind of fw it is. So, the loader > will pull right sw_version from header. > > v2: rebased on-top of drm-intel-nightly > v3: rebased on-top of drm-intel-nightly (again). > v4: rebased + spaces. > v7: rebased. > v8: rebased. > > Tested-by: Xiang Haihao > Signed-off-by: Anusha Srivatsa > Signed-off-by: Alex Dai > Signed-off-by: Peter Antoine > Reviewed-by: Dave Gordon > --- > drivers/gpu/drm/i915/intel_guc.h| 4 > drivers/gpu/drm/i915/intel_guc_fwif.h | 16 ++--- > drivers/gpu/drm/i915/intel_guc_loader.c | 41 > ++--- > 3 files changed, 45 insertions(+), 16 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_guc.h > b/drivers/gpu/drm/i915/intel_guc.h > index b134a41..812e4ca 100644 > --- a/drivers/gpu/drm/i915/intel_guc.h > +++ b/drivers/gpu/drm/i915/intel_guc.h > @@ -98,6 +98,9 @@ enum intel_uc_fw_status { > UC_FIRMWARE_SUCCESS > }; > > +#define UC_FW_TYPE_GUC 0 > +#define UC_FW_TYPE_HUC 1 > + > /* > * This structure encapsulates all the data needed during the process > * of fetching, caching, and loading the firmware image into the GuC. > @@ -115,6 +118,7 @@ struct intel_uc_fw { > uint16_t major_ver_found; > uint16_t minor_ver_found; > > + uint32_t fw_type; > uint32_t header_size; > uint32_t header_offset; > uint32_t rsa_size; > diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h > b/drivers/gpu/drm/i915/intel_guc_fwif.h > index e40db2d..b38b6b4 100644 > --- a/drivers/gpu/drm/i915/intel_guc_fwif.h > +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h > @@ -154,7 +154,7 @@ > * The GuC firmware layout looks like this: > * > * +---+ > - * |guc_css_header | > + * | uc_css_header | > * | | > * | contains major/minor version | > * +---+ > @@ -181,9 +181,16 @@ > * 3. Length info of each component can be found in header, in dwords. > * 4. Modulus and exponent key are not required by driver. They may not > appear > *in fw. So driver will load a truncated firmware in this case. > + * > + * HuC firmware layout is same as GuC firmware. > + * > + * HuC firmware css header is different. However, the only difference is > where > + * the version information is saved. The uc_css_header is unified to support > + * both. Driver should get HuC version from uc_css_header.huc_sw_version, > while > + * uc_css_header.guc_sw_version for GuC. > */ > > -struct guc_css_header { > +struct uc_css_header { > uint32_t module_type; > /* header_size includes all non-uCode bits, including css_header, rsa >* key, modulus key and exponent data. */ > @@ -214,7 +221,10 @@ struct guc_css_header { > > char username[8]; > char buildnumber[12]; > - uint32_t device_id; > + union { > + uint32_t device_id; > + uint32_t huc_sw_version; > + }; > uint32_t guc_sw_version; > uint32_t prod_preprod_fw; > uint32_t reserved[12]; I propose renaming the device_id field in this union to 'guc_client_branch_version'. GuC uses this position to store a client version and branch version. I'm not sure where the 'device_id' term came from. We don't reference this currently but may need to in the future so might as well name it properly. At the very least we should probably make it guc_device_id, to help indicate that it applies to guc fw only. In that same vein, can we make guc_sw_version into a union as below to reinforce the difference to huc? union { uint32_t guc_sw_version; uint32_t huc_reserved; }; Jeff > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c > b/drivers/gpu/drm/i915/intel_guc_loader.c > index 493295d..0b863a1 100644 > --- a/drivers/gpu/drm/i915/intel_guc_loader.c > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c > @@ -586,7 +586,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct > intel_uc_fw *uc_fw) > struct pci_dev *pdev = dev->pdev; > struct drm_i915_gem_object *obj; > const struct firmware *fw; > - struct guc_css_header *css; > + struct uc_css_header *css; > size_t size; > int err; > > @@ -603,19 +603,19 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct > intel_uc_fw *uc_fw) > uc_fw->uc_fw_path, fw); > > /* Check the size of the blob before examining buffer contents */ > - if (fw->size < sizeof(struct guc_css_header)) { > + if (fw->size < sizeof(struct uc_css_header)) { > DRM_NOTE("Firmware header is missing\n"); > goto fail; >
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Save megabytes of wasted sg entries
On Thu, Oct 13, 2016 at 11:24:46AM +, Saarinen, Jani wrote: > > == Series Details == > > > > Series: Save megabytes of wasted sg entries > > URL : https://patchwork.freedesktop.org/series/13706/ > > State : failure > > > > == Summary == > > > > Series 13706v1 Save megabytes of wasted sg entries > > https://patchwork.freedesktop.org/api/1.0/series/13706/revisions/1/mbox/ > > > > Test gem_cs_tlb: > > Subgroup basic-default: > > pass -> INCOMPLETE (fi-bsw-n3050) > > pass -> INCOMPLETE (fi-byt-n2820) > > pass -> INCOMPLETE (fi-hsw-4770r) > > pass -> INCOMPLETE (fi-skl-6260u) > > pass -> INCOMPLETE (fi-ivb-3770) > > pass -> INCOMPLETE (fi-kbl-7200u) > > pass -> INCOMPLETE (fi-skl-6700hq) > > pass -> INCOMPLETE (fi-bdw-5557u) > > pass -> INCOMPLETE (fi-ilk-650) > > pass -> INCOMPLETE (fi-hsw-4770) > > pass -> INCOMPLETE (fi-byt-j1900) > > pass -> INCOMPLETE (fi-snb-2520m) > > pass -> INCOMPLETE (fi-bxt-t5700) > > pass -> INCOMPLETE (fi-ivb-3520m) > running: igt/gem_cs_tlb/basic-default > > [014/246] pass: 14 - > Build timed out (after 18 minutes). Marking the build as aborted. > > [ 96.771613] gem_cs_tlb: starting subtest basic-default > [ 96.773567] general protection fault: [#1] PREEMPT SMP > [ 96.773599] Modules linked in: snd_hda_intel i915 cdc_ncm usbnet mii > x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel lpc_ich snd_hda_codec_hdmi snd_hda_codec_realtek > snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei > sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915] > [ 96.773775] CPU: 1 PID: 8922 Comm: gem_cs_tlb Tainted: G U > 4.8.0-CI-Patchwork_2698+ #1 > [ 96.773806] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) > 07/02/2012 > [ 96.773833] task: 8801311ace40 task.stack: 880137654000 > [ 96.773854] RIP: 0010:[] [] > kfree+0x72/0x2e0 > ... Please paste the full backtrace, it might throw a hint on what's going on. -Daniel > > > > > fi-bdw-5557u total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-bsw-n3050 total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-bxt-t5700 total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-byt-j1900 total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-byt-n2820 total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-hsw-4770 total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-hsw-4770r total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-ilk-650 total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-ivb-3520m total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-ivb-3770 total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-kbl-7200u total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-skl-6260u total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-skl-6700hqtotal:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > fi-snb-2520m total:15 pass:14 dwarn:0 dfail:0 fail:0 skip:0 > > > > Results at /archive/results/CI_IGT_test/Patchwork_2698/ > > > > 75d9d28f7f5d0147ba35e956268c3a3c079dc754 drm-intel-nightly: 2016y-10m- > > 13d-09h-14m-05s UTC integration manifest > > ae958d3 drm/i915: Trim sg table after creating it > > c393824 lib/scatterlist: Add sg_trim_table > > 35fb691 drm/i915: Use i915_sg_create for dmabuf 215eb9b drm/i915: Use > > i915_sg_create for rotated pages view > > 845b775 drm/i915: Use i915_sg_create for partial views > > 393cad6 drm/i915: Use i915_sg_create for userptr 0e4b44a drm/i915: Extract > > sg creation into a helper > > > > Jani Saarinen > Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo > > > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation 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 1/5] drm/i915: Use fence_write() from rpm resume
On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote: > On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote: > > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device *dev) > > * Commit delayed tiling changes if we have an object still > > * attached to the fence, otherwise just clear the fence. > > */ > > - if (vma && !i915_gem_object_is_tiled(vma->obj)) > > + if (vma && !i915_gem_object_is_tiled(vma->obj)) { > > + GEM_BUG_ON(!reg->dirty); > > + GEM_BUG_ON(!list_empty(&vma->obj->userfault_link)); > > + > > + list_move(®->link, &dev_priv->mm.fence_list); > > + vma->fence = NULL; > > vma = NULL; > > + } > > > > - fence_update(reg, vma); > > + fence_write(reg, vma); > > + reg->vma = vma; > > Same comments as with the userfault_list: Using rpm ordering to enforce > consistency causes mild panic attacks here with me ;-) > > Is the above (delayed tiling change commit) even possible here, at least > for rpm resume? Same for system s/r (both s3 and s4) since the pagetables > won't survive anyway. Can't we simply make this an impossibility? We also use this from reset to rewrite the old fences, and we know there we can hit the delayed fence write [4fc788f5ee3d]. It would also be possible to hit it on suspend as well. I've been thinking about whether we should be bothering to write the fence registers with the correct value or just cancel the fences. But we have to restore anything that is pinned, and we have to write something into the fences (just to be safe), and if we have to write something we may as well use the most recent information we have as that has a good chance of being used again. Long story short, I don't have a better idea for restoring or avoiding the restore of fences. -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 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access
On Thu, Oct 13, 2016 at 04:15:23PM +0100, Chris Wilson wrote: > On Thu, Oct 13, 2016 at 04:44:23PM +0200, Daniel Vetter wrote: > > On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > > b/drivers/gpu/drm/i915/i915_gem.c > > > index 91910ffe0964..587a91af5a3f 100644 > > > --- a/drivers/gpu/drm/i915/i915_gem.c > > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > > @@ -1469,7 +1469,9 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void > > > *data, > > >*/ > > > if (!i915_gem_object_has_struct_page(obj) || > > > cpu_write_needs_clflush(obj)) { > > > + intel_runtime_pm_get(dev_priv); > > > ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file); > > > + intel_runtime_pm_put(dev_priv); > > > > I'd move the rpm_get/put into gtt_pwrite_fast - there's only one caller, > > and it's in the spirit of this patch of moving the rpm get/put closer to > > where we really need it. > > What I've also done is move rpm_get/rpm_put into i915_gem_release_mmap() > and split out the RPM-suspend only i915_gem_release_all_mmaps() (if I > can think of a good name to better distinguish the two I'll do that as > well). The benefit being is that instead of simply asserting in one that > we hold the rpm-wakeref we take it. > > i915_gem_runtime_suspend__mmaps() ? Or maybe throw a ggtt in there for giggles, but yeah. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 1/5] drm/i915: Use fence_write() from rpm resume
On Thu, Oct 13, 2016 at 04:25:18PM +0100, Chris Wilson wrote: > On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote: > > On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote: > > > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device *dev) > > >* Commit delayed tiling changes if we have an object still > > >* attached to the fence, otherwise just clear the fence. > > >*/ > > > - if (vma && !i915_gem_object_is_tiled(vma->obj)) > > > + if (vma && !i915_gem_object_is_tiled(vma->obj)) { > > > + GEM_BUG_ON(!reg->dirty); > > > + GEM_BUG_ON(!list_empty(&vma->obj->userfault_link)); > > > + > > > + list_move(®->link, &dev_priv->mm.fence_list); > > > + vma->fence = NULL; > > > vma = NULL; > > > + } > > > > > > - fence_update(reg, vma); > > > + fence_write(reg, vma); > > > + reg->vma = vma; > > > > Same comments as with the userfault_list: Using rpm ordering to enforce > > consistency causes mild panic attacks here with me ;-) > > > > Is the above (delayed tiling change commit) even possible here, at least > > for rpm resume? Same for system s/r (both s3 and s4) since the pagetables > > won't survive anyway. Can't we simply make this an impossibility? > > We also use this from reset to rewrite the old fences, and we know there > we can hit the delayed fence write [4fc788f5ee3d]. It would also be > possible to hit it on suspend as well. > > I've been thinking about whether we should be bothering to write the > fence registers with the correct value or just cancel the fences. But we > have to restore anything that is pinned, and we have to write something > into the fences (just to be safe), and if we have to write something we > may as well use the most recent information we have as that has a good > chance of being used again. > > Long story short, I don't have a better idea for restoring or avoiding > the restore of fences. What about a rpm_resume only version that just does a blind fence_write? It is something, and we can update the book-keeping once we do get to one of the real synchronization points again. With that we can leave the versions for reset and system s/r alone ... Or is there trickery even with rpm going on? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 4/6] drm/i915: Always use the GTT for error capture
On Thu, Oct 13, 2016 at 05:02:50PM +0200, Daniel Vetter wrote: > On Wed, Oct 12, 2016 at 10:05:20AM +0100, Chris Wilson wrote: > > Since the GTT provides universal access to any GPU page, we can use it > > to reduce our plethora of read methods to just one. It also has the > > important characteristic of being exactly what the GPU sees - if there > > are incoherency problems, seeing the batch as executed (rather than as > > trapped inside the cpu cache) is important. > > > > Signed-off-by: Chris Wilson > > Reviewed-by: Joonas Lahtinen > > Meh, so much for me reading patches in order ;-) > > Please reorder this one before the previous one and I'll be happy too. Hmm, I actually thought this was. Shows what I remember about my series. -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] [RFC i-g-t PATCH 2/3] igt/gem_wait: Use new igt_dummyload api
On Thu, Oct 13, 2016 at 10:49:39AM +0100, Chris Wilson wrote: > On Thu, Oct 13, 2016 at 12:31:13PM +0300, Abdiel Janulgue wrote: > > > > > > On 10/12/2016 03:07 PM, Chris Wilson wrote: > > > On Wed, Oct 12, 2016 at 02:59:53PM +0300, Abdiel Janulgue wrote: > > >> Signed-off-by: Abdiel Janulgue > > >> --- > > >> tests/gem_wait.c | 77 > > >> +--- > > >> 1 file changed, 12 insertions(+), 65 deletions(-) > > > > > > We can do so much better than a dummy load here. We can precisely > > > control how long we want the object to be busy by using a recursive > > > batch buffer (and terminating that batch at the exact moment we require). > > > -Chris > > > > > Hi Chris, I see you've posted a better solution to gem_wait. I could > > drop this one and defer to yours instead. So for now, igt_dummyload has > > dropped to only 1 customer at the moment: kms_flip. Let me know whether > > it's possible to upstream this dummyload api. > > kms_flip would probably be better with a specific load rather than a > dummy as well. The challenge is whether the flip works given various > input states of the framebuffers, and the more control we have over > those inputs the better. Oh yeah, this is a pretty sweet idea with a spinning batch that we manually terminate. Assuming it works everywhere I think this is a much better approach, and by submitting different workloads we can always put the delay workload exactly where we want. Abdiel, can you pls update the JIRA to instead extract Chris' trick into a library (pretty sure Chris can help with bikeshedding the interface to make it all pretty) and then roll that one out? Being able to control the time used by delay tasks down to jiffies is real sweet. Also there might be some space to reuse this with Mika's hangcheck stuff, not sure. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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/3] drm/i915: Use RPM as the barrier for controlling user mmap access
On Thu, Oct 13, 2016 at 04:44:23PM +0200, Daniel Vetter wrote: > On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 91910ffe0964..587a91af5a3f 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -1469,7 +1469,9 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void > > *data, > > */ > > if (!i915_gem_object_has_struct_page(obj) || > > cpu_write_needs_clflush(obj)) { > > + intel_runtime_pm_get(dev_priv); > > ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file); > > + intel_runtime_pm_put(dev_priv); > > I'd move the rpm_get/put into gtt_pwrite_fast - there's only one caller, > and it's in the spirit of this patch of moving the rpm get/put closer to > where we really need it. What I've also done is move rpm_get/rpm_put into i915_gem_release_mmap() and split out the RPM-suspend only i915_gem_release_all_mmaps() (if I can think of a good name to better distinguish the two I'll do that as well). The benefit being is that instead of simply asserting in one that we hold the rpm-wakeref we take it. i915_gem_runtime_suspend__mmaps() ? -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: Assert we hold the CRTC powerwell for generating vblank interrupts
On Thu, Oct 13, 2016 at 04:17:07PM +0200, Daniel Vetter wrote: > On Wed, Oct 12, 2016 at 07:21:44AM +0200, Maarten Lankhorst wrote: > > I don't see a nice way to do this, it probably means we shouldn't do this > > at all.. > > Maybe have a function look at > > dev_priv->power_domains.domain_use_count[[POWER_DOMAIN_PIPE(pipe)] >= 1? > > It's potentially racy but I don't see a nice way to check, apart from > > hoping we handle the drm vblank on/off > > calls correctly. > > > > The only other way I see is demidlayering vblank. > > Or switch over power domains over to the core power domain stuff. There's > a reason those are protected with spinlocks, so that you can do these > kinds of checks ;-) Why not both! They're on the wishlist somewhere. -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 1/5] drm/i915: Use fence_write() from rpm resume
On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote: > During rpm resume we restore the fences, but we do not have the > protection of struct_mutex. This rules out updating the activity > tracking on the fences, and requires us to rely on the rpm as the > serialisation barrier instead. > > [ 350.298052] [drm:intel_runtime_resume [i915]] Resuming device > [ 350.308606] > [ 350.310520] === > [ 350.315560] [ INFO: suspicious RCU usage. ] > [ 350.320554] 4.8.0-rc8-bsw-rapl+ #3133 Tainted: G U W > [ 350.327208] --- > [ 350.331977] ../drivers/gpu/drm/i915/i915_gem_request.h:371 suspicious > rcu_dereference_protected() usage! > [ 350.342619] > [ 350.342619] other info that might help us debug this: > [ 350.342619] > [ 350.351593] > [ 350.351593] rcu_scheduler_active = 1, debug_locks = 0 > [ 350.358952] 3 locks held by Xorg/320: > [ 350.363077] #0: (&dev->mode_config.mutex){+.+.+.}, at: > [] drm_modeset_lock_all+0x3c/0xd0 [drm] > [ 350.375162] #1: (crtc_ww_class_acquire){+.+.+.}, at: > [] drm_modeset_lock_all+0x46/0xd0 [drm] > [ 350.387022] #2: (crtc_ww_class_mutex){+.+.+.}, at: [] > drm_modeset_lock+0x36/0x110 [drm] > [ 350.398236] > [ 350.398236] stack backtrace: > [ 350.403196] CPU: 1 PID: 320 Comm: Xorg Tainted: G U W > 4.8.0-rc8-bsw-rapl+ #3133 > [ 350.412457] Hardware name: Intel Corporation CHERRYVIEW C0 > PLATFORM/Braswell CRB, BIOS BRAS.X64.X088.R00.1510270350 10/27/2015 > [ 350.425212] 8801680a78c8 81332187 > 88016c5c5000 > [ 350.433611] 0001 8801680a78f8 810ca6da > 88016cc8b0f0 > [ 350.442012] 88016cc8 88016cc8 880177ad > 8801680a7948 > [ 350.450409] Call Trace: > [ 350.453165] [] dump_stack+0x67/0x90 > [ 350.458931] [] lockdep_rcu_suspicious+0xea/0x120 > [ 350.466002] [] fence_update+0xbd/0x670 [i915] > [ 350.472766] [] i915_gem_restore_fences+0x52/0x70 [i915] > [ 350.480496] [] vlv_resume_prepare+0x72/0x570 [i915] > [ 350.487839] [] intel_runtime_resume+0x102/0x210 [i915] > [ 350.495442] [] pci_pm_runtime_resume+0x7f/0xb0 > [ 350.502274] [] ? pci_restore_standard_config+0x40/0x40 > [ 350.509883] [] __rpm_callback+0x35/0x70 > [ 350.516037] [] ? pci_restore_standard_config+0x40/0x40 > [ 350.523646] [] rpm_callback+0x24/0x80 > [ 350.529604] [] ? pci_restore_standard_config+0x40/0x40 > [ 350.537212] [] rpm_resume+0x4ad/0x740 > [ 350.543161] [] __pm_runtime_resume+0x51/0x80 > [ 350.549824] [] intel_runtime_pm_get+0x28/0x90 [i915] > [ 350.557265] [] intel_display_power_get+0x23/0x50 [i915] > [ 350.565001] [] intel_atomic_commit_tail+0xdfd/0x10b0 > [i915] > [ 350.573106] [] ? > drm_atomic_helper_swap_state+0x159/0x300 [drm_kms_helper] > [ 350.582659] [] ? _raw_spin_unlock+0x31/0x50 > [ 350.589205] [] ? > drm_atomic_helper_swap_state+0x159/0x300 [drm_kms_helper] > [ 350.598787] [] intel_atomic_commit+0x3b5/0x500 [i915] > [ 350.606319] [] ? > drm_atomic_set_crtc_for_connector+0xcc/0x100 [drm] > [ 350.615209] [] drm_atomic_commit+0x49/0x50 [drm] > [ 350.622242] [] drm_atomic_helper_set_config+0x88/0xc0 > [drm_kms_helper] > [ 350.631419] [] drm_mode_set_config_internal+0x6c/0x120 > [drm] > [ 350.639623] [] drm_mode_setcrtc+0x22c/0x4d0 [drm] > [ 350.646760] [] drm_ioctl+0x209/0x460 [drm] > [ 350.653217] [] ? drm_mode_getcrtc+0x150/0x150 [drm] > [ 350.660536] [] ? __lock_is_held+0x4a/0x70 > [ 350.666885] [] do_vfs_ioctl+0x93/0x6b0 > [ 350.672939] [] ? __fget+0x113/0x200 > [ 350.678797] [] ? __fget+0x5/0x200 > [ 350.684361] [] SyS_ioctl+0x44/0x80 > [ 350.690030] [] do_syscall_64+0x5b/0x120 > [ 350.696184] [] entry_SYSCALL64_slow_path+0x25/0x25 > > Note we also have to remember the lesson from commit 4fc788f5ee3d > ("drm/i915: Flush delayed fence releases after reset") where we have to > flush any changes to the fence on restore. > > v2: Replace call to release user mmaps with an assertion that they have > already been zapped. > > Fixes: 49ef5294cda2 ("drm/i915: Move fence tracking from object to vma") > Reported-by: Ville Syrjälä > Signed-off-by: Chris Wilson > Cc: Ville Syrjälä > Cc: Joonas Lahtinen > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem_fence.c | 21 +++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c > b/drivers/gpu/drm/i915/i915_gem_fence.c > index 8df1fa7234e8..f7081f4b5d22 100644 > --- a/drivers/gpu/drm/i915/i915_gem_fence.c > +++ b/drivers/gpu/drm/i915/i915_gem_fence.c > @@ -290,6 +290,8 @@ i915_vma_put_fence(struct i915_vma *vma) > { > struct drm_i915_fence_reg *fence = vma->fence; > > + assert_rpm_wakelock_held(to_i915(vma->vm->dev)); > + > if (!fence) > return 0; > > @@ -341,6 +343,8 @@ i915_vma_get_fence(struct i915_vma *vma) > struct drm_i915_fence_reg *fence; > struct
Re: [Intel-gfx] [CI 3/6] drm/i915: Stop the machine whilst capturing the GPU crash dump
On Thu, Oct 13, 2016 at 04:57:39PM +0200, Daniel Vetter wrote: > On Wed, Oct 12, 2016 at 10:05:19AM +0100, Chris Wilson wrote: > > The error state is purposefully racy as we expect it to be called at any > > time and so have avoided any locking whilst capturing the crash dump. > > However, with multi-engine GPUs and multiple CPUs, those races can > > manifest into OOPSes as we attempt to chase dangling pointers freed on > > other CPUs. Under discussion are lots of ways to slow down normal > > operation in order to protect the post-mortem error capture, but what it > > we take the opposite approach and freeze the machine whilst the error > > capture runs (note the GPU may still running, but as long as we don't > > process any of the results the driver's bookkeeping will be static). > > > > Note that by of itself, this is not a complete fix. It also depends on > > the compiler barriers in list_add/list_del to prevent traversing the > > lists into the void. We also depend that we only require state from > > carefully controlled sources - i.e. all the state we require for > > post-mortem debugging should be reachable from the request itself so > > that we only have to worry about retrieving the request carefully. Once > > we have the request, we know that all pointers from it are intact. > > > > v2: Avoid drm_clflush_pages() inside stop_machine() as it may use > > stop_machine() itself for its wbinvd fallback. > > Hm, won't this hurt us real bad on any atom with ppgtt? Maybe a big check > gen check with a scary comment about why we can't call drm_clflush_pages > on old machines? Iirc gen3+ should all be able to flush without > stop_machine. :) Patch 2 switched to using coherent reads through the GTT for all. Everyone is now equal (and the nice part about that was that it uncovered the WC bug from kernel 4.0!) -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] [CI 4/6] drm/i915: Always use the GTT for error capture
On Wed, Oct 12, 2016 at 10:05:20AM +0100, Chris Wilson wrote: > Since the GTT provides universal access to any GPU page, we can use it > to reduce our plethora of read methods to just one. It also has the > important characteristic of being exactly what the GPU sees - if there > are incoherency problems, seeing the batch as executed (rather than as > trapped inside the cpu cache) is important. > > Signed-off-by: Chris Wilson > Reviewed-by: Joonas Lahtinen Meh, so much for me reading patches in order ;-) Please reorder this one before the previous one and I'll be happy too. > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 43 > drivers/gpu/drm/i915/i915_gem_gtt.h | 2 + > drivers/gpu/drm/i915/i915_gpu_error.c | 120 > -- > 3 files changed, 74 insertions(+), 91 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index 0bb4232f66bc..2d846aa39ca5 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -2717,6 +2717,7 @@ int i915_gem_init_ggtt(struct drm_i915_private > *dev_priv) >*/ > struct i915_ggtt *ggtt = &dev_priv->ggtt; > unsigned long hole_start, hole_end; > + struct i915_hw_ppgtt *ppgtt; > struct drm_mm_node *entry; > int ret; > > @@ -2724,6 +2725,15 @@ int i915_gem_init_ggtt(struct drm_i915_private > *dev_priv) > if (ret) > return ret; > > + /* Reserve a mappable slot for our lockless error capture */ > + ret = drm_mm_insert_node_in_range_generic(&ggtt->base.mm, > + &ggtt->error_capture, > + 4096, 0, -1, > + 0, ggtt->mappable_end, > + 0, 0); > + if (ret) > + return ret; > + > /* Clear any non-preallocated blocks */ > drm_mm_for_each_hole(entry, &ggtt->base.mm, hole_start, hole_end) { > DRM_DEBUG_KMS("clearing unused GTT space: [%lx, %lx]\n", > @@ -2738,25 +2748,21 @@ int i915_gem_init_ggtt(struct drm_i915_private > *dev_priv) > true); > > if (USES_PPGTT(dev_priv) && !USES_FULL_PPGTT(dev_priv)) { > - struct i915_hw_ppgtt *ppgtt; > - > ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL); > - if (!ppgtt) > - return -ENOMEM; > + if (!ppgtt) { > + ret = -ENOMEM; > + goto err; > + } > > ret = __hw_ppgtt_init(ppgtt, dev_priv); > - if (ret) { > - kfree(ppgtt); > - return ret; > - } > + if (ret) > + goto err_ppgtt; > > - if (ppgtt->base.allocate_va_range) > + if (ppgtt->base.allocate_va_range) { > ret = ppgtt->base.allocate_va_range(&ppgtt->base, 0, > ppgtt->base.total); > - if (ret) { > - ppgtt->base.cleanup(&ppgtt->base); > - kfree(ppgtt); > - return ret; > + if (ret) > + goto err_ppgtt_cleanup; > } > > ppgtt->base.clear_range(&ppgtt->base, > @@ -2770,6 +2776,14 @@ int i915_gem_init_ggtt(struct drm_i915_private > *dev_priv) > } > > return 0; > + > +err_ppgtt_cleanup: > + ppgtt->base.cleanup(&ppgtt->base); > +err_ppgtt: > + kfree(ppgtt); > +err: > + drm_mm_remove_node(&ggtt->error_capture); > + return ret; > } > > /** > @@ -2788,6 +2802,9 @@ void i915_ggtt_cleanup_hw(struct drm_i915_private > *dev_priv) > > i915_gem_cleanup_stolen(&dev_priv->drm); > > + if (drm_mm_node_allocated(&ggtt->error_capture)) > + drm_mm_remove_node(&ggtt->error_capture); > + > if (drm_mm_initialized(&ggtt->base.mm)) { > intel_vgt_deballoon(dev_priv); > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h > b/drivers/gpu/drm/i915/i915_gem_gtt.h > index ec78be2f8c77..bd93fb8f99d2 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.h > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h > @@ -450,6 +450,8 @@ struct i915_ggtt { > bool do_idle_maps; > > int mtrr; > + > + struct drm_mm_node error_capture; > }; > > struct i915_hw_ppgtt { > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > b/drivers/gpu/drm/i915/i915_gpu_error.c > index 159d6d7e0cee..b3b2e6c1c6c6 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -656,7 +656,7 @@ static void i915_error_object_free(struct > drm_i915_error_object *obj) > return; > > for (page = 0; page < obj->page_count; page++) > - kfree(obj->pages[page]); > +
Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs
On Thu, Oct 13, 2016 at 04:13:44PM +0200, Daniel Vetter wrote: > I was a bit over-eager in my cleanup in > > commit 95c081c17f284de50eaca60d4d55643a64d39019 > Author: Daniel Vetter > Date: Tue Jun 21 10:54:12 2016 +0200 > > drm: Move master pointer from drm_minor to drm_device > > Noticed by Chris Wilson. > > Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device") > Cc: Chris Wilson > Cc: Chris Wilson > Cc: Daniel Vetter > Cc: Emil Velikov > Cc: Julia Lawall > Signed-off-by: Daniel Vetter Tested-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
Re: [Intel-gfx] [PATCH] drm/i915: Skip unbinding large unmappable global buffers
On Thu, Oct 13, 2016 at 03:13:51PM +0100, Tvrtko Ursulin wrote: > > On 13/10/2016 13:59, Chris Wilson wrote: > >On Thu, Oct 13, 2016 at 12:29:44PM +0100, Tvrtko Ursulin wrote: > >>On 13/10/2016 09:55, Chris Wilson wrote: > >>>If the user requests a mappable binding to the global GTT, we will first > >>>unbind an existing mapping if it doesn't match. We will unbind even if > >>>there is no possibility that the object can fit in the mappable > >>>aperture. This may lead to a ping-pong migration of the object, for > >>>example igt/gem_exec_big. > >>> > >>>Testcase: igt/gem_exec_big > >>>Signed-off-by: Chris Wilson > >>>--- > >>> drivers/gpu/drm/i915/i915_gem.c | 19 ++- > >>> 1 file changed, 18 insertions(+), 1 deletion(-) > >>> > >>>diff --git a/drivers/gpu/drm/i915/i915_gem.c > >>>b/drivers/gpu/drm/i915/i915_gem.c > >>>index 2f939f90984b..f33aa9bb95c0 100644 > >>>--- a/drivers/gpu/drm/i915/i915_gem.c > >>>+++ b/drivers/gpu/drm/i915/i915_gem.c > >>>@@ -3144,6 +3144,9 @@ search_free: > >>> goto err_unpin; > >>> } > >>>+ > >>>+ GEM_BUG_ON(vma->node.start < start); > >>>+ GEM_BUG_ON(vma->node.start + vma->node.size > end); > >>> } > >>> GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level)); > >>>@@ -3843,7 +3846,8 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object > >>>*obj, > >>>u64 alignment, > >>>u64 flags) > >>> { > >>>- struct i915_address_space *vm = &to_i915(obj->base.dev)->ggtt.base; > >>>+ struct drm_i915_private *dev_priv = to_i915(obj->base.dev); > >>>+ struct i915_address_space *vm = &dev_priv->ggtt.base; > >>> struct i915_vma *vma; > >>> int ret; > >>>@@ -3858,6 +3862,19 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object > >>>*obj, > >>> (i915_vma_is_pinned(vma) || i915_vma_is_active(vma))) > >>> return ERR_PTR(-ENOSPC); > >>>+ if (flags & PIN_MAPPABLE) { > >>>+ u32 fence_size; > >>>+ > >>>+ fence_size = i915_gem_get_ggtt_size(dev_priv, vma->size, > >>>+ > >>>i915_gem_object_get_tiling(obj)); > >>>+ if (fence_size > dev_priv->ggtt.mappable_end) > >>>+ return ERR_PTR(-E2BIG); > >>>+ > >>>+ if (flags & PIN_NONBLOCK && > >>>+ fence_size > dev_priv->ggtt.mappable_end / 2) > >>>+ return ERR_PTR(-ENOSPC); > >>One half of aperture is a magic number or something else? > >Magic number. NONBLOCK means try, we have a fallback planned. > > > >It more or less comes from the old habit of having to assume that all > >fences take up twice the space we expect due to alignment. And given > >NONBLOCK means that we should have a better fallback than evicting the > >majority of the aperture on a whim. > > Ok I couldn't not think of any potential bad interactions. > > If you add a comment explaining the reasoning: Felt in the mood to write a few sentences. Hopefully they make sense in the morning. Thanks, -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] [CI 3/6] drm/i915: Stop the machine whilst capturing the GPU crash dump
On Wed, Oct 12, 2016 at 10:05:19AM +0100, Chris Wilson wrote: > The error state is purposefully racy as we expect it to be called at any > time and so have avoided any locking whilst capturing the crash dump. > However, with multi-engine GPUs and multiple CPUs, those races can > manifest into OOPSes as we attempt to chase dangling pointers freed on > other CPUs. Under discussion are lots of ways to slow down normal > operation in order to protect the post-mortem error capture, but what it > we take the opposite approach and freeze the machine whilst the error > capture runs (note the GPU may still running, but as long as we don't > process any of the results the driver's bookkeeping will be static). > > Note that by of itself, this is not a complete fix. It also depends on > the compiler barriers in list_add/list_del to prevent traversing the > lists into the void. We also depend that we only require state from > carefully controlled sources - i.e. all the state we require for > post-mortem debugging should be reachable from the request itself so > that we only have to worry about retrieving the request carefully. Once > we have the request, we know that all pointers from it are intact. > > v2: Avoid drm_clflush_pages() inside stop_machine() as it may use > stop_machine() itself for its wbinvd fallback. Hm, won't this hurt us real bad on any atom with ppgtt? Maybe a big check gen check with a scary comment about why we can't call drm_clflush_pages on old machines? Iirc gen3+ should all be able to flush without stop_machine. With that addressed you can upgrade to Reviewed-by: Daniel Vetter , but I think Mika should ack this too. -Daniel > > Signed-off-by: Chris Wilson > Acked-by: Daniel Vetter > --- > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/i915_gpu_error.c | 46 > +-- > 3 files changed, 31 insertions(+), 18 deletions(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index 8844b99bd760..3eff42e4a441 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -4,6 +4,7 @@ config DRM_I915 > depends on X86 && PCI > select INTEL_GTT > select INTERVAL_TREE > + select STOP_MACHINE > # we need shmfs for the swappable backing store, and in particular > # the shmem_readpage() which depends upon tmpfs > select SHMEM > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 380590b30bbf..4199e8aa436a 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -746,6 +746,8 @@ struct drm_i915_error_state { > struct kref ref; > struct timeval time; > > + struct drm_i915_private *i915; > + > char error_msg[128]; > bool simulated; > int iommu; > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > b/drivers/gpu/drm/i915/i915_gpu_error.c > index c88c0d192a60..159d6d7e0cee 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -28,6 +28,7 @@ > */ > > #include > +#include > #include "i915_drv.h" > > static const char *engine_str(int engine) > @@ -744,14 +745,12 @@ i915_error_object_create(struct drm_i915_private > *dev_priv, > > dst->page_count = num_pages; > while (num_pages--) { > - unsigned long flags; > void *d; > > d = kmalloc(PAGE_SIZE, GFP_ATOMIC); > if (d == NULL) > goto unwind; > > - local_irq_save(flags); > if (use_ggtt) { > void __iomem *s; > > @@ -770,15 +769,10 @@ i915_error_object_create(struct drm_i915_private > *dev_priv, > > page = i915_gem_object_get_page(src, i); > > - drm_clflush_pages(&page, 1); > - > s = kmap_atomic(page); > memcpy(d, s, PAGE_SIZE); > kunmap_atomic(s); > - > - drm_clflush_pages(&page, 1); > } > - local_irq_restore(flags); > > dst->pages[i++] = d; > reloc_offset += PAGE_SIZE; > @@ -1447,6 +1441,31 @@ static void i915_capture_gen_state(struct > drm_i915_private *dev_priv, > sizeof(error->device_info)); > } > > +static int capture(void *data) > +{ > + struct drm_i915_error_state *error = data; > + > + /* Ensure that what we readback from memory matches what the GPU sees */ > + wbinvd(); > + > + i915_capture_gen_state(error->i915, error); > + i915_capture_reg_state(error->i915, error); > + i915_gem_record_fences(error->i915, error); > + i915_gem_record_rings(error->i915, error); > + i915_capture_active_buffers(error->i915, error); > + i915_capture_pinned_buffers(error->i915, error); > + > + do_gettimeofday(&error->time); > + > + er
Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general
Reviewed-by: Jeff McGee On Mon, Oct 03, 2016 at 11:42:55AM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > Rename some of the GuC fw loading code to make them more general. We > will utilise them for HuC loading as well. > s/intel_guc_fw/intel_uc_fw/g > s/GUC_FIRMWARE/UC_FIRMWARE/g > > Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members, > such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for > same purpose. > > v2: rebased on top of nightly. > reapplied the search/replace as upstream code as changed. > v3: rebased again on drm-nightly. > v4: removed G from messages in shared fw fetch function. > v5: rebased. > v7: rebased. > v8: rebased. > > Signed-off-by: Anusha Srivatsa > Signed-off-by: Alex Dai > Signed-off-by: Peter Antoine > Reviewed-by: Dave Gordon > --- > drivers/gpu/drm/i915/i915_debugfs.c| 12 +-- > drivers/gpu/drm/i915/i915_guc_submission.c | 4 +- > drivers/gpu/drm/i915/intel_guc.h | 39 > drivers/gpu/drm/i915/intel_guc_loader.c| 156 > ++--- > 4 files changed, 106 insertions(+), 105 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 4fb9d82..44258a8 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -2416,7 +2416,7 @@ static int i915_llc(struct seq_file *m, void *data) > static int i915_guc_load_status_info(struct seq_file *m, void *data) > { > struct drm_i915_private *dev_priv = node_to_i915(m->private); > - struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw; > + struct intel_uc_fw *guc_fw = &dev_priv->guc.guc_fw; > u32 tmp, i; > > if (!HAS_GUC_UCODE(dev_priv)) > @@ -2424,15 +2424,15 @@ static int i915_guc_load_status_info(struct seq_file > *m, void *data) > > seq_printf(m, "GuC firmware status:\n"); > seq_printf(m, "\tpath: %s\n", > - guc_fw->guc_fw_path); > + guc_fw->uc_fw_path); > seq_printf(m, "\tfetch: %s\n", > - intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status)); > + intel_uc_fw_status_repr(guc_fw->fetch_status)); > seq_printf(m, "\tload: %s\n", > - intel_guc_fw_status_repr(guc_fw->guc_fw_load_status)); > + intel_uc_fw_status_repr(guc_fw->load_status)); > seq_printf(m, "\tversion wanted: %d.%d\n", > - guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted); > + guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted); > seq_printf(m, "\tversion found: %d.%d\n", > - guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found); > + guc_fw->major_ver_found, guc_fw->minor_ver_found); > seq_printf(m, "\theader: offset is %d; size = %d\n", > guc_fw->header_offset, guc_fw->header_size); > seq_printf(m, "\tuCode: offset is %d; size = %d\n", > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c > b/drivers/gpu/drm/i915/i915_guc_submission.c > index 43358e1..4b92943 100644 > --- a/drivers/gpu/drm/i915/i915_guc_submission.c > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c > @@ -1072,7 +1072,7 @@ int intel_guc_suspend(struct drm_device *dev) > struct i915_gem_context *ctx; > u32 data[3]; > > - if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS) > + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) > return 0; > > ctx = dev_priv->kernel_context; > @@ -1098,7 +1098,7 @@ int intel_guc_resume(struct drm_device *dev) > struct i915_gem_context *ctx; > u32 data[3]; > > - if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS) > + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) > return 0; > > ctx = dev_priv->kernel_context; > diff --git a/drivers/gpu/drm/i915/intel_guc.h > b/drivers/gpu/drm/i915/intel_guc.h > index b1ba869..b134a41 100644 > --- a/drivers/gpu/drm/i915/intel_guc.h > +++ b/drivers/gpu/drm/i915/intel_guc.h > @@ -91,29 +91,29 @@ struct i915_guc_client { > uint64_t submissions[I915_NUM_ENGINES]; > }; > > -enum intel_guc_fw_status { > - GUC_FIRMWARE_FAIL = -1, > - GUC_FIRMWARE_NONE = 0, > - GUC_FIRMWARE_PENDING, > - GUC_FIRMWARE_SUCCESS > +enum intel_uc_fw_status { > + UC_FIRMWARE_FAIL = -1, > + UC_FIRMWARE_NONE = 0, > + UC_FIRMWARE_PENDING, > + UC_FIRMWARE_SUCCESS > }; > > /* > * This structure encapsulates all the data needed during the process > * of fetching, caching, and loading the firmware image into the GuC. > */ > -struct intel_guc_fw { > - struct drm_device * guc_dev; > - const char *guc_fw_path; > - size_t guc_fw_size; > - struct drm_i915_gem_object *guc_fw_obj; > - enum intel_guc_fw_statusguc_fw_fetch_status; > - enum intel_guc_fw_statusguc_fw_load_status; > - > - uint16_t
Re: [Intel-gfx] [maintainer-tools PATCH 6/6] dim: add command to check for dim updates
On Tue, Oct 11, 2016 at 04:07:30PM +0300, Jani Nikula wrote: > On Tue, 11 Oct 2016, Daniel Vetter wrote: > > On Tue, Oct 11, 2016 at 11:47:32AM +0300, Jani Nikula wrote: > >> Add a command to check if the user is running an up-to-date version of > >> dim. > >> > >> Signed-off-by: Jani Nikula > >> --- > >> dim | 21 + > >> dim.rst | 4 > >> 2 files changed, 25 insertions(+) > >> > >> diff --git a/dim b/dim > >> index bef7bb6c401b..5fb3a0fee7ff 100755 > >> --- a/dim > >> +++ b/dim > >> @@ -179,6 +179,27 @@ if [ "$subcommand" != "setup" -a "$subcommand" != > >> "help" -a "$subcommand" != "us > >>xargs -n 1 echo | grep '^origin' | sed -e 's/^origin\///'` > >> fi > >> > >> +function dim_uptodate > >> +{ > >> + local using="${BASH_SOURCE[0]}" > >> + > >> + if [[ ! -e "$using" ]]; then > >> + echo "$dim: could not figure out the version being used > >> ($using)." >&2 > >> + exit 1 > >> + fi > >> + > >> + if [[ ! -e "$DIM_PREFIX/maintainer-tools/.git" ]]; then > >> + echo "$dim: could not find the upstream repo for $dim." >&2 > >> + exit 1 > >> + fi > >> + > >> + if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show > >> origin/maintainer-tools:dim |\ > >> + diff "$using" - >& /dev/null; then > >> + echo "$dim: not running upstream version of the script." >&2 > >> + exit 1 > >> + fi > >> +} > > > > Should we run this at startup every once in a while? Something like > > > > if [[ "$((`date +%s` % 100))" -eq "0" ]] ; then > > dim_uptodate > > fi > > > > at the top? date-based rng tested, otherwise not ... > > I had something like that in mind at first, but decided to be less > obnoxious for starters. ;) Oh, the real obnoxious version would auto-update dim if it's not up-to-date ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 3/3] drm/i915: Remove superfluous locking around userfault_list
On Tue, Oct 11, 2016 at 03:37:59PM +0100, Chris Wilson wrote: > Now that we have reduced the access to the list to either (a) under the > struct_mutex whilst holding the RPM wakeref (so that concurrent writers to > the list are serialised by struct_mutex) and (b) under the atomic > runtime suspend (which cannot run concurrently with any other accessor due > to the atomic nature of the runtime suspend) we can remove the extra > locking around the list itself. > > Signed-off-by: Chris Wilson So this is a bit a pet peeve of mine, but when changing locking schemes I'm trying to make an as clear as possible distinction between locking (which is just meant to protect the integrity of data structures, like e.g. the userfault_list here). And anything else which manages lifetimes and resources (all the get/put stuff we have) or ordering/sequence (waiting, waking up other stuff and all that). The reason for that is that with a BKL it is super easy to smash all these things into one, but if you have locking that also keeps stuff alive and guarantees ordering (or the other way round) it becomes nigh to impossible to untangle. Hence why I don't like this. -Daniel > --- > drivers/gpu/drm/i915/i915_drv.h | 3 --- > drivers/gpu/drm/i915/i915_gem.c | 21 - > 2 files changed, 4 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 72b3126c6c74..13ca968a760a 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1359,9 +1359,6 @@ struct i915_gem_mm { >*/ > struct list_head unbound_list; > > - /** Protects access to the userfault_list */ > - spinlock_t userfault_lock; > - > /** List of all objects in gtt_space, currently mmaped by userspace. >* All objects within this list must also be on bound_list. >*/ > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 587a91af5a3f..a268e804005c 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -1853,9 +1853,7 @@ int i915_gem_fault(struct vm_area_struct *area, struct > vm_fault *vmf) > goto err_unpin; > > assert_rpm_wakelock_held(dev_priv); > - spin_lock(&dev_priv->mm.userfault_lock); > list_add(&obj->userfault_link, &dev_priv->mm.userfault_list); > - spin_unlock(&dev_priv->mm.userfault_lock); > > err_unpin: > __i915_vma_unpin(vma); > @@ -1925,7 +1923,6 @@ void > i915_gem_release_mmap(struct drm_i915_gem_object *obj) > { > struct drm_i915_private *i915 = to_i915(obj->base.dev); > - bool zap = false; > > /* Serialisation between user GTT access and our code depends upon >* revoking the CPU's PTE whilst the mutex is held. The next user > @@ -1937,15 +1934,10 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj) >*/ > assert_rpm_wakelock_held(i915); > > - spin_lock(&i915->mm.userfault_lock); > - if (!list_empty(&obj->userfault_link)) { > - list_del_init(&obj->userfault_link); > - zap = true; > - } > - spin_unlock(&i915->mm.userfault_lock); > - if (!zap) > + if (list_empty(&obj->userfault_link)) > return; > > + list_del_init(&obj->userfault_link); > drm_vma_node_unmap(&obj->base.vma_node, > obj->base.dev->anon_inode->i_mapping); > > @@ -1963,13 +1955,9 @@ void > i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv) > { > struct drm_i915_gem_object *obj, *on; > - struct list_head userfault_list; > - > - spin_lock(&dev_priv->mm.userfault_lock); > - list_replace_init(&dev_priv->mm.userfault_list, &userfault_list); > - spin_unlock(&dev_priv->mm.userfault_lock); > > - list_for_each_entry_safe(obj, on, &userfault_list, userfault_link) > + list_for_each_entry_safe(obj, on, > + &dev_priv->mm.userfault_list, userfault_link) > i915_gem_release_mmap(obj); > } > > @@ -4457,7 +4445,6 @@ int i915_gem_init(struct drm_device *dev) > int ret; > > mutex_lock(&dev->struct_mutex); > - spin_lock_init(&dev_priv->mm.userfault_lock); > > if (!i915.enable_execlists) { > dev_priv->gt.resume = intel_legacy_submission_resume; > -- > 2.9.3 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation 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/3] drm/i915: Use RPM as the barrier for controlling user mmap access
On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote: > We can remove the false coupling between RPM and struct mutex by the > observation that we can use the RPM wakeref as the barrier around user > mmap access. That is as we tear down the user's PTE atomically from > within rpm suspend and then to fault in new PTE requires the rpm > wakeref, means that no user access is possible through those PTE without > RPM being awake. Having made that observation, we can then remove the > presumption of having to take rpm outside of struct_mutex and so allow > fine grained acquisition of a wakeref around hw access rather than > having to remember to acquire the wakeref early on. > > Signed-off-by: Chris Wilson > Cc: Imre Deak > Cc: Daniel Vetter > Cc: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_debugfs.c| 22 -- > drivers/gpu/drm/i915/i915_drv.c| 19 --- > drivers/gpu/drm/i915/i915_gem.c| 14 +- > drivers/gpu/drm/i915/i915_gem_gtt.c| 17 + > drivers/gpu/drm/i915/i915_gem_tiling.c | 4 > drivers/gpu/drm/i915/intel_uncore.c| 6 +++--- > 6 files changed, 21 insertions(+), 61 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index d4ecc5283c2a..d4779abd89e3 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -1400,14 +1400,9 @@ static int i915_hangcheck_info(struct seq_file *m, > void *unused) > static int ironlake_drpc_info(struct seq_file *m) > { > struct drm_i915_private *dev_priv = node_to_i915(m->private); > - struct drm_device *dev = &dev_priv->drm; > u32 rgvmodectl, rstdbyctl; > u16 crstandvid; > - int ret; > > - ret = mutex_lock_interruptible(&dev->struct_mutex); > - if (ret) > - return ret; > intel_runtime_pm_get(dev_priv); > > rgvmodectl = I915_READ(MEMMODECTL); > @@ -1415,7 +1410,6 @@ static int ironlake_drpc_info(struct seq_file *m) > crstandvid = I915_READ16(CRSTANDVID); > > intel_runtime_pm_put(dev_priv); > - mutex_unlock(&dev->struct_mutex); > > seq_printf(m, "HD boost: %s\n", yesno(rgvmodectl & MEMMODE_BOOST_EN)); > seq_printf(m, "Boost freq: %d\n", > @@ -2093,12 +2087,7 @@ static const char *swizzle_string(unsigned swizzle) > static int i915_swizzle_info(struct seq_file *m, void *data) > { > struct drm_i915_private *dev_priv = node_to_i915(m->private); > - struct drm_device *dev = &dev_priv->drm; > - int ret; > > - ret = mutex_lock_interruptible(&dev->struct_mutex); > - if (ret) > - return ret; > intel_runtime_pm_get(dev_priv); > > seq_printf(m, "bit6 swizzle for X-tiling = %s\n", > @@ -2138,7 +2127,6 @@ static int i915_swizzle_info(struct seq_file *m, void > *data) > seq_puts(m, "L-shaped memory detected\n"); > > intel_runtime_pm_put(dev_priv); > - mutex_unlock(&dev->struct_mutex); > > return 0; > } > @@ -4797,13 +4785,9 @@ i915_wedged_set(void *data, u64 val) > if (i915_reset_in_progress(&dev_priv->gpu_error)) > return -EAGAIN; > > - intel_runtime_pm_get(dev_priv); > - > i915_handle_error(dev_priv, val, > "Manually setting wedged to %llu", val); > > - intel_runtime_pm_put(dev_priv); > - > return 0; > } > > @@ -5038,22 +5022,16 @@ static int > i915_cache_sharing_get(void *data, u64 *val) > { > struct drm_i915_private *dev_priv = data; > - struct drm_device *dev = &dev_priv->drm; > u32 snpcr; > - int ret; > > if (!(IS_GEN6(dev_priv) || IS_GEN7(dev_priv))) > return -ENODEV; > > - ret = mutex_lock_interruptible(&dev->struct_mutex); > - if (ret) > - return ret; > intel_runtime_pm_get(dev_priv); > > snpcr = I915_READ(GEN6_MBCUNIT_SNPCR); > > intel_runtime_pm_put(dev_priv); > - mutex_unlock(&dev->struct_mutex); > > *val = (snpcr & GEN6_MBC_SNPCR_MASK) >> GEN6_MBC_SNPCR_SHIFT; > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 89d322215c84..31eee32fcf6d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -2313,24 +2313,6 @@ static int intel_runtime_suspend(struct device *kdev) > > DRM_DEBUG_KMS("Suspending device\n"); > > - /* > - * We could deadlock here in case another thread holding struct_mutex > - * calls RPM suspend concurrently, since the RPM suspend will wait > - * first for this RPM suspend to finish. In this case the concurrent > - * RPM resume will be followed by its RPM suspend counterpart. Still > - * for consistency return -EAGAIN, which will reschedule this suspend. > - */ > - if (!mutex_trylock(&dev->struct_mutex)) { > - DRM_DEBUG_KMS("device lock contention, deffering suspend\n"); >
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move user fault tracking to a separate list
On Tue, Oct 11, 2016 at 03:37:57PM +0100, Chris Wilson wrote: > We want to decouple RPM and struct_mutex, but currently RPM has to walk > the list of bound objects and remove userspace mmapping before we > suspend (otherwise userspace may continue to access the GTT whilst it is > powered down). This currently requires the struct_mutex to walk the > bound_list, but if we move that to a separate list and lock we can take > the first step towards removing the struct_mutex. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- > drivers/gpu/drm/i915/i915_drv.h | 20 +++--- > drivers/gpu/drm/i915/i915_gem.c | 39 > +++ > drivers/gpu/drm/i915/i915_gem_evict.c | 2 +- > 4 files changed, 46 insertions(+), 19 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 358663e833d6..d4ecc5283c2a 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -186,11 +186,11 @@ describe_obj(struct seq_file *m, struct > drm_i915_gem_object *obj) > } > if (obj->stolen) > seq_printf(m, " (stolen: %08llx)", obj->stolen->start); > - if (obj->pin_display || obj->fault_mappable) { > + if (obj->pin_display || !list_empty(&obj->userfault_link)) { > char s[3], *t = s; > if (obj->pin_display) > *t++ = 'p'; > - if (obj->fault_mappable) > + if (!list_empty(&obj->userfault_link)) > *t++ = 'f'; > *t = '\0'; > seq_printf(m, " (%s mappable)", s); > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index bf397b643cc0..72b3126c6c74 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1359,6 +1359,14 @@ struct i915_gem_mm { >*/ > struct list_head unbound_list; > > + /** Protects access to the userfault_list */ > + spinlock_t userfault_lock; > + > + /** List of all objects in gtt_space, currently mmaped by userspace. > + * All objects within this list must also be on bound_list. > + */ > + struct list_head userfault_list; > + > /** Usable portion of the GTT for GEM */ > unsigned long stolen_base; /* limited to low memory (32-bit) */ > > @@ -2215,6 +2223,11 @@ struct drm_i915_gem_object { > struct drm_mm_node *stolen; > struct list_head global_list; > > + /** > + * Whether the object is currently in the GGTT mmap. > + */ > + struct list_head userfault_link; > + > /** Used in execbuf to temporarily hold a ref */ > struct list_head obj_exec_link; > > @@ -2242,13 +2255,6 @@ struct drm_i915_gem_object { >*/ > unsigned int madv:2; > > - /** > - * Whether the current gtt mapping needs to be mappable (and isn't just > - * mappable by accident). Track pin and fault separate for a more > - * accurate mappable working set. > - */ > - unsigned int fault_mappable:1; > - > /* >* Is the object to be mapped as read-only to the GPU >* Only honoured if hardware has relevant pte bit > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index fdd496e6c081..91910ffe0964 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -1850,7 +1850,10 @@ int i915_gem_fault(struct vm_area_struct *area, struct > vm_fault *vmf) > if (ret) > goto err_unpin; > > - obj->fault_mappable = true; > + spin_lock(&dev_priv->mm.userfault_lock); > + list_add(&obj->userfault_link, &dev_priv->mm.userfault_list); > + spin_unlock(&dev_priv->mm.userfault_lock); I think we need to add it to the list _before_ we start punching in new ptes. At least if we want to decouple the locking and rpm refcounting a lot more (which I think we should, I had magic locks that ensure ordering on their own simply by being a BKL). But right now it's ok, so just a bikeshed. > + > err_unpin: > __i915_vma_unpin(vma); > err_unlock: > @@ -1918,36 +1921,52 @@ err: > void > i915_gem_release_mmap(struct drm_i915_gem_object *obj) > { > + struct drm_i915_private *i915 = to_i915(obj->base.dev); > + bool zap = false; > + > /* Serialisation between user GTT access and our code depends upon >* revoking the CPU's PTE whilst the mutex is held. The next user >* pagefault then has to wait until we release the mutex. > + * > + * Note that RPM complicates somewhat by adding an additional > + * requirement that operations to the GGTT be made holding the RPM > + * wakeref. >*/ > lockdep_assert_held(&obj->base.dev->struct_mutex); > > - if (!obj->fault_mappable) > + spin_lock(&i915->mm.userfault_lock); > + if (!list_empty(&obj->userfault_link)) { > + li
Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs
On Thu, Oct 13, 2016 at 10:13 AM, Daniel Vetter wrote: > I was a bit over-eager in my cleanup in > > commit 95c081c17f284de50eaca60d4d55643a64d39019 > Author: Daniel Vetter > Date: Tue Jun 21 10:54:12 2016 +0200 > > drm: Move master pointer from drm_minor to drm_device > > Noticed by Chris Wilson. > > Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device") > Cc: Chris Wilson > Cc: Chris Wilson > Cc: Daniel Vetter > Cc: Emil Velikov > Cc: Julia Lawall > Signed-off-by: Daniel Vetter Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/drm_info.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c > index 1df2d33d0b40..ffb2ab389d1d 100644 > --- a/drivers/gpu/drm/drm_info.c > +++ b/drivers/gpu/drm/drm_info.c > @@ -54,9 +54,6 @@ int drm_name_info(struct seq_file *m, void *data) > > mutex_lock(&dev->master_mutex); > master = dev->master; > - if (!master) > - goto out_unlock; > - > seq_printf(m, "%s", dev->driver->name); > if (dev->dev) > seq_printf(m, " dev=%s", dev_name(dev->dev)); > @@ -65,7 +62,6 @@ int drm_name_info(struct seq_file *m, void *data) > if (dev->unique) > seq_printf(m, " unique=%s", dev->unique); > seq_printf(m, "\n"); > -out_unlock: > mutex_unlock(&dev->master_mutex); > > return 0; > -- > 2.9.3 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Allow compaction upto SWIOTLB max segment size
On Wed, Oct 12, 2016 at 10:51:57PM +0100, Chris Wilson wrote: > On Wed, Oct 12, 2016 at 05:19:14PM -0400, Konrad Rzeszutek Wilk wrote: > > On Mon, Oct 10, 2016 at 11:27:00PM +0100, Chris Wilson wrote: > > > commit 1625e7e549c5 ("drm/i915: make compact dma scatter lists creation > > > work with SWIOTLB backend") took a heavy handed approach to undo the > > > scatterlist compaction in the face of SWIOTLB. (The compaction hit a bug > > > whereby we tried to pass a segment larger than SWIOTLB could handle.) We > > > can be a little more intelligent and try compacting the scatterlist up > > > to the maximum SWIOTLB segment size (when using SWIOTLB). > > > > > > > Won't this cause a bigger usage of the SWIOTLB bounce buffer ? > > It won't change the frequency of the usage of the bounce buffer, if that > is what you mean. Either you have intel-iommu and so will not go through > swiotlb, or you are forced to use swiotlb even though the hw doesn't > require it (swiotlb config is byzantium and always enabled unless you > hack it out and can rejoice at the lower cpu usage). Hahah. Wish that was possible. Anyhow my concern was with it under Xen, since the page_to_pfn(page) != last_pfn check is useless there (the PFNs may be contingous but underneath the machine frame numbers may be discontingous). And was thinking that this check should be moved to some form of 'DMA-API' type check, but that screams to me lots of work. Perhaps expose another swiotlb call to query the preferred size of the segments. So that you can get the 128 under baremetal SWIOTLB but under Xen it may expose 1. But that should not hold up this patch, and can be a followup patch I can write. Anyhow for *this* patch: Acked-by: Konrad Rzeszutek Wilk [as [xen,]swiotlb maintainer, in case you need this]. > -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] drm: Print device information again in debugfs
I was a bit over-eager in my cleanup in commit 95c081c17f284de50eaca60d4d55643a64d39019 Author: Daniel Vetter Date: Tue Jun 21 10:54:12 2016 +0200 drm: Move master pointer from drm_minor to drm_device Noticed by Chris Wilson. Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device") Cc: Chris Wilson Cc: Chris Wilson Cc: Daniel Vetter Cc: Emil Velikov Cc: Julia Lawall Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_info.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c index 1df2d33d0b40..ffb2ab389d1d 100644 --- a/drivers/gpu/drm/drm_info.c +++ b/drivers/gpu/drm/drm_info.c @@ -54,9 +54,6 @@ int drm_name_info(struct seq_file *m, void *data) mutex_lock(&dev->master_mutex); master = dev->master; - if (!master) - goto out_unlock; - seq_printf(m, "%s", dev->driver->name); if (dev->dev) seq_printf(m, " dev=%s", dev_name(dev->dev)); @@ -65,7 +62,6 @@ int drm_name_info(struct seq_file *m, void *data) if (dev->unique) seq_printf(m, " unique=%s", dev->unique); seq_printf(m, "\n"); -out_unlock: mutex_unlock(&dev->master_mutex); return 0; -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Merge duplicate gen4 and vlv/chv enable vblank callbacks
On Fri, Oct 07, 2016 at 08:49:52PM +0100, Chris Wilson wrote: > gen4/vlv/chv all use the same bits in pipestat to enable the vblank > interrupt, so they can share the same callbacks to enable/disable. > > Signed-off-by: Chris Wilson > Cc: Ville Syrjälä Irrespective of patch 2 this seems nice. git made a mess of the diff, but I think it all checks out. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/i915_irq.c | 59 > +++-- > 1 file changed, 28 insertions(+), 31 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index bd6c8b0eeaef..1e43fe30da11 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -2718,45 +2718,40 @@ void i915_handle_error(struct drm_i915_private > *dev_priv, > /* Called from drm generic code, passed 'crtc' which > * we use as a pipe index > */ > -static int i915_enable_vblank(struct drm_device *dev, unsigned int pipe) > +static int i8xx_enable_vblank(struct drm_device *dev, unsigned int pipe) > { > struct drm_i915_private *dev_priv = to_i915(dev); > unsigned long irqflags; > > spin_lock_irqsave(&dev_priv->irq_lock, irqflags); > - if (INTEL_INFO(dev)->gen >= 4) > - i915_enable_pipestat(dev_priv, pipe, > - PIPE_START_VBLANK_INTERRUPT_STATUS); > - else > - i915_enable_pipestat(dev_priv, pipe, > - PIPE_VBLANK_INTERRUPT_STATUS); > + i915_enable_pipestat(dev_priv, pipe, PIPE_VBLANK_INTERRUPT_STATUS); > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); > > return 0; > } > > -static int ironlake_enable_vblank(struct drm_device *dev, unsigned int pipe) > +static int i965_enable_vblank(struct drm_device *dev, unsigned int pipe) > { > struct drm_i915_private *dev_priv = to_i915(dev); > unsigned long irqflags; > - uint32_t bit = (INTEL_INFO(dev)->gen >= 7) ? DE_PIPE_VBLANK_IVB(pipe) : > - DE_PIPE_VBLANK(pipe); > > spin_lock_irqsave(&dev_priv->irq_lock, irqflags); > - ilk_enable_display_irq(dev_priv, bit); > + i915_enable_pipestat(dev_priv, pipe, > + PIPE_START_VBLANK_INTERRUPT_STATUS); > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); > > return 0; > } > > -static int valleyview_enable_vblank(struct drm_device *dev, unsigned int > pipe) > +static int ironlake_enable_vblank(struct drm_device *dev, unsigned int pipe) > { > struct drm_i915_private *dev_priv = to_i915(dev); > unsigned long irqflags; > + uint32_t bit = INTEL_GEN(dev) >= 7 ? > + DE_PIPE_VBLANK_IVB(pipe) : DE_PIPE_VBLANK(pipe); > > spin_lock_irqsave(&dev_priv->irq_lock, irqflags); > - i915_enable_pipestat(dev_priv, pipe, > - PIPE_START_VBLANK_INTERRUPT_STATUS); > + ilk_enable_display_irq(dev_priv, bit); > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); > > return 0; > @@ -2777,38 +2772,36 @@ static int gen8_enable_vblank(struct drm_device *dev, > unsigned int pipe) > /* Called from drm generic code, passed 'crtc' which > * we use as a pipe index > */ > -static void i915_disable_vblank(struct drm_device *dev, unsigned int pipe) > +static void i8xx_disable_vblank(struct drm_device *dev, unsigned int pipe) > { > struct drm_i915_private *dev_priv = to_i915(dev); > unsigned long irqflags; > > spin_lock_irqsave(&dev_priv->irq_lock, irqflags); > - i915_disable_pipestat(dev_priv, pipe, > - PIPE_VBLANK_INTERRUPT_STATUS | > - PIPE_START_VBLANK_INTERRUPT_STATUS); > + i915_disable_pipestat(dev_priv, pipe, PIPE_VBLANK_INTERRUPT_STATUS); > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); > } > > -static void ironlake_disable_vblank(struct drm_device *dev, unsigned int > pipe) > +static void i965_disable_vblank(struct drm_device *dev, unsigned int pipe) > { > struct drm_i915_private *dev_priv = to_i915(dev); > unsigned long irqflags; > - uint32_t bit = (INTEL_INFO(dev)->gen >= 7) ? DE_PIPE_VBLANK_IVB(pipe) : > - DE_PIPE_VBLANK(pipe); > > spin_lock_irqsave(&dev_priv->irq_lock, irqflags); > - ilk_disable_display_irq(dev_priv, bit); > + i915_disable_pipestat(dev_priv, pipe, > + PIPE_START_VBLANK_INTERRUPT_STATUS); > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); > } > > -static void valleyview_disable_vblank(struct drm_device *dev, unsigned int > pipe) > +static void ironlake_disable_vblank(struct drm_device *dev, unsigned int > pipe) > { > struct drm_i915_private *dev_priv = to_i915(dev); > unsigned long irqflags; > + uint32_t bit = INTEL_GEN(dev) >= 7 ? > + DE_PIPE_VBLANK_IVB(pipe) : DE_PIPE_VBLANK(
Re: [Intel-gfx] [PATCH] drm/i915: Assert we hold the CRTC powerwell for generating vblank interrupts
On Wed, Oct 12, 2016 at 07:21:44AM +0200, Maarten Lankhorst wrote: > Op 11-10-16 om 10:32 schreef Ville Syrjälä: > > On Tue, Oct 11, 2016 at 09:45:45AM +0200, Maarten Lankhorst wrote: > >> Op 11-10-16 om 08:55 schreef Ville Syrjälä: > >>> On Tue, Oct 11, 2016 at 08:17:22AM +0200, Maarten Lankhorst wrote: > Op 10-10-16 om 13:56 schreef Ville Syrjälä: > > On Mon, Oct 10, 2016 at 12:46:32PM +0100, Chris Wilson wrote: > >> On Mon, Oct 10, 2016 at 02:42:01PM +0300, Ville Syrjälä wrote: > >>> On Mon, Oct 10, 2016 at 12:34:54PM +0100, Chris Wilson wrote: > To enable the vblank itself, we need to have an RPM wakeref for the > mmio > access, and whilst generating the vblank interrupts we continue to > require the rpm wakeref. The assumption is that the RPM wakeref is > held > by the display powerwell held by the active pipe. As this chain was > not > obvious to me chasing the drm_wait_vblank ioctl, document it with a > WARN > during *_vblank_enable(). > > v2: Check the display power well rather than digging inside the > atomic > CRTC state. > > Signed-off-by: Chris Wilson > Cc: Ville Syrjälä > Cc: Maarten Lankhorst > --- > drivers/gpu/drm/i915/i915_irq.c | 20 > 1 file changed, 20 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > b/drivers/gpu/drm/i915/i915_irq.c > index 1e43fe30da11..f0f17055dbb9 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -2715,6 +2715,14 @@ void i915_handle_error(struct > drm_i915_private *dev_priv, > i915_reset_and_wakeup(dev_priv); > } > > +static void assert_pipe_is_awake(struct drm_i915_private *dev_priv, > + enum pipe pipe) > +{ > +WARN_ON(IS_ENABLED(CONFIG_DRM_I915_DEBUG) && > +!intel_display_power_is_enabled(dev_priv, > + > POWER_DOMAIN_PIPE(pipe))); > >>> Uses a mutex. And having a power well enabled doesn't mean much. It > >>> doesn't guarantee that vblanks work. > >> Impasse. :| > >> > >> There should be no point in an explicit assert_rpm_wakeref here as the > >> register access should catch an error there. Is there no safe way we > >> can > >> assert the current state of the CRTC is correct for enabling vblanks? > > crtc->active might be the closest thing, if we just ignore any locking. > > Though it looks like that has gone a bit mad these days, what with being > > set from the .crtc_enable() hooks but getting cleared outside the > > .crtc_disable() hooks. > > > I'm trying to kill crtc->active. > >>> Because it's evil? I still don't see much problem in having a thing to > >>> track the state of each pipe fairly accurately. > >>> > Maybe you'd want to use dev_priv->active_crtcs, but that won't save you > if you enable interrupts in between atomic commit and .crtc_disable > >>> Nothing atomic based will work well because the state is not flipped at > >>> the same time as the actual hardware state changes. > >>> > Safest bet is to look at the power state I think. > >>> I don't know which power state you mean, but I already shot down the > >>> power domain thing. > >>> > >>> > >> I would say use assert_pipe_enabled then. > > Nope. That one frobs with power domains too these days. > > > I don't see a nice way to do this, it probably means we shouldn't do this at > all.. > Maybe have a function look at > dev_priv->power_domains.domain_use_count[[POWER_DOMAIN_PIPE(pipe)] >= 1? > It's potentially racy but I don't see a nice way to check, apart from hoping > we handle the drm vblank on/off > calls correctly. > > The only other way I see is demidlayering vblank. Or switch over power domains over to the core power domain stuff. There's a reason those are protected with spinlocks, so that you can do these kinds of checks ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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] drm/i915: Skip unbinding large unmappable global buffers
On 13/10/2016 13:59, Chris Wilson wrote: On Thu, Oct 13, 2016 at 12:29:44PM +0100, Tvrtko Ursulin wrote: On 13/10/2016 09:55, Chris Wilson wrote: If the user requests a mappable binding to the global GTT, we will first unbind an existing mapping if it doesn't match. We will unbind even if there is no possibility that the object can fit in the mappable aperture. This may lead to a ping-pong migration of the object, for example igt/gem_exec_big. Testcase: igt/gem_exec_big Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 2f939f90984b..f33aa9bb95c0 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3144,6 +3144,9 @@ search_free: goto err_unpin; } + + GEM_BUG_ON(vma->node.start < start); + GEM_BUG_ON(vma->node.start + vma->node.size > end); } GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level)); @@ -3843,7 +3846,8 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj, u64 alignment, u64 flags) { - struct i915_address_space *vm = &to_i915(obj->base.dev)->ggtt.base; + struct drm_i915_private *dev_priv = to_i915(obj->base.dev); + struct i915_address_space *vm = &dev_priv->ggtt.base; struct i915_vma *vma; int ret; @@ -3858,6 +3862,19 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj, (i915_vma_is_pinned(vma) || i915_vma_is_active(vma))) return ERR_PTR(-ENOSPC); + if (flags & PIN_MAPPABLE) { + u32 fence_size; + + fence_size = i915_gem_get_ggtt_size(dev_priv, vma->size, + i915_gem_object_get_tiling(obj)); + if (fence_size > dev_priv->ggtt.mappable_end) + return ERR_PTR(-E2BIG); + + if (flags & PIN_NONBLOCK && + fence_size > dev_priv->ggtt.mappable_end / 2) + return ERR_PTR(-ENOSPC); One half of aperture is a magic number or something else? Magic number. NONBLOCK means try, we have a fallback planned. It more or less comes from the old habit of having to assume that all fences take up twice the space we expect due to alignment. And given NONBLOCK means that we should have a better fallback than evicting the majority of the aperture on a whim. Ok I couldn't not think of any potential bad interactions. If you add a comment explaining the reasoning: 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] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests
On Thu, Oct 13, 2016 at 04:55:49PM +0300, Jani Nikula wrote: > For whatever reason, I got a machine here where that file is empty (not > talking about the size, but cating the file actually produces > nothing). And I've got another machine where that is not the > case. *scratches head*. Appears to be Daniel's regression: commit 95c081c17f284de50eaca60d4d55643a64d39019 Author: Daniel Vetter Date: Tue Jun 21 10:54:12 2016 +0200 drm: Move master pointer from drm_minor to drm_device Too bad my name's on it 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 i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh
On Fri, Oct 07, 2016 at 10:15:19AM +0300, Joonas Lahtinen wrote: > On to, 2016-10-06 at 16:36 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > debugfs_wedged and drm_lib.sh are already using bashism so switch > > over > > to using #!/bin/bash instead of #!/bin/sh. > > > > Signed-off-by: Ville Syrjälä > > Just reminds me of my RFC to convert them all to #!/bin/sh. The final > resolution was that all the scripts will be converted into C programs > shortly, there was even a JIRA created for it, Daniel? Still the plan, and I even had "volunteers" for it. Unfortunately they got ACTed :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests
On Thu, Oct 13, 2016 at 04:55:49PM +0300, Jani Nikula wrote: > On Thu, 13 Oct 2016, Chris Wilson wrote: > >> + if [ -f $debugfs_path/dri/$minor/i915_error_state ] ; then > >> + i915_dfs_path=$debugfs_path/dri/$minor > > > > Thinking of how to wean ourselves off i915_error_state; how about > > That's of course independent of this series. > > > if [ grep -s i915 $debugfs_path/dri/$minor/name ]; then > > For whatever reason, I got a machine here where that file is empty (not > talking about the size, but cating the file actually produces > nothing). And I've got another machine where that is not the > case. *scratches head*. Is the first i915.ko builtin? -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 02/22] drm/i915: Shrink sdvo_cmd_names
On Wed, Oct 05, 2016 at 01:33:29PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Pack the struct _sdvo_cmd_name to save 736 bytes of .rodata. > > This is fine since the name pointers are used only for debug. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_sdvo.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c > b/drivers/gpu/drm/i915/intel_sdvo.c > index a061b0029797..9f352aac9526 100644 > --- a/drivers/gpu/drm/i915/intel_sdvo.c > +++ b/drivers/gpu/drm/i915/intel_sdvo.c > @@ -307,7 +307,7 @@ static bool intel_sdvo_read_byte(struct intel_sdvo > *intel_sdvo, u8 addr, u8 *ch) > static const struct _sdvo_cmd_name { > u8 cmd; > const char *name; > -} sdvo_cmd_names[] = { > +} __attribute__ ((packed)) sdvo_cmd_names[] = { > SDVO_CMD_NAME_ENTRY(SDVO_CMD_RESET), > SDVO_CMD_NAME_ENTRY(SDVO_CMD_GET_DEVICE_CAPS), > SDVO_CMD_NAME_ENTRY(SDVO_CMD_GET_FIRMWARE_REV), > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation 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 igt 1/2] lib/igt_aux: Add support for various system suspend/resume options
On Wed, Oct 05, 2016 at 12:04:52PM +0300, Imre Deak wrote: > /* suspend/hibernate and auto-resume system */ > -void igt_system_suspend_autoresume(void); > -void igt_system_hibernate_autoresume(void); > + > +enum igt_suspend_state { > + SUSPEND_STATE_FREEZE, > + SUSPEND_STATE_MEM, > + SUSPEND_STATE_DISK, > + > + SUSPEND_STATE_NUM, > +}; > + > +enum igt_suspend_test { > + SUSPEND_TEST_NONE, > + SUSPEND_TEST_FREEZER, > + SUSPEND_TEST_DEVICES, > + SUSPEND_TEST_PLATFORM, > + SUSPEND_TEST_PROCESSORS, > + SUSPEND_TEST_CORE, > + > + SUSPEND_TEST_NUM, > +}; Please document them enums too. And link from the functions to the enums (and make sure it works): $ ./autogen.sh --enable-gtk-doc $ make Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] intel-ci: CI is missing any wait tests in BAT
Add the two basic gem_wait tests to the fast list, together they take a total of 1s (when correctly functioning). Signed-off-by: Chris Wilson --- tests/intel-ci/fast-feedback.testlist | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist index f59ec98..853b911 100644 --- a/tests/intel-ci/fast-feedback.testlist +++ b/tests/intel-ci/fast-feedback.testlist @@ -126,6 +126,8 @@ igt@gem_sync@basic-store-each igt@gem_tiled_blits@basic igt@gem_tiled_fence_blits@basic igt@gem_tiled_pread_basic +igt@gem_wait@basic-busy-all +igt@gem_wait@basic-wait-all igt@gem_workarounds@basic-read igt@gvt_basic@invalid-placeholder-test igt@kms_addfb_basic@addfb25-bad-modifier -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Sanitory checks for platform that dont have GuC
Em Qua, 2016-10-12 às 16:13 -0700, Anusha Srivatsa escreveu: > i915.enable_guc_loading/submission=2 forces the usage of GuC. > For platforms that do not have a GuC, asking the kernel to > use a GuC should not result in an error state. Do extra checks > to see if the platform even has a GuC or not, regardless of the > kernel parameter. > > v2: Based on Rodrigo's patch and Paulo's suggestion(Paulo, Rodrigo) > v3: Correct the Indentation(Jani, Paulo) > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97573 > > Cc: Rodrigo Vivi > Cc: Zanoni Paulo > Cc: Jani Nikula > > Signed-off-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/intel_guc_loader.c | 16 ++-- > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c > b/drivers/gpu/drm/i915/intel_guc_loader.c > index 7ace96b..811080f 100644 > --- a/drivers/gpu/drm/i915/intel_guc_loader.c > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c > @@ -718,12 +718,16 @@ void intel_guc_init(struct drm_device *dev) > struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw; > const char *fw_path; > > - /* A negative value means "use platform default" */ > - if (i915.enable_guc_loading < 0) > - i915.enable_guc_loading = HAS_GUC_UCODE(dev); > - if (i915.enable_guc_submission < 0) > - i915.enable_guc_submission = HAS_GUC_SCHED(dev); > - > + if (!HAS_GUC(dev)) { > + i915.enable_guc_loading = 0; > + i915.enable_guc_submission = 0; > + } else { > + /* A negative value means "use platform default" */ > + if (i915.enable_guc_loading < 0) > + i915.enable_guc_loading = > HAS_GUC_UCODE(dev); > + if (i915.enable_guc_submission < 0) > + i915.enable_guc_submission = > HAS_GUC_SCHED(dev); > + } Well, the indentation is correct now, but this patch is still removing the blank line that was supposed to be at this spot, despite the fact that I pointed this problem in my two previous reviews... Please always pay attention to the reviews and try to make sure you're actually following them when submit new versions. It's a good idea if you can learn the patch format and look at the patch files directly in order to spot problems like this before submitting. I know this sounds super annoying since I'm just complaining about blank lines, but since I expect you to start contributing much more, I think it's worth trying to teach the coding style that's used by everybody so the next patches all come in the expected format. Anyway, I suppose we could amend this fix while applying the patch? If someone fixes that while applying, we can add: Reviewed-by: Paulo Zanoni > if (!HAS_GUC_UCODE(dev)) { > fw_path = NULL; > } else if (IS_SKYLAKE(dev)) { ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Add entrypoints for mapping dplls to encoders and crtcs
On Tue, Oct 04, 2016 at 03:32:17PM +0300, Ander Conselvan de Oliveira wrote: > Abstract the platform specific bits of mapping the dplls under a > platform independ entrypoints so the differences between platforms are > contained in the dpll code. I.e., it removes IS_PLATFORM() macros from > other parts of the code. > > Signed-off-by: Ander Conselvan de Oliveira > Not really sure this is worth it. This is all highly platform specific, adding abstraction just means even more hoops to jump through. But I spotted one thing while reading this. I know you're trying to consolidate the code here, but it feels a bit too much. At least I feel like the interactions between dpll and other code (i.e. how they link to encoders/crtc) is best left to that code. After all it's also that code that decides what kind of dpll setting it wants, the dpll mgr just figures out whether one is still available. -Daniel > --- > drivers/gpu/drm/i915/intel_ddi.c | 51 ++ > drivers/gpu/drm/i915/intel_display.c | 124 +- > drivers/gpu/drm/i915/intel_dp_mst.c | 4 +- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 299 > ++ > drivers/gpu/drm/i915/intel_dpll_mgr.h | 7 + > drivers/gpu/drm/i915/intel_drv.h | 4 +- > 6 files changed, 334 insertions(+), 155 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index 4077205..144fe5c 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -319,6 +319,19 @@ enum port intel_ddi_get_encoder_port(struct > intel_encoder *encoder) > } > } > > +struct intel_encoder * > +intel_ddi_get_port_encoder(struct drm_i915_private *dev_priv, enum port port) > +{ > + struct intel_encoder *encoder; > + > + for_each_intel_encoder(&dev_priv->drm, encoder) { > + if (port == intel_ddi_get_encoder_port(encoder)) > + return encoder; > + } > + > + return NULL; > +} > + > static const struct ddi_buf_trans * > bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries) > { > @@ -582,11 +595,12 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) > struct drm_i915_private *dev_priv = to_i915(dev); > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > struct intel_encoder *encoder; > - u32 temp, i, rx_ctl_val, ddi_pll_sel; > + u32 temp, i, rx_ctl_val; > > for_each_encoder_on_crtc(dev, crtc, encoder) { > WARN_ON(encoder->type != INTEL_OUTPUT_ANALOG); > intel_prepare_dp_ddi_buffers(encoder); > + break; > } > > /* Set the FDI_RX_MISC pwrdn lanes and the 2 workarounds listed at the > @@ -613,9 +627,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) > I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val); > > /* Configure Port Clock Select */ > - ddi_pll_sel = hsw_pll_to_ddi_pll_sel(intel_crtc->config->shared_dpll); > - I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel); > - WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL); > + intel_dpll_map_to_encoder(intel_crtc->config->shared_dpll, encoder); > > /* Start the training iterating through available voltages and emphasis, >* testing each value twice. */ > @@ -1607,33 +1619,6 @@ uint32_t ddi_signal_levels(struct intel_dp *intel_dp) > return DDI_BUF_TRANS_SELECT(level); > } > > -void intel_ddi_clk_select(struct intel_encoder *encoder, > - struct intel_shared_dpll *pll) > -{ > - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > - enum port port = intel_ddi_get_encoder_port(encoder); > - > - if (WARN_ON(!pll)) > - return; > - > - if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) { > - uint32_t val; > - > - /* DDI -> PLL mapping */ > - val = I915_READ(DPLL_CTRL2); > - > - val &= ~(DPLL_CTRL2_DDI_CLK_OFF(port) | > - DPLL_CTRL2_DDI_CLK_SEL_MASK(port)); > - val |= (DPLL_CTRL2_DDI_CLK_SEL(pll->id, port) | > - DPLL_CTRL2_DDI_SEL_OVERRIDE(port)); > - > - I915_WRITE(DPLL_CTRL2, val); > - > - } else if (INTEL_INFO(dev_priv)->gen < 9) { > - I915_WRITE(PORT_CLK_SEL(port), hsw_pll_to_ddi_pll_sel(pll)); > - } > -} > - > static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, > int link_rate, uint32_t lane_count, > struct intel_shared_dpll *pll, > @@ -1648,7 +1633,7 @@ static void intel_ddi_pre_enable_dp(struct > intel_encoder *encoder, > if (encoder->type == INTEL_OUTPUT_EDP) > intel_edp_panel_on(intel_dp); > > - intel_ddi_clk_select(encoder, pll); > + intel_dpll_map_to_encoder(pll, encoder); > intel_prepare_dp_ddi_buffers(encoder); > intel_ddi_init_dp_buf_reg(encoder); > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); > @@ -16
Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests
On Thu, 13 Oct 2016, Chris Wilson wrote: > On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote: >> While at it, make debugfs_path point at the debugfs root, not >> dri. This'll be handy in future work. >> >> Signed-off-by: Jani Nikula >> --- >> tests/drm_lib.sh | 16 ++-- >> 1 file changed, 10 insertions(+), 6 deletions(-) >> >> diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh >> index 113da4c7d645..87e3ad0ab547 100755 >> --- a/tests/drm_lib.sh >> +++ b/tests/drm_lib.sh >> @@ -41,18 +41,22 @@ do_or_die() { >> $@ > /dev/null 2>&1 || (echo "FAIL: $@ ($?)" && exit $IGT_EXIT_FAILURE) >> } >> >> -if [ -d /debug/dri ] ; then >> -debugfs_path=/debug/dri >> +if [ -d /sys/kernel/debug ]; then >> +debugfs_path=/sys/kernel/debug >> +elif [ -d /debug ]; then >> +debugfs_path=/debug >> +else >> +skip "debugfs not found" >> fi >> >> -if [ -d /sys/kernel/debug/dri ] ; then >> -debugfs_path=/sys/kernel/debug/dri >> +if [ ! -d $debugfs_path/dri ]; then >> +skip "dri debugfs not found" >> fi >> >> i915_dfs_path=x >> for minor in `seq 0 16`; do >> -if [ -f $debugfs_path/$minor/i915_error_state ] ; then >> -i915_dfs_path=$debugfs_path/$minor >> +if [ -f $debugfs_path/dri/$minor/i915_error_state ] ; then >> +i915_dfs_path=$debugfs_path/dri/$minor > > Thinking of how to wean ourselves off i915_error_state; how about That's of course independent of this series. > if [ grep -s i915 $debugfs_path/dri/$minor/name ]; then For whatever reason, I got a machine here where that file is empty (not talking about the size, but cating the file actually produces nothing). And I've got another machine where that is not the case. *scratches head*. BR, Jani. > > ? > -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
[Intel-gfx] ✗ Fi.CI.BAT: warning for New DDB Algo and WM fixes (rev4)
== Series Details == Series: New DDB Algo and WM fixes (rev4) URL : https://patchwork.freedesktop.org/series/1/ State : warning == Summary == Series 1v4 New DDB Algo and WM fixes https://patchwork.freedesktop.org/api/1.0/series/1/revisions/4/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (fi-hsw-4770) Test kms_busy: Subgroup basic-flip-default-b: dmesg-warn -> PASS (fi-hsw-4770) Subgroup basic-flip-default-c: dmesg-warn -> PASS (fi-hsw-4770) Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: dmesg-warn -> PASS (fi-hsw-4770) Subgroup basic-busy-flip-before-cursor-varying-size: dmesg-warn -> PASS (fi-hsw-4770) Subgroup basic-flip-after-cursor-legacy: dmesg-warn -> PASS (fi-hsw-4770) Subgroup basic-flip-after-cursor-varying-size: dmesg-warn -> PASS (fi-hsw-4770) Test kms_pipe_crc_basic: Subgroup bad-nb-words-3: dmesg-warn -> PASS (fi-ilk-650) Subgroup bad-pipe: dmesg-warn -> PASS (fi-hsw-4770) Subgroup hang-read-crc-pipe-b: dmesg-warn -> PASS (fi-hsw-4770) Subgroup hang-read-crc-pipe-c: dmesg-warn -> PASS (fi-hsw-4770) Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (fi-hsw-4770) Subgroup nonblocking-crc-pipe-a-frame-sequence: dmesg-warn -> PASS (fi-hsw-4770) Subgroup nonblocking-crc-pipe-b: dmesg-warn -> PASS (fi-hsw-4770) Subgroup nonblocking-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (fi-hsw-4770) Subgroup nonblocking-crc-pipe-c: dmesg-warn -> PASS (fi-hsw-4770) Subgroup nonblocking-crc-pipe-c-frame-sequence: dmesg-warn -> PASS (fi-hsw-4770) Subgroup read-crc-pipe-a: dmesg-warn -> PASS (fi-hsw-4770) Subgroup read-crc-pipe-b: dmesg-warn -> PASS (fi-hsw-4770) Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (fi-hsw-4770) pass -> DMESG-WARN (fi-ilk-650) Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-skl-6700k) dmesg-warn -> PASS (fi-byt-j1900) Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (fi-hsw-4770) Test pm_rpm: Subgroup basic-rte: pass -> DMESG-WARN (fi-hsw-4770) Test vgem_basic: Subgroup unload: skip -> PASS (fi-bdw-5557u) fi-bdw-5557u total:246 pass:231 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:246 pass:204 dwarn:0 dfail:0 fail:0 skip:42 fi-bxt-t5700 total:246 pass:216 dwarn:0 dfail:0 fail:0 skip:30 fi-byt-j1900 total:246 pass:213 dwarn:1 dfail:0 fail:1 skip:31 fi-byt-n2820 total:246 pass:210 dwarn:0 dfail:0 fail:1 skip:35 fi-hsw-4770 total:246 pass:221 dwarn:3 dfail:0 fail:0 skip:22 fi-hsw-4770r total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-ilk-650 total:246 pass:183 dwarn:1 dfail:0 fail:2 skip:60 fi-ivb-3520m total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-ivb-3770 total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 fi-kbl-7200u total:246 pass:222 dwarn:0 dfail:0 fail:0 skip:24 fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:246 pass:223 dwarn:0 dfail:0 fail:0 skip:23 fi-skl-6700k total:246 pass:221 dwarn:1 dfail:0 fail:0 skip:24 fi-skl-6770hqtotal:246 pass:230 dwarn:1 dfail:0 fail:1 skip:14 fi-snb-2520m total:246 pass:210 dwarn:0 dfail:0 fail:0 skip:36 fi-snb-2600 total:246 pass:209 dwarn:0 dfail:0 fail:0 skip:37 Results at /archive/results/CI_IGT_test/Patchwork_2703/ ab76ad934eba2e427d4b1db1313a9f30a009c075 drm-intel-nightly: 2016y-10m-13d-12h-30m-12s UTC integration manifest 5f867e4 drm/i915/skl+: use linetime latency instead of ddb size ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Add dpll entrypoint for dumping hw state
On Tue, Oct 04, 2016 at 03:32:16PM +0300, Ander Conselvan de Oliveira wrote: > Remove the IS_PLATFORM() macros from intel_dump_pipe_config() and split > that logic in platform specific implementations inside the dpll code, > accessed through a platform independent interface. > > Signed-off-by: Ander Conselvan de Oliveira > Real pretty ;-) Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_display.c | 35 +--- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 79 > +++ > drivers/gpu/drm/i915/intel_dpll_mgr.h | 3 ++ > 3 files changed, 84 insertions(+), 33 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index e6fe85b..8ecaf18 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -12744,6 +12744,7 @@ static void intel_dump_pipe_config(struct intel_crtc > *crtc, > const char *context) > { > struct drm_device *dev = crtc->base.dev; > + struct drm_i915_private *dev_priv = to_i915(dev); > struct drm_plane *plane; > struct intel_plane *intel_plane; > struct intel_plane_state *state; > @@ -12805,39 +12806,7 @@ static void intel_dump_pipe_config(struct intel_crtc > *crtc, > DRM_DEBUG_KMS("ips: %i\n", pipe_config->ips_enabled); > DRM_DEBUG_KMS("double wide: %i\n", pipe_config->double_wide); > > - if (IS_BROXTON(dev)) { > - DRM_DEBUG_KMS("dpll_hw_state: ebb0: 0x%x, ebb4: 0x%x," > - "pll0: 0x%x, pll1: 0x%x, pll2: 0x%x, pll3: 0x%x, " > - "pll6: 0x%x, pll8: 0x%x, pll9: 0x%x, pll10: 0x%x, > pcsdw12: 0x%x\n", > - pipe_config->dpll_hw_state.ebb0, > - pipe_config->dpll_hw_state.ebb4, > - pipe_config->dpll_hw_state.pll0, > - pipe_config->dpll_hw_state.pll1, > - pipe_config->dpll_hw_state.pll2, > - pipe_config->dpll_hw_state.pll3, > - pipe_config->dpll_hw_state.pll6, > - pipe_config->dpll_hw_state.pll8, > - pipe_config->dpll_hw_state.pll9, > - pipe_config->dpll_hw_state.pll10, > - pipe_config->dpll_hw_state.pcsdw12); > - } else if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) { > - DRM_DEBUG_KMS("dpll_hw_state: " > - "ctrl1: 0x%x, cfgcr1: 0x%x, cfgcr2: 0x%x\n", > - pipe_config->dpll_hw_state.ctrl1, > - pipe_config->dpll_hw_state.cfgcr1, > - pipe_config->dpll_hw_state.cfgcr2); > - } else if (HAS_DDI(dev)) { > - DRM_DEBUG_KMS("dpll_hw_state: wrpll: 0x%x spll: 0x%x\n", > - pipe_config->dpll_hw_state.wrpll, > - pipe_config->dpll_hw_state.spll); > - } else { > - DRM_DEBUG_KMS("dpll_hw_state: dpll: 0x%x, dpll_md: 0x%x, " > - "fp0: 0x%x, fp1: 0x%x\n", > - pipe_config->dpll_hw_state.dpll, > - pipe_config->dpll_hw_state.dpll_md, > - pipe_config->dpll_hw_state.fp0, > - pipe_config->dpll_hw_state.fp1); > - } > + intel_dpll_dump_hw_state(dev_priv, &pipe_config->dpll_hw_state); > > DRM_DEBUG_KMS("planes on this crtc\n"); > list_for_each_entry(plane, &dev->mode_config.plane_list, head) { > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c > b/drivers/gpu/drm/i915/intel_dpll_mgr.c > index 8c4efa9..9b02d9c 100644 > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c > @@ -447,6 +447,17 @@ ibx_get_dpll(struct intel_crtc *crtc, struct > intel_crtc_state *crtc_state, > return pll; > } > > +static void ibx_dump_hw_state(struct drm_i915_private *dev_priv, > + struct intel_dpll_hw_state *hw_state) > +{ > + DRM_DEBUG_KMS("dpll_hw_state: dpll: 0x%x, dpll_md: 0x%x, " > + "fp0: 0x%x, fp1: 0x%x\n", > + hw_state->dpll, > + hw_state->dpll_md, > + hw_state->fp0, > + hw_state->fp1); > +} > + > static const struct intel_shared_dpll_funcs ibx_pch_dpll_funcs = { > .prepare = ibx_pch_dpll_prepare, > .enable = ibx_pch_dpll_enable, > @@ -833,6 +844,13 @@ hsw_get_dpll(struct intel_crtc *crtc, struct > intel_crtc_state *crtc_state, > return pll; > } > > +static void hsw_dump_hw_state(struct drm_i915_private *dev_priv, > + struct intel_dpll_hw_state *hw_state) > +{ > + DRM_DEBUG_KMS("dpll_hw_state: wrpll: 0x%x spll: 0x%x\n", > + hw_state->wrpll, hw_state->spll); > +} > + > static const struct int
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c
On Tue, Oct 04, 2016 at 03:32:15PM +0300, Ander Conselvan de Oliveira wrote: > The documentation for most of the non-static members and structs were > missing. Fix that. > > v2: Fix typos (Durga) > > v3: Rebase. > Fix make docs warnings. > Document more. > > Signed-off-by: Ander Conselvan de Oliveira > As mentioned in an earlier patch, I think we should also move intel_atomic_get_shared_dpll_state from intel_atomic.c into intel_dpll_mgr.c. Grouping functions by the data structures they touch makes imo much more sense, than grouping them by topic. That way all the dpll stuff is in one place. > --- > Documentation/gpu/i915.rst| 12 +++ > drivers/gpu/drm/i915/intel_dpll_mgr.c | 90 ++-- > drivers/gpu/drm/i915/intel_dpll_mgr.h | 155 > ++ > 3 files changed, 237 insertions(+), 20 deletions(-) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 87aaffc..c19e437 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -204,6 +204,18 @@ Video BIOS Table (VBT) > .. kernel-doc:: drivers/gpu/drm/i915/intel_vbt_defs.h > :internal: > > +Display PLLs > + > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c > + :doc: Display PLLs > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c > + :internal: > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.h > + :internal: > + > Memory Management and Command Submission > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c > b/drivers/gpu/drm/i915/intel_dpll_mgr.c > index 9446446..8c4efa9 100644 > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c > @@ -23,6 +23,25 @@ > > #include "intel_drv.h" > > +/** > + * DOC: Display PLLs > + * > + * Display PLLs used for driving outputs vary by platform. While some have > + * per-pipe or per-encoder dedicated PLLs, others allow the use of any PLL > + * from a pool. In the latter scenario, it is possible that multiple pipes > + * share a PLL if their configurations match. > + * > + * This file provides an abstraction over display PLLs. The function > + * intel_shared_dpll_init() initializes the PLLs for the given platform. The > + * users of a PLL are tracked and that tracking is integrated with the atomic > + * modest interface. During an atomic operation, a PLL can be requested for a > + * given crtc and encoder configuration by calling intel_get_shared_dpll() > and s/crtc/CRTC/ for consistency (abbreviations are all upercase), pls do that on the entire doc. > + * a previously used PLL can be released with intel_release_shared_dpll(). > + * Changes to the users are first staged in the atomic state, and then made > + * effective by calling intel_shared_dpll_swap_state() during the atomic > + * commit phase. > + */ > + > struct intel_shared_dpll * > skl_find_link_pll(struct drm_i915_private *dev_priv, int clock) > { > @@ -61,6 +80,14 @@ skl_find_link_pll(struct drm_i915_private *dev_priv, int > clock) > return pll; > } > > +/** > + * intel_get_shared_dpll_by_id - get a DPLL given its id > + * @dev_priv: i915 device instance > + * @id: pll id > + * > + * Returns: > + * A pointer to the DPLL with @id > + */ > struct intel_shared_dpll * > intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv, > enum intel_dpll_id id) > @@ -68,6 +95,14 @@ intel_get_shared_dpll_by_id(struct drm_i915_private > *dev_priv, > return &dev_priv->shared_dplls[id]; > } > > +/** > + * intel_get_shared_dpll_id - get the id of a DPLL > + * @dev_priv: i915 device instance > + * @pll: the DPLL > + * > + * Returns: > + * The id of @pll > + */ > enum intel_dpll_id > intel_get_shared_dpll_id(struct drm_i915_private *dev_priv, >struct intel_shared_dpll *pll) > @@ -96,6 +131,13 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv, > pll->name, onoff(state), onoff(cur_state)); > } > > +/** > + * intel_prepare_shared_dpll - call a dpll's prepare hook > + * @crtc: crtc which has a shared dpll > + * > + * This calls the PLL's prepare hook if it has one and if the PLL is not > + * already enabled. The prepare hook is platform specific. > + */ > void intel_prepare_shared_dpll(struct intel_crtc *crtc) > { > struct drm_device *dev = crtc->base.dev; > @@ -118,12 +160,10 @@ void intel_prepare_shared_dpll(struct intel_crtc *crtc) > } > > /** > - * intel_enable_shared_dpll - enable PCH PLL > - * @dev_priv: i915 private structure > - * @pipe: pipe PLL to enable > + * intel_enable_shared_dpll - enable a crtc's shared DPLL > + * @crtc: crtc which has a shared DPLL > * > - * The PCH PLL needs to be enabled before the PCH transcoder, since it > - * drives the transcoder clock. > + * Enable the shared DPLL used by @crtc. > */ > void intel_enable_shared_dpll(struct intel_crtc *crtc) > { > @@ -
Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values
Op 08-10-16 om 02:11 schreef Lyude: > Now that we've make skl_wm_levels make a little more sense, we can > remove all of the redundant wm information. Up until now we'd been > storing two copies of all of the skl watermarks: one being the > skl_pipe_wm structs, the other being the global wm struct in > drm_i915_private containing the raw register values. This is confusing > and problematic, since it means we're prone to accidentally letting the > two copies go out of sync. So, get rid of all of the functions > responsible for computing the register values and just use a single > helper, skl_write_wm_level(), to convert and write the new watermarks on > the fly. > > Changes since v1: > - Fixup skl_write_wm_level() > - Fixup skl_wm_level_from_reg_val() > - Don't forget to copy *active to intel_crtc->wm.active.skl > > Signed-off-by: Lyude > Reviewed-by: Maarten Lankhorst > Cc: Ville Syrjälä > Cc: Paulo Zanoni > --- > drivers/gpu/drm/i915/i915_drv.h | 2 - > drivers/gpu/drm/i915/intel_display.c | 14 ++- > drivers/gpu/drm/i915/intel_drv.h | 6 +- > drivers/gpu/drm/i915/intel_pm.c | 204 > --- > drivers/gpu/drm/i915/intel_sprite.c | 8 +- > 5 files changed, 90 insertions(+), 144 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 0287c93..76583b2 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation { > struct skl_wm_values { > unsigned dirty_pipes; > struct skl_ddb_allocation ddb; > - uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8]; > - uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES]; > }; > > struct skl_wm_level { > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index a71d05a..39400a0 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -3378,6 +3378,8 @@ static void skylake_update_primary_plane(struct > drm_plane *plane, > struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc); > struct drm_framebuffer *fb = plane_state->base.fb; > const struct skl_wm_values *wm = &dev_priv->wm.skl_results; > + const struct skl_plane_wm *p_wm = > + &crtc_state->wm.skl.optimal.planes[0]; > int pipe = intel_crtc->pipe; > u32 plane_ctl; > unsigned int rotation = plane_state->base.rotation; > @@ -3414,7 +3416,7 @@ static void skylake_update_primary_plane(struct > drm_plane *plane, > intel_crtc->adjusted_y = src_y; > > if (wm->dirty_pipes & drm_crtc_mask(&intel_crtc->base)) > - skl_write_plane_wm(intel_crtc, wm, 0); > + skl_write_plane_wm(intel_crtc, p_wm, &wm->ddb, 0); > > I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl); > I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x); > @@ -3448,6 +3450,8 @@ static void skylake_disable_primary_plane(struct > drm_plane *primary, > struct drm_device *dev = crtc->dev; > struct drm_i915_private *dev_priv = to_i915(dev); > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > + struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state); > + const struct skl_plane_wm *p_wm = &cstate->wm.skl.optimal.planes[0]; > int pipe = intel_crtc->pipe; > > /* > @@ -3455,7 +3459,8 @@ static void skylake_disable_primary_plane(struct > drm_plane *primary, >* plane's visiblity isn't actually changing neither is its watermarks. >*/ > if (!crtc->primary->state->visible) > - skl_write_plane_wm(intel_crtc, &dev_priv->wm.skl_results, 0); > + skl_write_plane_wm(intel_crtc, p_wm, > +&dev_priv->wm.skl_results.ddb, 0); > > I915_WRITE(PLANE_CTL(pipe, 0), 0); > I915_WRITE(PLANE_SURF(pipe, 0), 0); > @@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct drm_crtc > *crtc, u32 base, > struct drm_device *dev = crtc->dev; > struct drm_i915_private *dev_priv = to_i915(dev); > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > + struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state); > const struct skl_wm_values *wm = &dev_priv->wm.skl_results; > + const struct skl_plane_wm *p_wm = > + &cstate->wm.skl.optimal.planes[PLANE_CURSOR]; > int pipe = intel_crtc->pipe; > uint32_t cntl = 0; > > if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes & drm_crtc_mask(crtc)) > - skl_write_cursor_wm(intel_crtc, wm); > + skl_write_cursor_wm(intel_crtc, p_wm, &wm->ddb); > > if (plane_state && plane_state->base.visible) { > cntl = MCURSOR_GAMMA_ENABLE; > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index d684f4f..958dc72 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Rename intel_shared_dpll->mode_set() to prepare()
On Tue, Oct 04, 2016 at 03:32:14PM +0300, Ander Conselvan de Oliveira wrote: > The hook is called from intel_prepare_shared_dpll(). The name doesn't > make sense after all the changes to modeset code. So just call it > prepare. > > Signed-off-by: Ander Conselvan de Oliveira > > Reviewed-by: Durgadoss R Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 8 > drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c > b/drivers/gpu/drm/i915/intel_dpll_mgr.c > index c88fc07..9446446 100644 > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c > @@ -112,7 +112,7 @@ void intel_prepare_shared_dpll(struct intel_crtc *crtc) > WARN_ON(pll->on); > assert_shared_dpll_disabled(dev_priv, pll); > > - pll->funcs.mode_set(dev_priv, pll); > + pll->funcs.prepare(dev_priv, pll); > } > mutex_unlock(&dev_priv->dpll_lock); > } > @@ -302,8 +302,8 @@ static bool ibx_pch_dpll_get_hw_state(struct > drm_i915_private *dev_priv, > return val & DPLL_VCO_ENABLE; > } > > -static void ibx_pch_dpll_mode_set(struct drm_i915_private *dev_priv, > - struct intel_shared_dpll *pll) > +static void ibx_pch_dpll_prepare(struct drm_i915_private *dev_priv, > + struct intel_shared_dpll *pll) > { > I915_WRITE(PCH_FP0(pll->id), pll->state.hw_state.fp0); > I915_WRITE(PCH_FP1(pll->id), pll->state.hw_state.fp1); > @@ -392,7 +392,7 @@ ibx_get_dpll(struct intel_crtc *crtc, struct > intel_crtc_state *crtc_state, > } > > static const struct intel_shared_dpll_funcs ibx_pch_dpll_funcs = { > - .mode_set = ibx_pch_dpll_mode_set, > + .prepare = ibx_pch_dpll_prepare, > .enable = ibx_pch_dpll_enable, > .disable = ibx_pch_dpll_disable, > .get_hw_state = ibx_pch_dpll_get_hw_state, > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h > b/drivers/gpu/drm/i915/intel_dpll_mgr.h > index 6e3a0f1..9a7db65 100644 > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h > @@ -101,7 +101,7 @@ struct intel_shared_dpll_state { > struct intel_shared_dpll_funcs { > /* The mode_set hook is optional and should be used together with the >* intel_prepare_shared_dpll function. */ > - void (*mode_set)(struct drm_i915_private *dev_priv, > + void (*prepare)(struct drm_i915_private *dev_priv, >struct intel_shared_dpll *pll); > void (*enable)(struct drm_i915_private *dev_priv, > struct intel_shared_dpll *pll); > -- > 2.5.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation 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 3/7] drm/i915: Rename intel_shared_dpll_config to intel_shared_dpll_state
On Tue, Oct 04, 2016 at 03:32:13PM +0300, Ander Conselvan de Oliveira wrote: > Struct intel_shared_dpll_config is used to hold the state of the DPLL in > the "atomic" sense, so call it state like everything else atomic. > > Signed-off-by: Ander Conselvan de Oliveira > Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/i915_debugfs.c | 12 +++ > drivers/gpu/drm/i915/intel_atomic.c | 6 ++-- > drivers/gpu/drm/i915/intel_ddi.c | 10 +++--- > drivers/gpu/drm/i915/intel_display.c | 22 ++-- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 68 > +-- > drivers/gpu/drm/i915/intel_dpll_mgr.h | 4 +-- > drivers/gpu/drm/i915/intel_drv.h | 4 +-- > 7 files changed, 63 insertions(+), 63 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index da71413..12b97af 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -3229,14 +3229,14 @@ static int i915_shared_dplls_info(struct seq_file *m, > void *unused) > > seq_printf(m, "DPLL%i: %s, id: %i\n", i, pll->name, pll->id); > seq_printf(m, " crtc_mask: 0x%08x, active: 0x%x, on: %s\n", > -pll->config.crtc_mask, pll->active_mask, > yesno(pll->on)); > +pll->state.crtc_mask, pll->active_mask, > yesno(pll->on)); > seq_printf(m, " tracked hardware state:\n"); > - seq_printf(m, " dpll:0x%08x\n", pll->config.hw_state.dpll); > + seq_printf(m, " dpll:0x%08x\n", pll->state.hw_state.dpll); > seq_printf(m, " dpll_md: 0x%08x\n", > -pll->config.hw_state.dpll_md); > - seq_printf(m, " fp0: 0x%08x\n", pll->config.hw_state.fp0); > - seq_printf(m, " fp1: 0x%08x\n", pll->config.hw_state.fp1); > - seq_printf(m, " wrpll: 0x%08x\n", pll->config.hw_state.wrpll); > +pll->state.hw_state.dpll_md); > + seq_printf(m, " fp0: 0x%08x\n", pll->state.hw_state.fp0); > + seq_printf(m, " fp1: 0x%08x\n", pll->state.hw_state.fp1); > + seq_printf(m, " wrpll: 0x%08x\n", pll->state.hw_state.wrpll); > } > drm_modeset_unlock_all(dev); > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c > b/drivers/gpu/drm/i915/intel_atomic.c > index c5a1667..fa6dc43 100644 > --- a/drivers/gpu/drm/i915/intel_atomic.c > +++ b/drivers/gpu/drm/i915/intel_atomic.c > @@ -267,7 +267,7 @@ int intel_atomic_setup_scalers(struct drm_device *dev, > > static void > intel_atomic_duplicate_dpll_state(struct drm_i915_private *dev_priv, > - struct intel_shared_dpll_config *shared_dpll) > + struct intel_shared_dpll_state *shared_dpll) > { > enum intel_dpll_id i; > > @@ -275,11 +275,11 @@ intel_atomic_duplicate_dpll_state(struct > drm_i915_private *dev_priv, > for (i = 0; i < dev_priv->num_shared_dpll; i++) { > struct intel_shared_dpll *pll = &dev_priv->shared_dplls[i]; > > - shared_dpll[i] = pll->config; > + shared_dpll[i] = pll->state; > } > } > > -struct intel_shared_dpll_config * > +struct intel_shared_dpll_state * > intel_atomic_get_shared_dpll_state(struct drm_atomic_state *s) > { > struct intel_atomic_state *state = to_intel_atomic_state(s); > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index 35f0b7c..4077205 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -992,7 +992,7 @@ static int bxt_calc_pll_link(struct drm_i915_private > *dev_priv, > return 0; > > pll = &dev_priv->shared_dplls[dpll]; > - state = &pll->config.hw_state; > + state = &pll->state.hw_state; > > clock.m1 = 2; > clock.m2 = (state->pll0 & PORT_PLL_M2_MASK) << 22; > @@ -2401,7 +2401,7 @@ intel_ddi_get_link_dpll(struct intel_dp *intel_dp, int > clock) > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); > struct intel_shared_dpll *pll = NULL; > - struct intel_shared_dpll_config tmp_pll_config; > + struct intel_shared_dpll_state tmp_pll_state; > enum intel_dpll_id dpll_id; > > if (IS_BROXTON(dev_priv)) { > @@ -2417,11 +2417,11 @@ intel_ddi_get_link_dpll(struct intel_dp *intel_dp, > int clock) > pll->active_mask); > return NULL; > } > - tmp_pll_config = pll->config; > + tmp_pll_state = pll->state; > if (!bxt_ddi_dp_set_dpll_hw_state(clock, > - &pll->config.hw_state)) { > + &pll->state.hw_state)) { > DRM_ERROR("Could not setup DPL
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Rename intel_shared_dpll_commit() to _swap_state()
On Tue, Oct 04, 2016 at 03:32:12PM +0300, Ander Conselvan de Oliveira wrote: > The function intel_shared_dpll_commit() performs the equivalent of > drm_atomic_helper_swap_state() for the shared dpll state, which is not > handled by the helpers. So rename it for consistency. > > v2: Fix typo in the commit message. (Durga) > v3: Rebase. > Signed-off-by: Ander Conselvan de Oliveira > > Reviewed-by: Durgadoss R Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +- > drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 28d9d3e..b8bfde0 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -14530,7 +14530,7 @@ static int intel_atomic_commit(struct drm_device *dev, > drm_atomic_helper_swap_state(state, true); > dev_priv->wm.distrust_bios_wm = false; > dev_priv->wm.skl_results = intel_state->wm_results; > - intel_shared_dpll_commit(state); > + intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); > > if (nonblock) > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c > b/drivers/gpu/drm/i915/intel_dpll_mgr.c > index f1b3feb..15bf462 100644 > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c > @@ -266,7 +266,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll *pll, > shared_dpll[pll->id].crtc_mask |= 1 << crtc->pipe; > } > > -void intel_shared_dpll_commit(struct drm_atomic_state *state) > +void intel_shared_dpll_swap_state(struct drm_atomic_state *state) > { > struct drm_i915_private *dev_priv = to_i915(state->dev); > struct intel_shared_dpll_config *shared_dpll; > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h > b/drivers/gpu/drm/i915/intel_dpll_mgr.h > index 99a82c9..06d61c5 100644 > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h > @@ -152,7 +152,7 @@ void intel_release_shared_dpll(struct intel_shared_dpll > *dpll, > void intel_prepare_shared_dpll(struct intel_crtc *crtc); > void intel_enable_shared_dpll(struct intel_crtc *crtc); > void intel_disable_shared_dpll(struct intel_crtc *crtc); > -void intel_shared_dpll_commit(struct drm_atomic_state *state); > +void intel_shared_dpll_swap_state(struct drm_atomic_state *state); > void intel_shared_dpll_init(struct drm_device *dev); > > /* BXT dpll related functions */ > -- > 2.5.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation 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 1/7] drm/i915: Introduce intel_release_shared_dpll()
On Tue, Oct 04, 2016 at 03:32:11PM +0300, Ander Conselvan de Oliveira wrote: > While the details of getting a shared dpll are wrapped by > intel_get_shared_dpll(), the release was still hand rolled into the > modeset code. Fix that by creating an entry point for releasing the > pll and move that code there. > > v2: Take old_dpll from crtc->state instead of crtc_state. (CI) > Signed-off-by: Ander Conselvan de Oliveira > > --- > drivers/gpu/drm/i915/intel_display.c | 6 + > drivers/gpu/drm/i915/intel_dpll_mgr.c | 41 > +++ > drivers/gpu/drm/i915/intel_dpll_mgr.h | 11 +++--- > 3 files changed, 22 insertions(+), 36 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index a366656..28d9d3e 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -13768,7 +13768,6 @@ static void intel_modeset_clear_plls(struct > drm_atomic_state *state) > { > struct drm_device *dev = state->dev; > struct drm_i915_private *dev_priv = to_i915(dev); > - struct intel_shared_dpll_config *shared_dpll = NULL; > struct drm_crtc *crtc; > struct drm_crtc_state *crtc_state; > int i; > @@ -13789,10 +13788,7 @@ static void intel_modeset_clear_plls(struct > drm_atomic_state *state) > if (!old_dpll) > continue; > > - if (!shared_dpll) > - shared_dpll = intel_atomic_get_shared_dpll_state(state); > - > - intel_shared_dpll_config_put(shared_dpll, old_dpll, intel_crtc); > + intel_release_shared_dpll(old_dpll, intel_crtc, state); > } > } > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c > b/drivers/gpu/drm/i915/intel_dpll_mgr.c > index 1c59ca5..f1b3feb 100644 > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c > @@ -79,28 +79,6 @@ intel_get_shared_dpll_id(struct drm_i915_private *dev_priv, > return (enum intel_dpll_id) (pll - dev_priv->shared_dplls); > } > > -void > -intel_shared_dpll_config_get(struct intel_shared_dpll_config *config, > - struct intel_shared_dpll *pll, > - struct intel_crtc *crtc) > -{ > - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); > - enum intel_dpll_id id = intel_get_shared_dpll_id(dev_priv, pll); > - > - config[id].crtc_mask |= 1 << crtc->pipe; > -} > - > -void > -intel_shared_dpll_config_put(struct intel_shared_dpll_config *config, > - struct intel_shared_dpll *pll, > - struct intel_crtc *crtc) > -{ > - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); > - enum intel_dpll_id id = intel_get_shared_dpll_id(dev_priv, pll); > - > - config[id].crtc_mask &= ~(1 << crtc->pipe); > -} > - > /* For ILK+ */ > void assert_shared_dpll(struct drm_i915_private *dev_priv, > struct intel_shared_dpll *pll, > @@ -285,7 +263,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll *pll, > DRM_DEBUG_DRIVER("using %s for pipe %c\n", pll->name, >pipe_name(crtc->pipe)); > > - intel_shared_dpll_config_get(shared_dpll, pll, crtc); > + shared_dpll[pll->id].crtc_mask |= 1 << crtc->pipe; > } > > void intel_shared_dpll_commit(struct drm_atomic_state *state) > @@ -1900,3 +1878,20 @@ intel_get_shared_dpll(struct intel_crtc *crtc, > > return dpll_mgr->get_dpll(crtc, crtc_state, encoder); > } > + > +/** > + * intel_release_shared_dpll - end use of DPLL by CRTC in atomic state > + * @dpll: dpll in use by @crtc > + * @crtc: crtc > + * @state: atomic state > + * > + */ > +void intel_release_shared_dpll(struct intel_shared_dpll *dpll, > +struct intel_crtc *crtc, > +struct drm_atomic_state *state) > +{ > + struct intel_shared_dpll_config *shared_dpll_config; > + > + shared_dpll_config = intel_atomic_get_shared_dpll_state(state); I wonder whether we shouldn't move intel_atomic_get_shared_dpll_state into intel_dpll_mgr.c too. That would further reduce the interfaces exported from intel_dpll_mgr.[hc]. On this patch: Reviewed-by: Daniel Vetter > + shared_dpll_config[dpll->id].crtc_mask &= ~(1 << crtc->pipe); > +} > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h > b/drivers/gpu/drm/i915/intel_dpll_mgr.h > index f438535..99a82c9 100644 > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h > @@ -138,14 +138,6 @@ intel_get_shared_dpll_by_id(struct drm_i915_private > *dev_priv, > enum intel_dpll_id > intel_get_shared_dpll_id(struct drm_i915_private *dev_priv, >struct intel_shared_dpll *pll); > -void > -intel_shared_dpll_config_get(struct intel_shared_dpll_config *config, > - struct intel_shared_dpll *pll, > - struct
Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatched INIT power domain disabling during suspend
On to, 2016-10-13 at 15:43 +0300, Ville Syrjälä wrote: > On Thu, Oct 13, 2016 at 02:34:06PM +0300, Imre Deak wrote: > > Currently the display INIT power domain disabling/enabling happens in a > > mismatched way in the suspend/resume_early hooks respectively. This can > > leave display power wells incorrectly disabled in the resume hook if the > > suspend sequence is aborted for some reason resulting in the > > suspend/resume hooks getting called but the suspend_late/resume_early > > hooks being skipped. In particular this change fixes "Unclaimed read > > from register 0x1e1204" on BYT/BSW triggered from i915_drm_resume()-> > > intel_pps_unlock_regs_wa() when suspending with /sys/power/pm_test set > > to devices. > > > > Cc: Ville Syrjälä > > Cc: David Weinehall > > Signed-off-by: Imre Deak > > --- > > drivers/gpu/drm/i915/i915_drv.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c > > index e9b3bfc..5adabac 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -1430,8 +1430,6 @@ static int i915_drm_suspend(struct drm_device *dev) > > > > dev_priv->suspend_count++; > > > > - intel_display_set_init_power(dev_priv, false); > > - > > intel_csr_ucode_suspend(dev_priv); > > > > out: > > @@ -1449,6 +1447,8 @@ static int i915_drm_suspend_late(struct drm_device > > *dev, bool hibernation) > > > > disable_rpm_wakeref_asserts(dev_priv); > > > > + intel_display_set_init_power(dev_priv, false); > > + > > Makes sense in most cases. > Reviewed-by: Ville Syrjälä > > > fw_csr = !IS_BROXTON(dev_priv) && > > suspend_to_idle(dev_priv) && dev_priv->csr.dmc_payload; > > However this part is quite confusing. We do the init_power_put > unconditionally, but the init_power_get is done from the init_hw() > which is conditional on this supend_to_idle special casing. So it seems > quite assymmetrical, and I can no longer claim to understand it. Yep, that's a problem of its own for the suspend-to-idle case, enabling the INIT domain should be also unconditional and happen from this function. I suppose this happened to work so far since it only applies to SKL where nothing depended on the INIT domain, everything takes its own domain ref. Will look into fixing this. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests
On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote: > While at it, make debugfs_path point at the debugfs root, not > dri. This'll be handy in future work. > > Signed-off-by: Jani Nikula > --- > tests/drm_lib.sh | 16 ++-- > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh > index 113da4c7d645..87e3ad0ab547 100755 > --- a/tests/drm_lib.sh > +++ b/tests/drm_lib.sh > @@ -41,18 +41,22 @@ do_or_die() { > $@ > /dev/null 2>&1 || (echo "FAIL: $@ ($?)" && exit $IGT_EXIT_FAILURE) > } > > -if [ -d /debug/dri ] ; then > - debugfs_path=/debug/dri > +if [ -d /sys/kernel/debug ]; then > + debugfs_path=/sys/kernel/debug > +elif [ -d /debug ]; then > + debugfs_path=/debug > +else > + skip "debugfs not found" > fi > > -if [ -d /sys/kernel/debug/dri ] ; then > - debugfs_path=/sys/kernel/debug/dri > +if [ ! -d $debugfs_path/dri ]; then > + skip "dri debugfs not found" > fi > > i915_dfs_path=x > for minor in `seq 0 16`; do > - if [ -f $debugfs_path/$minor/i915_error_state ] ; then > - i915_dfs_path=$debugfs_path/$minor > + if [ -f $debugfs_path/dri/$minor/i915_error_state ] ; then > + i915_dfs_path=$debugfs_path/dri/$minor Thinking of how to wean ourselves off i915_error_state; how about if [ grep -s i915 $debugfs_path/dri/$minor/name ]; then ? -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] kms_atomic : Added subtest for Single Pipe DBUF validation
On Tue, Oct 04, 2016 at 10:17:58AM +0530, meghanelogal wrote: > Existing DDB algorithm divide the DDB wrt data rate, > hence the planes with the less height but same width > will be allocated less blocks and watermark are based > on width which requires more DDB. With this data the flip > may fail. > > In new DDB algorithm, the DDB is divided based on > watermark requirement. > > In this subtest, dividing the htotal/200 will allocate > ~2-4 blocks out of total(512/896), flip may fail with the > exisiting algorithm.But with the new algorithm it will pass. > > Signed-off-by: Megha Nelogal Please note that igt can be run on _any_ linux driver. If you are testing for such a specific case like this one here, you definitely need to have very specific platform checks in place, using igt_require. But tbh I'm not sure this is all that useful -Daniel > --- > tests/kms_atomic.c | 77 > ++ > 1 file changed, 77 insertions(+) > > diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c > index f27ee46..ff25644 100644 > --- a/tests/kms_atomic.c > +++ b/tests/kms_atomic.c > @@ -1280,6 +1280,60 @@ static void atomic_invalid_params(struct > kms_atomic_crtc_state *crtc, > do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, &ioc, EFAULT); > } > > +static void validate_dbuf(struct kms_atomic_crtc_state *crtc, > + struct kms_atomic_plane_state **plane_array, > + int plane_count) > +{ > + int i; > + struct kms_atomic_desc *desc = crtc->state->desc; > + > + /* for active crtc do modeset on the native resolution */ > + drmModeAtomicReq *req = drmModeAtomicAlloc(); > + struct drm_mode_modeinfo *mode = crtc->mode.data; > + struct kms_atomic_plane_state plane; > + struct igt_fb fb; > + > + crtc_populate_req(crtc, req); > + > + /* Add plane data to the structure...*/ > + uint32_t crtc_x = 0; > + uint32_t crtc_y = 0; > + > + for (i = 0; i < plane_count; i++) { > + plane = *plane_array[i]; > + uint32_t format = plane_get_igt_format(&plane); > + > + igt_require(format != 0); > + plane.src_x = 0; > + plane.src_y = 0; > + plane.src_w = (mode->hdisplay / (1)) << 16; > + plane.crtc_x = crtc_x; > + plane.crtc_y = crtc_y; > + plane.crtc_w = (mode->hdisplay) / (1); > + plane.crtc_h = (mode->vdisplay) / (i + 1); > + > + plane.crtc_id = crtc->obj; > + > + if (i%2 == 0) { > + plane.src_h = (mode->vdisplay / (1)) << 16; > + plane.crtc_h = (mode->vdisplay) / (1); > + } > + > + if (i%2 == 1) { > + plane.src_h = ceil((mode->vdisplay / 200) << 16); > + plane.crtc_h = ceil((mode->vdisplay / 200)); > + } > + > + plane.fb_id = igt_create_fb(plane.state->desc->fd, > + plane.crtc_w, plane.crtc_h, > + format, I915_TILING_NONE, &fb); > + plane_populate_req(&plane, req); > + } > + do_atomic_commit(desc->fd, req, ATOMIC_RELAX_NONE); > + drmModeAtomicFree(req); > +} > + > + > igt_main > { > struct kms_atomic_desc desc; > @@ -1373,6 +1427,29 @@ igt_main > atomic_state_free(scratch); > } > > + igt_subtest("validate_dbuf") { > + struct kms_atomic_state *scratch = atomic_state_dup(current); > + struct kms_atomic_crtc_state *crtc = find_crtc(scratch, true); > + struct kms_atomic_plane_state *plane; > + struct kms_atomic_connector_state *connector = > + find_connector(scratch, crtc); > + struct kms_atomic_plane_state **plane_array = NULL; > + /* Enabling Two planes */ > + plane_array = calloc(2, sizeof(struct kms_atomic_plane_state > *)); > + int plane_count = 0; > + > + igt_require(crtc); > + plane = find_plane(scratch, PLANE_TYPE_PRIMARY, crtc); > + igt_require(plane); > + plane_array[plane_count] = plane; plane_count++; > + plane = find_plane(scratch, PLANE_TYPE_OVERLAY, crtc); > + igt_require(plane); > + plane_array[plane_count] = plane; plane_count++; > + igt_require(connector); > + validate_dbuf(crtc, plane_array, plane_count); > + atomic_state_free(scratch); > + } > + > atomic_state_free(current); > > igt_fixture > -- > 1.9.1 > -- Daniel Vetter Software Engineer, Intel Corporation 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] drm/i915: Unalias obj->phys_handle and obj->userptr
On Mon, Oct 03, 2016 at 10:18:03AM +0300, Joonas Lahtinen wrote: > On pe, 2016-09-30 at 18:31 +0100, Chris Wilson wrote: > > We use obj->phys_handle to choose the pread/pwrite path, but as > > obj->phys_handle is a union with obj->userptr, we then mistakenly use > > the phys_handle path for userptr objects within pread/pwrite. > > > > Testcase: igt/gem_userptr_blits/forbidden-operations > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519 > > Signed-off-by: Chris Wilson > > Cc: sta...@vger.kernel.org > > Reviewed-by: Joonas Lahtinen Commmented already on irc, but I totally panicked about this one. I think we need an ops->pwrite. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 0/8] HuC Loading Patches
On Thu, Sep 29, 2016 at 11:03:57AM -0700, Anusha Srivatsa wrote: > These patches add HuC loading support. The userspace > patches that check for a fully loaded HuC firmware and use > it can be found at: > https://lists.freedesktop.org/archives/libva/2016-September/004554.html > https://lists.freedesktop.org/archives/libva/2016-September/004555.html > > Peter Antoine (8): > drm/i915/guc: Make the GuC fw loading helper functions general > drm/i915/huc: Unified css_header struct for GuC and HuC > drm/i915/huc: Add HuC fw loading support > drm/i915/huc: Add debugfs for HuC loading status check > drm/i915/huc: Support HuC authentication > drm/i915/huc: Add BXT HuC Loading Support > drm/i915/get_params: Add GuC status to getparams > drm/i915/get_params: Add HuC status to getparams So trouble with these is that both original authors (all of them) and reviewers left intel. Which means we don't have anyone anymore who understands this, and a big part of review is making sure that in the end at least two people (author+reviewer) really understand the patches in full detail. In short we need to restart the review process here again before merging :( -Daniel > > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/i915_debugfs.c| 43 - > drivers/gpu/drm/i915/i915_drv.c| 11 ++ > drivers/gpu/drm/i915/i915_drv.h| 3 + > drivers/gpu/drm/i915/i915_guc_reg.h| 3 + > drivers/gpu/drm/i915/i915_guc_submission.c | 69 ++- > drivers/gpu/drm/i915/intel_guc.h | 46 +++-- > drivers/gpu/drm/i915/intel_guc_fwif.h | 17 +- > drivers/gpu/drm/i915/intel_guc_loader.c| 215 - > drivers/gpu/drm/i915/intel_huc.h | 44 + > drivers/gpu/drm/i915/intel_huc_loader.c| 289 > + > include/uapi/drm/i915_drm.h| 2 + > 12 files changed, 623 insertions(+), 120 deletions(-) > create mode 100644 drivers/gpu/drm/i915/intel_huc.h > create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c > > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx