Am 08.11.21 um 19:57 schrieb Amanoel Dawod:
Hi,
On Mon, Nov 1, 2021, at 10:15 AM, Thomas Zimmermann wrote:
Add destination-buffer pitch as argument to drm_fb_swab(). Done for
consistency with the rest of the interface.
v2:
* update documentation (Noralf)
Signed-off-by: Thomas Zimmer
On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
> We plan to add a new vsock transport based on hypercall (e.g. vmcall on Intel
> CPUs).
> It transports AF_VSOCK packets between the guest and host, which is similar to
> virtio-vsock, vmci-vsock and hyperv-vsock.
>
> Compared to the a
Enable FB_DAMAGE_CLIPS with simpledrm for improved performance and/or
less overhead. With this in place, add support for virtual screens
(i.e., framebuffers that are larger than the display resolution). This
also enables fbdev panning and page flipping.
After the discussion and bug fixing wrt to f
Add additional information on the semantics of the size fields in
struct drm_mode_config. Also add a TODO to review all driver for
correct usage of these fields.
Signed-off-by: Thomas Zimmermann
Acked-by: Noralf Trønnes
---
Documentation/gpu/todo.rst| 15 +++
include/drm/drm_mod
Move destination-buffer clipping from format-helper blit function into
caller. Rename drm_fb_blit_rect_dstclip() to drm_fb_blit_toio(). Done for
consistency with the rest of the interface. Remove drm_fb_blit_dstclip(),
which isn't required.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Noralf Trø
Allocating a shadow buffer of the height of the buffer object does
not support fbdev overallocation. Use surface height instead.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
Enable the FB_DAMAGE_CLIPS property to reduce display-update
overhead. Also fixes a warning in the kernel log.
simple-framebuffer simple-framebuffer.0: [drm]
drm_plane_enable_fb_damage_clips() not called
Fix the computation of the blit rectangle. This wasn't an issue so
far, as simpledrm alway
Add constants for the maximum size of the shadow-plane surface
size. Useful for shadow planes with virtual screen sizes. The
current sizes are 4096 scanlines with 4096 pixels each. This
seems reasonable for current hardware, but can be increased as
necessary.
In simpledrm, set the maximum framebuf
Move destination-buffer clipping from all format-helper memcpy
function into callers. Support destination-buffer pitch. Only
distinguish between system and I/O memory, but use same logic
everywhere.
Signed-off-by: Thomas Zimmermann
Tested-by: Noralf Trønnes
Reviewed-by: Noralf Trønnes
---
driv
Add destination-buffer pitch as argument to drm_fb_swab(). Done for
consistency with the rest of the interface.
v2:
* update documentation (Noralf)
Signed-off-by: Thomas Zimmermann
Tested-by: Noralf Trønnes
Reviewed-by: Noralf Trønnes
---
drivers/gpu/drm/drm_format_helper.c | 21 +
Move destination-buffer clipping from all format-helper conversion
functions into callers. Support destination-buffer pitch. Only
distinguish between system and I/O memory, but use same logic
everywhere.
Simply harmonize the interface and semantics of the existing code.
Not all conversion helpers
Provide a function that computes the offset into a blit destination
buffer. This will allow to move destination-buffer clipping into the
format-helper callers.
v2:
* provide documentation (Sam)
* return 'unsigned int' (Sam, Noralf)
Signed-off-by: Thomas Zimmermann
Reviewed-by: No
On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
> Hi,
>
>
>
> We plan to add a new vsock transport based on hypercall (e.g. vmcall on Intel
> CPUs).
>
> It transports AF_VSOCK packets between the guest and host, which is similar to
>
> virtio-vsock, vmci-vsock and hyperv-vsock.
>
On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
Hi,
We plan to add a new vsock transport based on hypercall (e.g. vmcall on Intel
CPUs).
It transports AF_VSOCK packets between the guest and host, which is similar to
virtio-vsock, vmci-vsock and hyperv-vsock.
Compared to the above
Den 10.11.2021 11.37, skrev Thomas Zimmermann:
> Enable the FB_DAMAGE_CLIPS property to reduce display-update
> overhead. Also fixes a warning in the kernel log.
>
> simple-framebuffer simple-framebuffer.0: [drm]
> drm_plane_enable_fb_damage_clips() not called
>
> Fix the computation of the
Hi
Am 10.11.21 um 13:34 schrieb Noralf Trønnes:
Den 10.11.2021 11.37, skrev Thomas Zimmermann:
Enable the FB_DAMAGE_CLIPS property to reduce display-update
overhead. Also fixes a warning in the kernel log.
simple-framebuffer simple-framebuffer.0: [drm]
drm_plane_enable_fb_damage_clips()
On Mon, Nov 08, 2021 at 10:47:40PM +0800, Xuan Zhuo wrote:
> On Mon, 8 Nov 2021 08:49:27 -0500, Michael S. Tsirkin wrote:
> >
> > Hmm a bunch of comments got ignored. See e.g.
> > https://lore.kernel.org/r/20211027043851-mutt-send-email-mst%40kernel.org
> > if they aren't relevant add code comment
On Wed, Nov 10, 2021 at 07:53:49AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 08, 2021 at 10:47:40PM +0800, Xuan Zhuo wrote:
> > On Mon, 8 Nov 2021 08:49:27 -0500, Michael S. Tsirkin
> > wrote:
> > >
> > > Hmm a bunch of comments got ignored. See e.g.
> > > https://lore.kernel.org/r/202110270
On Mon, Sep 13, 2021 at 05:55:58PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The AP Jump Table under SEV-ES contains the reset vector where non-boot
> CPUs start executing when coming out of reset. This means that a CPU
> coming out of the AP-reset-hold VMGEXIT also needs to start execu
Hi Linus,
usually this would have went via the vhost tree, but as this patch depends
on some patches that just went in via Andrews tree and MST doesn't have
any other patches for this merge window, I'm sending it myself
and base it on current mainline that contains the relevant commits
already. Th
On Tue, Nov 09, 2021 at 01:57:31PM -0800, Joe Perches wrote:
> On Tue, 2021-11-09 at 00:58 +, Nadav Amit wrote:
> > > On Nov 8, 2021, at 4:37 PM, Joe Perches wrote:
> > > On Mon, 2021-11-08 at 16:22 -0800, Srivatsa S. Bhat wrote:
> > >
> > > So it's an exploder not an actual maintainer and it
> On Nov 10, 2021, at 9:20 AM, Srivatsa S. Bhat wrote:
>
> On Tue, Nov 09, 2021 at 01:57:31PM -0800, Joe Perches wrote:
>> On Tue, 2021-11-09 at 00:58 +, Nadav Amit wrote:
On Nov 8, 2021, at 4:37 PM, Joe Perches wrote:
On Mon, 2021-11-08 at 16:22 -0800, Srivatsa S. Bhat wrote:
>>
On Wed, Nov 10, 2021 at 05:40:09PM +, Nadav Amit wrote:
>
>
> > On Nov 10, 2021, at 9:20 AM, Srivatsa S. Bhat
> > wrote:
> >
> > On Tue, Nov 09, 2021 at 01:57:31PM -0800, Joe Perches wrote:
> >> On Tue, 2021-11-09 at 00:58 +, Nadav Amit wrote:
> On Nov 8, 2021, at 4:37 PM, Joe Per
This series updates a few maintainer entries for VMware-maintained
subsystems and cleans up references to VMware's private mailing lists
to make it clear that they are effectively email-aliases to reach out
to reviewers.
Changes from v1->v3:
- Add Zack as the named maintainer for vmmouse driver
-
From: Srivatsa S. Bhat (VMware)
Deep has decided to transfer maintainership of the VMware hypervisor
interface to Srivatsa, and the joint-maintainership of paravirt ops in
the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file
to reflect this change.
Signed-off-by: Srivatsa S. Bhat
From: Srivatsa S. Bhat (VMware)
Zack Rusin will be taking over the maintainership of the VMware
vmmouse driver. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware)
Acked-by: Zack Rusin
Cc: linux-graphics-maintai...@vmware.com
Cc: pv-driv...@vmware.com
C
From: Srivatsa S. Bhat (VMware)
VMware mailing lists in the MAINTAINERS file are private lists meant
for VMware-internal review/notification for patches to the respective
subsystems. Anyone can post to these addresses, but there is no public
read access like open mailing lists, which makes them m
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
> From: Srivatsa S. Bhat (VMware)
>
> Deep has decided to transfer maintainership of the VMware hypervisor
> interface to Srivatsa, and the joint-maintainership of paravirt ops in
> the Linux kernel to Srivatsa and Alexey. Update t
On Wed, 10 Nov 2021 07:53:44 -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 08, 2021 at 10:47:40PM +0800, Xuan Zhuo wrote:
> > On Mon, 8 Nov 2021 08:49:27 -0500, Michael S. Tsirkin
> > wrote:
> > >
> > > Hmm a bunch of comments got ignored. See e.g.
> > > https://lore.kernel.org/r/20211027043851
On Wednesday, November 10, 2021 6:50 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 10, 2021 at 07:12:36AM +, Wang, Wei W wrote:
>
> hypercalls are fundamentally hypervisor dependent though.
Yes, each hypervisor needs to support it.
We could simplify the design and implementation to the minimal,
30 matches
Mail list logo
