On Mon 10 May 07:16 CDT 2021, sbill...@codeaurora.org wrote:
> On 2021-05-06 20:32, Rob Clark wrote:
> > On Wed, May 5, 2021 at 11:47 PM wrote:
> > >
> > > On 2021-05-05 15:31, Dmitry Baryshkov wrote:
> > > > Hi,
> > > >
> > > > On Wed, 5 May 2021 at 11:17, Sankeerth Billakanti
> > > > wrote:
On Mon, May 10, 2021 at 1:31 PM Pi-Hsun Shih wrote:
>
> Add suspend / resume hooks for anx7625 driver, that power off the device
> on suspend and power on the device on resume if it was previously
> powered.
>
> Signed-off-by: Pi-Hsun Shih
Tested-by: Hsin-Yi Wang
Tested on a mt8183 juniper
On Mon, May 10, 2021 at 1:31 PM Pi-Hsun Shih wrote:
>
> The driver originally use an atomic_t for keep track of the power
> status, which makes the driver more complicated than needed, and has
> some race condition as it's possible to have the power on and power off
> sequence going at the same
The eDP controller found in SC8180x is at large compatible with the
current implementation, but has its register blocks at slightly
different offsets.
Add the compatible and the new register layout.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_display.c | 1 +
Some bootloaders set the widebus enable bit in the INTF_CONFIG register,
but configuration of widebus isn't yet supported ensure that the
register has a known value, with widebus disabled.
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Signed-off-by: Bjorn Andersson
---
Not all platforms has DP_P0 at offset 0x1000 from the beginning of the
DP block. So move the offsets into dss_io_data, to make it possible in
the next patch to specify alternative offsets and sizes of these
segments.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 57
In the search for causes to timing issues seen during implementation of
eDP support for SC8180x a fair amount of time was spent concluding why
the calculated mvid/nvid values where wrong.
The overall conclusion is that the ratio of MVID/NVID describes, and
should match, the ratio between the
The first patch in the series is somewhat unrelated to the support, but
simplifies reasoning and debugging of timing related issues.
The second patch introduces support for dealing with different register block
layouts, which is used in the forth patch to describe the hardware blocks found
in the
From: Rob Clark
Add SC8180x to the hardware catalog, for initial support for the
platform. Due to limitations in the DP driver only one of the four DP
interfaces is left enabled.
The SC8180x platform supports the newly added DPU_INTF_WIDEBUS flag and
the Windows-on-Snapdragon bootloader leaves
Signed-off-by: Bjorn Andersson
---
This is a hack and as discussed on IRC this should be replaced by some sane
mechanism for dealing with the old and new IRQ layout. Including it in the
series for completeness.
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 14 ++
1 file
It's typical for the bootloader to configure CTL_0 for the boot splash
or EFIFB, but for non-DSI use cases the DPU driver tend to pick another
CTL and the system might end up with two configured data paths producing
data on the same INTF - with resulting graphical artifacts.
Naturally the end
Some hardware supports clocking 2 pixels per pixel clock pulse, known as
"widebus". The configuration needs to match between the DPU and the
interface controller, and the timing parameters must be adjusted.
As a first step towards supporting this, start by adding a INTF mask
flag to signal the
These patches adds MDSS and DPU support for the Qualcomm SC8180x platform.
The platform supports running 2 pixels per pixel clock cycle and the bootloader
enables this, so the first patch adds enough support to the DPU driver to
disable this again.
The second patch shoots down the data path
On Mon, Apr 26, 2021 at 11:24 PM Kai-Heng Feng
wrote:
>
> On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> to discrete GFX after S3. This is not desirable, because userspace will
> treat connected display as a new one, losing display settings.
>
> The expected behavior is
On Fri, Apr 30, 2021 at 12:57 PM Kai-Heng Feng
wrote:
>
> Screen flickers rapidly when two 4K 60Hz monitors are in use. This issue
> doesn't happen when one monitor is 4K 60Hz (pixelclock 594MHz) and
> another one is 4K 30Hz (pixelclock 297MHz).
>
> The issue is gone after setting
On Sun, 09 May 2021 16:11:43 -0700, Jason Ekstrand wrote:
>
> Yes, landing GuC support may be the first step in removing execlist
> support. The inevitable reality is that GPU scheduling is coming and
> likely to be there only path in the not-too-distant future. (See also
> the ongoing thread
https://bugzilla.kernel.org/show_bug.cgi?id=211875
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #296147|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=211875
--- Comment #10 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 296715
--> https://bugzilla.kernel.org/attachment.cgi?id=296715=edit
dmesg (kernel 5.13-rc1, A10-9700E)
Some locking stacktrace on kernel v5.13-rc1 before the usual
Add a function to add modifiers to a plane.
Signed-off-by: Tina Zhang
---
drivers/gpu/drm/drm_plane.c | 41 +
include/drm/drm_plane.h | 3 +++
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index
From: Vivek Kasireddy
With new use-cases coming up that include virtio-gpu:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9592
the FB associated with a Guest blob may have a modifier. Therefore,
this modifier info needs to be included as part of set_scanout_blob.
v2: (Tina)
* Use
Add a command to get modifier info from the backend.
Signed-off-by: Tina Zhang
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++
drivers/gpu/drm/virtio/virtgpu_kms.c | 3 ++
drivers/gpu/drm/virtio/virtgpu_plane.c | 16 ++
drivers/gpu/drm/virtio/virtgpu_vq.c| 42
This patchset introduces the modifiers support to virtio-gpu.
This RFC version tries to add a new virtio-gpu command to let front-end driver
query the modifiers' info from the backend. Besides, the front-end driver
may also need a new drm helper function to add the supported modifiers to a
plane
https://bugzilla.kernel.org/show_bug.cgi?id=212959
tob88...@gmail.com changed:
What|Removed |Added
Severity|blocking|normal
--
You may reply to this
https://bugzilla.kernel.org/show_bug.cgi?id=212959
tob88...@gmail.com changed:
What|Removed |Added
Summary|[drm:dm_helpers_dp_write_dp |[drm:dm_helpers_dp_write_dp
https://bugzilla.kernel.org/show_bug.cgi?id=212959
--- Comment #4 from tob88...@gmail.com ---
(In reply to Alex Deucher from comment #2)
> Please attach the dmesg output for your system. Other than the error, is
> the GPU otherwise working correctly?
The GPU otherwise is working correctly. On
https://bugzilla.kernel.org/show_bug.cgi?id=212959
--- Comment #3 from tob88...@gmail.com ---
Created attachment 296713
--> https://bugzilla.kernel.org/attachment.cgi?id=296713=edit
Dmesg output
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are
Hi Andrey,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.13-rc1 next-20210510]
[cannot apply to pci/next drm/drm
On 2021-05-10 5:33 p.m., Rodrigo Siqueira wrote:
LGTM,
Jay, any comment?
None, LGTM, and this applied already.
Reviewed-by: Rodrigo Siqueira
On 05/08, Rouven Czerwinski wrote:
This function is not used anywhere, remove it. It was added in
40dd6bd376a4 ("drm/amd/display: Linux Set/Read
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
The Memory
It's useful to know the total number of underflow events and currently
the debug stats are getting reset each time CRTC is being disabled. Let's
account the overall number of events that doesn't get a reset.
Reviewed-by: Michał Mirosław
Signed-off-by: Dmitry Osipenko
---
This series adds memory bandwidth management to the NVIDIA Tegra DRM driver,
which is done using interconnect framework. It fixes display corruption that
happens due to insufficient memory bandwidth.
Changelog:
v17: - No changes, re-sending for v5.14.
v16: - Implemented suggestions that were
On Mon, May 10, 2021 at 06:46:16PM +0530, Rajat Asthana wrote:
> Declare drm_send_event_helper as static to fix sparse warning:
>
> > warning: symbol 'drm_send_event_helper' was not declared.
> > Should it be static?
>
> Signed-off-by: Rajat Asthana
> ---
> Changes in v2:
> Provide full
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Thursday, April 22, 2021 6:20 AM
To: Kuehling, Felix ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Wednesday, April 21, 2021 8:31 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH v2 09/10] drm/ttm:
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Tuesday, April 27, 2021 10:09 AM
To: Zeng, Oak ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Wednesday, April 21, 2021 8:31 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH v2 07/10] drm/amdgpu:
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Monday, April 26, 2021 10:48 PM
To: Zeng, Oak ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Monday, April 26, 2021 10:41 PM
To: Zeng, Oak ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Friday, April 23, 2021 2:23 AM
To: Zeng, Oak ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Wednesday, April 21, 2021 8:31 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH v2 03/10] drm/amdgpu:
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ramesh Errabolu
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Wednesday, April 21, 2021 8:31 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH v2 02/10] drm/amdgpu:
Hi Alex,
On 5/10/21 16:17, Alex Deucher wrote:
> On Sun, May 9, 2021 at 6:48 PM Gustavo A. R. Silva
> wrote:
[..]
>>
>> Bug:
>> https://lore.kernel.org/dri-devel/3eedbe78-1fbd-4763-a7f3-ac5665e76...@xenosoft.de/
>> Fixes: 434fb1e7444a ("drm/radeon/nislands_smc.h: Replace one-element array
>>
On Fri, May 7, 2021 at 3:27 PM Werner Sembach wrote:
>
> xrandr --prop and other userspace info tools have currently no way of
> telling which color configuration is used on HDMI and DP ports.
>
> The ongoing transsition from HDMI 1.4 to 2.0 and the different bandwidth
> requirements of YCbCr
lgtm,
Reviewed-by: Rodrigo Siqueira
On 05/10, Andrey Grodzovsky wrote:
> It's already being released by DRM core through devm
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
LGTM,
Jay, any comment?
Reviewed-by: Rodrigo Siqueira
On 05/08, Rouven Czerwinski wrote:
> This function is not used anywhere, remove it. It was added in
> 40dd6bd376a4 ("drm/amd/display: Linux Set/Read link rate and lane count
> through debugfs") and moved in fe798de53a7a ("drm/amd/display:
Applied. Thanks!
Alex
On Mon, May 10, 2021 at 8:24 AM Zhen Lei wrote:
>
> The result of an expression consisting of a single relational operator is
> already of the bool type and does not need to be evaluated explicitly.
>
> No functional change.
>
> Signed-off-by: Zhen Lei
> ---
>
Applied. Thanks!
Alex
On Mon, May 10, 2021 at 8:16 AM Zhen Lei wrote:
>
> The result of an expression consisting of a single relational operator is
> already of the bool type and does not need to be evaluated explicitly.
>
> No functional change.
>
> Signed-off-by: Zhen Lei
> ---
>
On Mon, May 10, 2021 at 4:45 PM Gustavo A. R. Silva
wrote:
>
> Create new structure SISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
> and ACPIState.levels are never actually used as flexible arrays. Those
> arrays can be used as simple objects of type
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL,
Applied. Thanks!
Alex
On Mon, May 10, 2021 at 1:51 AM Kai-Heng Feng
wrote:
>
> On Mon, May 10, 2021 at 6:54 AM Gustavo A. R. Silva
> wrote:
> >
> > Create new structure SISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
> > and ACPIState.levels are never actually used as flexible arrays.
On Sun, May 9, 2021 at 6:48 PM Gustavo A. R. Silva
wrote:
>
> Create new structure NISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
> and ACPIState.levels are never actually used as flexible arrays. Those
> arrays can be used as simple objects of type
> NISLANDS_SMC_HW_PERFORMANCE_LEVEL,
https://bugzilla.kernel.org/show_bug.cgi?id=213007
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
Applied. Thanks!
Alex
On Sun, May 9, 2021 at 12:30 PM Christian König
wrote:
>
> Am 09.05.21 um 16:49 schrieb Dwaipayan Ray:
> > Fix a couple of syntax errors and removed one excess
> > parameter in the function documentations which lead
> > to kernel docs build warning.
> >
> > Signed-off-by:
In subject:
PCI: Add support for dev_groups to struct pci_driver
(not "struct pci_device_driver," which does not exist)
On Mon, May 10, 2021 at 12:36:17PM -0400, Andrey Grodzovsky wrote:
> This helps converting PCI drivers sysfs attributes to static.
>
> Analogous to b71b283e3d6d ("USB: add
Applied. Thanks!
Alex
On Sun, May 9, 2021 at 11:42 AM Rouven Czerwinski wrote:
>
> This function is not used anywhere, remove it. It was added in
> 40dd6bd376a4 ("drm/amd/display: Linux Set/Read link rate and lane count
> through debugfs") and moved in fe798de53a7a ("drm/amd/display: Move link
Create new structure SISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
and ACPIState.levels are never actually used as flexible arrays. Those
arrays can be used as simple objects of type
SISLANDS_SMC_HW_PERFORMANCE_LEVEL, instead.
Currently, the code fails because flexible array _levels_ in
On 5/10/21 8:04 PM, Dave Stevenson wrote:
Hi,
[...]
+static void sn65dsi83_enable(struct drm_bridge *bridge)
+{
+ struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+ unsigned int pval;
+ u16 val;
+ int ret;
+
+ /* Clear reset, disable PLL */
+
On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8.
> >
> > See, a number of converted documents ended with weird
Quoting Daniel Vetter (2021-05-10 11:26:40)
> On Mon, May 10, 2021 at 7:52 PM Stephen Boyd wrote:
> > The device list now has msm, i2c, bridge in that order. When we go to
> > system wide shutdown the bridge is shutdown first, then the i2c bus, and
> > then msm calls drm_atomic_helper_shutdown().
On Mon, May 10, 2021 at 10:44 AM Daniel Vetter wrote:
>
> On Mon, May 10, 2021 at 6:51 PM Rob Clark wrote:
> >
> > On Mon, May 10, 2021 at 9:14 AM Daniel Vetter wrote:
> > >
> > > On Sat, May 08, 2021 at 12:56:38PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > >
On Fri, May 07, 2021 at 05:42:09PM -0400, Lyude Paul wrote:
> Ville pointed this out to me when fixing some issues in
> drm_dp_read_downstream_info() - the DPCD version check here is bogus as
> there's no DisplayPort versions prior to 1.0. The original code from i915
> that this was extracted from
Daniel Vetter writes:
> On Mon, May 10, 2021 at 3:55 PM Martin Peres wrote:
>>
>> On 10/05/2021 02:11, Jason Ekstrand wrote:
>> > On May 9, 2021 12:12:36 Martin Peres wrote:
>> >
>> >> Hi,
>> >>
>> >> On 06/05/2021 22:13, Matthew Brost wrote:
>> >>> Basic GuC submission support. This is the
On 2021-05-10 2:27 p.m., Felix Kuehling wrote:
Am 2021-05-10 um 12:36 p.m. schrieb Andrey Grodzovsky:
It's needed to drop iommu backed pages on device unplug
before device's IOMMU group is released.
I don't see any calls to ttm_tt_unpopulate in the rest of the series
now. Is that an
Am 2021-05-10 um 12:36 p.m. schrieb Andrey Grodzovsky:
> It's needed to drop iommu backed pages on device unplug
> before device's IOMMU group is released.
I don't see any calls to ttm_tt_unpopulate in the rest of the series
now. Is that an accident, or can this patch be dropped?
Regards,
On Mon, May 10, 2021 at 7:52 PM Stephen Boyd wrote:
>
> Quoting Daniel Vetter (2021-05-10 09:05:21)
> > On Sat, May 08, 2021 at 12:41:18AM -0700, Stephen Boyd wrote:
> > > The device lists are poorly ordered when the component device code is
> > > used. This is because
On 10/05/21 19:57, Sean Christopherson wrote:
+Paolo
On Mon, May 10, 2021, Jason Gunthorpe wrote:
On Mon, May 10, 2021 at 04:55:39PM +0200, Daniel Vetter wrote:
yeah vfio is still broken for the case I care about. I think there's
also some questions open still about whether kvm really uses
Am 04.05.21 um 17:11 schrieb Daniel Vetter:
On Tue, May 04, 2021 at 04:26:42PM +0200, Christian König wrote:
Hi Daniel,
Am 04.05.21 um 16:15 schrieb Daniel Vetter:
Hi Christian,
On Tue, May 04, 2021 at 03:27:17PM +0200, Christian König wrote:
Hi guys,
with this patch set I want to look
On Mon, 10 May 2021 at 12:16, Marek Vasut wrote:
>
> On 5/10/21 11:58 AM, Dave Stevenson wrote:
> > On Sat, 8 May 2021 at 21:26, Marek Vasut wrote:
> >>
> >> On 5/7/21 2:48 PM, Dave Stevenson wrote:
> >>
> >> [...]
> >>
> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> +{
>
Quoting Daniel Vetter (2021-05-10 09:05:21)
> On Sat, May 08, 2021 at 12:41:18AM -0700, Stephen Boyd wrote:
> > The device lists are poorly ordered when the component device code is
> > used. This is because component_master_add_with_match() returns 0
> > regardless of component devices calling
On Mon, May 10, 2021 at 6:51 PM Rob Clark wrote:
>
> On Mon, May 10, 2021 at 9:14 AM Daniel Vetter wrote:
> >
> > On Sat, May 08, 2021 at 12:56:38PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > drm_atomic_helper_dirtyfb() will end up stalling for vblank on "video
> > > mode" type
Quoting Zhen Lei (2021-05-09 23:38:05)
> The error code returned by platform_get_irq() is stored in 'irq', it's
> forgotten to be copied to 'ret' before being returned. As a result, the
> value 0 of 'ret' is returned incorrectly.
>
> After the above fix is completed, initializing the local
On Mon, May 10, 2021 at 9:14 AM Daniel Vetter wrote:
>
> On Sat, May 08, 2021 at 12:56:38PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > drm_atomic_helper_dirtyfb() will end up stalling for vblank on "video
> > mode" type displays, which is pointless and unnecessary. Add an
> > optional
In case device remove is just simualted by sysfs then verify
device doesn't keep doing DMA to the released memory after
pci_remove is done.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Problem: If scheduler is already stopped by the time sched_entity
is released and entity's job_queue not empty I encountred
a hang in drm_sched_entity_flush. This is because drm_sched_entity_is_idle
never becomes false.
Fix: In drm_sched_fini detach all sched_entities from the
scheduler's run
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
v5:
Protect more places wher memcopy_to/form_io takes place
Protect IB submissions
v6: Switch to !drm_dev_enter instead of scoping entire code
with brackets.
Signed-off-by:
If removing while commands in flight you cannot wait to flush the
HW fences on a ring since the device is gone.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git
Return DRM_TASK_STATUS_ENODEV back to the scheduler when device
is not present so they timeout timer will not be rearmed.
v5: Update to match updated return values in enum drm_gpu_sched_stat
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 19 ---
We don't want to rearm the timer if driver hook reports
that the device is gone.
v5: Update drm_gpu_sched_stat values in code.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git
On device removal reroute all CPU mappings to dummy page
per drm_file instance or imported GEM object.
v4:
Update for modified ttm_bo_vm_dummy_page
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 21 -
1 file
This allows to remove explicit creation and destruction
of those attrs and by this avoids warnings on device
finalizing post physical device extraction.
v5: Use newly added pci_driver.dev_groups directly
Signed-off-by: Andrey Grodzovsky
Acked-by: Christian König
---
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
This helps converting PCI drivers sysfs attributes to static.
Analogous to b71b283e3d6d ("USB: add support for dev_groups to
struct usb_driver")
Signed-off-by: Andrey Grodzovsky
Suggested-by: Greg Kroah-Hartman
---
drivers/pci/pci-driver.c | 1 +
include/linux/pci.h | 3 +++
2 files
Some of the stuff in amdgpu_device_fini such as HW interrupts
disable and pending fences finilization must be done right away on
pci_remove while most of the stuff which relates to finilizing and
releasing driver data structures can be kept until
drm_driver.release hook is called, i.e. when the
Helps to expdite HW related stuff to amdgpu_pci_remove
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
It's already being released by DRM core through devm
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
Use it to call disply code dependent on device->drv_data
before it's set to NULL on device unplug
v5: Move HW finilization into this callback to prevent MMIO accesses
post cpi remove.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 59
It's needed to drop iommu backed pages on device unplug
before device's IOMMU group is released.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index
On device removal reroute all CPU mappings to dummy page.
v3:
Remove loop to find DRM file and instead access it
by vma->vm_file->private_data. Move dummy page installation
into a separate function.
v4:
Map the entire BOs VA space into on demand allocated dummy page
on the first fault for that
Until now extracting a card either by physical extraction (e.g. eGPU with
thunderbolt connection or by emulation through sysfs ->
/sys/bus/pci/devices/device_id/remove)
would cause random crashes in user apps. The random crashes in apps were
mostly due to the app having mapped a device backed
On Mon, May 10, 2021 at 3:55 PM Martin Peres wrote:
>
> On 10/05/2021 02:11, Jason Ekstrand wrote:
> > On May 9, 2021 12:12:36 Martin Peres wrote:
> >
> >> Hi,
> >>
> >> On 06/05/2021 22:13, Matthew Brost wrote:
> >>> Basic GuC submission support. This is the first bullet point in the
> >>>
On May 10, 2021 08:55:55 Martin Peres wrote:
On 10/05/2021 02:11, Jason Ekstrand wrote:
On May 9, 2021 12:12:36 Martin Peres wrote:
Hi,
On 06/05/2021 22:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point in the
upstreaming plan covered in the following
On Mon, May 10, 2021 at 7:12 AM Adam Ford wrote:
>
> On Mon, Oct 5, 2020 at 8:48 AM Marek Vasut wrote:
> >
> > This adds basic i.MX8MM glue code for the Samsung DSIM PHY.
> > There are still a couple of items which need to be sorted out
> > in drivers/gpu/drm/bridge/samsung-dsim.c before this
On Mon, May 10, 2021 at 06:14:20PM +0200, Daniel Vetter wrote:
> On Sat, May 08, 2021 at 12:56:38PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > drm_atomic_helper_dirtyfb() will end up stalling for vblank on "video
> > mode" type displays, which is pointless and unnecessary. Add an
> >
On Sat, 08 May 2021 22:22:50 +0200, Marek Vasut wrote:
> Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
>
> Reviewed-by: Linus Walleij
> Signed-off-by: Marek Vasut
> Cc: Douglas Anderson
> Cc: Jagan Teki
> Cc: Laurent Pinchart
> Cc: Linus Walleij
> Cc: Rob
On Sat, May 08, 2021 at 12:56:38PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> drm_atomic_helper_dirtyfb() will end up stalling for vblank on "video
> mode" type displays, which is pointless and unnecessary. Add an
> optional helper vfunc to determine if a plane is attached to a CRTC
> that
Hi,
Mon, 2021-05-10 at 17:36 +0200, Daniel Vetter wrote:
>
...
> > If DRM allows user-space to exhaust all of system memory, this seems
> > to be a gap in enforcement of MEMCG limits for system memory.
> > I tried to look into it when this was discussed in the past
> > My guess is that
On Sat, May 08, 2021 at 12:41:18AM -0700, Stephen Boyd wrote:
> The device lists are poorly ordered when the component device code is
> used. This is because component_master_add_with_match() returns 0
> regardless of component devices calling component_add() first. It can
> really only fail if an
On 10/05/2021 14:38, Mauro Carvalho Chehab wrote:
> Em Mon, 10 May 2021 14:16:16 +0100
> Edward Cree escreveu:
>> But what kinds of things with × or — in are going to be grept for?
>
> Actually, on almost all places, those aren't used inside math formulae, but
> instead, they describe video some
On 10/05/2021 14:59, Matthew Wilcox wrote:
> Most of these
> UTF-8 characters come from latex conversions and really aren't
> necessary (and are being used incorrectly).
I fully agree with fixing those.
The cover-letter, however, gave the impression that that was not the
main purpose of this
On Mon, May 10, 2021 at 13:55:18 +0200, Mauro Carvalho Chehab wrote:
> $ git grep "CPU 0 has been" Documentation/RCU/
> Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0
> has been in dyntick-idle mode for quite some time. When it |
>
On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> The main point on this series is to replace just the occurrences
> where ASCII represents the symbol equally well
> - U+2014 ('—'): EM DASH
Em dash is not the same thing as hyphen-minus, and the latter does not
serve 'equally well'.
1 - 100 of 187 matches
Mail list logo
