That is already fixed upstream.
Am 28.04.21 um 07:33 schrieb Felix Kuehling:
ttm_bo_swapout returns a non-0 value on success. Don't treat that as an
error in ttm_tt_populate.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Am 28.04.21 um 07:33 schrieb Felix Kuehling:
SG BOs do not occupy space that is managed by TTM. So do not evict them.
This fixes unexpected evictions of KFD's userptr BOs. KFD only expects
userptr "evictions" in the form of MMU notifiers.
NAK, SG BOs also account for the memory the GPU can cur
> A solution to make this configuration generic and exposed by the kernel
> would standardise this across Linux
Having a KMS property for this makes sense to me.
Chatting with Jani on IRC, it doesn't seem like there's any EDID or
DisplayID block for this.
Note, Android exposes a data structure [
On Tue, 27 Apr 2021, Linus Torvalds wrote:
> I've updated to Fedora 34 on one of my machines, and it causes a lot
> of i915 warnings like
>
> drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’:
> drivers/gpu/drm/i915/intel_pm.c:3059:9: note: referencing argument 3
> of type ‘c
On Wed, 28 Apr 2021 07:21:28 +
Simon Ser wrote:
> > A solution to make this configuration generic and exposed by the kernel
> > would standardise this across Linux
>
> Having a KMS property for this makes sense to me.
>
> Chatting with Jani on IRC, it doesn't seem like there's any EDID or
Am 2021-04-28 um 3:04 a.m. schrieb Christian König:
> Am 28.04.21 um 07:33 schrieb Felix Kuehling:
>> SG BOs do not occupy space that is managed by TTM. So do not evict them.
>>
>> This fixes unexpected evictions of KFD's userptr BOs. KFD only expects
>> userptr "evictions" in the form of MMU noti
On 22.04.21 00:31, Marek Vasut wrote:
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
but easy to add.
The driver operates the chip
On Wednesday, April 28th, 2021 at 9:44 AM, Pekka Paalanen
wrote:
> I'm kind of worried whether you can design a description structure that
> would be good for a long time. That list already looks quite
> complicated. Add also watch-like devices with circular displays.
>
> Would the kernel itself
Hello Harry,
Many of us in the mail chain have discussed this before, on what is the right
way to blend and tone map a SDR and a HDR buffer from same/different color
spaces, and what kind of DRM plane properties will be needed.
As you can see from the previous comments, that the majority of the
On 22.04.21 00:31, Marek Vasut wrote:
Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
Signed-off-by: Marek Vasut
Cc: Douglas Anderson
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: Stephen Boyd
Cc: devicet...@vger.ker
On 28.04.21 09:51, Frieder Schrempf wrote:
On 22.04.21 00:31, Marek Vasut wrote:
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
but
On Tue, 27 Apr 2021, Umesh Nerlige Ramappa
wrote:
> Perf measurements rely on CPU and engine timestamps to correlate
> events of interest across these time domains. Current mechanisms get
> these timestamps separately and the calculated delta between these
> timestamps lack enough accuracy.
>
> T
Am 28.04.21 um 09:49 schrieb Felix Kuehling:
Am 2021-04-28 um 3:04 a.m. schrieb Christian König:
Am 28.04.21 um 07:33 schrieb Felix Kuehling:
SG BOs do not occupy space that is managed by TTM. So do not evict them.
This fixes unexpected evictions of KFD's userptr BOs. KFD only expects
userptr
On 2021-04-28 8:59 a.m., Christian König wrote:
> Hi Dave,
>
> Am 27.04.21 um 21:23 schrieb Marek Olšák:
>> Supporting interop with any device is always possible. It depends on which
>> drivers we need to interoperate with and update them. We've already found
>> the path forward for amdgpu. We j
On Wed, 28 Apr 2021 at 10:13, Frieder Schrempf
wrote:
>
> On 28.04.21 09:51, Frieder Schrempf wrote:
> > On 22.04.21 00:31, Marek Vasut wrote:
> >> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> >> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> >>
On 28/04/2021 11:26, Loic Poulain wrote:
> On Wed, 28 Apr 2021 at 10:13, Frieder Schrempf
> wrote:
>>
>> On 28.04.21 09:51, Frieder Schrempf wrote:
>>> On 22.04.21 00:31, Marek Vasut wrote:
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
and TI SN65DSI84 Single-lin
On resume, dispc pm_runtime_force_resume() is not enabling the hardware
as we pass the pm_runtime_need_not_resume() test as the device is suspended
with no child devices.
As the resume continues, omap_atomic_comit_tail() calls dispc_runtime_get()
that calls rpm_resume() enabling the hardware, and
* Tony Lindgren [210427 10:54]:
> * Tony Lindgren [210427 10:12]:
> > * Tomi Valkeinen [210427 08:47]:
> > > If I understand right, this is only an issue when the dss was not enabled
> > > before the system suspend? And as the dispc is not enabled at suspend,
> > > pm_runtime_force_suspend and p
On Wed, Apr 28, 2021 at 2:54 PM Neil Armstrong wrote:
>
> On 28/04/2021 11:26, Loic Poulain wrote:
> > On Wed, 28 Apr 2021 at 10:13, Frieder Schrempf
> > wrote:
> >>
> >> On 28.04.21 09:51, Frieder Schrempf wrote:
> >>> On 22.04.21 00:31, Marek Vasut wrote:
> Add driver for TI SN65DSI83 Sing
On 26/04/2021 17:37, Claire Chang wrote:
On Fri, Apr 23, 2021 at 7:34 PM Steven Price wrote:
[...]
But even then if it's not and we have the situation where debugfs==NULL
then the debugfs_create_dir() here will cause a subsequent attempt in
swiotlb_create_debugfs() to fail (directory already
On Wed, Apr 28, 2021 at 08:59:47AM +0200, Christian König wrote:
> Hi Dave,
>
> Am 27.04.21 um 21:23 schrieb Marek Olšák:
> > Supporting interop with any device is always possible. It depends on
> > which drivers we need to interoperate with and update them. We've
> > already found the path forwar
On Wed, Apr 28, 2021 at 11:07:09AM +0200, Michel Dänzer wrote:
> On 2021-04-28 8:59 a.m., Christian König wrote:
> > Hi Dave,
> >
> > Am 27.04.21 um 21:23 schrieb Marek Olšák:
> >> Supporting interop with any device is always possible. It depends on which
> >> drivers we need to interoperate with
On Tue, Apr 27, 2021 at 06:27:27PM +, Simon Ser wrote:
> On Tuesday, April 27th, 2021 at 8:01 PM, Alex Deucher
> wrote:
>
> > It's an upcoming requirement for windows[1], so you are likely to
> > start seeing this across all GPU vendors that support windows. I
> > think the timing depends on
On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
> On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
> >
> > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
> > wrote:
> >
> > > > Ok. So that would only make the following use cases broken for now:
> > > >
> > > > - amd render ->
On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
> On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand wrote:
> >
> > This adds a bunch of complexity which the media driver has never
> > actually used. The media driver does technically bond a balanced engine
> > to another engine but th
On Fri, Apr 23, 2021 at 05:31:19PM -0500, Jason Ekstrand wrote:
> There's no sense in allowing userspace to create more engines than it
> can possibly access via execbuf.
>
> Signed-off-by: Jason Ekstrand
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +++
> 1 file changed, 3 insert
On Fri, Apr 23, 2021 at 05:31:21PM -0500, Jason Ekstrand wrote:
> As far as I can tell, the only real reason for this is to avoid taking a
> reference to the i915_gem_context. The cost of those two atomics
> probably pales in comparison to the cost of the ioctl itself so we're
> really not buying
Am 28.04.21 um 12:05 schrieb Daniel Vetter:
On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
wrote:
Ok. So that would only make the following use cases broken for now:
- amd
On 28/04/2021 11:16, Daniel Vetter wrote:
On Fri, Apr 23, 2021 at 05:31:19PM -0500, Jason Ekstrand wrote:
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7
>From anx7625 spec, the delay between powering on power supplies and gpio
should be larger than 10ms.
Fixes: 6c744983004e ("drm/bridge: anx7625: disable regulators when power off")
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Neil Armstrong
---
v1->v2: Extend sleep range a bit as the regulator on so
Hi, pinging here, can one of the kernel bridge maintainers review this patchset?
Thanks,
Dafna
On 09.04.21 18:19, Dafna Hirschfeld wrote:
ANX7688 is a typec port controller that also converts HDMI to DP.
ANX7688 is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone.
On Acer Chromebook
On Wed, Apr 28, 2021 at 10:44:03AM +0300, Pekka Paalanen wrote:
> On Wed, 28 Apr 2021 07:21:28 +
> Simon Ser wrote:
>
> > > A solution to make this configuration generic and exposed by the kernel
> > > would standardise this across Linux
> >
> > Having a KMS property for this makes sense t
On 16/04/2021 09:46, Tomi Valkeinen wrote:
> Hi Hans,
>
> On 02/03/2021 18:23, Hans Verkuil wrote:
>> Add bridge connector_attach/detach ops. These ops are called when a
>> bridge is attached or detached to a drm_connector. These ops can be
>> used to register and unregister an HDMI CEC adapter fo
On Wed, 28 Apr 2021, Daniel Vetter wrote:
> On Wed, Apr 28, 2021 at 10:44:03AM +0300, Pekka Paalanen wrote:
>> This seems more like a job for the hypothetical liboutput, just like
>> recognising HMDs (yes, I know, kernel does that already, but there is a
>> point that kernel may not want to put fb
On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
> Am 28.04.21 um 12:05 schrieb Daniel Vetter:
> > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
> > > On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
> > > > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
> >
On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote:
> On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
> > Am 28.04.21 um 12:05 schrieb Daniel Vetter:
> > > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
> > > > On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wr
On Wednesday, April 28th, 2021 at 2:21 PM, Daniel Vetter
wrote:
> Yeah I think we have pretty clear consensus on that goal, just no one yet
> volunteered to get going with the winsys/wayland work to plumb drm_syncobj
> through, and the kernel/mesa work to make that optionally a userspace
> fence
https://bugzilla.kernel.org/show_bug.cgi?id=212871
Bug ID: 212871
Summary: AMD Radeon Pro VEGA 20 (Aka Vega12) - Glitch and
freeze on any kernel and/or distro.
Product: Drivers
Version: 2.5
Kernel Version: Any
Hardware:
On Wed, Apr 28, 2021 at 6:31 AM Christian König
wrote:
>
> Am 28.04.21 um 12:05 schrieb Daniel Vetter:
> > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
> >> On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
> >>> On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
> >>> wrote:
Now, after a few fixes we may consider the conversion to
the GPIO descriptor API is done.
Signed-off-by: Andy Shevchenko
---
drivers/staging/fbtft/TODO | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/fbtft/TODO b/drivers/staging/fbtft/TODO
index a9f4802bb6be..e72a08bf221c
When requesting GPIO line the probe can be deferred.
In such case don't spam logs with an error message.
This can be achieved by switching to dev_err_probe().
Signed-off-by: Andy Shevchenko
---
drivers/staging/fbtft/fbtft-core.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
This series fixes a number of GPIO handling issues after converting this driver
to use descriptors.
The series has been tested on HX8347d display with parallel interface. Without
first patch it's not working.
In v3:
- added staging prefix (Fabio)
- slightly amended commit message in the patch 1
The infamous commit c440eee1a7a1 ("Staging: staging: fbtft: Switch to
the GPIO descriptor interface") broke GPIO handling completely.
It has already four commits to rectify and it seems not enough.
In order to fix the mess here we:
1) Set default to "inactive" for all requested pins
2) Fix CS
The custom ->reset() repeats the generic one, replace it.
Note, in newer kernels the context of the function is a sleeping one,
it's fine to switch over to the sleeping functions. Keeping the reset
line asserted longer than 20 microseconds is also okay, it's an idling
state of the hardware.
Signe
Multi line comment have been aligned starting with a *
The closing */ has been shifted to a new line.
Single space replaced with tab space
This is done to maintain code uniformity.
Signed-off-by: Shubhankar Kuranagatti
---
drivers/i2c/i2c-core-smbus.c | 17 ++---
1 file changed, 10 i
https://bugzilla.kernel.org/show_bug.cgi?id=212871
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=212871
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
Note that you don't need to file two bugs.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=212871
--- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) ---
Also filed as: https://gitlab.freedesktop.org/drm/amd/-/issues/1582
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee
Am 28.04.21 um 14:26 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
Am 28.04.21 um 12:05 schrieb Daniel Vetter:
On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
On Tue, Apr 27,
Add bridge connector_attach/detach ops. These ops are called when a
bridge is attached or detached to a drm_connector. These ops can be
used to register and unregister an HDMI CEC adapter for a bridge that
supports CEC.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/drm_bridge_connector.c | 25
Implement the new connector_attach/detach bridge ops. This makes it
possible to associate a CEC adapter with a drm connector, which helps
userspace determine which cec device node belongs to which drm connector.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm
Add HDMI CEC support for OMAP5.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/Kconfig | 8 +
drivers/gpu/drm/omapdrm/Makefile | 1 +
drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 +
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 64 +-
The cec clock is required as well in order to support HDMI CEC,
document this.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomi Valkeinen
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
Switch to using cec_s_phys_addr_from_edid() instead of a two-step process
of calling cec_get_edid_phys_addr() followed by cec_s_phys_addr().
Signed-off-by: Hans Verkuil
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 13 ++---
drivers/gpu/drm/omapdrm/dss/hdmi4_
Add cec clock to the dra7 and omap5 device trees.
Signed-off-by: Hans Verkuil
Acked-by: Tony Lindgren
Reviewed-by: Tomi Valkeinen
---
arch/arm/boot/dts/dra7.dtsi | 5 +++--
arch/arm/boot/dts/omap5.dtsi | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts
This series improves the drm_bridge support for CEC by introducing two
new bridge ops in the first patch, and using those in the second patch.
This makes it possible to call cec_s_conn_info() and set
CEC_CAP_CONNECTOR_INFO for the CEC adapter, so userspace can associate
the CEC adapter with the co
On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
> Am 28.04.21 um 14:26 schrieb Daniel Vetter:
> > On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
> > > > Am 28.04.21 um 12:05 schrieb Daniel Vetter
Am 28.04.21 um 15:34 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
Am 28.04.21 um 14:26 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
Am 28.04.21
On 28/04/2021 05:47, Bjorn Andersson wrote:
On Mon 26 Apr 19:18 CDT 2021, Dmitry Baryshkov wrote:
[..]
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 92fe844b517b..be578fc4e54f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -12
On Wed 28 Apr 08:41 CDT 2021, Dmitry Baryshkov wrote:
> On 28/04/2021 05:47, Bjorn Andersson wrote:
> > On Mon 26 Apr 19:18 CDT 2021, Dmitry Baryshkov wrote:
> > [..]
> > > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > > index 92fe844b517b..be578fc4e54f 100644
> >
On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko Ursulin wrote:
>
> On 28/04/2021 11:16, Daniel Vetter wrote:
> > On Fri, Apr 23, 2021 at 05:31:19PM -0500, Jason Ekstrand wrote:
> > > There's no sense in allowing userspace to create more engines than it
> > > can possibly access via execbuf.
> > >
On 28/04/2021 16:59, Bjorn Andersson wrote:
On Wed 28 Apr 08:41 CDT 2021, Dmitry Baryshkov wrote:
On 28/04/2021 05:47, Bjorn Andersson wrote:
On Mon 26 Apr 19:18 CDT 2021, Dmitry Baryshkov wrote:
[..]
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 92fe844b517
Hi Tony,
Thank you for the patch.
On Wed, Apr 28, 2021 at 12:25:00PM +0300, Tony Lindgren wrote:
> On resume, dispc pm_runtime_force_resume() is not enabling the hardware
> as we pass the pm_runtime_need_not_resume() test as the device is suspended
> with no child devices.
>
> As the resume cont
On 4/28/21 11:24 AM, Neil Armstrong wrote:
[...]
+static int sn65dsi83_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+struct device *dev = &client->dev;
+enum sn65dsi83_model model;
+struct sn65dsi83 *ctx;
+int ret;
+
+ctx = devm_kzalloc(
On 4/28/21 11:49 AM, Jagan Teki wrote:
[...]
I just saw the note in the header of the driver that says that single
link mode is unsupported for the DSI84.
I have hardware with a single link display and if I set
ctx->lvds_dual_link = false it works just fine.
How is this supposed to be selected
On 4/28/21 9:56 AM, Frieder Schrempf wrote:
[...]
+properties:
+ compatible:
+ oneOf:
+ - const: ti,sn65dsi83
+ - const: ti,sn65dsi84
+
+ reg:
+ const: 0x2d
There is a strapping pin to select the last bit of the address, so apart
from 0x2d also 0x2c is valid here.
Fixed, al
On 28/04/2021 15:02, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko Ursulin wrote:
On 28/04/2021 11:16, Daniel Vetter wrote:
On Fri, Apr 23, 2021 at 05:31:19PM -0500, Jason Ekstrand wrote:
There's no sense in allowing userspace to create more engines than it
can possi
On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
> Am 28.04.21 um 15:34 schrieb Daniel Vetter:
> > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
> > > Am 28.04.21 um 14:26 schrieb Daniel Vetter:
> > > > On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote
On Fri, Apr 23, 2021 at 05:31:22PM -0500, Jason Ekstrand wrote:
Maybe explain that you pull this out since with the proto context there
will be two paths to set this, one for proto context, the other for
context already finalized and executing patches?
With that: Reviewed-by: Daniel Vetter
> Si
Am 28.04.21 um 16:34 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
Am 28.04.21 um 15:34 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
Am 28.04.21 um 14:26 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 02:21:5
Until now extracting a card either by physical extraction (e.g. eGPU with
thunderbolt connection or by emulation through syfs ->
/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 B
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
This is exact copy of 'USB: add support for dev_groups to
struct usb_device_driver' patch by Greg but just for
the PCI case.
Signed-off-by: Andrey Grodzovsky
Suggested-by: Greg Kroah-Hartman
---
drivers/pci/pci-driver.c | 1 +
include/linux/pci.h | 3 +++
2 files changed, 4 insertions(+)
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 +--
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 BO
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/
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(-)
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
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 21 -
1 file changed, 16 insertions(+), 5 deleti
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
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 48c407cff112..f
With this calling drm_dev_unplug will flush and block
all in flight IOCTLs
Also, add feature such that if device supports graceful unplug
we enclose entire IOCTL in SRCU critical section.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_ioctl.c | 15 +--
include/drm/drm_drv.
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
Will be used to complete all schedulte fences on device
remove
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_entity.c | 3 ++-
include/drm/gpu_scheduler.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_enti
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
Will be later used block further submissions once device is
removed. Also complete schedule fence if scheduling failed
due to submission blocking.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 13 +++
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
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 31 +++
This allows to remove explicit creation and destruction
of those attrs and by this avoids warnings on device
finilizing post physical device extraction.
v5: Use newly added pci_driver.dev_groups directly
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 17
Access to those must be prevented post pci_remove
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 38 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 28 ++--
drivers/gpu/drm/am
No point calling amdgpu_fence_wait_empty before stopping the
SW scheduler otherwise there is always a chance another job sneaked
in after the wait.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff
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
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 75 +
To allow scoping DRM IOCTLs with drm_dev_enter/exit.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8a19b8dd0
To allow completion and further block of HW accesses post device PCI
remove.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 44 +--
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 26 +++---
2 files changed, 47 insertions(+), 23 deletions
To allow completion and further block of HW accesses post device PCI
remove.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 11 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 26 +++--
drivers/g
To allow completion and further block of HW accesses post device PCI
remove.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
b/drivers/g
Make sure all fecens dependent on HW present are force signaled
when handling device removal. This helpes later to scope all HW
accesing code such as IOCTLs in drm_dev_enter/exit and use
drm_dev_unplug as synchronization point past which we know HW
will not be accessed anymore outside of pci remove
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
To allow completion and further block of HW accesses post device PCI
remove.
Signed-off-by: Andrey Grodzovsky
---
.../amd/display/amdgpu_dm/amdgpu_dm_hdcp.c| 124 +++---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 24 +++-
2 files changed, 98 insertions(+), 50 deletions(-)
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
Am 2021-04-28 um 5:05 a.m. schrieb Christian König:
> Am 28.04.21 um 09:49 schrieb Felix Kuehling:
>> Am 2021-04-28 um 3:04 a.m. schrieb Christian König:
>>> Am 28.04.21 um 07:33 schrieb Felix Kuehling:
SG BOs do not occupy space that is managed by TTM. So do not evict
them.
Thi
On 2021-04-28 11:11 a.m., Andrey Grodzovsky wrote:
Make sure all fecens dependent on HW present are force signaled
when handling device removal. This helpes later to scope all HW
accesing code such as IOCTLs in drm_dev_enter/exit and use
drm_dev_unplug as synchronization point past which we kn
1 - 100 of 212 matches
Mail list logo
