Hi
Am 09.04.21 um 11:22 schrieb Daniel Vetter:
Is it that easy? simepldrm's detach function has code to synchronize with
concurrent hotplug removals. If we can use drm_dev_unplug() for everything,
I'm all for it.
Uh, I should have looked at the code instead of just asking silly
questions :-)
Hi all,
Today's linux-next merge of the vfio tree got a conflict in:
drivers/gpu/drm/i915/gvt/gvt.c
between commit:
9ff06c385300 ("drm/i915/gvt: Remove references to struct drm_device.pdev")
from the drm tree and commit:
383987fd15ba ("vfio/gvt: Use mdev_get_type_group_id()")
from the
Am 17.03.21 um 16:43 schrieb Maxime Ripard:
The HDMI controllers in the BCM2711 support YUV444 and YUV420 outputs,
let's add support for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 73 +++--
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 6 +++
On 15/04/2021 04:47, Laurent Pinchart wrote:
Being informed of a failure to attach a bridge is useful, and many
drivers prints an error message in that case. Move the message to
drm_bridge_attach() to avoid code duplication.
Suggested-by: Stephen Boyd
Signed-off-by: Laurent Pinchart
---
driv
On Wed, Apr 14, 2021 at 5:16 PM Dmitry Baryshkov
wrote:
>
> On 15/04/2021 02:11, Abhinav Kumar wrote:
> > Add the msm_disp_snapshot module which adds supports to dump dpu
> > registers and capture the drm atomic state which can be used in
> > case of error conditions.
> >
> > changes in v4:
> >
This shortcut is no longer needed with access managed properly by KFD.
Signed-off-by: Felix Kuehling
Reviewed-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdg
DRM render node file handles are used for CPU mapping of BOs using mmap
by the Thunk. It uses the DRM render node of the GPU where the BO was
allocated.
DRM allows mmap access automatically when it creates a GEM handle for a
BO. KFD BOs don't have GEM handles, so KFD needs to manage access
manuall
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
to access the BO through the corresponding file descriptor. The VM can
also be extracted from drm_priv, so drm_priv can replace the vm parameter
in the kfd2kgd interface.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/am
Hi Doug,
On Wed, Apr 14, 2021 at 06:19:13PM -0700, Doug Anderson wrote:
> On Sun, Apr 4, 2021 at 5:50 PM Laurent Pinchart wrote:
> > On Fri, Apr 02, 2021 at 03:28:35PM -0700, Douglas Anderson wrote:
> > > The drm_bridge_chain_pre_enable() is not the proper opposite of
> > > drm_bridge_chain_post_d
Being informed of a failure to attach a bridge is useful, and many
drivers prints an error message in that case. Move the message to
drm_bridge_attach() to avoid code duplication.
Suggested-by: Stephen Boyd
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |
Hi Doug,
On Wed, Apr 14, 2021 at 06:22:57PM -0700, Doug Anderson wrote:
> On Wed, Apr 14, 2021 at 5:58 PM Laurent Pinchart wrote:
> > On Fri, Apr 02, 2021 at 03:28:46PM -0700, Douglas Anderson wrote:
> > > Unpreparing and re-preparing a panel can be a really heavy
> > > operation. Panels datasheet
From: Philip Yang
SVMAPISupported property added to HSA_CAPABILITY, the value match
HSA_CAPABILITY defined in Thunk spec:
SVMAPISupported: it will not be supported on older kernels that don't
have HMM or on systems with GFXv8 or older GPUs without support for
48-bit virtual addresses.
CoherentH
With xnack on, GPU vm fault handler decide the best restore location,
then migrate range to the best restore location and update GPU mapping
to recover the GPU vm fault.
Signed-off-by: Philip Yang
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers
If prefetch range to gpu with acutal location is another gpu, or GPU
retry fault restore pages to migrate the range with acutal location is
gpu, then migrate from one gpu to another gpu.
Use system memory as bridge because sdma engine may not able to access
another gpu vram, use sdma of source gpu
Control whether to build SVM support into amdgpu with a Kconfig option.
This makes it easier to disable it in production kernels if this new
feature causes problems in production environments.
Use "depends on" instead of "select" for DEVICE_PRIVATE, as is
recommended for visible options.
Reviewed
From: Alex Sierra
Add to amdgpu_amdkfd_fence.enable_signal callback, support
for svm_bo fence eviction.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 11 ---
1 file changed, 8 insertions(+),
With xnack on, add validate timestamp in order to handle GPU vm fault
from multiple GPUs.
If GPU retry fault need migrate the range to the best restore location,
use range validate timestamp to record system timestamp after range is
restored to update GPU page table.
Because multiple pages of sam
From: Alex Sierra
[why]
As part of the SVM functionality, the eviction mechanism used for
SVM_BOs is different. This mechanism uses one eviction fence per prange,
instead of one fence per kfd_process.
[how]
A svm_bo reference to amdgpu_amdkfd_fence to allow differentiate between
SVM_BO or regula
From: Alex Sierra
Add CREATE_SVM_BO define bit for SVM BOs.
Another define flag was moved to concentrate these
KFD type flags in one include file.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 ++-
From: Alex Sierra
By default this timestamp is 32 bit counter. It gets
overflowed in around 10 minutes.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu
svm_bo eviction mechanism is different from regular BOs.
Every SVM_BO created contains one eviction fence and one
worker item for eviction process.
SVM_BOs can be attached to one or more pranges.
For SVM_BO eviction mechanism, TTM will start to call
enable_signal callback for every SVM_BO until VRA
If CPU page fault happens, HMM pgmap_ops callback migrate_to_ram start
migrate memory from vram to ram in steps:
1. migrate_vma_pages get vram pages, and notify HMM to invalidate the
pages, HMM interval notifier callback evict process queues
2. Allocate system memory pages
3. Use svm copy memory t
From: Alex Sierra
[why]
To support svm bo eviction mechanism.
[how]
If the BO crated has AMDGPU_AMDKFD_CREATE_SVM_BO flag set,
enable_signal callback will be called inside amdgpu_evict_flags.
This also causes gutting of the BO by removing all placements,
so that TTM won't actually do an eviction
GPU page tables are invalidated by unmapping prange directly at
the mmu notifier, when page fault retry is enabled through
amdgpu_noretry global parameter. The restore page table is
performed at the page fault handler.
If xnack is on, we update GPU mappings after migration to avoid
unnecessary GPU
From: Philip Yang
Add svm (shared virtual memory) ioctl data structure and API definition.
The svm ioctl API is designed to be extensible in the future. All
operations are provided by a single IOCTL to preserve ioctl number
space. The arguments structure ends with a variable size array of
attrib
Use amdgpu_vm_bo_update_mapping to update GPU page table to map or unmap
svm range system memory pages address to GPUs.
Signed-off-by: Philip Yang
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 473 ++
This is needed to allow per-process XNACK mode selection in the SQ when
booting with XNACK off by default.
Signed-off-by: Felix Kuehling
Reviewed-by: Philip Yang
Tested-by: Alex Sierra
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 8 ++--
Page table restore implementation in SVM API. This is called from
the fault handler at amdgpu_vm. To update page tables through
the page fault retry IH.
Signed-off-by: Alex Sierra
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdk
From: Alex Sierra
Use SVM API to restore page tables when retry fault and
compute context are enabled.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 +++-
1 file changed, 15 insertions(+),
From: Philip Yang
amdgpu_gmc_get_vm_pte use bo_va->is_xgmi same hive information to set
pte flags to update GPU mapping. Add local structure variable bo_va, and
update bo_va.is_xgmi, pass it to mapping->bo_va while mapping to GPU.
Assuming xgmi pstate is hi after boot.
Signed-off-by: Philip Yan
From: Philip Yang
Use sdma linear copy to migrate data between ram and vram. The sdma
linear copy command uses kernel buffer function queue to access system
memory through gart table.
Use reserved gart table window 0 to map system page address, and vram
page address is direct mapping. Use the sa
If svm range perfetch location is not zero, use TTM to alloc
amdgpu_bo vram nodes to validate svm range, then map vram nodes to GPUs.
Use offset to sub allocate from the same amdgpu_bo to handle overlap
vram range while adding new range or unmapping range.
svm_bo has ref count to trace the shared
From: Philip Yang
It will be used by kfd to map svm range to GPU, because svm range does
not have amdgpu_bo and bo_va, cannot use amdgpu_bo_update interface, use
amdgpu vm update interface directly.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
driv
Register svm range with same address and size but perferred_location
is changed from CPU to GPU or from GPU to CPU, trigger migration the svm
range from ram to vram or from vram to ram.
If svm range prefetch location is GPU with flags
KFD_IOCTL_SVM_FLAG_HOST_ACCESS, validate the svm range on ram f
From: Alex Sierra
XNACK mode controls the SQ RETRY_DISABLE setting that determines,
whether recoverable page faults can be supported on GFXv9 hardware.
Only on Aldebaran we can support different processes running with
different XNACK modes. On older chips all processes must use the same
RETRY_DIS
From: Philip Yang
Register vram memory as MEMORY_DEVICE_PRIVATE type resource, to
allocate vram backing pages for page migration.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +
drivers/gpu/drm/amd/amd
HMM interval notifier callback notify CPU page table will be updated,
stop process queues if the updated address belongs to svm range
registered in process svms objects tree. Scheduled restore work to
update GPU page table using new pages address in the updated svm range.
The restore worker flushe
From: Alex Sierra
Xnack retries are used for page fault recovery. Some AMD chip
families support continuously retry while page table entries are invalid.
The driver must handle the page fault interrupt and fill in a valid entry
for the GPU to continue.
This ioctl allows to enable/disable XNACK r
From: Philip Yang
For larger range allocation, if hmm_range_fault return -EBUSY, set retry
timeout based on 1 second for every 512MB, this is safe timeout value.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c |
From: Philip Yang
When application explicitly call unmap or unmap from mmput when
application exit, driver will receive MMU_NOTIFY_UNMAP event to remove
svm range from process svms object tree and list first, unmap from GPUs
(in the following patch).
Split the svm ranges to handle partial unmapp
From: Philip Yang
Get the intersection of attributes over all memory in the given
range
Signed-off-by: Philip Yang
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 164 +++
1 file changed,
From: Philip Yang
Move the HMM get pages function from amdgpu_ttm and to amdgpu_mn. This
common function will be used by new svm APIs.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 83 +++
From: Philip Yang
svm range structure stores the range start address, size, attributes,
flags, prefetch location and gpu bitmap which indicates which GPU this
range maps to. Same virtual address is shared by CPU and GPUs.
Process has svm range list which uses both interval tree and list to
store
From: Philip Yang
Use HMM to get system memory pages address, which will be used to
map to GPUs or migrate to vram.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 116 ++-
drivers/gpu/drm
From: Alex Sierra
svm range uses gpu bitmap to store which GPU svm range maps to.
Application pass driver gpu id to specify GPU, the helper is needed to
convert gpu id to gpu bitmap idx.
Access through kfd_process_device pointers array from kfd_process.
Signed-off-by: Alex Sierra
Reviewed-by:
Updates since v4:
- Rebased on upstream.
- Added SPDX license headers and updated copyright on added files
- Disabled XNACK on GFXv10 and later GPUs that don't support shader
preemption on fault
- Updated PTE flags for Aldebaran
This series and the corresponding ROCm Thunk and KFDTest changes ar
Hi,
On Wed, Apr 14, 2021 at 5:58 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> Thank you for the patch.
>
> On Fri, Apr 02, 2021 at 03:28:46PM -0700, Douglas Anderson wrote:
> > Unpreparing and re-preparing a panel can be a really heavy
> > operation. Panels datasheets often specify something on th
Hi,
On Sun, Apr 4, 2021 at 5:50 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> Thank you for the patch.
>
> On Fri, Apr 02, 2021 at 03:28:35PM -0700, Douglas Anderson wrote:
> > The drm_bridge_chain_pre_enable() is not the proper opposite of
> > drm_bridge_chain_post_disable(). It continues along th
Hi,
On Tue, Apr 6, 2021 at 9:52 AM Andrzej Hajda wrote:
>
> Hello again after easter,
Sorry, I was out last week and I'm just getting back to this now.
> I have looked little bit more at sn65* driver and its application to
> have better background.
>
> I miss only info what panel do you have,
Hi Dmitry
Thanks for the review.
On 2021-04-14 17:16, Dmitry Baryshkov wrote:
On 15/04/2021 02:11, Abhinav Kumar wrote:
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v4:
-
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:46PM -0700, Douglas Anderson wrote:
> Unpreparing and re-preparing a panel can be a really heavy
> operation. Panels datasheets often specify something on the order of
> 500ms as the delay you should insert after turning off the pane
Hi Andrzej,
On Tue, Apr 06, 2021 at 06:52:07PM +0200, Andrzej Hajda wrote:
> Hello again after easter,
>
> I have looked little bit more at sn65* driver and its application to
> have better background.
>
> I miss only info what panel do you have, how it is enabled/power controlled.
>
> W dniu
On 15/04/2021 02:11, Abhinav Kumar wrote:
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v4:
- rename dpu_dbg to msm_disp_snapshot and move it to msm/disp
- start using a li
On Mon, Apr 12, 2021 at 10:36 PM Vivek Kasireddy
wrote:
> If support for Blob resources is available, then dumb BOs created
> by the driver can be considered as guest Blobs.
>
> v2: Don't skip transfer and flush commands as part of plane update
> as the device may have created a shared mapping. (
Add snapshot points across dpu driver to trigger dumps when critical
errors are hit.
changes in v4:
- change the callers to use the new snapshot macro
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +++---
drivers/gpu/drm/msm/disp/dpu1/dp
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v4:
- rename dpu_dbg to msm_disp_snapshot and move it to msm/disp
- start using a list of blocks to store the hardware block infor
Currently drm_atomic_print_state() internally allocates and uses a
drm_info printer. Allow it to accept any drm_printer type so that
the API can be leveraged even for taking drm snapshot.
Rename the drm_atomic_print_state() to drm_atomic_print_new_state()
so that it reflects its functionality bett
This series adds support to use devcoredump for DPU driver. It introduces
the msm_disp_snapshot module which assists in the capturing of register dumps
during
error scenarios. When a display related error happens, the msm_disp_snapshot
module
captures all the relevant register dumps along with th
Quoting Kuogee Hsieh (2021-04-14 14:02:50)
> Initialize audio_comp when audio starts and wait for audio_comp at
> dp_display_disable(). This will take care of both dongle unplugged
> and display off (suspend) cases.
>
> Changes in v2:
> -- add dp_display_start_audio()
>
> Signed-off-by: Kuogee Hs
Quoting Kuogee Hsieh (2021-04-14 14:02:34)
> Link status is different from display connected status in the case
> of something like an Apple dongle where the type-c plug can be
> connected, and therefore the link is connected, but no sink is
> connected until an HDMI cable is plugged into the dongl
Quoting Kuogee Hsieh (2021-04-13 16:11:44)
> Make sure main link is in connection state before start aux
> read/write operation to avoid unnecessary long delay due to
> main link had been unplugged.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
> drivers/gp
Initialize audio_comp when audio starts and wait for audio_comp at
dp_display_disable(). This will take care of both dongle unplugged
and display off (suspend) cases.
Changes in v2:
-- add dp_display_start_audio()
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_audio.c | 1 +
drive
Link status is different from display connected status in the case
of something like an Apple dongle where the type-c plug can be
connected, and therefore the link is connected, but no sink is
connected until an HDMI cable is plugged into the dongle.
The sink_count of DPCD of dongle will increase t
If the panel connected to the bridge supports backlight control
using DPCD registers on the DisplayPort aux channel, setting
"use-aux-backlight" property in the bridge node will enable the
registration of a DP aux backlight device from the bridge driver.
Signed-off-by: Rajeev Nandan
---
.../devi
The backlight level of an eDP panel can be controlled through the AUX
channel using DPCD registers of the panel.
The capability for the Source device to adjust backlight characteristics
within the panel, using the Sink device DPCD registers is indicated by
the TCON_BACKLIGHT_ADJUSTMENT_CAPABLE bit
Add support to control the backlight of the eDP panel connected to
the ti-sn65dsi86 bridge through aux channel.
Signed-off-by: Rajeev Nandan
---
drivers/gpu/drm/bridge/Kconfig| 1 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 26 ++
2 files changed, 27 insertions(+)
Add panel backlight control using DPCD registers on the DisplayPort aux
channel.
Signed-off-by: Rajeev Nandan
---
drivers/gpu/drm/Kconfig| 8 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_dp_aux_backlight.c | 191 +
inclu
+mesa-dev and some Intel mesa people.
On Wed, Apr 14, 2021 at 5:23 AM Daniel Vetter wrote:
>
> On Tue, Apr 13, 2021 at 12:47:06PM +0100, Matthew Auld wrote:
> > Add an entry for the new uAPI needed for DG1.
> >
> > v2(Daniel):
> > - include the overall upstreaming plan
> > - add a note for mm
On Wed, 2021-04-14 at 18:49 +0200, Thierry Reding wrote:
> On Fri, Feb 19, 2021 at 04:52:59PM -0500, Lyude Paul wrote:
> > As pointed out by the documentation for drm_dp_aux_register(),
> > drm_dp_aux_init() should be used in situations where the AUX channel for a
> > display driver can potentially
On Tue, 6 Apr 2021 16:40:23 -0300
Jason Gunthorpe wrote:
> vfio_mdev has a number of different objects: mdev_parent, mdev_type and
> mdev_device.
>
> Unfortunately the types of these have been erased in various places
> throughout the API, and this makes it very hard to understand this code or
Fixes the following W=1 kernel build warning(s):
drivers/staging/fbtft/fb_ili9320.c: In function ‘read_devicecode’:
drivers/staging/fbtft/fb_ili9320.c:25:6: warning: variable ‘ret’ set but not
used [-Wunused-but-set-variable]
Cc: Greg Kroah-Hartman
Cc: dri-devel@lists.freedesktop.org
Cc: linu
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (57):
staging: r8192U_core: Remove two unused variables 'ret' and
'reset_status'
staging: android: ashmem: Supply description for
On 2021-04-13 20:17, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-04-13 16:11:30)
At dongle unplug, dp initializes audio_comp followed by sending
disconnect
event notification to audio and to make sure audio had shutdown
completely
by wait for audio completion notification at display_disable(
Hi Neil,
Le mer. 14 avril 2021 à 8:17, Neil Armstrong
a écrit :
Hi,
Le 13/04/2021 à 22:56, Paul Cercueil a écrit :
Hi Neil,
I get build failures locally:
drivers/gpu/drm/bridge/ite-it66121.c: In function
‘it66121_hw_reset’:
drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit
On Fri, Feb 19, 2021 at 04:52:59PM -0500, Lyude Paul wrote:
> As pointed out by the documentation for drm_dp_aux_register(),
> drm_dp_aux_init() should be used in situations where the AUX channel for a
> display driver can potentially be registered before it's respective DRM
> driver. This is the c
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
>
>
> On 12/04/2021 10:05, Matthew Auld wrote:
> > From: Venkata Sandeep Dhanalakota
> >
> > Determine the possible coherent map type based on object location,
> > and if target has llc or if user requires an always coherent
> > mapping.
> >
> >
Am 2021-04-14 um 11:21 a.m. schrieb philip yang:
>
>
> On 2021-04-07 7:12 p.m., Felix Kuehling wrote:
>> amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
>> to access the BO through the corresponding file descriptor.
>>
>> Signed-off-by: Felix Kuehling
>> ---
>> drivers/gp
Am 2021-04-14 um 11:37 a.m. schrieb philip yang:
>
>
> On 2021-04-07 7:12 p.m., Felix Kuehling wrote:
>> DRM allows access automatically when it creates a GEM handle for a BO.
>> KFD BOs don't have GEM handles, so KFD needs to manage access manually.
>
> After reading drm vma manager, I understand
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
This shortcut is no longer needed with access managed progerly by KFD.
Reviewed-by: Philip Yang
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
1 fi
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
DRM allows access automatically when it creates a GEM handle for a BO.
KFD BOs don't have GEM handles, so KFD needs to manage access manually.
After reading drm vma manager, I understand it uses rbtree
On 12/04/2021 10:05, Matthew Auld wrote:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
drivers/gpu/drm/i915/gt/intel_gtt.c | 27 +--
driv
On 14/04/2021 10:16, Laurent Pinchart wrote:
> Hi Neil,
>
> On Wed, Apr 14, 2021 at 10:08:46AM +0200, Neil Armstrong wrote:
>> On 14/04/2021 10:06, Robert Foss wrote:
>>> On Wed, 14 Apr 2021 at 08:13, Neil Armstrong
>>> wrote:
Le 13/04/2021 à 22:21, Robert Foss a écrit :
> Hey Neil & Ph
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #15 from Alexander von Gluck (kallis...@unixzen.com) ---
Applied my patch above to ArchLinux (5.11.13-arch1-1) and gave it a whirl. Got
a little information from nouveou before the system hard locks up.
nouveau :0d:00.0: enabling
On 12/04/2021 10:05, Matthew Auld wrote:
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant for much older hw, therefore we can drop the
has_aperture check since it should always be
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.
Cc: Matthew Auld
Cc: CQ Tang
Suggested-by: Michal Wajdeczko
Signed-off-by: Ve
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
to access the BO through the corresponding file descriptor.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
On 12/04/2021 10:05, Matthew Auld wrote:
From: Mohammed Khajapasha
Return EREMOTE value when frame buffer object is not backed by LMEM
for discrete. If Local memory is supported by hardware the framebuffer
backing gem objects should be from local memory.
Signed-off-by: Mohammed Khajapasha
-
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
ROCm user mode has acquired VMs from DRM file descriptors for as long
as it supported the upstream KFD. Legacy code to support older versions
of ROCm is not needed any more.
Reviewed-by: Philip Yang
Am 2021-04-14 um 3:33 a.m. schrieb Christian König:
> Am 14.04.21 um 08:46 schrieb Felix Kuehling:
>> amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The
>> dmabuf->resv
>> must not be held by the caller or dma_buf_detach will deadlock. This is
>> probably not the right fix. I get a recur
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:
for_each_new_connector_in_state(&state->base, connector, ...
drm_connector_update
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.
Registering a privacy-screen device with the new privacy-screen class
code will also
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/
Add 2 drm_connector privacy-screen helper functions:
1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.
This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).
Sign
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen.c | 67 +++
include/drm/drm_privacy_screen_consume
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.
This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.
Signed-off-by: Hans d
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
"privacy-screen hw-state", to deal with devices where the OS might be
lo
On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.
This commit adds a privacy-screen class allowing the dr
Hi All,
Here is the privacy-screen related code which I last posted in August
of last year. To the best of my knowledge there is consensus about /
everyone is in agreement with the new userspace API (2 connector properties)
this patch-set add (patch 1 of the series).
The blocker the last time was
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #14 from Ilia Mirkin (imir...@alum.mit.edu) ---
Also, wow, BAR1 = 16GB?? Normally it's like 256MB. No wonder your TB setup had
issues.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are wat
1 - 100 of 148 matches
Mail list logo
