The hardware sets the TMUWCF bit back to 0 when the TMU write
combiner flush completes so we should be checking for that instead
of the L2TFLS bit.
Fixes spurious Vulkan CTS failures in:
dEQP-VK.binding_model.descriptorset_random.*
---
drivers/gpu/drm/v3d/v3d_gem.c | 2 +-
1 file changed, 1
An error capture allocates memory, memory allocations depend on resets,
and resets need to flush the G2H handlers to seal several races. If the
error capture is done from the G2H handler this creates a circular
dependency. To work around this, do a error capture in a work queue
asynchronously from
It isn't safe to scrub for missing G2H or continue with the reset until
all G2H processing is complete. Flush the G2H work queue during reset to
ensure it is done running. No need to call the IRQ handler directly
either as the scrubbing code can deal with any missing G2H.
Signed-off-by: Matthew
Move guc_ids under submission_state sub-structure as a future patch will
use contexts_lock (global GuC submission lock) to protect more data.
Introducing the sub-structure makes ownership of the locking / fields
clear.
v2:
(Docs)
- Fix Docs warning by adding comment to submission_state
From: John Harrison
When i915 receives a context reset notification from GuC, it triggers
an error capture before resetting any outstanding requsts of that
context. Unfortunately, the error capture is not a time bound
operation. In certain situations it can take a long time, particularly
when
Rather allocating an error capture in nowait context to break a lockdep
splat [1], do the error capture async compared to the G2H processing.
v2: Fix Docs warning
Signed-off-by: Matthew Brost
[1] https://patchwork.freedesktop.org/patch/451415/?series=93704=5
John Harrison (1):
drm/i915/guc:
On Mon, Sep 13, 2021 at 03:38:44PM -0700, John Harrison wrote:
> On 9/13/2021 09:54, Matthew Brost wrote:
>
> On Thu, Sep 09, 2021 at 03:51:27PM -0700, John Harrison wrote:
>
> On 8/20/2021 15:44, Matthew Brost wrote:
>
> Calling switch_to_kernel_context isn't needed if
On Tue, 14 Sept 2021 at 14:55, Matthew Brost wrote:
>
> From: Venkata Sandeep Dhanalakota
>
> Defining vma on stack can cause stack overflow, if
> vma gets populated with new fields.
Is there some higher level locking stopping that from getting trashed?
or a guarantee that uc_fw_bind_ggtt is
From: Venkata Sandeep Dhanalakota
Defining vma on stack can cause stack overflow, if
vma gets populated with new fields.
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
The GuC objects are perma-pinned and need to be dumped during an error
capture. Use the macro i915_gem_object_is_lmem rather than
__i915_gem_object_is_lmem to avoid a lockdep splat as the former is the
correct call if the object is perma-pinned.
Signed-off-by: Matthew Brost
Cc: Thomas Hellstrom
From: Daniele Ceraolo Spurio
The firmware binary has to be loaded from lmem and the recommendation is
to put all other objects in there as well. Note that we don't fall back
to system memory if the allocation in lmem fails because all objects are
allocated during driver load and if we have
Enable GuC submission by default on DG1
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 86c318516e14..2fef3b0bbe95
From: Daniele Ceraolo Spurio
Add DG1 GuC / HuC firmware defs
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Minimum set of patches to enable GuC submission on DG1 and enable it by
default.
A little difficult to test as IGTs do not work with DG1 due to a bunch
of uAPI features being disabled (e.g. relocations, caching memory
options, etc...) and CI for DG1 isn't all that useful yet. Tested quite
Move guc_ids under submission_state sub-structure as a future patch will
use contexts_lock (global GuC submission lock) to protect more data.
Introducing the sub-structure makes ownership of the locking / fields
clear.
Signed-off-by: Matthew Brost
---
It isn't safe to scrub for missing G2H or continue with the reset until
all G2H processing is complete. Flush the G2H work queue during reset to
ensure it is done running. No need to call the IRQ handler directly
either as the scrubbing code can deal with any missing G2H.
Signed-off-by: Matthew
Rather allocating an error capture in nowait context to break a lockdep
splat [1], do the error capture async compared to the G2H processing.
Signed-off-by: Matthew Brost
[1] https://patchwork.freedesktop.org/patch/451415/?series=93704=5
John Harrison (1):
drm/i915/guc: Refcount context
From: John Harrison
When i915 receives a context reset notification from GuC, it triggers
an error capture before resetting any outstanding requsts of that
context. Unfortunately, the error capture is not a time bound
operation. In certain situations it can take a long time, particularly
when
An error capture allocates memory, memory allocations depend on resets,
and resets need to flush the G2H handlers to seal several races. If the
error capture is done from the G2H handler this creates a circular
dependency. To work around this, do a error capture in a work queue
asynchronously from
On 13/9/21 6:51 pm, Vlastimil Babka wrote:
On 9/10/21 16:10, Imran Khan wrote:
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot
Changes in v2:
- Addressed review comment.
- Added Acked from Vlastimil.
- Fixed one mistake, due to which stack_trace_snprint was always
getting invoked with 0 as space value.
Changed it to make use of space argument, because users that
are printing stack entries into buffer,
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot for this purpose.
Also change above mentioned users to use this helper.
On 1/14/21 11:40 PM, Palmer Dabbelt wrote:
From: Palmer Dabbelt
cdn_dp_resume is only used under PM_SLEEP, and now that it's static an
unused function warning is triggered undner !PM_SLEEP. This
conditionally enables the function to avoid the warning.
Fixes: 7c49abb4c2f8 ("drm/rockchip:
Quoting Sankeerth Billakanti (2021-08-11 17:08:01)
> The eDP controller on SC7280 is similar to the eDP/DP controllers
> supported by the current driver implementation.
>
> SC7280 supports one EDP and one DP controller which can operate
> concurrently.
>
> The following are some required changes
Hi Maarten,
I love your patch! Perhaps something to improve:
[auto build test WARNING on regulator/for-next]
[also build test WARNING on tegra-drm/drm/tegra/for-next v5.14]
[cannot apply to tip/locking/core linus/master next-20210909]
[If your patch is applied to the wrong git tree, kindly drop
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next linus/master v5.15-rc1
next-20210913]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next
drm/drm-next
[AMD Official Use Only]
Driver can exchange the custom profiling settings with SMU FW using the table
below:
TABLE_CUSTOM_DPM
And the related data structure is CustomDpmSettings_t.
BR
Evan
> -Original Message-
> From: Alex Deucher
> Sent: Monday, September 13, 2021 11:11 PM
> To:
Hi Sean,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.15-rc1 next-20210913]
[If your patch is applied to the wrong git tree
On Mon, Sep 13, 2021 at 11:52 AM Chia-I Wu wrote:
> .
>
> On Mon, Sep 13, 2021 at 10:48 AM Gurchetan Singh
> wrote:
> >
> >
> >
> > On Fri, Sep 10, 2021 at 12:33 PM Chia-I Wu wrote:
> >>
> >> On Wed, Sep 8, 2021 at 6:37 PM Gurchetan Singh
> >> wrote:
> >> >
> >> > We don't want fences from
Quoting Sean Paul (2021-09-13 10:57:44)
> From: Sean Paul
>
> This patch adds the register ranges required for HDCP to the sc7180
> device tree. These registers will be used to inject HDCP key as well as
> toggle HDCP on and off.
It doesn't look to do any of that?
>
> Signed-off-by: Sean Paul
On Mon, Sep 13, 2021 at 04:19:00PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Introduce context parent-child relationship. Once this relationship is
> > created all pinning / unpinning operations are directed to the parent
> > context. The parent context is
Quoting Sean Paul (2021-09-13 10:57:43)
> diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> index 64d8d9e5e47a..984301442653 100644
> ---
On Mon, Sep 13, 2021 at 03:26:29PM -0700, John Harrison wrote:
> On 9/9/2021 17:41, Matthew Brost wrote:
> > On Thu, Sep 09, 2021 at 03:46:43PM -0700, John Harrison wrote:
> > > On 8/20/2021 15:44, Matthew Brost wrote:
> > > > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> >
On Mon, Sep 13, 2021 at 04:06:33PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Expose logical engine instance to user via query engine info IOCTL. This
> > is required for split-frame workloads as these needs to be placed on
> > engines in a logically contiguous
Hi,
On Mon, Sep 13, 2021 at 2:33 PM Philip Chen wrote:
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> index 685e9c38b2db..1b2414601538 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@
If a driver supports this capability, it means that there would be an
additional signalling mechanism for a page flip completion in addition
to out_fence or DRM_MODE_PAGE_FLIP_EVENT.
This capability may only be relevant for Virtual KMS drivers and is currently
used only by virtio-gpu. Also, it
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 63 +++---
1 file changed, 56 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index
Release_fence is very similar if not the same as out_fence; it
is an additional signalling mechanism for a page flip completion.
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/drm_atomic_uapi.c | 43 +--
drivers/gpu/drm/drm_crtc.c| 2 ++
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +++-
drivers/gpu/drm/virtio/virtgpu_vq.c | 7 +--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_fence.c | 9 +
drivers/gpu/drm/virtio/virtgpu_kms.c |
The main idea behind DRM_CAP_RELEASE_FENCE is to add an additional
signaling mechanism for a pageflip completion in addition to out_fence
or DRM_EVENT_FLIP_COMPLETE event. This allows a compositor to start
a new repaint cycle with a new buffer instead of waiting for the
old buffer to be free.
This is needed to leverage the out_fence machinery for similar but
additional singalling mechanisms.
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/drm_atomic_uapi.c | 57 ---
1 file changed, 37 insertions(+), 20 deletions(-)
diff --git
Hi,
On Mon, Sep 13, 2021 at 2:33 PM Philip Chen wrote:
>
> Implement the first version of AUX support, which will be useful as
> we expand the driver to support varied use cases.
>
> WARNING: This patch is not fully verified by hardware. But as AUX CH
> is not implemented for ps8640 driver until
Hi, Markus:
Markus Schneider-Pargmann 於 2021年9月10日 週五 下午1:36寫道：
>
> Hi Chun-Kuang,
>
> On Fri, Sep 10, 2021 at 07:37:50AM +0800, Chun-Kuang Hu wrote:
> > Hi, Markus:
> >
> > Markus Schneider-Pargmann 於 2021年9月7日 週二 上午3:37寫道：
> > >
> > > This patch adds a DisplayPort driver for the Mediatek
On 8/20/2021 15:44, Matthew Brost wrote:
Introduce context parent-child relationship. Once this relationship is
created all pinning / unpinning operations are directed to the parent
context. The parent context is responsible for pinning all of its'
children and itself.
This is a precursor to
On 8/20/2021 15:44, Matthew Brost wrote:
Expose logical engine instance to user via query engine info IOCTL. This
is required for split-frame workloads as these needs to be placed on
engines in a logically contiguous order. The logical mapping can change
based on fusing. Rather than having user
On 9/13/2021 09:54, Matthew Brost wrote:
On Thu, Sep 09, 2021 at 03:51:27PM -0700, John Harrison wrote:
On 8/20/2021 15:44, Matthew Brost wrote:
Calling switch_to_kernel_context isn't needed if the engine PM reference
is taken while all contexts are pinned. By not calling
On 9/9/2021 17:41, Matthew Brost wrote:
On Thu, Sep 09, 2021 at 03:46:43PM -0700, John Harrison wrote:
On 8/20/2021 15:44, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a scheduling of user context could be enabled.
As with earlier PM
On Thu, Sep 9, 2021 at 2:27 PM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2021-09-09 14:14:29)
> > On Thu, Sep 9, 2021 at 12:09 PM Stephen Boyd wrote:
> > >
> > >
> > > Oh does this have register pages? regmap has support for pages where you
> > > write some indirection register and then
On Thu, Sep 9, 2021 at 12:07 PM Stephen Boyd wrote:
>
> Quoting Philip Chen (2021-09-09 11:15:27)
> > On Wed, Sep 8, 2021 at 3:27 PM Stephen Boyd wrote:
> > >
> > > Quoting Philip Chen (2021-09-08 11:18:06)
> > >
> > > > +
> > > > + data = (len - 1) & AUX_LENGTH_MASK;
> > > > +
Implement the first version of AUX support, which will be useful as
we expand the driver to support varied use cases.
WARNING: This patch is not fully verified by hardware. But as AUX CH
is not implemented for ps8640 driver until now, the patch shouldn't
cause any functional regression in
Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs,
which will simplify the future update on ps8640 driver.
Signed-off-by: Philip Chen
---
Changes in v2:
- Add separate reg map config per page
drivers/gpu/drm/bridge/parade-ps8640.c | 89 ++
1 file
On Mon, 13 Sep 2021 13:57:43 -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
>
On Mon, Sep 13, 2021 at 02:10:16PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> When i915 receives a context reset notification from GuC, it triggers
> an error capture before resetting any outstanding requsts of that
> context. Unfortunately, the error capture is not a time
From: John Harrison
When i915 receives a context reset notification from GuC, it triggers
an error capture before resetting any outstanding requsts of that
context. Unfortunately, the error capture is not a time bound
operation. In certain situations it can take a long time, particularly
when
On 2021-09-13 3:26 p.m., Sean Paul wrote:
> On Mon, Sep 13, 2021 at 2:05 PM Alex Deucher wrote:
>>
>> On Mon, Sep 13, 2021 at 1:57 PM Sean Paul wrote:
>>>
>>> From: Sean Paul
>>>
>>> Hello,
>>> This patchset pulls the HDCP protocol auth/exchange/check logic out from
>>> i915 into a HDCP
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completes successfully.
v2:
(Tvrtko)
- Skip test if preemption timeout compiled out
- Skip test if engine
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #298525|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #9 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 298785
--> https://bugzilla.kernel.org/attachment.cgi?id=298785=edit
kernel dmesg (kernel 5.15-rc1, AMD FX-8370)
--
You may reply to this email to add a comment.
You
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 298783
--> https://bugzilla.kernel.org/attachment.cgi?id=298783=edit
output of kmemleak (kernel 5.15-rc1, AMD FX-8370)
Seems unchanged in kernel 5.15-rc1.
# cat
Hi Maxime,
thanks for the ping on irc. I had accidently deleted v2 of this patch.
Sam
On Mon, Aug 30, 2021 at 11:49:09AM +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() function is iterating over all the
> connectors when an hotplug event is detected.
>
> During that
> -Original Message-
> From: Dexuan Cui
> Sent: Monday, September 13, 2021 2:27 PM
> To: drawat.fl...@gmail.com; Haiyang Zhang ;
> airl...@linux.ie; dan...@ffwll.ch; tzimmerm...@suse.de; dri-
> de...@lists.freedesktop.org
> Cc: linux-hyp...@vger.kernel.org;
Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
control brightness, apparently needs a delay before setting brightness
after power on. Without this delay the panel does accept the setting
and may come up with some arbitrary brightness (sometimes it's too dark,
sometimes
On Mon, Sep 13, 2021 at 2:05 PM Alex Deucher wrote:
>
> On Mon, Sep 13, 2021 at 1:57 PM Sean Paul wrote:
> >
> > From: Sean Paul
> >
> > Hello,
> > This patchset pulls the HDCP protocol auth/exchange/check logic out from
> > i915 into a HDCP helper library which drivers can use to implement the
On Mon, Sep 13, 2021 at 01:40:34PM -0400, Eric Farman wrote:
> On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > This addresses Cornelia's remark on the earlier patch that ccw has a
> > confusing lifecycle. While it doesn't seem like the original attempt
> > was
> > functionally wrong,
Hi,
On Mon, Sep 13, 2021 at 3:59 AM yangcong
wrote:
>
> This is an incell IC, TDDI use time division multiplexing.
> Init code effect touch sensing.
> Support touch function we needed to handle were:
> a) Update init code for the panel driver, adjust the porch value.
> b) After update init code
.
On Mon, Sep 13, 2021 at 10:48 AM Gurchetan Singh
wrote:
>
>
>
> On Fri, Sep 10, 2021 at 12:33 PM Chia-I Wu wrote:
>>
>> On Wed, Sep 8, 2021 at 6:37 PM Gurchetan Singh
>> wrote:
>> >
>> > We don't want fences from different 3D contexts (virgl, gfxstream,
>> > venus) to be on the same
It looks like Hyper-V supports a hardware cursor feature. It is not used
by Linux VM, but the Hyper-V host still draws a point as an extra mouse
pointer, which is unwanted, especially when Xorg is running.
The hyperv_fb driver uses synthvid_send_ptr() to hide the unwanted pointer.
When the
Enable shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index
We currently just evict lmem objects to system memory when under memory
pressure. For this case we lack the usual object mm.pages, which
effectively hides the pages from the i915-gem shrinker, until we
actually "attach" the TT to the object, or in the case of lmem-only
objects it just gets
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8
Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable
update the shrinker visible lists immediately. This at least simplifies
the next patch, and does make the behaviour more obvious. The potential
downside is that make_unshrinkable now grabs a global lock even when the
object itself
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
Fixes some object-debug splat which appeared while debugging something
unrelated.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
From: Thomas Hellström
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now
Add new flag to indicate special shmem based tt, which can directly
handle swapping itself, and should be visible to some shrinker.
As part of this we should skip the ttm_pages_allocated accounting, since
such tt objects should already be reachable, and potentially reclaimable
by some shrinker,
On Mon, Sep 13, 2021 at 1:57 PM Sean Paul wrote:
>
> From: Sean Paul
>
> Hello,
> This patchset pulls the HDCP protocol auth/exchange/check logic out from
> i915 into a HDCP helper library which drivers can use to implement the
> proper protocol and UAPI interactions for achieving HDCP.
>
>
From: Sean Paul
This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
helpers.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/Makefile| 1 +
drivers/gpu/drm/msm/dp/dp_debug.c | 49 +++-
drivers/gpu/drm/msm/dp/dp_debug.h | 6 +-
From: Sean Paul
This patch adds the register ranges required for HDCP to the sc7180
device tree. These registers will be used to inject HDCP key as well as
toggle HDCP on and off.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/dp/dp_parser.c | 30 +++---
From: Sean Paul
This patch adds the bindings for the MSM DisplayPort HDCP registers
which are required to write the HDCP key into the display controller as
well as the registers to enable HDCP authentication/key
exchange/encryption.
Signed-off-by: Sean Paul
---
From: Sean Paul
Audio is initialized last, it should be de-initialized first to match
the order in dp_init_sub_modules().
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
From: Sean Paul
encoder->commit() was being misused because there were some global
resources which needed to be tweaked in encoder->enable() which were not
accessible in dpu_encoder.c. That is no longer true and the redirect
serves no purpose any longer. So remove the indirection.
From: Sean Paul
A couple more useless checks to remove in dpu_encoder.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
From: Sean Paul
Make includes alphabetical in dpu_kms.c
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index
From: Sean Paul
Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.
The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Signed-off-by: Sean Paul
---
.../drm/i915/display/intel_display_debugfs.c | 9 +++-
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 52 +++
1 file changed, 35 insertions(+), 17
From: Sean Paul
This patch expands upon the HDCP helper library to manage HDCP
enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could
From: Sean Paul
This patch updates the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, simply return
true if the content protection value is changing and let the driver
decide whether a modeset is required or not.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_hdcp.c | 33
From: Sean Paul
This patch moves the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_hdcp.c | 71 -
From: Sean Paul
Hello,
This patchset pulls the HDCP protocol auth/exchange/check logic out from
i915 into a HDCP helper library which drivers can use to implement the
proper protocol and UAPI interactions for achieving HDCP.
Originally this was all stuffed into i915 since it was the only driver
On Tue, Aug 24, 2021 at 03:54:24PM -0700, Nathan Chancellor wrote:
> Commit 46e2068081e9 ("drm/i915: Disable some extra clang warnings")
> disabled -Wsometimes-uninitialized as noisy but there have been a few
> fixes to clang that make the false positive rate fairly low so it should
> be enabled
On Fri, Sep 10, 2021 at 12:33 PM Chia-I Wu wrote:
> On Wed, Sep 8, 2021 at 6:37 PM Gurchetan Singh
> wrote:
> >
> > We don't want fences from different 3D contexts (virgl, gfxstream,
> > venus) to be on the same timeline. With explicit context creation,
> > we can specify the number of ring
On Mon, Sep 13, 2021 at 11:33:46AM +0100, Tvrtko Ursulin wrote:
>
> On 10/09/2021 21:09, Matthew Brost wrote:
> > On Fri, Sep 10, 2021 at 09:36:17AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 20/08/2021 23:44, Matthew Brost wrote:
> > > > Sometimes it is desirable to queue work up for later if
Recent rework, which made HDMI PHY driver a platform device, inadvertely
reversed clock setup order. HW is very touchy about it. Proper way is to
handle controllers resets and clocks first and HDMI PHYs second.
Currently, without this fix, first mode set completely fails (nothing on
HDMI monitor)
On Mon, Sep 13, 2021 at 10:55:59AM +0100, Tvrtko Ursulin wrote:
>
> On 20/08/2021 23:44, Matthew Brost wrote:
> > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > circuiting while a deregister context H2G is in flight.
> >
> > FIXME: Move locking / structure changes into
On Thu, Sep 09, 2021 at 03:51:27PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Calling switch_to_kernel_context isn't needed if the engine PM reference
> > is taken while all contexts are pinned. By not calling
> > switch_to_kernel_context we save on issuing a
On Thu, Sep 09, 2021 at 03:51:27PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Calling switch_to_kernel_context isn't needed if the engine PM reference
> > is taken while all contexts are pinned. By not calling
> > switch_to_kernel_context we save on issuing a
On Mon, Sep 13, 2021 at 10:24:43AM +0100, Tvrtko Ursulin wrote:
>
> On 10/09/2021 20:49, Matthew Brost wrote:
> > On Fri, Sep 10, 2021 at 12:12:42PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 20/08/2021 23:44, Matthew Brost wrote:
> > > > Add logical engine mapping. This is required for
1 - 100 of 187 matches
Mail list logo
