Re: [Intel-gfx] [PATCH v2] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams
Are we required to add reference to intel_guc.c and intel_wopcm.c in Documentation/gpu/i915.rst? On 3/15/2018 12:14 AM, Jackie Li wrote: GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams to be generated correctly, and it also corrects some errors in the diagram description. v2: - Fixed errors in diagram description Signed-off-by: Jackie Li Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_guc.c | 52 -- drivers/gpu/drm/i915/intel_wopcm.c | 44 +--- 2 files changed, 50 insertions(+), 46 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 3eb516e..6a4f36e 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -495,35 +495,37 @@ int intel_guc_resume(struct intel_guc *guc) /** * DOC: GuC Address Space * - * The layout of GuC address space is shown as below: + * The layout of GuC address space is shown below: * - *+==> ++ <== GUC_GGTT_TOP - *^|| - *||| - *||DRAM| - *|| Memory | - *||| - * GuC || - * Address +> ++ <== WOPCM Top - * Space ^ | HW contexts RSVD | - *| | |WOPCM | - *| | +==> ++ <== GuC WOPCM Top - *|GuC^|| - *|GGTT ||| - *|Pin GuC |GuC | - *|Bias WOPCM | WOPCM| - *| |Size || - *| | ||| - *v v v|| - *+=+=+==> ++ <== GuC WOPCM Base - * | Non-GuC WOPCM| - * | (HuC/Reserved) | - * ++ <== WOPCM Base + * :: + * + * +==> ++ <== GUC_GGTT_TOP + * ^|| + * ||| + * ||DRAM| + * || Memory | + * ||| + *GuC || + * Address +> ++ <== WOPCM Top + * Space ^ | HW contexts RSVD | + * | | |WOPCM | + * | | +==> ++ <== GuC WOPCM Top + * |GuC^|| + * |GGTT ||| + * |Pin GuC |GuC | + * |Bias WOPCM | WOPCM| + * | |Size || + * | | ||| + * v v v|| + * +=+=+==> ++ <== GuC WOPCM Base + * | Non-GuC WOPCM| + * | (HuC/Reserved) | + * ++ <== WOPCM Base * * The lower part [0, GuC ggtt_pin_bias) is mapped to WOPCM which consists of * GuC WOPCM and WOPCM reserved for other usage (e.g.RC6 context). The value of - * the GuC ggtt_pin_bias is determined by the actually GuC WOPCM size which is - * set in GUC_WOPCM_SIZE register. + * the GuC ggtt_pin_bias is determined by the GuC WOPCM size which is set in + * GUC_WOPCM_SIZE register. */ /** diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c index 4117886..74bf76f 100644 --- a/drivers/gpu/drm/i915/intel_wopcm.c +++ b/drivers/gpu/drm/i915/intel_wopcm.c @@ -11,28 +11,30 @@ * DOC: WOPCM Layout * * The layout of the WOPCM will be fixed after writing to GuC WOPCM size and - * offset registers whose are calculated are determined by size of HuC/GuC - * firmware size and set of hw requirements/restrictions as shown below: + * offset registers whose values are calculated and determined by HuC/GuC + * firmware size and set of hardware requirements/restrictions as shown below: * - * +=> ++ <== WOPCM Top - * ^ | HW contexts RSVD | - * | +===> ++ <== GuC WOPCM Top - * | ^ || - * | | || - * | | || - * |GuC|| - * | WOPCM || - * |Size ++ - * WOPCM | |GuC FW RSVD | - * | | ++ - *
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
== Series Details == Series: series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads URL : https://patchwork.freedesktop.org/series/39992/ State : success == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-shrfb-draw-render: fail -> PASS (shard-apl) Known issues: Test kms_flip: Subgroup 2x-plain-flip-ts-check: pass -> FAIL (shard-hsw) fdo#100368 Subgroup flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 shard-apltotal:3406 pass:1801 dwarn:1 dfail:0 fail:7 skip:1595 time:12677s shard-hswtotal:3441 pass:1766 dwarn:1 dfail:0 fail:2 skip:1671 time:11795s shard-snbtotal:3441 pass:1357 dwarn:1 dfail:0 fail:2 skip:2081 time:7162s Blacklisted hosts: shard-kbltotal:3366 pass:1899 dwarn:2 dfail:0 fail:9 skip:1454 time:9302s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8356/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
sound/pci/hda/hda_intel.c
between commits:
1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
40088dc4e1ea ("ALSA: hda - Revert power_save option default value")
from Linus' tree and commit:
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc sound/pci/hda/hda_intel.c
index d5017adf9feb,ec4e6b829ee2..
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@@ -2219,8 -2201,8 +2223,9 @@@ static int azx_probe_continue(struct az
struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
struct hdac_bus *bus = azx_bus(chip);
struct pci_dev *pci = chip->pci;
+ struct hda_codec *codec;
int dev = chip->dev_index;
+ int val;
int err;
hda->probe_continued = 1;
@@@ -2302,21 -2284,16 +2307,30 @@@
chip->running = 1;
azx_add_card_list(chip);
+ val = power_save;
+#ifdef CONFIG_PM
+ if (pm_blacklist) {
+ const struct snd_pci_quirk *q;
+
+ q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
+ if (q && val) {
+ dev_info(chip->card->dev, "device %04x:%04x is on the
power_save blacklist, forcing power_save to 0\n",
+ q->subvendor, q->subdevice);
+ val = 0;
+ }
+ }
+#endif /* CONFIG_PM */
++
+ /*
+* The discrete GPU cannot power down unless the HDA controller runtime
+* suspends, so activate runtime PM on codecs even if power_save == 0.
+*/
+ if (use_vga_switcheroo(hda))
+ list_for_each_codec(codec, &chip->bus)
+ codec->auto_runtime_pm = 1;
+
- snd_hda_set_power_save(&chip->bus, power_save * 1000);
+ snd_hda_set_power_save(&chip->bus, val * 1000);
- if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
+ if (azx_has_pm_runtime(chip))
pm_runtime_put_autosuspend(&pci->dev);
out_free:
pgphpwx_Ysp4R.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-tip:drm-tip 15/1373] arch/frv/include/asm/pgalloc.h:48:2: error: implicit declaration of function 'pgtable_page_dtor'; did you mean 'pgdat_page_nr'?
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 178cfb9373cc2bdfcb6ca73e03369d2c37cc4b58
commit: d8d019ccffb838bb0dd98e583b5c25ccc0bc6ece [15/1373] drm/amdgpu: Add KFD
eviction fence
config: frv-allyesconfig (attached as .config)
compiler: frv-linux-gcc (GCC) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d8d019ccffb838bb0dd98e583b5c25ccc0bc6ece
# save the attached .config to linux build tree
make.cross ARCH=frv
All errors (new ones prefixed by >>):
In file included from arch/frv/include/asm/mmu_context.h:17:0,
from include/linux/mmu_context.h:5,
from drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd.h:29,
from drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_fence.c:30:
arch/frv/include/asm/pgalloc.h: In function 'pte_free':
>> arch/frv/include/asm/pgalloc.h:48:2: error: implicit declaration of function
>> 'pgtable_page_dtor'; did you mean 'pgdat_page_nr'?
>> [-Werror=implicit-function-declaration]
pgtable_page_dtor(pte);
^
pgdat_page_nr
cc1: some warnings being treated as errors
vim +48 arch/frv/include/asm/pgalloc.h
^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16 45
2f569afd include/asm-frv/pgalloc.h Martin Schwidefsky 2008-02-08 46 static
inline void pte_free(struct mm_struct *mm, pgtable_t pte)
^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16 47 {
2f569afd include/asm-frv/pgalloc.h Martin Schwidefsky 2008-02-08 @48
pgtable_page_dtor(pte);
^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16 49
__free_page(pte);
^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16 50 }
^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16 51
:: The code at line 48 was first introduced by commit
:: 2f569afd9ced9ebec9a6eb3dbf6f83429be0a7b4 CONFIG_HIGHPTE vs. sub-page
page tables.
:: TO: Martin Schwidefsky
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12
> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Wednesday, March 14, 2018 9:06 PM > To: Srinivas, Vidya > Cc: Maarten Lankhorst ; intel- > g...@lists.freedesktop.org; Syrjala, Ville ; > Lankhorst, > Maarten > Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale > for NV12 > > On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote: > > > > > > > -Original Message- > > > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > > > Sent: Wednesday, March 14, 2018 4:03 PM > > > To: Srinivas, Vidya ; intel- > > > g...@lists.freedesktop.org > > > Cc: Syrjala, Ville ; Lankhorst, Maarten > > > > > > Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler > > > max scale for NV12 > > > > > > Op 14-03-18 om 11:31 schreef Srinivas, Vidya: > > > > > > > >> -Original Message- > > > >> From: Maarten Lankhorst > > > >> [mailto:maarten.lankho...@linux.intel.com] > > > >> Sent: Wednesday, March 14, 2018 3:55 PM > > > >> To: Srinivas, Vidya ; intel- > > > >> g...@lists.freedesktop.org > > > >> Cc: Syrjala, Ville ; Lankhorst, Maarten > > > >> > > > >> Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale > > > >> scaler max scale for NV12 > > > >> > > > >> Op 14-03-18 om 10:52 schreef Maarten Lankhorst: > > > >>> Op 09-03-18 om 09:48 schreef Vidya Srinivas: > > > From: Chandra Konduru > > > > > > This patch updates scaler max limit support for NV12 > > > > > > v2: Rebased (me) > > > > > > v3: Rebased (me) > > > > > > v4: Missed the Tested-by/Reviewed-by in the previous series > > > Adding the same to commit message in this version. > > > > > > v5: Addressed review comments from Ville and rebased > > > - calculation of max_scale to be made less convoluted by > > > splitting it up a bit > > > - Indentation errors to be fixed in the series > > > > > > v6: Rebased (me) > > > Fixed review comments from Paauwe, Bob J Previous version, > > > where a split of calculation was done, was wrong. Fixed that issue > here. > > > > > > v7: Rebased (me) > > > > > > v8: Rebased (me) > > > > > > v9: Rebased (me) > > > > > > v10: Rebased (me) > > > > > > v11: Addressed review comments from Shashank Sharma > Alignment > > > >> issues > > > fixed. > > > When call to skl_update_scaler is made, 0 was being sent > > > instead of pixel_format. > > > When crtc update scaler is called, we dont have the fb to > > > derive the pixel format. Added the function parameter bool > > > plane_scaler_check to account for this. > > > > > > v12: Fixed failure in IGT debugfs_test. > > > fb is NULL in skl_update_scaler_plane Due to this, accessing > > > fb->format caused failure. > > > Patch checks fb before using. > > > > > > v13: In the previous version there was a flaw. > > > In skl_update_scaler during plane_scaler_check if the format > > > was non-NV12, it would set need_scaling to false. This could > > > reset the previously set need_scaling from a previous condition > > > check. Patch fixes this. > > > Patch also adds minimum src height for YUV 420 formats to 16 > > > (as defined in BSpec) and adds for checking this range. > > > > > > Tested-by: Clinton Taylor > > > Reviewed-by: Clinton Taylor > > > Signed-off-by: Chandra Konduru > > > Signed-off-by: Nabendu Maiti > > > Signed-off-by: Uma Shankar > > > Signed-off-by: Vidya Srinivas > > > --- > > > drivers/gpu/drm/i915/intel_display.c | 78 > > > >> ++-- > > > drivers/gpu/drm/i915/intel_drv.h | 4 +- > > > drivers/gpu/drm/i915/intel_sprite.c | 3 +- > > > 3 files changed, 61 insertions(+), 24 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > b/drivers/gpu/drm/i915/intel_display.c > > > index 34f7225..7fd8354 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -3466,6 +3466,8 @@ static u32 skl_plane_ctl_format(uint32_t > > > >> pixel_format) > > > return PLANE_CTL_FORMAT_YUV422 | > > > >> PLANE_CTL_YUV422_UYVY; > > > case DRM_FORMAT_VYUY: > > > return PLANE_CTL_FORMAT_YUV422 | > > > >> PLANE_CTL_YUV422_VYUY; > > > +case DRM_FORMAT_NV12: > > > +return PLANE_CTL_FORMAT_NV12; > > > default: > > > MISSING_CASE(pixel_format); > > > } > > > @@ -4705,7 +4707,9 @@ static void cpt_verify_modeset(struct > > > drm_device *dev, int pipe) static int > > > skl_update_scaler(struct intel_crtc_state *crtc_state, bool > force_detach, > > > unsigned int scaler_user, int *scaler_id, >
Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12
> -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > Sent: Thursday, March 15, 2018 12:34 AM > To: Ville Syrjälä > Cc: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org; Syrjala, Ville ; > Lankhorst, > Maarten > Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale > for NV12 > > Op 14-03-18 om 18:08 schreef Ville Syrjälä: > > On Wed, Mar 14, 2018 at 04:55:08PM +0100, Maarten Lankhorst wrote: > >> Op 14-03-18 om 16:35 schreef Ville Syrjälä: > >>> On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote: > > -Original Message- > > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > > Sent: Wednesday, March 14, 2018 4:03 PM > > To: Srinivas, Vidya ; intel- > > g...@lists.freedesktop.org > > Cc: Syrjala, Ville ; Lankhorst, Maarten > > > > Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale > > scaler max scale for NV12 > > > > Op 14-03-18 om 11:31 schreef Srinivas, Vidya: > >>> -Original Message- > >>> From: Maarten Lankhorst > >>> [mailto:maarten.lankho...@linux.intel.com] > >>> Sent: Wednesday, March 14, 2018 3:55 PM > >>> To: Srinivas, Vidya ; intel- > >>> g...@lists.freedesktop.org > >>> Cc: Syrjala, Ville ; Lankhorst, Maarten > >>> > >>> Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale > >>> scaler max scale for NV12 > >>> > >>> Op 14-03-18 om 10:52 schreef Maarten Lankhorst: > Op 09-03-18 om 09:48 schreef Vidya Srinivas: > > From: Chandra Konduru > > > > This patch updates scaler max limit support for NV12 > > > > v2: Rebased (me) > > > > v3: Rebased (me) > > > > v4: Missed the Tested-by/Reviewed-by in the previous series > > Adding the same to commit message in this version. > > > > v5: Addressed review comments from Ville and rebased > > - calculation of max_scale to be made less convoluted by > > splitting it up a bit > > - Indentation errors to be fixed in the series > > > > v6: Rebased (me) > > Fixed review comments from Paauwe, Bob J Previous version, > > where a split of calculation was done, was wrong. Fixed that > issue here. > > > > v7: Rebased (me) > > > > v8: Rebased (me) > > > > v9: Rebased (me) > > > > v10: Rebased (me) > > > > v11: Addressed review comments from Shashank Sharma > Alignment > >>> issues > > fixed. > > When call to skl_update_scaler is made, 0 was being sent > > instead of pixel_format. > > When crtc update scaler is called, we dont have the fb to > > derive the pixel format. Added the function parameter bool > > plane_scaler_check to account for this. > > > > v12: Fixed failure in IGT debugfs_test. > > fb is NULL in skl_update_scaler_plane Due to this, accessing > > fb->format caused failure. > > Patch checks fb before using. > > > > v13: In the previous version there was a flaw. > > In skl_update_scaler during plane_scaler_check if the format > > was non-NV12, it would set need_scaling to false. This could > > reset the previously set need_scaling from a previous > > condition check. Patch fixes this. > > Patch also adds minimum src height for YUV 420 formats to 16 > > (as defined in BSpec) and adds for checking this range. > > > > Tested-by: Clinton Taylor > > Reviewed-by: Clinton Taylor > > Signed-off-by: Chandra Konduru > > Signed-off-by: Nabendu Maiti > > > Signed-off-by: Uma Shankar > > Signed-off-by: Vidya Srinivas > > --- > > drivers/gpu/drm/i915/intel_display.c | 78 > >>> ++-- > > drivers/gpu/drm/i915/intel_drv.h | 4 +- > > drivers/gpu/drm/i915/intel_sprite.c | 3 +- > > 3 files changed, 61 insertions(+), 24 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 34f7225..7fd8354 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -3466,6 +3466,8 @@ static u32 > skl_plane_ctl_format(uint32_t > >>> pixel_format) > > return PLANE_CTL_FORMAT_YUV422 | > >>> PLANE_CTL_YUV422_UYVY; > > case DRM_FORMAT_VYUY: > > return PLANE_CTL_FORMAT_YUV422 | > >>> PLANE_CTL_YUV422_VYUY; > > + case DRM_FORMAT_NV12: > > + return PLANE_CTL_FORMAT_NV12; > > default: > > MISSING_CASE(pixel_format); > > } > >>
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/huc: Check HuC status in dedicated function
== Series Details == Series: drm/i915/huc: Check HuC status in dedicated function URL : https://patchwork.freedesktop.org/series/39986/ State : failure == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite: pass -> FAIL (shard-apl) Known issues: Test drv_suspend: Subgroup debugfs-reader: pass -> SKIP (shard-snb) fdo#102365 Test gem_eio: Subgroup in-flight-external: incomplete -> PASS (shard-apl) fdo#105341 +1 Test kms_flip: Subgroup 2x-plain-flip-fb-recreate: fail -> PASS (shard-hsw) fdo#100368 +1 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 shard-apltotal:3401 pass:1789 dwarn:1 dfail:0 fail:8 skip:1601 time:12464s shard-hswtotal:3441 pass:1766 dwarn:1 dfail:0 fail:1 skip:1672 time:11873s shard-snbtotal:3441 pass:1354 dwarn:1 dfail:0 fail:3 skip:2083 time:7129s Blacklisted hosts: shard-kbltotal:3425 pass:1925 dwarn:1 dfail:0 fail:9 skip:1488 time:9137s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8353/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev2)
== Series Details == Series: drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev2) URL : https://patchwork.freedesktop.org/series/39979/ State : failure == Summary == Possible new issues: Test gem_exec_capture: Subgroup capture-vebox: pass -> FAIL (shard-apl) Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-indfb-draw-mmap-wc: pass -> FAIL (shard-apl) Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite: pass -> FAIL (shard-apl) Test kms_vblank: Subgroup pipe-a-ts-continuation-suspend: skip -> PASS (shard-snb) Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl) fdo#105341 Test kms_flip: Subgroup plain-flip-fb-recreate-interruptible: fail -> PASS (shard-hsw) fdo#100368 +1 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3286 pass:1721 dwarn:1 dfail:0 fail:9 skip:1553 time:11853s shard-hswtotal:3441 pass:1766 dwarn:1 dfail:0 fail:1 skip:1672 time:11890s shard-snbtotal:3441 pass:1356 dwarn:1 dfail:0 fail:3 skip:2081 time:7165s Blacklisted hosts: shard-kbltotal:3425 pass:1925 dwarn:1 dfail:0 fail:9 skip:1488 time:9042s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8351/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines
== Series Details == Series: series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39981/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-external: incomplete -> PASS (shard-apl) fdo#105341 +1 Test kms_flip: Subgroup 2x-plain-flip-fb-recreate: fail -> PASS (shard-hsw) fdo#100368 +1 Test kms_vblank: Subgroup pipe-c-ts-continuation-dpms-suspend: skip -> PASS (shard-hsw) k.org#196691 Test perf: Subgroup blocking: pass -> FAIL (shard-hsw) fdo#102252 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 k.org#196691 https://bugzilla.kernel.org/show_bug.cgi?id=196691 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3426 pass:1803 dwarn:1 dfail:0 fail:7 skip:1613 time:12439s shard-hswtotal:3442 pass:1767 dwarn:1 dfail:0 fail:2 skip:1671 time:11916s shard-snbtotal:3442 pass:1356 dwarn:1 dfail:0 fail:3 skip:2082 time:7197s Blacklisted hosts: shard-kbltotal:3426 pass:1907 dwarn:20 dfail:0 fail:9 skip:1488 time:9076s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8349/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove hole and padding from intel_shared_dpll
== Series Details == Series: drm/i915: Remove hole and padding from intel_shared_dpll URL : https://patchwork.freedesktop.org/series/39972/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 Test kms_chv_cursor_fail: Subgroup pipe-c-128x128-bottom-edge: fail -> PASS (shard-apl) fdo#105185 Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: pass -> FAIL (shard-apl) fdo#101623 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 shard-apltotal:3444 pass:1815 dwarn:1 dfail:0 fail:8 skip:1619 time:13035s shard-hswtotal:3444 pass:1769 dwarn:1 dfail:0 fail:2 skip:1671 time:11968s shard-snbtotal:3444 pass:1360 dwarn:1 dfail:0 fail:2 skip:2081 time:7239s Blacklisted hosts: shard-kbltotal:3411 pass:1912 dwarn:7 dfail:0 fail:9 skip:1482 time:9607s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8347/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Control PSR at runtime through debugfs only (rev2)
== Series Details == Series: drm/i915: Control PSR at runtime through debugfs only (rev2) URL : https://patchwork.freedesktop.org/series/39955/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 Test kms_chv_cursor_fail: Subgroup pipe-c-128x128-bottom-edge: fail -> PASS (shard-apl) fdo#105185 Test kms_flip: Subgroup plain-flip-fb-recreate: pass -> FAIL (shard-hsw) fdo#100368 +2 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3444 pass:1816 dwarn:1 dfail:0 fail:7 skip:1619 time:13096s shard-hswtotal:3444 pass:1767 dwarn:1 dfail:0 fail:4 skip:1671 time:11950s shard-snbtotal:3444 pass:1360 dwarn:1 dfail:0 fail:2 skip:2081 time:7226s Blacklisted hosts: shard-kbltotal:3368 pass:1902 dwarn:1 dfail:0 fail:9 skip:1454 time:9437s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8346/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Update syntax of GuC log functions (rev2)
== Series Details == Series: drm/i915/guc: Update syntax of GuC log functions (rev2) URL : https://patchwork.freedesktop.org/series/39859/ State : failure == Summary == Possible new issues: Test kms_mmio_vs_cs_flip: Subgroup setplane_vs_cs_flip: pass -> FAIL (shard-apl) Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl) fdo#105341 +1 Test kms_chv_cursor_fail: Subgroup pipe-c-128x128-bottom-edge: fail -> PASS (shard-apl) fdo#105185 Test kms_flip: Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Test kms_flip_tiling: Subgroup flip-changes-tiling-yf: pass -> FAIL (shard-apl) fdo#103822 fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 shard-apltotal:3401 pass:1793 dwarn:1 dfail:0 fail:9 skip:1596 time:12912s shard-hswtotal:3444 pass:1768 dwarn:1 dfail:0 fail:3 skip:1671 time:11928s shard-snbtotal:3444 pass:1360 dwarn:1 dfail:0 fail:2 skip:2081 time:7284s Blacklisted hosts: shard-kbltotal:3335 pass:1874 dwarn:6 dfail:0 fail:9 skip:1443 time:8997s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8345/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
== Series Details == Series: series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads URL : https://patchwork.freedesktop.org/series/39992/ State : success == Summary == Series 39992v1 series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads https://patchwork.freedesktop.org/api/1.0/series/39992/revisions/1/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:440s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:444s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:540s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:519s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:503s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:411s fi-cfl-s2total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:587s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:585s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:429s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:320s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:425s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:475s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:427s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:477s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:469s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:515s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:654s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:528s fi-skl-6700hqtotal:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:542s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:506s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:496s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:445s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:588s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:403s Blacklisted hosts: fi-cnl-drrs total:285 pass:243 dwarn:14 dfail:0 fail:0 skip:28 time:519s 178cfb9373cc2bdfcb6ca73e03369d2c37cc4b58 drm-tip: 2018y-03m-14d-21h-38m-09s UTC integration manifest 8dab9a7c7110 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads 1a52c6e6d006 drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8356/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes
On Wed, 2018-03-14 at 23:09 +0100, Hans de Goede wrote: > Hi, > > On 14-03-18 21:49, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2018-02-14 at 09:25 +0100, Hans de Goede wrote: > >> Hi, > >> > >> On 12-02-18 18:42, Pandiyan, Dhinakaran wrote: > >>> On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote: > Hi, > > On 12-02-18 07:08, Dhinakaran Pandiyan wrote: > > PSR currently when enabled results in semi-permanent freezes or > > noticeable > > cursor lags. > > > > https://patchwork.freedesktop.org/series/37598/ will fix long freezes > > due > > to frame counter resets. > > > > This series has three more fixes - > > Patch 1 eliminates PSR exit for flips and makes us rely on the HW to do > > it. > > Patch 2 fixes cusor move lag by relying on HW to exit PSR. > > Patch 3 fixes temporary freeze seen with fbdev. > > > > With both the series applied, PSR on my SKL ThinkPad feels pretty good. > > Thank you for your great work on this. > > Are there any more PSR fixes in the pipeline? > >>> > >>> Yeah, there are a few more fixes that I hope will appear on the list in > >>> the next two weeks or so. > >> > >> Ok, can you send a mail when you're done (in sofar any software is ever > >> "done") and you would like me to ask all people who have been kind enough > >> to test PSR to retest ? > >> > > > > Hi Hans, > > > > Thanks for your patience and help. I believe the current drm-tip is in a > > decent shape to retest PSR. Booting with i915.enable_psr = 1 is still > > needed. The fixes have been mostly developed/tested on gen-9 hardware > > but they apply to other platforms too. > > Cool, thank you. Current drm-tip will all be merged into 4.17-rc1, right? Rodrigo, Can you help me answer that? > > Then I think I will just wait for that, most distros already provide rc builds > for testing, so that way it will be easy for people to test. > > Regards, > > Hans > > > > > > > > -DK > > > If not I think I should do > a custom Fedora kernel build based on 4.15 + recent fixes and ask all my > testers to retest with that. > > I do have some questions before I do this: > > 1) I believe that only testers with skylake (normal or LP) or newer > should > re-test, correct? > >>> > >>> These fixes do apply for HSW/BDW, so essentially all the big cores > >>> supporting PSR. But, HSW/BDW need fixes for AUX channel-PSR interaction > >>> also. I haven't looked into CHV/VLV. > >>> > > 2) I know there are 2 series (including this one), can someone provide a > link > to the latest patchwork version of those 2 series, or even better a git > branch with 4.15 + those patches? Any patches I'm missing if I pick up > these > 2 series? > >>> > >>> https://patchwork.freedesktop.org/series/37598/ > >>> https://patchwork.freedesktop.org/series/38067/ > >>> > >>> > 3) I'm thinking 4.15 atm, but I could also do a 4.16-rc1 test kernel > instead > if that would be better, would that be better ? > >>> > >>> I can't think of any diff that would affect PSR, but the latest is > >>> better I suppose. > >> > >> Ok. > >> > >> Regards, > >> > >> Hans > >> ___ > >> 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 mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function
On 14/03/18 15:23, Michal Wajdeczko wrote:
On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry
wrote:
On 14/03/18 13:04, Michal Wajdeczko wrote:
We try to keep all HuC related code in dedicated file.
There is no need to peek HuC register directly during
handling getparam ioctl.
Signed-off-by: Michal Wajdeczko
Cc: Michel Thierry
Cc: Rodrigo Vivi
Cc: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
drivers/gpu/drm/i915/intel_huc.c | 25 +
drivers/gpu/drm/i915/intel_huc.h | 1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index f03555e..a902e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device
*dev, void *data,
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
- intel_runtime_pm_get(dev_priv);
- value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
- intel_runtime_pm_put(dev_priv);
+ value = intel_huc_check_status(&dev_priv->huc);
+ if (value < 0)
+ return value;
break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
diff --git a/drivers/gpu/drm/i915/intel_huc.c
b/drivers/gpu/drm/i915/intel_huc.c
index 1d6c47b..2912852 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
DRM_ERROR("HuC: Authentication failed %d\n", ret);
return ret;
}
+
+/**
+ * intel_huc_check_status() - check HuC status
+ * @huc: intel_huc structure
+ *
+ * This function reads status register to verify if HuC
+ * firmware was successfully loaded.
+ *
+ * Returns positive value if HuC firmware is loaded and verified
+ * and -ENODEV if HuC is not present.
Before if huc was not loaded, get_param would just return 0 and the
ioctl call would be OK.
There is another potential problem, as in case HuC was loaded, this
getparam would return specific bit from register instead of predefined
value that shall indicate "loaded/verified" like "1".
What if this bit from register will be moved on future platforms?
Really? ;)
I once heard someone claiming he had talked with the hw team and they've
agreed not to randomly shuffle register specifications
(please laugh with me).
Should we still return this old one?
Maybe there's a test somewhere that would break?
I hope not, and given above concern, I assume we can still modify it.
Is there any documentation what to expect from this getparam?
And the media driver would survive the change [1] if that's what we care
about.
But is the response from getparam ABI? I would say just
drm_i915_getparam_t is.
[1]
https://github.com/intel/media-driver/blob/c0321bc88e12247d21fa2d0b470cff841c3712ba/media_driver/linux/common/os/hwinfo_linux.c#L254
(I'm not arguing -ENODEV is better).
In all other places (like debugfs) we return -ENODEV if user wants
to access HuC data on platform without HuC, so I think we should be
consistent.
sorry, a missing comma... I was agreeing with you:
>> (I'm not arguing, -ENODEV is better).
Otherwise,
Reviewed-by: Michel Thierry
+ */
+int intel_huc_check_status(struct intel_huc *huc)
+{
+ struct drm_i915_private *dev_priv = huc_to_i915(huc);
+ u32 status;
+
+ if (!HAS_HUC(dev_priv))
+ return -ENODEV;
+
+ intel_runtime_pm_get(dev_priv);
+ status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+ intel_runtime_pm_put(dev_priv);
+
+ return status;
+}
diff --git a/drivers/gpu/drm/i915/intel_huc.h
b/drivers/gpu/drm/i915/intel_huc.h
index b185850..aa85490 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -37,6 +37,7 @@ struct intel_huc {
void intel_huc_init_early(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_check_status(struct intel_huc *huc);
static inline int intel_huc_sanitize(struct intel_huc *huc)
{
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.
However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/i915_reg.h| 4
drivers/gpu/drm/i915/intel_engine_cs.c | 19 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index abdc513..b283427 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2849,6 +2849,10 @@ enum i915_power_well_id {
#define GEN10_F2_SS_DIS_SHIFT18
#define GEN10_F2_SS_DIS_MASK (0xf << GEN10_F2_SS_DIS_SHIFT)
+#defineGEN10_MIRROR_FUSE3 _MMIO(0x9118)
+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK 0x0F
+
#define GEN8_EU_DISABLE0 _MMIO(0x9134)
#define GEN8_EU_DIS0_S0_MASK 0xff
#define GEN8_EU_DIS0_S1_SHIFT24
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index bc8fed7..c17d2d5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -798,7 +798,26 @@ static u32 calculate_mcr(u32 mcr, struct drm_i915_private
*dev_priv)
static void wa_init_mcr(struct drm_i915_private *dev_priv)
{
u32 mcr;
+ u32 fuse3;
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+ u32 slice;
+ /* If more than one slice are enabled, L3Banks should be all enabled */
+ if (hweight8(sseu->slice_mask) == 1) {
+ /*
+* WaProgramMgsrForL3BankSpecificMmioReads:
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
+ slice = find_last_bit((unsigned long *)&(sseu->slice_mask),
+ sizeof(sseu->slice_mask));
+ fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+ if (WARN_ON(!((fuse3 & GEN10_L3BANK_MASK)
+ & ((sseu->subslice_mask[slice]
+ |
sseu->subslice_mask[slice]>>GEN10_L3BANK_PAIR_COUNT)
+ & GEN10_L3BANK_MASK
+ DRM_WARN("Real silicon should have matched L3Bank and
subslice enabled\n");
+ }
mcr = I915_READ(GEN8_MCR_SELECTOR);
mcr = calculate_mcr(mcr, dev_priv);
I915_WRITE(GEN8_MCR_SELECTOR, mcr);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.
However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg for INSTDONE.
Also, 0xFDC will lose its information after TDR/engine reset/power state
change.
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/intel_engine_cs.c | 43 --
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a2b1e9e..bc8fed7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -781,6 +781,29 @@ const char *i915_cache_level_str(struct drm_i915_private
*i915, int type)
}
}
+static u32 calculate_mcr(u32 mcr, struct drm_i915_private *dev_priv)
+{
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+ u32 slice = find_last_bit((unsigned long *)&(sseu->slice_mask),
+ sizeof(sseu->slice_mask));
+ u32 subslice = find_last_bit((unsigned long
*)&(sseu->subslice_mask[slice]),
+ sizeof(sseu->subslice_mask[0]));
+
+ mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+ return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+ u32 mcr;
+
+ mcr = I915_READ(GEN8_MCR_SELECTOR);
+ mcr = calculate_mcr(mcr, dev_priv);
+ I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
static inline uint32_t
read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
int subslice, i915_reg_t reg)
@@ -799,18 +822,31 @@ read_subslice_reg(struct drm_i915_private *dev_priv, int
slice,
intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
/*
* The HW expects the slice and sublice selectors to be reset to 0
* after reading out the registers.
*/
- WARN_ON_ONCE(mcr & (GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK));
+ if (INTEL_GEN(dev_priv) < 10)
+ WARN_ON_ONCE(mcr & (GEN8_MCR_SLICE_MASK |
+GEN8_MCR_SUBSLICE_MASK));
+
mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
ret = I915_READ_FW(reg);
- mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+* expects mcr to be programed to a enabled slice/subslice pair
+* before any MMIO read into slice/subslice register
+*/
+ if (INTEL_GEN(dev_priv) < 10)
+ mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ else
+ mcr = calculate_mcr(mcr, dev_priv);
+
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
@@ -1278,6 +1314,9 @@ static int cnl_init_workarounds(struct intel_engine_cs
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
+ /* WaProgramMgsrForCorrectSliceSpecificMmioReads: cnl */
+ wa_init_mcr(dev_priv);
+
/* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
I915_WRITE(GAMT_CHKN_BIT_REG,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915/psr: Nuke aux_frame_sync
== Series Details == Series: series starting with [1/6] drm/i915/psr: Nuke aux_frame_sync URL : https://patchwork.freedesktop.org/series/39990/ State : failure == Summary == Series 39990v1 series starting with [1/6] drm/i915/psr: Nuke aux_frame_sync https://patchwork.freedesktop.org/api/1.0/series/39990/revisions/1/mbox/ Possible new issues: Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (fi-skl-6770hq) Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:432s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:441s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:539s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:299s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:516s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:506s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:408s fi-cfl-s2total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:589s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:592s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:427s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:407s fi-ilk-650 total:285 pass:224 dwarn:0 dfail:0 fail:1 skip:60 time:425s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:475s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:429s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:476s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:468s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:515s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:654s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:527s fi-skl-6700hqtotal:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:544s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:497s fi-skl-6770hqtotal:285 pass:264 dwarn:0 dfail:0 fail:1 skip:20 time:479s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:448s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:578s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:409s Blacklisted hosts: fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:533s 178cfb9373cc2bdfcb6ca73e03369d2c37cc4b58 drm-tip: 2018y-03m-14d-21h-38m-09s UTC integration manifest f82d67643405 drm/i915/psr: Enable aux frame sync in source 5adb06aa65d7 drm/i915/psr: Rename intel_crtc_state has_psr to can_psr d4117b9b7931 drm/i915/psr: Do not override PSR2 sink support dd78cdfeb5ba drm/i915/psr: Enable Y-coordinate support in source 0496ade25ff9 drm/i915/psr: Tie PSR2 support to Y coordinate requirement in intel_psr_init_dpcd() 742aaf18896d drm/i915/psr: Nuke aux_frame_sync == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8355/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Here goes drm-intel-fixes-2018-03-14: - 1 display fix for bxt - 1 gem fix for fences - 1 gem/pm fix for rps freq Thanks, Rodrigo. The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae: Linux 4.16-rc5 (2018-03-11 17:25:09 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-03-14 for you to fetch changes up to f1430f145eefcab2bddb9e836d427c4aac067faa: drm/i915: Kick the rps worker when changing the boost frequency (2018-03-12 11:24:49 -0700) - 1 display fix for bxt - 1 gem fix for fences - 1 gem/pm fix for rps freq Chris Wilson (2): drm/i915: Only prune fences after wait-for-all drm/i915: Kick the rps worker when changing the boost frequency Mustamin B Mustaffa (1): drm/i915: Enable VBT based BL control for DP drivers/gpu/drm/i915/i915_gem.c | 16 drivers/gpu/drm/i915/i915_sysfs.c | 10 -- drivers/gpu/drm/i915/intel_dp.c | 10 +++--- 3 files changed, 23 insertions(+), 13 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915/psr: Enable aux frame sync in source
Even with GTC not enabled lets send the aux frame sync.
Hardware is going to send dummy values but this way we can get rid of
this workarround in PSR exit: 'drm/i915/psr: disable aux_frame_sync
on psr2 exit'.
Also moving the line disabling aux frame sync in sink to after report
that PSR2 has exit to avoid.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 15 ++-
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9fc1722c0fb..5a2364656aa5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4132,6 +4132,7 @@ enum {
#define EDP_PSR2_CTL _MMIO(0x6f900)
#define EDP_PSR2_ENABLE (1<<31)
#define EDP_SU_TRACK_ENABLE (1<<30)
+#define EDP_AUX_FRAME_SYNC_ENABLE(1<<27)
#define EDP_Y_COORDINATE_VALID (1<<26)
#define EDP_Y_COORDINATE_ENABLE (1<<25)
#define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index d622e37894d4..7aab66b5bc91 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -418,6 +418,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
* good enough. */
val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
+ val |= EDP_AUX_FRAME_SYNC_ENABLE;
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_SYNCHRONIZATION_LATENCY_IN_SINK,
@@ -715,11 +716,6 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
i915_reg_t psr_status;
u32 psr_status_mask;
- if (dev_priv->psr.psr2_enabled)
- drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
- 0);
-
if (dev_priv->psr.psr2_enabled) {
psr_status = EDP_PSR2_STATUS;
psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
@@ -742,6 +738,11 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
2000))
DRM_ERROR("Timed out waiting for PSR Idle State\n");
+ if (dev_priv->psr.psr2_enabled)
+ drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
+ 0);
+
dev_priv->psr.active = false;
} else {
if (dev_priv->psr.psr2_enabled)
@@ -863,10 +864,6 @@ static void intel_psr_exit(struct drm_i915_private
*dev_priv)
return;
if (HAS_DDI(dev_priv)) {
- if (dev_priv->psr.psr2_enabled)
- drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
- 0);
if (dev_priv->psr.psr2_enabled) {
val = I915_READ(EDP_PSR2_CTL);
WARN_ON(!(val & EDP_PSR2_ENABLE));
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915/psr: Tie PSR2 support to Y coordinate requirement in intel_psr_init_dpcd()
Move to only one place the sink requirements that the actual driver
needs to enable PSR2.
Also intel_psr2_config_valid() is called every time the crtc config
is computed, wasting some time every time it was checking for
Y coordinate requirement.
This allow us to nuke y_cord_support and some of VSC setup code that
was handling a scenario that would never happen(PSR2 without Y
coordinate).
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_psr.c | 55
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8a584273f897..d4bc8d18f56c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -603,7 +603,6 @@ struct i915_psr {
unsigned busy_frontbuffer_bits;
bool psr2_support;
bool link_standby;
- bool y_cord_support;
bool colorimetry_support;
bool alpm;
bool has_hw_tracking;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 9811f5f0bc75..62d97d5576d1 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp *intel_dp)
intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
}
-static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
+static bool intel_dp_get_y_coord_required(struct intel_dp *intel_dp)
{
uint8_t psr_caps = 0;
@@ -137,22 +137,38 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 9 &&
(intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
- uint8_t frame_sync_cap;
+ uint8_t frame_sync_cap, y_coord_req;
dev_priv->psr.sink_support = true;
+
+ /* PSR2 needs frame sync to do selective updates */
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
&frame_sync_cap) != 1)
frame_sync_cap = 0;
frame_sync_cap = (frame_sync_cap & DP_AUX_FRAME_SYNC_CAP);
- /* PSR2 needs frame sync as well */
- dev_priv->psr.psr2_support = frame_sync_cap;
- DRM_DEBUG_KMS("PSR2 %s on sink",
- dev_priv->psr.psr2_support ? "supported" : "not
supported");
+
+ /*
+* FIXME: Enable PSR2 only for y-coordinate PSR2 panels
+* After GTC implementation, remove this restriction.
+*
+* All panels that supports PSR version 3 that is
+* PSR2 + Y-coordinate support can handle Y coordinates in VSC
+* but we are only sure that it is going to be used when
+* required by the panel. This way panel is capable to do
+* selective update even without a valid aux frame sync.
+*/
+ y_coord_req = intel_dp_get_y_coord_required(intel_dp);
+
+ dev_priv->psr.psr2_support = frame_sync_cap && y_coord_req;
+ if (dev_priv->psr.psr2_support)
+ DRM_DEBUG_KMS("PSR2 supported on sink\n");
+ else
+ DRM_DEBUG_KMS("PSR2 not supported on sink"
+ "(frame sync: %d Y-coord required: %d)\n",
+ frame_sync_cap, y_coord_req);
if (dev_priv->psr.psr2_support) {
- dev_priv->psr.y_cord_support =
- intel_dp_get_y_cord_status(intel_dp);
dev_priv->psr.colorimetry_support =
intel_dp_get_colorimetry_status(intel_dp);
dev_priv->psr.alpm =
@@ -198,16 +214,12 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
memset(&psr_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
psr_vsc.sdp_header.HB1 = 0x7;
- if (dev_priv->psr.colorimetry_support &&
- dev_priv->psr.y_cord_support) {
+ if (dev_priv->psr.colorimetry_support) {
psr_vsc.sdp_header.HB2 = 0x5;
psr_vsc.sdp_header.HB3 = 0x13;
- } else if (dev_priv->psr.y_cord_support) {
+ } else {
psr_vsc.sdp_header.HB2 = 0x4;
psr_vsc.sdp_header.HB3 = 0xe;
- } else {
- psr_vsc.sdp_header.HB2 = 0x3;
- psr_vsc.sdp_header.HB3 = 0xc;
}
} else {
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
@@ -478,15 +490,6 @@ static bool intel_psr2_config_valid(struct intel_dp
[Intel-gfx] [PATCH 4/6] drm/i915/psr: Do not override PSR2 sink support
Sink can support our PSR2 requirements but userspace can request
a resolution that PSR2 hardware do not support, in this case it
was overwritten the PSR2 sink support.
Adding another flag here, this way if requested resolution changed
to a value that PSR2 hardware can handle, PSR2 can be enabled.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_psr.c| 36 ++--
3 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 972014b2497d..aa5918583df8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2571,7 +2571,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
yesno(work_busy(&dev_priv->psr.work.work)));
if (HAS_DDI(dev_priv)) {
- if (dev_priv->psr.psr2_support)
+ if (dev_priv->psr.psr2_enabled)
enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
else
enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
@@ -2619,7 +2619,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "Performance_Counter: %u\n", psrperf);
}
- if (dev_priv->psr.psr2_support) {
+ if (dev_priv->psr.psr2_enabled) {
u32 psr2 = I915_READ(EDP_PSR2_STATUS);
seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d4bc8d18f56c..d4475196f78a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -601,11 +601,12 @@ struct i915_psr {
bool active;
struct delayed_work work;
unsigned busy_frontbuffer_bits;
- bool psr2_support;
+ bool sink_psr2_support;
bool link_standby;
bool colorimetry_support;
bool alpm;
bool has_hw_tracking;
+ bool psr2_enabled;
void (*enable_source)(struct intel_dp *,
const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c9da1390a727..4cb613855c20 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -160,15 +160,15 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
*/
y_coord_req = intel_dp_get_y_coord_required(intel_dp);
- dev_priv->psr.psr2_support = frame_sync_cap && y_coord_req;
- if (dev_priv->psr.psr2_support)
+ dev_priv->psr.sink_psr2_support = frame_sync_cap && y_coord_req;
+ if (dev_priv->psr.sink_psr2_support)
DRM_DEBUG_KMS("PSR2 supported on sink\n");
else
DRM_DEBUG_KMS("PSR2 not supported on sink"
"(frame sync: %d Y-coord required: %d)\n",
frame_sync_cap, y_coord_req);
- if (dev_priv->psr.psr2_support) {
+ if (dev_priv->psr.sink_psr2_support) {
dev_priv->psr.colorimetry_support =
intel_dp_get_colorimetry_status(intel_dp);
dev_priv->psr.alpm =
@@ -209,7 +209,7 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
struct edp_vsc_psr psr_vsc;
- if (dev_priv->psr.psr2_support) {
+ if (dev_priv->psr.psr2_enabled) {
/* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
memset(&psr_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
@@ -281,12 +281,12 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 0);
/* Enable AUX frame sync at sink */
- if (dev_priv->psr.psr2_support)
+ if (dev_priv->psr.psr2_enabled)
drm_dp_dpcd_writeb(&intel_dp->aux,
DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
DP_AUX_FRAME_SYNC_ENABLE);
/* Enable ALPM at sink for psr2 */
- if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
+ if (dev_priv->psr.psr2_enabled && dev_priv->psr.alpm)
drm_dp_dpcd_writeb(&intel_dp->aux,
DP_RECEIVER_ALPM_CONFIG,
DP_ALPM_ENABLE);
@@ -452,7 +452,7 @@ static void hsw_psr_activate(struct intel_dp *intel_dp)
*/
/* psr1 and psr2 are mutually exclusive.*/
- if (dev_priv->psr.psr2_support)
+ if (dev_priv->psr.psr2_enabled)
hsw_activate_psr2(
[Intel-gfx] [PATCH 5/6] drm/i915/psr: Rename intel_crtc_state has_psr to can_psr
This value is a match of hardware and sink has PSR + if it can be
enabled by the requested state, see intel_psr_compute_config().
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_psr.c | 12 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a215aa78b0be..cccaf84415ab 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -807,8 +807,8 @@ struct intel_crtc_state {
struct intel_link_m_n dp_m2_n2;
bool has_drrs;
- bool has_psr;
- bool has_psr2;
+ bool can_psr;
+ bool can_psr2;
/*
* Frequence the dpll for the port should run at. Differs from the
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 4cb613855c20..d622e37894d4 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -560,9 +560,9 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
return;
}
- crtc_state->has_psr = true;
- crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
- DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
+ crtc_state->can_psr = true;
+ crtc_state->can_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
+ DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->can_psr2 ? "2" : "");
}
static void intel_psr_activate(struct intel_dp *intel_dp)
@@ -632,7 +632,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- if (!crtc_state->has_psr)
+ if (!crtc_state->can_psr)
return;
if (WARN_ON(!CAN_PSR(dev_priv)))
@@ -645,7 +645,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
goto unlock;
}
- dev_priv->psr.psr2_enabled = crtc_state->has_psr2;
+ dev_priv->psr.psr2_enabled = crtc_state->can_psr2;
dev_priv->psr.busy_frontbuffer_bits = 0;
dev_priv->psr.setup_vsc(intel_dp, crtc_state);
@@ -767,7 +767,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- if (!old_crtc_state->has_psr)
+ if (!old_crtc_state->can_psr)
return;
if (WARN_ON(!CAN_PSR(dev_priv)))
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915/psr: Enable Y-coordinate support in source
We are requiring that sink requires Y-coordinate but we are not
sending it in the main-link.
Even if hardware tracking isn't good enough it will not cause
any more issues enabling it.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_psr.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a15db41a208a..e9fc1722c0fb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4132,6 +4132,8 @@ enum {
#define EDP_PSR2_CTL _MMIO(0x6f900)
#define EDP_PSR2_ENABLE (1<<31)
#define EDP_SU_TRACK_ENABLE (1<<30)
+#define EDP_Y_COORDINATE_VALID (1<<26)
+#define EDP_Y_COORDINATE_ENABLE (1<<25)
#define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
#define EDP_PSR2_TP2_TIME_500(0<<8)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 62d97d5576d1..c9da1390a727 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -416,8 +416,8 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
/* FIXME: selective update is probably totally broken because it doesn't
* mesh at all with our frontbuffer tracking. And the hw alone isn't
* good enough. */
- val |= EDP_PSR2_ENABLE |
- EDP_SU_TRACK_ENABLE;
+ val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+ val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_SYNCHRONIZATION_LATENCY_IN_SINK,
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915/psr: Nuke aux_frame_sync
PSR2 selective update requires aux frame sync(even though we don't
support it in i915) and do not makes sense active PSR2 to only do
full screen updates aka PSR1.
Having aux_frame_sync flag could cause it be set to true even when
the PSR1 is being used, see intel_psr2_config_valid().
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_psr.c | 10 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e27ba8fb64e6..8a584273f897 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -602,7 +602,6 @@ struct i915_psr {
struct delayed_work work;
unsigned busy_frontbuffer_bits;
bool psr2_support;
- bool aux_frame_sync;
bool link_standby;
bool y_cord_support;
bool colorimetry_support;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 317cb4a12693..9811f5f0bc75 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -144,9 +144,9 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
&frame_sync_cap) != 1)
frame_sync_cap = 0;
- dev_priv->psr.aux_frame_sync = frame_sync_cap &
DP_AUX_FRAME_SYNC_CAP;
+ frame_sync_cap = (frame_sync_cap & DP_AUX_FRAME_SYNC_CAP);
/* PSR2 needs frame sync as well */
- dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
+ dev_priv->psr.psr2_support = frame_sync_cap;
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not
supported");
@@ -269,7 +269,7 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 0);
/* Enable AUX frame sync at sink */
- if (dev_priv->psr.aux_frame_sync)
+ if (dev_priv->psr.psr2_support)
drm_dp_dpcd_writeb(&intel_dp->aux,
DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
DP_AUX_FRAME_SYNC_ENABLE);
@@ -714,7 +714,7 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
i915_reg_t psr_status;
u32 psr_status_mask;
- if (dev_priv->psr.aux_frame_sync)
+ if (dev_priv->psr.psr2_support)
drm_dp_dpcd_writeb(&intel_dp->aux,
DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
0);
@@ -862,7 +862,7 @@ static void intel_psr_exit(struct drm_i915_private
*dev_priv)
return;
if (HAS_DDI(dev_priv)) {
- if (dev_priv->psr.aux_frame_sync)
+ if (dev_priv->psr.psr2_support)
drm_dp_dpcd_writeb(&intel_dp->aux,
DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
0);
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v5] drm/i915/psr: Kill scheduled work for Core platforms.
On Wed, 2018-03-14 at 13:47 -0700, Rodrigo Vivi wrote:
> On Wed, Mar 14, 2018 at 01:24:13PM -0700, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-03-13 at 15:23 -0700, Rodrigo Vivi wrote:
> > > The immediate enabling is actually not an issue for the
> > > HW perspective for core platforms that have HW tracking.
> > > HW will wait few identical idle frames before transitioning
> > > to actual psr active anyways.
> > >
> > > Note that this patch also remove the delayed activation
> > > on HSW and BDW introduced by commit 'd0ac896a477d
> > > ("drm/i915: Delay first PSR activation.")'. This was
> > > introduced to fix a blank screen on VLV/CHV and also
> > > masked some frozen screens on other core platforms.
> > > Probably the same that we are now properly hunting and fixing.
> > >
> > > Furthermore, if we stop using delayed activation on core
> > > platforms we will be able, on following up patches,
> > > to use available workarounds to make HW tracking properly
> > > exit PSR instead of the big nuke of disabling psr and
> > > re-enable on exit and activate respectively.
> > > At least on few reliable cases.
> > >
> > > v2:(DK): Remove unnecessary WARN_ONs and make some other
> > >VLV | CHV more readable.
> > > v3: Do it regardless the timer rework.
> > > v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable.
> > > v5: Kill remaining items and fully rework activation functions.
> > >
> > > Cc: Dhinakaran Pandiyan
> > > Signed-off-by: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 20 +++---
> > > drivers/gpu/drm/i915/i915_drv.h | 3 +-
> > > drivers/gpu/drm/i915/intel_psr.c| 134
> > > ++--
> > > 3 files changed, 65 insertions(+), 92 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 972014b2497d..7dfada863f9c 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2567,15 +2567,14 @@ static int i915_edp_psr_status(struct seq_file
> > > *m, void *data)
> > > seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
> > > seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> > > dev_priv->psr.busy_frontbuffer_bits);
> > > - seq_printf(m, "Re-enable work scheduled: %s\n",
> > > -yesno(work_busy(&dev_priv->psr.work.work)));
> > >
> > > - if (HAS_DDI(dev_priv)) {
> > > - if (dev_priv->psr.psr2_support)
> > > - enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> > > - else
> > > - enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> > > - } else {
> > > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > > + bool scheduled;
> > > +
> > > + scheduled = work_busy(&dev_priv->psr.vlv_activate_work.work);
> > > + seq_printf(m, "Re-enable work scheduled: %s\n",
> > > +yesno(scheduled));
> > > +
> > > for_each_pipe(dev_priv, pipe) {
> > > enum transcoder cpu_transcoder =
> > > intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> > > @@ -2594,6 +2593,11 @@ static int i915_edp_psr_status(struct seq_file *m,
> > > void *data)
> > >
> > > intel_display_power_put(dev_priv, power_domain);
> > > }
> > > + } else {
> > > + if (dev_priv->psr.psr2_support)
> > > + enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> > > + else
> > > + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> > > }
> > >
> > > seq_printf(m, "Main link in standby mode: %s\n",
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 74b0e9d8ff62..409997f29e07 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -598,7 +598,7 @@ struct i915_psr {
> > > bool sink_support;
> > > struct intel_dp *enabled;
> > > bool active;
> > > - struct delayed_work work;
> > > + struct delayed_work vlv_activate_work;
> > > unsigned busy_frontbuffer_bits;
> > > bool psr2_support;
> > > bool aux_frame_sync;
> > > @@ -613,7 +613,6 @@ struct i915_psr {
> > > void (*disable_source)(struct intel_dp *,
> > > const struct intel_crtc_state *);
> > > void (*enable_sink)(struct intel_dp *);
> > > - void (*activate)(struct intel_dp *);
> > > void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
> > > };
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 317cb4a12693..bc7b94a06417 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -311,24 +311,6 @@ static void vlv_psr_enable_source(struct intel_dp
> > > *intel_dp,
> > > VLV_EDP_PSR_ENABLE);
> > > }
> > >
> > > -static void vlv_psr_activate(struct int
Re: [Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function
On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry
wrote:
On 14/03/18 13:04, Michal Wajdeczko wrote:
We try to keep all HuC related code in dedicated file.
There is no need to peek HuC register directly during
handling getparam ioctl.
Signed-off-by: Michal Wajdeczko
Cc: Michel Thierry
Cc: Rodrigo Vivi
Cc: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
drivers/gpu/drm/i915/intel_huc.c | 25 +
drivers/gpu/drm/i915/intel_huc.h | 1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index f03555e..a902e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device
*dev, void *data,
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
- intel_runtime_pm_get(dev_priv);
- value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
- intel_runtime_pm_put(dev_priv);
+ value = intel_huc_check_status(&dev_priv->huc);
+ if (value < 0)
+ return value;
break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
diff --git a/drivers/gpu/drm/i915/intel_huc.c
b/drivers/gpu/drm/i915/intel_huc.c
index 1d6c47b..2912852 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
DRM_ERROR("HuC: Authentication failed %d\n", ret);
return ret;
}
+
+/**
+ * intel_huc_check_status() - check HuC status
+ * @huc: intel_huc structure
+ *
+ * This function reads status register to verify if HuC
+ * firmware was successfully loaded.
+ *
+ * Returns positive value if HuC firmware is loaded and verified
+ * and -ENODEV if HuC is not present.
Before if huc was not loaded, get_param would just return 0 and the
ioctl call would be OK.
There is another potential problem, as in case HuC was loaded, this
getparam would return specific bit from register instead of predefined
value that shall indicate "loaded/verified" like "1".
What if this bit from register will be moved on future platforms?
Should we still return this old one?
Maybe there's a test somewhere that would break?
I hope not, and given above concern, I assume we can still modify it.
Is there any documentation what to expect from this getparam?
(I'm not arguing -ENODEV is better).
In all other places (like debugfs) we return -ENODEV if user wants
to access HuC data on platform without HuC, so I think we should be
consistent.
Otherwise,
Reviewed-by: Michel Thierry
+ */
+int intel_huc_check_status(struct intel_huc *huc)
+{
+ struct drm_i915_private *dev_priv = huc_to_i915(huc);
+ u32 status;
+
+ if (!HAS_HUC(dev_priv))
+ return -ENODEV;
+
+ intel_runtime_pm_get(dev_priv);
+ status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+ intel_runtime_pm_put(dev_priv);
+
+ return status;
+}
diff --git a/drivers/gpu/drm/i915/intel_huc.h
b/drivers/gpu/drm/i915/intel_huc.h
index b185850..aa85490 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -37,6 +37,7 @@ struct intel_huc {
void intel_huc_init_early(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_check_status(struct intel_huc *huc);
static inline int intel_huc_sanitize(struct intel_huc *huc)
{
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes
Hi, On 14-03-18 21:49, Pandiyan, Dhinakaran wrote: On Wed, 2018-02-14 at 09:25 +0100, Hans de Goede wrote: Hi, On 12-02-18 18:42, Pandiyan, Dhinakaran wrote: On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote: Hi, On 12-02-18 07:08, Dhinakaran Pandiyan wrote: PSR currently when enabled results in semi-permanent freezes or noticeable cursor lags. https://patchwork.freedesktop.org/series/37598/ will fix long freezes due to frame counter resets. This series has three more fixes - Patch 1 eliminates PSR exit for flips and makes us rely on the HW to do it. Patch 2 fixes cusor move lag by relying on HW to exit PSR. Patch 3 fixes temporary freeze seen with fbdev. With both the series applied, PSR on my SKL ThinkPad feels pretty good. Thank you for your great work on this. Are there any more PSR fixes in the pipeline? Yeah, there are a few more fixes that I hope will appear on the list in the next two weeks or so. Ok, can you send a mail when you're done (in sofar any software is ever "done") and you would like me to ask all people who have been kind enough to test PSR to retest ? Hi Hans, Thanks for your patience and help. I believe the current drm-tip is in a decent shape to retest PSR. Booting with i915.enable_psr = 1 is still needed. The fixes have been mostly developed/tested on gen-9 hardware but they apply to other platforms too. Cool, thank you. Current drm-tip will all be merged into 4.17-rc1, right? Then I think I will just wait for that, most distros already provide rc builds for testing, so that way it will be easy for people to test. Regards, Hans -DK If not I think I should do a custom Fedora kernel build based on 4.15 + recent fixes and ask all my testers to retest with that. I do have some questions before I do this: 1) I believe that only testers with skylake (normal or LP) or newer should re-test, correct? These fixes do apply for HSW/BDW, so essentially all the big cores supporting PSR. But, HSW/BDW need fixes for AUX channel-PSR interaction also. I haven't looked into CHV/VLV. 2) I know there are 2 series (including this one), can someone provide a link to the latest patchwork version of those 2 series, or even better a git branch with 4.15 + those patches? Any patches I'm missing if I pick up these 2 series? https://patchwork.freedesktop.org/series/37598/ https://patchwork.freedesktop.org/series/38067/ 3) I'm thinking 4.15 atm, but I could also do a 4.16-rc1 test kernel instead if that would be better, would that be better ? I can't think of any diff that would affect PSR, but the latest is better I suppose. Ok. Regards, Hans ___ 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] drm/i915: Reword warning for missing cases
On Tue, Mar 13, 2018 at 03:23:54PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 13, 2018 at 01:06:49PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-03-13 13:01:42)
> > > On Tue, Mar 13, 2018 at 12:17:13AM +, Chris Wilson wrote:
> > > > Quoting Lucas De Marchi (2018-03-13 00:03:12)
> > > > > In some places we end up converting switch statements to a series of
> > > > > if/else, particularly when introducing helper functions to handle a
> > > > > group of cases. It's tempting to either leave a wrong warning (since
> > > > > now
> > > > > we don't have a switch case anymore) or to convert to WARN(1, ...),
> > > > > losing what MISSING_CASE() provides: source location and id number.
> > > > >
> > > > > Fix the message to allow reusing MISSING_CASE() - it may not always be
> > > > > correct (e.g. if you are not checking an id anymore), but it avoids
> > > > > useless conversions. A quick grep reveals at least a few users in
> > > > > drivers/gpu/drm/i915/intel_csr.c and drivers/gpu/drm/i915/intel_ddi.c.
> > > > >
> > > > > Signed-off-by: Lucas De Marchi
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_utils.h | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_utils.h
> > > > > b/drivers/gpu/drm/i915/i915_utils.h
> > > > > index 51dbfe5bb418..8cdc21b92f5f 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_utils.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_utils.h
> > > > > @@ -40,7 +40,7 @@
> > > > > #undef WARN_ON_ONCE
> > > > > #define WARN_ON_ONCE(x) WARN_ONCE((x), "%s", "WARN_ON_ONCE("
> > > > > __stringify(x) ")")
> > > > >
> > > > > -#define MISSING_CASE(x) WARN(1, "Missing switch case (%lu) in %s\n",
> > > > > \
> > > > > +#define MISSING_CASE(x) WARN(1, "Missing case (%lu) in %s\n", \
> > > > > (long)(x), __func__)
> > > >
> > > > Whilst here you could make this more informative by:
> > > > "Missing case (%s = %lu) in %s\n", __stringify(x), (long)(x), __func__
> > >
> > > The backtrace isn't enough?
> >
> > Not if we have more than one in a function.
>
> I was just commenting on the __func__ part actually. That seems pretty
> much redundant to me. The stringify part does seem like a decent idea,
> and matches our WARN() trickery pretty well.
Humn... indeed. On a quick look I thought it was there so we wouldn't need a
addr2line.
But we are not even printing the line number, just the function name.
The warning is from the kernel already does that and more.
What about:
#define MISSING_CASE(x) WARN(1, "Missing case (%s == %lu)\n", \
__stringify(x), (unsigned long)(x))
I added a simple hack on probe and I get this:
[ 4535.233717] Missing case (ret == 0)
[ 4535.233868] WARNING: CPU: 1 PID: 795 at drivers/gpu/drm/i915/i915_drv.c:1341
i915_driver_load+0x42/0x10e0 [i915]
Lucas De Marchi
>
> > (Why would we do that, you
> > might ask, and I'd answer if the point is to make this more generic and
> > versatile, then do so. We already have the value, why not then explain
> > what that value is.) And give me a single sentence identifying the missing
> > case makes it much more pleasant.
> > -Chris
>
> --
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Control PSR at runtime through debugfs only
On Wed, Mar 14, 2018 at 12:46:58PM +0100, Maarten Lankhorst wrote:
> Allow controlling link status through i915_edp_psr_status, in the same way
> kernel does.
> This replaces changing the module parameter at runtime, then forcing a
> modeset.
>
> Writing -1 restores the original PSR mode set through the module parameter.
> Writing 0 disables PSR.
> Writing 1 enables PSR with default link standby mode.
> Writing 2 enables PSR with link standby.
> Writing 3 enables PSR with link standby disabled.
>
> Signed-off-by: Maarten Lankhorst
> ---
> This breaks kms_frontbuffer_tracking, and needs the following patch to work:
> https://patchwork.freedesktop.org/patch/209956/
>
> XXX: Make global_enable a tristate, to keep older versions of
> kms_frontbuffer_tracking working?
>
> drivers/gpu/drm/i915/i915_debugfs.c | 182
> +++-
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_params.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h| 7 ++
> drivers/gpu/drm/i915/intel_psr.c| 139 ---
> 5 files changed, 271 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 574fcf234007..534a3b04e6a3 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2546,16 +2546,13 @@ static const char *psr2_live_status(u32 val)
>
> static int i915_edp_psr_status(struct seq_file *m, void *data)
> {
> - struct drm_i915_private *dev_priv = node_to_i915(m->private);
> + struct drm_i915_private *dev_priv = m->private;
> u32 psrperf = 0;
> u32 stat[3];
> enum pipe pipe;
> bool enabled = false;
> bool sink_support;
>
> - if (!HAS_PSR(dev_priv))
> - return -ENODEV;
> -
> sink_support = dev_priv->psr.sink_support;
> seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
> if (!sink_support)
> @@ -2631,6 +2628,181 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
> return 0;
> }
>
> +static bool psr_needs_disable(struct drm_i915_private *dev_priv,
> + bool enable, bool link_standby)
> +{
> + if (!dev_priv->psr.global_enable)
> + return false;
> +
> + if (!enable)
> + return true;
> +
> + if (dev_priv->psr.link_standby != link_standby)
> + return true;
> +
> + return false;
> +}
> +
> +static bool psr_needs_enable(struct drm_i915_private *dev_priv,
> + bool enable)
> +{
> + if (!enable)
> + return false;
> +
> + return !dev_priv->psr.global_enable;
> +}
> +
> +static int __i915_edp_psr_write(struct drm_i915_private *dev_priv,
> + struct drm_modeset_acquire_ctx *ctx,
> + bool enable, bool link_standby)
> +{
> + struct drm_device *dev = &dev_priv->drm;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector;
> + struct drm_encoder *encoder;
> + struct drm_crtc *crtc;
> + int ret;
> + bool needs_enable, found;
> +
> + ret = drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
> + if (ret)
> + return ret;
> +
> + mutex_lock(&dev_priv->psr.lock);
> +retry:
> + if (!dev_priv->psr.enabled) {
> + dev_priv->psr.global_enable = enable;
> + dev_priv->psr.link_standby = link_standby;
> + goto end;
> + }
> + encoder = &dp_to_dig_port(dev_priv->psr.enabled)->base.base;
> + mutex_unlock(&dev_priv->psr.lock);
> +
> + found = false;
> + drm_connector_list_iter_begin(dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter)
> + if (connector->state->best_encoder == encoder) {
> + found = true;
> + break;
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +
> + if (WARN_ON(!found))
> + return -EINVAL;
> +
> + crtc = connector->state->crtc;
> + ret = drm_modeset_lock(&crtc->mutex, ctx);
> + if (ret)
> + return ret;
> +
> + mutex_lock(&dev_priv->psr.lock);
> + if (dev_priv->psr.enabled != enc_to_intel_dp(encoder))
> + goto retry;
> +
> + if ((connector->state->commit &&
> !try_wait_for_completion(&connector->state->commit->hw_done)) ||
> + (crtc->state->commit &&
> !try_wait_for_completion(&crtc->state->commit->hw_done))) {
> + ret = -EBUSY;
> + goto end;
> + }
> +
> + if (psr_needs_disable(dev_priv, enable, link_standby)) {
> + __intel_psr_disable(dev_priv, dev_priv->psr.enabled,
> to_intel_crtc_state(crtc->state));
> + dev_priv->psr.global_enable = false;
> + }
> +
> + needs_enable = psr_needs_enable(dev_priv, enable);
> + dev_priv->psr.global_enable = enable;
> + dev_priv->psr.link_standby = lin
Re: [Intel-gfx] [PATCH v3 0/2] CNL port refactoring
On Wed, Mar 14, 2018 at 01:36:51PM +0530, Mahesh Kumar wrote: > This series fixes CNL PORT_TX_DW5/7_LNO_D register address. > This series also introduces macros to get register address of > CNL_PORT_TX registers instead of defining for each DW instance. > > changes since V1: > completely kill _MMIO_PORT6 macro > changes since V2: > use underscore prefix in macro > merge patch 1 and 2 > changes since V3: > Address review comments pushed to dinq. Thanks for that. > > Mahesh Kumar (2): > drm/i915/cnl; Add macro to get PORT_TX register > drm/i915/cnl: Kill _MMIO_PORT6 macro > > drivers/gpu/drm/i915/i915_reg.h | 147 > > 1 file changed, 44 insertions(+), 103 deletions(-) > > -- > 2.14.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/psr: Test PSR.
== Series Details == Series: drm/i915/psr: Test PSR. URL : https://patchwork.freedesktop.org/series/39989/ State : warning == Summary == Series 39989v1 drm/i915/psr: Test PSR. https://patchwork.freedesktop.org/api/1.0/series/39989/revisions/1/mbox/ Possible new issues: Test gem_mmap: Subgroup basic-small-bo: pass -> DMESG-WARN (fi-skl-6600u) pass -> DMESG-WARN (fi-skl-6700hq) Test gem_mmap_gtt: Subgroup basic-read-write: pass -> DMESG-WARN (fi-skl-6600u) Subgroup basic-small-bo: pass -> DMESG-WARN (fi-skl-6600u) pass -> DMESG-WARN (fi-skl-6700hq) Subgroup basic-small-bo-tiledy: pass -> DMESG-WARN (fi-skl-6600u) Subgroup basic-small-copy: pass -> DMESG-WARN (fi-skl-6700hq) Subgroup basic-wc: pass -> DMESG-WARN (fi-skl-6700hq) Subgroup basic-write-gtt: pass -> DMESG-WARN (fi-skl-6700hq) Test gem_wait: Subgroup basic-busy-all: pass -> DMESG-WARN (fi-skl-6600u) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-skl-6770hq) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-skl-6600u) Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-skl-6600u) fdo#104108 +1 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:442s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:544s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:514s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:506s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s2total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:580s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:586s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:430s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:315s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:409s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:428s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:480s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:431s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:468s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:514s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:651s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:443s fi-skl-6600u total:285 pass:250 dwarn:8 dfail:0 fail:0 skip:27 time:529s fi-skl-6700hqtotal:285 pass:254 dwarn:5 dfail:0 fail:0 skip:26 time:540s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:505s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:495s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:428s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:448s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:564s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:401s Blacklisted hosts: fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:525s 86e964296fe8bc85fdb624fa75b4cd83fcfb58cd drm-tip: 2018y-03m-14d-17h-40m-20s UTC integration manifest cd04825b7dbc drm/i915/psr: Test PSR. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8354/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Test PSR.
On Wed, Mar 14, 2018 at 02:08:14PM -0700, Dhinakaran Pandiyan wrote: > Don't panic, this is just a trial. LOL! :) > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_psr.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index 317cb4a12693..88602614f326 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -1077,9 +1077,7 @@ void intel_psr_init(struct drm_i915_private *dev_priv) > if (!dev_priv->psr.sink_support) > return; > > - /* Per platform default: all disabled. */ > - if (i915_modparams.enable_psr == -1) > - i915_modparams.enable_psr = 0; > + i915_modparams.enable_psr = 1; > > /* Set link_standby x link_off defaults */ > if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) > -- > 2.14.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] [PATCH] drm/i915/psr: Test PSR.
Don't panic, this is just a trial. Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_psr.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 317cb4a12693..88602614f326 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -1077,9 +1077,7 @@ void intel_psr_init(struct drm_i915_private *dev_priv) if (!dev_priv->psr.sink_support) return; - /* Per platform default: all disabled. */ - if (i915_modparams.enable_psr == -1) - i915_modparams.enable_psr = 0; + i915_modparams.enable_psr = 1; /* Set link_standby x link_off defaults */ if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
On Wed, Mar 14, 2018 at 01:20:06PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
>
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
>
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
>
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
> V6: print statement revisions, DP_REV to DPCD_REV, comment correction
> V7: typo
https://patchwork.freedesktop.org/series/39473/
Checkpatch noticed few lines like this over 80 char.
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/drm_dp_helper.c | 18 ++
> include/drm/drm_dp_helper.h | 6 ++
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..793c0ff 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> DP_TRAINING_AUX_RD_MASK;
int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> rd_interval);
DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
rd_interval);
> +
> + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DPCD_REV_14))
> udelay(100);
> else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
> }
> EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> DP_TRAINING_AUX_RD_MASK;
ditto
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> rd_interval);
ditto
> +
> + if (rd_interval == 0)
> udelay(400);
> else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
> }
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..9afea9f 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,11 @@
> /* AUX CH addresses */
> /* DPCD */
> #define DP_DPCD_REV 0x000
> +# define DPCD_REV_100x10
> +# define DPCD_REV_110x11
> +# define DPCD_REV_120x12
> +# define DPCD_REV_130x13
> +# define DPCD_REV_140x14
DP_DPCD_REV_ to match the reg name
>
> #define DP_MAX_LINK_RATE0x001
>
> @@ -118,6 +123,7 @@
> # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher
> */
>
> #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2 */
maybe add "?" to be in sync with the reg offset?
>
> #define DP_ADAPTER_CAP 0x00f /* 1.2 */
> # define DP_FORCE_LOAD_SENSE_CAP (1 << 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
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: Check HuC status in dedicated function
== Series Details == Series: drm/i915/huc: Check HuC status in dedicated function URL : https://patchwork.freedesktop.org/series/39986/ State : success == Summary == Series 39986v1 drm/i915/huc: Check HuC status in dedicated function https://patchwork.freedesktop.org/api/1.0/series/39986/revisions/1/mbox/ Possible new issues: Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-skl-6770hq) Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:446s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:535s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:516s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:519s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:505s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s2total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:582s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:587s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:427s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:318s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:424s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:475s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:429s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:480s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:467s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:514s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:651s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:440s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:530s fi-skl-6700hqtotal:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:544s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:512s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:501s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:242 pass:208 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:398s Blacklisted hosts: fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:545s 86e964296fe8bc85fdb624fa75b4cd83fcfb58cd drm-tip: 2018y-03m-14d-17h-40m-20s UTC integration manifest d9e8e4b60d8c drm/i915/huc: Check HuC status in dedicated function == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8353/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes
On Wed, 2018-02-14 at 09:25 +0100, Hans de Goede wrote: > Hi, > > On 12-02-18 18:42, Pandiyan, Dhinakaran wrote: > > On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote: > >> Hi, > >> > >> On 12-02-18 07:08, Dhinakaran Pandiyan wrote: > >>> PSR currently when enabled results in semi-permanent freezes or noticeable > >>> cursor lags. > >>> > >>> https://patchwork.freedesktop.org/series/37598/ will fix long freezes due > >>> to frame counter resets. > >>> > >>> This series has three more fixes - > >>> Patch 1 eliminates PSR exit for flips and makes us rely on the HW to do > >>> it. > >>> Patch 2 fixes cusor move lag by relying on HW to exit PSR. > >>> Patch 3 fixes temporary freeze seen with fbdev. > >>> > >>> With both the series applied, PSR on my SKL ThinkPad feels pretty good. > >> > >> Thank you for your great work on this. > >> > >> Are there any more PSR fixes in the pipeline? > > > > Yeah, there are a few more fixes that I hope will appear on the list in > > the next two weeks or so. > > Ok, can you send a mail when you're done (in sofar any software is ever > "done") and you would like me to ask all people who have been kind enough > to test PSR to retest ? > Hi Hans, Thanks for your patience and help. I believe the current drm-tip is in a decent shape to retest PSR. Booting with i915.enable_psr = 1 is still needed. The fixes have been mostly developed/tested on gen-9 hardware but they apply to other platforms too. -DK > >> If not I think I should do > >> a custom Fedora kernel build based on 4.15 + recent fixes and ask all my > >> testers to retest with that. > >> > >> I do have some questions before I do this: > >> > >> 1) I believe that only testers with skylake (normal or LP) or newer should > >> re-test, correct? > > > > These fixes do apply for HSW/BDW, so essentially all the big cores > > supporting PSR. But, HSW/BDW need fixes for AUX channel-PSR interaction > > also. I haven't looked into CHV/VLV. > > > >> > >> 2) I know there are 2 series (including this one), can someone provide a > >> link > >> to the latest patchwork version of those 2 series, or even better a git > >> branch with 4.15 + those patches? Any patches I'm missing if I pick up > >> these > >> 2 series? > > > > https://patchwork.freedesktop.org/series/37598/ > > https://patchwork.freedesktop.org/series/38067/ > > > > > >> 3) I'm thinking 4.15 atm, but I could also do a 4.16-rc1 test kernel > >> instead > >> if that would be better, would that be better ? > > > > I can't think of any diff that would affect PSR, but the latest is > > better I suppose. > > Ok. > > Regards, > > Hans > ___ > 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] [RFC v5] drm/i915/psr: Kill scheduled work for Core platforms.
On Wed, Mar 14, 2018 at 01:24:13PM -0700, Pandiyan, Dhinakaran wrote:
> On Tue, 2018-03-13 at 15:23 -0700, Rodrigo Vivi wrote:
> > The immediate enabling is actually not an issue for the
> > HW perspective for core platforms that have HW tracking.
> > HW will wait few identical idle frames before transitioning
> > to actual psr active anyways.
> >
> > Note that this patch also remove the delayed activation
> > on HSW and BDW introduced by commit 'd0ac896a477d
> > ("drm/i915: Delay first PSR activation.")'. This was
> > introduced to fix a blank screen on VLV/CHV and also
> > masked some frozen screens on other core platforms.
> > Probably the same that we are now properly hunting and fixing.
> >
> > Furthermore, if we stop using delayed activation on core
> > platforms we will be able, on following up patches,
> > to use available workarounds to make HW tracking properly
> > exit PSR instead of the big nuke of disabling psr and
> > re-enable on exit and activate respectively.
> > At least on few reliable cases.
> >
> > v2:(DK): Remove unnecessary WARN_ONs and make some other
> > VLV | CHV more readable.
> > v3: Do it regardless the timer rework.
> > v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable.
> > v5: Kill remaining items and fully rework activation functions.
> >
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 20 +++---
> > drivers/gpu/drm/i915/i915_drv.h | 3 +-
> > drivers/gpu/drm/i915/intel_psr.c| 134
> > ++--
> > 3 files changed, 65 insertions(+), 92 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 972014b2497d..7dfada863f9c 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2567,15 +2567,14 @@ static int i915_edp_psr_status(struct seq_file *m,
> > void *data)
> > seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
> > seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> >dev_priv->psr.busy_frontbuffer_bits);
> > - seq_printf(m, "Re-enable work scheduled: %s\n",
> > - yesno(work_busy(&dev_priv->psr.work.work)));
> >
> > - if (HAS_DDI(dev_priv)) {
> > - if (dev_priv->psr.psr2_support)
> > - enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> > - else
> > - enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> > - } else {
> > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > + bool scheduled;
> > +
> > + scheduled = work_busy(&dev_priv->psr.vlv_activate_work.work);
> > + seq_printf(m, "Re-enable work scheduled: %s\n",
> > + yesno(scheduled));
> > +
> > for_each_pipe(dev_priv, pipe) {
> > enum transcoder cpu_transcoder =
> > intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> > @@ -2594,6 +2593,11 @@ static int i915_edp_psr_status(struct seq_file *m,
> > void *data)
> >
> > intel_display_power_put(dev_priv, power_domain);
> > }
> > + } else {
> > + if (dev_priv->psr.psr2_support)
> > + enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> > + else
> > + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> > }
> >
> > seq_printf(m, "Main link in standby mode: %s\n",
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 74b0e9d8ff62..409997f29e07 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -598,7 +598,7 @@ struct i915_psr {
> > bool sink_support;
> > struct intel_dp *enabled;
> > bool active;
> > - struct delayed_work work;
> > + struct delayed_work vlv_activate_work;
> > unsigned busy_frontbuffer_bits;
> > bool psr2_support;
> > bool aux_frame_sync;
> > @@ -613,7 +613,6 @@ struct i915_psr {
> > void (*disable_source)(struct intel_dp *,
> >const struct intel_crtc_state *);
> > void (*enable_sink)(struct intel_dp *);
> > - void (*activate)(struct intel_dp *);
> > void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
> > };
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 317cb4a12693..bc7b94a06417 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -311,24 +311,6 @@ static void vlv_psr_enable_source(struct intel_dp
> > *intel_dp,
> >VLV_EDP_PSR_ENABLE);
> > }
> >
> > -static void vlv_psr_activate(struct intel_dp *intel_dp)
> > -{
> > - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > - struct drm_device *dev = dig_port->base.base.dev;
> > - struct drm_i915_private *dev_pri
[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/drm_dp_helper.c | 18 ++
include/drm/drm_dp_helper.h | 6 ++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..793c0ff 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
rd_interval);
+
+ if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DPCD_REV_14))
udelay(100);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
rd_interval);
+
+ if (rd_interval == 0)
udelay(400);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..9afea9f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
/* AUX CH addresses */
/* DPCD */
#define DP_DPCD_REV 0x000
+# define DPCD_REV_100x10
+# define DPCD_REV_110x11
+# define DPCD_REV_120x12
+# define DPCD_REV_130x13
+# define DPCD_REV_140x14
#define DP_MAX_LINK_RATE0x001
@@ -118,6 +123,7 @@
# define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2 */
#define DP_ADAPTER_CAP 0x00f /* 1.2 */
# define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v5] drm/i915/psr: Kill scheduled work for Core platforms.
On Tue, 2018-03-13 at 15:23 -0700, Rodrigo Vivi wrote:
> The immediate enabling is actually not an issue for the
> HW perspective for core platforms that have HW tracking.
> HW will wait few identical idle frames before transitioning
> to actual psr active anyways.
>
> Note that this patch also remove the delayed activation
> on HSW and BDW introduced by commit 'd0ac896a477d
> ("drm/i915: Delay first PSR activation.")'. This was
> introduced to fix a blank screen on VLV/CHV and also
> masked some frozen screens on other core platforms.
> Probably the same that we are now properly hunting and fixing.
>
> Furthermore, if we stop using delayed activation on core
> platforms we will be able, on following up patches,
> to use available workarounds to make HW tracking properly
> exit PSR instead of the big nuke of disabling psr and
> re-enable on exit and activate respectively.
> At least on few reliable cases.
>
> v2:(DK): Remove unnecessary WARN_ONs and make some other
>VLV | CHV more readable.
> v3: Do it regardless the timer rework.
> v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable.
> v5: Kill remaining items and fully rework activation functions.
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 20 +++---
> drivers/gpu/drm/i915/i915_drv.h | 3 +-
> drivers/gpu/drm/i915/intel_psr.c| 134
> ++--
> 3 files changed, 65 insertions(+), 92 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 972014b2497d..7dfada863f9c 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2567,15 +2567,14 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
> seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
> seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> dev_priv->psr.busy_frontbuffer_bits);
> - seq_printf(m, "Re-enable work scheduled: %s\n",
> -yesno(work_busy(&dev_priv->psr.work.work)));
>
> - if (HAS_DDI(dev_priv)) {
> - if (dev_priv->psr.psr2_support)
> - enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> - else
> - enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> - } else {
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + bool scheduled;
> +
> + scheduled = work_busy(&dev_priv->psr.vlv_activate_work.work);
> + seq_printf(m, "Re-enable work scheduled: %s\n",
> +yesno(scheduled));
> +
> for_each_pipe(dev_priv, pipe) {
> enum transcoder cpu_transcoder =
> intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> @@ -2594,6 +2593,11 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
>
> intel_display_power_put(dev_priv, power_domain);
> }
> + } else {
> + if (dev_priv->psr.psr2_support)
> + enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> + else
> + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> }
>
> seq_printf(m, "Main link in standby mode: %s\n",
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 74b0e9d8ff62..409997f29e07 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -598,7 +598,7 @@ struct i915_psr {
> bool sink_support;
> struct intel_dp *enabled;
> bool active;
> - struct delayed_work work;
> + struct delayed_work vlv_activate_work;
> unsigned busy_frontbuffer_bits;
> bool psr2_support;
> bool aux_frame_sync;
> @@ -613,7 +613,6 @@ struct i915_psr {
> void (*disable_source)(struct intel_dp *,
> const struct intel_crtc_state *);
> void (*enable_sink)(struct intel_dp *);
> - void (*activate)(struct intel_dp *);
> void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *);
> };
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 317cb4a12693..bc7b94a06417 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -311,24 +311,6 @@ static void vlv_psr_enable_source(struct intel_dp
> *intel_dp,
> VLV_EDP_PSR_ENABLE);
> }
>
> -static void vlv_psr_activate(struct intel_dp *intel_dp)
> -{
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = dig_port->base.base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct drm_crtc *crtc = dig_port->base.base.crtc;
> - enum pipe pipe = to_intel_crtc(crtc)->pipe;
> -
> - /*
> - * Let's do the transition from PSR_state 1 (inactive) to
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
On Wed, Mar 14, 2018 at 10:40:08AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
>
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
>
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
>
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
> V6: print statement revisions, DP_REV to DPCD_REV, comment correction
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/drm_dp_helper.c | 18 ++
> include/drm/drm_dp_helper.h | 6 ++
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..392e92e 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> rd_interval);
> +
> + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
s/DP_REV_14/DPCD_REV_14 right?
> udelay(100);
> else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
> }
> EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> rd_interval);
> +
> + if (rd_interval == 0)
> udelay(400);
> else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
> }
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..9afea9f 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,11 @@
> /* AUX CH addresses */
> /* DPCD */
> #define DP_DPCD_REV 0x000
> +# define DPCD_REV_100x10
> +# define DPCD_REV_110x11
> +# define DPCD_REV_120x12
> +# define DPCD_REV_130x13
> +# define DPCD_REV_140x14
>
> #define DP_MAX_LINK_RATE0x001
>
> @@ -118,6 +123,7 @@
> # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher
> */
>
> #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2 */
>
> #define DP_ADAPTER_CAP 0x00f /* 1.2 */
> # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> --
> 2.7.4
>
> ___
> 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] drm/i915/huc: Check HuC status in dedicated function
On 14/03/18 13:04, Michal Wajdeczko wrote:
We try to keep all HuC related code in dedicated file.
There is no need to peek HuC register directly during
handling getparam ioctl.
Signed-off-by: Michal Wajdeczko
Cc: Michel Thierry
Cc: Rodrigo Vivi
Cc: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
drivers/gpu/drm/i915/intel_huc.c | 25 +
drivers/gpu/drm/i915/intel_huc.h | 1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f03555e..a902e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
- intel_runtime_pm_get(dev_priv);
- value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
- intel_runtime_pm_put(dev_priv);
+ value = intel_huc_check_status(&dev_priv->huc);
+ if (value < 0)
+ return value;
break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 1d6c47b..2912852 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
DRM_ERROR("HuC: Authentication failed %d\n", ret);
return ret;
}
+
+/**
+ * intel_huc_check_status() - check HuC status
+ * @huc: intel_huc structure
+ *
+ * This function reads status register to verify if HuC
+ * firmware was successfully loaded.
+ *
+ * Returns positive value if HuC firmware is loaded and verified
+ * and -ENODEV if HuC is not present.
Before if huc was not loaded, get_param would just return 0 and the
ioctl call would be OK. Maybe there's a test somewhere that would break?
(I'm not arguing -ENODEV is better).
Otherwise,
Reviewed-by: Michel Thierry
+ */
+int intel_huc_check_status(struct intel_huc *huc)
+{
+ struct drm_i915_private *dev_priv = huc_to_i915(huc);
+ u32 status;
+
+ if (!HAS_HUC(dev_priv))
+ return -ENODEV;
+
+ intel_runtime_pm_get(dev_priv);
+ status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+ intel_runtime_pm_put(dev_priv);
+
+ return status;
+}
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index b185850..aa85490 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -37,6 +37,7 @@ struct intel_huc {
void intel_huc_init_early(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_check_status(struct intel_huc *huc);
static inline int intel_huc_sanitize(struct intel_huc *huc)
{
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams
On 03/14/2018 12:26 PM, Michal Wajdeczko wrote: On Wed, 14 Mar 2018 19:44:43 +0100, Jackie Li wrote: GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams to be generated correctly, and it also corrects some errors in the diagram description. v2: - Fixed errors in diagram description Signed-off-by: Jackie Li Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_guc.c | 52 -- drivers/gpu/drm/i915/intel_wopcm.c | 44 +--- 2 files changed, 50 insertions(+), 46 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 3eb516e..6a4f36e 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -495,35 +495,37 @@ int intel_guc_resume(struct intel_guc *guc) /** * DOC: GuC Address Space * - * The layout of GuC address space is shown as below: + * The layout of GuC address space is shown below: * - * +==> ++ <== GUC_GGTT_TOP - * ^ | | - * | | | - * | | DRAM | - * | | Memory | - * | | | - * GuC | | - * Address +> ++ <== WOPCM Top - * Space ^ | HW contexts RSVD | - * | | | WOPCM | - * | | +==> ++ <== GuC WOPCM Top - * | GuC ^ | | - * | GGTT | | | - * | Pin GuC | GuC | - * | Bias WOPCM | WOPCM | - * | | Size | | - * | | | | | - * v v v | | - * +=+=+==> ++ <== GuC WOPCM Base - * | Non-GuC WOPCM | - * | (HuC/Reserved) | - * ++ <== WOPCM Base + * :: + * + * +==> ++ <== GUC_GGTT_TOP + * ^ | | + * | | | + * | | DRAM | + * | | Memory | + * | | | + * GuC | | + * Address +> ++ <== WOPCM Top + * Space ^ | HW contexts RSVD | + * | | | WOPCM | + * | | +==> ++ <== GuC WOPCM Top + * | GuC ^ | | + * | GGTT | | | + * | Pin GuC | GuC | + * | Bias WOPCM | WOPCM | + * | | Size | | + * | | | | | + * v v v | | + * +=+=+==> ++ <== GuC WOPCM Base + * | Non-GuC WOPCM | + * | (HuC/Reserved) | + * ++ <== WOPCM Base * * The lower part [0, GuC ggtt_pin_bias) is mapped to WOPCM which consists of * GuC WOPCM and WOPCM reserved for other usage (e.g.RC6 context). The hmm, "lower part [...)" is little ambiguous here, as one may look for "upper part [...)", so maybe better to be explicit: "The lower part of GuC Address Space ie. [0, ggtt_pin_bias) is mapped to WOPCM, while upper part of GuC Address Space ie. [ggtt_pin_bias, GUC_GGTT_TOP) is mapped to DRAM." Agree. it's more clear in this way. but I think we should remove "ie." update it to "The lower part of GuC Address Space [0, ggtt_pin_bias) is mapped to WOPCM"? value of - * the GuC ggtt_pin_bias is determined by the actually GuC WOPCM size which is - * set in GUC_WOPCM_SIZE register. + * the GuC ggtt_pin_bias is determined by the GuC WOPCM size which is set in + * GUC_WOPCM_SIZE register. */ hmm, I'm not sure that above statement is correct, compare your diagram and calculation: guc->ggtt_pin_bias = i915->wopcm.size - i915->wopcm.guc.base; also I would not mention registers here, as we don't read them while calculating bias, so maybe something like this: "The value of ggtt_pin_bias is determined by the WOPCM size and actual GuC WOPCM base." Thanks. Will update it. Regards, -Jackie ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Work around compiler warnings on some kernel configs
On Wed, Mar 14, 2018 at 6:57 PM, Tvrtko Ursulin wrote: > On 14/03/2018 08:31, Patchwork wrote: > > Pushed it, thanks for the review! > > (And I forgot to copy Arnd on the patch..) > > So Arnd, sorry, I forgot Reported-by does not add Cc from git send-email. > https://patchwork.freedesktop.org/series/39939/ is my version of the fix for > this. (Now merged.) Hopefully it works for your randconfigs as well and > thanks for sending a patch in the first place! The patch looks good to me, thanks for the follow-up Acked-by: Arnd Bergmann I didn't test it, but you'll hear from me if it breaks again. One comment about the use of spin_lock_irqsave(), you wrote: "Slight penalty we now pay is an additional irqsave spin lock/unlock cycle on the event enable path. But since enable is not a fast path, that is preferrable to the alternative solution which was doing MMIO under irqsave spinlock." While I don't know about the exact cost on x86, on many architectures spin_lock_irqsave()/spin_unlock_irqrestore() is much more expensive than a plain spin_lock()/spin_unlock() or spin_lock_irq()/spin_unlock_irq() pair that doesn't have to store the disabled-state. I see you already removed the inner irqsave()/irqrestore() pair that is now useless (I failed to notice that in my original patch), but in my experience, it's usually possible to do the same for many others as well after proving that a function is always called with IRQs enabled or always disabled. Arnd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function
We try to keep all HuC related code in dedicated file.
There is no need to peek HuC register directly during
handling getparam ioctl.
Signed-off-by: Michal Wajdeczko
Cc: Michel Thierry
Cc: Rodrigo Vivi
Cc: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
drivers/gpu/drm/i915/intel_huc.c | 25 +
drivers/gpu/drm/i915/intel_huc.h | 1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f03555e..a902e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
- intel_runtime_pm_get(dev_priv);
- value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
- intel_runtime_pm_put(dev_priv);
+ value = intel_huc_check_status(&dev_priv->huc);
+ if (value < 0)
+ return value;
break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 1d6c47b..2912852 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
DRM_ERROR("HuC: Authentication failed %d\n", ret);
return ret;
}
+
+/**
+ * intel_huc_check_status() - check HuC status
+ * @huc: intel_huc structure
+ *
+ * This function reads status register to verify if HuC
+ * firmware was successfully loaded.
+ *
+ * Returns positive value if HuC firmware is loaded and verified
+ * and -ENODEV if HuC is not present.
+ */
+int intel_huc_check_status(struct intel_huc *huc)
+{
+ struct drm_i915_private *dev_priv = huc_to_i915(huc);
+ u32 status;
+
+ if (!HAS_HUC(dev_priv))
+ return -ENODEV;
+
+ intel_runtime_pm_get(dev_priv);
+ status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+ intel_runtime_pm_put(dev_priv);
+
+ return status;
+}
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index b185850..aa85490 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -37,6 +37,7 @@ struct intel_huc {
void intel_huc_init_early(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_check_status(struct intel_huc *huc);
static inline int intel_huc_sanitize(struct intel_huc *huc)
{
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.
On 03/14/2018 11:26 AM, Pandiyan, Dhinakaran wrote:
On Wed, 2018-03-14 at 15:35 +0200, Ville Syrjälä wrote:
On Tue, Mar 13, 2018 at 10:48:25PM -0700, Dhinakaran Pandiyan wrote:
If bios sets up an MST output and hardware state readout code sees this is
an SST configuration, when disabling the encoder we end up calling
->post_disable_dp() hook instead of the MST version. Consequently, we write
to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
the MST hub. This results in continuous link training failures which keep
the system busy delaying boot. We could identify bios MST boot discrepancy
and handle it accordingly but a simple way to solve this is to write to the
DP_SET_POWER dpcd for MST too.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
Cc: Ville Syrjälä
Cc: Jani Nikula
Reported-by: Laura Abbott
Cc: sta...@vger.kernel.org
Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message
transactions for dpms control")
Tested-by: Laura Abbott
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_ddi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index dbcf1a0586f9..8c2d778560f0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2205,8 +2205,7 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
intel_ddi_init_dp_buf_reg(encoder);
- if (!is_mst)
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
The spec is perhaps a bit unclear on this.
"If the message is sent as a path request, all DP nodes from the source
immediate downstream device and the targeted DP node will be placed in
the D0 power state."
Doesn't quite tell me whether the immediate downstream device is
included in that list of nodes.
However the spec goes on to say
"Each nodes immediate upstream device will use Native AUX writes to the
SET_POWER & SET_DP_PWR_VOLTAGE register (DPCD Address 00600h) to set
the power state of the downstream node."
and since we are the immediate upstream for that device I guess it makes
sense that we should still do the DP_SET_POWER manually.
But I have to wonder what the original issue was before we started to use
POWER_UP/DOWN_PHY. I suppose somehow some further downstream device
wasn't in D0 when we needed it.
Correct, sinks farther downstream weren't lighting up.
But that is a bit weird as I believe all
devices should really start up in D0.
Anyways based on my reading of the spec I can justify this so
Reviewed-by: Ville Syrjälä
Thanks for the review.
I presume we want cc:stable + fixes: on this?
Yeah, I suppose we should wait for the reporter to confirm that this
indeed fixes the bug. It does fix the problem on the Thinkpad laptop +
dock I tested it on.
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
@@ -2304,14 +2303,12 @@ static void intel_ddi_post_disable_dp(struct
intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
struct intel_dp *intel_dp = &dig_port->dp;
- bool is_mst = intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST);
/*
* Power down sink before disabling the port, otherwise we end
* up getting interrupts from the sink on detecting link loss.
*/
- if (!is_mst)
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_disable_ddi_buf(encoder);
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: drop various VLAs in i915_debugfs.c
== Series Details == Series: drm/i915: drop various VLAs in i915_debugfs.c URL : https://patchwork.freedesktop.org/series/39985/ State : failure == Summary == Applying: drm/i915: drop various VLAs in i915_debugfs.c error: Failed to merge in the changes. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_debugfs.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_debugfs.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_debugfs.c Patch failed at 0001 drm/i915: drop various VLAs in i915_debugfs.c The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: drop various VLAs in i915_debugfs.c
Avoid 3 VLAs[1] by using real constant expressions instead of variables.
The compiler should be able to optimize the original code and avoid using
any actual VLAs. Anyway this change is useful because it will avoid a false
positives with -Wvla, it might also help the compiler generating better
code.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Salvatore Mesoraca
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e968aea..bf0a8e3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4259,19 +4259,20 @@ static ssize_t cur_wm_latency_write(struct file *file,
const char __user *ubuf,
i915_cache_sharing_get, i915_cache_sharing_set,
"%llu\n");
+#define CHERRYVIEW_SS_MAX 2
+
static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
{
- int ss_max = 2;
int ss;
- u32 sig1[ss_max], sig2[ss_max];
+ u32 sig1[CHERRYVIEW_SS_MAX], sig2[CHERRYVIEW_SS_MAX];
sig1[0] = I915_READ(CHV_POWER_SS0_SIG1);
sig1[1] = I915_READ(CHV_POWER_SS1_SIG1);
sig2[0] = I915_READ(CHV_POWER_SS0_SIG2);
sig2[1] = I915_READ(CHV_POWER_SS1_SIG2);
- for (ss = 0; ss < ss_max; ss++) {
+ for (ss = 0; ss < CHERRYVIEW_SS_MAX; ss++) {
unsigned int eu_cnt;
if (sig1[ss] & CHV_SS_PG_ENABLE)
@@ -4290,15 +4291,17 @@ static void cherryview_sseu_device_status(struct
drm_i915_private *dev_priv,
}
}
+#define GEN10_S_MAX 6
+#define GEN10_SS_MAX 4
+
static void gen10_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
{
const struct intel_device_info *info = INTEL_INFO(dev_priv);
- int s_max = 6, ss_max = 4;
int s, ss;
- u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+ u32 s_reg[GEN10_S_MAX], eu_reg[2 * GEN10_S_MAX], eu_mask[2];
- for (s = 0; s < s_max; s++) {
+ for (s = 0; s < GEN10_S_MAX; s++) {
/*
* FIXME: Valid SS Mask respects the spec and read
* only valid bits for those registers, excluding reserverd
@@ -4320,7 +4323,7 @@ static void gen10_sseu_device_status(struct
drm_i915_private *dev_priv,
GEN9_PGCTL_SSB_EU210_ACK |
GEN9_PGCTL_SSB_EU311_ACK;
- for (s = 0; s < s_max; s++) {
+ for (s = 0; s < GEN10_S_MAX; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4328,7 +4331,7 @@ static void gen10_sseu_device_status(struct
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslice_mask = info->sseu.subslice_mask;
- for (ss = 0; ss < ss_max; ss++) {
+ for (ss = 0; ss < GEN10_SS_MAX; ss++) {
unsigned int eu_cnt;
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4345,12 +4348,15 @@ static void gen10_sseu_device_status(struct
drm_i915_private *dev_priv,
}
}
+#define GEN9_S_MAX 3
+#define GEN9_SS_MAX 4
+
static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
{
- int s_max = 3, ss_max = 4;
+ int s_max = GEN9_S_MAX, ss_max = GEN9_SS_MAX;
int s, ss;
- u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
+ u32 s_reg[GEN9_S_MAX], eu_reg[2*GEN9_S_MAX], eu_mask[2];
/* BXT has a single slice and at most 3 subslices. */
if (IS_GEN9_LP(dev_priv)) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drop various VLAs in i915_debugfs.c
2018-03-14 13:27 GMT+01:00 Joonas Lahtinen : > CHV_SS_MAX should be good enough. Make these function scoped (so #define > at the beginning and #undef at the end of function). > > Do use ARRAY_SIZE() instead of repeating. Thank you very much for your suggestions. Unfortunately, it seems that someone else already fixed this issue, so I'll just drop this patch. Best regards, Salvatore ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drop various VLAs in i915_debugfs.c
2018-03-14 13:17 GMT+01:00 Jani Nikula :
> Thanks for your patch. However, Chris beat you to it with:
>
> 7aa0b14ede64 ("drm/i915: Remove variable length arrays from sseu debugfs
> printers")
I didn't notice it :)
> as well as adding -Wvla to our subdir-ccflags-y to prevent more from
> cropping up:
>
> c5c2b11894f4 ("drm/i915: Warn against variable length arrays")
Great!
Best regards,
Salvatore
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
On Tue, Mar 13, 2018 at 02:47:45PM -0700, Alexei Starovoitov wrote:
> On 3/13/18 2:37 PM, Roman Gushchin wrote:
> > On Tue, Mar 13, 2018 at 02:27:58PM -0700, Alexei Starovoitov wrote:
> > > On 3/13/18 1:50 PM, Tejun Heo wrote:
> > > > Hello, Matt.
> > > >
> > > > cc'ing Roman and Alexei.
> > > >
> > > > On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote:
> > > > > There are cases where other parts of the kernel may wish to store data
> > > > > associated with individual cgroups without building a full cgroup
> > > > > controller. Let's add interfaces to allow them to register and lookup
> > > > > this private data for individual cgroups.
> > > > >
> > > > > A kernel system (e.g., a driver) that wishes to register private data
> > > > > for a cgroup will do so by subclassing the 'struct cgroup_priv'
> > > > > structure to describe the necessary data to store. Before
> > > > > registering a
> > > > > private data structure to a cgroup, the caller should fill in the
> > > > > 'key'
> > > > > and 'free' fields of the base cgroup_priv structure.
> > > > >
> > > > > * 'key' should be a unique void* that will act as a key for future
> > > > >privdata lookups/removals. Note that this allows drivers to store
> > > > >per-device private data for a cgroup by using a device pointer as
> > > > > a key.
> > > > >
> > > > > * 'free' should be a function pointer to a function that may be used
> > > > >to destroy the private data. This function will be called
> > > > >automatically if the underlying cgroup is destroyed.
> > > >
> > > > This feature turned out to have more users than I originally
> > > > anticipated and bpf also wants something like this to track network
> > > > states. The requirements are pretty similar but not quite the same.
> > > > The extra requirements are...
> > > >
> > > > * Lookup must be really cheap. Probably using pointer hash or walking
> > > > list isn't great, so maybe idr based lookup + RCU protected index
> > > > table per cgroup?
> > > >
> > > > * It should support both regular memory and percpu pointers. Given
> > > > that what cgroup does is pretty much cgroup:key -> pointer lookup,
> > > > it's mostly about getting the interface right so that it's not too
> > > > error-prone.
> > >
> > > from bpf side there should be _zero_ lookups.
> > > If bpf do a lookup it can equally use its own map to do that.
> > >
> > > From bpf program point of view it will look like:
> > > struct my_data {
> > > u64 a;
> > > u32 b;
> > > } *ptr;
> > > ptr = bpf_get_cgroup_buf(skb, sizeof(struct my_data));
> > >
> > > bpf_get_cgroup_buf() is lookup-free. Worst case it will do pointer
> > > dereferences
> > > skb->sk->sk_cgrp_data->val to get to cgroup and from cgroup to get pointer
> > > to the buffer.
> >
> > Having strictly one buffer per-cgroup sounds very limiting.
> > What if two independent bpf programs start using it?
> >
> > > In good case it may be optimized (inlined) by the verifier into absolute
> > > address of that cgroup scratch buffer at attach time.
> >
> > Maybe we can have an idr-based index table (as Tejun suggested above),
> > but avoid performance penalty by optimizing the lookup out at the attach
> > time?
>
> it has to be zero lookups. If idr lookup is involved, it's cleaner
> to add idr as new bpf map type and use cgroup ino as an id.
>
Hm, what if we will have a buffer attached to a bpf program attached to a
cgroup?
Then we will have zero lookups on a hot path, but independent bpf programs
will be able to use their own buffers.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
On Tue, Mar 13, 2018 at 03:42:20PM -0700, Alexei Starovoitov wrote: > On 3/13/18 3:13 PM, Tejun Heo wrote: > > Hello, > > > > On Tue, Mar 13, 2018 at 02:47:45PM -0700, Alexei Starovoitov wrote: > > > it has to be zero lookups. If idr lookup is involved, it's cleaner > > > to add idr as new bpf map type and use cgroup ino as an id. > > > > Oh, idr (or rather ida) is just to allocate the key, once the key is > > there it pretty much should boil down to sth like > > > > rcu_read_lock(); > > table = rcu_deref(cgrp->table); > > if (key < table->len) > > ret = table[key]; > > else > > ret = NULL; > > rcu_read_unlock(); > > > > Depending on the requirements, we can get rid of the table->len check > > by making key alloc path more expensive (ie. give out key only after > > table extension is fully done and propagated). > > just like two bpf progs can be attached to the same cgroup > the same bpf prog can be attached to multiple cgroups. > If we use ida to allocate an id and store it bpf->aux->cgroup_table_key > to later do: cgrp->table[bpf->aux->cgroup_table_key] > this id==key would need to valid across multiple cgroups which > complicates things a lot. > > It feels that we need something similar to compute_effective_progs() > but for this scratch buffers. > Then at the time of BPF_PROG_RUN_ARRAY supply corresponding > scratch buffer for every program. > Next to cgrp->bpf.effective[type] have similar array of pointers > to scratch buffers. Sorry, if I wasn't clear, this is exactly what I mean in my prev letter: make a pointer to a scratch buffer unique per (cgroup, attached program) pair. Then we'll have zero lookups on a hot path, but keep the flexibility.. Sounds very good to me. Thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
On Tue, Mar 13, 2018 at 02:27:58PM -0700, Alexei Starovoitov wrote:
> On 3/13/18 1:50 PM, Tejun Heo wrote:
> > Hello, Matt.
> >
> > cc'ing Roman and Alexei.
> >
> > On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote:
> > > There are cases where other parts of the kernel may wish to store data
> > > associated with individual cgroups without building a full cgroup
> > > controller. Let's add interfaces to allow them to register and lookup
> > > this private data for individual cgroups.
> > >
> > > A kernel system (e.g., a driver) that wishes to register private data
> > > for a cgroup will do so by subclassing the 'struct cgroup_priv'
> > > structure to describe the necessary data to store. Before registering a
> > > private data structure to a cgroup, the caller should fill in the 'key'
> > > and 'free' fields of the base cgroup_priv structure.
> > >
> > > * 'key' should be a unique void* that will act as a key for future
> > >privdata lookups/removals. Note that this allows drivers to store
> > >per-device private data for a cgroup by using a device pointer as a
> > > key.
> > >
> > > * 'free' should be a function pointer to a function that may be used
> > >to destroy the private data. This function will be called
> > >automatically if the underlying cgroup is destroyed.
> >
> > This feature turned out to have more users than I originally
> > anticipated and bpf also wants something like this to track network
> > states. The requirements are pretty similar but not quite the same.
> > The extra requirements are...
> >
> > * Lookup must be really cheap. Probably using pointer hash or walking
> > list isn't great, so maybe idr based lookup + RCU protected index
> > table per cgroup?
> >
> > * It should support both regular memory and percpu pointers. Given
> > that what cgroup does is pretty much cgroup:key -> pointer lookup,
> > it's mostly about getting the interface right so that it's not too
> > error-prone.
>
> from bpf side there should be _zero_ lookups.
> If bpf do a lookup it can equally use its own map to do that.
>
> From bpf program point of view it will look like:
> struct my_data {
> u64 a;
> u32 b;
> } *ptr;
> ptr = bpf_get_cgroup_buf(skb, sizeof(struct my_data));
>
> bpf_get_cgroup_buf() is lookup-free. Worst case it will do pointer
> dereferences
> skb->sk->sk_cgrp_data->val to get to cgroup and from cgroup to get pointer
> to the buffer.
Having strictly one buffer per-cgroup sounds very limiting.
What if two independent bpf programs start using it?
> In good case it may be optimized (inlined) by the verifier into absolute
> address of that cgroup scratch buffer at attach time.
Maybe we can have an idr-based index table (as Tejun suggested above),
but avoid performance penalty by optimizing the lookup out at the attach time?
Thanks!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
On 3/13/18 3:13 PM, Tejun Heo wrote: Hello, On Tue, Mar 13, 2018 at 02:47:45PM -0700, Alexei Starovoitov wrote: it has to be zero lookups. If idr lookup is involved, it's cleaner to add idr as new bpf map type and use cgroup ino as an id. Oh, idr (or rather ida) is just to allocate the key, once the key is there it pretty much should boil down to sth like rcu_read_lock(); table = rcu_deref(cgrp->table); if (key < table->len) ret = table[key]; else ret = NULL; rcu_read_unlock(); Depending on the requirements, we can get rid of the table->len check by making key alloc path more expensive (ie. give out key only after table extension is fully done and propagated). just like two bpf progs can be attached to the same cgroup the same bpf prog can be attached to multiple cgroups. If we use ida to allocate an id and store it bpf->aux->cgroup_table_key to later do: cgrp->table[bpf->aux->cgroup_table_key] this id==key would need to valid across multiple cgroups which complicates things a lot. It feels that we need something similar to compute_effective_progs() but for this scratch buffers. Then at the time of BPF_PROG_RUN_ARRAY supply corresponding scratch buffer for every program. Next to cgrp->bpf.effective[type] have similar array of pointers to scratch buffers. We probably need to think through how the same mechanism can be used for per-socket scratch buffers. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
On 3/13/18 2:37 PM, Roman Gushchin wrote:
On Tue, Mar 13, 2018 at 02:27:58PM -0700, Alexei Starovoitov wrote:
On 3/13/18 1:50 PM, Tejun Heo wrote:
Hello, Matt.
cc'ing Roman and Alexei.
On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote:
There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller. Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.
A kernel system (e.g., a driver) that wishes to register private data
for a cgroup will do so by subclassing the 'struct cgroup_priv'
structure to describe the necessary data to store. Before registering a
private data structure to a cgroup, the caller should fill in the 'key'
and 'free' fields of the base cgroup_priv structure.
* 'key' should be a unique void* that will act as a key for future
privdata lookups/removals. Note that this allows drivers to store
per-device private data for a cgroup by using a device pointer as a key.
* 'free' should be a function pointer to a function that may be used
to destroy the private data. This function will be called
automatically if the underlying cgroup is destroyed.
This feature turned out to have more users than I originally
anticipated and bpf also wants something like this to track network
states. The requirements are pretty similar but not quite the same.
The extra requirements are...
* Lookup must be really cheap. Probably using pointer hash or walking
list isn't great, so maybe idr based lookup + RCU protected index
table per cgroup?
* It should support both regular memory and percpu pointers. Given
that what cgroup does is pretty much cgroup:key -> pointer lookup,
it's mostly about getting the interface right so that it's not too
error-prone.
from bpf side there should be _zero_ lookups.
If bpf do a lookup it can equally use its own map to do that.
From bpf program point of view it will look like:
struct my_data {
u64 a;
u32 b;
} *ptr;
ptr = bpf_get_cgroup_buf(skb, sizeof(struct my_data));
bpf_get_cgroup_buf() is lookup-free. Worst case it will do pointer
dereferences
skb->sk->sk_cgrp_data->val to get to cgroup and from cgroup to get pointer
to the buffer.
Having strictly one buffer per-cgroup sounds very limiting.
What if two independent bpf programs start using it?
In good case it may be optimized (inlined) by the verifier into absolute
address of that cgroup scratch buffer at attach time.
Maybe we can have an idr-based index table (as Tejun suggested above),
but avoid performance penalty by optimizing the lookup out at the attach time?
it has to be zero lookups. If idr lookup is involved, it's cleaner
to add idr as new bpf map type and use cgroup ino as an id.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
On 3/13/18 1:50 PM, Tejun Heo wrote:
Hello, Matt.
cc'ing Roman and Alexei.
On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote:
There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller. Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.
A kernel system (e.g., a driver) that wishes to register private data
for a cgroup will do so by subclassing the 'struct cgroup_priv'
structure to describe the necessary data to store. Before registering a
private data structure to a cgroup, the caller should fill in the 'key'
and 'free' fields of the base cgroup_priv structure.
* 'key' should be a unique void* that will act as a key for future
privdata lookups/removals. Note that this allows drivers to store
per-device private data for a cgroup by using a device pointer as a key.
* 'free' should be a function pointer to a function that may be used
to destroy the private data. This function will be called
automatically if the underlying cgroup is destroyed.
This feature turned out to have more users than I originally
anticipated and bpf also wants something like this to track network
states. The requirements are pretty similar but not quite the same.
The extra requirements are...
* Lookup must be really cheap. Probably using pointer hash or walking
list isn't great, so maybe idr based lookup + RCU protected index
table per cgroup?
* It should support both regular memory and percpu pointers. Given
that what cgroup does is pretty much cgroup:key -> pointer lookup,
it's mostly about getting the interface right so that it's not too
error-prone.
from bpf side there should be _zero_ lookups.
If bpf do a lookup it can equally use its own map to do that.
From bpf program point of view it will look like:
struct my_data {
u64 a;
u32 b;
} *ptr;
ptr = bpf_get_cgroup_buf(skb, sizeof(struct my_data));
bpf_get_cgroup_buf() is lookup-free. Worst case it will do pointer
dereferences
skb->sk->sk_cgrp_data->val to get to cgroup and from cgroup to get
pointer to the buffer.
In good case it may be optimized (inlined) by the verifier into absolute
address of that cgroup scratch buffer at attach time.
sizeof(struct my_data) will be seen by verifier and it will propagate it
into prog->aux.
Later at prog attach time the kernel will request allocation via
cgroup_malloc(cgrp)
This scratch memory will be available per-cgroup and can be further
divided by the bpf program.
The bound checks will be done statically by the verifier similar to map
values.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Engine discovery query
== Series Details == Series: drm/i915: Engine discovery query URL : https://patchwork.freedesktop.org/series/39958/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 shard-apltotal:3401 pass:1795 dwarn:1 dfail:0 fail:7 skip:1596 time:12800s shard-hswtotal:3444 pass:1769 dwarn:1 dfail:0 fail:2 skip:1671 time:11958s shard-snbtotal:3444 pass:1360 dwarn:1 dfail:0 fail:2 skip:2081 time:7290s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8343/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev2)
== Series Details == Series: drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev2) URL : https://patchwork.freedesktop.org/series/39979/ State : success == Summary == Series 39979v2 drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams https://patchwork.freedesktop.org/api/1.0/series/39979/revisions/2/mbox/ Possible new issues: Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-skl-6770hq) fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:428s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:441s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:383s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:536s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:516s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:515s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:501s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-cfl-s2total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:584s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:587s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:314s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:474s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:433s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:475s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:467s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:511s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:659s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:438s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:528s fi-skl-6700hqtotal:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:540s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:502s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:490s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:564s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:399s Blacklisted hosts: fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:533s 86e964296fe8bc85fdb624fa75b4cd83fcfb58cd drm-tip: 2018y-03m-14d-17h-40m-20s UTC integration manifest d844e97e5304 drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8351/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams
On Wed, 14 Mar 2018 19:44:43 +0100, Jackie Li wrote: GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams to be generated correctly, and it also corrects some errors in the diagram description. v2: - Fixed errors in diagram description Signed-off-by: Jackie Li Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_guc.c | 52 -- drivers/gpu/drm/i915/intel_wopcm.c | 44 +--- 2 files changed, 50 insertions(+), 46 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 3eb516e..6a4f36e 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -495,35 +495,37 @@ int intel_guc_resume(struct intel_guc *guc) /** * DOC: GuC Address Space * - * The layout of GuC address space is shown as below: + * The layout of GuC address space is shown below: * - *+==> ++ <== GUC_GGTT_TOP - *^|| - *||| - *||DRAM| - *|| Memory | - *||| - * GuC || - * Address +> ++ <== WOPCM Top - * Space ^ | HW contexts RSVD | - *| | |WOPCM | - *| | +==> ++ <== GuC WOPCM Top - *|GuC^|| - *|GGTT ||| - *|Pin GuC |GuC | - *|Bias WOPCM | WOPCM| - *| |Size || - *| | ||| - *v v v|| - *+=+=+==> ++ <== GuC WOPCM Base - * | Non-GuC WOPCM| - * | (HuC/Reserved) | - * ++ <== WOPCM Base + * :: + * + * +==> ++ <== GUC_GGTT_TOP + * ^|| + * ||| + * ||DRAM| + * || Memory | + * ||| + *GuC || + * Address +> ++ <== WOPCM Top + * Space ^ | HW contexts RSVD | + * | | |WOPCM | + * | | +==> ++ <== GuC WOPCM Top + * |GuC^|| + * |GGTT ||| + * |Pin GuC |GuC | + * |Bias WOPCM | WOPCM| + * | |Size || + * | | ||| + * v v v|| + * +=+=+==> ++ <== GuC WOPCM Base + * | Non-GuC WOPCM| + * | (HuC/Reserved) | + * ++ <== WOPCM Base * * The lower part [0, GuC ggtt_pin_bias) is mapped to WOPCM which consists of * GuC WOPCM and WOPCM reserved for other usage (e.g.RC6 context). The hmm, "lower part [...)" is little ambiguous here, as one may look for "upper part [...)", so maybe better to be explicit: "The lower part of GuC Address Space ie. [0, ggtt_pin_bias) is mapped to WOPCM, while upper part of GuC Address Space ie. [ggtt_pin_bias, GUC_GGTT_TOP) is mapped to DRAM." value of - * the GuC ggtt_pin_bias is determined by the actually GuC WOPCM size which is - * set in GUC_WOPCM_SIZE register. + * the GuC ggtt_pin_bias is determined by the GuC WOPCM size which is set in + * GUC_WOPCM_SIZE register. */ hmm, I'm not sure that above statement is correct, compare your diagram and calculation: guc->ggtt_pin_bias = i915->wopcm.size - i915->wopcm.guc.base; also I would not mention registers here, as we don't read them while calculating bias, so maybe something like this: "The value of ggtt_pin_bias is determined by the WOPCM size and actual GuC WOPCM base." /Michal ___ 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/guc: Unify naming of private GuC action functions
== Series Details == Series: drm/i915/guc: Unify naming of private GuC action functions URL : https://patchwork.freedesktop.org/series/39982/ State : warning == Summary == Series 39982v1 drm/i915/guc: Unify naming of private GuC action functions https://patchwork.freedesktop.org/api/1.0/series/39982/revisions/1/mbox/ Possible new issues: Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-skl-6770hq) Test kms_force_connector_basic: Subgroup force-connector-state: pass -> SKIP (fi-ivb-3520m) Subgroup force-edid: pass -> SKIP (fi-ivb-3520m) Subgroup force-load-detect: pass -> SKIP (fi-ivb-3520m) Subgroup prune-stale-modes: pass -> SKIP (fi-ivb-3520m) Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:436s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:441s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:378s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:535s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:511s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:517s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:503s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:409s fi-cfl-s2total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:580s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:509s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:588s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:425s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:315s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:532s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:421s fi-ivb-3520m total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:471s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:430s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:478s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:462s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:514s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:662s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:436s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:531s fi-skl-6700hqtotal:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:540s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:506s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:425s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:242 pass:208 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:399s Blacklisted hosts: fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:546s 86e964296fe8bc85fdb624fa75b4cd83fcfb58cd drm-tip: 2018y-03m-14d-17h-40m-20s UTC integration manifest 4a9184965adc drm/i915/guc: Unify naming of private GuC action functions == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8350/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12
Op 14-03-18 om 18:08 schreef Ville Syrjälä:
> On Wed, Mar 14, 2018 at 04:55:08PM +0100, Maarten Lankhorst wrote:
>> Op 14-03-18 om 16:35 schreef Ville Syrjälä:
>>> On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote:
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, March 14, 2018 4:03 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: Syrjala, Ville ; Lankhorst, Maarten
>
> Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max
> scale
> for NV12
>
> Op 14-03-18 om 11:31 schreef Srinivas, Vidya:
>>> -Original Message-
>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>>> Sent: Wednesday, March 14, 2018 3:55 PM
>>> To: Srinivas, Vidya ; intel-
>>> g...@lists.freedesktop.org
>>> Cc: Syrjala, Ville ; Lankhorst, Maarten
>>>
>>> Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler
>>> max scale for NV12
>>>
>>> Op 14-03-18 om 10:52 schreef Maarten Lankhorst:
Op 09-03-18 om 09:48 schreef Vidya Srinivas:
> From: Chandra Konduru
>
> This patch updates scaler max limit support for NV12
>
> v2: Rebased (me)
>
> v3: Rebased (me)
>
> v4: Missed the Tested-by/Reviewed-by in the previous series Adding
> the same to commit message in this version.
>
> v5: Addressed review comments from Ville and rebased
> - calculation of max_scale to be made less convoluted by splitting
> it up a bit
> - Indentation errors to be fixed in the series
>
> v6: Rebased (me)
> Fixed review comments from Paauwe, Bob J Previous version, where a
> split of calculation was done, was wrong. Fixed that issue here.
>
> v7: Rebased (me)
>
> v8: Rebased (me)
>
> v9: Rebased (me)
>
> v10: Rebased (me)
>
> v11: Addressed review comments from Shashank Sharma Alignment
>>> issues
> fixed.
> When call to skl_update_scaler is made, 0 was being sent instead of
> pixel_format.
> When crtc update scaler is called, we dont have the fb to derive
> the pixel format. Added the function parameter bool
> plane_scaler_check to account for this.
>
> v12: Fixed failure in IGT debugfs_test.
> fb is NULL in skl_update_scaler_plane Due to this, accessing
> fb->format caused failure.
> Patch checks fb before using.
>
> v13: In the previous version there was a flaw.
> In skl_update_scaler during plane_scaler_check if the format was
> non-NV12, it would set need_scaling to false. This could reset the
> previously set need_scaling from a previous condition check. Patch
> fixes this.
> Patch also adds minimum src height for YUV 420 formats to 16 (as
> defined in BSpec) and adds for checking this range.
>
> Tested-by: Clinton Taylor
> Reviewed-by: Clinton Taylor
> Signed-off-by: Chandra Konduru
> Signed-off-by: Nabendu Maiti
> Signed-off-by: Uma Shankar
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/i915/intel_display.c | 78
>>> ++--
> drivers/gpu/drm/i915/intel_drv.h | 4 +-
> drivers/gpu/drm/i915/intel_sprite.c | 3 +-
> 3 files changed, 61 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 34f7225..7fd8354 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3466,6 +3466,8 @@ static u32 skl_plane_ctl_format(uint32_t
>>> pixel_format)
> return PLANE_CTL_FORMAT_YUV422 |
>>> PLANE_CTL_YUV422_UYVY;
> case DRM_FORMAT_VYUY:
> return PLANE_CTL_FORMAT_YUV422 |
>>> PLANE_CTL_YUV422_VYUY;
> + case DRM_FORMAT_NV12:
> + return PLANE_CTL_FORMAT_NV12;
> default:
> MISSING_CASE(pixel_format);
> }
> @@ -4705,7 +4707,9 @@ static void cpt_verify_modeset(struct
> drm_device *dev, int pipe) static int skl_update_scaler(struct
> intel_crtc_state *crtc_state, bool force_detach,
> unsigned int scaler_user, int *scaler_id,
> - int src_w, int src_h, int dst_w, int dst_h)
> + int src_w, int src_h, int dst_w, int dst_h,
> + bool plane_scaler_check,
> + uint32_t pixel_format)
> {
> struct intel_crtc_scaler_state *scal
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines
== Series Details == Series: series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39981/ State : success == Summary == Series 39981v1 series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines https://patchwork.freedesktop.org/api/1.0/series/39981/revisions/1/mbox/ Possible new issues: Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-skl-6770hq) fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:438s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:444s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:532s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:294s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:512s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:515s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:511s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s2total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:577s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:519s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:583s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:418s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:315s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:532s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:401s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:481s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:426s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:463s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:514s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:651s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:439s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:528s fi-skl-6700hqtotal:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:547s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:507s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:493s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:424s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:583s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:402s Blacklisted hosts: fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:520s 86e964296fe8bc85fdb624fa75b4cd83fcfb58cd drm-tip: 2018y-03m-14d-17h-40m-20s UTC integration manifest 92fe8ca9be16 drm/i915: move gen8 irq shifts to intel_lrc.c 6d190a4d604c drm/i915: use engine->irq_keep_mask when resetting irqs e0198a0269a6 drm/i915: add a selftest for the mmio_bases table 4d139fa5e73a drm/i915: store all mmio bases in intel_engines == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8349/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams
GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams to be generated correctly, and it also corrects some errors in the diagram description. v2: - Fixed errors in diagram description Signed-off-by: Jackie Li Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_guc.c | 52 -- drivers/gpu/drm/i915/intel_wopcm.c | 44 +--- 2 files changed, 50 insertions(+), 46 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 3eb516e..6a4f36e 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -495,35 +495,37 @@ int intel_guc_resume(struct intel_guc *guc) /** * DOC: GuC Address Space * - * The layout of GuC address space is shown as below: + * The layout of GuC address space is shown below: * - *+==> ++ <== GUC_GGTT_TOP - *^|| - *||| - *||DRAM| - *|| Memory | - *||| - * GuC || - * Address +> ++ <== WOPCM Top - * Space ^ | HW contexts RSVD | - *| | |WOPCM | - *| | +==> ++ <== GuC WOPCM Top - *|GuC^|| - *|GGTT ||| - *|Pin GuC |GuC | - *|Bias WOPCM | WOPCM| - *| |Size || - *| | ||| - *v v v|| - *+=+=+==> ++ <== GuC WOPCM Base - * | Non-GuC WOPCM| - * | (HuC/Reserved) | - * ++ <== WOPCM Base + * :: + * + * +==> ++ <== GUC_GGTT_TOP + * ^|| + * ||| + * ||DRAM| + * || Memory | + * ||| + *GuC || + * Address +> ++ <== WOPCM Top + * Space ^ | HW contexts RSVD | + * | | |WOPCM | + * | | +==> ++ <== GuC WOPCM Top + * |GuC^|| + * |GGTT ||| + * |Pin GuC |GuC | + * |Bias WOPCM | WOPCM| + * | |Size || + * | | ||| + * v v v|| + * +=+=+==> ++ <== GuC WOPCM Base + * | Non-GuC WOPCM| + * | (HuC/Reserved) | + * ++ <== WOPCM Base * * The lower part [0, GuC ggtt_pin_bias) is mapped to WOPCM which consists of * GuC WOPCM and WOPCM reserved for other usage (e.g.RC6 context). The value of - * the GuC ggtt_pin_bias is determined by the actually GuC WOPCM size which is - * set in GUC_WOPCM_SIZE register. + * the GuC ggtt_pin_bias is determined by the GuC WOPCM size which is set in + * GUC_WOPCM_SIZE register. */ /** diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c index 4117886..74bf76f 100644 --- a/drivers/gpu/drm/i915/intel_wopcm.c +++ b/drivers/gpu/drm/i915/intel_wopcm.c @@ -11,28 +11,30 @@ * DOC: WOPCM Layout * * The layout of the WOPCM will be fixed after writing to GuC WOPCM size and - * offset registers whose are calculated are determined by size of HuC/GuC - * firmware size and set of hw requirements/restrictions as shown below: + * offset registers whose values are calculated and determined by HuC/GuC + * firmware size and set of hardware requirements/restrictions as shown below: * - * +=> ++ <== WOPCM Top - * ^ | HW contexts RSVD | - * | +===> ++ <== GuC WOPCM Top - * | ^ || - * | | || - * | | || - * |GuC|| - * | WOPCM || - * |Size ++ - * WOPCM | |GuC FW RSVD | - * | | ++ - * | | | GuC Stack RSVD | - * | | +--- + - * | v | GuC WOPCM RSVD | - * | +===> ++ <
[Intel-gfx] [PATCH] drm/i915/guc: Unify naming of private GuC action functions
We should avoid using guc_log prefix for functions that don't
operate on GuC log, but rather request action from the GuC.
Better to use guc_action prefix.
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_guc_log.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index b9c7bd7..457168a 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -39,7 +39,7 @@
* registers value.
*/
-static int guc_log_flush_complete(struct intel_guc *guc)
+static int guc_action_flush_log_complete(struct intel_guc *guc)
{
u32 action[] = {
INTEL_GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE
@@ -48,7 +48,7 @@ static int guc_log_flush_complete(struct intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
-static int guc_log_flush(struct intel_guc *guc)
+static int guc_action_flush_log(struct intel_guc *guc)
{
u32 action[] = {
INTEL_GUC_ACTION_FORCE_LOG_BUFFER_FLUSH,
@@ -58,7 +58,8 @@ static int guc_log_flush(struct intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
-static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity)
+static int guc_action_enable_log(struct intel_guc *guc, bool enable,
+u32 verbosity)
{
union guc_log_control control_val = {
{
@@ -525,7 +526,7 @@ static void guc_log_capture_logs(struct intel_guc *guc)
* time, so get/put should be really quick.
*/
intel_runtime_pm_get(dev_priv);
- guc_log_flush_complete(guc);
+ guc_action_flush_log_complete(guc);
intel_runtime_pm_put(dev_priv);
}
@@ -541,7 +542,7 @@ static void guc_flush_logs(struct intel_guc *guc)
/* Ask GuC to update the log buffer state */
intel_runtime_pm_get(dev_priv);
- guc_log_flush(guc);
+ guc_action_flush_log(guc);
intel_runtime_pm_put(dev_priv);
/* GuC would have updated log buffer by now, so capture it */
@@ -639,10 +640,11 @@ int intel_guc_log_control_set(struct intel_guc *guc, u64
val)
}
intel_runtime_pm_get(dev_priv);
- ret = guc_log_control(guc, enabled, LOG_LEVEL_TO_VERBOSITY(val));
+ ret = guc_action_enable_log(guc, enabled, LOG_LEVEL_TO_VERBOSITY(val));
intel_runtime_pm_put(dev_priv);
if (ret) {
- DRM_DEBUG_DRIVER("guc_log_control action failed %d\n", ret);
+ DRM_DEBUG_DRIVER("GuC action to %s log failed (%d)\n",
+enabled ? "enable" : "disable", ret);
goto out_unlock;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams
== Series Details == Series: drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams URL : https://patchwork.freedesktop.org/series/39979/ State : success == Summary == Series 39979v1 drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams https://patchwork.freedesktop.org/api/1.0/series/39979/revisions/1/mbox/ Possible new issues: Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-skl-6770hq) Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> FAIL (fi-cnl-y3) fdo#104951 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:428s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:439s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:536s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:512s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:514s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:501s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:408s fi-cfl-s2total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:583s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-y3total:285 pass:258 dwarn:0 dfail:0 fail:1 skip:26 time:574s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:424s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:311s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:534s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:421s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:476s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:428s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:514s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:658s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:525s fi-skl-6700hqtotal:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:539s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:507s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:495s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:435s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:592s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:400s Blacklisted hosts: fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:517s 86e964296fe8bc85fdb624fa75b4cd83fcfb58cd drm-tip: 2018y-03m-14d-17h-40m-20s UTC integration manifest c729cf26691d drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8348/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Update syntax of GuC log functions
On Wed, Mar 14, 2018 at 06:53:23PM +0100, Michal Wajdeczko wrote: > On Wed, 14 Mar 2018 18:20:18 +0100, Michal Wajdeczko > wrote: > > > On Wed, 14 Mar 2018 17:56:01 +0100, Michał Winiarski > > wrote: > > > > > On Wed, Mar 14, 2018 at 02:45:39PM +, Michal Wajdeczko wrote: > > > > We moved GuC log related data and code to separate files and > > > > definition but we didn't change functions syntax to follow > > > > object-verb pattern. Let's fix that before we continue with > > > > next round of code refactoring. > > > > > > > > v2: rebased > > > > > > > > Signed-off-by: Michal Wajdeczko > > > > Cc: Michal Winiarski > > > > Cc: Chris Wilson > > > > Reviewed-by: Michał Winiarski > > > > > > One more comment, since I just noticed this while rebasing my guc > > > patches on > > > this rename. > > > > > > What about guc actions? > > > We now have guc_log_flush_complete, guc_log_flush and > > > guc_log_control that are > > > using intel_guc rather than intel_guc_log. > > > Which is reasonable - because those don't touch guc->log, but it's also > > > inconsistent (I'm also adding guc_log_flush_irq_enable). > > > > > > If you want to follow object-verb pattern, you should either rename > > > or pass > > > intel_guc_log and do the log_to_guc dance there. > > > > I was planning to rename them in next patch as follows: > > > > guc_log_flush_complete -> guc_send_flush_log_complete > > guc_log_flush -> guc_send_flush_log > > guc_log_control-> guc_send_control_log > > or (to match naming used in intel_guc_ct.c) > > guc_log_flush_complete -> guc_action_flush_log_complete > guc_log_flush -> guc_action_flush_log > guc_log_control-> guc_action_control_log > > or maybe other ideas ? I don't mind having it in a follow-up patch. I'd pick guc_action_*, but both schemes sound good so it's up to you. -Michał ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/4] drm/i915: use engine->irq_keep_mask when resetting irqs
the "reset" value and the "keep" value are the same.
While at it, add a TODO for gen11 interrupt reset
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3a69b367e565..5e8f6896d059 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1666,6 +1666,10 @@ static void reset_irq(struct intel_engine_cs *engine)
struct drm_i915_private *dev_priv = engine->i915;
int i;
+ /* TODO: correctly reset irqs for gen11 */
+ if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
+ return;
+
GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
/*
@@ -1677,11 +1681,11 @@ static void reset_irq(struct intel_engine_cs *engine)
*/
for (i = 0; i < 2; i++) {
I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
- GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
+ engine->irq_keep_mask);
POSTING_READ(GEN8_GT_IIR(gtiir[engine->id]));
}
GEM_BUG_ON(I915_READ(GEN8_GT_IIR(gtiir[engine->id])) &
- (GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift));
+ engine->irq_keep_mask);
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
}
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/4] drm/i915: store all mmio bases in intel_engines
The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're running
on in a consistent way.
v2: document that the list goes in reverse order, update starting gen
for render (Chris)
v3: starting gen for render back to 1 to make our life easier with
selftests (Chris)
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Chris Wilson #v2
---
drivers/gpu/drm/i915/intel_engine_cs.c | 78 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 -
2 files changed, 50 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index f22c5f72df8d..068d94e71cd5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,17 @@ static const struct engine_class_info
intel_engine_classes[] = {
},
};
+#define MAX_MMIO_BASES 3
struct engine_info {
unsigned int hw_id;
unsigned int uabi_id;
u8 class;
u8 instance;
- u32 mmio_base;
+ /* mmio bases table *must* be sorted in reverse gen order */
+ struct engine_mmio_base {
+ u32 gen : 8;
+ u32 base : 24;
+ } mmio_bases[MAX_MMIO_BASES];
unsigned irq_shift;
};
@@ -96,7 +101,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_RENDER,
.class = RENDER_CLASS,
.instance = 0,
- .mmio_base = RENDER_RING_BASE,
+ .mmio_bases = {
+ { .gen = 1, .base = RENDER_RING_BASE }
+ },
.irq_shift = GEN8_RCS_IRQ_SHIFT,
},
[BCS] = {
@@ -104,7 +111,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BLT,
.class = COPY_ENGINE_CLASS,
.instance = 0,
- .mmio_base = BLT_RING_BASE,
+ .mmio_bases = {
+ { .gen = 6, .base = BLT_RING_BASE }
+ },
.irq_shift = GEN8_BCS_IRQ_SHIFT,
},
[VCS] = {
@@ -112,7 +121,11 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 0,
- .mmio_base = GEN6_BSD_RING_BASE,
+ .mmio_bases = {
+ { .gen = 11, .base = GEN11_BSD_RING_BASE },
+ { .gen = 6, .base = GEN6_BSD_RING_BASE },
+ { .gen = 4, .base = BSD_RING_BASE }
+ },
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
},
[VCS2] = {
@@ -120,7 +133,10 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 1,
- .mmio_base = GEN8_BSD2_RING_BASE,
+ .mmio_bases = {
+ { .gen = 11, .base = GEN11_BSD2_RING_BASE },
+ { .gen = 8, .base = GEN8_BSD2_RING_BASE }
+ },
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
},
[VCS3] = {
@@ -128,7 +144,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 2,
- .mmio_base = GEN11_BSD3_RING_BASE,
+ .mmio_bases = {
+ { .gen = 11, .base = GEN11_BSD3_RING_BASE }
+ },
.irq_shift = 0, /* not used */
},
[VCS4] = {
@@ -136,7 +154,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 3,
- .mmio_base = GEN11_BSD4_RING_BASE,
+ .mmio_bases = {
+ { .gen = 11, .base = GEN11_BSD4_RING_BASE }
+ },
.irq_shift = 0, /* not used */
},
[VECS] = {
@@ -144,7 +164,10 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLASS,
.instance = 0,
- .mmio_base = VEBOX_RING_BASE,
+ .mmio_bases = {
+ { .gen = 11, .base = GEN11_VEBOX_RING_BASE },
+ { .gen = 7, .base = VEBOX_RING_BASE }
+ },
.irq_shift = GEN8_VECS_IRQ_SHIFT,
},
[VECS2] = {
@@ -152,7 +175,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_
[Intel-gfx] [PATCH v4 2/4] drm/i915: add a selftest for the mmio_bases table
Check that the entries are in reverse gen order and that all entries
with gen > 0 have an mmio base set.
v2: loop forward, simplify logic, use i915_subtests (Chris)
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_engine_cs.c | 16 +++---
.../gpu/drm/i915/selftests/i915_mock_selftests.h | 1 +
drivers/gpu/drm/i915/selftests/intel_engine_cs.c | 58 ++
3 files changed, 69 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/intel_engine_cs.c
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 068d94e71cd5..c0fb01c68ef8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -263,16 +263,21 @@ static u32 __engine_mmio_base(struct drm_i915_private
*i915,
return bases[i].base;
}
+static void __sprint_engine_name(char *name, const struct engine_info *info)
+{
+ WARN_ON(snprintf(name, INTEL_ENGINE_CS_MAX_NAME, "%s%u",
+ intel_engine_classes[info->class].name, info->instance) >=
+ INTEL_ENGINE_CS_MAX_NAME);
+}
+
static int
intel_engine_setup(struct drm_i915_private *dev_priv,
enum intel_engine_id id)
{
const struct engine_info *info = &intel_engines[id];
- const struct engine_class_info *class_info;
struct intel_engine_cs *engine;
GEM_BUG_ON(info->class >= ARRAY_SIZE(intel_engine_classes));
- class_info = &intel_engine_classes[info->class];
BUILD_BUG_ON(MAX_ENGINE_CLASS >= BIT(GEN11_ENGINE_CLASS_WIDTH));
BUILD_BUG_ON(MAX_ENGINE_INSTANCE >= BIT(GEN11_ENGINE_INSTANCE_WIDTH));
@@ -293,9 +298,7 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->id = id;
engine->i915 = dev_priv;
- WARN_ON(snprintf(engine->name, sizeof(engine->name), "%s%u",
-class_info->name, info->instance) >=
- sizeof(engine->name));
+ __sprint_engine_name(engine->name, info);
engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = __engine_mmio_base(dev_priv, info->mmio_bases);
engine->irq_shift = info->irq_shift;
@@ -303,7 +306,7 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->instance = info->instance;
engine->uabi_id = info->uabi_id;
- engine->uabi_class = class_info->uabi_class;
+ engine->uabi_class = intel_engine_classes[info->class].uabi_class;
engine->context_size = __intel_engine_context_size(dev_priv,
engine->class);
@@ -2140,4 +2143,5 @@ void intel_disable_engine_stats(struct intel_engine_cs
*engine)
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_engine.c"
+#include "selftests/intel_engine_cs.c"
#endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
index 9a48aa441743..d16d74178e9d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h
@@ -14,6 +14,7 @@ selftest(fence, i915_sw_fence_mock_selftests)
selftest(scatterlist, scatterlist_mock_selftests)
selftest(syncmap, i915_syncmap_mock_selftests)
selftest(uncore, intel_uncore_mock_selftests)
+selftest(engine, intel_engine_cs_mock_selftests)
selftest(breadcrumbs, intel_breadcrumbs_mock_selftests)
selftest(timelines, i915_gem_timeline_mock_selftests)
selftest(requests, i915_request_mock_selftests)
diff --git a/drivers/gpu/drm/i915/selftests/intel_engine_cs.c
b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c
new file mode 100644
index ..cfaa6b296835
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/intel_engine_cs.c
@@ -0,0 +1,58 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include "../i915_selftest.h"
+
+static int intel_mmio_bases_check(void *arg)
+{
+ int i, j;
+
+ for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
+ const struct engine_info *info = &intel_engines[i];
+ char name[INTEL_ENGINE_CS_MAX_NAME];
+ u8 prev = U8_MAX;
+
+ __sprint_engine_name(name, info);
+
+ for (j = 0; j < MAX_MMIO_BASES; j++) {
+ u8 gen = info->mmio_bases[j].gen;
+ u32 base = info->mmio_bases[j].base;
+
+ if (gen >= prev) {
+ pr_err("%s: %s: mmio base for gen %x "
+ "is before the one for gen %x\n",
+ __func__, name, prev, gen);
+ return -EINVAL;
+ }
+
+ if (gen == 0)
+ break;
+
+ if (!base) {
+ pr_err("%s
[Intel-gfx] [PATCH v4 4/4] drm/i915: move gen8 irq shifts to intel_lrc.c
The only usage outside the intel_lrc.c file is in the ringbuffer
init, but the irq mask calculated there is then overwritten for
all engines that have a non-zero shift, so we can drop it.
This change is not aimed at code saving but at removing from
intel_engines information that does not apply to all gens that have
the engine. When checking without the temporary WARN_ON, code size
is basically unchanged.
v2: make the irq_shifts array static const
v3: rebase, move irq_shifts array to logical_ring_default_irqs
v4: move array inside the if and use u8 for it (Chris)
Suggested-by: Michel Thierry
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 10 --
drivers/gpu/drm/i915/intel_lrc.c| 15 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
4 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index c0fb01c68ef8..58d3e45c4e19 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -92,7 +92,6 @@ struct engine_info {
u32 gen : 8;
u32 base : 24;
} mmio_bases[MAX_MMIO_BASES];
- unsigned irq_shift;
};
static const struct engine_info intel_engines[] = {
@@ -104,7 +103,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 1, .base = RENDER_RING_BASE }
},
- .irq_shift = GEN8_RCS_IRQ_SHIFT,
},
[BCS] = {
.hw_id = BCS_HW,
@@ -114,7 +112,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 6, .base = BLT_RING_BASE }
},
- .irq_shift = GEN8_BCS_IRQ_SHIFT,
},
[VCS] = {
.hw_id = VCS_HW,
@@ -126,7 +123,6 @@ static const struct engine_info intel_engines[] = {
{ .gen = 6, .base = GEN6_BSD_RING_BASE },
{ .gen = 4, .base = BSD_RING_BASE }
},
- .irq_shift = GEN8_VCS1_IRQ_SHIFT,
},
[VCS2] = {
.hw_id = VCS2_HW,
@@ -137,7 +133,6 @@ static const struct engine_info intel_engines[] = {
{ .gen = 11, .base = GEN11_BSD2_RING_BASE },
{ .gen = 8, .base = GEN8_BSD2_RING_BASE }
},
- .irq_shift = GEN8_VCS2_IRQ_SHIFT,
},
[VCS3] = {
.hw_id = VCS3_HW,
@@ -147,7 +142,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 11, .base = GEN11_BSD3_RING_BASE }
},
- .irq_shift = 0, /* not used */
},
[VCS4] = {
.hw_id = VCS4_HW,
@@ -157,7 +151,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 11, .base = GEN11_BSD4_RING_BASE }
},
- .irq_shift = 0, /* not used */
},
[VECS] = {
.hw_id = VECS_HW,
@@ -168,7 +161,6 @@ static const struct engine_info intel_engines[] = {
{ .gen = 11, .base = GEN11_VEBOX_RING_BASE },
{ .gen = 7, .base = VEBOX_RING_BASE }
},
- .irq_shift = GEN8_VECS_IRQ_SHIFT,
},
[VECS2] = {
.hw_id = VECS2_HW,
@@ -178,7 +170,6 @@ static const struct engine_info intel_engines[] = {
.mmio_bases = {
{ .gen = 11, .base = GEN11_VEBOX2_RING_BASE }
},
- .irq_shift = 0, /* not used */
},
};
@@ -301,7 +292,6 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
__sprint_engine_name(engine->name, info);
engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = __engine_mmio_base(dev_priv, info->mmio_bases);
- engine->irq_shift = info->irq_shift;
engine->class = info->class;
engine->instance = info->instance;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5e8f6896d059..0ef91f22420e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2118,7 +2118,20 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
static inline void
logical_ring_default_irqs(struct intel_engine_cs *engine)
{
- unsigned shift = engine->irq_shift;
+ unsigned shift = 0;
+
+ if (INTEL_GEN(engine->i915) < 11) {
+ const u8 irq_shifts[] = {
+ [RCS] = GEN8_RCS_IRQ_SHIFT,
+ [BCS] = GEN8_BCS_IRQ_SHIFT,
+ [VCS] = GEN8_VCS1_IRQ_SHIFT,
+ [VCS2] = GEN8_VCS2_IRQ_SHIFT,
+
Re: [Intel-gfx] [PATCH] drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.
On Wed, 2018-03-14 at 15:35 +0200, Ville Syrjälä wrote:
> On Tue, Mar 13, 2018 at 10:48:25PM -0700, Dhinakaran Pandiyan wrote:
> > If bios sets up an MST output and hardware state readout code sees this is
> > an SST configuration, when disabling the encoder we end up calling
> > ->post_disable_dp() hook instead of the MST version. Consequently, we write
> > to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
> > enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
> > the MST hub. This results in continuous link training failures which keep
> > the system busy delaying boot. We could identify bios MST boot discrepancy
> > and handle it accordingly but a simple way to solve this is to write to the
> > DP_SET_POWER dpcd for MST too.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
Reported-by: Laura Abbott
Cc: sta...@vger.kernel.org
Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message
transactions for dpms control")
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index dbcf1a0586f9..8c2d778560f0 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2205,8 +2205,7 @@ static void intel_ddi_pre_enable_dp(struct
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder, crtc_state);
> >
> > intel_ddi_init_dp_buf_reg(encoder);
> > - if (!is_mst)
> > - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>
> The spec is perhaps a bit unclear on this.
>
> "If the message is sent as a path request, all DP nodes from the source
> immediate downstream device and the targeted DP node will be placed in
> the D0 power state."
>
> Doesn't quite tell me whether the immediate downstream device is
> included in that list of nodes.
>
> However the spec goes on to say
> "Each nodes immediate upstream device will use Native AUX writes to the
> SET_POWER & SET_DP_PWR_VOLTAGE register (DPCD Address 00600h) to set
> the power state of the downstream node."
>
> and since we are the immediate upstream for that device I guess it makes
> sense that we should still do the DP_SET_POWER manually.
>
> But I have to wonder what the original issue was before we started to use
> POWER_UP/DOWN_PHY. I suppose somehow some further downstream device
> wasn't in D0 when we needed it.
Correct, sinks farther downstream weren't lighting up.
> But that is a bit weird as I believe all
> devices should really start up in D0.
>
> Anyways based on my reading of the spec I can justify this so
> Reviewed-by: Ville Syrjälä
>
Thanks for the review.
> I presume we want cc:stable + fixes: on this?
Yeah, I suppose we should wait for the reporter to confirm that this
indeed fixes the bug. It does fix the problem on the Thinkpad laptop +
dock I tested it on.
>
> > intel_dp_start_link_train(intel_dp);
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > @@ -2304,14 +2303,12 @@ static void intel_ddi_post_disable_dp(struct
> > intel_encoder *encoder,
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
> > struct intel_dp *intel_dp = &dig_port->dp;
> > - bool is_mst = intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST);
> >
> > /*
> > * Power down sink before disabling the port, otherwise we end
> > * up getting interrupts from the sink on detecting link loss.
> > */
> > - if (!is_mst)
> > - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >
> > intel_disable_ddi_buf(encoder);
> >
> > --
> > 2.14.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Engine discovery query
> -Original Message- > From: Tvrtko Ursulin [mailto:tursu...@ursulin.net] > Sent: Wednesday, March 14, 2018 7:06 AM > To: Intel-gfx@lists.freedesktop.org > Cc: tursu...@ursulin.net; Ursulin, Tvrtko ; Chris > Wilson ; Bloomfield, Jon > ; Rogozhkin, Dmitry V > ; Landwerlin, Lionel G > ; Joonas Lahtinen > > Subject: [RFC] drm/i915: Engine discovery query > > From: Tvrtko Ursulin > > Engine discovery query allows userspace to enumerate engines, probe their > configuration features, all without needing to maintain the internal PCI > ID based database. > > A new query for the generic i915 query ioctl is added named > DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure > drm_i915_query_engine_info. The address of latter should be passed to the > kernel in the query.data_ptr field, and should be large enough for the > kernel to fill out all known engines as struct drm_i915_engine_info > elements trailing the query. > > As with other queries, setting the item query length to zero allows > userspace to query minimum required buffer size. > > Enumerated engines have common type mask which can be used to query all > hardware engines, versus engines userspace can submit to using the execbuf > uAPI. > > Engines also have capabilities which are per engine class namespace of > bits describing features not present on all engine instances. > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson > Cc: Jon Bloomfield > Cc: Dmitry Rogozhkin > Cc: Lionel Landwerlin > Cc: Joonas Lahtinen > --- > This is RFC for now since it is not very usable before the new execbuf API > or virtual engine queue submission gets closer. > > In this version I have added capability of distinguishing between hardware > engines and ABI engines. This is to account for probable future use cases > like virtualization, where guest might only see one engine instance, but > will want to know overall hardware capabilities in order to tune its > behaviour. The patch looks good, but... I can't see any use for exposing the unreachable engines. Can you elaborate on why a umd running in a VM would need to know about the engines assigned to other VM's ? Is it even desirable to leak the physical capabilities to VM's ? In general a VM would have a very limited view of the underlying hardware. It's unlikely to even be capable of discovering true h/w engine counts. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Engine discovery query
On 14/03/18 17:53, Tvrtko Ursulin wrote: Maybe I reorder it like: u32 flags; u16 class; u16 instance; u32/u64 capabilities; u32 rdsvd[some]; Looks good :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Work around compiler warnings on some kernel configs
On 14/03/2018 08:31, Patchwork wrote: == Series Details == Series: drm/i915/pmu: Work around compiler warnings on some kernel configs URL : https://patchwork.freedesktop.org/series/39939/ State : success == Summary == Series 39939v1 drm/i915/pmu: Work around compiler warnings on some kernel configs https://patchwork.freedesktop.org/api/1.0/series/39939/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:439s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:534s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:301s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:504s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:513s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:507s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:498s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:587s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:585s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:420s fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:316s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:530s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:401s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:418s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:477s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:430s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:474s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:470s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:513s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:441s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:529s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:539s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:512s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:498s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:428s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:437s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:398s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:28 time:517s 613eb885b69e808a46f11125870e47b67a326d76 drm-tip: 2018y-03m-14d-05h-56m-23s UTC integration manifest 34462fc0bee3 drm/i915/pmu: Work around compiler warnings on some kernel configs Pushed it, thanks for the review! (And I forgot to copy Arnd on the patch..) So Arnd, sorry, I forgot Reported-by does not add Cc from git send-email. https://patchwork.freedesktop.org/series/39939/ is my version of the fix for this. (Now merged.) Hopefully it works for your randconfigs as well and thanks for sending a patch in the first place! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams
GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams to be generated correctly. Signed-off-by: Jackie Li Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_guc.c | 46 -- drivers/gpu/drm/i915/intel_wopcm.c | 40 + 2 files changed, 45 insertions(+), 41 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 3eb516e..61d00f8 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -497,28 +497,30 @@ int intel_guc_resume(struct intel_guc *guc) * * The layout of GuC address space is shown as below: * - *+==> ++ <== GUC_GGTT_TOP - *^|| - *||| - *||DRAM| - *|| Memory | - *||| - * GuC || - * Address +> ++ <== WOPCM Top - * Space ^ | HW contexts RSVD | - *| | |WOPCM | - *| | +==> ++ <== GuC WOPCM Top - *|GuC^|| - *|GGTT ||| - *|Pin GuC |GuC | - *|Bias WOPCM | WOPCM| - *| |Size || - *| | ||| - *v v v|| - *+=+=+==> ++ <== GuC WOPCM Base - * | Non-GuC WOPCM| - * | (HuC/Reserved) | - * ++ <== WOPCM Base + * :: + * + * +==> ++ <== GUC_GGTT_TOP + * ^|| + * ||| + * ||DRAM| + * || Memory | + * ||| + *GuC || + * Address +> ++ <== WOPCM Top + * Space ^ | HW contexts RSVD | + * | | |WOPCM | + * | | +==> ++ <== GuC WOPCM Top + * |GuC^|| + * |GGTT ||| + * |Pin GuC |GuC | + * |Bias WOPCM | WOPCM| + * | |Size || + * | | ||| + * v v v|| + * +=+=+==> ++ <== GuC WOPCM Base + * | Non-GuC WOPCM| + * | (HuC/Reserved) | + * ++ <== WOPCM Base * * The lower part [0, GuC ggtt_pin_bias) is mapped to WOPCM which consists of * GuC WOPCM and WOPCM reserved for other usage (e.g.RC6 context). The value of diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c index 4117886..030debd 100644 --- a/drivers/gpu/drm/i915/intel_wopcm.c +++ b/drivers/gpu/drm/i915/intel_wopcm.c @@ -14,25 +14,27 @@ * offset registers whose are calculated are determined by size of HuC/GuC * firmware size and set of hw requirements/restrictions as shown below: * - * +=> ++ <== WOPCM Top - * ^ | HW contexts RSVD | - * | +===> ++ <== GuC WOPCM Top - * | ^ || - * | | || - * | | || - * |GuC|| - * | WOPCM || - * |Size ++ - * WOPCM | |GuC FW RSVD | - * | | ++ - * | | | GuC Stack RSVD | - * | | +--- + - * | v | GuC WOPCM RSVD | - * | +===> ++ <== GuC WOPCM base - * | | WOPCM RSVD | - * | +--- + <== HuC Firmware Top - * v | HuC FW| - * +=> ++ <== WOPCM Base + * :: + * + *+=> ++ <== WOPCM Top + *^ | HW contexts RSVD | + *| +===> ++ <== GuC WOPCM Top + *| ^ || + *| | || + *| | || + *|GuC|| + *| WOPCM || + *|Size ++ + * WOPCM | |GuC FW RSVD | +
Re: [Intel-gfx] [RFC] drm/i915: Engine discovery query
On 14/03/2018 16:40, Lionel Landwerlin wrote:
Looks mostly good to me. I have a few comments below.
On 14/03/18 14:05, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Engine discovery query allows userspace to enumerate engines, probe their
configuration features, all without needing to maintain the internal PCI
ID based database.
A new query for the generic i915 query ioctl is added named
DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure
drm_i915_query_engine_info. The address of latter should be passed to the
kernel in the query.data_ptr field, and should be large enough for the
kernel to fill out all known engines as struct drm_i915_engine_info
elements trailing the query.
As with other queries, setting the item query length to zero allows
userspace to query minimum required buffer size.
Enumerated engines have common type mask which can be used to query all
hardware engines, versus engines userspace can submit to using the
execbuf
uAPI.
Engines also have capabilities which are per engine class namespace of
bits describing features not present on all engine instances.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jon Bloomfield
Cc: Dmitry Rogozhkin
Cc: Lionel Landwerlin
Cc: Joonas Lahtinen
---
This is RFC for now since it is not very usable before the new execbuf
API
or virtual engine queue submission gets closer.
In this version I have added capability of distinguishing between
hardware
engines and ABI engines. This is to account for probable future use cases
like virtualization, where guest might only see one engine instance, but
will want to know overall hardware capabilities in order to tune its
behaviour.
In general I think we will have to wait a bit before defining the final
look of the uAPI, but in the meantime I thought it useful to share as
RFC.
---
drivers/gpu/drm/i915/i915_query.c | 61
+
drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
include/uapi/drm/i915_drm.h | 44
4 files changed, 111 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 3ace929dd90f..e00d02796d42 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -82,9 +82,70 @@ static int query_topology_info(struct
drm_i915_private *dev_priv,
return total_length;
}
+static int
+query_engine_info(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct drm_i915_query_engine_info query, *q;
+ struct drm_i915_engine_info *info;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int len;
+
+ if (query_item->flags)
+ return -EINVAL;
+
+ len = sizeof(struct drm_i915_query_engine_info) +
+ I915_NUM_ENGINES * sizeof(struct drm_i915_engine_info);
+
+ if (!query_item->length)
+ return len;
+ else if (query_item->length < len)
+ return -EINVAL;
+
+ if (copy_from_user(&query, u64_to_user_ptr(query_item->data_ptr),
+ sizeof(query)))
+ return -EFAULT;
+
+ if (query.num_engines ||
+ query.rsvd[0] || query.rsvd[1] || query.rsvd[2])
+ return -EINVAL;
+
+ if (!access_ok(VERIFY_WRITE, u64_to_user_ptr(query_item->data_ptr),
+ len))
+ return -EFAULT;
+
+ q = kzalloc(len, GFP_KERNEL);
+ if (!q)
+ return -ENOMEM;
Do you actually need to kalloc?
Why not a drm_i915_engine_info on the stack that you copy to the right
user pointer directly?
Yep, that will make it simpler.
+
+ info = &q->engines[0];
+
+ for_each_engine(engine, i915, id) {
+ info->class = engine->uabi_class;
+ info->instance = engine->instance;
+ info->type = I915_ENGINE_TYPE_PHYSICAL |
+ I915_ENGINE_TYPE_UAPI;
+ info->capabilities = engine->capabilities;
+ info++;
+ q->num_engines++;
+ }
+
+ if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr), q, len)) {
+ len = -EFAULT;
+ goto out;
+ }
+
+out:
+ kfree(q);
+
+ return len;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private
*dev_priv,
struct drm_i915_query_item *query_item) = {
query_topology_info,
+ query_engine_info,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct
drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a2b1e9e2c008..81be4acd8358 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -86,6 +86,7 @@ struct engine_info {
unsigned int uabi_id;
u8 class;
u8 instance;
+ u32 capabilities;
u32 mmio_base;
unsigned irq_shift;
};
@@ -114,6 +115,7 @@ static const struct engine_info intel_engines[] = {
.instance = 0,
.mmio_base = GEN6_BSD_RING_BASE,
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Update syntax of GuC log functions
On Wed, 14 Mar 2018 18:20:18 +0100, Michal Wajdeczko wrote: On Wed, 14 Mar 2018 17:56:01 +0100, Michał Winiarski wrote: On Wed, Mar 14, 2018 at 02:45:39PM +, Michal Wajdeczko wrote: We moved GuC log related data and code to separate files and definition but we didn't change functions syntax to follow object-verb pattern. Let's fix that before we continue with next round of code refactoring. v2: rebased Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski Cc: Chris Wilson Reviewed-by: Michał Winiarski One more comment, since I just noticed this while rebasing my guc patches on this rename. What about guc actions? We now have guc_log_flush_complete, guc_log_flush and guc_log_control that are using intel_guc rather than intel_guc_log. Which is reasonable - because those don't touch guc->log, but it's also inconsistent (I'm also adding guc_log_flush_irq_enable). If you want to follow object-verb pattern, you should either rename or pass intel_guc_log and do the log_to_guc dance there. I was planning to rename them in next patch as follows: guc_log_flush_complete -> guc_send_flush_log_complete guc_log_flush -> guc_send_flush_log guc_log_control-> guc_send_control_log or (to match naming used in intel_guc_ct.c) guc_log_flush_complete -> guc_action_flush_log_complete guc_log_flush -> guc_action_flush_log guc_log_control-> guc_action_control_log or maybe other ideas ? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/drm_dp_helper.c | 18 ++
include/drm/drm_dp_helper.h | 6 ++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..392e92e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
rd_interval);
+
+ if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
udelay(100);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
rd_interval);
+
+ if (rd_interval == 0)
udelay(400);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..9afea9f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
/* AUX CH addresses */
/* DPCD */
#define DP_DPCD_REV 0x000
+# define DPCD_REV_100x10
+# define DPCD_REV_110x11
+# define DPCD_REV_120x12
+# define DPCD_REV_130x13
+# define DPCD_REV_140x14
#define DP_MAX_LINK_RATE0x001
@@ -118,6 +123,7 @@
# define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2 */
#define DP_ADAPTER_CAP 0x00f /* 1.2 */
# define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp
On Tue, Mar 13, 2018 at 07:24:20PM -0400, Lyude Paul wrote:
> On Mon, 2018-03-12 at 23:01 +0200, Ville Syrjälä wrote:
> > On Fri, Mar 09, 2018 at 04:32:27PM -0500, Lyude Paul wrote:
> > > While having the modeset_retry_work in intel_connector makes sense with
> > > SST, this paradigm doesn't make a whole ton of sense when it comes to
> > > MST since we have to deal with multiple connectors. In most cases, it's
> > > more useful to just use the intel_dp struct since it indicates whether
> > > or not we're dealing with an MST device, along with being able to easily
> > > trace the intel_dp struct back to it's respective connector (if there is
> > > any). So, move the modeset_retry_work function out of the
> > > intel_connector struct and into intel_dp.
> > >
> > > Signed-off-by: Lyude Paul
> > > Reviewed-by: Manasi Navare
> > > Cc: Manasi Navare
> > > Cc: Ville Syrjälä
> > >
> > > V2:
> > > - Remove accidental duplicate modeset_retry_work in intel_connector
> > > V3:
> > > - Also check against eDP in intel_hpd_poll_fini() - mdnavare
> > > Signed-off-by: Lyude Paul
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 25
> > > +++-
> > > -
> > > drivers/gpu/drm/i915/intel_dp.c | 10 --
> > > drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
> > > drivers/gpu/drm/i915/intel_drv.h | 6 +++---
> > > 4 files changed, 31 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index f424fff477f6..3b7fa430a84a 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -15394,16 +15394,37 @@ static void intel_hpd_poll_fini(struct
> > > drm_device
> > > *dev)
> > > {
> > > struct intel_connector *connector;
> > > struct drm_connector_list_iter conn_iter;
> > > + struct work_struct *work;
> > > + int conn_type;
> > >
> > > /* Kill all the work that may have been queued by hpd. */
> > > drm_connector_list_iter_begin(dev, &conn_iter);
> > > for_each_intel_connector_iter(connector, &conn_iter) {
> > > - if (connector->modeset_retry_work.func)
> > > - cancel_work_sync(&connector->modeset_retry_work);
> > > if (connector->hdcp_shim) {
> > > cancel_delayed_work_sync(&connector-
> > > >hdcp_check_work);
> > > cancel_work_sync(&connector->hdcp_prop_work);
> > > }
> > > +
> > > + conn_type = connector->base.connector_type;
> > > + if (conn_type != DRM_MODE_CONNECTOR_eDP &&
> > > + conn_type != DRM_MODE_CONNECTOR_DisplayPort)
> > > + continue;
> > > +
> > > + if (connector->mst_port) {
> > > + work = &connector->mst_port->modeset_retry_work;
> > > + } else {
> > > + struct intel_encoder *intel_encoder =
> > > + connector->encoder;
> > > + struct intel_dp *intel_dp;
> > > +
> > > + if (!intel_encoder)
> > > + continue;
> > > +
> > > + intel_dp = enc_to_intel_dp(&intel_encoder->base);
> > > + work = &intel_dp->modeset_retry_work;
> > > + }
> > > +
> > > + cancel_work_sync(work);
> >
> > Why are we even walking the connectors for this? Can't we just
> > walk the encoders instead?
> We could walk the encoders for this, but seeing as we're already walking the
> connectors for the HDCP prop doesn't it make more sense to just stick our code
> there? or is there a simpler solution for this I'm missing
I think walking the encoders when you want encoders is a lot cleaner.
Keeps the snr much higher.
> >
> > > }
> > > drm_connector_list_iter_end(&conn_iter);
> > > }
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 4dd1b2287dd6..5abf0c95725a 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct
> > > intel_dp
> > > *intel_dp,
> > >
> > > static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> > > {
> > > - struct intel_connector *intel_connector;
> > > - struct drm_connector *connector;
> > > + struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
> > > + modeset_retry_work);
> > > + struct drm_connector *connector = &intel_dp->attached_connector-
> > > >base;
> > >
> > > - intel_connector = container_of(work, typeof(*intel_connector),
> > > -modeset_retry_work);
> > > - connector = &intel_connector->base;
> > > DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> > > connector->name);
> > >
> > > @@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port
> > > *intel_dig_port,
> > > int typ
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Update syntax of GuC log functions
On Wed, 14 Mar 2018 17:56:01 +0100, Michał Winiarski wrote: On Wed, Mar 14, 2018 at 02:45:39PM +, Michal Wajdeczko wrote: We moved GuC log related data and code to separate files and definition but we didn't change functions syntax to follow object-verb pattern. Let's fix that before we continue with next round of code refactoring. v2: rebased Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski Cc: Chris Wilson Reviewed-by: Michał Winiarski One more comment, since I just noticed this while rebasing my guc patches on this rename. What about guc actions? We now have guc_log_flush_complete, guc_log_flush and guc_log_control that are using intel_guc rather than intel_guc_log. Which is reasonable - because those don't touch guc->log, but it's also inconsistent (I'm also adding guc_log_flush_irq_enable). If you want to follow object-verb pattern, you should either rename or pass intel_guc_log and do the log_to_guc dance there. I was planning to rename them in next patch as follows: guc_log_flush_complete -> guc_send_flush_log_complete guc_log_flush -> guc_send_flush_log guc_log_control-> guc_send_control_log /Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove hole and padding from intel_shared_dpll
On Wed, Mar 14, 2018 at 09:31:32AM -0700, Lucas De Marchi wrote:
> Reorder fields so we save 8 bytes per instance: this removes a 4-bytes
> hole after enum intel_dpll_id and a 4-bytes padding.
>
> Signed-off-by: Lucas De Marchi
> ---
>
> Is this something desirable? I happened to be looking at
> intel_shared_dpll and noticed the hole. I haven't checked any other struct
> yet, but there are probably more and more important ones. This one saves
> only 8 * I915_NUM_PLLS.
>
> drivers/gpu/drm/i915/intel_dpll_mgr.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> index f24ccf443d25..9635522dcb32 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> @@ -238,11 +238,6 @@ struct intel_shared_dpll {
>*/
> enum intel_dpll_id id;
>
> - /**
> - * @funcs: platform specific hooks
> - */
> - struct intel_shared_dpll_funcs funcs;
> -
> #define INTEL_DPLL_ALWAYS_ON (1 << 0)
> /**
>* @flags:
> @@ -252,6 +247,11 @@ struct intel_shared_dpll {
>* not in use by any CRTC.
>*/
> uint32_t flags;
> +
> + /**
> + * @funcs: platform specific hooks
> + */
> + struct intel_shared_dpll_funcs funcs;
Why do we need to copy the entire thing here anyway? Can't we just
make this a pointer?
> };
>
> #define SKL_DPLL0 0
> --
> 2.14.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12
On Wed, Mar 14, 2018 at 04:55:08PM +0100, Maarten Lankhorst wrote:
> Op 14-03-18 om 16:35 schreef Ville Syrjälä:
> > On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote:
> >>
> >>> -Original Message-
> >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Wednesday, March 14, 2018 4:03 PM
> >>> To: Srinivas, Vidya ; intel-
> >>> g...@lists.freedesktop.org
> >>> Cc: Syrjala, Ville ; Lankhorst, Maarten
> >>>
> >>> Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max
> >>> scale
> >>> for NV12
> >>>
> >>> Op 14-03-18 om 11:31 schreef Srinivas, Vidya:
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Wednesday, March 14, 2018 3:55 PM
> > To: Srinivas, Vidya ; intel-
> > g...@lists.freedesktop.org
> > Cc: Syrjala, Ville ; Lankhorst, Maarten
> >
> > Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler
> > max scale for NV12
> >
> > Op 14-03-18 om 10:52 schreef Maarten Lankhorst:
> >> Op 09-03-18 om 09:48 schreef Vidya Srinivas:
> >>> From: Chandra Konduru
> >>>
> >>> This patch updates scaler max limit support for NV12
> >>>
> >>> v2: Rebased (me)
> >>>
> >>> v3: Rebased (me)
> >>>
> >>> v4: Missed the Tested-by/Reviewed-by in the previous series Adding
> >>> the same to commit message in this version.
> >>>
> >>> v5: Addressed review comments from Ville and rebased
> >>> - calculation of max_scale to be made less convoluted by splitting
> >>> it up a bit
> >>> - Indentation errors to be fixed in the series
> >>>
> >>> v6: Rebased (me)
> >>> Fixed review comments from Paauwe, Bob J Previous version, where a
> >>> split of calculation was done, was wrong. Fixed that issue here.
> >>>
> >>> v7: Rebased (me)
> >>>
> >>> v8: Rebased (me)
> >>>
> >>> v9: Rebased (me)
> >>>
> >>> v10: Rebased (me)
> >>>
> >>> v11: Addressed review comments from Shashank Sharma Alignment
> > issues
> >>> fixed.
> >>> When call to skl_update_scaler is made, 0 was being sent instead of
> >>> pixel_format.
> >>> When crtc update scaler is called, we dont have the fb to derive
> >>> the pixel format. Added the function parameter bool
> >>> plane_scaler_check to account for this.
> >>>
> >>> v12: Fixed failure in IGT debugfs_test.
> >>> fb is NULL in skl_update_scaler_plane Due to this, accessing
> >>> fb->format caused failure.
> >>> Patch checks fb before using.
> >>>
> >>> v13: In the previous version there was a flaw.
> >>> In skl_update_scaler during plane_scaler_check if the format was
> >>> non-NV12, it would set need_scaling to false. This could reset the
> >>> previously set need_scaling from a previous condition check. Patch
> >>> fixes this.
> >>> Patch also adds minimum src height for YUV 420 formats to 16 (as
> >>> defined in BSpec) and adds for checking this range.
> >>>
> >>> Tested-by: Clinton Taylor
> >>> Reviewed-by: Clinton Taylor
> >>> Signed-off-by: Chandra Konduru
> >>> Signed-off-by: Nabendu Maiti
> >>> Signed-off-by: Uma Shankar
> >>> Signed-off-by: Vidya Srinivas
> >>> ---
> >>> drivers/gpu/drm/i915/intel_display.c | 78
> > ++--
> >>> drivers/gpu/drm/i915/intel_drv.h | 4 +-
> >>> drivers/gpu/drm/i915/intel_sprite.c | 3 +-
> >>> 3 files changed, 61 insertions(+), 24 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>> b/drivers/gpu/drm/i915/intel_display.c
> >>> index 34f7225..7fd8354 100644
> >>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> @@ -3466,6 +3466,8 @@ static u32 skl_plane_ctl_format(uint32_t
> > pixel_format)
> >>> return PLANE_CTL_FORMAT_YUV422 |
> > PLANE_CTL_YUV422_UYVY;
> >>> case DRM_FORMAT_VYUY:
> >>> return PLANE_CTL_FORMAT_YUV422 |
> > PLANE_CTL_YUV422_VYUY;
> >>> + case DRM_FORMAT_NV12:
> >>> + return PLANE_CTL_FORMAT_NV12;
> >>> default:
> >>> MISSING_CASE(pixel_format);
> >>> }
> >>> @@ -4705,7 +4707,9 @@ static void cpt_verify_modeset(struct
> >>> drm_device *dev, int pipe) static int skl_update_scaler(struct
> >>> intel_crtc_state *crtc_state, bool force_detach,
> >>> unsigned int scaler_user, int *scaler_id,
> >>> - int src_w, int src_h, int dst_w, int dst_h)
> >>> + int src_w, int src_h, int dst_w, int dst_h,
> >>> + bool plane_scaler_check,
> >>> + uint32_t pixel_format)
> >>> {
> >>> struct intel_crtc_scaler_state *scaler_state =
> >>> &crtc_s
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove hole and padding from intel_shared_dpll
== Series Details == Series: drm/i915: Remove hole and padding from intel_shared_dpll URL : https://patchwork.freedesktop.org/series/39972/ State : success == Summary == Series 39972v1 drm/i915: Remove hole and padding from intel_shared_dpll https://patchwork.freedesktop.org/api/1.0/series/39972/revisions/1/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:433s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:440s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:541s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:302s fi-bxt-dsi total:246 pass:219 dwarn:0 dfail:0 fail:0 skip:26 fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:523s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:510s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:415s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:583s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:430s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:323s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:474s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:428s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:473s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:474s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:517s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:656s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:438s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:526s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:541s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:507s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:504s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:427s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:449s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:567s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:404s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:28 time:533s f25b08dcf09c72da5a530dca49a4b93bd6d75395 drm-tip: 2018y-03m-14d-14h-33m-13s UTC integration manifest e5d2a4edc559 drm/i915: Remove hole and padding from intel_shared_dpll == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8347/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Update syntax of GuC log functions
On Wed, Mar 14, 2018 at 02:45:39PM +, Michal Wajdeczko wrote: > We moved GuC log related data and code to separate files and > definition but we didn't change functions syntax to follow > object-verb pattern. Let's fix that before we continue with > next round of code refactoring. > > v2: rebased > > Signed-off-by: Michal Wajdeczko > Cc: Michal Winiarski > Cc: Chris Wilson > Reviewed-by: Michał Winiarski One more comment, since I just noticed this while rebasing my guc patches on this rename. What about guc actions? We now have guc_log_flush_complete, guc_log_flush and guc_log_control that are using intel_guc rather than intel_guc_log. Which is reasonable - because those don't touch guc->log, but it's also inconsistent (I'm also adding guc_log_flush_irq_enable). If you want to follow object-verb pattern, you should either rename or pass intel_guc_log and do the log_to_guc dance there. -Michał > --- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/intel_guc.c | 8 +- > drivers/gpu/drm/i915/intel_guc_log.c | 203 > +++ > drivers/gpu/drm/i915/intel_guc_log.h | 18 ++-- > drivers/gpu/drm/i915/intel_uc.c | 4 +- > 5 files changed, 126 insertions(+), 111 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/36] drm/i915: Remove obsolete min/max freq setters from debugfs
On 3/14/2018 3:07 PM, Chris Wilson wrote:
A more complete, and more importantly stable, interface for controlling
the RPS frequency range is available in sysfs, obsoleting the unstable
debugfs.
Signed-off-by: Chris Wilson
Reviewed-by: Sagar Arun Kamble
(I'm assuming we don't want to mention "getters" in subject as it is
trivial and obvious :) )
---
drivers/gpu/drm/i915/i915_debugfs.c | 115
1 file changed, 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5965df3e6215..034fb7cfc80e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4136,119 +4136,6 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_drop_caches_fops,
i915_drop_caches_get, i915_drop_caches_set,
"0x%08llx\n");
-static int
-i915_max_freq_get(void *data, u64 *val)
-{
- struct drm_i915_private *dev_priv = data;
-
- if (INTEL_GEN(dev_priv) < 6)
- return -ENODEV;
-
- *val = intel_gpu_freq(dev_priv, dev_priv->gt_pm.rps.max_freq_softlimit);
- return 0;
-}
-
-static int
-i915_max_freq_set(void *data, u64 val)
-{
- struct drm_i915_private *dev_priv = data;
- struct intel_rps *rps = &dev_priv->gt_pm.rps;
- u32 hw_max, hw_min;
- int ret;
-
- if (INTEL_GEN(dev_priv) < 6)
- return -ENODEV;
-
- DRM_DEBUG_DRIVER("Manually setting max freq to %llu\n", val);
-
- ret = mutex_lock_interruptible(&rps->lock);
- if (ret)
- return ret;
-
- /*
-* Turbo will still be enabled, but won't go above the set value.
-*/
- val = intel_freq_opcode(dev_priv, val);
-
- hw_max = rps->max_freq;
- hw_min = rps->min_freq;
-
- if (val < hw_min || val > hw_max || val < rps->min_freq_softlimit) {
- ret = -EINVAL;
- goto unlock;
- }
-
- rps->max_freq_softlimit = val;
-
- if (intel_set_rps(dev_priv, val))
- DRM_DEBUG_DRIVER("failed to update RPS to new softlimit\n");
-
-unlock:
- mutex_unlock(&rps->lock);
- return ret;
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(i915_max_freq_fops,
- i915_max_freq_get, i915_max_freq_set,
- "%llu\n");
-
-static int
-i915_min_freq_get(void *data, u64 *val)
-{
- struct drm_i915_private *dev_priv = data;
-
- if (INTEL_GEN(dev_priv) < 6)
- return -ENODEV;
-
- *val = intel_gpu_freq(dev_priv, dev_priv->gt_pm.rps.min_freq_softlimit);
- return 0;
-}
-
-static int
-i915_min_freq_set(void *data, u64 val)
-{
- struct drm_i915_private *dev_priv = data;
- struct intel_rps *rps = &dev_priv->gt_pm.rps;
- u32 hw_max, hw_min;
- int ret;
-
- if (INTEL_GEN(dev_priv) < 6)
- return -ENODEV;
-
- DRM_DEBUG_DRIVER("Manually setting min freq to %llu\n", val);
-
- ret = mutex_lock_interruptible(&rps->lock);
- if (ret)
- return ret;
-
- /*
-* Turbo will still be enabled, but won't go below the set value.
-*/
- val = intel_freq_opcode(dev_priv, val);
-
- hw_max = rps->max_freq;
- hw_min = rps->min_freq;
-
- if (val < hw_min ||
- val > hw_max || val > rps->max_freq_softlimit) {
- ret = -EINVAL;
- goto unlock;
- }
-
- rps->min_freq_softlimit = val;
-
- if (intel_set_rps(dev_priv, val))
- DRM_DEBUG_DRIVER("failed to update RPS to new softlimit\n");
-
-unlock:
- mutex_unlock(&rps->lock);
- return ret;
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(i915_min_freq_fops,
- i915_min_freq_get, i915_min_freq_set,
- "%llu\n");
-
static int
i915_cache_sharing_get(void *data, u64 *val)
{
@@ -4749,8 +4636,6 @@ static const struct i915_debugfs_files {
const struct file_operations *fops;
} i915_debugfs_files[] = {
{"i915_wedged", &i915_wedged_fops},
- {"i915_max_freq", &i915_max_freq_fops},
- {"i915_min_freq", &i915_min_freq_fops},
{"i915_cache_sharing", &i915_cache_sharing_fops},
{"i915_ring_missed_irq", &i915_ring_missed_irq_fops},
{"i915_ring_test_irq", &i915_ring_test_irq_fops},
--
Thanks,
Sagar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Engine discovery query
Looks mostly good to me. I have a few comments below.
On 14/03/18 14:05, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Engine discovery query allows userspace to enumerate engines, probe their
configuration features, all without needing to maintain the internal PCI
ID based database.
A new query for the generic i915 query ioctl is added named
DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure
drm_i915_query_engine_info. The address of latter should be passed to the
kernel in the query.data_ptr field, and should be large enough for the
kernel to fill out all known engines as struct drm_i915_engine_info
elements trailing the query.
As with other queries, setting the item query length to zero allows
userspace to query minimum required buffer size.
Enumerated engines have common type mask which can be used to query all
hardware engines, versus engines userspace can submit to using the execbuf
uAPI.
Engines also have capabilities which are per engine class namespace of
bits describing features not present on all engine instances.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jon Bloomfield
Cc: Dmitry Rogozhkin
Cc: Lionel Landwerlin
Cc: Joonas Lahtinen
---
This is RFC for now since it is not very usable before the new execbuf API
or virtual engine queue submission gets closer.
In this version I have added capability of distinguishing between hardware
engines and ABI engines. This is to account for probable future use cases
like virtualization, where guest might only see one engine instance, but
will want to know overall hardware capabilities in order to tune its
behaviour.
In general I think we will have to wait a bit before defining the final
look of the uAPI, but in the meantime I thought it useful to share as RFC.
---
drivers/gpu/drm/i915/i915_query.c | 61 +
drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
include/uapi/drm/i915_drm.h | 44
4 files changed, 111 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 3ace929dd90f..e00d02796d42 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -82,9 +82,70 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
return total_length;
}
+static int
+query_engine_info(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct drm_i915_query_engine_info query, *q;
+ struct drm_i915_engine_info *info;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int len;
+
+ if (query_item->flags)
+ return -EINVAL;
+
+ len = sizeof(struct drm_i915_query_engine_info) +
+ I915_NUM_ENGINES * sizeof(struct drm_i915_engine_info);
+
+ if (!query_item->length)
+ return len;
+ else if (query_item->length < len)
+ return -EINVAL;
+
+ if (copy_from_user(&query, u64_to_user_ptr(query_item->data_ptr),
+ sizeof(query)))
+ return -EFAULT;
+
+ if (query.num_engines ||
+ query.rsvd[0] || query.rsvd[1] || query.rsvd[2])
+ return -EINVAL;
+
+ if (!access_ok(VERIFY_WRITE, u64_to_user_ptr(query_item->data_ptr),
+ len))
+ return -EFAULT;
+
+ q = kzalloc(len, GFP_KERNEL);
+ if (!q)
+ return -ENOMEM;
Do you actually need to kalloc?
Why not a drm_i915_engine_info on the stack that you copy to the right
user pointer directly?
+
+ info = &q->engines[0];
+
+ for_each_engine(engine, i915, id) {
+ info->class = engine->uabi_class;
+ info->instance = engine->instance;
+ info->type = I915_ENGINE_TYPE_PHYSICAL |
+I915_ENGINE_TYPE_UAPI;
+ info->capabilities = engine->capabilities;
+ info++;
+ q->num_engines++;
+ }
+
+ if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr), q, len)) {
+ len = -EFAULT;
+ goto out;
+ }
+
+out:
+ kfree(q);
+
+ return len;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
+ query_engine_info,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a2b1e9e2c008..81be4acd8358 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -86,6 +86,7 @@ struct engine_info {
unsigned int uabi_id;
u8 class;
u8 instance;
+ u32 capabilities;
u32 mmio_base;
unsigned
[Intel-gfx] [PATCH] drm/i915: Remove hole and padding from intel_shared_dpll
Reorder fields so we save 8 bytes per instance: this removes a 4-bytes
hole after enum intel_dpll_id and a 4-bytes padding.
Signed-off-by: Lucas De Marchi
---
Is this something desirable? I happened to be looking at
intel_shared_dpll and noticed the hole. I haven't checked any other struct
yet, but there are probably more and more important ones. This one saves
only 8 * I915_NUM_PLLS.
drivers/gpu/drm/i915/intel_dpll_mgr.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/intel_dpll_mgr.h
index f24ccf443d25..9635522dcb32 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
@@ -238,11 +238,6 @@ struct intel_shared_dpll {
*/
enum intel_dpll_id id;
- /**
-* @funcs: platform specific hooks
-*/
- struct intel_shared_dpll_funcs funcs;
-
#define INTEL_DPLL_ALWAYS_ON (1 << 0)
/**
* @flags:
@@ -252,6 +247,11 @@ struct intel_shared_dpll {
* not in use by any CRTC.
*/
uint32_t flags;
+
+ /**
+* @funcs: platform specific hooks
+*/
+ struct intel_shared_dpll_funcs funcs;
};
#define SKL_DPLL0 0
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Control PSR at runtime through debugfs only (rev2)
== Series Details == Series: drm/i915: Control PSR at runtime through debugfs only (rev2) URL : https://patchwork.freedesktop.org/series/39955/ State : success == Summary == Series 39955v2 drm/i915: Control PSR at runtime through debugfs only https://patchwork.freedesktop.org/api/1.0/series/39955/revisions/2/mbox/ fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:436s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:448s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:543s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:508s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:525s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:506s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:509s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:586s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:427s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:319s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:476s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:430s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:470s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:515s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:657s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:438s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:527s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:539s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:509s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:596s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:399s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:28 time:516s f25b08dcf09c72da5a530dca49a4b93bd6d75395 drm-tip: 2018y-03m-14d-14h-33m-13s UTC integration manifest 0325fffb04c8 drm/i915: Allow control of PSR at runtime through debugfs. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8346/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/icl: Enable 2nd DBuf slice only when needed
ICL has two slices of DBuf, each slice of size 1024 blocks.
We should not always enable slice-2. It should be enabled only if
display total required BW is > 12GBps OR more than 1 pipes are enabled.
Changes since V1:
- typecast total_data_rate to u64 before multiplication to solve any
possible overflow (Rodrigo)
- fix where skl_wm_get_hw_state was memsetting ddb, resulting
enabled_slices to become zero
- Fix the logic of calculating ddb_size
Changes since V2:
- If no-crtc is part of commit required_slices will have value "0",
don't try to disable DBuf slice.
Changes since V3:
- Create a generic helper to enable/disable slice
- don't return early if total_data_rate is 0, it may be cursor only
commit, or atomic modeset without any plane.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c| 10 +
drivers/gpu/drm/i915/intel_drv.h| 6 +++
drivers/gpu/drm/i915/intel_pm.c | 58 +++--
drivers/gpu/drm/i915/intel_runtime_pm.c | 65 ++---
4 files changed, 113 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e1771cac75d3..f7e606db239d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12198,6 +12198,8 @@ static void skl_update_crtcs(struct drm_atomic_state
*state)
bool progress;
enum pipe pipe;
int i;
+ uint8_t hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
+ uint8_t required_slices = intel_state->wm_results.ddb.enabled_slices;
const struct skl_ddb_entry *entries[I915_MAX_PIPES] = {};
@@ -12206,6 +12208,10 @@ static void skl_update_crtcs(struct drm_atomic_state
*state)
if (new_crtc_state->active)
entries[i] =
&to_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
+ /* If 2nd DBuf slice required, enable it here */
+ if (INTEL_GEN(dev_priv) >= 11 && required_slices > hw_enabled_slices)
+ icl_dbuf_slices_update(dev_priv, required_slices);
+
/*
* Whenever the number of active pipes changes, we need to make sure we
* update the pipes in the right order so that their ddb allocations
@@ -12256,6 +12262,10 @@ static void skl_update_crtcs(struct drm_atomic_state
*state)
progress = true;
}
} while (progress);
+
+ /* If 2nd DBuf slice is no more required disable it */
+ if (INTEL_GEN(dev_priv) >= 11 && required_slices < hw_enabled_slices)
+ icl_dbuf_slices_update(dev_priv, required_slices);
}
static void intel_atomic_helper_free_state(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a215aa78b0be..dfb6b5665031 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -140,6 +140,10 @@
#define KHz(x) (1000 * (x))
#define MHz(x) KHz(1000 * (x))
+#define KBps(x) (1000 * (x))
+#define MBps(x) KBps(1000 * (x))
+#define GBps(x) ((uint64_t) 1000 * MBps((x)))
+
/*
* Display related stuff
*/
@@ -1910,6 +1914,8 @@ bool intel_display_power_get_if_enabled(struct
drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
+void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
+ uint8_t req_slices);
static inline void
assert_rpm_device_not_suspended(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 1d331f505f44..bb304c019163 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3771,9 +3771,42 @@ bool intel_can_enable_sagv(struct drm_atomic_state
*state)
return true;
}
+static unsigned int intel_get_ddb_size(struct drm_i915_private *dev_priv,
+ const struct intel_crtc_state *cstate,
+ const unsigned int total_data_rate,
+ const int num_active,
+ struct skl_ddb_allocation *ddb)
+{
+ const struct drm_display_mode *adjusted_mode;
+ u64 total_data_bw;
+ u16 ddb_size = INTEL_INFO(dev_priv)->ddb_size;
+
+ WARN_ON(ddb_size == 0);
+
+ if (INTEL_GEN(dev_priv) < 11)
+ return ddb_size - 4; /* 4 blocks for bypass path allocation */
+
+ adjusted_mode = &cstate->base.adjusted_mode;
+ total_data_bw = (u64)total_data_rate * drm_mode_vrefresh(adjusted_mode);
+
+ /*
+* 12GB/s is maximum BW supported by single DBuf slice.
+*/
+ if (total_data_bw >= GBps(12) || num_active > 1)
+ ddb->enabled_slices = 2;
+ else
Re: [Intel-gfx] [PATCH] drm/i915: Allow control of PSR at runtime through debugfs.
Op 14-03-18 om 17:07 schreef Chris Wilson: > Quoting Maarten Lankhorst (2018-03-14 15:58:32) >> Currently tests modify i915.enable_psr and then do a modeset cycle >> to change PSR. We can write a value to i915_edp_psr_status to force >> a certain value without a modeset. >> >> To retain compatibility with older userspace, we also still allow >> the override through the module parameter, and add some tracking >> to check whether a debugfs mode is specified. > Is it possible for you to mandate that the process holds the file open > for as long as it wants its value to hold. Then we can automatically > clean up if the process dies; without requiring userspace to dig itself > out of a hole. > -Chris For testing PSR someone might directly echo values to the debugfs file, so I didn't want to keep the fd handle as reference count.. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Update syntax of GuC log functions (rev2)
== Series Details == Series: drm/i915/guc: Update syntax of GuC log functions (rev2) URL : https://patchwork.freedesktop.org/series/39859/ State : success == Summary == Series 39859v2 drm/i915/guc: Update syntax of GuC log functions https://patchwork.freedesktop.org/api/1.0/series/39859/revisions/2/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:433s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:442s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:542s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:300s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:511s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:518s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:506s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:414s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:514s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:601s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:321s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:474s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:434s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:477s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:472s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:515s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:656s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:530s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:542s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:514s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:492s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:586s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:403s Blacklisted hosts: fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0 skip:28 time:523s f25b08dcf09c72da5a530dca49a4b93bd6d75395 drm-tip: 2018y-03m-14d-14h-33m-13s UTC integration manifest 5f735ea22b06 drm/i915/guc: Update syntax of GuC log functions == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8345/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow control of PSR at runtime through debugfs.
Quoting Maarten Lankhorst (2018-03-14 15:58:32) > Currently tests modify i915.enable_psr and then do a modeset cycle > to change PSR. We can write a value to i915_edp_psr_status to force > a certain value without a modeset. > > To retain compatibility with older userspace, we also still allow > the override through the module parameter, and add some tracking > to check whether a debugfs mode is specified. Is it possible for you to mandate that the process holds the file open for as long as it wants its value to hold. Then we can automatically clean up if the process dies; without requiring userspace to dig itself out of a hole. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Allow control of PSR at runtime through debugfs.
Currently tests modify i915.enable_psr and then do a modeset cycle
to change PSR. We can write a value to i915_edp_psr_status to force
a certain value without a modeset.
To retain compatibility with older userspace, we also still allow
the override through the module parameter, and add some tracking
to check whether a debugfs mode is specified.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_debugfs.c | 193 +++-
drivers/gpu/drm/i915/i915_drv.h | 7 ++
drivers/gpu/drm/i915/intel_drv.h| 7 ++
drivers/gpu/drm/i915/intel_psr.c| 155 ++---
4 files changed, 301 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 574fcf234007..4abf8034d5c7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2546,16 +2546,13 @@ static const char *psr2_live_status(u32 val)
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
- struct drm_i915_private *dev_priv = node_to_i915(m->private);
+ struct drm_i915_private *dev_priv = m->private;
u32 psrperf = 0;
u32 stat[3];
enum pipe pipe;
bool enabled = false;
bool sink_support;
- if (!HAS_PSR(dev_priv))
- return -ENODEV;
-
sink_support = dev_priv->psr.sink_support;
seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
if (!sink_support)
@@ -2631,6 +2628,192 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
return 0;
}
+static bool psr_global_enabled(enum i915_psr_debugfs_mode mode)
+{
+ switch (mode) {
+ case PSR_DEBUGFS_MODE_DEFAULT: return i915_modparams.enable_psr;
+ case PSR_DEBUGFS_MODE_DISABLED: return false;
+ case PSR_DEBUGFS_MODE_ENABLED: return true;
+ }
+
+ /* GCC is stupid. */
+ return false;
+}
+
+static bool psr_needs_disable(struct drm_i915_private *dev_priv,
+ bool enable, bool link_standby)
+{
+ if (!dev_priv->psr.hw_configured)
+ return false;
+
+ if (!enable)
+ return true;
+
+ if (dev_priv->psr.link_standby != link_standby)
+ return true;
+
+ return false;
+}
+
+static bool psr_needs_enable(struct drm_i915_private *dev_priv,
+bool enable)
+{
+ return enable && !dev_priv->psr.hw_configured;
+}
+
+static int __i915_edp_psr_write(struct drm_i915_private *dev_priv,
+ struct drm_modeset_acquire_ctx *ctx,
+ enum i915_psr_debugfs_mode mode,
+ bool link_standby)
+{
+ struct drm_device *dev = &dev_priv->drm;
+ struct drm_connector_list_iter conn_iter;
+ struct drm_connector *connector;
+ struct drm_encoder *encoder;
+ struct drm_crtc *crtc;
+ int ret;
+ bool needs_enable, found, enable;
+
+ ret = drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
+ if (ret)
+ return ret;
+
+ mutex_lock(&dev_priv->psr.lock);
+retry:
+ if (!dev_priv->psr.enabled) {
+ dev_priv->psr.debugfs_mode = mode;
+ dev_priv->psr.link_standby = link_standby;
+ goto end;
+ }
+ encoder = &dp_to_dig_port(dev_priv->psr.enabled)->base.base;
+ mutex_unlock(&dev_priv->psr.lock);
+
+ found = false;
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter)
+ if (connector->state->best_encoder == encoder) {
+ found = true;
+ break;
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
+ if (WARN_ON(!found))
+ return -EINVAL;
+
+ crtc = connector->state->crtc;
+ ret = drm_modeset_lock(&crtc->mutex, ctx);
+ if (ret)
+ return ret;
+
+ mutex_lock(&dev_priv->psr.lock);
+ enable = psr_global_enabled(mode);
+
+ if (dev_priv->psr.enabled != enc_to_intel_dp(encoder))
+ goto retry;
+
+ if ((connector->state->commit &&
!try_wait_for_completion(&connector->state->commit->hw_done)) ||
+ (crtc->state->commit &&
!try_wait_for_completion(&crtc->state->commit->hw_done))) {
+ ret = -EBUSY;
+ goto end;
+ }
+
+ if (psr_needs_disable(dev_priv, enable, link_standby))
+ __intel_psr_disable(dev_priv, dev_priv->psr.enabled,
to_intel_crtc_state(crtc->state));
+
+ needs_enable = psr_needs_enable(dev_priv, enable);
+ dev_priv->psr.debugfs_mode = mode;
+ dev_priv->psr.link_standby = link_standby;
+
+ if (needs_enable)
+ __intel_psr_enable(dev_priv, dev_priv->psr.enabled,
to_intel_crtc_state(crtc->state));
+
+end:
+ mutex_unlock(&dev_priv->psr.lock);
+ return re
Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12
Op 14-03-18 om 16:35 schreef Ville Syrjälä:
> On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote:
>>
>>> -Original Message-
>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>>> Sent: Wednesday, March 14, 2018 4:03 PM
>>> To: Srinivas, Vidya ; intel-
>>> g...@lists.freedesktop.org
>>> Cc: Syrjala, Ville ; Lankhorst, Maarten
>>>
>>> Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max
>>> scale
>>> for NV12
>>>
>>> Op 14-03-18 om 11:31 schreef Srinivas, Vidya:
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, March 14, 2018 3:55 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: Syrjala, Ville ; Lankhorst, Maarten
>
> Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler
> max scale for NV12
>
> Op 14-03-18 om 10:52 schreef Maarten Lankhorst:
>> Op 09-03-18 om 09:48 schreef Vidya Srinivas:
>>> From: Chandra Konduru
>>>
>>> This patch updates scaler max limit support for NV12
>>>
>>> v2: Rebased (me)
>>>
>>> v3: Rebased (me)
>>>
>>> v4: Missed the Tested-by/Reviewed-by in the previous series Adding
>>> the same to commit message in this version.
>>>
>>> v5: Addressed review comments from Ville and rebased
>>> - calculation of max_scale to be made less convoluted by splitting
>>> it up a bit
>>> - Indentation errors to be fixed in the series
>>>
>>> v6: Rebased (me)
>>> Fixed review comments from Paauwe, Bob J Previous version, where a
>>> split of calculation was done, was wrong. Fixed that issue here.
>>>
>>> v7: Rebased (me)
>>>
>>> v8: Rebased (me)
>>>
>>> v9: Rebased (me)
>>>
>>> v10: Rebased (me)
>>>
>>> v11: Addressed review comments from Shashank Sharma Alignment
> issues
>>> fixed.
>>> When call to skl_update_scaler is made, 0 was being sent instead of
>>> pixel_format.
>>> When crtc update scaler is called, we dont have the fb to derive
>>> the pixel format. Added the function parameter bool
>>> plane_scaler_check to account for this.
>>>
>>> v12: Fixed failure in IGT debugfs_test.
>>> fb is NULL in skl_update_scaler_plane Due to this, accessing
>>> fb->format caused failure.
>>> Patch checks fb before using.
>>>
>>> v13: In the previous version there was a flaw.
>>> In skl_update_scaler during plane_scaler_check if the format was
>>> non-NV12, it would set need_scaling to false. This could reset the
>>> previously set need_scaling from a previous condition check. Patch
>>> fixes this.
>>> Patch also adds minimum src height for YUV 420 formats to 16 (as
>>> defined in BSpec) and adds for checking this range.
>>>
>>> Tested-by: Clinton Taylor
>>> Reviewed-by: Clinton Taylor
>>> Signed-off-by: Chandra Konduru
>>> Signed-off-by: Nabendu Maiti
>>> Signed-off-by: Uma Shankar
>>> Signed-off-by: Vidya Srinivas
>>> ---
>>> drivers/gpu/drm/i915/intel_display.c | 78
> ++--
>>> drivers/gpu/drm/i915/intel_drv.h | 4 +-
>>> drivers/gpu/drm/i915/intel_sprite.c | 3 +-
>>> 3 files changed, 61 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index 34f7225..7fd8354 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -3466,6 +3466,8 @@ static u32 skl_plane_ctl_format(uint32_t
> pixel_format)
>>> return PLANE_CTL_FORMAT_YUV422 |
> PLANE_CTL_YUV422_UYVY;
>>> case DRM_FORMAT_VYUY:
>>> return PLANE_CTL_FORMAT_YUV422 |
> PLANE_CTL_YUV422_VYUY;
>>> + case DRM_FORMAT_NV12:
>>> + return PLANE_CTL_FORMAT_NV12;
>>> default:
>>> MISSING_CASE(pixel_format);
>>> }
>>> @@ -4705,7 +4707,9 @@ static void cpt_verify_modeset(struct
>>> drm_device *dev, int pipe) static int skl_update_scaler(struct
>>> intel_crtc_state *crtc_state, bool force_detach,
>>> unsigned int scaler_user, int *scaler_id,
>>> - int src_w, int src_h, int dst_w, int dst_h)
>>> + int src_w, int src_h, int dst_w, int dst_h,
>>> + bool plane_scaler_check,
>>> + uint32_t pixel_format)
>>> {
>>> struct intel_crtc_scaler_state *scaler_state =
>>> &crtc_state->scaler_state;
>>> @@ -4723,6 +4727,10 @@ skl_update_scaler(struct intel_crtc_state
> *crtc_state, bool force_detach,
>>> */
>>> need_scaling = src_w != dst_w || src_h != dst_h;
>>>
>>> + if (plane_scaler_check)
>>> +
Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12
On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote:
>
>
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Wednesday, March 14, 2018 4:03 PM
> > To: Srinivas, Vidya ; intel-
> > g...@lists.freedesktop.org
> > Cc: Syrjala, Ville ; Lankhorst, Maarten
> >
> > Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max
> > scale
> > for NV12
> >
> > Op 14-03-18 om 11:31 schreef Srinivas, Vidya:
> > >
> > >> -Original Message-
> > >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > >> Sent: Wednesday, March 14, 2018 3:55 PM
> > >> To: Srinivas, Vidya ; intel-
> > >> g...@lists.freedesktop.org
> > >> Cc: Syrjala, Ville ; Lankhorst, Maarten
> > >>
> > >> Subject: Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler
> > >> max scale for NV12
> > >>
> > >> Op 14-03-18 om 10:52 schreef Maarten Lankhorst:
> > >>> Op 09-03-18 om 09:48 schreef Vidya Srinivas:
> > From: Chandra Konduru
> >
> > This patch updates scaler max limit support for NV12
> >
> > v2: Rebased (me)
> >
> > v3: Rebased (me)
> >
> > v4: Missed the Tested-by/Reviewed-by in the previous series Adding
> > the same to commit message in this version.
> >
> > v5: Addressed review comments from Ville and rebased
> > - calculation of max_scale to be made less convoluted by splitting
> > it up a bit
> > - Indentation errors to be fixed in the series
> >
> > v6: Rebased (me)
> > Fixed review comments from Paauwe, Bob J Previous version, where a
> > split of calculation was done, was wrong. Fixed that issue here.
> >
> > v7: Rebased (me)
> >
> > v8: Rebased (me)
> >
> > v9: Rebased (me)
> >
> > v10: Rebased (me)
> >
> > v11: Addressed review comments from Shashank Sharma Alignment
> > >> issues
> > fixed.
> > When call to skl_update_scaler is made, 0 was being sent instead of
> > pixel_format.
> > When crtc update scaler is called, we dont have the fb to derive
> > the pixel format. Added the function parameter bool
> > plane_scaler_check to account for this.
> >
> > v12: Fixed failure in IGT debugfs_test.
> > fb is NULL in skl_update_scaler_plane Due to this, accessing
> > fb->format caused failure.
> > Patch checks fb before using.
> >
> > v13: In the previous version there was a flaw.
> > In skl_update_scaler during plane_scaler_check if the format was
> > non-NV12, it would set need_scaling to false. This could reset the
> > previously set need_scaling from a previous condition check. Patch
> > fixes this.
> > Patch also adds minimum src height for YUV 420 formats to 16 (as
> > defined in BSpec) and adds for checking this range.
> >
> > Tested-by: Clinton Taylor
> > Reviewed-by: Clinton Taylor
> > Signed-off-by: Chandra Konduru
> > Signed-off-by: Nabendu Maiti
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Vidya Srinivas
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 78
> > >> ++--
> > drivers/gpu/drm/i915/intel_drv.h | 4 +-
> > drivers/gpu/drm/i915/intel_sprite.c | 3 +-
> > 3 files changed, 61 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 34f7225..7fd8354 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3466,6 +3466,8 @@ static u32 skl_plane_ctl_format(uint32_t
> > >> pixel_format)
> > return PLANE_CTL_FORMAT_YUV422 |
> > >> PLANE_CTL_YUV422_UYVY;
> > case DRM_FORMAT_VYUY:
> > return PLANE_CTL_FORMAT_YUV422 |
> > >> PLANE_CTL_YUV422_VYUY;
> > + case DRM_FORMAT_NV12:
> > + return PLANE_CTL_FORMAT_NV12;
> > default:
> > MISSING_CASE(pixel_format);
> > }
> > @@ -4705,7 +4707,9 @@ static void cpt_verify_modeset(struct
> > drm_device *dev, int pipe) static int skl_update_scaler(struct
> > intel_crtc_state *crtc_state, bool force_detach,
> > unsigned int scaler_user, int *scaler_id,
> > -int src_w, int src_h, int dst_w, int dst_h)
> > +int src_w, int src_h, int dst_w, int dst_h,
> > +bool plane_scaler_check,
> > +uint32_t pixel_format)
> > {
> > struct intel_crtc_scaler_state *scaler_state =
> > &crtc_state->scaler_state;
> > @@ -4723,6 +4727,10 @@ skl_update_scaler(struct intel_crtc_state
> > >> *crtc_state, bool force_detach,
> > */
> > need_scaling = src_w != dst_w || src_h != dst_h;
> >
[Intel-gfx] ✗ Fi.CI.BAT: failure for Aspect ratio support in DRM layer
== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/39960/ State : failure == Summary == Series 39960v1 Aspect ratio support in DRM layer https://patchwork.freedesktop.org/api/1.0/series/39960/revisions/1/mbox/ Possible new issues: Test debugfs_test: Subgroup read_all_entries: pass -> INCOMPLETE (fi-bdw-5557u) pass -> INCOMPLETE (fi-bdw-gvtdvm) pass -> INCOMPLETE (fi-bsw-n3050) pass -> INCOMPLETE (fi-bxt-dsi) pass -> INCOMPLETE (fi-bxt-j4205) pass -> INCOMPLETE (fi-byt-j1900) pass -> INCOMPLETE (fi-byt-n2820) pass -> INCOMPLETE (fi-cfl-8700k) pass -> INCOMPLETE (fi-cfl-u) pass -> INCOMPLETE (fi-cnl-y3) pass -> INCOMPLETE (fi-hsw-4770) pass -> INCOMPLETE (fi-ivb-3520m) pass -> INCOMPLETE (fi-ivb-3770) pass -> INCOMPLETE (fi-kbl-7500u) pass -> INCOMPLETE (fi-kbl-7567u) pass -> INCOMPLETE (fi-kbl-r) pass -> INCOMPLETE (fi-skl-6260u) pass -> INCOMPLETE (fi-skl-6600u) pass -> INCOMPLETE (fi-skl-6700hq) pass -> INCOMPLETE (fi-skl-6770hq) pass -> INCOMPLETE (fi-skl-guc) pass -> INCOMPLETE (fi-skl-gvtdvm) pass -> INCOMPLETE (fi-snb-2600) Test kms_busy: Subgroup basic-flip-a: pass -> INCOMPLETE (fi-skl-6700k2) Known issues: Test debugfs_test: Subgroup read_all_entries: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-bdw-gvtdvmtotal:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:300s fi-bxt-dsi total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-bxt-j4205 total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-byt-j1900 total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-byt-n2820 total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-cfl-8700k total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-cfl-u total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-cnl-y3total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:316s fi-hsw-4770 total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-ivb-3520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-ivb-3770 total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-kbl-7500u total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-kbl-7567u total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-kbl-r total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:656s fi-skl-6260u total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-skl-6600u total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-skl-6700hqtotal:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-skl-6700k2total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-6770hqtotal:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-skl-guc total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-skl-gvtdvmtotal:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 Blacklisted hosts: fi-cnl-drrs total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 f25b08dcf09c72da5a530dca49a4b93bd6d75395 drm-tip: 2018y-03m-14d-14h-33m-13s UTC integration manifest 66bf96cb81bf drm: Add and handle new aspect ratios in DRM layer 80d25a6111f8 drm: Add aspect ratio parsing in DRM layer 379b4f8d66d6 drm: Expose modes with aspect ratio, only if requested 359f0f077e28 drm: Handle aspect ratio info in legacy and atomic modeset paths 9837d35d48c9 drm: Handle aspect-ratio info in getblob 59aaeea05d17 drm: Add DRM client cap for aspect-ratio d32c25792da3 video/hdmi: Reject illegal picture aspect ratios f934f537fa46 drm/edid: Don't send bogus aspect ratios in AVI infoframes 860a8ce3ff3e drm/e
Re: [Intel-gfx] [PATCH 13/36] drm/i915: Merge sandybridge_pcode_(read|write)
On Wed, Mar 14, 2018 at 09:37:25AM +, Chris Wilson wrote:
> These routines are identical except in the nature of the value parameter.
> For writes it is a pure in-param, but for a read, we need an out-param.
> Since they differ in a single line, merge the two routines into one.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_pm.c | 114
> ++--
> 1 file changed, 40 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6d5003b521f2..6259c95ce293 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -9159,12 +9159,10 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
> }
> }
>
> -static inline int gen6_check_mailbox_status(struct drm_i915_private
> *dev_priv)
> +static inline int gen6_check_mailbox_status(struct drm_i915_private
> *dev_priv,
> + u32 mbox)
> {
> - uint32_t flags =
> - I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_ERROR_MASK;
> -
> - switch (flags) {
> + switch (mbox & GEN6_PCODE_ERROR_MASK) {
> case GEN6_PCODE_SUCCESS:
> return 0;
> case GEN6_PCODE_UNIMPLEMENTED_CMD:
> @@ -9177,17 +9175,15 @@ static inline int gen6_check_mailbox_status(struct
> drm_i915_private *dev_priv)
> case GEN6_PCODE_TIMEOUT:
> return -ETIMEDOUT;
> default:
> - MISSING_CASE(flags);
> + MISSING_CASE(mbox & GEN6_PCODE_ERROR_MASK);
> return 0;
> }
> }
>
> -static inline int gen7_check_mailbox_status(struct drm_i915_private
> *dev_priv)
> +static inline int gen7_check_mailbox_status(struct drm_i915_private
> *dev_priv,
> + u32 mbox)
> {
> - uint32_t flags =
> - I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_ERROR_MASK;
> -
> - switch (flags) {
> + switch (mbox & GEN6_PCODE_ERROR_MASK) {
> case GEN6_PCODE_SUCCESS:
> return 0;
> case GEN6_PCODE_ILLEGAL_CMD:
> @@ -9199,18 +9195,21 @@ static inline int gen7_check_mailbox_status(struct
> drm_i915_private *dev_priv)
> case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
> return -EOVERFLOW;
> default:
> - MISSING_CASE(flags);
> + MISSING_CASE(mbox & GEN6_PCODE_ERROR_MASK);
> return 0;
> }
> }
>
> -static int __sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32
> mbox, u32 *val)
> +static int __sandybridge_pcode_rw(struct drm_i915_private *dev_priv,
> + u32 mbox, u32 *val,
> + int fast_timeout_us,
> + int slow_timeout_ms,
> + bool is_read)
> {
> - int status;
> -
> lockdep_assert_held(&dev_priv->sb_lock);
>
> - /* GEN6_PCODE_* are outside of the forcewake domain, we can
> + /*
> + * GEN6_PCODE_* are outside of the forcewake domain, we can
>* use te fw I915_READ variants to reduce the amount of work
>* required when reading/writing.
>*/
> @@ -9224,69 +9223,36 @@ static int __sandybridge_pcode_read(struct
> drm_i915_private *dev_priv, u32 mbox,
>
> if (__intel_wait_for_register_fw(dev_priv,
>GEN6_PCODE_MAILBOX, GEN6_PCODE_READY,
> 0,
> - 500, 0, NULL))
> + fast_timeout_us,
> + slow_timeout_ms,
> + &mbox))
> return -ETIMEDOUT;
>
> - *val = I915_READ_FW(GEN6_PCODE_DATA);
> - I915_WRITE_FW(GEN6_PCODE_DATA, 0);
> + if (is_read)
> + *val = I915_READ_FW(GEN6_PCODE_DATA);
So we stop clearing GEN6_PCODE_DATA. It gets set before the next pcode
access, so yes looks redundant here. The patch looks ok:
Reviewed-by: Imre Deak
>
> if (INTEL_GEN(dev_priv) > 6)
> - status = gen7_check_mailbox_status(dev_priv);
> + return gen7_check_mailbox_status(dev_priv, mbox);
> else
> - status = gen6_check_mailbox_status(dev_priv);
> -
> - return status;
> + return gen6_check_mailbox_status(dev_priv, mbox);
> }
>
> int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
> *val)
> {
> - int status;
> + int err;
>
> mutex_lock(&dev_priv->sb_lock);
> - status = __sandybridge_pcode_read(dev_priv, mbox, val);
> + err = __sandybridge_pcode_rw(dev_priv, mbox, val,
> + 500, 0,
> + true);
> mutex_unlock(&dev_priv->sb_lock);
>
> - if (status) {
> + if (err) {
> DRM_DEBUG_DRIVER("warning: pcode (read from mbox %x) mailbox
> access failed for %ps: %d\n",
> - mbox,
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Aspect ratio support in DRM layer
== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/39960/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/modes: Introduce drm_mode_match() Okay! Commit: drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy Okay! Commit: drm/edid: Fix cea mode aspect ratio handling Okay! Commit: drm/edid: Don't send bogus aspect ratios in AVI infoframes Okay! Commit: video/hdmi: Reject illegal picture aspect ratios Okay! Commit: drm: Add DRM client cap for aspect-ratio Okay! Commit: drm: Handle aspect-ratio info in getblob +drivers/gpu/drm/drm_property.c:776:71:expected struct drm_mode_modeinfo *umode +drivers/gpu/drm/drm_property.c:776:71:got struct drm_mode_modeinfo [noderef] *mode +drivers/gpu/drm/drm_property.c:776:71: warning: incorrect type in argument 2 (different address spaces) Commit: drm: Handle aspect ratio info in legacy and atomic modeset paths Okay! Commit: drm: Expose modes with aspect ratio, only if requested Okay! Commit: drm: Add aspect ratio parsing in DRM layer Okay! Commit: drm: Add and handle new aspect ratios in DRM layer Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [maintainer-tools PATCH] doc: how to become a drm-intel committer
Until now, the drm-intel commit access have been handed out ad hoc, without transparency, consistency, or fairness. With pressure to add more committers, this is no longer tenable, if it ever was. Document the requirements and expectations around becoming a drm-intel committer. The Linux kernel operates in a model where, by and large, only maintainers commit patches. Maintainer teams are no longer rare, but the drm-intel and drm-misc maintainer/committer model is definitely an outlier. The drm-intel maintainers believe that a reasonable level of experience and track record of working on the driver, as well as actively engaging in the community upstream, are necessary before becoming a committer. While the requirements outlined here may seem strict in contrast with many projects, they are extremely liberal by kernel standards. Finally, no rules are carved in stone. We fully expect the requirements to be adjusted later. However, it will be much easier to start strict and relax the requirements later than the other way round. Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: Dave Airlie Cc: dim-to...@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Jani Nikula Signed-off-by: Joonas Lahtinen Signed-off-by: Rodrigo Vivi --- We encourage the drm-misc maintainers to consider and document your requirements for committers. While there's certain appeal to aligning on the rules between drm-misc and drm-intel, we don't think they necessarily have to be the same. --- commit-access.rst | 143 ++ index.rst | 1 + 2 files changed, 144 insertions(+) create mode 100644 commit-access.rst diff --git a/commit-access.rst b/commit-access.rst new file mode 100644 index ..dbc50f2b5bd3 --- /dev/null +++ b/commit-access.rst @@ -0,0 +1,143 @@ +=== + Commit Access +=== + +The drm-misc and drm-intel repositories operate in a maintainer/committer model +with a large pool committers who can push patches in accordance with the stated +merge criteria, and maintainers handling pull requests, topic branches, merges, +and so on. + +This document outlines the requirements for becoming a committer. + +drm-misc + + +TBD. + +drm-intel +- + +Requirements + + +The baseline requirements for becoming a drm-intel committer are: + +- Comfortable with the open collaboration model we have. + +- Enough experience to gauge reasonably well how much review a patch needs, and + when pushing a patch, whether it needs acks from domain experts or + maintainers. + +- Strong presence in the project communication channels (intel-gfx mailing list + and #intel-gfx IRC channel) for topics in their area of expertise. + +Since everyone is different and has different focus in their work, there are no +hard and fast rules, but just indicators and some judgement. + +Positive indicators are: + +- Decent amount of non-trivial patches merged in the past year (25+ patches, + excluding simple code movement, typo fixes and similar patches). + +- Decent amount of in-depth review, again 25+ in the past year as the threshold. + +- Lots of experience and commit rights in related open-source projects, like + Mesa, or kernel trees like drm-misc, since the processes are very similar. 2+ + years as the threshold here, and this is also fulfilled after 2+ years of + working in the virtual upstream team (product tree hacking doesn't count). + +- Already merged a complex feature, e.g. spanning multiple subsystems or even + involving userspace. + +- Active member on freedesktop.org bugzilla. A developer that besides submitting + patches to fix bugs is also engaged on bugs discussion giving constructive + comments helping to drive the bug entry to a solution. Hence keeping bug list + active, clean, and under control. + +Contra-indicators are: + +- Not around on IRC (taking timezones into account of course). + +- Mostly simple patches and rubber-stamping reviews not resulting in in-depth + discussions. + +- No complete feature patch set merged yet. + +As a rule of thumb, commit rights will be granted when most positive indicators +are fulfilled and no negative indicators present. The current project +maintainers assess whether a candidate meets the requirements, and make the +decisions about commit rights. + +Nomination +~~ + +Any developer, who already have demonstrated some of positive requirements, can +be nominated at any time by anyone: maintainers, committers, managers, peers, +and even self nomination are accepted. + +Nomination process is simply sending an email to the drm-intel +maintainers. Please nominate one person per email, and Cc: the +nominee. Nominations are processed by the maintainers on a first come, first +served basis, as nominations are received. + +Nomination is not a guarantee of the commit rights. In case a nomination is +rejected, the ma
Re: [Intel-gfx] [PATCH 3/3] drm: Store the calculated vrefresh in the user mode
On Tue, Mar 13, 2018 at 08:04:03PM +0100, Maarten Lankhorst wrote: > Op 13-03-18 om 16:07 schreef Ville Syrjala: > > From: Ville Syrjälä > > > > Ignore the vrefresh in the mode the user passed in and instead > > calculate the value based on the actual timings. This way we can > > actually trust mode->vrefresh to some degree. > > > > Or should we compare the user's idea of vrefresh with the one > > we get from the timings and return an error if they differ? We > > can't really be sure what the user is asking in that case. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/drm_modes.c | 8 +++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > > index f6b7c0e36a1a..021526ec6fa0 100644 > > --- a/drivers/gpu/drm/drm_modes.c > > +++ b/drivers/gpu/drm/drm_modes.c > > @@ -1609,7 +1609,11 @@ int drm_mode_convert_umode(struct drm_device *dev, > > out->vsync_end = in->vsync_end; > > out->vtotal = in->vtotal; > > out->vscan = in->vscan; > > - out->vrefresh = in->vrefresh; > > +/* > > + * Ignore what the user is saying here and instead > > + * calculate vrefresh based on the actual timings. > > + */ > > + out->vrefresh = 0; > > out->flags = in->flags; > > out->type = in->type; > > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN); > > @@ -1619,6 +1623,8 @@ int drm_mode_convert_umode(struct drm_device *dev, > > if (out->status != MODE_OK) > > return -EINVAL; > > > > + out->vrefresh = drm_mode_vrefresh(out); > > + > > drm_mode_set_crtcinfo(out, CRTC_INTERLACE_HALVE_V); > > > > return 0; > > Could we also get this with dim fixes tags dc911f5bd8aa, so we can backport > the alt mode handling patch? Do we want/need to backport it actually? > > And update the documentation about vrefresh, that you can retrieve it with > drm_mode_vrefresh? The whole "return cached value if present, otherwise calculate but don't update the cached value" apporach always seemed off to me. Might be a good idea to change it somehow. Maybe just always calculate it, or do the cached value updates in sensible places so that you only have to calculate once. But I haven't actually checked how much work that would entail. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
