On 31/08/2021 15:56, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource_byname() helper instead of
> calling platform_get_resource_byname() and devm_ioremap_resource()
> separately
>
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_io
Allow TTM know if vendor set new ttm mananger out of bounds by adding
build_bug_on.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 8
include/drm/ttm/ttm_device.h| 3 +++
include/drm/ttm/ttm_range_manager.h | 18 --
3 files chan
Am 13.09.21 um 10:09 schrieb xinhui pan:
Allow TTM know if vendor set new ttm mananger out of bounds by adding
build_bug_on.
Signed-off-by: xinhui pan
Yeah, that looks better. Reviewed-by: Christian König
Going to push that to drm-misc-next.
Thanks,
Christian.
---
drivers/gpu/drm/ttm
https://bugzilla.kernel.org/show_bug.cgi?id=214375
Nirmoy (nirmoy.ai...@gmail.com) changed:
What|Removed |Added
CC||nirmoy.ai...@gmail.com
Am 13.09.21 um 10:34 schrieb Paul Menzel:
The warning
amdgpu :05:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not
supported
leaves the reader wondering, if anything can be done about it. As it’s
unsupported in the hardware, and nothing can be done about, mention that
in the log mes
Op 10-09-2021 om 17:02 schreef Peter Zijlstra:
> On Thu, Sep 09, 2021 at 11:32:18AM +0200, Maarten Lankhorst wrote:
>> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
>> index d456579d0952..791c28005eef 100644
>> --- a/kernel/locking/mutex.c
>> +++ b/kernel/locking/mutex.c
>> @@ -736,6
As the user cannot do anything about the unsupported Trusted Memory Zone
(TMZ) feature, do not warn about it, but make it informational, so
demote the log level from warning to info.
Signed-off-by: Paul Menzel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
1 file changed, 1 insertion(+), 1
The warning
amdgpu :05:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported
leaves the reader wondering, if anything can be done about it. As it’s
unsupported in the hardware, and nothing can be done about, mention that
in the log message.
amdgpu :05:00.0: amdgpu: Truste
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 for this purpose.
> Also change above men
Hi Adam,
On Sun, Sep 12, 2021 at 11:00:54PM +0200, Adam Borowski wrote:
> A subfeature of a built-in can't depend on a module.
Maybe I am a bit dense this morning, but I do not really see what error
this fixes. Can you elaborate a bit what situations are fixed by this
patch.
Thanks in advance,
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 split-frame, as
workloads need to be placed on engines in a logically contiguous manner.
v2:
On Mon, 13 Sep 2021, "Shankar, Uma" wrote:
>> -Original Message-
>> From: dri-devel On Behalf Of Jani
>> Nikula
>> Sent: Tuesday, August 31, 2021 7:48 PM
>> To: intel-...@lists.freedesktop.org
>> Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com; Nikula,
>> Jani
>>
>>
On 9/13/21 8:17 AM, Christian König wrote:
Am 11.09.21 um 08:07 schrieb Thomas Hellström:
On Fri, 2021-09-10 at 19:03 +0200, Christian König wrote:
Am 10.09.21 um 17:30 schrieb Thomas Hellström:
On Fri, 2021-09-10 at 16:40 +0200, Christian König wrote:
Am 10.09.21 um 15:15 schrieb Thomas He
Am 13.09.21 um 11:36 schrieb Thomas Hellström:
On 9/13/21 8:17 AM, Christian König wrote:
Am 11.09.21 um 08:07 schrieb Thomas Hellström:
On Fri, 2021-09-10 at 19:03 +0200, Christian König wrote:
Am 10.09.21 um 17:30 schrieb Thomas Hellström:
On Fri, 2021-09-10 at 16:40 +0200, Christian König
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 different patch
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_c
On 9/13/21 11:41 AM, Christian König wrote:
Am 13.09.21 um 11:36 schrieb Thomas Hellström:
On 9/13/21 8:17 AM, Christian König wrote:
Am 11.09.21 um 08:07 schrieb Thomas Hellström:
On Fri, 2021-09-10 at 19:03 +0200, Christian König wrote:
Am 10.09.21 um 17:30 schrieb Thomas Hellström:
On F
W dniu 10.09.2021 o 12:12, Maxime Ripard pisze:
> Without proper care and an agreement between how DSI hosts and devices
> drivers register their MIPI-DSI entities and potential components, we can
> end up in a situation where the drivers can never probe.
>
> Most drivers were taking evasive mane
Hi,
On 8/26/21 1:43 PM, Vivi, Rodrigo wrote:
> On Thu, 2021-08-26 at 10:23 +0200, Maxime Ripard wrote:
>> On Wed, Aug 25, 2021 at 04:03:43PM +, Vivi, Rodrigo wrote:
>>> On Tue, 2021-08-24 at 18:48 +0200, Hans de Goede wrote:
Hi,
On 8/24/21 10:45 AM, Jani Nikula wrote:
> On F
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 the GT PM isn't
held and run that work on next GT PM unpark.
Sounds maybe plausible, b
On 12/09/2021 22:08, Dmitry Osipenko wrote:
> Currently driver supports legacy power domain API, this patch adds generic
> power domain support. This allows us to utilize a modern GENPD API for
> newer device-trees.
>
> Tested-by: Peter Geis # Ouya T30
> Tested-by: Paul Fertser # PAZ00 T20
> Tes
On 12/09/2021 22:08, Dmitry Osipenko wrote:
> Convert NVIDIA Tegra video decoder binding to schema.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Dmitry Osipenko
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> .../bindings/media/nvidia,tegra-vde.txt | 64 ---
> .../bind
On 12/09/2021 22:08, Dmitry Osipenko wrote:
> Document new OPP table and power domain properties of the video decoder
> hardware.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Dmitry Osipenko
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> .../devicetree/bindings/media/nvidia,tegra-vd
On 10/09/2021 21:49, Matthew Brost wrote:
On Fri, Sep 10, 2021 at 12:25:43PM +0100, Tvrtko Ursulin wrote:
On 20/08/2021 23:44, Matthew Brost wrote:
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
betw
> -Original Message-
> From: Nikula, Jani
> Sent: Monday, September 13, 2021 3:00 PM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com
> Subject: RE: [PATCH v2 4/6] drm/edid: parse the DisplayID v2.0 VESA vendor
>
On 9/13/21 12:16 PM, Thomas Hellström wrote:
On 9/13/21 11:41 AM, Christian König wrote:
Am 13.09.21 um 11:36 schrieb Thomas Hellström:
On 9/13/21 8:17 AM, Christian König wrote:
Am 11.09.21 um 08:07 schrieb Thomas Hellström:
On Fri, 2021-09-10 at 19:03 +0200, Christian König wrote:
Am 10
Hi everybody,
we recently found that a good bunch of the RCU accesses to the dma_resv object
are actually not correctly protected.
Those where fixed by either dropping the RCU approach and taking appropriate
locks or using a central function to return the current fences as array and
then work
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 63 +++
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 81 +++---
1 file changed, 32 insertions(+), 49 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/dr
A simpler version of the iterator to be used when the dma_resv object is
locked.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 38 ++
include/linux/dma-resv.h | 18 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 54 +-
1 file changed, 7 insertions(+), 47 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/driv
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 44
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index 862eb3
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 64 +-
1 file changed, 7 insertions(+), 57 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/driv
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
v2: use sizeof(void*) instead
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 110 +
1 file changed, 37 insertions(+), 73 deletions(-)
diff --git a/d
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 30 +++-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_ge
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_sw_fence.c | 52 ++--
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index c589a681da77..
This is probably a fix since we didn't even grabed a reference to the
fences.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0a3127
Simplifying the code a bit. Also drop the RCU read side lock since the
object is locked anyway.
Untested since I can't get the driver to compile on !ARM.
Signed-off-by: Christian König
---
drivers/gpu/drm/msm/msm_gem.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 6987d412a94
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 09c820045859..6e3b8491be68 100644
--- a/drivers
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_excl_unlocked().
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 489e22190e29..0a9270
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 48 +++--
1 file changed, 12 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 05d0b3eb
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_request.c | 36 ++---
1 file changed, 7 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 37aef1308573..b81
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 29
1 file changed, 5 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 1317454
This is maybe even a fix since the RCU usage here looks incorrect.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 49 +---
1 file changed, 9 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 1e97520
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_excl_unlocked().
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_atomic_helper.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
b/drivers/gp
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_sync.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sync.c
b/drivers/gpu/drm/radeon/radeon_sync.c
index 9257b60144c4..14a4d81
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index eec6c9e9cda7..1
We certainly hold the reservation lock here, no need for the RCU dance.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etna
Heureka, that's finally not used any more.
Signed-off-by: Christian König
---
include/linux/dma-resv.h | 26 --
1 file changed, 26 deletions(-)
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index 6f9bb7e4c538..90c15cbe7d92 100644
--- a/include/linux/dm
Instead of hand rolling the logic.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index b8fa6e
Commit a25b988ff83f ("drm/bridge: Extend bridge API to disable connector
creation")
added DRM_BRIDGE_ATTACH_NO_CONNECTOR bridge flag and all bridges handle
this flag in some way since then.
Newly added bridge drivers must no longer contain the connector creation and
will fail probing if this flag
On 2021-09-11 18:39:19, AngeloGioacchino Del Regno wrote:
> In function dpu_encoder_phys_cmd_wait_for_commit_done we are always
> checking if the relative CTL is started by waiting for an interrupt
> to fire: it is fine to do that, but then sometimes we call this
> function while the CTL is up and
Support for these two panels fits in nicely with the existing
panel-boe-tv101wum-nl6 driver as suggested by Sam [1]. The main things
we needed to handle were:
a) These panels need slightly longer delays in two places. Since these
new delays aren't much longer, let's just unconditionally increase
th
On Wed, Sep 8, 2021 at 3:23 AM Daniel Gomez wrote:
>
> On Tue, 7 Sept 2021 at 19:23, Alex Deucher wrote:
> >
> > On Tue, Sep 7, 2021 at 4:53 AM Daniel Gomez wrote:
> > >
> > > Add custom power profile mode support on smu10.
> > > Update workload bit list.
> > > ---
> > >
> > > Hi,
> > >
> > > I'
On Fri, Sep 10, 2021 at 3:54 PM Felix Kuehling wrote:
>
> These bits are de-facto part of the uAPI, so declare them in a uAPI header.
>
Please include a link to the userspace that uses this in the commit message.
Alex
> Signed-off-by: Felix Kuehling
> ---
> MAINTAINERS
https://bugzilla.kernel.org/show_bug.cgi?id=214375
--- Comment #2 from Calvin Walton (calvin.wal...@kepstin.ca) ---
Thank you for the quick patch! I've tested it on top of 5.14.2, and the kms
driver initialization and fb console are now working correctly.
--
You may reply to this email to add a
https://bugzilla.kernel.org/show_bug.cgi?id=211425
Andreas (icedragon...@web.de) changed:
What|Removed |Added
Kernel Version|5.13.13 |5.14.3
Severity
From: Ralph Campbell
There are several places where ZONE_DEVICE struct pages assume a reference
count == 1 means the page is idle and free. Instead of open coding this,
add a helper function to hide this detail.
Signed-off-by: Ralph Campbell
Signed-off-by: Alex Sierra
Reviewed-by: Christoph He
v1:
AMD is building a system architecture for the Frontier supercomputer
with a coherent interconnect between CPUs and GPUs. This hardware
architecture allows the CPUs to coherently access GPU device memory.
We have hardware in our labs and we are working with our partner HPE on
the BIOS, firmware
Device memory that is cache coherent from device and CPU point of view.
This is use on platform that have an advance system bus (like CAPI or
CCIX). Any page of a process can be migrated to such memory. However,
no one should be allow to pin such memory so that it can always be
evicted.
Signed-off
This case is used to migrate pages from device memory, back to system
memory. Device public type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
---
v2:
condition added when migrations from device public pages.
---
include/linux/migrate.h | 1 +
mm/migrate.
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_PUBLIC to create the device
page map region.
Signe
Ref counter from device pages is init to zero during memmap init zone.
The first time a new device page is allocated to migrate data into it,
its ref counter needs to be initialized to one.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 ++-
1 file changed, 2 inserti
Public device type memory on VRAM to RAM migration, has similar access
as System RAM from the CPU. This flag sets the source from the sender.
Which in Public type case, should be set as
MIGRATE_VMA_SELECT_DEVICE_PUBLIC.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration, etc.). Clean up the code so the reference
Test cases such as migrate_fault and migrate_multiple,
were modified to explicit migrate from device to sys memory
without the need of page faults, when using device public
type.
Snapshot test case updated to read memory device type
first and based on that, get the proper returned results
migrate_
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device public type.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c | 15 ++-
lib/test_hmm_uapi.h | 7 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/lib/test_hmm.
In order to configure device public in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
---
v5:
Remove devmem->pag
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as public.
Signed-off-by: Alex Sierra
---
tools/testing/selftests/vm/test_hmm.sh | 20 +
Device Public type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only suppo
On Tue, 31 Aug 2021, Jani Nikula wrote:
> v2 of https://patchwork.freedesktop.org/series/94161/ with the VESA OUI
> check and an OUI helper patch added.
Maarten, Maxime, Thomas - may I have an ack for merging this via
drm-intel? I think at this time we can get the merge to drm-next and
backmerge
There is no devfreq on a3xx at the moment since gpu_busy is not
implemented. This means that msm_devfreq_init() will return early
and the entire devfreq setup is skipped.
However, msm_devfreq_active() and msm_devfreq_idle() are still called
unconditionally later, causing a NULL pointer dereference
Applied. Thanks.
Alex
On Mon, Sep 13, 2021 at 4:46 AM Paul Menzel wrote:
>
> As the user cannot do anything about the unsupported Trusted Memory Zone
> (TMZ) feature, do not warn about it, but make it informational, so
> demote the log level from warning to info.
>
> Signed-off-by: Paul Menzel
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 split-fr
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 request
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 request
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 dif
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 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 t
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 eac
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 to
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
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 -
drivers/gp
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 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 to
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 m
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 de
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 +++-
drivers/gpu/drm/i915/display/intel_hdcp.
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 fully
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 ae48
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
b/drivers/gpu/drm/msm/disp/dpu1/dpu_enco
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.
Signed-off-by:
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
b/
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
---
.../bindings/display/msm/dp-cont
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 +++---
drivers/gpu/d
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 +-
drivers/gpu/drm/msm/dp/dp_di
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.
>
> Origi
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, if
1 - 100 of 178 matches
Mail list logo
