Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree

2019-08-15 Thread Daniel Vetter
On Fri, Aug 16, 2019 at 6:48 AM Sam Ravnborg wrote: > > Hi Stephen. > > On Fri, Aug 16, 2019 at 01:31:32PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the drm-misc tree, today's linux-next build (x86_64 > > allmodconfig) produced this warning: > > > > warning: same module name

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Daniel Vetter
On Fri, Aug 16, 2019 at 3:00 AM Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 10:49:31PM +0200, Daniel Vetter wrote: > > On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote: > > > > So if someone can explain to me how that

Re: [Intel-gfx] [v7][PATCH 00/12] drm/i915: adding state checker for gamma lut values

2019-08-15 Thread Sharma, Swati2
Hi Jani, I was involved in other activities. Will resume work on this now. Thanks and Regards, Swati -Original Message- From: Jani Nikula Sent: Thursday, August 15, 2019 1:44 PM To: Sharma, Swati2 ; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [v7][PATCH 00/12] drm/i915: a

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Dynamically allocate s0ix struct for VLV

2019-08-15 Thread Lucas De Marchi
On Thu, Aug 15, 2019 at 6:24 PM Daniele Ceraolo Spurio wrote: > > This is only required for a single platform so no need to reserve the > memory on all of them. > > This removes the last direct dependency of i915_drv.h on i915_reg.h > (apart from the i915_reg_t definition). > > Signed-off-by: Dani

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Move gmbus definitions out of i915_reg.h

2019-08-15 Thread Lucas De Marchi
On Thu, Aug 15, 2019 at 6:24 PM Daniele Ceraolo Spurio wrote: > > They're not related to registers, so move them to the more appropriate > intel_gmbus.h > > Signed-off-by: Daniele Ceraolo Spurio > Cc: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_gmbus.h | 22 ++ >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftest/buddy: fixup igt_buddy_alloc_range

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915/selftest/buddy: fixup igt_buddy_alloc_range URL : https://patchwork.freedesktop.org/series/65256/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14029_full Summary

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Move engine IDs out of i915_reg.h

2019-08-15 Thread Lucas De Marchi
On Thu, Aug 15, 2019 at 6:23 PM Daniele Ceraolo Spurio wrote: > > To remove the dependency between the GT headers and i915_reg.h, move the > definition of the engine IDs/classes to intel_engine_types.h > > Signed-off-by: Daniele Ceraolo Spurio > Cc: Chris Wilson > Cc: Tvrtko Ursulin Reviewed-b

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Move i915_power_well_id out of i915_reg.h

2019-08-15 Thread Lucas De Marchi
On Thu, Aug 15, 2019 at 6:24 PM Daniele Ceraolo Spurio wrote: > > It has nothing to do with registers, so move it to the more appropriate > intel_display_power.h > > Signed-off-by: Daniele Ceraolo Spurio > Cc: Imre Deak > --- > .../drm/i915/display/intel_display_power.c| 1 + > .../drm/i91

Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree

2019-08-15 Thread Sam Ravnborg
Hi Stephen. On Fri, Aug 16, 2019 at 01:31:32PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the drm-misc tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > warning: same module names found: > drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl804

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache (rev2)

2019-08-15 Thread Patchwork
== Series Details == Series: series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache (rev2) URL : https://patchwork.freedesktop.org/series/65226/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14028_full ==

[Intel-gfx] linux-next: build warning after merge of the drm-misc tree

2019-08-15 Thread Stephen Rothwell
Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) produced this warning: warning: same module names found: drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.ko drivers/gpu/drm/panel/panel-nec-nl8048hl11.ko warning: same module names found:

Re: [Intel-gfx] Linux Kernel 5.2.8 (uvc or i915? <<<)

