On Tue, May 4, 2021 at 12:16 PM Marek Olšák wrote:
>
> I see some mentions of XNACK and recoverable page faults. Note that all
> gaming AMD hw that has userspace queues doesn't have XNACK, so there is no
> overhead in compute units. My understanding is that recoverable page faults
> are still s
On Mon, May 03, 2021 at 10:57:44AM -0500, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
First, a bit of commit message please here.
Second I accidentally went down the rabbit hole and ended up at
try_qad_pin().
Your patch looks good, unfortunately my brain is complete mushroom soup
now.
LONTIUM_LT8912B uses "drm_display_mode_to_videomode" from
DRM framework that needs VIDEOMODE_HELPERS to be enabled.
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Reported-by: Michal Suchánek
Signed-off-by: Adrien Grassein
---
drivers/gpu/drm/bridge/Kconfig | 1 +
1 fi
Fixed proposed at:
https://lore.kernel.org/dri-devel/20210504220207.4004511-1-adrien.grass...@gmail.com/T/#u
Thanks,
Le mar. 4 mai 2021 à 21:19, Adrien Grassein
a écrit :
>
> Ok thanks,
>
> I will investigate this.
>
> Le mar. 4 mai 2021 à 21:04, Michal Suchánek a écrit :
> >
> > Hello,
> >
> >
On 05/03, Simon Ser wrote:
> 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_fr
On Tue, May 04, 2021 at 05:41:36PM +0100, Matthew Auld wrote:
> We use some of the lower bits of the retire function pointer for
> potential flags, which is quite thorny, since the caller needs to
> remember to give the function the correct alignment with
> __i915_active_call, otherwise we might in
0-day reports:
drivers/gpu/drm/drm_file.c:789:6: error:
no previous prototype for 'drm_send_event_helper'
Since drm_send_event_helper() is only used locally,
declare it static to fix the problem.
Reported-by: kernel test robot
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/drm_file.
From: Thomas Hellstrom
The SVGA3dCmdDXGenMips command uses a shader-resource view to access
the underlying surface. Normally accesses using that view-type are not
dirtying the underlying surface, but that particular command is an
exception.
Mark the surface gpu-dirty after a SVGA3dCmdDXGenMips co
Now since Christian reworked TTM to always keep objects on the LRU
list unless they are pinned we shouldn't need the reservation
semaphore. It makes the driver code a lot cleaner, especially
because it was a little hard to reason when and where the
reservation semaphore needed to be held.
Signed-o
SVGA_REG_ENABLE is a register name, and SVGA_REG_ENABLE_(ENABLE|
DISABLE|HIDE) are its valid values. We were incorrectly setting
the register value to itself. This happened to work because
the SVGA_REG_ENABLE is happens to to be the same value as
SVGA_REG_ENABLE_ENABLE, but is still semantically in
SVGA3 is the next version of our PCI device. Some of the changes
include using MMIO for register accesses instead of ioports,
deprecating the FIFO MMIO and removing a lot of the old and
legacy functionality. SVGA3 doesn't support guest backed
objects right now so everything except 3D is working.
S
This set includes some lost fixes and adds SVGA v3 and arm64 support
to the driver. SVGA v3 is the next version of our virtual device,
it's largely about making the device a little easier and cleaner
to use (e.g. MMIO for register accesses instead of ioports, adding
MSI-X support, deprecating the F
From: Thomas Hellstrom
In cases where the dirty linear memory range spans multiple sample sheets
in a surface, the dirty surface region is incorrectly computed.
To do this correctly and in an optimized fashion we would have to compute
the dirty region of each sample sheet and compute the union o
This change fixes all of the arm64 issues we've had in the driver.
ARM support is provided in svga version 3, for which support we've added
in previous changes. svga version 3 currently lacks many of the
advanced features (in particular 3D support is lacking) but
that will change in time.
Signed-o
On Wednesday, May 5th, 2021 at 2:14 AM, Rodrigo Siqueira
wrote:
> > As Ville said, if things got this far and the format is unsupported,
> > something
> > must be going wrong. I'm not confident enough to switch this to a WARN_ON,
> > though.
>
> Hi Simon, thanks for your explanation.
>
> Is it
From: Andi Kleen
Newer gcc prints the following warning:
drivers/gpu/drm/i915/intel_pm.c:3057:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
and some other related warnings in similar functions.
gcc has a point here. Some of the latency arr
Hi there,
While browsing an old downstream kernel, I found a patch[0] that enables
sample_c optimizations at Broadwell GPUs. The message from the upstream
commit that enables it for Haswell[1] (and presumably where the code
at[0] was copied from) states that "[..] later platforms remove this
On Tue, 04 May 2021, Andi Kleen wrote:
> From: Andi Kleen
>
> Newer gcc prints the following warning:
>
> drivers/gpu/drm/i915/intel_pm.c:3057:9: warning: ‘intel_print_wm_latency’
> reading 16 bytes from a region of size 10 [-Wstringop-overread]
> and some other related warnings in similar funct
101 - 118 of 118 matches
Mail list logo
