Hi,
what happened to these patches? In thread "[REGRESSION] drm/etnaviv: command
buffer outside valid memory window" [1] it was mentioned these got "shot
down" due to layering violations, but no official correspondence has been
found? Is is due to exporting symbols from mm/cma.c in [1/2] and why i
On 29/04/2021 07:46, Tony Lindgren wrote:
Hi,
* Laurent Pinchart [210428 14:10]:
Based on my experience on the camera and display side with devices that
are made of multiple components, suspend and resume are best handled in
a controlled way by the top-level driver. Otherwise you end up having
Hi,
On Fri, Apr 30, 2021 at 10:44:53AM -0700, Stephen Boyd wrote:
> Quoting Rob Clark (2021-04-30 10:17:39)
> > From: Rob Clark
> >
> > dpu_crtc_atomic_flush() was directly poking it's attached planes in a
> > code path that ended up in dpu_plane_atomic_update(), even if the plane
> > was not inv
Hi Stephen,
On Fri, Apr 30, 2021 at 01:59:39PM -0700, Stephen Boyd wrote:
> Quoting Maxime Ripard (2021-04-13 03:13:18)
> > Hi,
> >
> > This is a follow-up of the discussion here:
> > https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
> >
> > This implements a mechanism t
On Fri, 30 Apr 2021, Jani Nikula wrote:
> On Thu, 29 Apr 2021, Lyude Paul wrote:
>> JFYI Jani and Ben: I will be pushing this patch to drm-misc-next sometime
>> today if there's no objections
>
> Thanks for the heads-up, I think this breaks i915. See my review
> comments elsewhere in the thread.
On Sun, May 02, 2021 at 12:49:46PM +0200, Thomas Zimmermann wrote:
> The pdev field in struct drm_device was recently moved into the legacy
> section. Remove it entirely. References are replaced with upcasts from
> the structure's dev field. This change only affects legacy drivers for
> userspace m
On Mon, 03 May 2021, Jani Nikula wrote:
> On Fri, 30 Apr 2021, Jani Nikula wrote:
>> On Thu, 29 Apr 2021, Lyude Paul wrote:
>>> JFYI Jani and Ben: I will be pushing this patch to drm-misc-next sometime
>>> today if there's no objections
>>
>> Thanks for the heads-up, I think this breaks i915. Se
On Fri, 30 Apr 2021, "Cornij, Nikola" wrote:
> I'll fix the dpcd part to use kHz on Monday
I'd appreciate that, thanks. I think it is the better interface.
> My apologies as well, not only for coming up with the wrong patch in
> first place, but also for missing to CC all the maintainers.
The d
On 01/05/2021 23:00, Sebastian Reichel wrote:
Running a legacy application, which directly uses /dev/fb0
currently results in display not being refreshed when the
application mmaps the memory instead of calling write().
Deferred IO support will also schedule dirty_work with the
damage collected
Hi Hans,
On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote:
> +/**
> + * struct drm_connector_oob_hotplug_event_data: OOB hotplug event data
> + *
> + * Contains data about out-of-band hotplug events, signalled through
> + * drm_connector_oob_hotplug_event().
> + */
> +struct drm_conne
The current calculation based on the required_dma mask can be significantly
off, so that the linear window only overlaps a small part of the DRAM
address space. This can lead to the command buffer being unmappable, which
is obviously bad.
Rework the linear window offset calculation to be based on
* Tomi Valkeinen [210503 08:04]:
> On 29/04/2021 07:46, Tony Lindgren wrote:
> > I think the remaining issue is how dispc should provide services to
> > the other components.
> >
> > If dispc needs to be enabled to provide services to the other modules,
> > maybe there's some better Linux generic
Am Mo., 3. Mai 2021 um 12:24 Uhr schrieb Lucas Stach :
>
> The current calculation based on the required_dma mask can be significantly
> off, so that the linear window only overlaps a small part of the DRAM
> address space. This can lead to the command buffer being unmappable, which
> is obviously
Am 30.04.21 um 17:04 schrieb Matthew Auld:
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
Make sure to allocate a resource object here.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_sys_manager.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/
Am 30.04.21 um 17:02 schrieb Matthew Auld:
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
Similar to the TTM range manager.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_mem.h | 1 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 4
2 files changed, 5 insertions(+
Hi,
* Tony Lindgren [210503 10:45]:
> * Tomi Valkeinen [210503 08:04]:
> > On 29/04/2021 07:46, Tony Lindgren wrote:
> > > Decoupling the system suspend and resume from PM runtime calls for
> > > all the other dss components should still also be done IMO. But that
> > > can be done as a separate
Hi Lucas,
we tested your patch on PHYTEC i.MX6Q phyCORE with 1GiB and 2GiB RAM variants.
I can happily report that the previous issues with "command buffer outside
valid memory window" are gone when using kernel's cmdline parameter cma=256M
for example!
If you want you can add:
Tested-by: Primo
Thanks for the feedback. I got some questions below.
> On Thu, Apr 29, 2021 at 02:05:53PM +0200, Werner Sembach wrote:
>> When encoder validation of a display mode fails, retry with less bandwidth
>> heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
>> to support 4k60Hz out
Let the user know what went wrong in drm_gem_fb_init_with_funcs
failure paths.
v2: use proper format specifier for size_t (kernel test robot)
Signed-off-by: Simon Ser
Reviewed-by: Michel Dänzer
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Noralf Trønnes
Cc: Andrzej Pietrasiewicz
---
drivers/gpu/
On 28/04/2021 8:21 am, 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
> DisplayID block f
* Tony Lindgren [210503 11:16]:
> ..the use of pm_runtime_put_sync() like you suggested. I did a quick
> test with the minimal change below and that works :) Seems like that's
> probably the best minimal fix for the -rc cycle.
Sorry I was mistaken, the patch below won't help for the omapdrm
PM ru
On 05/03, Simon Ser wrote:
> Let the user know what went wrong in drm_gem_fb_init_with_funcs
> failure paths.
>
> v2: use proper format specifier for size_t (kernel test robot)
>
> Signed-off-by: Simon Ser
> Reviewed-by: Michel Dänzer
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Noralf Trønne
On Monday, May 3rd, 2021 at 4:20 PM, Rodrigo Siqueira
wrote:
> > diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > index 109d11fb4cd4..aeb808a0ba54 100644
> > --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > +++ b/drivers/gpu/
On Fri, Apr 23, 2021 at 9:46 PM Robin Murphy wrote:
>
> On 2021-04-22 09:15, Claire Chang wrote:
> > The restricted DMA pool is preferred if available.
> >
> > The restricted DMA pools provide a basic level of protection against the
> > DMA overwriting buffer contents at unexpected times. However,
Include the header for the prototype.
Signed-off-by: Christian König
Reported-by: kernel test robot
---
drivers/gpu/drm/ttm/ttm_sys_manager.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_sys_manager.c
b/drivers/gpu/drm/ttm/ttm_sys_manager.c
index f754d2c965f1..
Hi,
On 5/3/21 10:00 AM, Heikki Krogerus wrote:
> Hi Hans,
>
> On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote:
>> +/**
>> + * struct drm_connector_oob_hotplug_event_data: OOB hotplug event data
>> + *
>> + * Contains data about out-of-band hotplug events, signalled through
>> + * dr
On 2021/05/02 10:53, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 988d0763361bb65690d60e2bc53a6b72777040c3
> Author: Tetsuo Handa
> Date: Sun Sep 27 11:46:30 2020 +
>
> vt_ioctl: make VT_RESIZEX behave like VT_RESIZE
>
That commit is irrelevant. Below is a simplified
On Sat, May 1, 2021 at 6:27 PM Marek Olšák wrote:
>
> On Wed, Apr 28, 2021 at 5:07 AM 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 depend
Sorry for the top-post but there's no good thing to reply to here...
One of the things pointed out to me recently by Daniel Vetter that I
didn't fully understand before is that dma_buf has a very subtle
second requirement beyond finite time completion: Nothing required
for signaling a dma-fence c
Am 03.05.21 um 16:59 schrieb Jason Ekstrand:
Sorry for the top-post but there's no good thing to reply to here...
One of the things pointed out to me recently by Daniel Vetter that I
didn't fully understand before is that dma_buf has a very subtle
second requirement beyond finite time completion
On Mon, May 03, 2021 at 01:39:04PM +0200, Werner Sembach wrote:
> Thanks for the feedback. I got some questions below.
> > On Thu, Apr 29, 2021 at 02:05:53PM +0200, Werner Sembach wrote:
> >> When encoder validation of a display mode fails, retry with less bandwidth
> >> heavy YCbCr420 color mode,
On Mon, May 3, 2021 at 10:03 AM Christian König
wrote:
>
> Am 03.05.21 um 16:59 schrieb Jason Ekstrand:
> > Sorry for the top-post but there's no good thing to reply to here...
> >
> > One of the things pointed out to me recently by Daniel Vetter that I
> > didn't fully understand before is that d
On Mon, May 3, 2021 at 5:00 PM Jason Ekstrand wrote:
>
> Sorry for the top-post but there's no good thing to reply to here...
>
> One of the things pointed out to me recently by Daniel Vetter that I
> didn't fully understand before is that dma_buf has a very subtle
> second requirement beyond fini
On Mon, May 3, 2021 at 10:16 AM Bas Nieuwenhuizen
wrote:
>
> On Mon, May 3, 2021 at 5:00 PM Jason Ekstrand wrote:
> >
> > Sorry for the top-post but there's no good thing to reply to here...
> >
> > One of the things pointed out to me recently by Daniel Vetter that I
> > didn't fully understand b
https://bugzilla.kernel.org/show_bug.cgi?id=212935
Bug ID: 212935
Summary: When my monitors go to standby amdgpu crashes
Product: Drivers
Version: 2.5
Kernel Version: 5.11
Hardware: All
OS: Linux
Tree: Mainlin
Hi All,
Here is v2 of my work on making DP over Type-C work on devices where the
Type-C controller does not drive the HPD pin on the GPU, but instead
we need to forward HPD events from the Type-C controller to the DRM driver.
Changes in v2:
- Replace the bogus "drm/connector: Make the drm_sysfs c
Add a fwnode pointer to struct drm_connector and register an acpi_bus_type
for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled).
The adding of the fwnode pointer allows drivers to associate a fwnode
that represents a connector with that connector.
When the new fwnode pointer p
Give connector sysfs devices there own device_type, this allows us to
check if a device passed to functions dealing with generic devices is
a drm_connector or not.
A check like this is necessary in the drm_connector_acpi_bus_match()
function added in the next patch in this series.
Signed-off-by:
Add a function to find a connector based on a fwnode.
This will be used by the new drm_connector_oob_hotplug_event()
function which is added by the next patch in this patch-set.
Changes in v2:
- Complete rewrite to use a global connector list in drm_connector.c
rather then using a class-dev-ite
Add a new drm_connector_oob_hotplug_event() function and
oob_hotplug_event drm_connector_funcs member.
On some hardware a hotplug event notification may come from outside the
display driver / device. An example of this is some USB Type-C setups
where the hardware muxes the DisplayPort data and aux
On some Cherry Trail devices, DisplayPort over Type-C is supported through
a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
case does the PD/alt-mode negotiation itself, rather then everything being
ha
From: Heikki Krogerus
On Intel platforms we know that the ACPI connector device
node order will follow the order the driver (i915) decides.
The decision is made using the custom Intel ACPI OpRegion
(intel_opregion.c), though the driver does not actually know
that the values it sends to ACPI there
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
---
drivers/usb/typec/altmodes/displayport.c | 35 +---
1 file changed, 13 insertions(+), 22 deletion
Use the new drm_connector_find_by_fwnode() and
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
---
Changes in v2:
- Add missing depends on DRM to TYPEC_DP_ALTMODE Kconfig entry
---
drivers/usb/type
The Type-C connector on these devices is connected to DP-2 not DP-1,
so the reference must be to the DD04 child-node of the GPU, rather
then the DD02 child-node.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/intel_cht_int33fe_typec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Overview:
-
This patch series attempts to clean up some of the IOCTL mess we've created
over the last few years. The most egregious bit being context mutability.
In summary, this series:
1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP
2. Drops the entire CONTEXT_CLONE A
This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
ringsize on construction"). This API was originally added for OpenCL
but the compute-runtime PR has sat open for a year without action so we
can still pull it out if we want. I argue we should drop it for three
reasons:
1.
Previously, we were storing the ring size in the ring pointer before it
was actually allocated. We would then guard setting the ring size on
checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really
only saves us a few bytes on something that already burns at least 4K.
Instead, this
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels. It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support. However, the
libdrm and Bei
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. For years we've had the idea of a watchdog
uAPI floating about. The aim was for media, so that they could set very
tight deadlines for their transcodes jobs, so that if you have a corrupt
bitstream
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git
This API allows one context to grab bits out of another context upon
creation. It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
real userspace. It's used by a few IGT tests and that's it. Since it
doesn't add any
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would he
This has never been used by any userspace except IGT and provides no
real functionality beyond parroting back parameters userspace passed in
as part of context creation or via setparam. If the context is in
legacy mode (where you use I915_EXEC_RENDER and friends), it returns
success with zero data
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 the balanced engine only has one engine in the
sibling set. This doesn't actually result in a virtual engine.
This functionality was orig
Even though FENCE_SUBMIT is only documented to wait until the request in
the in-fence starts instead of waiting until it completes, it has a bit
more magic than that. If FENCE_SUBMIT is used to submit something to a
balanced engine, we would wait to assign engines until the primary
request was rea
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 ---
drivers/gpu/drm/i915/i915
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
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 ourselves anything here. We're about to make context
lookup a tiny bit
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43 ---
2 files changed, 3
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other.
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_con
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
.../gpu/drm/i915/gem/selftests/mock_con
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
drivers/g
There's a big comment saying how useful it is but no one is using this
for anything anymore.
It was added in 2bfa996e031b ("drm/i915: Store owning file on the
i915_address_space") and used for debugfs at the time as well as telling
the difference between the global GTT and a PPGTT. In f6e8aa38717
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 267 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
4 files changed, 1
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 304
1 file changed, 304 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ad6e98d8a4fbd..6e5828fe1a792 100644
--- a/drive
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests/mock_contex
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed,
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us get rid of the complex VM setting code.
Signed-off-by: Jason
Hi Christian,
On 4/30/21 11:25 AM, Christian König wrote:
Instead of both driver and TTM allocating memory finalize embedding the
ttm_resource object as base into the driver backends.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 44 ++
drive
From: Jared Baldridge
[ Upstream commit 81ad7f9f78e4ff80e95be8282423f511b84f1166 ]
The OneGX1 Pro has a fairly unique combination of generic strings,
but we additionally match on the BIOS date just to be safe.
Signed-off-by: Jared Baldridge
Reviewed-by: Hans de Goede
Signed-off-by: Hans de Go
From: Tong Zhang
[ Upstream commit b91907a6241193465ca92e357adf16822242296d ]
if qxl_device_init() fail, drm device will not be registered,
in this case, do not run qxl_drm_release()
[5.258534]
==
[5.258931] BUG: KASAN: us
From: Gerd Hoffmann
[ Upstream commit 4ca77c513537700d3fae69030879f781dde1904c ]
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas Zimmermann
Link:
http://patchwork.freedesktop.org/patch/msgid/20210204145712.1531203-6-kr
From: Thomas Zimmermann
[ Upstream commit ee4a92d690f30f3793df942939726bec0338e65b ]
Use AST_MAX_HWC_HEIGHT for setting offset_y in the cursor plane's
atomic_check. The code used AST_MAX_HWC_WIDTH instead. This worked
because both constants has the same value.
Signed-off-by: Thomas Zimmermann
From: Martin Leung
[ Upstream commit efe213e5a57e0cd92fa4f328dc1963d330549982 ]
[Why]
Hardware team remeasured, need to update timings
to increase latency slightly and avoid intermittent
underflows.
[How]
sr exit latency update.
Signed-off-by: Martin Leung
Reviewed-by: Alvin Lee
Acked-by: Qi
From: Nicholas Kazlauskas
[ Upstream commit 737b2b536a30a467c405d75f2287e17828838a13 ]
[Why]
Color corruption can occur on bootup into a login
manager that applies a non-linear gamma LUT because
the LUT may not actually be powered on before writing.
It's cleared on the next full pipe reprogramm
From: Tong Zhang
[ Upstream commit dc739820ff90acccd013f6bb420222978a982791 ]
a connector is leaked upon module unload, it seems that we should do
similar to sample driver as suggested in drm_drv.c.
Adding drm_atomic_helper_shutdown() in ast_pci_remove to prevent leaking.
[ 153.822134] WARNIN
From: Huang Rui
[ Upstream commit ca1203d7d7295c49e5707d7def457bdc524a8edb ]
We should commit the value after restore them back to default as well.
$ echo "r" > pp_od_clk_voltage
$ echo "c" > pp_od_clk_voltage
Signed-off-by: Huang Rui
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Si
From: Eryk Brol
[ Upstream commit 349a19b2f1b01e713268c7de9944ad669ccdf369 ]
[why]
This check for ASIC revision is no longer useful and causes
lightup issues after a topology change in MST DSC scenario.
In this case, DSC configs should be recalculated for the new
topology. This check prevented t
From: Aric Cyr
[ Upstream commit 6ad98e8aeb0106f453bb154933e8355849244990 ]
[Why]
There is a window of time where we optimize bandwidth due to no streams
enabled will enable PSTATE changing but HUBPs are not disabled yet.
This results in underflow counter increasing in some hotplug scenarios.
[
From: Wyatt Wood
[ Upstream commit 8039bc7130ef4206a58e4dc288621bc97eba08eb ]
[Why]
GPINT timeout is causing PSR_STATE_0 to be returned when it shouldn't.
We must guarantee that PSR is fully disabled before doing hw programming
on driver-side.
[How]
Return invalid state if GPINT command times o
From: Xiaogang Chen
[ Upstream commit b6f91fc183f758461b9462cc93e673adbbf95c2d ]
amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT interrupt(hpd, hpd_rx) by using work
queue and uses single work_struct. If new interrupt is recevied before the
previous handler finished, new interrupts(same type) will b
From: Lee Jones
[ Upstream commit 3e3527f5b765c6f479ba55e5a570ee9538589a74 ]
Fixes the following W=1 kernel build warning(s):
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59:
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:100
From: Arunpravin
[ Upstream commit d8cce9306801cfbf709055677f7896905094ff95 ]
Remove unnecessary comments, enable restore mode using
'|=' operator, fixes the alignment to improve the code
readability.
v2: Move all restoration flag check to bitwise '&' operator
Signed-off-by: Arunpravin
Review
From: Emily Deng
[ Upstream commit bb0cd09be45ea457f25fdcbcb3d6cf2230f26c46 ]
When unloading driver after killing some applications, it will hit sdma
flush tlb job timeout which is called by ttm_bo_delay_delete. So
to avoid the job submit after fence driver fini, call
ttm_bo_lock_delayed_workqu
From: xndcn
[ Upstream commit 377f8331d0565e6f71ba081c894029a92d0c7e77 ]
virtio_gpu_object array is not freed or unlocked in some
failed cases.
Signed-off-by: xndcn
Link:
http://patchwork.freedesktop.org/patch/msgid/20210305151819.14330-1-xnd...@gmail.com
Signed-off-by: Gerd Hoffmann
Signed-
From: Kenneth Feng
[ Upstream commit 0979d43259e13846d86ba17e451e17fec185d240 ]
Workload number mapped to the correct one.
This issue is only on vega10.
Signed-off-by: Kenneth Feng
Reviewed-by: Kevin Wang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/pow
From: Obeida Shamoun
[ Upstream commit cdfd4c689e2a52c313b35ddfc1852ff274f91acb ]
WLED3_SINK_REG_SYNC is, as the name implies, a sink register offset.
Therefore, use the sink address as base instead of the ctrl address.
This fixes the sync toggle on wled4, which can be observed by the fact
that
From: Philip Yang
[ Upstream commit b672cb1eee59efe6ca5bb2a2ce90060a22860558 ]
If xnack is on, VM retry fault interrupt send to IH ring1, and ring1
will be full quickly. IH cannot receive other interrupts, this causes
deadlock if migrating buffer using sdma and waiting for sdma done while
handli
From: Kiran Gunda
[ Upstream commit 4d6e9cdff7fbb6bef3e5559596fab3eeffaf95ca ]
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after
an FSC update.
On WLED5 we should only toggle the MOD_SYNC bit after a brightness
upd
From: Jonathan Kim
[ Upstream commit 4ac5617c4b7d0f0a8f879997f8ceaa14636d7554 ]
The psp supplies the link type in the upper 2 bits of the psp xgmi node
information num_hops field. With a new link type, Aldebaran has these
bits set to a non-zero value (1 = xGMI3) so the KFD topology will report
From: Anson Jacob
[ Upstream commit 6a30a92997eee49554f72b462dce90abe54a496f ]
[Why]
dc_cursor_position do not initialise position.translate_by_source when
crtc or plane->state->fb is NULL. UBSAN caught this error in
dce110_set_cursor_position, as the value was garbage.
[How]
Initialise dc_curs
From: Alex Sierra
[ Upstream commit 9a9c59a8f4f4478d5951eb0bded1d17b936aad6e ]
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: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu
From: Qingqing Zhuo
[ Upstream commit 51ba691206e35464fd7ec33dd519d141c80b5dff ]
[Why]
vblank_workqueue is never released.
[How]
Free it upon dm finish.
Tested-by: Daniel Wheeler
Signed-off-by: Qingqing Zhuo
Reviewed-by: Nicholas Kazlauskas
Acked-by: Solomon Chiu
Signed-off-by: Alex Deuche
From: xinhui pan
[ Upstream commit 79fcd446e7e182c52c2c808c76f8de3eb6714349 ]
drm_gem_object_put() should be paired with drm_gem_object_lookup().
All gem objs are saved in fb->base.obj[]. Need put the old first before
assign a new obj.
Trigger VRAM leak by running command below
$ service gdm r
From: Dmytro Laktyushkin
[ Upstream commit 8ee0fea4baf90e43efe2275de208a7809f9985bc ]
Incorrect variable used, missing initialization during validation.
Tested-by: Daniel Wheeler
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Eric Bernstein
Acked-by: Solomon Chiu
Signed-off-by: Alex Deucher
1 - 100 of 246 matches
Mail list logo
