On Fri, Feb 07, 2020 at 04:17:13PM -0500, Alex Deucher wrote:
> Split into init and register functions to avoid a segfault
> in some configs when the load/unload callbacks are removed.
>
> v2:
> - add back accidently dropped has_aux setting
> - set dev in late_register
>
> v3:
> - fix dp cec orde
Hi, Tzung-Bi:
On Thu, 2020-02-13 at 15:59 +0800, Tzung-Bi Shih wrote:
> hdmi_conn_detect and mtk_hdmi_audio_hook_plugged_cb would be called
> by different threads.
>
> Imaging the following calling sequence:
>Thread AThread B
> -
Hi, Matthias:
On Thu, 2020-02-13 at 21:19 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The mmsys block provides registers and clocks for the display
> subsystem. The binding description should therefore live together with
> the rest of the display descriptions. Move it to d
Hi, Bibby:
On Fri, 2020-02-14 at 12:49 +0800, Bibby Hsieh wrote:
> Mediatek CMDQ driver removed atomic parameter and implementation
> related to atomic. DRM driver need to make sure previous message
> done or be aborted before we send next message.
>
> If previous message is still waiting for eve
On Thu, 13 Feb 2020, Nathan Chancellor wrote:
> A recent commit in clang added -Wtautological-compare to -Wall, which is
> enabled for i915 after -Wtautological-compare is disabled for the rest
> of the kernel so we see the following warning on x86_64:
>
> ../drivers/gpu/drm/i915/gem/i915_gem_exe
[AMD Public Use]
Hi Paul,
Thanks for the mail!
I tried to solve this problem by having restriction on sending one msg at a
time due to hub/dock compatibility problems.
>From my experience, some branch devices don't handle well on interleaved
>replies (Dock from HP I think)
As the result of tha
Mediatek CMDQ driver removed atomic parameter and implementation
related to atomic. DRM driver need to make sure previous message
done or be aborted before we send next message.
If previous message is still waiting for event, it means the
setting hasn't been updated into display hardware register,
In order to use GCE function, we need add some information
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16
1 file changed, 16 insertions(+)
diff
According mtk hardware design, stream_done0 and stream_done1 are
generated by mutex, so we move gce event property to mutex device mode.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/medi
Hey Linus,
This week's fixes ready for rc2. The core has a build fix for edid
code on certain compilers/arches/, one MST fix and one vgem fix.
Regular amdgpu fixes, and a couple of small driver fixes. The i915
fixes are bit larger than normal for this stage, but they were having
CI issues last wee
Hi, Matthias:
On Thu, 2020-02-13 at 21:19 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> Switch probing for the MMSYS to support invocation to a
> plain paltform device. The driver will be probed by the DRM subsystem.
>
> Signed-off-by: Matthias Brugger
>
> ---
>
> Change
Hello Rob,
We removed the bridge object for DisplayPort due to review comments in
patch set 1.
Added more details below.
Original Message
Subject: Re: [DPU PATCH v3 3/5] drm/msm/dp: add displayPort driver
support
Date: 2019-12-02 08:48
From: Rob Clark
To: Chandan Uddara
Quoting Andi Shyti (2020-02-11 22:56:44)
> Hi Chris,
>
> On Fri, Feb 07, 2020 at 03:17:20PM +, Chris Wilson wrote:
> > We try hard to select a suitable hole in the drm_mm first time. But if
> > that is unsuccessful, we then have to look at neighbouring nodes, and
> > this requires traversing t
Hi,
On Tue, Feb 11, 2020 at 01:10:07PM +0200, Laurent Pinchart wrote:
> On Tue, Feb 11, 2020 at 01:08:12PM +0200, Tomi Valkeinen wrote:
> > On 11/02/2020 13:07, Laurent Pinchart wrote:
> >
> > >> Hopefully soon (in five years? =) we can say that omapdrm supports all
> > >> the boards, and we can
On Fri, Feb 14, 2020 at 12:30:48AM +0100, Daniel Vetter wrote:
> On Thu, Feb 13, 2020 at 11:39 PM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Feb 13, 2020 at 02:30:09PM -0800, John Hubbard wrote:
> > > On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote:
> > > > When calling debugfs functions, there is no
On Thu, Feb 13, 2020 at 11:39 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Feb 13, 2020 at 02:30:09PM -0800, John Hubbard wrote:
> > On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote:
> > > When calling debugfs functions, there is no need to ever check the
> > > return value. The function can work or not,
On 2/13/20 2:39 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 13, 2020 at 02:30:09PM -0800, John Hubbard wrote:
>> On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote:
>>> When calling debugfs functions, there is no need to ever check the
>>> return value. The function can work or not, but the code logic sh
We'll have to do something like this eventually, and this
conveys we want a Virgl context by default.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virt
For old userspace, initialization will still be implicit.
For backwards compatibility, enqueue virtio_gpu_cmd_context_create after
the first 3D ioctl.
v2: staticify virtio_gpu_create_context
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 --
drivers/gpu/drm/virti
Let's delay enqueuing the context creation command until the first 3D
ioctl, as we add more context types. This series is based on kraxel's
"[PATCH v3 0/4] drm/virtio: rework batching" patches.
Gurchetan Singh (5):
drm/virtio: use consistent names for drm_files
drm/virtio: factor out context
Use an atomic variable to track whether a context has been
initiated.
v2: Fix possible race (@olv)
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++
drivers/gpu/drm/virtio/virtgpu_kms.c | 1 +
3 files changed, 5 in
We currently create an OpenGL context when opening the DRM fd
if 3D is available.
We may need other context types (VK,..) in the future, and the plan
is to have explicit initialization for that.
For explicit initialization to work, we need to factor out
virtio_gpu_create_context from driver initi
Minor cleanup, change:
- file_priv--> file,
- drm_file --> file.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/
On Thu, Feb 13, 2020 at 02:30:09PM -0800, John Hubbard wrote:
> On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do something different based on th
On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
Should we follow that line of reasoning further, and simply re
On Thu, Feb 13, 2020 at 1:41 PM Paolo Bonzini wrote:
>
> On 13/02/20 22:30, Chia-I Wu wrote:
> > Hi,
> >
> > Host GPU drivers like to give userspace WC mapping. When the userspace
> > makes
> > the mapping available to a guest, it also tells the guest to create a WC
> > mapping. However, even w
On Thu, 13 Feb 2020, Nathan Chancellor wrote:
> On Thu, Feb 13, 2020 at 04:37:15PM +0200, Jani Nikula wrote:
>> On Wed, 12 Feb 2020, Michel Dänzer wrote:
>> > On 2020-02-12 6:07 p.m., Nathan Chancellor wrote:
>> >> On Wed, Feb 12, 2020 at 09:52:52AM +0100, Michel Dänzer wrote:
>> >>> On 2020-02-1
Hi,
On Tue, Feb 11, 2020 at 07:22:14PM +0200, Tomi Valkeinen wrote:
> On 11/02/2020 18:27, Tony Lindgren wrote:
> > > We are still missing DSI command mode support, and moving it
> > > to the common DRM model.
> >
> > Nope, DSI command mode support has been working just fine for
> > a while now :
On 13/02/20 22:30, Chia-I Wu wrote:
> Hi,
>
> Host GPU drivers like to give userspace WC mapping. When the userspace makes
> the mapping available to a guest, it also tells the guest to create a WC
> mapping. However, even when the guest kernel picks the correct memory type,
> it gets ignored be
Better reflect the structure of the code and metion why we could not
always honor the guest.
Signed-off-by: Chia-I Wu
Cc: Gurchetan Singh
Cc: Gerd Hoffmann
---
arch/x86/kvm/vmx/vmx.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/
When a memslot has KVM_MEM_DMA set, we want VMX_EPT_IPAT_BIT cleared
for the memslot. Before that is possible, simply call
kvm_arch_register_noncoherent_dma for the memslot.
SVM does not have the ignore-pat bit. Guest PAT is always honored.
Signed-off-by: Chia-I Wu
Cc: Gurchetan Singh
Cc: Ger
When the flag is set, it means the the userspace wants to do DMA
with the memory and the guest will use an appropriate memory type to
access the memory. The kernel should be prepared to honor the
guest's memory type.
Signed-off-by: Chia-I Wu
Cc: Gurchetan Singh
Cc: Gerd Hoffmann
---
Documenta
Hi,
Host GPU drivers like to give userspace WC mapping. When the userspace makes
the mapping available to a guest, it also tells the guest to create a WC
mapping. However, even when the guest kernel picks the correct memory type,
it gets ignored because of VMX_EPT_IPAT_BIT on Intel.
This series
On Thu, Feb 13, 2020 at 3:03 PM Rob Clark wrote:
>
> From: Rob Clark
>
> The component order between the two was swapped, resulting in incorrect
> color when games with 565 visual hit the overlay path instead of GPU
> composition.
>
> Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
> Sign
From: Sean Paul
Currently we have one down reply message servicing the mst manager, so
we need to serialize all tx msgs to ensure we only have one message in
flight at a time. For obvious reasons this is suboptimal (but less
suboptimal than the free-for-all we had before serialization).
This pat
From: Sean Paul
Now that we can support multiple simultaneous replies, remove the
restrictions placed on sending new tx msgs.
This patch essentially just reverts commit
5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time")
now that the problem is solved in a different way.
Cc: Wayne
From: Sean Paul
Hey all,
Earlier this week on my 5.5 kernel (I can't seem to get a 5.6 kernel to
behave on any of my devices), I ran into the multi-reply problem that
Wayne fixed in January. Without realizing there was already a fix
upstream, I went about solving it in different way. It wasn't un
From: Sean Paul
In preparation of per-branch device down message handling, separate
header parsing from message building. This will allow us to peek at
figure out which branch device the message is from before starting to
parse the message contents.
Signed-off-by: Sean Paul
---
drivers/gpu/drm
From: Matthias Brugger
The MMSYS subsystem includes clocks and drm components.
This patch adds an initailization path through a platform device
for the clock part, so that both drivers get probed from the same
device tree compatible.
Signed-off-by: Matthias Brugger
Reviewed-by: Enric Balletbo i
From: Matthias Brugger
Check the return value of of_clk_get and print an error
message if not EPROBE_DEFER.
Signed-off-by: Matthias Brugger
---
Changes in v7:
- fix check of return value of of_clk_get
- fix identation
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a plain
paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
Changes in v7:
- free clk_data->clks as well
- get rid of private data structure
Changes in v6: None
Chang
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a
plain paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
Changes in v7:
- free clk_data->clks as well
- get rid of private data structure
Changes in v6: None
Chang
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a
plain paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
Changes in v7:
- free clk_data->clks as well
- get rid of private data structure
Changes in v6: None
Chang
From: Matthias Brugger
It can happen that the mmsys clock drivers aren't probed before the
platform driver gets invoked. The platform driver used to print a warning
that the driver failed to get the clocks. Omit this error on
the defered probe path.
Signed-off-by: Matthias Brugger
Reviewed-by:
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a
plain paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
Changes in v7:
- add blank line after declaration
- free clk_data->clks as well
- get rid of private data s
From: Matthias Brugger
MediaTek mt7623 uses the mt2701 bindings as fallback.
Document this in the binding description.
Signed-off-by: Matthias Brugger
Acked-by: Rob Herring
---
Changes in v7:
- fix typo in commit message
- add Rob's ack
Changes in v6: None
Changes in v5: None
Changes in v4:
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a
plain paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
Changes in v7:
- free clk_data->clks as well
- get rid of private data structure
Changes in v6: None
Chang
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a
plain paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
Changes in v7:
- free clk_data->clks as well
- get rid of private data structure
Changes in v6: None
Chang
From: Matthias Brugger
The mmsys memory space is shared between the drm and the
clk driver. Use regmap to access it.
Signed-off-by: Matthias Brugger
Reviewed-by: Philipp Zabel
Reviewed-by: CK Hu
---
Changes in v7:
- add R-by from CK
Changes in v6: None
Changes in v5: None
Changes in v4: No
From: Matthias Brugger
This is version seven of the series. The biggest change is, that I added
a first patch that actually moves the mmsys binding from arm/mediatek to
display/mediatek, as in effect the mmsys is part of the display
subsystem.
Since version five, the clock probing is implemented
From: Matthias Brugger
The mmsys block provides registers and clocks for the display
subsystem. The binding description should therefore live together with
the rest of the display descriptions. Move it to display/mediatek.
Signed-off-by: Matthias Brugger
---
Changes in v7:
- move the binding
From: Matthias Brugger
The MediaTek DRM has a block called mmsys, which sets
the routing and enables the different blocks.
This patch adds one line for the mmsys bindings description and changes
the mmsys description to use the generic form of referring to a specific
Soc.
Signed-off-by: Matthias
From: Rob Clark
The component order between the two was swapped, resulting in incorrect
color when games with 565 visual hit the overlay path instead of GPU
composition.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_forma
The old implementation of placing planes on the CRTC while configuring
the planes was naive and relied on the order in which the planes were
configured, enabled, and disabled. The situation where a plane's zpos
was changed on the fly was completely broken. The usual symptoms of
this problem was scr
On 09/12/2019 06:34, CK Hu wrote:
> Hi, Matthias:
>
> On Sat, 2019-12-07 at 23:47 +0100, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> The MMSYS subsystem includes clocks and drm components.
>> This patch adds an initailization path through a platform device
>> for the clock p
On 13/02/2020 13:52, Jyri Sarha wrote:
> On 13/02/2020 12:49, Tomi Valkeinen wrote:
>> On 13/02/2020 12:44, Jyri Sarha wrote:
>>
>>> + /*
>>> + * If a plane on a CRTC changes add all active planes on that
>>> + * CRTC to the atomic state. This is needed for updating the
>>> + * plane
On 09/12/2019 09:51, CK Hu wrote:
> Hi, Matthias:
>
> On Sat, 2019-12-07 at 23:47 +0100, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> Switch probing for the MMSYS to support invocation to a
>> plain paltform device. The driver will be probed by the DRM subsystem.
>>
>> Singed
On 09/12/2019 10:58, Enric Balletbo i Serra wrote:
> Hi Matthias,
>
> On 7/12/19 23:47, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> Switch probing for the MMSYS to support invocation to a plain
>> paltform device. The driver will be probed by the DRM subsystem.
>>
>> Signed-
On 09/12/2019 10:39, Enric Balletbo i Serra wrote:
> Hi Matthias,
>
> On 7/12/19 23:47, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> It can happen that the mmsys clock drivers aren't probed before the
>> platform driver gets invoked. The platform driver used to print a warnin
On Thu, Feb 13, 2020 at 5:22 AM Gerd Hoffmann wrote:
>
> Move virtio_gpu_notify() to higher-level functions for
> virtio_gpu_cmd_create_resource(), virtio_gpu_cmd_resource_create_3d()
> and virtio_gpu_cmd_resource_attach_backing().
>
> virtio_gpu_object_create() will batch commands and notify only
Series is
Reviewed-by: Chia-I Wu
After the series, virtio_gpu_cmd_* may or may not call
virtio_gpu_notify. It is error-prone and should be fixed, such that
virtio_gpu_cmd_* never notifies, or such that different naming
conventions are used for functions that notify and for those don't.
On Th
On 09/12/2019 06:12, CK Hu wrote:
> Hi, Matthias:
>
> On Sat, 2019-12-07 at 23:47 +0100, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> The MediaTek DRM has a block called mmsys, which sets
>> the routing and enalbes the different blocks.
>> This patch adds one line for the mms
On Thu, Feb 13, 2020 at 12:28 PM Christian König
wrote:
>
> Am 13.02.20 um 15:32 schrieb Alex Deucher:
> > On Thu, Feb 13, 2020 at 5:17 AM Christian König
> > wrote:
> >> Am 13.02.20 um 10:54 schrieb Daniel Vetter:
> >>> On Fri, Feb 07, 2020 at 02:50:57PM -0500, Alex Deucher wrote:
> In orde
Am 13.02.20 um 15:32 schrieb Alex Deucher:
On Thu, Feb 13, 2020 at 5:17 AM Christian König
wrote:
Am 13.02.20 um 10:54 schrieb Daniel Vetter:
On Fri, Feb 07, 2020 at 02:50:57PM -0500, Alex Deucher wrote:
In order to remove the load and unload drm callbacks,
we need to reorder the init sequenc
Am 13.02.20 um 15:30 schrieb Gerd Hoffmann:
@@ -311,10 +311,8 @@ qxl_bo_physical_address(struct qxl_device *qdev, struct
qxl_bo *bo,
(bo->tbo.mem.mem_type == TTM_PL_VRAM)
? &qdev->main_slot : &qdev->surfaces_slot;
- WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offs
Anyone want to take a shot at this one?
Alex
On Fri, Feb 7, 2020 at 4:17 PM Alex Deucher wrote:
>
> Split into init and register functions to avoid a segfault
> in some configs when the load/unload callbacks are removed.
>
> v2:
> - add back accidently dropped has_aux setting
> - set dev in late
On Fri, 12 Jul 2019 18:21:17 +0200
Sam Ravnborg wrote:
> Hi Joshua.
>
> On Tue, Jul 09, 2019 at 04:24:49PM +, nicolas.fe...@microchip.com wrote:
> > On 09/07/2019 at 17:35, Joshua Henderson wrote:
> > > This bit enables replication logic to expand an RGB color less than 24
> > > bits, to 2
https://bugzilla.kernel.org/show_bug.cgi?id=206519
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=206519
--- Comment #1 from Shlomo (shl...@fastmail.com) ---
Created attachment 287355
--> https://bugzilla.kernel.org/attachment.cgi?id=287355&action=edit
dmesg after boot
--
You are receiving this mail because:
You are watching the assignee of the b
https://bugzilla.kernel.org/show_bug.cgi?id=206519
Bug ID: 206519
Summary: [amdgpu] kernel NULL pointer dereference on shutdown
Product: Drivers
Version: 2.5
Kernel Version: 5.5.1.arch1-1, 5.5.3-arch1-1
Hardware: All
OS: Li
This beautifies the build log.
[Before]
HOSTCC drivers/gpu/drm/radeon/mkregtable
MKREGTABLE drivers/gpu/drm/radeon/r100_reg_safe.h
MKREGTABLE drivers/gpu/drm/radeon/rn50_reg_safe.h
CC [M] drivers/gpu/drm/radeon/r100.o
MKREGTABLE drivers/gpu/drm/radeon/r300_reg_safe.h
CC [M] drivers
This Makefile repeats similar build rules. Use a pattern rule.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/radeon/Makefile | 29 +
1 file changed, 1 insertion(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
i
if_changed must have FORCE as a prerequisite, and the targets must be
added to 'targets'.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/radeon/Makefile | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu
On 2/13/20 3:30 PM, Gerd Hoffmann wrote:
@@ -311,10 +311,8 @@ qxl_bo_physical_address(struct qxl_device *qdev, struct
qxl_bo *bo,
(bo->tbo.mem.mem_type == TTM_PL_VRAM)
? &qdev->main_slot : &qdev->surfaces_slot;
- WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offset
On Thu, Feb 13, 2020 at 1:48 PM Linus Walleij wrote:
> The last in-kernel user of the old framebuffer driver is the
> IM-PD1 module for the Integrator/AP. Let's implement support for
> this remaining user so we can migrate the last user over to
> DRM and delete the old FB driver.
>
> On the Integr
On Wed, 12 Feb 2020, Michel Dänzer wrote:
> On 2020-02-12 6:07 p.m., Nathan Chancellor wrote:
>> On Wed, Feb 12, 2020 at 09:52:52AM +0100, Michel Dänzer wrote:
>>> On 2020-02-11 9:39 p.m., Nathan Chancellor wrote:
On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
> On 2020-02
On Thu, Feb 13, 2020 at 01:01:57PM +0100, Nirmoy Das wrote:
> With this patch series I am trying to remove GPU address dependency in
> TTM and moving GPU address calculation to individual drm drivers.
> This is required[1] to continue the work started by Brian Welty to create
> struct drm_mem_regio
On Thu, Feb 13, 2020 at 5:17 AM Christian König
wrote:
>
> Am 13.02.20 um 10:54 schrieb Daniel Vetter:
> > On Fri, Feb 07, 2020 at 02:50:57PM -0500, Alex Deucher wrote:
> >> In order to remove the load and unload drm callbacks,
> >> we need to reorder the init sequence to move all the drm
> >> deb
> @@ -311,10 +311,8 @@ qxl_bo_physical_address(struct qxl_device *qdev, struct
> qxl_bo *bo,
> (bo->tbo.mem.mem_type == TTM_PL_VRAM)
> ? &qdev->main_slot : &qdev->surfaces_slot;
>
> - WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offset) != slot->gpu_offset);
> -
> -
Hi,
Missatge de CK Hu del dia dj., 13 de febr. 2020 a les 5:06:
>
> Hi, Bibby:
>
> On Thu, 2020-02-13 at 09:23 +0800, Bibby Hsieh wrote:
> > Besides x, y position, width and height,
> > fb also need updating in async update.
> >
>
> Reviewed-by: CK Hu
>
> > Fixes: 920fffcc8912 ("drm/mediatek: up
On 2/13/20 2:00 PM, Christian König wrote:
Cool, than that is a lot easier to implement than I thought it would be.
I assume you don't have Radeon hardware lying around to test this?
Yes this would be nice I don't have a Radeon hw with me.
If you can you give me a branch on the AMD (or pu
On 2/13/20 2:00 PM, Christian König wrote:
Am 13.02.20 um 13:31 schrieb Nirmoy:
On 2/13/20 1:18 PM, Christian König wrote:
Looks like most of the patch is missing?
We should have quite a number of uses of the BO offset in radeon or
do all of those go through radeon_bo_gpu_offset?
Compilatio
Move virtio_gpu_notify() to higher-level functions for
virtio_gpu_cmd_create_resource(), virtio_gpu_cmd_resource_create_3d()
and virtio_gpu_cmd_resource_attach_backing().
virtio_gpu_object_create() will batch commands and notify only once when
creating a resource.
Signed-off-by: Gerd Hoffmann
--
Move virtio_gpu_notify() to higher-level functions for
virtio_gpu_cmd_resource_flush(), virtio_gpu_cmd_set_scanout() and
virtio_gpu_cmd_transfer_to_host_{2d,3d}().
virtio_gpu_primary_plane_update() will notify only once for a series
of commands (restores plane update command batching).
Signed-off
Move virtio_gpu_notify() to higher-level functions for
virtio_gpu_cmd_get_display_info() and virtio_gpu_cmd_get_edids().
virtio_gpu_config_changed_work_func() and virtio_gpu_init() will
batch commands and notify only once per update
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgp
v4:
- split into multiple patches.
Gerd Hoffmann (4):
drm/virtio: rework notification for better batching
drm/virtio: batch plane updates (pageflip)
drm/virtio: batch resource creation
drm/virtio: batch display query.
drivers/gpu/drm/virtio/virtgpu_drv.h | 6 ++--
drivers/gpu/drm/v
Drop the virtio_gpu_{disable,enable}_notify(). Add a new
virtio_gpu_notify() call instead, which must be called whenever
the driver wants make sure the host is notified needed.
Drop automatic notification from command submission. Add
virtio_gpu_notify() calls after each command query instead.
Th
Am 13.02.20 um 13:31 schrieb Nirmoy:
On 2/13/20 1:18 PM, Christian König wrote:
Looks like most of the patch is missing?
We should have quite a number of uses of the BO offset in radeon or
do all of those go through radeon_bo_gpu_offset?
Compilation worked so I think all those(bo->offset) acc
Hi Ben,
sorry for the delayed response. Haven been rather busy recently.
Am 28.01.20 um 06:49 schrieb Ben Skeggs:
On Sat, 25 Jan 2020 at 00:30, Christian König
wrote:
From: Christian König
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not worki
When roll over detected for seq_num_m, we shouldn't continue with stream
management with rolled over value.
So we are terminating the stream management retry, on roll over of the
seq_num_m.
v2:
using drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
v3:
dev_priv is used as i915 [JaniN]
v4:
ro
The last in-kernel user of the old framebuffer driver is the
IM-PD1 module for the Integrator/AP. Let's implement support for
this remaining user so we can migrate the last user over to
DRM and delete the old FB driver.
On the Integrator/AP the IM-PD1 system controller will exist
alongside the com
On 2/13/20 1:18 PM, Christian König wrote:
Looks like most of the patch is missing?
We should have quite a number of uses of the BO offset in radeon or do
all of those go through radeon_bo_gpu_offset?
Compilation worked so I think all those(bo->offset) accesses went
through radeon_bo_gpu_offs
Am 13.02.20 um 13:01 schrieb Nirmoy Das:
With this patch series I am trying to remove GPU address dependency in
TTM and moving GPU address calculation to individual drm drivers.
This is required[1] to continue the work started by Brian Welty to create
struct drm_mem_region which can be leverage b
Looks like most of the patch is missing?
We should have quite a number of uses of the BO offset in radeon or do
all of those go through radeon_bo_gpu_offset?
If yes then the change is much smaller than I thought i needs to be.
Christian.
Am 13.02.20 um 13:01 schrieb Nirmoy Das:
Signed-off-b
On 13/02/2020 12:49, Tomi Valkeinen wrote:
> On 13/02/2020 12:44, Jyri Sarha wrote:
>
>> + /*
>> + * If a plane on a CRTC changes add all active planes on that
>> + * CRTC to the atomic state. This is needed for updating the
>> + * plane positions in tidss_crtc_position_planes() whi
On 2020-02-12 at 15:59:39 +0530, Ramalingam C wrote:
> Need to extract the 2 most significant bits from a byte for constructing
> the revoked KSV count of the SRM.
>
> Signed-off-by: Ramalingam C
> ---
> include/drm/drm_hdcp.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --g
> 2020年2月13日 18:01，Koenig, Christian 写道：
>
> Am 13.02.20 um 05:11 schrieb Pan, Xinhui:
>>
>>
>>> 2020年2月12日 19:53，Christian König 写道：
>>>
>>> Am 12.02.20 um 07:23 schrieb Pan, Xinhui:
> 2020年2月11日 23:43，Christian König 写道：
>
> When non-imported BOs are resurrected for delayed
On 12/02/2020 20:22, Rob Herring wrote:
> From: Tomeu Vizoso
>
> If the exception type isn't a translation fault, don't try to map and
> instead go straight to a terminal fault.
>
> Otherwise, we can get flooded by kernel warnings and further faults.
>
> Signed-off-by: Tomeu Vizoso
> Signed-of
On 13/02/2020 12:44, Jyri Sarha wrote:
+ /*
+* If a plane on a CRTC changes add all active planes on that
+* CRTC to the atomic state. This is needed for updating the
+* plane positions in tidss_crtc_position_planes() which is
+* called from crtc_atomic_enab
The old implementation of placing planes on the CRTC while configuring
the planes was naive and relied on the order in which the planes were
configured, enabled, and disabled. The situation where a plane's zpos
was changed on the fly was completely broken. The usual symptoms of
this problem was scr
1 - 100 of 135 matches
Mail list logo
