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
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
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
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:
>
>
[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
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
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(+)
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
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
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
>
> ---
>
>
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
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
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
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
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
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
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 --
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
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
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
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
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
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
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
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
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
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:
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
---
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
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")
>
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
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
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
---
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
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
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
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
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
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
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
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
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
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:
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
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:
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
---
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
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
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
>>> + *
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.
>>
>>
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.
>>
>>
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
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
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
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
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
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
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)
? >main_slot : >surfaces_slot;
- WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offset) !=
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=206519
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
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=edit
dmesg after boot
--
You are receiving this mail because:
You are watching the assignee of the bug.
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:
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]
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
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
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)
? >main_slot : >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
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
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
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
> >>
> @@ -311,10 +311,8 @@ qxl_bo_physical_address(struct qxl_device *qdev, struct
> qxl_bo *bo,
> (bo->tbo.mem.mem_type == TTM_PL_VRAM)
> ? >main_slot : >surfaces_slot;
>
> - WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offset) != slot->gpu_offset);
> -
> - /* TODO
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:
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
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?
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).
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
---
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 ++--
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.
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)
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
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:
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
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
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
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:
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()
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
> 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
>
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
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
1 - 100 of 135 matches
Mail list logo
