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
in
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 las
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(-)
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 ++--
drivers/gpu/drm/amd/amdgpu/
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 chang
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 chang
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
---
drivers/gpu/drm/amd/amdgpu/
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 a/drivers/gpu/
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 ---
1
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 a/drivers/gpu/drm/amd
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: A
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 queu
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 a/drivers/gpu/drm/amd/a
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 h
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 variable
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 di
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 com
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)
> +{
> >
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 into
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
mm
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 component_master_add_with_ma
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,
Felix
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 accident,
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 fir
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
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
> > > >
> > > > drm_atomic_helpe
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 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 c
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 */
+ regmap_write(
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
stru
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
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 s
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:
https://bugzilla.kernel.org/show_bug.cgi?id=213007
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
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, instea
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. Thos
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, inste
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
> ---
> drivers/gp
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
> ---
> drivers/gp
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: Mo
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 a/drivers/gpu/drm
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 4:2:
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
>> w
[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:
[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: Friday, April 23, 2021 2:23 AM
To: Zeng, Oak ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 04/10
[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 05/1
[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 06/1
[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: Tuesday, April 27, 2021 10:09 AM
To: Zeng, Oak ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 08/
[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: Don
[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
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 name
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 giv
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
---
drivers/gpu/drm/tegra/d
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
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
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
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&action=edit
Dmesg output
--
You may reply to this email to add a comment.
You are receiving this mail because:
You a
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 ot
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
tob88...@gmail.com changed:
What|Removed |Added
Severity|blocking|normal
--
You may reply to this ema
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
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 +
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 dr
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
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&action=edit
dmesg (kernel 5.13-rc1, A10-9700E)
Some locking stacktrace on kernel v5.13-rc1 before the u
https://bugzilla.kernel.org/show_bug.cgi?id=211875
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #296147|0 |1
is obsolete|
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 with
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 "power_dpm_force
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
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 confi
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 tim
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 goal
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 change
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 t
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
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 pixel
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 +++
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
---
drive
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 +
drivers/gpu/drm/m
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 ti
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 dev
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:
>
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/gpu/drm/panfro
On Mon, May 10, 2021 at 12:26:12PM +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
[...]
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
>
> As Linux developers are all around the globe, an
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
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 a
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
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 ++
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
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
Acked-by: Christian Kö
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
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/am
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
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 sc
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
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
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 11 ++
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
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
Reviewed-by: Christi
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
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 insertio
On Wed, May 05, 2021 at 06:24:14PM +0200, Hans de Goede wrote:
> Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
> rather then having separate code-paths for this in various places
> which call it.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Heikki Krogerus
> ---
> drivers/
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
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
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv
On Wed, May 05, 2021 at 06:24:15PM +0200, Hans de Goede wrote:
> Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
> drivers know about DisplayPort over Type-C hotplug events.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Heikki Krogerus
> ---
> Changes in v3:
> - Only cal
101 - 197 of 197 matches
Mail list logo
