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:
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:
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 ++
>
== 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
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
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 +
>
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:
>
== 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
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:
[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
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
== 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**
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
== 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
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 +++
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 +++
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
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
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 |
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 +
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
== 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
---
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
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
== 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
---
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
== 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
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 |
== 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
---
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
== 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
== 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
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
== 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
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
> >
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
>
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
> >
== 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
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
== 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
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
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
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
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
== 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
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
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 -
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
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|
== 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
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
> >
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
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.
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 --
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
> ---
>
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
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
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
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
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
> -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
== 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
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
== 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
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
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
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
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
== 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
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
> > > >
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
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
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
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
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.
> >
> >
== 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**
== 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"
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
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
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
== 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
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
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
== 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
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..
> > > >
> >
== 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
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
>
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
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
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
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
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
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(+),
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
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
== 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
---
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
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
From: Michał Winiarski
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.
v2: rebased
v3: use __intel_uc_fw_get_upload_size (Daniele)
Signed-off-by:
On Thu, Aug 15, 2019 at 01:56:31PM -0300, 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() -
1 - 100 of 166 matches
Mail list logo
