Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH 2/2] drm: rcar-du: Use %p4cc to print 4CC format
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Thu, Aug 25, 2022 at 11:39:05AM +0100, Biju Das wrote:
> > Replace use of struct rcar_du_format_info with %p4cc for printing 4CC
> > form
On 26/08/2022 22:24, Lucas Stach wrote:
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
>
> Signed-off-by: Lucas Stach
> Tested-by: Marek Vasut
What tested-by means in the terms of bindings? What tests were applied
e
On 26/08/2022 22:24, Lucas Stach wrote:
> Add binding for the i.MX8MP HDMI parallel video interface block.
>
> Signed-off-by: Lucas Stach
> Tested-by: Marek Vasut
Same question - how was it tested? This is v1, right?
Rest looks good, except Laurent's comments.
Best regards,
Krzysztof
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. Besides cleaner code in driver
side this also allows adding struct device to vfio_device as the first
step toward adding cdev uAPI in the future. Another benefit is that
user can now look
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. This is also a preparatory
step for adding struct device into vfio_device.
New pair of helpers together with a kref in vfio_device:
- vfio_alloc_device()
- vfio_put_device()
Drivers c
From: Yi Liu
Also introduce two pci core helpers as @init/@release for pci drivers:
- vfio_pci_core_init_dev()
- vfio_pci_core_release_dev()
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/vfio/pci/vfio_pci.c | 20 +-
drivers/vfio/pci/vfio_pci_core.c | 35 +
From: Yi Liu
mlx5 has its own @init/@release for handling migration cap.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/vfio/pci/mlx5/main.c | 49 ++--
1 file changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/vfio/pci/mlx5/main.c b/d
From: Yi Liu
Tidy up @probe so all migration specific initialization logic is moved
to migration specific @init callback.
Remove vfio_pci_core_{un}init_device() given no user now.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
.../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 80 +
From: Yi Liu
and manage mdpy_count inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
samples/vfio-mdev/mdpy.c | 81 +++-
1 file changed, 47 insertions(+), 34 deletions(-)
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/md
From: Yi Liu
and manage available ports inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
samples/vfio-mdev/mtty.c | 67 +++-
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-md
From: Yi Liu
and manage avail_mbytes inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
samples/vfio-mdev/mbochs.c | 73 --
1 file changed, 46 insertions(+), 27 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mde
From: Yi Liu
Export symbol of vfio_release_device_set() so fsl-mc @init can handle
the error path cleanly instead of assuming certain vfio core API can
help release device_set afterwards.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 87 ++
Move vfio_device to the start of intel_vgpu as required by the new
helpers.
Change intel_gvt_create_vgpu() to use intel_vgpu as the first param
as other vgpu helpers do.
Signed-off-by: Kevin Tian
---
drivers/gpu/drm/i915/gvt/gvt.h | 5 ++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 52 ++
From: Yi Liu
and manage available_instances inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/s390/crypto/vfio_ap_ops.c | 50 ++-
1 file changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/d
Move vfio_device_ops from platform core to platform drivers so device
specific init/cleanup can be added.
Introduce two new helpers vfio_platform_init/release_common() for the
use in driver @init/@release.
vfio_platform_probe/remove_common() will be deprecated.
Signed-off-by: Kevin Tian
---
dr
Implement amba's own vfio_device_ops.
Remove vfio_platform_probe/remove_common() given no user now.
Signed-off-by: Kevin Tian
---
drivers/vfio/platform/vfio_amba.c | 72 ++-
drivers/vfio/platform/vfio_platform_common.c | 50 -
drivers/vfio/platform/vfio_
ccw is the only exception which cannot use vfio_alloc_device() because
its private device structure is designed to serve both mdev and parent.
Life cycle of the parent is managed by css_driver so vfio_ccw_private
must be allocated/freed in css_driver probe/remove path instead of
conforming to vfio
With the addition of vfio_put_device() now the names become confusing.
vfio_put_device() is clear from object life cycle p.o.v given kref.
vfio_device_put()/vfio_device_try_get() are helpers for tracking
users on a registered device.
Now rename them:
- vfio_device_put() -> vfio_device_put_regi
From: Yi Liu
and replace kref. With it a 'vfio-dev/vfioX' node is created under the
sysfs path of the parent, indicating the device is bound to a vfio
driver, e.g.:
/sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
It is also a preparatory step toward adding cdev for supporting future
devi
This missed a Suggested-by from Jason. Will add in next version.
> From: Tian, Kevin
> Sent: Sunday, August 28, 2022 1:11 AM
>
> ccw is the only exception which cannot use vfio_alloc_device() because
> its private device structure is designed to serve both mdev and parent.
> Life cycle of the pa
"Michael Kelley (LINUX)" writes:
> From: Vitaly Kuznetsov Sent: Thursday, August 25, 2022
> 2:00 AM
>>
>> vmbus_reserve_fb() tries reserving framebuffer region iff
>> 'screen_info.lfb_base' is set. Gen2 VMs seem to have it set by EFI fb
>
> Just so I'm clear, by "EFI fb" you mean the EFI layer
"Michael Kelley (LINUX)" writes:
> From: Vitaly Kuznetsov Sent: Thursday, August 25, 2022
> 2:00 AM
>>
>> Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
>> DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
>>
>> $ cat /proc/iomem
>> ...
>> f80
vmbus_reserve_fb() tries reserving framebuffer region iff
'screen_info.lfb_base' is set. Gen2 VMs seem to have it set by EFI
and/or by the kernel EFI FB driver (or, in some edge cases like kexec,
the address where the buffer was moved, see
https://lore.kernel.org/all/20201014092429.1415040-1-kas...
There are already three places in kernel which define PCI_VENDOR_ID_MICROSOFT
and two for PCI_DEVICE_ID_HYPERV_VIDEO and there's a need to use these
from core Vmbus code. Move the defines where they belong.
No functional change.
Reviewed-by: Michael Kelley
Acked-by: Bjorn Helgaas # pci_ids.h
Si
Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
$ cat /proc/iomem
...
f800-fffb : PCI Bus :00
f800-fbff : :00:08.0
f800-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
.
Changes since v2:
- Add Michael's R-b tags to PATCHes1-3 and Bjorn's A-b tag to PATCH1.
- Commit messages tweaks [Michael].
Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
$ cat /proc/iomem
...
f800
https://bugzilla.kernel.org/show_bug.cgi?id=216143
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #301197|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=216143
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
https://bugzilla.kernel.org/show_bug.cgi?id=216143
--- Comment #14 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Erhard F. from comment #13)
> I'll close here as it's clear this is not strictly an AMD driver issue.
Not really clear; there could be buggy amdgpu driver code, which happen
https://bugzilla.kernel.org/show_bug.cgi?id=216143
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resol
(one more time without forgetting dri-devel this time)
Hi Dave,
A few fixes for the v6.0 cycle. I meant to send this a bit earlier
but ended up at the bottom of other rabbit holes. Summary below (and
in tag msg)
The following changes since commit cb77085b1f0a86ef9dfba86b5f3ed6c3340c2ea3:
dr
Den 26.08.2022 16.56, skrev Dom Cobley:
> On Fri, 26 Aug 2022 at 05:08, Mateusz Kwiatkowski wrote:
>> - Commenting out the pm_runtime_put() / pm_runtime_get_sync() calls in
>> vc4_vec.c
>> - Reverting this PR by Dom Cobley a.k.a. popcornmix:
>>https://github.com/raspberrypi/linux/pull/4639
On Fri, Aug 26, 2022 at 2:43 AM Dmitry Baryshkov
wrote:
>
> On 23/08/2022 14:54, Jilin Yuan wrote:
> > Delete the redundant word 'one'.
>
> The whitespace is unnecessary.
>
> >
> > Signed-off-by: Jilin Yuan
>
> Reviewed-by: Dmitry Baryshkov
> Fixes: 7198e6b03155 ("drm/msm: add a3xx gpu support
The pull request you sent on Fri, 26 Aug 2022 20:29:35 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/fbdev-for-6.0-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/89b749d8552d78c4dd86dea86e2e6ba8aafab9fe
Thank you!
--
Deet
Hi Biju,
On Sat, Aug 27, 2022 at 09:04:25AM +, Biju Das wrote:
> Subject: Re: [PATCH 2/2] drm: rcar-du: Use %p4cc to print 4CC format
> > On Thu, Aug 25, 2022 at 11:39:05AM +0100, Biju Das wrote:
> > > Replace use of struct rcar_du_format_info with %p4cc for printing 4CC
> > > formats.
> >
>
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v5 2/2] drm: rcar-du: Add RZ/G2L DSI driver
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Thu, Aug 25, 2022 at 02:42:29PM +0100, Biju Das wrote:
> > This driver supports the MIPI DSI encoder found in the RZ/G2L SoC. It
> > currently
Hi Biju,
On Sat, Aug 27, 2022 at 07:07:20PM +, Biju Das wrote:
> Subject: Re: [PATCH v5 2/2] drm: rcar-du: Add RZ/G2L DSI driver
> > On Thu, Aug 25, 2022 at 02:42:29PM +0100, Biju Das wrote:
> > > This driver supports the MIPI DSI encoder found in the RZ/G2L SoC. It
> > > currently supports DS
Clean up punctuation, spelling, and formatting for command line usage
and modprobe config file usage in udlfb.rst.
Signed-off-by: Randy Dunlap
Cc: Bernie Thompson
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Helge Deller
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.
Hi,
just sending the original Niranjana's patch as an RFC. It's v3 as
the v2 has been reviewed offline with Ramalingam.
I'm still keeping most of the structure even though some further
discussion can be done starting from here.
Copy pasting Niranjana's original cover letter message:
DRM_I915_GE
From: Niranjana Vishwanathapura
At vm creation time, add a flag to indicate that the new vm will use
vm_bind only for object binding.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 -
driv
From: Niranjana Vishwanathapura
To reuse i915_gem_object_max_page_size() in upcoming
implementation, expose it in i915_gem_object.h
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 16 +
From: Niranjana Vishwanathapura
Implement the bind and unbind of an object at the specified GPU virtual
addresses.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile
From: Niranjana Vishwanathapura
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for shared BOs, in the exec
From: Niranjana Vishwanathapura
VM private BOs can be only mapped on specified VM and cannot be dmabuf
exported.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 ++
1 file changed, 6 inserti
From: Niranjana Vishwanathapura
Do not support the vm in vm_bind_mode in execbuf2 ioctl.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/
From: Niranjana Vishwanathapura
Treat VM_BIND vmas as persistent across execbuf ioctl calls and handle
them during the request submission in the execbuff path.
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission.
Signed-off-by: Niranjana Vishwa
From: Niranjana Vishwanathapura
To reuse i915_gem_vm_lookup in upcoming implementation, expose it in
i915_gem_context.h
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ++-
drivers/gpu
From: Niranjana Vishwanathapura
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have bee
From: Niranjana Vishwanathapura
Add support for handling out fence of vm_bind call.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 3 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 82
From: Niranjana Vishwanathapura
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 200 +-
From: Niranjana Vishwanathapura
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/
From: Niranjana Vishwanathapura
Add ioctls to enable the vm_bind and vm_unbind feature
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_driver.c | 2 ++
include/uapi/drm/i915_drm.h| 4
2 files changed, 6
From: Niranjana Vishwanathapura
Add the uapi for the implemented execbuf3 ioctl to present it for
userspace. This ioctl can be used only for vm_bind mode and vm_binded
batchbuffers can be submitted only through execbuf3 ioctl.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
From: Niranjana Vishwanathapura
vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing (ie., multiple
bindings to the same section of the object).
Skip vma_lookup for persistent vmas as it supports aliasing.
Signed-off-by: Niranjana Vishwana
From: Niranjana Vishwanathapura
Add getparam support for VM_BIND capability version support.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_getparam.c | 3 +++
include/uapi/drm/i915_drm.h | 21 +++
From: Niranjana Vishwanathapura
Add i915_vma_is_bind_complete() to check if the binding of a
of the VM of a specific VMA is complete.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_vma.c | 28 ++
On 8/22/2022 10:53 AM, Dmitry Baryshkov wrote:
On 15/07/2022 00:54, Abhinav Kumar wrote:
On 7/12/2022 6:22 AM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DS
lkp reported some warnings below. I'll got them fixed in the next
version. Not sure why they are not captured in my builds though
I did turn on treating warnings as error.
drivers/vfio/fsl-mc/vfio_fsl_mc.c:570:6: warning: no previous prototype for
'vfio_fsl_mc_release_dev' [-Wmissing-prototypes]
On 8/28/22 02:39, Randy Dunlap wrote:
> -From the command line, pass options to modprobe
> -modprobe udlfb fb_defio=0 console=1 shadow=1
> +From the command line, pass options to modprobe::
>
> -Or modify options on the fly at /sys/module/udlfb/parameters directory via
> -sudo nano fb_defio
> -ch
On Fri, Aug 26, 2022 at 2:07 PM Lucas Stach wrote:
>
> From: Marco Felsch
>
> The GPU is found on the NXP i.MX8MN SoC. The feature bits are taken from
> the NXP downstream kernel driver 6.4.3.p2.
>
This series fixes an issue where I saw:
etnaviv-gpu 3800.gpu: recover hung GPU!
With mesa-22.
On 8/27/22 18:51, Bagas Sanjaya wrote:
> On 8/28/22 02:39, Randy Dunlap wrote:
>> -From the command line, pass options to modprobe
>> -modprobe udlfb fb_defio=0 console=1 shadow=1
>> +From the command line, pass options to modprobe::
>>
>> -Or modify options on the fly at /sys/module/udlfb/par
Hi Laurent,
> Subject: Re: [PATCH 2/2] drm: rcar-du: Use %p4cc to print 4CC format
>
> Hi Biju,
>
> On Sat, Aug 27, 2022 at 09:04:25AM +, Biju Das wrote:
> > Subject: Re: [PATCH 2/2] drm: rcar-du: Use %p4cc to print 4CC format
> > > On Thu, Aug 25, 2022 at 11:39:05AM +0100, Biju Das wrote:
>
62 matches
Mail list logo