2019-08-15 Thread Randy Dunlap
[adding mailing lists etc. with Nathaniel's test info] On 8/15/19 7:21 PM, Nathaniel Russell wrote: > Well i surpressed the uvcvideo driver and you are right Randy it > definitely is not the uvcvideo driver. There is something going on in > the i915 driver. > > > On 8/15/19, Randy Dunlap wrote

Re: [Intel-gfx] [PATCH 1/3] drm/i915/tgl: Introduce initial Tigerlake Workarounds

2019-08-15 Thread Lucas De Marchi
On Tue, Aug 13, 2019 at 11:07:54AM -0700, Radhakrishna Sripada wrote: On Thu, Jul 25, 2019 at 05:02:24PM -0700, Lucas De Marchi wrote: From: Michel Thierry Inherit workarounds from previous platforms that are still valid for Tigerlake. WaPipelineFlushCoherentLines:tgl (changed register but

[Intel-gfx] ✓ Fi.CI.BAT: success for Some more display uncore prep work

2019-08-15 Thread Patchwork
== Series Details == Series: Some more display uncore prep work URL : https://patchwork.freedesktop.org/series/65281/ State : success == Summary == CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14043 Summary --- **SUCCESS** N

Re: [Intel-gfx] Linux Kernel 5.2.8 (uvc or i915?)

2019-08-15 Thread Randy Dunlap
On 8/15/19 6:15 PM, Nathaniel Russell wrote: > I would really like help with the kernel error with my uvcvideo driver. > Hi again. What makes you think that the problem is related to the uvcvideo driver? Does some previous kernel version work correctly? If so, what version(s)? Does this warni

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Some more display uncore prep work

2019-08-15 Thread Patchwork
== Series Details == Series: Some more display uncore prep work URL : https://patchwork.freedesktop.org/series/65281/ State : warning == Summary == $ dim checkpatch origin/drm-tip 683fe77978b3 drm/i915: Move i915_power_well_id out of i915_reg.h 54c3dc873f33 drm/i915: Move engine IDs out of i91

[Intel-gfx] [PATCH 1/6] drm/i915: Move i915_power_well_id out of i915_reg.h

2019-08-15 Thread Daniele Ceraolo Spurio
It has nothing to do with registers, so move it to the more appropriate intel_display_power.h Signed-off-by: Daniele Ceraolo Spurio Cc: Imre Deak --- .../drm/i915/display/intel_display_power.c| 1 + .../drm/i915/display/intel_display_power.h| 21 +++ drivers/gpu/drm/i91

[Intel-gfx] [PATCH 2/6] drm/i915: Move engine IDs out of i915_reg.h

2019-08-15 Thread Daniele Ceraolo Spurio
To remove the dependency between the GT headers and i915_reg.h, move the definition of the engine IDs/classes to intel_engine_types.h Signed-off-by: Daniele Ceraolo Spurio Cc: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_engine_types.h | 20 +++ drivers/gpu/drm

[Intel-gfx] [PATCH 6/6] drm/i915: Wrappers for display register waits

2019-08-15 Thread Daniele Ceraolo Spurio
To reduce the number of explicit dev_priv->uncore calls in the display code ahead of the introduction of dev_priv->de_uncore, this patch introduces a wrapper for one of the main usages of it, the register waits. When we transition to the new uncore, we can just update the wrapper to point to the ap

[Intel-gfx] [PATCH 0/6] Some more display uncore prep work

2019-08-15 Thread Daniele Ceraolo Spurio
Since we want to tag registers as belonging to display, I believe it'd be nice to move them to a dedicated header in the display folder and include just that in .c files, to make sure we get the split right. The first 4 patches of the series prepare i915_drv.h for being able to not use definition f

[Intel-gfx] [PATCH 4/6] drm/i915: Dynamically allocate s0ix struct for VLV

2019-08-15 Thread Daniele Ceraolo Spurio
This is only required for a single platform so no need to reserve the memory on all of them. This removes the last direct dependency of i915_drv.h on i915_reg.h (apart from the i915_reg_t definition). Signed-off-by: Daniele Ceraolo Spurio Cc: Imre Deak --- drivers/gpu/drm/i915/i915_drv.c | 107

[Intel-gfx] [PATCH 3/6] drm/i915: Move gmbus definitions out of i915_reg.h

2019-08-15 Thread Daniele Ceraolo Spurio
They're not related to registers, so move them to the more appropriate intel_gmbus.h Signed-off-by: Daniele Ceraolo Spurio Cc: Jani Nikula --- drivers/gpu/drm/i915/display/intel_gmbus.h | 22 ++ drivers/gpu/drm/i915/i915_drv.h| 1 + drivers/gpu/drm/i915/i915_reg

[Intel-gfx] [PATCH 5/6] drm/i915: Introduce i915_reg_types.h

2019-08-15 Thread Daniele Ceraolo Spurio
With the introduction of display uncore, we want to categorize registers between display and non-display. To help us getting it right, it will be useful to move the display registers to a new file that can be used without including i915_reg.h. To allow that, move all the basic register type definit

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/uc: Add explicit DISABLED state for firmware

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915/uc: Add explicit DISABLED state for firmware URL : https://patchwork.freedesktop.org/series/65278/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14042 Summary ---

Re: [Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Daniele Ceraolo Spurio
On 8/15/19 5:21 PM, Michal Wajdeczko wrote: On Fri, 16 Aug 2019 02:10:26 +0200, Daniele Ceraolo Spurio wrote: On 8/15/19 2:48 PM, Michal Wajdeczko wrote: We can do WOPCM partitioning using rough estimates and limits and perform detailed check as separate step.  v2: oops! s/max/min  Signe

Re: [Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Michal Wajdeczko
On Fri, 16 Aug 2019 02:10:26 +0200, Daniele Ceraolo Spurio wrote: On 8/15/19 2:48 PM, Michal Wajdeczko wrote: We can do WOPCM partitioning using rough estimates and limits and perform detailed check as separate step. v2: oops! s/max/min Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraol

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Allow usage of all GPIO pins (rev2)

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915/gen11: Allow usage of all GPIO pins (rev2) URL : https://patchwork.freedesktop.org/series/65261/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14041 Summary ---

Re: [Intel-gfx] [PATCH 3/5] drm/i915/wopcm: Try to use already locked WOPCM layout

2019-08-15 Thread Daniele Ceraolo Spurio
On 8/15/19 10:12 AM, Michal Wajdeczko wrote: If WOPCM layout is already locked in HW we shouldn't continue with our own partitioning as it could be likely different and we will be unable to enforce it and fail. Instead we should try to reuse what is already programmed, maybe there will be a fit

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Convert a few more bland dmesg info to be device specific

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915: Convert a few more bland dmesg info to be device specific URL : https://patchwork.freedesktop.org/series/65253/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14027_full ==

Re: [Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Daniele Ceraolo Spurio
On 8/15/19 2:48 PM, Michal Wajdeczko wrote: We can do WOPCM partitioning using rough estimates and limits and perform detailed check as separate step. v2: oops! s/max/min Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_wopcm.c |

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Add Wa_1604278689:icl,ehl

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915/gen11: Add Wa_1604278689:icl,ehl URL : https://patchwork.freedesktop.org/series/65276/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14040 Summary --- **FAILURE

[Intel-gfx] [PATCH] drm/i915/uc: Add explicit DISABLED state for firmware

2019-08-15 Thread Michal Wajdeczko
We really need to have separate NOT_SUPPORTED state (for lack of hardware support) and DISABLED state (to indicate user decision) as we will have to take special steps even if GuC firmware is now disabled but hardware exists and could have been previously used. Signed-off-by: Michal Wajdeczko Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for More WOPCM fixes (rev2)

2019-08-15 Thread Patchwork
== Series Details == Series: More WOPCM fixes (rev2) URL : https://patchwork.freedesktop.org/series/65263/ State : success == Summary == CI Bug Log - changes from CI_DRM_6714 -> Patchwork_14039 Summary --- **SUCCESS** No regressio

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp/dsc: Add Support for all BPCs supported by TGL (rev4)

2019-08-15 Thread Patchwork
== Series Details == Series: drm/dp/dsc: Add Support for all BPCs supported by TGL (rev4) URL : https://patchwork.freedesktop.org/series/63526/ State : success == Summary == CI Bug Log - changes from CI_DRM_6713 -> Patchwork_14038 Summary -

[Intel-gfx] [PATCH] drm/i915/gen11: Allow usage of all GPIO pins

2019-08-15 Thread Matt Roper
Our pin mapping tables for ICP and MCC currently only list the standard GPIO pins used for various output ports. Even through ICP's standard pin usage only utilizes pins 1, 2, and 9-12, and MCC's standard pin usage only uses pins 1, 2, and 9, these platforms do still have GPIO registers to address

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache

2019-08-15 Thread Patchwork
== Series Details == Series: series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache URL : https://patchwork.freedesktop.org/series/65226/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14025_full =

Re: [Intel-gfx] [PATCH] drm/i915/gen11: Add Wa_1604278689:icl,ehl

2019-08-15 Thread Matt Roper
On Thu, Aug 15, 2019 at 11:19:36PM +0100, Chris Wilson wrote: > Quoting Matt Roper (2019-08-15 22:58:59) > > From the bspec: > > > > "SW must always program the FBC_RT_BASE_ADDR_REGISTER_* register > > in Render Engine to a reserved value (0x_) such that the > > pro

Re: [Intel-gfx] [PATCH] drm/i915/gen11: Add Wa_1604278689:icl,ehl

2019-08-15 Thread Chris Wilson
Quoting Matt Roper (2019-08-15 22:58:59) > From the bspec: > > "SW must always program the FBC_RT_BASE_ADDR_REGISTER_* register > in Render Engine to a reserved value (0x_) such that the > programmed value doesn’t match the render target surface address > pr

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Andrew Morton
On Thu, 15 Aug 2019 10:44:29 +0200 Michal Hocko wrote: > > I continue to struggle with this. It introduces a new kernel state > > "running preemptibly but must not call schedule()". How does this make > > any sense? > > > > Perhaps a much, much more detailed description of the oom_reaper > > s

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915/gt: Track timeline activeness in enter/exit

2019-08-15 Thread Patchwork
== Series Details == Series: series starting with [CI,1/4] drm/i915/gt: Track timeline activeness in enter/exit URL : https://patchwork.freedesktop.org/series/65274/ State : success == Summary == CI Bug Log - changes from CI_DRM_6713 -> Patchwork_14037

[Intel-gfx] [PATCH] drm/i915/gen11: Add Wa_1604278689:icl,ehl

2019-08-15 Thread Matt Roper
From the bspec: "SW must always program the FBC_RT_BASE_ADDR_REGISTER_* register in Render Engine to a reserved value (0x_) such that the programmed value doesn’t match the render target surface address programmed. This would disable render engine from gener

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT (rev2)

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT (rev2) URL : https://patchwork.freedesktop.org/series/65222/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14024_full ==

[Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Michal Wajdeczko
We can do WOPCM partitioning using rough estimates and limits and perform detailed check as separate step. v2: oops! s/max/min Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_wopcm.c | 105 - 1 file changed

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for More WOPCM fixes

2019-08-15 Thread Michal Wajdeczko
On Thu, 15 Aug 2019 19:52:44 +0200, Patchwork wrote: == Series Details == Series: More WOPCM fixes URL : https://patchwork.freedesktop.org/series/65263/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14032

Re: [Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Chris Wilson
Quoting Takashi Iwai (2019-08-15 20:42:14) [snip] > > Gah, that's a breakage by the commit ee5f85d9290f ("ALSA: hda: Add > codec on bus address table lately"). Please revert it in your tree, > I'll do it same on sound git tree now. Thanks for taking care of it! -Chris ___

[Intel-gfx] [v3] drm/dp/dsc: Add Support for all BPCs supported by TGL

2019-08-15 Thread Anusha Srivatsa
DSC engine on ICL supports only 8 and 10 BPC as the input BPC. But DSC engine in TGL supports 8, 10 and 12 BPC. Add 12 BPC support for DSC while calculating compression configuration. v2: Remove the separate define TGL_DP_DSC_MAX_SUPPORTED_BPC and use the value directly.(More such defines can be r

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Move tasklet kicking to __i915_request_queue caller

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915: Move tasklet kicking to __i915_request_queue caller URL : https://patchwork.freedesktop.org/series/65221/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711_full -> Patchwork_14022_full

[Intel-gfx] [CI 3/4] drm/i915/gt: Guard timeline pinning without relying on struct_mutex

2019-08-15 Thread Chris Wilson
In preparation for removing struct_mutex from around context retirement, we need to make timeline pinning and unpinning safe. Since multiple engines/contexts can share a single timeline, we cannot rely on borrowing the context mutex (otherwise we could state that the timeline is only pinned/unpinne

[Intel-gfx] [CI 1/4] drm/i915/gt: Track timeline activeness in enter/exit

2019-08-15 Thread Chris Wilson
Lift moving the timeline to/from the active_list on enter/exit in order to shorten the active tracking span in comparison to the existing pin/unpin. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_pm.c| 1 - drivers/gpu/drm/i915/gt/intel_cont

[Intel-gfx] [CI 2/4] drm/i915/gt: Convert timeline tracking to spinlock

2019-08-15 Thread Chris Wilson
Convert the active_list manipulation of timelines to use spinlocks so that we can perform the updates from underneath a quick interrupt callback, if need be. Signed-off-by: Chris Wilson Matthew Auld --- drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +- drivers/gpu/drm/i915/gt/intel_reset.c|

[Intel-gfx] [CI 4/4] drm/i915: Protect request retirement with timeline->mutex

2019-08-15 Thread Chris Wilson
Forgo the struct_mutex requirement for request retirement as we have been transitioning over to only using the timeline->mutex for controlling the lifetime of a request on that timeline. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 18

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "ALSA: hda: Add codec on bus address table lately"

2019-08-15 Thread Patchwork
== Series Details == Series: Revert "ALSA: hda: Add codec on bus address table lately" URL : https://patchwork.freedesktop.org/series/65271/ State : success == Summary == CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14036 Summary

Re: [Intel-gfx] [PATCH v3 hmm 08/11] drm/radeon: use mmu_notifier_get/put for struct radeon_mn

2019-08-15 Thread Jason Gunthorpe
On Thu, Aug 15, 2019 at 10:28:21AM +0200, Christian König wrote: > Am 07.08.19 um 01:15 schrieb Jason Gunthorpe: > > From: Jason Gunthorpe > > > > radeon is using a device global hash table to track what mmu_notifiers > > have been registered on struct mm. This is better served with the new > > g

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Daniel Vetter
On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote: > > So if someone can explain to me how that works with lockdep I can of > > course implement it. But afaics that doesn't exist (I tried to explain > > that somewhere else alrea

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Protect request retirement with timeline->mutex

2019-08-15 Thread Chris Wilson
Quoting Matthew Auld (2019-08-15 21:33:07) > On Wed, 14 Aug 2019 at 10:28, Chris Wilson wrote: > > > > Forgo the struct_mutex requirement for request retirement as we have > > been transitioning over to only using the timeline->mutex for > > controlling the lifetime of a request on that timeline.

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Extract intel_frontbuffer active tracking

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:27, Chris Wilson wrote: > > Move the active tracking for the frontbuffer operations out of the > i915_gem_object and into its own first class (refcounted) object. In the > process of detangling, we switch from low level request tracking to the > easier i915_active -- with

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Protect request retirement with timeline->mutex

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:28, Chris Wilson wrote: > > Forgo the struct_mutex requirement for request retirement as we have > been transitioning over to only using the timeline->mutex for > controlling the lifetime of a request on that timeline. > > Signed-off-by: Chris Wilson > --- > .../gpu/drm

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Daniel Vetter
On Thu, Aug 15, 2019 at 9:35 PM Michal Hocko wrote: > > On Thu 15-08-19 16:18:10, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 09:05:25PM +0200, Michal Hocko wrote: > > > > > This is what you claim and I am saying that fs_reclaim is about a > > > restricted reclaim context and it is an ugly

[Intel-gfx] [PATCH] Revert "ALSA: hda: Add codec on bus address table lately"

2019-08-15 Thread Takashi Iwai
This reverts commit ee5f85d9290f ("ALSA: hda: Add codec on bus address table lately"). The commit caused several regression since I've overlooked that the function doesn't manage only the caddr_tbl but also the codec linked list that is referred indirectly in the other drivers. Revert for now to

Re: [Intel-gfx] [PATCH 4/8] drm/i915/gt: Guard timeline pinning with its own mutex

2019-08-15 Thread Chris Wilson
Quoting Matthew Auld (2019-08-15 20:19:58) > On Wed, 14 Aug 2019 at 10:28, Chris Wilson wrote: > > > > In preparation for removing struct_mutex from around context retirement, > > we need to make timeline pinning safe. Since multiple engines/contexts > > can share a single timeline, it needs to be

Re: [Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Takashi Iwai
On Thu, 15 Aug 2019 20:15:51 +0200, Chris Wilson wrote: > > In the recent snd merge of > > ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff > 53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device() > ee5f85d9290f ALSA: hda: Add codec on bus address table lately > f2dbe87c5ac1 ALS

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Michal Hocko
On Thu 15-08-19 16:18:10, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 09:05:25PM +0200, Michal Hocko wrote: > > > This is what you claim and I am saying that fs_reclaim is about a > > restricted reclaim context and it is an ugly hack. It has proven to > > report false positives. Maybe it can

Re: [Intel-gfx] [PATCH] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head

2019-08-15 Thread Tang, CQ
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Daniel Vetter > Sent: Wednesday, August 14, 2019 12:25 PM > To: Intel Graphics Development > Cc: Daniel Vetter ; Vetter, Daniel > > Subject: [Intel-gfx] [PATCH] RFC: drm/i915: Switch o

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove i915 ggtt WA since GT E0 (rev3)

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915: Remove i915 ggtt WA since GT E0 (rev3) URL : https://patchwork.freedesktop.org/series/65160/ State : success == Summary == CI Bug Log - changes from CI_DRM_6710_full -> Patchwork_14021_full Summary ---

Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

2019-08-15 Thread Chris Wilson
Quoting Chris Wilson (2019-08-15 20:03:13) > Quoting Daniel Vetter (2019-08-15 19:48:42) > > On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson > > wrote: > > > Quoting Daniel Vetter (2019-08-14 18:20:53) > > > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > > > > Now that dma_fence

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5] dma-fence: Propagate errors to dma-fence-array container (rev7)

2019-08-15 Thread Patchwork
== Series Details == Series: series starting with [v5] dma-fence: Propagate errors to dma-fence-array container (rev7) URL : https://patchwork.freedesktop.org/series/65027/ State : failure == Summary == Applying: dma-fence: Propagate errors to dma-fence-array container Using index info to rec

Re: [Intel-gfx] [PATCH 4/8] drm/i915/gt: Guard timeline pinning with its own mutex

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:28, Chris Wilson wrote: > > In preparation for removing struct_mutex from around context retirement, > we need to make timeline pinning safe. Since multiple engines/contexts > can share a single timeline, it needs to be protected by a mutex. > > Signed-off-by: Chris Wilso

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Tolakanahalli Pradeep, Madhumitha
On Thu, 2019-08-15 at 11:53 -0700, Manasi Navare wrote: > On Thu, Aug 15, 2019 at 11:39:54AM -0700, Tolakanahalli Pradeep, > Madhumitha wrote: > > On Thu, 2019-08-15 at 11:24 -0700, Manasi Navare wrote: > > > On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha > > > Tolakanahalli > > > Pradeep wro

Re: [Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Chris Wilson
Quoting Chris Wilson (2019-08-15 19:15:51) > In the recent snd merge of > > ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff > 53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device() > ee5f85d9290f ALSA: hda: Add codec on bus address table lately > f2dbe87c5ac1 ALSA: hda - Drop un

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Michal Hocko
On Thu 15-08-19 15:24:48, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 07:42:07PM +0200, Michal Hocko wrote: > > On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Patchwork
== Series Details == Series: Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs" URL : https://patchwork.freedesktop.org/series/65267/ State : success == Summary == CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14034 Su

Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

2019-08-15 Thread Chris Wilson
Quoting Daniel Vetter (2019-08-15 19:48:42) > On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson wrote: > > Quoting Daniel Vetter (2019-08-14 18:20:53) > > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > > > Now that dma_fence_signal always takes the spinlock to flush the > > > > cb_

Re: [Intel-gfx] [PATCH 3/8] drm/i915/gt: Convert timeline tracking to spinlock

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:27, Chris Wilson wrote: > > Convert the list manipulation of active to use spinlocks so that we can active_list > perform the updates from underneath a quick interrupt callback. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld _

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Manasi Navare
On Thu, Aug 15, 2019 at 11:39:54AM -0700, Tolakanahalli Pradeep, Madhumitha wrote: > On Thu, 2019-08-15 at 11:24 -0700, Manasi Navare wrote: > > On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha Tolakanahalli > > Pradeep wrote: > > > Removing restriction on Pipe A as TigerLake onwards, all the

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Tolakanahalli Pradeep, Madhumitha
On Thu, 2019-08-15 at 11:24 -0700, Manasi Navare wrote: > On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha Tolakanahalli > Pradeep wrote: > > Removing restriction on Pipe A as TigerLake onwards, all the pipes > > support DSC. > > May be elaborate this commit message a little bit something like

Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

2019-08-15 Thread Daniel Vetter
On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson wrote: > Quoting Daniel Vetter (2019-08-14 18:20:53) > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > > Now that dma_fence_signal always takes the spinlock to flush the > > > cb_list, simply take the spinlock and call dma_fence_sign

Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

2019-08-15 Thread Chris Wilson
Quoting Daniel Vetter (2019-08-14 18:20:53) > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > Now that dma_fence_signal always takes the spinlock to flush the > > cb_list, simply take the spinlock and call dma_fence_signal_locked() to > > avoid code repetition. > > > > Suggested-

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: disable DDIC

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915/tgl: disable DDIC URL : https://patchwork.freedesktop.org/series/65217/ State : success == Summary == CI Bug Log - changes from CI_DRM_6710_full -> Patchwork_14020_full Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Patchwork
== Series Details == Series: Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs" URL : https://patchwork.freedesktop.org/series/65267/ State : warning == Summary == $ dim checkpatch origin/drm-tip d4ceec6bc210 Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

Re: [Intel-gfx] [PATCH 2/8] drm/i915/gt: Track timeline activeness in enter/exit

2019-08-15 Thread Matthew Auld
On Wed, 14 Aug 2019 at 10:44, Chris Wilson wrote: > > Lift moving the timeline to/from the active_list on enter/exit in order > to shorten the active tracking span in comparison to the existing > pin/unpin. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Jerome Glisse
On Thu, Aug 15, 2019 at 03:01:59PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 01:39:22PM -0400, Jerome Glisse wrote: > > On Thu, Aug 15, 2019 at 02:35:57PM -0300, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote: > > > > > > > I'm not really w

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Manasi Navare
On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha Tolakanahalli Pradeep wrote: > Removing restriction on Pipe A as TigerLake onwards, all the pipes support > DSC. May be elaborate this commit message a little bit something like: "On previous platforms, DSC was not supported on Pipe A while st

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Fini hw even if GuC is not running (rev2)

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915/uc: Fini hw even if GuC is not running (rev2) URL : https://patchwork.freedesktop.org/series/65140/ State : success == Summary == CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14033 Summary ---

[Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"

2019-08-15 Thread Chris Wilson
In the recent snd merge of ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff 53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device() ee5f85d9290f ALSA: hda: Add codec on bus address table lately f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs module unload

Re: [Intel-gfx] [PATCH v7 1/9] drm_dp_cec: add connector info support.

2019-08-15 Thread Lyude Paul
Reviewed-by: Lyude Paul On Wed, 2019-08-14 at 12:44 +0200, Dariusz Marcinkiewicz wrote: > Pass the connector info to the CEC adapter. This makes it possible > to associate the CEC adapter with the corresponding drm connector. > > Signed-off-by: Dariusz Marcinkiewicz > Signed-off-by: Hans Verkui

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Enabling DSC on Pipe A for TGL

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915/tgl: Enabling DSC on Pipe A for TGL URL : https://patchwork.freedesktop.org/series/65216/ State : success == Summary == CI Bug Log - changes from CI_DRM_6710_full -> Patchwork_14019_full Summary ---

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Jerome Glisse
On Thu, Aug 15, 2019 at 07:42:07PM +0200, Michal Hocko wrote: > On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > > > __GFP_DIRECT_RECLAIM.. > > > > > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for More WOPCM fixes

2019-08-15 Thread Patchwork
== Series Details == Series: More WOPCM fixes URL : https://patchwork.freedesktop.org/series/65263/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14032 Summary --- **FAILURE** Serious unknown cha

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Michal Hocko
On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > > __GFP_DIRECT_RECLAIM.. > > > > > > This matches the existing test in __need_fs_reclaim() - so if you are >

Re: [Intel-gfx] [PATCH 22/22] drm/i915/mst: Do not hardcoded the crtcs that encoder can connect

2019-08-15 Thread James Ausmus
On Thu, Jul 18, 2019 at 04:10:13PM +0300, Ville Syrjälä wrote: > On Fri, Jul 12, 2019 at 06:09:40PM -0700, Lucas De Marchi wrote: > > From: José Roberto de Souza > > > > Tiger Lake has up to 4 pipes so the mask would need to be 0xf instead of > > 0x7. Do not hardcode the mask so it allows the fak

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Jerome Glisse
On Thu, Aug 15, 2019 at 02:35:57PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote: > > > I'm not really well versed in the details of our userptr, but both > > amdgpu and i915 wait for the gpu to complete from > > invalidate_range_start. Jerome has at

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Jerome Glisse
On Thu, Aug 15, 2019 at 07:21:47PM +0200, Daniel Vetter wrote: > On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe wrote: > > > > On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote: > > > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote: > > > > On Thu, Aug 15, 2019 at 04:4

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

2019-08-15 Thread Daniel Vetter
On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote: > > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > > > > > > > You have to wait for the

[Intel-gfx] [PATCH v2] drm/i915/uc: Fini hw even if GuC is not running

2019-08-15 Thread Fernando Pacheco
We should not be skipping uc_fini_hw on finding GuC is no longer running. There is plenty of hw and internal state that can be cleaned up without having to communicate with GuC. v2: better to check if fw is available (Michal) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943 Signed-of

[Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations

2019-08-15 Thread Michal Wajdeczko
We can do WOPCM partitioning using rough estimates and limits and perform detailed check as separate step. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_wopcm.c | 105 - 1 file changed, 74 insertions(+), 3

[Intel-gfx] [PATCH 3/5] drm/i915/wopcm: Try to use already locked WOPCM layout

2019-08-15 Thread Michal Wajdeczko
If WOPCM layout is already locked in HW we shouldn't continue with our own partitioning as it could be likely different and we will be unable to enforce it and fail. Instead we should try to reuse what is already programmed, maybe there will be a fit. This should enable us to reload driver with sl

[Intel-gfx] [PATCH 4/5] drm/i915/wopcm: Update error messages

2019-08-15 Thread Michal Wajdeczko
All WOPCM error messages are device specific, so use device specific error functions. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_wopcm.c | 44 -- 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Allow usage of all GPIO pins

2019-08-15 Thread Patchwork
== Series Details == Series: drm/i915/gen11: Allow usage of all GPIO pins URL : https://patchwork.freedesktop.org/series/65261/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14031 Summary --- **FAIL

[Intel-gfx] [PATCH 5/5] drm/i915/wopmc: Fix SPDX tag location

2019-08-15 Thread Michal Wajdeczko
Move SPDX tag to first line, and update year to 2019. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_wopcm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c index 3

[Intel-gfx] [PATCH 0/5] More WOPCM fixes

2019-08-15 Thread Michal Wajdeczko
More WOPCM fixes Michal Wajdeczko (4): drm/i915/wopcm: Check WOPCM layout separately from calculations drm/i915/wopcm: Try to use already locked WOPCM layout drm/i915/wopcm: Update error messages drm/i915/wopmc: Fix SPDX tag location Michał Winiarski (1): drm/i915/uc: Move FW size sanit

  1   2   >