On Thu, Jul 22, 2021 at 09:02:41PM +0200, Daniel Vetter wrote:
> On Thu, Jul 22, 2021 at 6:00 PM Boqun Feng wrote:
> >
> > On Thu, Jul 22, 2021 at 12:38:10PM +0200, Daniel Vetter wrote:
> > > On Thu, Jul 22, 2021 at 05:29:27PM +0800, Desmond Cheong Zhi Xi wrote:
> > > > Inside drm_is_current_maste
On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote:
> +static int loongson_drm_load(struct drm_device *dev)
> +{
> + struct loongson_device *ldev;
> + int ret;
> +
> + ldev = devm_kzalloc(dev->dev, sizeof(*ldev), GFP_KERNEL);
> + if (!ldev)
> + return -ENOMEM;
>
On Thu, Jul 22, 2021 at 9:51 PM Karol Herbst wrote:
>
> hey thanks for the report.
>
> This is a known issue and the fix is pending in drm-mist-fixes and
> should land in 5.14 soonish.
It just landed in Linus' tree yesterday, please retest that or -rc3.
If it's still broken it's something else.
-
On Thu, Jul 22, 2021 at 08:22:43PM +0200, Thomas Zimmermann wrote:
> Hi,
>
> I'm not knowledgeable enougth to give this a full review. If you can just
> answer my questions, fell free to add an
>
> Acked-by: Thomas Zimmermann
>
> to the patch. :)
>
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 08:40:56PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > intel-gfx-ci realized that something is not quite coherent anymore on
> > some platforms for our i915+vgem tests, when I tried to switch vgem
> > over to shmem helpers.
> >
On Thu, Jul 22, 2021 at 08:50:48PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > Aside from deleting lots of code the real motivation here is to switch
> > the mmap over to VM_PFNMAP, to be more consistent with what real gpu
> > drivers do. They're all VM
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
in dma_buf_release, which could be triggered by user space closing the
dma-buf file description while there are outstanding fence callbacks
from dma_buf_poll.
Cc: sta...@vger.ker
Am 23.07.21 um 09:36 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 08:40:56PM +0200, Thomas Zimmermann wrote:
Hi
Am 13.07.21 um 22:51 schrieb Daniel Vetter:
[SNIP]
+#ifdef CONFIG_X86
+ if (shmem->map_wc)
+ set_pages_array_wc(pages, obj->size >> PAGE_SHIFT);
+#endif
I cann
On Thu, 22 Jul 2021 09:48:00 -0400
Sean Paul wrote:
> On Thu, Jul 22, 2021 at 3:49 AM Pekka Paalanen wrote:
> >
> > On Wed, 21 Jul 2021 13:55:07 -0400
> > Sean Paul wrote:
> >
> > > From: Sean Paul
> > >
> > > Hi all,
> > > I just had the pleasure of rebasing this set on our CrOS downstream
On 2021-07-20 3:11 p.m., Christian König wrote:
> Daniel pointed me towards this function and there are multiple obvious
> problems
> in the implementation.
>
> First of all the retry loop is not working as intended. In general the retry
> makes only sense if you grab the reference first and then
Am 23.07.21 um 09:58 schrieb Michel Dänzer:
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
in dma_buf_release, which could be triggered by user space closing the
dma-buf file description while there are outstanding fence cal
On 2021-07-23 10:04 a.m., Christian König wrote:
> Am 23.07.21 um 09:58 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> This makes sure we don't hit the
>>
>> BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
>>
>> in dma_buf_release, which could be triggered by user space closing the
On Wed, Jul 14, 2021 at 10:51 AM Christian König
wrote:
>
>
>
> Am 13.07.21 um 17:28 schrieb Alex Deucher:
> > On Tue, Jul 13, 2021 at 2:57 AM Christian König
> > wrote:
> >>
> >>
> >> Am 13.07.21 um 00:06 schrieb Felix Kuehling:
> >>> KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE
Am 23.07.21 um 10:19 schrieb Michel Dänzer:
On 2021-07-23 10:04 a.m., Christian König wrote:
Am 23.07.21 um 09:58 schrieb Michel Dänzer:
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
in dma_buf_release, which could be tri
On Fri, Jul 23, 2021 at 06:51:59AM +0100, Christoph Hellwig wrote:
> On Thu, Jul 22, 2021 at 04:29:11PM -0500, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > This is a little bit of rework and extension of Huacai's nice work at [1].
> >
> > It moves the VGA arbiter to the PCI subsystem, fi
Am 23.07.21 um 10:21 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 10:51 AM Christian König
wrote:
Am 13.07.21 um 17:28 schrieb Alex Deucher:
On Tue, Jul 13, 2021 at 2:57 AM Christian König
wrote:
Am 13.07.21 um 00:06 schrieb Felix Kuehling:
KFD Thunk maps invisible VRAM BOs with PRO
On Fri, Jul 23, 2021 at 10:02:39AM +0200, Christian König wrote:
> Am 23.07.21 um 09:36 schrieb Daniel Vetter:
> > On Thu, Jul 22, 2021 at 08:40:56PM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > > [SNIP]
> > > > +#ifdef CONFIG_X86
> > > > +
It's not used. Drivers should instead use the helpers anyway.
Currently both vbox and i915 hand-roll this and it's not the greatest.
vbox looks buggy, and i915 does a bit much that helpers would take
care of I think.
Also improve the kerneldocs while we're at it.
Reviewed-by: José Roberto de Sou
There's two stages of manual upload/invalidate displays:
- just handling dirtyfb and uploading the entire fb all the time
- looking at damage clips
In the latter case we support it through fbdev emulation (with
fb_defio), atomic property, and with the dirtfy clip rects.
Make sure at least the ato
We're trying to have a fairly strict split between core functionality
that defines the uapi, including the docs, and the helper functions to
implement it.
Move drm_plane_enable_fb_damage_clips and associated kerneldoc into
drm_plane from drm_damage_helper.c to fix this.
Reviewed-by: José Roberto
On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
> Doing this in vmw_ttm_destroy() is to late.
>
> It turned out that this is not a good idea at all because it leaves pointers
> to freed up system memory pages in the GART tables of the drivers.
So I wanted to review this series, a
On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote:
> From: Chenyang Li
>
> This patch adds an initial DRM driver for the Loongson LS7A1000
> bridge chip(LS7A). The LS7A bridge chip contains two display
> controllers, support dual display output. The maximum support for
> each channel dis
On Thu, 22 Jul 2021 at 12:54, Daniel Vetter wrote:
>
> On Thu, Jul 22, 2021 at 12:34:55PM +0100, Matthew Auld wrote:
> > Try to document the object caching related bits, like cache_coherent and
> > cache_dirty.
> >
> > v2(Ville):
> > - As pointed out by Ville, fix the completely incorrect assumpt
On Fri, Jul 23, 2021 at 10:33:48AM +0200, Christian König wrote:
>
>
> Am 23.07.21 um 10:21 schrieb Daniel Vetter:
> > On Wed, Jul 14, 2021 at 10:51 AM Christian König
> > wrote:
> > >
> > >
> > > Am 13.07.21 um 17:28 schrieb Alex Deucher:
> > > > On Tue, Jul 13, 2021 at 2:57 AM Christian Köni
On Fri, Jul 23, 2021 at 10:19:49AM +0200, Michel Dänzer wrote:
> On 2021-07-23 10:04 a.m., Christian König wrote:
> > Am 23.07.21 um 09:58 schrieb Michel Dänzer:
> >> From: Michel Dänzer
> >>
> >> This makes sure we don't hit the
> >>
> >> BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
Add display node for vdosys0.
Signed-off-by: jason-jh.lin
---
This patch is based on [1][2][3][4]
[1]arm64: dts: Add Mediatek SoC MT8195 and evaluation board dts and Makefile
-
https://patchwork.kernel.org/project/linux-mediatek/patch/20210601075350.31515-2-seiya.w...@mediatek.com/
[2]arm64: dt
Add mtk-mutex support for mt8195 vdosys0.
Signed-off-by: jason-jh.lin
---
This patch is base on [1]
[1]add mt8195 SoC DRM binding
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
---
drivers/soc/mediatek/mtk-mutex.c | 93 ++--
1 file changed,
Add DSC into mtk_drm_ddp_comp to support for mt8195.
DSC is designed for real-time systems with real-time compression,
transmission, decompression and display.
The DSC standard is a specification of the algorithms used for
compressing and decompressing image display streams, including
the specific
Add mt8195 vdosys0 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: jason-jh.lin
---
This patch is base on [1]
[1]add mt8195 SoC DRM binding
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
---
drivers/soc/mediatek/mt8195-mmsys.h|
Add MERGE module file:
MERGE module is used to merge two slice-per-line inputs
into one side-by-side output.
Signed-off-by: jason-jh.lin
---
This patch is base on [1]
[1]add mt8195 SoC DRM binding
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
---
drivers/gpu/drm/med
The hardware path of vdosys0 with eDP panel output need to go through
by several modules, such as, OVL, RDMA, COLOR, CCORR, AAL, GAMMA,
DITHER, DSC and MERGE.
Change in v4:
- extract dt-binding patches to another patch series
https://patchwork.kernel.org/project/linux-mediatek/list/?series=51959
Add driver data of mt8195 vdosys0 to mediatek-drm and the sub driver.
Signed-off-by: jason-jh.lin
---
This patch is base on [1]
[1]add mt8195 SoC DRM binding
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++
drive
Am 23.07.21 um 11:00 schrieb Daniel Vetter:
On Fri, Jul 23, 2021 at 10:33:48AM +0200, Christian König wrote:
Am 23.07.21 um 10:21 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 10:51 AM Christian König
wrote:
Am 13.07.21 um 17:28 schrieb Alex Deucher:
On Tue, Jul 13, 2021 at 2:57 AM Christ
On 2021-07-23 11:02 a.m., Daniel Vetter wrote:
> On Fri, Jul 23, 2021 at 10:19:49AM +0200, Michel Dänzer wrote:
>> On 2021-07-23 10:04 a.m., Christian König wrote:
>>> Am 23.07.21 um 09:58 schrieb Michel Dänzer:
From: Michel Dänzer
This makes sure we don't hit the
BUG_
Am 23.07.21 um 10:47 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers
From: Arnd Bergmann
With the addition of the DMA fence, the host1x driver now fails to
build without the sync_file helper:
arm-linux-gnueabi-ld: drivers/gpu/host1x/fence.o: in function
`host1x_fence_create_fd':
fence.c:(.text+0x624): undefined reference to `sync_file_create'
Fixes: ad0529424de
From: Arnd Bergmann
When the backlight support is disabled, the driver fails to build:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_sor_atomic_disable':
drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
nouveau_connector' has no member named 'backlight'
1665 |
From: Arnd Bergmann
A recent patch left an unused variable in place that needs to be
removed:
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c: In function 'hibmc_unload':
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c:252:35: error: unused variable
'priv' [-Werror=unused-variable]
252 |
Hi Arnd,
I think the best fix for this is to just remove that function -- it is
currently not used anywhere. I posted a patch to do that, but Thierry is
currently on vacation so it hasn't been picked up yet.
thanks,
Mikko
On 7/23/21 12:14 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
With
On 7/23/21 12:17 PM, Mikko Perttunen wrote:
Hi Arnd,
I think the best fix for this is to just remove that function -- it is
currently not used anywhere. I posted a patch to do that, but Thierry is
currently on vacation so it hasn't been picked up yet.
.. and sorry for the top post ..
Mikko
On Fri, Jul 23, 2021 at 11:13 AM Christian König
wrote:
>
> Am 23.07.21 um 10:47 schrieb Daniel Vetter:
> > On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
> >> Doing this in vmw_ttm_destroy() is to late.
> >>
> >> It turned out that this is not a good idea at all because it leave
On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> When the backlight support is disabled, the driver fails to build:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> 'nv50_sor_atomic_disable':
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'st
Am 23.07.21 um 11:21 schrieb Daniel Vetter:
On Fri, Jul 23, 2021 at 11:13 AM Christian König
wrote:
Am 23.07.21 um 10:47 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good i
Hi, Bjorn,
On Fri, Jul 23, 2021 at 5:29 AM Bjorn Helgaas wrote:
>
> From: Bjorn Helgaas
>
> This is a little bit of rework and extension of Huacai's nice work at [1].
>
> It moves the VGA arbiter to the PCI subsystem, fixes a few nits, and breaks
> a few pieces off Huacai's patch to make the mai
Hi Jason,
Thank you for your patch.
Missatge de jason-jh.lin del dia dv., 23
de jul. 2021 a les 11:02:
>
> Add mt8195 vdosys0 clock driver name and routing table to
> the driver data of mtk-mmsys.
>
> Signed-off-by: jason-jh.lin
> ---
> This patch is base on [1]
>
> [1]add mt8195 SoC DRM bindin
On Fri, Jul 23, 2021 at 11:24 AM Daniel Vetter wrote:
>
> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > 'nv50_sor_atomi
On Fri, Jul 23, 2021 at 12:10 PM Karol Herbst wrote:
>
> On Fri, Jul 23, 2021 at 11:24 AM Daniel Vetter wrote:
> >
> > On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> > >
> > > From: Arnd Bergmann
> > >
> > > When the backlight support is disabled, the driver fails to build:
> > >
> > >
On Thu, Jul 22, 2021 at 09:02:04PM +0200, Marek Vasut wrote:
> On 7/22/21 1:28 PM, Daniel Thompson wrote:
> > On Wed, Jul 21, 2021 at 08:46:42PM +0200, Marek Vasut wrote:
> > > On 7/21/21 6:12 PM, Daniel Thompson wrote:
> > > > On Wed, Jul 21, 2021 at 05:09:57PM +0200, Marek Vasut wrote:
> > > > >
On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
>
> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > 'nv50_sor_atomi
Add the missing scache_cntl0 register programing which is required for
a660 gpu.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 ---
1 file changed, 27 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
This patch adds support for the gpu found in the Snapdragon 7c Gen 3
compute platform. This gpu is similar to the exisiting a660 gpu with
minor delta in the programing sequence. As the Adreno GPUs are moving
away from a numeric chipid based naming scheme to a string, it was
decided to use 0x0603050
Try to document the object caching related bits, like cache_coherent and
cache_dirty.
v2(Ville):
- As pointed out by Ville, fix the completely incorrect assumptions
about the "partial" coherency on shared LLC platforms.
v3(Daniel):
- Fix nonsense about "dirtying" the cache with reads.
v4(Dani
EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
possible for userspace to bypass the GTT caching bits set by the kernel,
as per the given object cache_level. This is troublesome since the heavy
flush we apply when first acquiring the pages is skipped if the kernel
thinks the objec
Hi Nancy,
Thank you for your patch.
Missatge de Nancy.Lin del dia dj., 22 de jul.
2021 a les 11:46:
>
> Among other features the mmsys driver should implement a reset
> controller to be able to reset different bits from their space.
>
I'm working on a series that does the same, it should be nic
Currently there are (at least) two problems in the way pwm_bl starts
managing the enable_gpio pin. Both occur when the backlight is initially
off and the driver finds the pin not already in output mode and, as a
result, unconditionally switches it to output-mode and asserts the signal.
Problem 1:
Hi Nancy,
Thank you for your patch.
Missatge de Nancy.Lin del dia dj., 22 de jul.
2021 a les 11:45:
>
> Add mt8195 vdosys1 clock driver name and routing table to
> the driver data of mtk-mmsys.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/soc/mediatek/mt8195-mmsys.h| 83 +++
On 21/07/2021 22:48, Chris Morgan wrote:
> From: Chris Morgan
>
> Set a condition for the message of "Couldn't set OPP regulators" to not
> display if the error code is EPROBE_DEFER. Note that I used an if
> statement to capture the condition instead of the dev_err_probe
> function because I didn
Hi Nancy,
Thank you for your patch
Missatge de Nancy.Lin del dia dj., 22 de jul.
2021 a les 11:46:
>
> The DT binding includes for reset controllers are located in
> include/dt-bindings/reset/. Move the Mediatek reset constants in there.
>
I think that the patch that introduces mt8195-resets.h
Hi Jason,
Thank you for your patch.
Missatge de jason-jh.lin del dia dj., 22
de jul. 2021 a les 11:26:
>
> There are 2 display hardware path in mt8195, namely vdosys0 and
> vdosys1, so add their definition in mtk-mmsys documentation.
>
Just having 2 display hardware paths is not a reason to hav
On Fri, Jul 23, 2021 at 11:15:10AM +0100, Daniel Thompson wrote:
> On Thu, Jul 22, 2021 at 09:02:04PM +0200, Marek Vasut wrote:
> > On 7/22/21 1:28 PM, Daniel Thompson wrote:
> > > On Wed, Jul 21, 2021 at 08:46:42PM +0200, Marek Vasut wrote:
> > > > On 7/21/21 6:12 PM, Daniel Thompson wrote:
> > >
On 15/07/2021 10:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs proposing
the common specification which should enable nice common userspace tools to be
written.
For the moment I only have intel_gpu_top converted to use this
Add the necessary dt nodes for gpu support in sc7280.
Signed-off-by: Akhil P Oommen
---
This patch has dependency on the GPUCC bindings patch here:
https://patchwork.kernel.org/project/linux-arm-msm/patch/1619519590-3019-4-git-send-email-t...@codeaurora.org/
arch/arm64/boot/dts/qcom/sc7280.dtsi
Am 23.07.21 um 13:21 schrieb Tvrtko Ursulin:
On 15/07/2021 10:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs
proposing
the common specification which should enable nice common userspace
tools to be
written.
For the moment
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a complete set of pages
upon creation. To be more efficient than simply populating the userptr
using get_user_pages() (as done by the call to set-domain or
On Tue, Jul 20, 2021 at 04:35:44PM +0200, Maxime Ripard wrote:
> New KMS properties come with a bunch of requirements to avoid each
> driver from running their own, inconsistent, set of properties,
> eventually leading to issues like property conflicts, inconsistencies
> between drivers and semanti
On Fri, Jul 23, 2021 at 09:44:35AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 20, 2021 at 02:42:52PM -0300, Jason Gunthorpe wrote:
> > .write = vfio_fsl_mc_write,
> > @@ -625,13 +526,15 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device
> > *mc_dev)
> > vdev->mc_dev = mc_dev;
On Fri, Jul 23, 2021 at 09:45:21AM +0200, Christoph Hellwig wrote:
> Looks good,
>
> Reviewed-by: Christoph Hellwig
>
> On Tue, Jul 20, 2021 at 02:42:53PM -0300, Jason Gunthorpe wrote:
> > Platform simply wants to run some code when the device is first
> > opened/last closed. Use the core framew
On 7/23/21 1:17 PM, Daniel Thompson wrote:
On Fri, Jul 23, 2021 at 11:15:10AM +0100, Daniel Thompson wrote:
On Thu, Jul 22, 2021 at 09:02:04PM +0200, Marek Vasut wrote:
On 7/22/21 1:28 PM, Daniel Thompson wrote:
On Wed, Jul 21, 2021 at 08:46:42PM +0200, Marek Vasut wrote:
On 7/21/21 6:12 PM,
s/Exporting/Importing
Fixes: 805dc614d58a8 ("drm/prime: Update docs")
Cc: Daniel Vetter
Signed-off-by: Jose Maria Casanova Crespo
---
drivers/gpu/drm/drm_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index
Am 23.07.21 um 14:31 schrieb Charan Teja Reddy:
It is expected from the clients to follow the below steps on an imported
dmabuf fd:
a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd
b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf
o Here the kernel does some slab allocations, sa
On Fri, Jul 23, 2021 at 09:47:49AM +0200, Christoph Hellwig wrote:
> > @@ -2020,12 +2004,17 @@ static int vfio_pci_probe(struct pci_dev *pdev,
> > const struct pci_device_id *id)
> > INIT_LIST_HEAD(&vdev->vma_list);
> > init_rwsem(&vdev->memory_lock);
> >
> > - ret = vfio_pci_reflck_at
Hi Vinay,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.14-rc2 next-20210723]
[If your patch is applied to the wrong git tree
On Fri, Jul 23, 2021 at 02:29:03PM +0200, Christoph Hellwig wrote:
> On Fri, Jul 23, 2021 at 09:22:27AM -0300, Jason Gunthorpe wrote:
> > > But do we even need the else part? Assingning &mc_dev->dev is
> > > equivalent to the default per-device set anyway, isn't it?
> >
> > Not quite, the default
On Fri, Jul 23, 2021 at 10:05:43AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 20, 2021 at 02:42:55PM -0300, Jason Gunthorpe wrote:
> > Keep track of all the vfio_devices that have been added to the device set
> > and use this list in vfio_pci_try_bus_reset() instead of trying to work
> > backwar
On Fri, Jul 23, 2021 at 10:12:08AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 20, 2021 at 02:42:56PM -0300, Jason Gunthorpe wrote:
> > Like vfio_pci_try_bus_reset() this code wants to reset all of the devices
> > in the "reset group" which is the same membership as the device set.
> >
> > Inste
On 23/07/2021 12:23, Christian König wrote:
Am 23.07.21 um 13:21 schrieb Tvrtko Ursulin:
On 15/07/2021 10:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs
proposing
the common specification which should enable nice common us
On Fri, Jul 23, 2021 at 9:51 AM Tvrtko Ursulin
wrote:
>
>
> On 23/07/2021 12:23, Christian König wrote:
> > Am 23.07.21 um 13:21 schrieb Tvrtko Ursulin:
> >>
> >> On 15/07/2021 10:18, Tvrtko Ursulin wrote:
> >>> From: Tvrtko Ursulin
> >>>
> >>> Same old work but now rebased and series ending with
+ David, Roy
On Thu, Jul 15, 2021 at 5:18 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Convert fdinfo format to one documented in drm-usage-stats.rst.
>
> Opens:
> * Does it work for AMD?
> * What are the semantics of AMD engine utilisation reported in percents?
>Can it align with
On Wed, Jul 21, 2021 at 1:07 PM Ryan Taylor wrote:
>
> Modify the VKMS driver into an api that dce_virtual can use to create
> virtual displays that obey drm's atomic modesetting api.
>
> v2: Made local functions static.
>
> Reported-by: kernel test robot
> Signed-off-by: Ryan Taylor
> ---
> dr
On Wed, Jul 21, 2021 at 1:07 PM Ryan Taylor wrote:
>
> Move dce_virtual into amdgpu_vkms and update all references to
> dce_virtual with amdgpu_vkms.
>
> v2: Removed more references to dce_virtual.
>
> v3: Restored display modes from previous implementation.
>
> Reported-by: kernel test robot
> S
On Fri, Jul 23, 2021 at 09:39:14AM +0200, Christoph Hellwig wrote:
> This looks unessecarily complicated. We can just try to load first
> and then store it under the same lock, e.g.:
Yes indeed, I went with this:
int vfio_assign_device_set(struct vfio_device *device, void *set_id)
{
uns
On Fri, Jul 23, 2021 at 02:34:13PM +0200, Christian König wrote:
> Am 23.07.21 um 14:31 schrieb Charan Teja Reddy:
> > It is expected from the clients to follow the below steps on an imported
> > dmabuf fd:
> > a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd
> > b) dma_buf_attach(dmabuf); //
On 7/23/21 2:15 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When the backlight support is disabled, the driver fails to build:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> 'nv50_sor_atomic_disable':
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> nouvea
On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap wrote:
>
> On 7/23/21 2:15 AM, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > 'nv50_sor_atomic_disable':
> > driv
On 07/23, Jose Maria Casanova Crespo wrote:
> s/Exporting/Importing
>
> Fixes: 805dc614d58a8 ("drm/prime: Update docs")
Fixes flag here looks a little bit overkill. Anyway, this change lgtm
Reported-by: Rodrigo Siqueira
> Cc: Daniel Vetter
> Signed-off-by: Jose Maria Casanova Crespo
>
> ---
On Fri, Jul 23, 2021 at 12:16:31PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
> >
> > On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> > >
> > > From: Arnd Bergmann
> > >
> > > When the backlight support is disabled, the driver fails to build:
> >
On 21/07/2021 21:17, Jason Ekstrand wrote:
On Wed, Jul 21, 2021 at 1:32 PM Daniel Vetter wrote:
This essentially reverts
commit 84a1074920523430f9dc30ff907f4801b4820072
Author: Chris Wilson
Date: Wed Jan 24 11:36:08 2018 +
drm/i915: Shrink the GEM kmem_caches upon idling
mm/vm
We already have logging for ADDFB2. Add some logging for RMFB as
well.
This can be handy when trying to find out why a CRTC gets magically
disabled.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_framebuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/
[AMD Official Use Only]
Thanks Alex! I will make these changes.
Best,
Ryan
From: Alex Deucher
Sent: Friday, July 23, 2021 7:33 AM
To: Taylor, Ryan
Cc: Maling list - DRI developers ; amd-gfx
list ; kernel test robot ;
Daniel Vetter ; Siqueira, Rodrigo
; Meliss
On Friday 23 July 2021 09:26:10 Daniel Vetter wrote:
> On Thu, Jul 22, 2021 at 9:51 PM Karol Herbst wrote:
> >
> > hey thanks for the report.
> >
> > This is a known issue and the fix is pending in drm-mist-fixes and
> > should land in 5.14 soonish.
>
> It just landed in Linus' tree yesterday, pl
On Fri, 2021-07-23 at 11:24 +0200, Daniel Vetter wrote:
> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > 'nv50_sor_atom
It is expected from the clients to follow the below steps on an imported
dmabuf fd:
a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd
b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf
o Here the kernel does some slab allocations, say for
dma_buf_attachment and may be some other slab
Without prefix debugfs can't properly create component
debug information tree when driver register more than
one component per device, in this case two. Fix this.
debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
Signed-off-by: Ivan T. Ivanov
---
drivers/gpu/drm/vc4/v
On 7/23/21 8:15 AM, Karol Herbst wrote:
> On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap wrote:
>>
>> On 7/23/21 2:15 AM, Arnd Bergmann wrote:
>>> From: Arnd Bergmann
>>>
>>> When the backlight support is disabled, the driver fails to build:
>>>
>>> drivers/gpu/drm/nouveau/dispnv50/disp.c: In funct
On Fri, Jul 23, 2021 at 5:46 PM Simon Ser wrote:
>
> We already have logging for ADDFB2. Add some logging for RMFB as
> well.
>
> This can be handy when trying to find out why a CRTC gets magically
> disabled.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_framebuf
On Fri, Jul 23, 2021 at 6:31 PM Randy Dunlap wrote:
>
> On 7/23/21 8:15 AM, Karol Herbst wrote:
> > On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap wrote:
> >>
> >> On 7/23/21 2:15 AM, Arnd Bergmann wrote:
> >>> From: Arnd Bergmann
> >>>
> >>> When the backlight support is disabled, the driver fail
Hi Tvrtko,
Thanks for typing this up!
On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin
wrote:
> +Mandatory fully standardised keys
> +-
> +
> +- drm-driver:
> +
> +String shall contain a fixed string uniquely identified the driver handling
> +the device in question. F
On Fri, Jul 23, 2021 at 05:43:01PM +0100, Daniel Stone wrote:
> Hi Tvrtko,
> Thanks for typing this up!
>
> On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin
> wrote:
> > +Mandatory fully standardised keys
> > +-
> > +
> > +- drm-driver:
> > +
> > +String shall contain
To let the userspace recognize that it's running on top of a vmwgfx
that supports mks-stat ioctls we need to bump the version number.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Neha Bhende
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 +++---
1 file changed, 3 insertions(
The macro has been accounting for DRM_COMMAND_BASE for a long time
now so there's no reason to still be duplicating it. Plus we were
leaving the name undefined which meant that all the DRM ioctl
warnings/errors were always listing "null" ioctl at the culprit.
This fixes the undefined ioctl name an
1 - 100 of 198 matches
Mail list logo
