Re: [PATCH] drm/ttm: remove unused varibles
Am 20.11.20 um 07:49 schrieb Tian Tao:
fixed the following warnings
drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
Signed-off-by: Tian Tao
The subject should read drm/nouveau instead of drm/ttm, but apart from
that the patch is Acked-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7aa4286..9465f56 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1228,7 +1228,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
{
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
- struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (ttm_tt_is_populated(ttm))
@@ -1242,7 +1241,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
}
drm = nouveau_bdev(bdev);
- dev = drm->dev->dev;
return ttm_pool_alloc(&drm->ttm.bdev.pool, ttm, ctx);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 5.10-rc4
Hi David
Am 18.11.20 um 23:01 schrieb David Laight:
From: Thomas Zimmermann
Sent: 18 November 2020 19:37
Hi
Am 18.11.20 um 19:10 schrieb Linus Torvalds:
On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote:
I've got the 'splat' below during boot.
This is an 8-core C2758 Atom cpu using the on-board/cpu graphics.
User space is Ubuntu 20.04.
Additionally the X display has all the colours and alignment slightly
messed up.
5.9.0 was ok.
I'm just guessing the two issues are related.
Sounds likely. But it would be lovely if you could bisect when
exactly the problem(s) started to both verify that, and just to
pinpoint the exact change..
I don't quite understand what 'git bisect' did.
I was bisecting between v5.9 and v5.10-rc1 but it suddenly started
generating v5.9.0-rc5+ kernels.
The identified commit was 13a8f46d803 drm/ttm: move ghost object created.
(retyped - hope it is right).
But the diff to that last 'good' commit is massive.
So I don't know if that is anywhere near right.
Did you try Daniel's suggestion of testing with the direct parent commit?
Best regards
Thomas
David
I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast:
Program display mode in CRTC's atomic_enable" which looks relevant in
that it's right in that call-chain.
Did some initialization perhaps get overlooked?
And Dave and Daniel and the drm list cc'd as well..
Full splat left quoted below for new people and list.
Linus
[ 20.809891] WARNING: CPU: 0 PID: 973 at
drivers/gpu/drm/drm_gem_vram_helper.c:284
drm_gem_vram_offset+0x35/0x40 [drm_vram_helper]
That line is at [1], which comes from
46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4")
But the patch was merged in 5.9-rc1, so it's probably something else.
We've had a lot of TTM-related changes recently, so my best guess is
that it's something in TTM with BO initialization.
From some grepping, it looks like we have to call ttm_bo_mem_space() to
fill mm_node (i.e., the pointer that causes the warning). But I cannot
find where vram helpers do this. Maybe that's a good starting point.
I'm adding the TTM devs to cc.
Best regards
Thomas
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h
elper.c?h=v5.10-rc4#n284
[ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac
scsi_dh_emc scsi_dh_alua
ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si
intel_cstate ipmi_devintf
ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables
x_tables autofs4 btrfs
blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy
async_pq async_xor
async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast
drm_vram_helper drm_kms_helper
syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm
crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper
crypto_simd igb usbhid cryptd
ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit
[ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78
[ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015
[ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper]
[ 20.907342] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48
8b 87 80 01 00 00 5d
48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00
00 0f 1f 44 00 00 55
48 8b 87 18 06
[ 20.926100] RSP: 0018:9f59811d3a68 EFLAGS: 00010246
[ 20.931339] RAX: 0002 RBX: 8b46861e20c0 RCX: c032d600
[ 20.938479] RDX: 8b468f47a000 RSI: 8b46861e2000 RDI: 8b468f9acc00
[ 20.945622] RBP: 9f59811d3a68 R08: 0040 R09: 8b46864ce288
[ 20.952769] R10: R11: 0001 R12: 8b468f47a000
[ 20.959915] R13: R14: R15: 8b468ad2bf00
[ 20.967057] FS: 7f5b37ac5cc0() GS:8b49efc0()
knlGS:
[ 20.975149] CS: 0010 DS: ES: CR0: 80050033
[ 20.980904] CR2: 7f5b3d093f00 CR3: 000103438000 CR4: 001006f0
[ 20.988047] Call Trace:
[ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast]
[ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast]
[ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper]
[ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper]
[ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper]
[ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper]
[ 21.026269] drm_atomic_commit+0x4a/0x50 [drm]
[ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper]
[ 21.037384] __setplane_atomic+0xcc/0x110 [drm]
[ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm]
[ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm]
[ 21.052287] ? alloc_set_pte+0x10d/0x6d0
[ 21
Re: [PATCH] drm/kmb: Fix possible oops in probe error handling
On Fri, Nov 20, 2020 at 01:29:45AM +, Chrisanthus, Anitha wrote:
> Hi Dan,
>
> > -Original Message-
> > From: Dan Carpenter
> > Sent: Monday, November 16, 2020 11:21 PM
> > To: Chrisanthus, Anitha
> > Cc: Dea, Edmund J ; David Airlie ;
> > Daniel Vetter ; Sam Ravnborg ; dri-
> > de...@lists.freedesktop.org; kernel-janit...@vger.kernel.org
> > Subject: [PATCH] drm/kmb: Fix possible oops in probe error handling
> >
> > If kmb_dsi_init() fails the error handling will dereference an error
> > pointer which will cause an Oops.
> >
> > Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display")
> > Signed-off-by: Dan Carpenter
> > ---
> > drivers/gpu/drm/kmb/kmb_drv.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/kmb/kmb_drv.c
> > b/drivers/gpu/drm/kmb/kmb_drv.c
> > index a31a840ce634..8c43b136765c 100644
> > --- a/drivers/gpu/drm/kmb/kmb_drv.c
> > +++ b/drivers/gpu/drm/kmb/kmb_drv.c
> > @@ -504,7 +504,7 @@ static int kmb_probe(struct platform_device *pdev)
> > if (IS_ERR(kmb->kmb_dsi)) {
We check that this is an error pointer.
> > drm_err(&kmb->drm, "failed to initialize DSI\n");
> > ret = PTR_ERR(kmb->kmb_dsi);
> > - goto err_free1;
^^^
We go to err_free1.
> > + goto err_clear_drvdata;
> > }
> dsi host is registered earlier, it needs to be unregistered, original code
> is correct.
>
> Anitha
> >
> > kmb->kmb_dsi->dev = &dsi_pdev->dev;
> > @@ -540,8 +540,9 @@ static int kmb_probe(struct platform_device *pdev)
> > drm_crtc_cleanup(&kmb->crtc);
> > drm_mode_config_cleanup(&kmb->drm);
> > err_free1:
^
Which is here.
> > - dev_set_drvdata(dev, NULL);
> > kmb_dsi_host_unregister(kmb->kmb_dsi);
And then we crash.
Probably my commit message was not clear enough. I will change the
commit message and resend.
regards,
dan carpenter
> > + err_clear_drvdata:
> > + dev_set_drvdata(dev, NULL);
> >
> > return ret;
> > }
> > --
> > 2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/kmb: Fix possible oops in probe error handling
If kmb_dsi_init() fails the "kmb->kmb_dsi" variable is an error pointer.
The kernel will Oops when we pass it to kmb_dsi_host_unregister().
Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display")
Signed-off-by: Dan Carpenter
---
v2: write a better commit message
drivers/gpu/drm/kmb/kmb_drv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c
index a31a840ce634..8c43b136765c 100644
--- a/drivers/gpu/drm/kmb/kmb_drv.c
+++ b/drivers/gpu/drm/kmb/kmb_drv.c
@@ -504,7 +504,7 @@ static int kmb_probe(struct platform_device *pdev)
if (IS_ERR(kmb->kmb_dsi)) {
drm_err(&kmb->drm, "failed to initialize DSI\n");
ret = PTR_ERR(kmb->kmb_dsi);
- goto err_free1;
+ goto err_clear_drvdata;
}
kmb->kmb_dsi->dev = &dsi_pdev->dev;
@@ -540,8 +540,9 @@ static int kmb_probe(struct platform_device *pdev)
drm_crtc_cleanup(&kmb->crtc);
drm_mode_config_cleanup(&kmb->drm);
err_free1:
- dev_set_drvdata(dev, NULL);
kmb_dsi_host_unregister(kmb->kmb_dsi);
+ err_clear_drvdata:
+ dev_set_drvdata(dev, NULL);
return ret;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe
On 19/11/2020 15:41, Daniel Vetter wrote:
> The media model assumes that buffers are all preallocated, so that
> when a media pipeline is running we never miss a deadline because the
> buffers aren't allocated or available.
>
> This means we cannot fix the v4l follow_pfn usage through
> mmu_notifier, without breaking how this all works. The only real fix
> is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
> tell everyone to cut over to dma-buf memory sharing for zerocopy.
>
> userptr for normal memory will keep working as-is, this only affects
> the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
> videobuf2-dma-sg: Support io userptr operations on io memory").
>
> Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Thanks!
Hans
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: Laurent Dufour
> Cc: Vlastimil Babka
> Cc: Daniel Jordan
> Cc: Michel Lespinasse
> Signed-off-by: Daniel Vetter
> --
> v3:
> - Reference the commit that enabled the zerocopy userptr use case to
> make it abundandtly clear that this patch only affects that, and not
> normal memory userptr. The old commit message already explained that
> normal memory userptr is unaffected, but I guess that was not clear
> enough.
> ---
> drivers/media/common/videobuf2/frame_vector.c | 2 +-
> drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/frame_vector.c
> b/drivers/media/common/videobuf2/frame_vector.c
> index a0e65481a201..1a82ec13ea00 100644
> --- a/drivers/media/common/videobuf2/frame_vector.c
> +++ b/drivers/media/common/videobuf2/frame_vector.c
> @@ -70,7 +70,7 @@ int get_vaddr_frames(unsigned long start, unsigned int
> nr_frames,
> break;
>
> while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
> - err = follow_pfn(vma, start, &nums[ret]);
> + err = unsafe_follow_pfn(vma, start, &nums[ret]);
> if (err) {
> if (ret == 0)
> ret = err;
> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
> b/drivers/media/v4l2-core/videobuf-dma-contig.c
> index 52312ce2ba05..821c4a76ab96 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
> @@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct
> videobuf_dma_contig_memory *mem,
> user_address = untagged_baddr;
>
> while (pages_done < (mem->size >> PAGE_SHIFT)) {
> - ret = follow_pfn(vma, user_address, &this_pfn);
> + ret = unsafe_follow_pfn(vma, user_address, &this_pfn);
> if (ret)
> break;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 06/17] media: videobuf2: Move frame_vector into media subsystem
On 19/11/2020 15:41, Daniel Vetter wrote:
> It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
> symbol from all over the tree (well just one place, somehow omap media
> driver still had this in its Kconfig, despite not using it).
>
> Reviewed-by: John Hubbard
> Acked-by: Mauro Carvalho Chehab
> Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Thanks!
Hans
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: Mauro Carvalho Chehab
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Daniel Vetter
> Signed-off-by: Daniel Vetter
> --
> v3:
> - Create a new frame_vector.h header for this (Mauro)
> v5:
> - Rebase over changes in frame-vector.c from Tomasz review.
> ---
> drivers/media/common/videobuf2/Kconfig| 1 -
> drivers/media/common/videobuf2/Makefile | 1 +
> .../media/common/videobuf2}/frame_vector.c| 2 +
> drivers/media/platform/omap/Kconfig | 1 -
> include/linux/mm.h| 42 -
> include/media/frame_vector.h | 47 +++
> include/media/videobuf2-core.h| 1 +
> mm/Kconfig| 3 --
> mm/Makefile | 1 -
> 9 files changed, 51 insertions(+), 48 deletions(-)
> rename {mm => drivers/media/common/videobuf2}/frame_vector.c (99%)
> create mode 100644 include/media/frame_vector.h
>
> diff --git a/drivers/media/common/videobuf2/Kconfig
> b/drivers/media/common/videobuf2/Kconfig
> index edbc99ebba87..d2223a12c95f 100644
> --- a/drivers/media/common/videobuf2/Kconfig
> +++ b/drivers/media/common/videobuf2/Kconfig
> @@ -9,7 +9,6 @@ config VIDEOBUF2_V4L2
>
> config VIDEOBUF2_MEMOPS
> tristate
> - select FRAME_VECTOR
>
> config VIDEOBUF2_DMA_CONTIG
> tristate
> diff --git a/drivers/media/common/videobuf2/Makefile
> b/drivers/media/common/videobuf2/Makefile
> index 77bebe8b202f..54306f8d096c 100644
> --- a/drivers/media/common/videobuf2/Makefile
> +++ b/drivers/media/common/videobuf2/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> videobuf2-common-objs := videobuf2-core.o
> +videobuf2-common-objs += frame_vector.o
>
> ifeq ($(CONFIG_TRACEPOINTS),y)
>videobuf2-common-objs += vb2-trace.o
> diff --git a/mm/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c
> similarity index 99%
> rename from mm/frame_vector.c
> rename to drivers/media/common/videobuf2/frame_vector.c
> index f8c34b895c76..a0e65481a201 100644
> --- a/mm/frame_vector.c
> +++ b/drivers/media/common/videobuf2/frame_vector.c
> @@ -8,6 +8,8 @@
> #include
> #include
>
> +#include
> +
> /**
> * get_vaddr_frames() - map virtual addresses to pfns
> * @start: starting user address
> diff --git a/drivers/media/platform/omap/Kconfig
> b/drivers/media/platform/omap/Kconfig
> index f73b5893220d..de16de46c0f4 100644
> --- a/drivers/media/platform/omap/Kconfig
> +++ b/drivers/media/platform/omap/Kconfig
> @@ -12,6 +12,5 @@ config VIDEO_OMAP2_VOUT
> depends on VIDEO_V4L2
> select VIDEOBUF2_DMA_CONTIG
> select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
> - select FRAME_VECTOR
> help
> V4L2 Display driver support for OMAP2/3 based boards.
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index efb8c39bc933..b1a4a140863d 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1751,48 +1751,6 @@ int account_locked_vm(struct mm_struct *mm, unsigned
> long pages, bool inc);
> int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
> struct task_struct *task, bool bypass_rlim);
>
> -/* Container for pinned pfns / pages */
> -struct frame_vector {
> - unsigned int nr_allocated; /* Number of frames we have space for */
> - unsigned int nr_frames; /* Number of frames stored in ptrs array */
> - bool got_ref; /* Did we pin pages by getting page ref? */
> - bool is_pfns; /* Does array contain pages or pfns? */
> - void *ptrs[]; /* Array of pinned pfns / pages. Use
> - * pfns_vector_pages() or pfns_vector_pfns()
> - * for access */
> -};
> -
> -struct frame_vector *frame_vector_create(unsigned int nr_frames);
> -void frame_vector_destroy(struct frame_vector *vec);
> -int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
> - struct frame_vector *vec);
> -void put_vaddr_frames(struct frame_vector *vec);
> -int frame_vector_to_pages(struct frame_vector *vec);
> -void frame_vector_to_pfns(struct frame_vector *vec);
> -
> -static inline unsigned int frame_vector_count(struct
Re: [PATCH] drm/kmb: Remove an unnecessary NULL check
Hi Anitha. On Fri, Nov 20, 2020 at 01:19:06AM +, Chrisanthus, Anitha wrote: > Looks good to me. Can we get either an "Acked-by:" or "Reviewed-by:"? Then we can use this while applying. Any news on gettting commit access yourself? If not, then try to ping on the open ticket. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe
On 20/11/2020 09:06, Hans Verkuil wrote:
> On 19/11/2020 15:41, Daniel Vetter wrote:
>> The media model assumes that buffers are all preallocated, so that
>> when a media pipeline is running we never miss a deadline because the
>> buffers aren't allocated or available.
>>
>> This means we cannot fix the v4l follow_pfn usage through
>> mmu_notifier, without breaking how this all works. The only real fix
>> is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
>> tell everyone to cut over to dma-buf memory sharing for zerocopy.
>>
>> userptr for normal memory will keep working as-is, this only affects
>> the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
>> videobuf2-dma-sg: Support io userptr operations on io memory").
>>
>> Acked-by: Tomasz Figa
>
> Acked-by: Hans Verkuil
Actually, cancel this Acked-by.
So let me see if I understand this right: VM_IO | VM_PFNMAP mappings can
move around. There is a mmu_notifier that can be used to be notified when
that happens, but that can't be used with media buffers since those buffers
must always be available and in the same place.
So follow_pfn is replaced by unsafe_follow_pfn to signal that what is attempted
is unsafe and unreliable.
If CONFIG_STRICT_FOLLOW_PFN is set, then unsafe_follow_pfn will fail, if it
is unset, then it writes a warning to the kernel log but just continues while
still unsafe.
I am very much inclined to just drop VM_IO | VM_PFNMAP support in the media
subsystem. For vb2 there is a working alternative in the form of dmabuf, and
frankly for vb1 I don't care. If someone really needs this for a vb1 driver,
then they can do the work to convert that driver to vb2.
I've added Mauro to the CC list and I'll ping a few more people to see what
they think, but in my opinion support for USERPTR + VM_IO | VM_PFNMAP
should just be killed off.
If others would like to keep it, then frame_vector.c needs a comment before
the 'while' explaining why the unsafe_follow_pfn is there and that using
dmabuf is the proper alternative to use. That will make it easier for
developers to figure out why they see a kernel warning and what to do to
fix it, rather than having to dig through the git history for the reason.
Regards,
Hans
>
> Thanks!
>
> Hans
>
>> Signed-off-by: Daniel Vetter
>> Cc: Jason Gunthorpe
>> Cc: Kees Cook
>> Cc: Dan Williams
>> Cc: Andrew Morton
>> Cc: John Hubbard
>> Cc: Jérôme Glisse
>> Cc: Jan Kara
>> Cc: Dan Williams
>> Cc: linux...@kvack.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-samsung-...@vger.kernel.org
>> Cc: linux-me...@vger.kernel.org
>> Cc: Pawel Osciak
>> Cc: Marek Szyprowski
>> Cc: Kyungmin Park
>> Cc: Tomasz Figa
>> Cc: Laurent Dufour
>> Cc: Vlastimil Babka
>> Cc: Daniel Jordan
>> Cc: Michel Lespinasse
>> Signed-off-by: Daniel Vetter
>> --
>> v3:
>> - Reference the commit that enabled the zerocopy userptr use case to
>> make it abundandtly clear that this patch only affects that, and not
>> normal memory userptr. The old commit message already explained that
>> normal memory userptr is unaffected, but I guess that was not clear
>> enough.
>> ---
>> drivers/media/common/videobuf2/frame_vector.c | 2 +-
>> drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/common/videobuf2/frame_vector.c
>> b/drivers/media/common/videobuf2/frame_vector.c
>> index a0e65481a201..1a82ec13ea00 100644
>> --- a/drivers/media/common/videobuf2/frame_vector.c
>> +++ b/drivers/media/common/videobuf2/frame_vector.c
>> @@ -70,7 +70,7 @@ int get_vaddr_frames(unsigned long start, unsigned int
>> nr_frames,
>> break;
>>
>> while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
>> -err = follow_pfn(vma, start, &nums[ret]);
>> +err = unsafe_follow_pfn(vma, start, &nums[ret]);
>> if (err) {
>> if (ret == 0)
>> ret = err;
>> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
>> b/drivers/media/v4l2-core/videobuf-dma-contig.c
>> index 52312ce2ba05..821c4a76ab96 100644
>> --- a/drivers/media/v4l2-core/videobuf-dma-contig.c
>> +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
>> @@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct
>> videobuf_dma_contig_memory *mem,
>> user_address = untagged_baddr;
>>
>> while (pages_done < (mem->size >> PAGE_SHIFT)) {
>> -ret = follow_pfn(vma, user_address, &this_pfn);
>> +ret = unsafe_follow_pfn(vma, user_address, &this_pfn);
>> if (ret)
>> break;
>>
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe
On Fri, Nov 20, 2020 at 5:28 PM Hans Verkuil wrote:
>
> On 20/11/2020 09:06, Hans Verkuil wrote:
> > On 19/11/2020 15:41, Daniel Vetter wrote:
> >> The media model assumes that buffers are all preallocated, so that
> >> when a media pipeline is running we never miss a deadline because the
> >> buffers aren't allocated or available.
> >>
> >> This means we cannot fix the v4l follow_pfn usage through
> >> mmu_notifier, without breaking how this all works. The only real fix
> >> is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
> >> tell everyone to cut over to dma-buf memory sharing for zerocopy.
> >>
> >> userptr for normal memory will keep working as-is, this only affects
> >> the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
> >> videobuf2-dma-sg: Support io userptr operations on io memory").
> >>
> >> Acked-by: Tomasz Figa
> >
> > Acked-by: Hans Verkuil
>
> Actually, cancel this Acked-by.
>
> So let me see if I understand this right: VM_IO | VM_PFNMAP mappings can
> move around. There is a mmu_notifier that can be used to be notified when
> that happens, but that can't be used with media buffers since those buffers
> must always be available and in the same place.
>
> So follow_pfn is replaced by unsafe_follow_pfn to signal that what is
> attempted
> is unsafe and unreliable.
>
> If CONFIG_STRICT_FOLLOW_PFN is set, then unsafe_follow_pfn will fail, if it
> is unset, then it writes a warning to the kernel log but just continues while
> still unsafe.
>
> I am very much inclined to just drop VM_IO | VM_PFNMAP support in the media
> subsystem. For vb2 there is a working alternative in the form of dmabuf, and
> frankly for vb1 I don't care. If someone really needs this for a vb1 driver,
> then they can do the work to convert that driver to vb2.
>
> I've added Mauro to the CC list and I'll ping a few more people to see what
> they think, but in my opinion support for USERPTR + VM_IO | VM_PFNMAP
> should just be killed off.
>
> If others would like to keep it, then frame_vector.c needs a comment before
> the 'while' explaining why the unsafe_follow_pfn is there and that using
> dmabuf is the proper alternative to use. That will make it easier for
> developers to figure out why they see a kernel warning and what to do to
> fix it, rather than having to dig through the git history for the reason.
I'm all for dropping that code.
Best regards,
Tomasz
>
> Regards,
>
> Hans
>
> >
> > Thanks!
> >
> > Hans
> >
> >> Signed-off-by: Daniel Vetter
> >> Cc: Jason Gunthorpe
> >> Cc: Kees Cook
> >> Cc: Dan Williams
> >> Cc: Andrew Morton
> >> Cc: John Hubbard
> >> Cc: Jérôme Glisse
> >> Cc: Jan Kara
> >> Cc: Dan Williams
> >> Cc: linux...@kvack.org
> >> Cc: linux-arm-ker...@lists.infradead.org
> >> Cc: linux-samsung-...@vger.kernel.org
> >> Cc: linux-me...@vger.kernel.org
> >> Cc: Pawel Osciak
> >> Cc: Marek Szyprowski
> >> Cc: Kyungmin Park
> >> Cc: Tomasz Figa
> >> Cc: Laurent Dufour
> >> Cc: Vlastimil Babka
> >> Cc: Daniel Jordan
> >> Cc: Michel Lespinasse
> >> Signed-off-by: Daniel Vetter
> >> --
> >> v3:
> >> - Reference the commit that enabled the zerocopy userptr use case to
> >> make it abundandtly clear that this patch only affects that, and not
> >> normal memory userptr. The old commit message already explained that
> >> normal memory userptr is unaffected, but I guess that was not clear
> >> enough.
> >> ---
> >> drivers/media/common/videobuf2/frame_vector.c | 2 +-
> >> drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
> >> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/common/videobuf2/frame_vector.c
> >> b/drivers/media/common/videobuf2/frame_vector.c
> >> index a0e65481a201..1a82ec13ea00 100644
> >> --- a/drivers/media/common/videobuf2/frame_vector.c
> >> +++ b/drivers/media/common/videobuf2/frame_vector.c
> >> @@ -70,7 +70,7 @@ int get_vaddr_frames(unsigned long start, unsigned int
> >> nr_frames,
> >> break;
> >>
> >> while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
> >> -err = follow_pfn(vma, start, &nums[ret]);
> >> +err = unsafe_follow_pfn(vma, start, &nums[ret]);
> >> if (err) {
> >> if (ret == 0)
> >> ret = err;
> >> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
> >> b/drivers/media/v4l2-core/videobuf-dma-contig.c
> >> index 52312ce2ba05..821c4a76ab96 100644
> >> --- a/drivers/media/v4l2-core/videobuf-dma-contig.c
> >> +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
> >> @@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct
> >> videobuf_dma_contig_memory *mem,
> >> user_address = untagged_baddr;
> >>
> >> while (pages_done < (mem->size >> PAGE_SHIFT)) {
> >> -ret = follow_pfn(vma, user_address, &this_pfn);
> >> +ret = unsafe_follow_pfn(vma, user_ad
Re: [PATCH] drm/kmb: Remove an unnecessary NULL check
Hi Am 20.11.20 um 09:21 schrieb Sam Ravnborg: Hi Anitha. On Fri, Nov 20, 2020 at 01:19:06AM +, Chrisanthus, Anitha wrote: Looks good to me. Can we get either an "Acked-by:" or "Reviewed-by:"? Then we can use this while applying. Any news on gettting commit access yourself? If not, then try to ping on the open ticket. It's been acked a while ago. I sent out a reminder to Daniel Stone. Best regards Thomas Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/5] console: Miscellaneous clean-ups, do not use FNTCHARCNT() in fbcon.c
On Thu, Nov 19, 2020 at 04:10:57PM +0100, Daniel Vetter wrote:
> On Thu, Nov 19, 2020 at 9:33 AM Peilin Ye wrote:
> > setfont seems to work fine, I tried Georgian-Fixed16 (256 chars) and
> > Uni2-VGA16 (512 chars) under /usr/share/consolefonts/ in my Ubuntu box,
> > including setting all consoles to the same font:
> >
> > for i in {1..6}; do
> > sudo setfont -C /dev/tty${i}
> > /usr/share/consolefonts/Georgian-Fixed16.psf.gz
> > done
> >
> > Font rotation also seems to work fine:
> >
> > for i in {1..4}; do
> > echo $i | sudo tee /sys/class/graphics/fbcon/rotate
> > sleep 1
> > done
>
> Thanks a lot for checking all this.
Not a problem, watching my console rotating was fun :)
> > One last thing I can think of is tile blitting, but I don't have the
> > hardware (e.g. a Matrox G400 card, see FB_TILEBLITTING in
> > drivers/video/fbdev/Kconfig) at hand, nor did I figure out how to
> > simulate it after searching for a while. However based on the other
> > tests above I believe vc->vc_font.charcount is set properly.
>
> tbh I'll just go ahead and delete it if it's broken :-)
>
> Userspace we have to keep working (and there's actually people
> creating new products on top of drm display drivers using fbdev
> emulation and /dev/fb/0 interface!), but kernel internal stuff like
> fbcon acceleration we can trim pretty aggressively I think.
Ah, I see, I'll leave it be, then.
Thanks,
Peilin Ye
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm: Introduce an atomic_commit_setup function
Hi
Am 19.11.20 um 16:32 schrieb Daniel Vetter:
On Thu, Nov 19, 2020 at 10:59:42AM +0100, Thomas Zimmermann wrote:
Hi
Am 13.11.20 um 16:29 schrieb Maxime Ripard:
Private objects storing a state shared across all CRTCs need to be
carefully handled to avoid a use-after-free issue.
The proper way to do this to track all the commits using that shared
state and wait for the previous commits to be done before going on with
the current one to avoid the reordering of commits that could occur.
However, this commit setup needs to be done after
drm_atomic_helper_setup_commit(), because before the CRTC commit
structure hasn't been allocated before, and before the workqueue is
scheduled, because we would be potentially reordered already otherwise.
That means that drivers currently have to roll their own
drm_atomic_helper_commit() function, even though it would be identical
if not for the commit setup.
Let's introduce a hook to do so that would be called as part of
drm_atomic_helper_commit, allowing us to reuse the atomic helpers.
Suggested-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_helper.c | 6 ++
include/drm/drm_modeset_helper_vtables.h | 18 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ddd0e3239150..7d69c7844dfc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2083,8 +2083,11 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
struct drm_plane *plane;
struct drm_plane_state *old_plane_state, *new_plane_state;
struct drm_crtc_commit *commit;
+ const struct drm_mode_config_helper_funcs *funcs;
int i, ret;
+ funcs = state->dev->mode_config.helper_private;
+
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
commit = kzalloc(sizeof(*commit), GFP_KERNEL);
if (!commit)
@@ -2169,6 +2172,9 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
new_plane_state->commit = drm_crtc_commit_get(commit);
}
+ if (funcs && funcs->atomic_commit_setup)
+ return funcs->atomic_commit_setup(state);
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_helper_setup_commit);
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index f2de050085be..56470baf0513 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1396,6 +1396,24 @@ struct drm_mode_config_helper_funcs {
* drm_atomic_helper_commit_tail().
*/
void (*atomic_commit_tail)(struct drm_atomic_state *state);
+
+ /**
+* @atomic_commit_setup:
+*
+* This hook is used by the default atomic_commit() hook implemented in
+* drm_atomic_helper_commit() together with the nonblocking helpers (see
+* drm_atomic_helper_setup_commit()) to extend the DRM commit setup. It
+* is not used by the atomic helpers.
+*
+* This function is called at the end of
+* drm_atomic_helper_setup_commit(), so once the commit has been
+* properly setup across the generic DRM object states. It allows
+* drivers to do some additional commit tracking that isn't related to a
+* CRTC, plane or connector, typically a private object.
+*
+* This hook is optional.
+*/
+ int (*atomic_commit_setup)(struct drm_atomic_state *state);
It feels hacky and screwed-on to me. I'd suggest to add an
atomic_commit_prepare callback that is called by drm_atomic_helper where it
currently calls drm_atomic_helper_setup_commit(). The default implementation
would include setup_commit and prepare_planes. Some example code for
drm_atomic_helper.c
static int commit_prepare(state)
{
drm_atomic_helper_setup_commit(state)
drm_atomic_helper_prepare_planes(state)
}
int drm_atomic_helper_commit()
{
if (async_update) {
...
}
if (funcs->atomic_commit_prepare)
funcs->atomic_commit_prepare(state)
else
commit_prepare(state)
/* the rest of the current function below */
INIT_WORK(&state->commit_work, commit_work);
...
}
Drivers that implement atomic_commit_prepare would be expected to call
drm_atomic_helper_setup_commit() and drm_atomic_helper_prepare_planes() or
their own implementation of them.
The whole construct mimics how commit tails work.
Yeah what I suggested is a bit much midlayer, but we've done what you
suggested above with all drivers rolling their own atomic_commit. It
wasn't pretty. There's still drivers like vc4 which haven't switched, and
which have their own locking and synchronization.
Hence why I think the callback approach here is better, gives drivers less
excuses to
[PATCH] drm/dp: Add dpcd backlight control for 0x4c83 0x4f41
Signed-off-by: Kai-Chuan Hsieh
---
drivers/gpu/drm/drm_dp_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index deeed73f4ed6..6789e30a3cba 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1882,6 +1882,7 @@ static const struct edid_quirk edid_quirk_list[] = {
{ MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4c, 0x83), PROD_ID(0x47, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
+ { MFG(0x4c, 0x83), PROD_ID(0x4f, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
};
#undef MFG
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 07/23] mtd: spi-nor: hisi-sfc: Demote non-conformant kernel-doc
On Mon, 2020-11-09 at 18:21:50 UTC, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter > or member 'np' not described in 'hisi_spi_nor_register' > drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter > or member 'host' not described in 'hisi_spi_nor_register' > > Cc: Tudor Ambarus > Cc: Miquel Raynal > Cc: Richard Weinberger > Cc: Vignesh Raghavendra > Cc: Sumit Semwal > Cc: "Christian König" > Cc: linux-...@lists.infradead.org > Cc: linux-me...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linaro-mm-...@lists.linaro.org > Signed-off-by: Lee Jones > Reviewed-by: Vignesh Raghavendra Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks. Miquel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: dsi: Modify horizontal front/back porch byte formula
Hi CK,
On Fri, 20 Nov 2020 07:23:35 +0800
Chun-Kuang Hu wrote:
> From: CK Hu
>
> In the patch to be fixed, horizontal_backporch_byte become to large
> for some panel, so roll back that patch. For small hfp or hbp panel,
> using vm->hfront_porch + vm->hback_porch to calculate
> horizontal_backporch_byte would make it negtive, so
> use horizontal_backporch_byte itself to make it positive.
>
> Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of panel with
> small hfp or hbp")
>
> Signed-off-by: CK Hu
> Signed-off-by: Chun-Kuang Hu
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 61
> +++--- 1 file changed, 22 insertions(+), 39
> deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c index 4a188a942c38..65fd99c528af
> 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -444,7 +444,10 @@ static void mtk_dsi_config_vdo_timing(struct
> mtk_dsi *dsi) u32 horizontal_sync_active_byte;
> u32 horizontal_backporch_byte;
> u32 horizontal_frontporch_byte;
> + u32 horizontal_front_back_byte;
> + u32 data_phy_cycles_byte;
> u32 dsi_tmp_buf_bpp, data_phy_cycles;
> + u32 delta;
> struct mtk_phy_timing *timing = &dsi->phy_timing;
>
> struct videomode *vm = &dsi->vm;
> @@ -466,50 +469,30 @@ static void mtk_dsi_config_vdo_timing(struct
> mtk_dsi *dsi) horizontal_sync_active_byte = (vm->hsync_len *
> dsi_tmp_buf_bpp - 10);
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> - horizontal_backporch_byte = vm->hback_porch *
> dsi_tmp_buf_bpp;
> + horizontal_backporch_byte = vm->hback_porch *
> dsi_tmp_buf_bpp - 10; else
> horizontal_backporch_byte = (vm->hback_porch +
> vm->hsync_len) *
> - dsi_tmp_buf_bpp;
> + dsi_tmp_buf_bpp - 10;
>
> data_phy_cycles = timing->lpx + timing->da_hs_prepare +
> - timing->da_hs_zero + timing->da_hs_exit;
> -
> - if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> - if ((vm->hfront_porch + vm->hback_porch) *
> dsi_tmp_buf_bpp >
> - data_phy_cycles * dsi->lanes + 18) {
> - horizontal_frontporch_byte =
> - vm->hfront_porch * dsi_tmp_buf_bpp -
> - (data_phy_cycles * dsi->lanes + 18) *
> - vm->hfront_porch /
> - (vm->hfront_porch + vm->hback_porch);
> -
> - horizontal_backporch_byte =
> - horizontal_backporch_byte -
> - (data_phy_cycles * dsi->lanes + 18) *
> - vm->hback_porch /
> - (vm->hfront_porch + vm->hback_porch);
> - } else {
> - DRM_WARN("HFP less than d-phy, FPS will
> under 60Hz\n");
> - horizontal_frontporch_byte =
> vm->hfront_porch *
> - dsi_tmp_buf_bpp;
> - }
> + timing->da_hs_zero + timing->da_hs_exit +
> 3; +
> + delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 :
> 12; +
> + horizontal_frontporch_byte = vm->hfront_porch *
> dsi_tmp_buf_bpp;
> + horizontal_front_back_byte = horizontal_frontporch_byte +
> horizontal_backporch_byte;
> + data_phy_cycles_byte = data_phy_cycles * dsi->lanes + delta;
> +
> + if (horizontal_front_back_byte > data_phy_cycles_byte) {
> + horizontal_frontporch_byte -= data_phy_cycles_byte *
> +
> horizontal_frontporch_byte /
> +
> horizontal_front_back_byte; +
> + horizontal_backporch_byte -= data_phy_cycles_byte *
> +
> horizontal_backporch_byte /
> +
> horizontal_front_back_byte; } else {
> - if ((vm->hfront_porch + vm->hback_porch) *
> dsi_tmp_buf_bpp >
> - data_phy_cycles * dsi->lanes + 12) {
> - horizontal_frontporch_byte =
> - vm->hfront_porch * dsi_tmp_buf_bpp -
> - (data_phy_cycles * dsi->lanes + 12) *
> - vm->hfront_porch /
> - (vm->hfront_porch + vm->hback_porch);
> - horizontal_backporch_byte =
> horizontal_backporch_byte -
> - (data_phy_cycles * dsi->lanes + 12) *
> - vm->hback_porch /
> - (vm->hfront_porch + vm->hback_porch);
> - } else {
> - DRM_WARN("HFP less than d-phy, FPS will
> under 60Hz\n");
> - horizontal_frontporch_byte =
> vm->hfront_porch *
> - dsi_tmp_buf_bpp;
> - }
> + DRM_WARN("HFP + HBP less than d-phy, FPS will under
> 60Hz\n"); }
>
> writel(ho
[PATCH] video: goldfishfb: remove casting dma_alloc_coherent
Remove casting the values returned by dma_alloc_coherent.
Signed-off-by: Xu Wang
---
drivers/video/fbdev/goldfishfb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 9c83ec3f8e1f..c2f386b35617 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -238,8 +238,7 @@ static int goldfish_fb_probe(struct platform_device *pdev)
fb->fb.var.blue.length = 5;
framesize = width * height * 2 * 2;
- fb->fb.screen_base = (char __force __iomem *)dma_alloc_coherent(
- &pdev->dev, framesize,
+ fb->fb.screen_base = dma_alloc_coherent(&pdev->dev, framesize,
&fbpaddr, GFP_KERNEL);
pr_debug("allocating frame buffer %d * %d, got %p\n",
width, height, fb->fb.screen_base);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 07/11] dt-bindings: phy: convert MIP DSI PHY binding to YAML schema
On Fri, 2020-11-20 at 07:38 +0800, Chun-Kuang Hu wrote:
> Hi, Chunfeng:
>
> Chunfeng Yun 於 2020年11月18日 週三 下午4:21寫道：
> >
> > Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
> >
> > Cc: Chun-Kuang Hu
> > Signed-off-by: Chunfeng Yun
> > ---
> > v3: new patch
> > ---
> > .../display/mediatek/mediatek,dsi.txt | 18 +---
> > .../bindings/phy/mediatek,dsi-phy.yaml| 83 +++
> > 2 files changed, 84 insertions(+), 17 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > index f06f24d405a5..8238a86686be 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > @@ -22,23 +22,7 @@ Required properties:
> > MIPI TX Configuration Module
> >
> >
> > -The MIPI TX configuration module controls the MIPI D-PHY.
> > -
> > -Required properties:
> > -- compatible: "mediatek,-mipi-tx"
> > -- the supported chips are mt2701, 7623, mt8173 and mt8183.
> > -- reg: Physical base address and length of the controller's registers
> > -- clocks: PLL reference clock
> > -- clock-output-names: name of the output clock line to the DSI encoder
> > -- #clock-cells: must be <0>;
> > -- #phy-cells: must be <0>.
> > -
> > -Optional properties:
> > -- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000.
> > And
> > - the step is 200.
> > -- nvmem-cells: A phandle to the calibration data provided by a nvmem
> > device. If
> > - unspecified default values shall be used.
> > -- nvmem-cell-names: Should be "calibration-data"
> > +See phy/mediatek,dsi-phy.yaml
> >
> > Example:
> >
> > diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> > b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> > new file mode 100644
> > index ..87f8df251ab0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> > @@ -0,0 +1,83 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/mediatek,dsi-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MediaTek MIPI Display Serial Interface (DSI) PHY binding
> > +
> > +maintainers:
> > + - Chun-Kuang Hu
> > + - Chunfeng Yun
>
> Please add Philipp Zabel because he is Mediatek DRM driver maintainer.
Ok
>
> DRM DRIVERS FOR MEDIATEK
> M: Chun-Kuang Hu
> M: Philipp Zabel
> L: dri-devel@lists.freedesktop.org
> S: Supported
> F: Documentation/devicetree/bindings/display/mediatek/
>
> > +
> > +description: The MIPI DSI PHY supports up to 4-lane output.
> > +
> > +properties:
> > + $nodename:
> > +pattern: "^dsi-phy@[0-9a-f]+$"
> > +
> > + compatible:
> > +enum:
> > + - mediatek,mt2701-mipi-tx
> > + - mediatek,mt7623-mipi-tx
> > + - mediatek,mt8173-mipi-tx
>
> Add mediatek,mt8183-mipi-tx
Ok, will add it
Thanks
>
> Regards,
> Chun-Kuang.
>
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +items:
> > + - description: PLL reference clock
> > +
> > + clock-output-names:
> > +maxItems: 1
> > +
> > + "#phy-cells":
> > +const: 0
> > +
> > + "#clock-cells":
> > +const: 0
> > +
> > + nvmem-cells:
> > +maxItems: 1
> > +description: A phandle to the calibration data provided by a nvmem
> > device,
> > + if unspecified, default values shall be used.
> > +
> > + nvmem-cell-names:
> > +items:
> > + - const: calibration-data
> > +
> > + drive-strength-microamp:
> > +description: adjust driving current, the step is 200.
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +minimum: 2000
> > +maximum: 6000
> > +default: 4600
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-output-names
> > + - "#phy-cells"
> > + - "#clock-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +dsi-phy@10215000 {
> > +compatible = "mediatek,mt8173-mipi-tx";
> > +reg = <0x10215000 0x1000>;
> > +clocks = <&clk26m>;
> > +clock-output-names = "mipi_tx0_pll";
> > +drive-strength-microamp = <4000>;
> > +nvmem-cells= <&mipi_tx_calibration>;
> > +nvmem-cell-names = "calibration-data";
> > +#clock-cells = <0>;
> > +#phy-cells = <0>;
> > +};
> > +
> > +...
> > --
> > 2.18.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 06/11] dt-bindings: phy: convert HDMI PHY binding to YAML schema
On Fri, 2020-11-20 at 07:42 +0800, Chun-Kuang Hu wrote:
> Hi, Chunfeng:
>
> Chunfeng Yun 於 2020年11月18日 週三 下午4:21寫道：
> >
> > Convert HDMI PHY binding to YAML schema mediatek,hdmi-phy.yaml
> >
> > Cc: Chun-Kuang Hu
> > Signed-off-by: Chunfeng Yun
> > Reviewed-by: Rob Herring
> > ---
> > v3: add Reviewed-by Rob
> > v2: fix binding check warning of reg in example
> > ---
> > .../display/mediatek/mediatek,hdmi.txt| 18 +---
> > .../bindings/phy/mediatek,hdmi-phy.yaml | 91 +++
> > 2 files changed, 92 insertions(+), 17 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> > index 6b1c586403e4..b284ca51b913 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> > @@ -53,23 +53,7 @@ Required properties:
> >
> > HDMI PHY
> >
> > -
> > -The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
> > -output and drives the HDMI pads.
> > -
> > -Required properties:
> > -- compatible: "mediatek,-hdmi-phy"
> > -- the supported chips are mt2701, mt7623 and mt8173
> > -- reg: Physical base address and length of the module's registers
> > -- clocks: PLL reference clock
> > -- clock-names: must contain "pll_ref"
> > -- clock-output-names: must be "hdmitx_dig_cts" on mt8173
> > -- #phy-cells: must be <0>
> > -- #clock-cells: must be <0>
> > -
> > -Optional properties:
> > -- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
> > -- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
> > +See phy/mediatek,hdmi-phy.yaml
> >
> > Example:
> >
> > diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> > b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> > new file mode 100644
> > index ..96700bb8bc00
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> > @@ -0,0 +1,91 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/mediatek,hdmi-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MediaTek High Definition Multimedia Interface (HDMI) PHY binding
> > +
> > +maintainers:
> > + - Chun-Kuang Hu
> > + - Chunfeng Yun
>
> Please add Philipp Zabel because he is Mediatek DRM driver maintainer.
Ok, will do it
Thanks a lot
>
> DRM DRIVERS FOR MEDIATEK
> M: Chun-Kuang Hu
> M: Philipp Zabel
> L: dri-devel at lists.freedesktop.org
> S: Supported
> F: Documentation/devicetree/bindings/display/mediatek/
>
> Regards,
> Chun-Kuang.
>
> > +
> > +description: |
> > + The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
> > + output and drives the HDMI pads.
> > +
> > +properties:
> > + $nodename:
> > +pattern: "^hdmi-phy@[0-9a-f]+$"
> > +
> > + compatible:
> > +enum:
> > + - mediatek,mt2701-hdmi-phy
> > + - mediatek,mt7623-hdmi-phy
> > + - mediatek,mt8173-hdmi-phy
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +items:
> > + - description: PLL reference clock
> > +
> > + clock-names:
> > +items:
> > + - const: pll_ref
> > +
> > + clock-output-names:
> > +items:
> > + - const: hdmitx_dig_cts
> > +
> > + "#phy-cells":
> > +const: 0
> > +
> > + "#clock-cells":
> > +const: 0
> > +
> > + mediatek,ibias:
> > +description:
> > + TX DRV bias current for < 1.65Gbps
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +minimum: 0
> > +maximum: 63
> > +default: 0xa
> > +
> > + mediatek,ibias_up:
> > +description:
> > + TX DRV bias current for >= 1.65Gbps
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +minimum: 0
> > +maximum: 63
> > +default: 0x1c
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - clock-output-names
> > + - "#phy-cells"
> > + - "#clock-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +hdmi_phy: hdmi-phy@10209100 {
> > +compatible = "mediatek,mt8173-hdmi-phy";
> > +reg = <0x10209100 0x24>;
> > +clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
> > +clock-names = "pll_ref";
> > +clock-output-names = "hdmitx_dig_cts";
> > +mediatek,ibias = <0xa>;
> > +mediatek,ibias_up = <0x1c>;
> > +#clock-cells = <0>;
> > +#phy-cells = <0>;
> > +};
> > +
> > +...
> > --
> > 2.18.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: remove unused varibles
fixed the following warnings
drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
Signed-off-by: Tian Tao
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7aa4286..9465f56 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1228,7 +1228,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
{
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
- struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (ttm_tt_is_populated(ttm))
@@ -1242,7 +1241,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
}
drm = nouveau_bdev(bdev);
- dev = drm->dev->dev;
return ttm_pool_alloc(&drm->ttm.bdev.pool, ttm, ctx);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 07/17] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
18.11.2020 07:21, Viresh Kumar пишет:
...
+ /* legacy device-trees don't have OPP table and must be updated */
+ if (!device_property_present(&pdev->dev, "operating-points-v2")) {
+ dev_err(&pdev->dev,
+ "OPP table not found, please update your device
tree\n");
+ return -ENODEV;
+ }
+
>>>
>>> You forgot to remove this ?
>>
>> Yes, good catch. I'm planning to replace this code with a common helper
>> sometime soon, so if there won't be another reasons to make a new
>> revision, then I'd prefer to keep it as-is for now.
>
> You should just replace this patch only with a version of V9.1 and you
> aren't really required to resend the whole series. And you should fix
> it before it gets merged. This isn't a formatting issue which we just
> let through. I trust you when you say that you will fix it, but this
> must be fixed now.
>
Should be easier to resend it all. I'll update it over the weekend, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
general protection fault in drm_atomic_set_crtc_for_connector
Hello, syzbot found the following issue on: HEAD commit:03430750 Add linux-next specific files for 20201116 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=123c946a50 kernel config: https://syzkaller.appspot.com/x/.config?x=a1c4c3f27041fdb8 dashboard link: https://syzkaller.appspot.com/bug?extid=1aec08e752387f55c449 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1521398150 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1659041650 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+1aec08e752387f55c...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc00: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x-0x0007] CPU: 1 PID: 8503 Comm: syz-executor619 Not tainted 5.10.0-rc3-next-20201116-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:drm_atomic_set_crtc_for_connector+0x426/0x5f0 drivers/gpu/drm/drm_atomic_uapi.c:342 Code: 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e a6 00 00 00 48 b8 00 00 00 00 00 fc ff df 41 8b 4d 28 <80> 38 00 0f 85 83 01 00 00 48 8b 2c 25 00 00 00 00 48 b8 00 00 00 RSP: 0018:c900018bf938 EFLAGS: 00010246 RAX: dc00 RBX: 8880116b0100 RCX: 0022 RDX: 111003019a66 RSI: 84302d10 RDI: 8880180cd330 RBP: R08: 888018051900 R09: 8880180cd343 R10: R11: R12: 88801a024800 R13: 8880180cd308 R14: 8880116b0108 R15: 88801cd1b700 FS: () GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 006cf0a0 CR3: 0b08e000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: update_output_state drivers/gpu/drm/drm_atomic.c:1454 [inline] __drm_atomic_helper_set_config+0x72a/0xe80 drivers/gpu/drm/drm_atomic.c:1568 drm_client_modeset_commit_atomic+0x527/0x7c0 drivers/gpu/drm/drm_client_modeset.c:1023 drm_client_modeset_commit_locked+0x145/0x580 drivers/gpu/drm/drm_client_modeset.c:1145 drm_client_modeset_commit+0x4d/0x80 drivers/gpu/drm/drm_client_modeset.c:1171 __drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:252 [inline] __drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:231 [inline] drm_fb_helper_restore_fbdev_mode_unlocked drivers/gpu/drm/drm_fb_helper.c:279 [inline] drm_fb_helper_lastclose drivers/gpu/drm/drm_fb_helper.c:1942 [inline] drm_fbdev_client_restore+0xe3/0x1a0 drivers/gpu/drm/drm_fb_helper.c:2334 drm_client_dev_restore+0x17f/0x270 drivers/gpu/drm/drm_client.c:226 drm_lastclose drivers/gpu/drm/drm_file.c:468 [inline] drm_release+0x441/0x530 drivers/gpu/drm/drm_file.c:499 __fput+0x283/0x920 fs/file_table.c:280 task_work_run+0xdd/0x190 kernel/task_work.c:140 exit_task_work include/linux/task_work.h:30 [inline] do_exit+0xb9b/0x29f0 kernel/exit.c:823 do_group_exit+0x125/0x310 kernel/exit.c:920 __do_sys_exit_group kernel/exit.c:931 [inline] __se_sys_exit_group kernel/exit.c:929 [inline] __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:929 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x443b18 Code: Unable to access opcode bytes at RIP 0x443aee. RSP: 002b:7fff6ec2d738 EFLAGS: 0246 ORIG_RAX: 00e7 RAX: ffda RBX: RCX: 00443b18 RDX: RSI: 003c RDI: RBP: 004c34f0 R08: 00e7 R09: ffd0 R10: R11: 0246 R12: 0001 R13: 006d5180 R14: R15: Modules linked in: ---[ end trace f24317b9689e8a7a ]--- RIP: 0010:drm_atomic_set_crtc_for_connector+0x426/0x5f0 drivers/gpu/drm/drm_atomic_uapi.c:342 Code: 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e a6 00 00 00 48 b8 00 00 00 00 00 fc ff df 41 8b 4d 28 <80> 38 00 0f 85 83 01 00 00 48 8b 2c 25 00 00 00 00 48 b8 00 00 00 RSP: 0018:c900018bf938 EFLAGS: 00010246 RAX: dc00 RBX: 8880116b0100 RCX: 0022 RDX: 111003019a66 RSI: 84302d10 RDI: 8880180cd330 RBP: R08: 888018051900 R09: 8880180cd343 R10: R11: R12: 88801a024800 R13: 8880180cd308 R14: 8880116b0108 R15: 88801cd1b700 FS: () GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55ee32e491f8 CR3: 18634000 CR4: 001506e0 DR0: DR1: DR2: D
Re: [PATCH v2] drm: document drm_mode_get_connector
On Thursday, November 19, 2020 4:06 PM, Daniel Vetter wrote: > > + /** > > +* @connection: Status of the connector. > > +* > > +* See enum drm_connector_status. > > Please add & so it becomes a link in the generated docs (and pls check > the link goes to the right place). Per [1], just prefixing the enum name with "enum" is enough to generate a link. I prefer this style over the ampersand because it makes the raw text easier to read. The result looks like this [2]. [1]: https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#cross-referencing-from-restructuredtext [2]: https://l.sr.ht/o7Kb.png > > +*/ > > __u32 connection; > > - __u32 mm_width; /**< width in millimeters */ > > - __u32 mm_height; /**< height in millimeters */ > > + /** @mm_width: Width of the connected sink in millimeters. */ > > + __u32 mm_width; > > + /** @mm_height: Height of the connected sink in millimeters. */ > > + __u32 mm_height; > > + /** > > +* @subpixel: Subpixel order of the connected sink. > > +* > > +* See enum subpixel_order. > > Same here. This one doesn't generate a link, because enum subpixel_order is undocumented. As soon as it's documented, the link will be created. The enum is weird in the first place: it has CamelCase members and no drm_ prefix. > With the nits addressed: Reviewed-by: Daniel Vetter I'll fix the other issues you've raised, thanks for the review! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: document drm_mode_get_connector
Document how to perform a GETCONNECTOR ioctl. Document the various
struct fields. Also document how to perform a forced probe, and when
should user-space do it.
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm_mode.h | 78 ++---
1 file changed, 73 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index f29c1d37be67..3979389fcc4f 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -368,27 +368,95 @@ enum drm_mode_subconnector {
#define DRM_MODE_CONNECTOR_WRITEBACK 18
#define DRM_MODE_CONNECTOR_SPI 19
+/**
+ * struct drm_mode_get_connector - Get connector metadata.
+ *
+ * User-space can perform a GETCONNECTOR ioctl to retrieve information about a
+ * connector. User-space is expected to retrieve encoders, modes and properties
+ * by performing this ioctl at least twice: the first time to retrieve the
+ * number of elements, the second time to retrieve the elements themselves.
+ *
+ * To retrieve the number of elements, set @count_props and @count_encoders to
+ * zero, set @count_modes to 1, and set @modes_ptr to a temporary struct
+ * drm_mode_modeinfo element.
+ *
+ * To retrieve the elements, allocate arrays for @encoders_ptr, @modes_ptr,
+ * @props_ptr and @prop_values_ptr, then set @count_modes, @count_props and
+ * @count_encoders to their capacity.
+ *
+ * Performing the ioctl only twice may be racy: the number of elements may have
+ * changed with a hotplug event in-between the two ioctls. User-space is
+ * expected to retry the last ioctl until the number of elements stabilizes.
+ * The kernel won't fill any array which doesn't have the expected length.
+ *
+ * **Force-probing a connector**
+ *
+ * If the @count_modes field is set to zero, the kernel will perform a forced
+ * probe on the connector to refresh the connector status, modes and EDID.
+ * A forced-probe can be slow and the ioctl will block. A force-probe can cause
+ * flickering and temporary freezes, so it should not be performed
+ * automatically.
+ *
+ * User-space shouldn't need to force-probe connectors in general: the kernel
+ * will automatically take care of probing connectors that don't support
+ * hot-plug detection when appropriate. However, user-space may force-probe
+ * connectors on user request (e.g. clicking a "Scan connectors" button, or
+ * opening a UI to manage screens).
+ */
struct drm_mode_get_connector {
-
+ /** @encoders_ptr: Pointer to ``__u32`` array of object IDs. */
__u64 encoders_ptr;
+ /** @modes_ptr: Pointer to struct drm_mode_modeinfo array. */
__u64 modes_ptr;
+ /** @props_ptr: Pointer to ``__u32`` array of property IDs. */
__u64 props_ptr;
+ /** @prop_values_ptr: Pointer to ``__u64`` array of property values. */
__u64 prop_values_ptr;
+ /** @count_modes: Number of modes. */
__u32 count_modes;
+ /** @count_props: Number of properties. */
__u32 count_props;
+ /** @count_encoders: Number of encoders. */
__u32 count_encoders;
- __u32 encoder_id; /**< Current Encoder */
- __u32 connector_id; /**< Id */
+ /** @encoder_id: Object ID of the current encoder. */
+ __u32 encoder_id;
+ /** @connector_id: Object ID of the connector. */
+ __u32 connector_id;
+ /**
+* @connector_type: Type of the connector.
+*
+* See DRM_MODE_CONNECTOR_* defines.
+*/
__u32 connector_type;
+ /**
+* @connector_type_id: Type-specific connector number.
+*
+* This is not an object ID. This is a per-type connector number. Each
+* (type, type_id) combination is unique across all connectors of a DRM
+* device.
+*/
__u32 connector_type_id;
+ /**
+* @connection: Status of the connector.
+*
+* See enum drm_connector_status.
+*/
__u32 connection;
- __u32 mm_width; /**< width in millimeters */
- __u32 mm_height; /**< height in millimeters */
+ /** @mm_width: Width of the connected sink in millimeters. */
+ __u32 mm_width;
+ /** @mm_height: Height of the connected sink in millimeters. */
+ __u32 mm_height;
+ /**
+* @subpixel: Subpixel order of the connected sink.
+*
+* See enum subpixel_order.
+*/
__u32 subpixel;
+ /** @pad: Padding, must be zero. */
__u32 pad;
};
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe
On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
>
> On 20/11/2020 09:06, Hans Verkuil wrote:
> > On 19/11/2020 15:41, Daniel Vetter wrote:
> >> The media model assumes that buffers are all preallocated, so that
> >> when a media pipeline is running we never miss a deadline because the
> >> buffers aren't allocated or available.
> >>
> >> This means we cannot fix the v4l follow_pfn usage through
> >> mmu_notifier, without breaking how this all works. The only real fix
> >> is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
> >> tell everyone to cut over to dma-buf memory sharing for zerocopy.
> >>
> >> userptr for normal memory will keep working as-is, this only affects
> >> the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
> >> videobuf2-dma-sg: Support io userptr operations on io memory").
> >>
> >> Acked-by: Tomasz Figa
> >
> > Acked-by: Hans Verkuil
>
> Actually, cancel this Acked-by.
>
> So let me see if I understand this right: VM_IO | VM_PFNMAP mappings can
> move around. There is a mmu_notifier that can be used to be notified when
> that happens, but that can't be used with media buffers since those buffers
> must always be available and in the same place.
>
> So follow_pfn is replaced by unsafe_follow_pfn to signal that what is
> attempted
> is unsafe and unreliable.
>
> If CONFIG_STRICT_FOLLOW_PFN is set, then unsafe_follow_pfn will fail, if it
> is unset, then it writes a warning to the kernel log but just continues while
> still unsafe.
>
> I am very much inclined to just drop VM_IO | VM_PFNMAP support in the media
> subsystem. For vb2 there is a working alternative in the form of dmabuf, and
> frankly for vb1 I don't care. If someone really needs this for a vb1 driver,
> then they can do the work to convert that driver to vb2.
>
> I've added Mauro to the CC list and I'll ping a few more people to see what
> they think, but in my opinion support for USERPTR + VM_IO | VM_PFNMAP
> should just be killed off.
>
> If others would like to keep it, then frame_vector.c needs a comment before
> the 'while' explaining why the unsafe_follow_pfn is there and that using
> dmabuf is the proper alternative to use. That will make it easier for
> developers to figure out why they see a kernel warning and what to do to
> fix it, rather than having to dig through the git history for the reason.
I'm happy to add a comment, but otherwise if you all want to ditch
this, can we do this as a follow up on top? There's quite a bit of
code that can be deleted and I'd like to not hold up this patch set
here on that - it's already a fairly sprawling pain touching about 7
different subsystems (ok only 6-ish now since the s390 patch landed).
For the comment, is the explanation next to unsafe_follow_pfn not good
enough?
So ... can I get you to un-cancel your ack?
Thanks, Daniel
>
> Regards,
>
> Hans
>
> >
> > Thanks!
> >
> > Hans
> >
> >> Signed-off-by: Daniel Vetter
> >> Cc: Jason Gunthorpe
> >> Cc: Kees Cook
> >> Cc: Dan Williams
> >> Cc: Andrew Morton
> >> Cc: John Hubbard
> >> Cc: Jérôme Glisse
> >> Cc: Jan Kara
> >> Cc: Dan Williams
> >> Cc: linux...@kvack.org
> >> Cc: linux-arm-ker...@lists.infradead.org
> >> Cc: linux-samsung-...@vger.kernel.org
> >> Cc: linux-me...@vger.kernel.org
> >> Cc: Pawel Osciak
> >> Cc: Marek Szyprowski
> >> Cc: Kyungmin Park
> >> Cc: Tomasz Figa
> >> Cc: Laurent Dufour
> >> Cc: Vlastimil Babka
> >> Cc: Daniel Jordan
> >> Cc: Michel Lespinasse
> >> Signed-off-by: Daniel Vetter
> >> --
> >> v3:
> >> - Reference the commit that enabled the zerocopy userptr use case to
> >> make it abundandtly clear that this patch only affects that, and not
> >> normal memory userptr. The old commit message already explained that
> >> normal memory userptr is unaffected, but I guess that was not clear
> >> enough.
> >> ---
> >> drivers/media/common/videobuf2/frame_vector.c | 2 +-
> >> drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
> >> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/common/videobuf2/frame_vector.c
> >> b/drivers/media/common/videobuf2/frame_vector.c
> >> index a0e65481a201..1a82ec13ea00 100644
> >> --- a/drivers/media/common/videobuf2/frame_vector.c
> >> +++ b/drivers/media/common/videobuf2/frame_vector.c
> >> @@ -70,7 +70,7 @@ int get_vaddr_frames(unsigned long start, unsigned int
> >> nr_frames,
> >> break;
> >>
> >> while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
> >> -err = follow_pfn(vma, start, &nums[ret]);
> >> +err = unsafe_follow_pfn(vma, start, &nums[ret]);
> >> if (err) {
> >> if (ret == 0)
> >> ret = err;
> >> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
> >> b/drivers/media/v4l2-core/videobuf-dma-contig.c
> >> index 52312ce2ba05..821c4a76ab96 100644
> >> --- a/drivers/medi
Re: [PATCH v2] drm: document drm_mode_get_connector
On Fri, Nov 20, 2020 at 9:46 AM Simon Ser wrote: > > On Thursday, November 19, 2020 4:06 PM, Daniel Vetter wrote: > > > > + /** > > > +* @connection: Status of the connector. > > > +* > > > +* See enum drm_connector_status. > > > > Please add & so it becomes a link in the generated docs (and pls check > > the link goes to the right place). > > Per [1], just prefixing the enum name with "enum" is enough to generate a > link. > I prefer this style over the ampersand because it makes the raw text easier to > read. The result looks like this [2]. > > [1]: > https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#cross-referencing-from-restructuredtext > [2]: https://l.sr.ht/o7Kb.png Ah nice, I missed that this was updated. We have a ton of & in our kerneldoc that probably could be dropped ... -Daniel > > > > +*/ > > > __u32 connection; > > > - __u32 mm_width; /**< width in millimeters */ > > > - __u32 mm_height; /**< height in millimeters */ > > > + /** @mm_width: Width of the connected sink in millimeters. */ > > > + __u32 mm_width; > > > + /** @mm_height: Height of the connected sink in millimeters. */ > > > + __u32 mm_height; > > > + /** > > > +* @subpixel: Subpixel order of the connected sink. > > > +* > > > +* See enum subpixel_order. > > > > Same here. > > This one doesn't generate a link, because enum subpixel_order is undocumented. > As soon as it's documented, the link will be created. > > The enum is weird in the first place: it has CamelCase members and no drm_ > prefix. > > > With the nits addressed: Reviewed-by: Daniel Vetter > > I'll fix the other issues you've raised, thanks for the review! -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: goldfishfb: remove casting dma_alloc_coherent
Hi
Am 20.11.20 um 09:23 schrieb Xu Wang:
Remove casting the values returned by dma_alloc_coherent.
Signed-off-by: Xu Wang
---
drivers/video/fbdev/goldfishfb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 9c83ec3f8e1f..c2f386b35617 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -238,8 +238,7 @@ static int goldfish_fb_probe(struct platform_device *pdev)
fb->fb.var.blue.length = 5;
framesize = width * height * 2 * 2;
- fb->fb.screen_base = (char __force __iomem *)dma_alloc_coherent(
- &pdev->dev, framesize,
+ fb->fb.screen_base = dma_alloc_coherent(&pdev->dev, framesize,
&fbpaddr, GFP_KERNEL);
But dma_alloc_coherent() returns void*. I wonder if this change wouldn't
result in a warning from the compiler.
Best regards
Thomas
pr_debug("allocating frame buffer %d * %d, got %p\n",
width, height, fb->fb.screen_base);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/virtio: use fence_id when processing fences
On Wed, Nov 18, 2020 at 05:08:08PM -0800, Gurchetan Singh wrote:
Currently, the fence ID, which can be used to identify a
virtgpu fence, is the same as the fence sequence number.
Let's use the fence_id name to clearly signal this.
Signed-off-by: Gurchetan Singh
Reviewed-by: Anthoine Bourgeois
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_fence.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index c94052376d18..7c7967a2eb84 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -420,7 +420,7 @@ void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
struct virtio_gpu_ctrl_hdr *cmd_hdr,
struct virtio_gpu_fence *fence);
void virtio_gpu_fence_event_process(struct virtio_gpu_device *vdev,
- u64 last_seq);
+ u64 fence_id);
/* virtgpu_object.c */
void virtio_gpu_cleanup_object(struct virtio_gpu_object *bo);
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 5b2a4146c5bd..2fe9c7ebcbd4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -112,16 +112,16 @@ void virtio_gpu_fence_emit(struct virtio_gpu_device
*vgdev,
}
void virtio_gpu_fence_event_process(struct virtio_gpu_device *vgdev,
- u64 last_seq)
+ u64 fence_id)
{
struct virtio_gpu_fence_driver *drv = &vgdev->fence_drv;
struct virtio_gpu_fence *fence, *tmp;
unsigned long irq_flags;
spin_lock_irqsave(&drv->lock, irq_flags);
- atomic64_set(&vgdev->fence_drv.last_seq, last_seq);
+ atomic64_set(&vgdev->fence_drv.last_seq, fence_id);
list_for_each_entry_safe(fence, tmp, &drv->fences, node) {
- if (last_seq < fence->f.seqno)
+ if (fence_id < fence->f.seqno)
continue;
dma_fence_signal_locked(&fence->f);
list_del(&fence->node);
--
2.29.2.299.gdc1121823c-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/virtio: rename sync_seq and last_seq
On Wed, Nov 18, 2020 at 05:08:09PM -0800, Gurchetan Singh wrote:
To be clearer about our intentions to associate sequence numbers
and fence IDs, let's rename these variables.
Signed-off-by: Gurchetan Singh
Reviewed-by: Anthoine Bourgeois
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio/virtgpu_fence.c | 9 +
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index f336a8fa..5fefc88d47e4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -67,8 +67,8 @@ virtio_gpu_debugfs_irq_info(struct seq_file *m, void *data)
struct virtio_gpu_device *vgdev = node->minor->dev->dev_private;
seq_printf(m, "fence %llu %lld\n",
- (u64)atomic64_read(&vgdev->fence_drv.last_seq),
- vgdev->fence_drv.sync_seq);
+ (u64)atomic64_read(&vgdev->fence_drv.last_fence_id),
+ vgdev->fence_drv.current_fence_id);
return 0;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 7c7967a2eb84..6a232553c99b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -127,8 +127,8 @@ typedef void (*virtio_gpu_resp_cb)(struct virtio_gpu_device
*vgdev,
struct virtio_gpu_vbuffer *vbuf);
struct virtio_gpu_fence_driver {
- atomic64_t last_seq;
- uint64_t sync_seq;
+ atomic64_t last_fence_id;
+ uint64_t current_fence_id;
uint64_t context;
struct list_head fences;
spinlock_t lock;
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 2fe9c7ebcbd4..728ca36f6327 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -48,7 +48,7 @@ static bool virtio_fence_signaled(struct dma_fence *f)
/* leaked fence outside driver before completing
* initialization with virtio_gpu_fence_emit */
return false;
- if (atomic64_read(&fence->drv->last_seq) >= fence->f.seqno)
+ if (atomic64_read(&fence->drv->last_fence_id) >= fence->f.seqno)
return true;
return false;
}
@@ -62,7 +62,8 @@ static void virtio_timeline_value_str(struct dma_fence *f,
char *str, int size)
{
struct virtio_gpu_fence *fence = to_virtio_fence(f);
- snprintf(str, size, "%llu", (u64)atomic64_read(&fence->drv->last_seq));
+ snprintf(str, size, "%llu",
+(u64)atomic64_read(&fence->drv->last_fence_id));
}
static const struct dma_fence_ops virtio_fence_ops = {
@@ -100,7 +101,7 @@ void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
unsigned long irq_flags;
spin_lock_irqsave(&drv->lock, irq_flags);
- fence->f.seqno = ++drv->sync_seq;
+ fence->f.seqno = ++drv->current_fence_id;
dma_fence_get(&fence->f);
list_add_tail(&fence->node, &drv->fences);
spin_unlock_irqrestore(&drv->lock, irq_flags);
@@ -119,7 +120,7 @@ void virtio_gpu_fence_event_process(struct
virtio_gpu_device *vgdev,
unsigned long irq_flags;
spin_lock_irqsave(&drv->lock, irq_flags);
- atomic64_set(&vgdev->fence_drv.last_seq, fence_id);
+ atomic64_set(&vgdev->fence_drv.last_fence_id, fence_id);
list_for_each_entry_safe(fence, tmp, &drv->fences, node) {
if (fence_id < fence->f.seqno)
continue;
--
2.29.2.299.gdc1121823c-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next/master bisection: baseline.dmesg.emerg on meson-gxbb-p200
On 19/11/2020 19:35, Marc Zyngier wrote:
> On 2020-11-19 18:13, Jerome Brunet wrote:
>> On Thu 19 Nov 2020 at 19:04, Guillaume Tucker
>> wrote:
>>
>>> Hi Marc,
>>>
>>> On 19/11/2020 11:58, Marc Zyngier wrote:
On 2020-11-19 10:26, Neil Armstrong wrote:
> On 19/11/2020 11:20, Marc Zyngier wrote:
>> On 2020-11-19 08:50, Guillaume Tucker wrote:
>>> Please see the automated bisection report below about some kernel
>>> errors on meson-gxbb-p200.
>>>
>>> Reports aren't automatically sent to the public while we're
>>> trialing new bisection features on kernelci.org, however this one
>>> looks valid.
>>>
>>> The bisection started with next-20201118 but the errors are still
>>> present in next-20201119. Details for this regression:
>>>
>>> https://kernelci.org/test/case/id/5fb6196bfd0127fd68d8d902/
>>>
>>> The first error is:
>>>
>>> [ 14.757489] Internal error: synchronous external abort: 96000210
>>> [#1] PREEMPT SMP
>>
>> Looks like yet another clock ordering setup. I guess different Amlogic
>> platforms have slightly different ordering requirements.
>>
>> Neil, do you have any idea of which platform requires which ordering?
>> The variability in DT and platforms is pretty difficult to follow (and
>> I don't think I have such board around).
>
> The requirements should be the same, here the init was done before calling
> dw_hdmi_probe to be sure the clocks and internals resets were deasserted.
> But since you boot from u-boot already enabling these, it's already
> active.
>
> The solution would be to revert and do some check in meson_dw_hdmi_init()
> to
> check if already enabled and do nothing.
A better fix seems to be this, which makes it explicit that there is
a dependency between some of the registers accessed from
meson_dw_hdmi_init()
and the iahb clock.
Guillaume, can you give this a go on your failing box?
>>>
>>> I confirm it solves the problem. Please add this to your fix
>>> patch if it's OK with you:
>>>
>>> Reported-by: "kernelci.org bot"
>>> Tested-by: Guillaume Tucker
>>>
>>>
>>> For the record, it passed all the tests when applied on top of
>>> the "bad" revision found by the bisection:
>>>
>>>
>>> http://lava.baylibre.com:10080/scheduler/alljobs?search=v5.10-rc3-1021-gb8668a2e5ea1
>>>
>>> and the exact same test on the "bad" revision without the fix
>>> consistently showed the error:
>>>
>>> http://lava.baylibre.com:10080/scheduler/job/374176
>>>
>>>
>>> Thanks,
>>> Guillaume
>>>
>>>
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 7f8eea494147..52af8ba94311 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -146,6 +146,7 @@ struct meson_dw_hdmi {
struct reset_control *hdmitx_ctrl;
struct reset_control *hdmitx_phy;
struct clk *hdmi_pclk;
+ struct clk *iahb_clk;
struct clk *venci_clk;
struct regulator *hdmi_supply;
u32 irq_stat;
@@ -1033,6 +1034,13 @@ static int meson_dw_hdmi_bind(struct device *dev,
struct device *master,
}
clk_prepare_enable(meson_dw_hdmi->hdmi_pclk);
+ meson_dw_hdmi->iahb_clk = devm_clk_get(dev, "iahb");
+ if (IS_ERR(meson_dw_hdmi->iahb_clk)) {
+ dev_err(dev, "Unable to get iahb clk\n");
+ return PTR_ERR(meson_dw_hdmi->iahb_clk);
+ }
+ clk_prepare_enable(meson_dw_hdmi->iahb_clk);
On previous SoCs, iahb was directly the bus clock (clk81), and on recent socs
this clock is a gate.
The question is why is it disabled. Maybe a previous failed probe disabled it
in the dw-hdmi probe failure code and this clock is needed for
meson_dw_hdmi_init(),
so yeah this is the right fix.
Thanks.
Could you send a revert of b33340e33acdfe5ca6a5aa1244709575ae1e0432 and then
proper fix with clk_disable_unprepare added ?
>>
>> If you guys are going ahead with this fix, this call to
>> clk_prepare_enable() needs to be balanced with clk_disable_unprepare()
>> somehow
>
> Yup, good point.
>
> Although this driver *never* disables any clock it enables, and leaves it
> to the main DW driver, which I guess makes it leak references.
>
> So all 3 clocks need fixing.
Exact.
Thx Guillaume for testing,
Neil
>
> Thanks,
>
> M.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm: Introduce an atomic_commit_setup function
On Fri, Nov 20, 2020 at 9:39 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 19.11.20 um 16:32 schrieb Daniel Vetter:
> > On Thu, Nov 19, 2020 at 10:59:42AM +0100, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 13.11.20 um 16:29 schrieb Maxime Ripard:
> >>> Private objects storing a state shared across all CRTCs need to be
> >>> carefully handled to avoid a use-after-free issue.
> >>>
> >>> The proper way to do this to track all the commits using that shared
> >>> state and wait for the previous commits to be done before going on with
> >>> the current one to avoid the reordering of commits that could occur.
> >>>
> >>> However, this commit setup needs to be done after
> >>> drm_atomic_helper_setup_commit(), because before the CRTC commit
> >>> structure hasn't been allocated before, and before the workqueue is
> >>> scheduled, because we would be potentially reordered already otherwise.
> >>>
> >>> That means that drivers currently have to roll their own
> >>> drm_atomic_helper_commit() function, even though it would be identical
> >>> if not for the commit setup.
> >>>
> >>> Let's introduce a hook to do so that would be called as part of
> >>> drm_atomic_helper_commit, allowing us to reuse the atomic helpers.
> >>>
> >>> Suggested-by: Daniel Vetter
> >>> Signed-off-by: Maxime Ripard
> >>> ---
> >>>drivers/gpu/drm/drm_atomic_helper.c | 6 ++
> >>>include/drm/drm_modeset_helper_vtables.h | 18 ++
> >>>2 files changed, 24 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >>> b/drivers/gpu/drm/drm_atomic_helper.c
> >>> index ddd0e3239150..7d69c7844dfc 100644
> >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>> @@ -2083,8 +2083,11 @@ int drm_atomic_helper_setup_commit(struct
> >>> drm_atomic_state *state,
> >>> struct drm_plane *plane;
> >>> struct drm_plane_state *old_plane_state, *new_plane_state;
> >>> struct drm_crtc_commit *commit;
> >>> + const struct drm_mode_config_helper_funcs *funcs;
> >>> int i, ret;
> >>> + funcs = state->dev->mode_config.helper_private;
> >>> +
> >>> for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> >>> new_crtc_state, i) {
> >>> commit = kzalloc(sizeof(*commit), GFP_KERNEL);
> >>> if (!commit)
> >>> @@ -2169,6 +2172,9 @@ int drm_atomic_helper_setup_commit(struct
> >>> drm_atomic_state *state,
> >>> new_plane_state->commit = drm_crtc_commit_get(commit);
> >>> }
> >>> + if (funcs && funcs->atomic_commit_setup)
> >>> + return funcs->atomic_commit_setup(state);
> >>> +
> >>> return 0;
> >>>}
> >>>EXPORT_SYMBOL(drm_atomic_helper_setup_commit);
> >>> diff --git a/include/drm/drm_modeset_helper_vtables.h
> >>> b/include/drm/drm_modeset_helper_vtables.h
> >>> index f2de050085be..56470baf0513 100644
> >>> --- a/include/drm/drm_modeset_helper_vtables.h
> >>> +++ b/include/drm/drm_modeset_helper_vtables.h
> >>> @@ -1396,6 +1396,24 @@ struct drm_mode_config_helper_funcs {
> >>> * drm_atomic_helper_commit_tail().
> >>> */
> >>> void (*atomic_commit_tail)(struct drm_atomic_state *state);
> >>> +
> >>> + /**
> >>> +* @atomic_commit_setup:
> >>> +*
> >>> +* This hook is used by the default atomic_commit() hook implemented
> >>> in
> >>> +* drm_atomic_helper_commit() together with the nonblocking helpers
> >>> (see
> >>> +* drm_atomic_helper_setup_commit()) to extend the DRM commit setup.
> >>> It
> >>> +* is not used by the atomic helpers.
> >>> +*
> >>> +* This function is called at the end of
> >>> +* drm_atomic_helper_setup_commit(), so once the commit has been
> >>> +* properly setup across the generic DRM object states. It allows
> >>> +* drivers to do some additional commit tracking that isn't related
> >>> to a
> >>> +* CRTC, plane or connector, typically a private object.
> >>> +*
> >>> +* This hook is optional.
> >>> +*/
> >>> + int (*atomic_commit_setup)(struct drm_atomic_state *state);
> >>
> >> It feels hacky and screwed-on to me. I'd suggest to add an
> >> atomic_commit_prepare callback that is called by drm_atomic_helper where it
> >> currently calls drm_atomic_helper_setup_commit(). The default
> >> implementation
> >> would include setup_commit and prepare_planes. Some example code for
> >> drm_atomic_helper.c
> >>
> >> static int commit_prepare(state)
> >> {
> >> drm_atomic_helper_setup_commit(state)
> >>
> >> drm_atomic_helper_prepare_planes(state)
> >> }
> >>
> >> int drm_atomic_helper_commit()
> >> {
> >> if (async_update) {
> >> ...
> >> }
> >>
> >> if (funcs->atomic_commit_prepare)
> >> funcs->atomic_commit_prepare(state)
> >> else
> >> commit_prepare(state)
> >>
> >> /* the rest of the current function below */
> >> INIT_WORK(&state->commit_work, commit_work);
> >> ...
> >> }
> >>
> >> Drivers that i
Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
On Fri, Nov 20, 2020 at 7:32 AM Sumit Semwal wrote: > > Hi Daniel, > > > On Wed, 18 Nov 2020 at 13:16, Daniel Vetter wrote: > > > > On Wed, Nov 18, 2020 at 3:40 AM John Stultz wrote: > > > On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote: > > > > On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote: > > > > > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter wrote: > > > > > > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote: > > > > > > > On Tue, 10 Nov 2020 at 09:19, John Stultz > > > > > > > wrote: > > > > > > > > > > > > > > > > Hey All, > > > > > > > > So just wanted to send my last revision of my patch series > > > > > > > > of performance optimizations to the dma-buf system heap. > > > > > > > > > > > > > > Thanks very much for your patches - I think the first 5 patches > > > > > > > look good to me. > > > > > > > > > > > > > > I know there was a bit of discussion over adding a new > > > > > > > system-uncached > > > > > > > heap v/s using a flag to identify that; I think I prefer the > > > > > > > separate > > > > > > > heap idea, but lets ask one last time if any one else has any real > > > > > > > objections to it. > > > > > > > > > > > > > > Daniel, Christian: any comments from your side on this? > > > > > > > > > > > > I do wonder a bit where the userspace stack for this all is, since > > > > > > tuning > > > > > > allocators without a full stack is fairly pointless. dma-buf heaps > > > > > > is a > > > > > > bit in a limbo situation here it feels like. > > > > > > > > > > As mentioned in the system-uncached patch: > > > > > Pending opensource users of this code include: > > > > > * AOSP HiKey960 gralloc: > > > > > - > > > > > https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519 > > > > > - Visibly improves performance over the system heap > > > > > * AOSP Codec2 (possibly, needs more review): > > > > > - > > > > > https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325 > > > > > > > > > > Additionally both the HiKey, HiKey960 grallocs and Codec2 are already > > > > > able to use the current dmabuf heaps instead of ION. > > > > > > > > > > So I'm not sure what you mean by limbo, other than it being in a > > > > > transition state where the interface is upstream and we're working on > > > > > moving vendors to it from ION (which is staged to be dropped in 5.11). > > > > > Part of that work is making sure we don't regress the performance > > > > > expectations. > > > > > > > > The mesa thing below, since if we test this with some downstream kernel > > > > drivers or at least non-mesa userspace I'm somewhat worried we're just > > > > creating a nice split world between the android gfx world and the > > > > mesa/linux desktop gfx world. > > > > > > > > But then that's kinda how android rolls, so *shrug* > > > > > > > > > > Plus I'm vary of anything related to leaking this kind of stuff > > > > > > beyond the > > > > > > dma-api because dma api maintainers don't like us doing that. But > > > > > > personally no concern on that front really, gpus need this. It's > > > > > > just that > > > > > > we do need solid justification I think if we land this. Hence back > > > > > > to > > > > > > first point. > > > > > > > > > > > > Ideally first point comes in the form of benchmarking on android > > > > > > together > > > > > > with a mesa driver (or mesa + some v4l driver or whatever it takes > > > > > > to > > > > > > actually show the benefits, I have no idea). > > > > > > > > > > Tying it with mesa is a little tough as the grallocs for mesa devices > > > > > usually use gbm (gralloc.gbm or gralloc.minigbm). Swapping the > > > > > allocation path for dmabuf heaps there gets a little complex as last I > > > > > tried that (when trying to get HiKey working with Lima graphics, as > > > > > gbm wouldn't allocate the contiguous buffers required by the display), > > > > > I ran into issues with the drm_hwcomposer and mesa expecting the gbm > > > > > private handle metadata in the buffer when it was passed in. > > > > > > > > > > But I might take a look at it again. I got a bit lost digging through > > > > > the mesa gbm allocation paths last time. > > > > > > > > > > I'll also try to see if I can find a benchmark for the codec2 code > > > > > (using dmabuf heaps with and without the uncached heap) on on db845c > > > > > (w/ mesa), as that is already working and I suspect that might be > > > > > close to what you're looking for. > > > > > > > > tbh I think trying to push for this long term is the best we can hope > > > > for. > > > > > > > > Media is also a lot more *meh* since it's deeply fragmented and a lot > > > > less > > > > of it upstream than on the gles/display side. > > > > > > > > I think confirming that this at least doesn't horrible blow up on a > > > > gralloc/gbm+mesa stack would be useful I think. > > > > > > Sorry, I'm still a little foggy on precisely what you're
Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
On Fri, Nov 20, 2020 at 8:58 AM Dan Carpenter wrote: > > On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote: > > On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter > > wrote: > > > > > > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote: > > > > Hi, > > > > > > > > On 10/27/20 2:51 PM, Hans de Goede wrote: > > > > > Add missing pci_iounmap() calls to properly unmap the memory on > > > > > probe-failure and remove. > > > > > > > > > > Reported-by: kernel test robot > > > > > Reported-by: Dan Carpenter > > > > > Signed-off-by: Hans de Goede > > > > > > > > For some reason the spam-filter used by Red Hat's email system has eaten > > > > Daniel Vetter's reply to this, so let me copy and paste that from > > > > patchwork: > > > > > > > > Daniel Vetter wrote: > > > > > > > > > I think switching over to devm would be really nice. And for pci all > > > > > you need to do is use pcim_enable_device and delete all the cleanup > > > > > code, and it's all done. Hand rolling device cleanup code really isn't > > > > > a great idea and way too error-prone. Plus you're using lots of devm_ > > > > > already. > > > > > > > > Good point, so I just checked and the vboxvideo code is already > > > > using pcim_enable_device() so it looks like this is a false-positive > > > > from the l...@intel.com bot, and Dan Carpenter missed that > > > > pcim_enable_device() > > > > makes all subsequent pci-resource acquiring calls behave like devm > > > > calls, > > > > when he forwarded the report to me. > > > > > > > > Tl;DR: there is no bug / leak and this patch can be dropped. > > > > > > > > Is there a place where I can report a bug against the l...@intel.com bot > > > > for this false-positive ? > > > > > > Ah. Thanks! > > > > > > This is a Smatch bug. There is a list for that sma...@vger.kernel.org > > > but I already remove the pci_iomap() from the list of functions that > > > needs to be unwound based on your report. > > > > I guess if smatch sees a pci_enable_device but not pcim_enable_device > > on the same device as passed to pci_iomap (and a pile of other pci > > functions) then it still must be unwound. Could smatch detect that? > > There's a lot of pci drivers not using the managed functions, catching > > bugs in these would be good. > > It's a lot of code. There would be two ways to implement this: > > 1) Somehow store the links to figure out the value of: > > devres_find(vbox->ddev.pdev.dev)->enabled > > That's very complicated. I'm sort of working on some of the steps > involved but and it's probably a multi year process before it's > possible. > > 2) Create a data base table with driver data, then store if the driver > calls pcim_enable_device(). This is still a bit of work, but probably > straight forward. Storing driver data would be useful for other things > as well. Hm maybe I totally misunderstand how smatch works, but I thought you can track additional invariants and stuff on various pointers. So I figured you just track whether pci_enable_device has been called on a struct pci_device *dev, and then if anyone calls pci_iomap on the same pointer and there's no cleanup, it's a bug. For any other case you just can't tell (since absence of pcim_enable_device might just mean that smatch doesn't see through the maze). Or is that what you meant with approach 2? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] More meson HDMI fixes
Guillaume reported that my earlier fixes for the meson HDMI driver broke another set of machines which are now exploding (clock not enabled). I have thus reconsidered the approach and came up with an alternative fix (enable a missing clock), which Guillaume confirmed to be working. Jerome pointed out that this driver is leaking clock references like a sieve, so that needed addressing too. The first patch start by fixing the clock leakage using a devm facility. The second patch addresses the earlier crash by reusing the infrastructure put together in the first patch. Tested on VIM3l. Marc Zyngier (2): drm/meson: dw-hdmi: Disable clocks on driver teardown drm/meson: dw-hdmi: Enable the iahb clock early enough drivers/gpu/drm/meson/meson_dw_hdmi.c | 51 ++- 1 file changed, 35 insertions(+), 16 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/meson: dw-hdmi: Disable clocks on driver teardown
The HDMI driver request clocks early, but never disable them, leaving
the clocks on even when the driver is removed.
Fix it by slightly refactoring the clock code, and register a devm
action that will eventually disable/unprepare the enabled clocks.
Signed-off-by: Marc Zyngier
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 43 ++-
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 7f8eea494147..29623b309cb1 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -145,8 +145,6 @@ struct meson_dw_hdmi {
struct reset_control *hdmitx_apb;
struct reset_control *hdmitx_ctrl;
struct reset_control *hdmitx_phy;
- struct clk *hdmi_pclk;
- struct clk *venci_clk;
struct regulator *hdmi_supply;
u32 irq_stat;
struct dw_hdmi *hdmi;
@@ -946,6 +944,29 @@ static void meson_disable_regulator(void *data)
regulator_disable(data);
}
+static void meson_disable_clk(void *data)
+{
+ clk_disable_unprepare(data);
+}
+
+static int meson_enable_clk(struct device *dev, char *name)
+{
+ struct clk *clk;
+ int ret;
+
+ clk = devm_clk_get(dev, name);
+ if (IS_ERR(clk)) {
+ dev_err(dev, "Unable to get %s pclk\n", name);
+ return PTR_ERR(clk);
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (!ret)
+ ret = devm_add_action_or_reset(dev, meson_disable_clk, clk);
+
+ return ret;
+}
+
static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
@@ -1026,19 +1047,13 @@ static int meson_dw_hdmi_bind(struct device *dev,
struct device *master,
if (IS_ERR(meson_dw_hdmi->hdmitx))
return PTR_ERR(meson_dw_hdmi->hdmitx);
- meson_dw_hdmi->hdmi_pclk = devm_clk_get(dev, "isfr");
- if (IS_ERR(meson_dw_hdmi->hdmi_pclk)) {
- dev_err(dev, "Unable to get HDMI pclk\n");
- return PTR_ERR(meson_dw_hdmi->hdmi_pclk);
- }
- clk_prepare_enable(meson_dw_hdmi->hdmi_pclk);
+ ret = meson_enable_clk(dev, "isfr");
+ if (ret)
+ return ret;
- meson_dw_hdmi->venci_clk = devm_clk_get(dev, "venci");
- if (IS_ERR(meson_dw_hdmi->venci_clk)) {
- dev_err(dev, "Unable to get venci clk\n");
- return PTR_ERR(meson_dw_hdmi->venci_clk);
- }
- clk_prepare_enable(meson_dw_hdmi->venci_clk);
+ ret = meson_enable_clk(dev, "venci");
+ if (ret)
+ return ret;
dw_plat_data->regm = devm_regmap_init(dev, NULL, meson_dw_hdmi,
&meson_dw_hdmi_regmap_config);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/meson: dw-hdmi: Enable the iahb clock early enough
Instead of moving meson_dw_hdmi_init() around which breaks existing
platform, let's enable the clock meson_dw_hdmi_init() depends on.
This means we don't have to worry about this clock being enabled or
not, depending on the boot-loader features.
Fixes: b33340e33acd ("drm/meson: dw-hdmi: Ensure that clocks are enabled before
touching the TOP registers")
Reported-by: Guillaume Tucker
Tested-by: Guillaume Tucker
Signed-off-by: Marc Zyngier
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 29623b309cb1..aad75a22dc33 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -1051,6 +1051,10 @@ static int meson_dw_hdmi_bind(struct device *dev, struct
device *master,
if (ret)
return ret;
+ ret = meson_enable_clk(dev, "iahb");
+ if (ret)
+ return ret;
+
ret = meson_enable_clk(dev, "venci");
if (ret)
return ret;
@@ -1086,6 +1090,8 @@ static int meson_dw_hdmi_bind(struct device *dev, struct
device *master,
encoder->possible_crtcs = BIT(0);
+ meson_dw_hdmi_init(meson_dw_hdmi);
+
DRM_DEBUG_DRIVER("encoder initialized\n");
/* Bridge / Connector */
@@ -1110,8 +1116,6 @@ static int meson_dw_hdmi_bind(struct device *dev, struct
device *master,
if (IS_ERR(meson_dw_hdmi->hdmi))
return PTR_ERR(meson_dw_hdmi->hdmi);
- meson_dw_hdmi_init(meson_dw_hdmi);
-
next_bridge = of_drm_find_bridge(pdev->dev.of_node);
if (next_bridge)
drm_bridge_attach(encoder, next_bridge,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: document drm_mode_modeinfo
This allows `struct drm_mode_modeinfo` references to be linkified.
Some descriptions are borrowed from struct drm_display_mode.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
include/uapi/drm/drm_mode.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 3979389fcc4f..900b6f87d5c8 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -218,6 +218,24 @@ extern "C" {
#define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
#define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
+/**
+ * struct drm_mode_modeinfo - Display mode information.
+ * @clock: pixel clock in kHz
+ * @hdisplay: horizontal display size
+ * @hsync_start: horizontal sync start
+ * @hsync_end: horizontal sync end
+ * @htotal: horizontal total size
+ * @hskew: horizontal skew
+ * @vdisplay: vertical display size
+ * @vsync_start: vertical sync start
+ * @vsync_end: vertical sync end
+ * @vtotal: vertical total size
+ * @vscan: vertical scan
+ * @vrefresh: approximate vertical refresh rate in Hz
+ * @flags: bitmask of misc. flags, see DRM_MODE_FLAG_* defines
+ * @type: bitmask of type flags, see DRM_MODE_TYPE_* defines
+ * @name: string describing the mode resolution
+ */
struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] mmu_notifier fs fs_reclaim lockdep annotations
Hi all, I've finally gotten around to polish of my lockdep anntotation patches from a while ago: https://lore.kernel.org/dri-devel/20200610194101.1668038-1-daniel.vet...@ffwll.ch/ That patch has been in -mm for a few days already, but it immediately hit some issues with xfs. Changes since v2: - Now hopefully the bug that bombed xfs fixed. - With unit-tests (that's the part I really wanted and never got to) - might_alloc() helper thrown in for good. The unit test stuff was the major drag until I figured out how to make this very easy with the locking selftests. Comments, review, testing all very much welcome. Cheers, Daniel Daniel Vetter (3): mm: Track mmu notifiers in fs_reclaim_acquire/release mm: Extract might_alloc() debug check locking/selftests: Add testcases for fs_reclaim include/linux/sched/mm.h | 16 ++ lib/locking-selftest.c | 47 mm/mmu_notifier.c| 7 -- mm/page_alloc.c | 31 -- mm/slab.h| 5 + mm/slob.c| 6 ++--- 6 files changed, 86 insertions(+), 26 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] mm: Track mmu notifiers in fs_reclaim_acquire/release
fs_reclaim_acquire/release nicely catch recursion issues when
allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
to use to keep the excessive caches in check). For mmu notifier
recursions we do have lockdep annotations since 23b68395c7c7
("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
But these only fire if a path actually results in some pte
invalidation - for most small allocations that's very rarely the case.
The other trouble is that pte invalidation can happen any time when
__GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
recursion.
I was pondering whether we should just do the general annotation, but
there's always the risk for false positives. Plus I'm assuming that
the core fs and io code is a lot better reviewed and tested than
random mmu notifier code in drivers. Hence why I decide to only
annotate for that specific case.
Furthermore even if we'd create a lockdep map for direct reclaim, we'd
still need to explicit pull in the mmu notifier map - there's a lot
more places that do pte invalidation than just direct reclaim, these
two contexts arent the same.
Note that the mmu notifiers needing their own independent lockdep map
is also the reason we can't hold them from fs_reclaim_acquire to
fs_reclaim_release - it would nest with the acquistion in the pte
invalidation code, causing a lockdep splat. And we can't remove the
annotations from pte invalidation and all the other places since
they're called from many other places than page reclaim. Hence we can
only do the equivalent of might_lock, but on the raw lockdep map.
With this we can also remove the lockdep priming added in 66204f1d2d1b
("mm/mmu_notifiers: prime lockdep") since the new annotations are
strictly more powerful.
v2: Review from Thomas Hellstrom:
- unbotch the fs_reclaim context check, I accidentally inverted it,
but it didn't blow up because I inverted it immediately
- fix compiling for !CONFIG_MMU_NOTIFIER
v3: Unbreak the PF_MEMALLOC_ context flags. Thanks to Qian for the
report and Dave for explaining what I failed to see.
Cc: linux-fsde...@vger.kernel.org
Cc: Dave Chinner
Cc: Qian Cai
Cc: linux-...@vger.kernel.org
Cc: Thomas Hellström (Intel)
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: linux-r...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Christian König
Cc: "Matthew Wilcox (Oracle)"
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 7 ---
mm/page_alloc.c | 31 ---
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 5654dd19addc..61ee40ed804e 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -612,13 +612,6 @@ int __mmu_notifier_register(struct mmu_notifier
*subscription,
mmap_assert_write_locked(mm);
BUG_ON(atomic_read(&mm->mm_users) <= 0);
- if (IS_ENABLED(CONFIG_LOCKDEP)) {
- fs_reclaim_acquire(GFP_KERNEL);
- lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
- lock_map_release(&__mmu_notifier_invalidate_range_start_map);
- fs_reclaim_release(GFP_KERNEL);
- }
-
if (!mm->notifier_subscriptions) {
/*
* kmalloc cannot be called under mm_take_all_locks(), but we
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 23f5066bd4a5..ff0f9a84b8de 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -57,6 +57,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -4264,10 +4265,8 @@ should_compact_retry(struct alloc_context *ac, unsigned
int order, int alloc_fla
static struct lockdep_map __fs_reclaim_map =
STATIC_LOCKDEP_MAP_INIT("fs_reclaim", &__fs_reclaim_map);
-static bool __need_fs_reclaim(gfp_t gfp_mask)
+static bool __need_reclaim(gfp_t gfp_mask)
{
- gfp_mask = current_gfp_context(gfp_mask);
-
/* no reclaim without waiting on it */
if (!(gfp_mask & __GFP_DIRECT_RECLAIM))
return false;
@@ -4276,10 +4275,6 @@ static bool __need_fs_reclaim(gfp_t gfp_mask)
if (current->flags & PF_MEMALLOC)
return false;
- /* We're only interested __GFP_FS allocations for now */
- if (!(gfp_mask & __GFP_FS))
- return false;
-
if (gfp_mask & __GFP_NOLOCKDEP)
return false;
@@ -4298,15 +4293,29 @@ void __fs_reclaim_release(void)
void fs_reclaim_acquire(gfp_t gfp_mask)
{
- if (__need_fs_reclaim(gfp_mask))
- __fs_reclaim_acquire();
+ gfp_mask = current_gfp_context(gfp_mask);
+
+ if (__need_reclaim(gfp_mask)) {
+ if (gfp_mask & __GFP_FS)
+ __fs_reclaim_acquire();
+
+#ifdef CONFIG_MMU_NOTIFIER
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
+ lock_map_release(&__mmu_notifier_invalidate_rang
[PATCH 2/3] mm: Extract might_alloc() debug check
Extracted from slab.h, which seems to have the most complete version
including the correct might_sleep() check. Roll it out to slob.c.
Motivated by a discussion with Paul about possibly changing call_rcu
behaviour to allocate memory, but only roughly every 500th call.
There are a lot fewer places in the kernel that care about whether
allocating memory is allowed or not (due to deadlocks with reclaim
code) than places that care whether sleeping is allowed. But debugging
these also tends to be a lot harder, so nice descriptive checks could
come in handy. I might have some use eventually for annotations in
drivers/gpu.
Note that unlike fs_reclaim_acquire/release gfpflags_allow_blocking
does not consult the PF_MEMALLOC flags. But there is no flag
equivalent for GFP_NOWAIT, hence this check can't go wrong due to
memalloc_no*_save/restore contexts. Willy is working on a patch series
which might change this:
https://lore.kernel.org/linux-mm/20200625113122.7540-7-wi...@infradead.org/
I think best would be if that updates gfpflags_allow_blocking(), since
there's a ton of callers all over the place for that already.
Acked-by: Vlastimil Babka
Acked-by: Paul E. McKenney
Cc: Paul E. McKenney
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Vlastimil Babka
Cc: Mathieu Desnoyers
Cc: Sebastian Andrzej Siewior
Cc: Michel Lespinasse
Cc: Daniel Vetter
Cc: Waiman Long
Cc: Thomas Gleixner
Cc: Randy Dunlap
Cc: linux...@kvack.org
Cc: linux-fsde...@vger.kernel.org
Cc: Dave Chinner
Cc: Qian Cai
Cc: linux-...@vger.kernel.org
Cc: "Matthew Wilcox (Oracle)"
Signed-off-by: Daniel Vetter
---
include/linux/sched/mm.h | 16
mm/slab.h| 5 +
mm/slob.c| 6 ++
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index d5ece7a9a403..f94405d43fd1 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -180,6 +180,22 @@ static inline void fs_reclaim_acquire(gfp_t gfp_mask) { }
static inline void fs_reclaim_release(gfp_t gfp_mask) { }
#endif
+/**
+ * might_alloc - Marks possible allocation sites
+ * @gfp_mask: gfp_t flags that would be use to allocate
+ *
+ * Similar to might_sleep() and other annotations this can be used in functions
+ * that might allocate, but often dont. Compiles to nothing without
+ * CONFIG_LOCKDEP. Includes a conditional might_sleep() if @gfp allows
blocking.
+ */
+static inline void might_alloc(gfp_t gfp_mask)
+{
+ fs_reclaim_acquire(gfp_mask);
+ fs_reclaim_release(gfp_mask);
+
+ might_sleep_if(gfpflags_allow_blocking(gfp_mask));
+}
+
/**
* memalloc_noio_save - Marks implicit GFP_NOIO allocation scope.
*
diff --git a/mm/slab.h b/mm/slab.h
index 6d7c6a5056ba..37b981247e5d 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -500,10 +500,7 @@ static inline struct kmem_cache
*slab_pre_alloc_hook(struct kmem_cache *s,
{
flags &= gfp_allowed_mask;
- fs_reclaim_acquire(flags);
- fs_reclaim_release(flags);
-
- might_sleep_if(gfpflags_allow_blocking(flags));
+ might_alloc(flags);
if (should_failslab(s, flags))
return NULL;
diff --git a/mm/slob.c b/mm/slob.c
index 7cc9805c8091..8d4bfa46247f 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -474,8 +474,7 @@ __do_kmalloc_node(size_t size, gfp_t gfp, int node,
unsigned long caller)
gfp &= gfp_allowed_mask;
- fs_reclaim_acquire(gfp);
- fs_reclaim_release(gfp);
+ might_alloc(gfp);
if (size < PAGE_SIZE - minalign) {
int align = minalign;
@@ -597,8 +596,7 @@ static void *slob_alloc_node(struct kmem_cache *c, gfp_t
flags, int node)
flags &= gfp_allowed_mask;
- fs_reclaim_acquire(flags);
- fs_reclaim_release(flags);
+ might_alloc(flags);
if (c->size < PAGE_SIZE) {
b = slob_alloc(c->size, flags, c->align, node, 0);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] locking/selftests: Add testcases for fs_reclaim
Since I butchered this I figured better to make sure we have testcases
for this now. Since we only have a locking context for __GFP_FS that's
the only thing we're testing right now.
Cc: linux-fsde...@vger.kernel.org
Cc: Dave Chinner
Cc: Qian Cai
Cc: linux-...@vger.kernel.org
Cc: Thomas Hellström (Intel)
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: linux-r...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Christian König
Cc: "Matthew Wilcox (Oracle)"
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: linux-ker...@vger.kernel.org
---
lib/locking-selftest.c | 47 ++
1 file changed, 47 insertions(+)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index a899b3f0e2e5..ad47c3358e30 100644
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2357,6 +2358,50 @@ static void queued_read_lock_tests(void)
pr_cont("\n");
}
+static void fs_reclaim_correct_nesting(void)
+{
+ fs_reclaim_acquire(GFP_KERNEL);
+ might_alloc(GFP_NOFS);
+ fs_reclaim_release(GFP_KERNEL);
+}
+
+static void fs_reclaim_wrong_nesting(void)
+{
+ fs_reclaim_acquire(GFP_KERNEL);
+ might_alloc(GFP_KERNEL);
+ fs_reclaim_release(GFP_KERNEL);
+}
+
+static void fs_reclaim_protected_nesting(void)
+{
+ unsigned int flags;
+
+ fs_reclaim_acquire(GFP_KERNEL);
+ flags = memalloc_nofs_save();
+ might_alloc(GFP_KERNEL);
+ memalloc_nofs_restore(flags);
+ fs_reclaim_release(GFP_KERNEL);
+}
+
+static void fs_reclaim_tests(void)
+{
+ printk(" \n");
+ printk(" | fs_reclaim tests |\n");
+ printk(" \n");
+
+ print_testname("correct nesting");
+ dotest(fs_reclaim_correct_nesting, SUCCESS, 0);
+ pr_cont("\n");
+
+ print_testname("wrong nesting");
+ dotest(fs_reclaim_wrong_nesting, FAILURE, 0);
+ pr_cont("\n");
+
+ print_testname("protected nesting");
+ dotest(fs_reclaim_protected_nesting, SUCCESS, 0);
+ pr_cont("\n");
+}
+
void locking_selftest(void)
{
/*
@@ -2478,6 +2523,8 @@ void locking_selftest(void)
if (IS_ENABLED(CONFIG_QUEUED_RWLOCKS))
queued_read_lock_tests();
+ fs_reclaim_tests();
+
if (unexpected_testcase_failures) {
printk("-\n");
debug_locks = 0;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: don't set page->mapping
Random observation while trying to review Christian's patch series to
stop looking at struct page for dma-buf imports.
This was originally added in
commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
Author: Thomas Hellstrom
Date: Fri Jan 3 11:47:23 2014 +0100
drm/ttm: Correctly set page mapping and -index members
Needed for some vm operations; most notably unmap_mapping_range() with
even_cows = 0.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
but we do not have a single caller of unmap_mapping_range with
even_cows == 0. And all the gem drivers don't do this, so another
small thing we could standardize between drm and ttm drivers.
Plus I don't really see a need for unamp_mapping_range where we don't
want to indiscriminately shoot down all ptes.
Cc: Thomas Hellstrom
Cc: Brian Paul
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
---
drivers/gpu/drm/ttm/ttm_tt.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index da9eeffe0c6d..5b2eb6d58bb7 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -284,17 +284,6 @@ int ttm_tt_swapout(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
return ret;
}
-static void ttm_tt_add_mapping(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
-{
- pgoff_t i;
-
- if (ttm->page_flags & TTM_PAGE_FLAG_SG)
- return;
-
- for (i = 0; i < ttm->num_pages; ++i)
- ttm->pages[i]->mapping = bdev->dev_mapping;
-}
-
int ttm_tt_populate(struct ttm_bo_device *bdev,
struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
{
@@ -313,7 +302,6 @@ int ttm_tt_populate(struct ttm_bo_device *bdev,
if (ret)
return ret;
- ttm_tt_add_mapping(bdev, ttm);
ttm->page_flags |= TTM_PAGE_FLAG_PRIV_POPULATED;
if (unlikely(ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
ret = ttm_tt_swapin(ttm);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next/master bisection: baseline.dmesg.emerg on meson-gxbb-p200
On 2020-11-20 09:26, Neil Armstrong wrote:
On 19/11/2020 19:35, Marc Zyngier wrote:
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 7f8eea494147..52af8ba94311 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -146,6 +146,7 @@ struct meson_dw_hdmi {
struct reset_control *hdmitx_ctrl;
struct reset_control *hdmitx_phy;
struct clk *hdmi_pclk;
+ struct clk *iahb_clk;
struct clk *venci_clk;
struct regulator *hdmi_supply;
u32 irq_stat;
@@ -1033,6 +1034,13 @@ static int meson_dw_hdmi_bind(struct device
*dev, struct device *master,
}
clk_prepare_enable(meson_dw_hdmi->hdmi_pclk);
+ meson_dw_hdmi->iahb_clk = devm_clk_get(dev, "iahb");
+ if (IS_ERR(meson_dw_hdmi->iahb_clk)) {
+ dev_err(dev, "Unable to get iahb clk\n");
+ return PTR_ERR(meson_dw_hdmi->iahb_clk);
+ }
+ clk_prepare_enable(meson_dw_hdmi->iahb_clk);
On previous SoCs, iahb was directly the bus clock (clk81), and on
recent socs
this clock is a gate.
The question is why is it disabled. Maybe a previous failed probe
disabled it
in the dw-hdmi probe failure code and this clock is needed for
meson_dw_hdmi_init(),
so yeah this is the right fix.
Thanks.
Could you send a revert of b33340e33acdfe5ca6a5aa1244709575ae1e0432
and then proper fix with clk_disable_unprepare added ?
Bah. I missed that email and sent a slightly different resolution.
Hopefully that'll be good enough.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: don't set page->mapping
Am 20.11.20 um 10:54 schrieb Daniel Vetter:
Random observation while trying to review Christian's patch series to
stop looking at struct page for dma-buf imports.
This was originally added in
commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
Author: Thomas Hellstrom
Date: Fri Jan 3 11:47:23 2014 +0100
drm/ttm: Correctly set page mapping and -index members
Needed for some vm operations; most notably unmap_mapping_range() with
even_cows = 0.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
but we do not have a single caller of unmap_mapping_range with
even_cows == 0. And all the gem drivers don't do this, so another
small thing we could standardize between drm and ttm drivers.
Plus I don't really see a need for unamp_mapping_range where we don't
want to indiscriminately shoot down all ptes.
Cc: Thomas Hellstrom
Cc: Brian Paul
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
This is still a NAK as long as we can't come up with a better way to
track TTMs page allocations.
Additional to that page_mapping() is used quite extensively in the mm
code and I'm not sure if that isn't needed for other stuff as well.
Regards,
Christian.
---
drivers/gpu/drm/ttm/ttm_tt.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index da9eeffe0c6d..5b2eb6d58bb7 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -284,17 +284,6 @@ int ttm_tt_swapout(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
return ret;
}
-static void ttm_tt_add_mapping(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
-{
- pgoff_t i;
-
- if (ttm->page_flags & TTM_PAGE_FLAG_SG)
- return;
-
- for (i = 0; i < ttm->num_pages; ++i)
- ttm->pages[i]->mapping = bdev->dev_mapping;
-}
-
int ttm_tt_populate(struct ttm_bo_device *bdev,
struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
{
@@ -313,7 +302,6 @@ int ttm_tt_populate(struct ttm_bo_device *bdev,
if (ret)
return ret;
- ttm_tt_add_mapping(bdev, ttm);
ttm->page_flags |= TTM_PAGE_FLAG_PRIV_POPULATED;
if (unlikely(ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
ret = ttm_tt_swapin(ttm);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: don't set page->mapping
On Fri, Nov 20, 2020 at 11:04 AM Christian König
wrote:
>
> Am 20.11.20 um 10:54 schrieb Daniel Vetter:
> > Random observation while trying to review Christian's patch series to
> > stop looking at struct page for dma-buf imports.
> >
> > This was originally added in
> >
> > commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
> > Author: Thomas Hellstrom
> > Date: Fri Jan 3 11:47:23 2014 +0100
> >
> > drm/ttm: Correctly set page mapping and -index members
> >
> > Needed for some vm operations; most notably unmap_mapping_range() with
> > even_cows = 0.
> >
> > Signed-off-by: Thomas Hellstrom
> > Reviewed-by: Brian Paul
> >
> > but we do not have a single caller of unmap_mapping_range with
> > even_cows == 0. And all the gem drivers don't do this, so another
> > small thing we could standardize between drm and ttm drivers.
> >
> > Plus I don't really see a need for unamp_mapping_range where we don't
> > want to indiscriminately shoot down all ptes.
> >
> > Cc: Thomas Hellstrom
> > Cc: Brian Paul
> > Signed-off-by: Daniel Vetter
> > Cc: Christian Koenig
> > Cc: Huang Rui
>
> This is still a NAK as long as we can't come up with a better way to
> track TTMs page allocations.
>
> Additional to that page_mapping() is used quite extensively in the mm
> code and I'm not sure if that isn't needed for other stuff as well.
Apologies, I'm honestly not quite sure how this lone patch here ended
up in this submission. I didn't want to send it out.
-Daniel
>
> Regards,
> Christian.
>
> > ---
> > drivers/gpu/drm/ttm/ttm_tt.c | 12
> > 1 file changed, 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> > index da9eeffe0c6d..5b2eb6d58bb7 100644
> > --- a/drivers/gpu/drm/ttm/ttm_tt.c
> > +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> > @@ -284,17 +284,6 @@ int ttm_tt_swapout(struct ttm_bo_device *bdev, struct
> > ttm_tt *ttm)
> > return ret;
> > }
> >
> > -static void ttm_tt_add_mapping(struct ttm_bo_device *bdev, struct ttm_tt
> > *ttm)
> > -{
> > - pgoff_t i;
> > -
> > - if (ttm->page_flags & TTM_PAGE_FLAG_SG)
> > - return;
> > -
> > - for (i = 0; i < ttm->num_pages; ++i)
> > - ttm->pages[i]->mapping = bdev->dev_mapping;
> > -}
> > -
> > int ttm_tt_populate(struct ttm_bo_device *bdev,
> > struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
> > {
> > @@ -313,7 +302,6 @@ int ttm_tt_populate(struct ttm_bo_device *bdev,
> > if (ret)
> > return ret;
> >
> > - ttm_tt_add_mapping(bdev, ttm);
> > ttm->page_flags |= TTM_PAGE_FLAG_PRIV_POPULATED;
> > if (unlikely(ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
> > ret = ttm_tt_swapin(ttm);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: don't set page->mapping
Am 20.11.20 um 11:05 schrieb Daniel Vetter:
On Fri, Nov 20, 2020 at 11:04 AM Christian König
wrote:
Am 20.11.20 um 10:54 schrieb Daniel Vetter:
Random observation while trying to review Christian's patch series to
stop looking at struct page for dma-buf imports.
This was originally added in
commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
Author: Thomas Hellstrom
Date: Fri Jan 3 11:47:23 2014 +0100
drm/ttm: Correctly set page mapping and -index members
Needed for some vm operations; most notably unmap_mapping_range() with
even_cows = 0.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
but we do not have a single caller of unmap_mapping_range with
even_cows == 0. And all the gem drivers don't do this, so another
small thing we could standardize between drm and ttm drivers.
Plus I don't really see a need for unamp_mapping_range where we don't
want to indiscriminately shoot down all ptes.
Cc: Thomas Hellstrom
Cc: Brian Paul
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
This is still a NAK as long as we can't come up with a better way to
track TTMs page allocations.
Additional to that page_mapping() is used quite extensively in the mm
code and I'm not sure if that isn't needed for other stuff as well.
Apologies, I'm honestly not quite sure how this lone patch here ended
up in this submission. I didn't want to send it out.
No problem.
But looking a bit deeper into the mm code that other drm drivers don't
set this correctly and still use unmap_mapping_range() sounds like quite
a bug to me.
Going to track down what exactly that is used for.
Christian.
-Daniel
Regards,
Christian.
---
drivers/gpu/drm/ttm/ttm_tt.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index da9eeffe0c6d..5b2eb6d58bb7 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -284,17 +284,6 @@ int ttm_tt_swapout(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
return ret;
}
-static void ttm_tt_add_mapping(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
-{
- pgoff_t i;
-
- if (ttm->page_flags & TTM_PAGE_FLAG_SG)
- return;
-
- for (i = 0; i < ttm->num_pages; ++i)
- ttm->pages[i]->mapping = bdev->dev_mapping;
-}
-
int ttm_tt_populate(struct ttm_bo_device *bdev,
struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
{
@@ -313,7 +302,6 @@ int ttm_tt_populate(struct ttm_bo_device *bdev,
if (ret)
return ret;
- ttm_tt_add_mapping(bdev, ttm);
ttm->page_flags |= TTM_PAGE_FLAG_PRIV_POPULATED;
if (unlikely(ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
ret = ttm_tt_swapin(ttm);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document drm_mode_modeinfo
On Fri, Nov 20, 2020 at 10:46 AM Simon Ser wrote:
>
> This allows `struct drm_mode_modeinfo` references to be linkified.
>
> Some descriptions are borrowed from struct drm_display_mode.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> ---
> include/uapi/drm/drm_mode.h | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 3979389fcc4f..900b6f87d5c8 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -218,6 +218,24 @@ extern "C" {
> #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
> #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
>
> +/**
> + * struct drm_mode_modeinfo - Display mode information.
> + * @clock: pixel clock in kHz
> + * @hdisplay: horizontal display size
> + * @hsync_start: horizontal sync start
> + * @hsync_end: horizontal sync end
> + * @htotal: horizontal total size
> + * @hskew: horizontal skew
> + * @vdisplay: vertical display size
> + * @vsync_start: vertical sync start
> + * @vsync_end: vertical sync end
> + * @vtotal: vertical total size
> + * @vscan: vertical scan
> + * @vrefresh: approximate vertical refresh rate in Hz
> + * @flags: bitmask of misc. flags, see DRM_MODE_FLAG_* defines
> + * @type: bitmask of type flags, see DRM_MODE_TYPE_* defines
> + * @name: string describing the mode resolution
Since if you look at this following random links it's not clear this
is the uapi version.
So maybe add something like "This is the userspace API display mode
information structure. For the kernel version seee struct
drm_display_mode". And a similar comment in reverse in the
kernel-internal struct.
With that added: Reviewed-by: Daniel Vetter
> + */
> struct drm_mode_modeinfo {
> __u32 clock;
> __u16 hdisplay;
> --
> 2.29.2
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 5.10-rc4; graphics alignment
Hi Am 20.11.20 um 10:52 schrieb David Laight: Hi David Am 18.11.20 um 23:01 schrieb David Laight: ... Did you try Daniel's suggestion of testing with the direct parent commit? (I was on holiday yesterday and didn't want to spend a sunny afternoon doing bisects.) Makes sense :) I've just done that and it is bad. Is there any way to bisect through the parts of the drm merge patch into v5.10-rc1 ? That ought to be quicker (and less error prone) than the bisect builds I was doing. Note that the stack 'splat' is due to a later change. It is separate from the broken pixel alignment. I actually saw the vga text go 'funny' while the boot was outputting all the [OK] messages (from systemd?) before the graphic login stole tty1 (bloody stupid to use tty1). I don't need to use the failing system today, I'll have another go at isolating the failure. You can use drm-tip for testing, where many of the DRM patches go through. https://cgit.freedesktop.org/drm/drm-tip/ It's fairly up-to-date. I have two systems with AST chips and neither shows any of the symptoms you describe; nor do we have such reports about drivers that use a similar stack (hibmc, bochs). Could you provide the output of dmesg | grep drm Best regards Thomas David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210123] drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] - flip_done time out with vmwgfx
https://bugzilla.kernel.org/show_bug.cgi?id=210123 --- Comment #3 from Stefan Mayr (stefan+ker...@mayr-stefan.de) --- Did some more test with Kernel versions provided by SUSE: Kernel 5.0.13 - 6 days without issues Kernel 5.2.14 - 2 days until we got the error message Today I installed 5.1.16 and we wait if this versions shows the error or not -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/10] drm/fb-helper: Call dirty helper after writing to fbdev
If fbdev uses a shadow framebuffer, call the damage handler. Otherwise
the update might not make it to the screen.
v2:
* mark virtual screen as dirty (Ville)
Signed-off-by: Thomas Zimmermann
Fixes: 222ec45f4c69 ("drm/fb_helper: Support framebuffers in I/O memory")
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Gerd Hoffmann
Cc: dri-devel@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/drm_fb_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 25edf670867c..9c673f33d222 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2189,6 +2189,9 @@ static ssize_t drm_fbdev_fb_write(struct fb_info *info,
const char __user *buf,
if (ret > 0)
*ppos += ret;
+ if (ret > 0)
+ drm_fb_helper_dirty(info, 0, 0, info->var.xres_virtual,
info->var.yres_virtual);
+
return ret ? ret : err;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/10] drm/fb-helper: Various fixes and cleanups
Here's a number of fb-helper patches that have been piling up recently. Patches 1 to 3 fix bugs that I spotted while going through the code. Because of the way the fbdev code works, they have been avoided so far. Patches 4 to 10 cleanup damage handling for fbdev's shadow buffer and fix a few issues. Specifically, the final patch adds locking to the code that flushes the shadow framebuffer into BO memory. During the conversion of radeon to generic fbdev, the question came up about interference with concurrent modesets. If fbdev has the BO pinned in system memory for flushing while the modeset wants to pin it to VRAM for scanout, the modeset would most likely fail. We haven't seen that so far, but it's possible at least. Acquiring the fb-helper lock during the flush operation prevents concurrent modesets from taking place. The code has been tested with SHMEM and TTM BOs; with atomic and non- atomic modesetting. [1] https://patchwork.freedesktop.org/patch/400054/?series=83765&rev=1 Thomas Zimmermann (10): drm/fb-helper: Call dirty helper after writing to fbdev drm/fb-helper: Unmap client buffer during shutdown drm/client: Depend on GEM object kmap ref-counting drm/fb-helper: Rename dirty worker to damage worker drm/fb-helper: Return early in dirty worker drm/fb-helper: Separate shadow-buffer flushing and calling dirty callback drm/fb-helper: Move damage blit code and its setup into separate routine drm/fb-helper: Restore damage area upon errors drm/fb-helper: Copy dma-buf map before flushing shadow fb drm/fb-helper: Acquire modeset lock around shadow-buffer flushing drivers/gpu/drm/drm_client.c| 4 - drivers/gpu/drm/drm_fb_helper.c | 155 +--- include/drm/drm_fb_helper.h | 14 +-- 3 files changed, 108 insertions(+), 65 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/10] drm/client: Depend on GEM object kmap ref-counting
DRM client's vmap/vunmap functions don't allow for multiple vmap operations. Calling drm_client_buffer_vmap() twice returns the same mapping, then calling drm_client_buffer_vunmap() twice already unmaps on the first call. This leads to unbalanced vmap refcounts. Fix this by calling drm_gem_vmap() unconditionally in drm_client_buffer_vmap(). All drivers that support DRM clients have to implement correct ref- counting for their vmap operations, or not vunmap at all. This is the case for drivers that use CMA, SHMEM and VRAM helpers, and QXL. Other drivers are not affected. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_client.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c index fe573acf1067..ce45e380f4a2 100644 --- a/drivers/gpu/drm/drm_client.c +++ b/drivers/gpu/drm/drm_client.c @@ -314,9 +314,6 @@ drm_client_buffer_vmap(struct drm_client_buffer *buffer, struct dma_buf_map *map struct dma_buf_map *map = &buffer->map; int ret; - if (dma_buf_map_is_set(map)) - goto out; - /* * FIXME: The dependency on GEM here isn't required, we could * convert the driver handle to a dma-buf instead and use the @@ -329,7 +326,6 @@ drm_client_buffer_vmap(struct drm_client_buffer *buffer, struct dma_buf_map *map if (ret) return ret; -out: *map_copy = *map; return 0; -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] drm/fb-helper: Return early in dirty worker
Returning early in the dirty worker if no update is required makes the
code more readable. No functional changes are made.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 87d4759de04a..c90185f9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -407,24 +407,23 @@ static void drm_fb_helper_damage_work(struct work_struct
*work)
clip->x2 = clip->y2 = 0;
spin_unlock_irqrestore(&helper->damage_lock, flags);
- /* call dirty callback only when it has been really touched */
- if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) {
-
- /* Generic fbdev uses a shadow buffer */
- if (helper->buffer) {
- ret = drm_client_buffer_vmap(helper->buffer, &map);
- if (ret)
- return;
- drm_fb_helper_damage_blit_real(helper, &clip_copy,
&map);
- }
-
- if (helper->fb->funcs->dirty)
- helper->fb->funcs->dirty(helper->fb, NULL, 0, 0,
-&clip_copy, 1);
+ /* Call damage handlers only if necessary */
+ if (!(clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2))
+ return;
- if (helper->buffer)
- drm_client_buffer_vunmap(helper->buffer);
+ /* Generic fbdev uses a shadow buffer */
+ if (helper->buffer) {
+ ret = drm_client_buffer_vmap(helper->buffer, &map);
+ if (ret)
+ return;
+ drm_fb_helper_damage_blit_real(helper, &clip_copy, &map);
}
+
+ if (helper->fb->funcs->dirty)
+ helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
+
+ if (helper->buffer)
+ drm_client_buffer_vunmap(helper->buffer);
}
/**
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/10] drm/fb-helper: Restore damage area upon errors
If the damage handling fails, restore the damage area. The next invocation
of the damage worker will then perform the update.
v2:
* print a single warning if dirty callback fails (Daniel, Sebastian)
* update comment
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b0bde894bf39..b36d9852cdf7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -432,11 +432,28 @@ static void drm_fb_helper_damage_work(struct work_struct
*work)
if (helper->buffer) {
ret = drm_fb_helper_damage_blit(helper, &clip_copy);
if (drm_WARN_ON_ONCE(dev, ret))
- return;
+ goto err;
}
- if (helper->fb->funcs->dirty)
- helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
+ if (helper->fb->funcs->dirty) {
+ ret = helper->fb->funcs->dirty(helper->fb, NULL, 0, 0,
&clip_copy, 1);
+ if (drm_WARN_ON_ONCE(dev, ret))
+ goto err;
+ }
+
+ return;
+
+err:
+ /*
+* Restore damage clip rectangle on errors. The next run
+* of the damage worker will perform the update.
+*/
+ spin_lock_irqsave(&helper->damage_lock, flags);
+ clip->x1 = min_t(u32, clip->x1, clip_copy.x1);
+ clip->y1 = min_t(u32, clip->y1, clip_copy.y1);
+ clip->x2 = max_t(u32, clip->x2, clip_copy.x2);
+ clip->y2 = max_t(u32, clip->y2, clip_copy.y2);
+ spin_unlock_irqrestore(&helper->damage_lock, flags);
}
/**
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/10] drm/fb-helper: Rename dirty worker to damage worker
The dirty worker handles all damage updates, instead of just calling
the framebuffer's dirty callback. Rename it to damage worker. Also
rename related variables accordingly. No functional changes are made.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 65 +++--
include/drm/drm_fb_helper.h | 14 +++
2 files changed, 36 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index aa7af463c50d..87d4759de04a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -371,9 +371,9 @@ static void drm_fb_helper_resume_worker(struct work_struct
*work)
console_unlock();
}
-static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
- struct drm_clip_rect *clip,
- struct dma_buf_map *dst)
+static void drm_fb_helper_damage_blit_real(struct drm_fb_helper *fb_helper,
+ struct drm_clip_rect *clip,
+ struct dma_buf_map *dst)
{
struct drm_framebuffer *fb = fb_helper->fb;
unsigned int cpp = fb->format->cpp[0];
@@ -391,21 +391,21 @@ static void drm_fb_helper_dirty_blit_real(struct
drm_fb_helper *fb_helper,
}
}
-static void drm_fb_helper_dirty_work(struct work_struct *work)
+static void drm_fb_helper_damage_work(struct work_struct *work)
{
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
- dirty_work);
- struct drm_clip_rect *clip = &helper->dirty_clip;
+ damage_work);
+ struct drm_clip_rect *clip = &helper->damage_clip;
struct drm_clip_rect clip_copy;
unsigned long flags;
struct dma_buf_map map;
int ret;
- spin_lock_irqsave(&helper->dirty_lock, flags);
+ spin_lock_irqsave(&helper->damage_lock, flags);
clip_copy = *clip;
clip->x1 = clip->y1 = ~0;
clip->x2 = clip->y2 = 0;
- spin_unlock_irqrestore(&helper->dirty_lock, flags);
+ spin_unlock_irqrestore(&helper->damage_lock, flags);
/* call dirty callback only when it has been really touched */
if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) {
@@ -415,7 +415,7 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
ret = drm_client_buffer_vmap(helper->buffer, &map);
if (ret)
return;
- drm_fb_helper_dirty_blit_real(helper, &clip_copy, &map);
+ drm_fb_helper_damage_blit_real(helper, &clip_copy,
&map);
}
if (helper->fb->funcs->dirty)
@@ -440,10 +440,10 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
const struct drm_fb_helper_funcs *funcs)
{
INIT_LIST_HEAD(&helper->kernel_fb_list);
- spin_lock_init(&helper->dirty_lock);
+ spin_lock_init(&helper->damage_lock);
INIT_WORK(&helper->resume_work, drm_fb_helper_resume_worker);
- INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
- helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
+ INIT_WORK(&helper->damage_work, drm_fb_helper_damage_work);
+ helper->damage_clip.x1 = helper->damage_clip.y1 = ~0;
mutex_init(&helper->lock);
helper->funcs = funcs;
helper->dev = dev;
@@ -579,7 +579,7 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
return;
cancel_work_sync(&fb_helper->resume_work);
- cancel_work_sync(&fb_helper->dirty_work);
+ cancel_work_sync(&fb_helper->damage_work);
info = fb_helper->fbdev;
if (info) {
@@ -614,30 +614,30 @@ static bool drm_fbdev_use_shadow_fb(struct drm_fb_helper
*fb_helper)
fb->funcs->dirty;
}
-static void drm_fb_helper_dirty(struct fb_info *info, u32 x, u32 y,
- u32 width, u32 height)
+static void drm_fb_helper_damage(struct fb_info *info, u32 x, u32 y,
+u32 width, u32 height)
{
struct drm_fb_helper *helper = info->par;
- struct drm_clip_rect *clip = &helper->dirty_clip;
+ struct drm_clip_rect *clip = &helper->damage_clip;
unsigned long flags;
if (!drm_fbdev_use_shadow_fb(helper))
return;
- spin_lock_irqsave(&helper->dirty_lock, flags);
+ spin_lock_irqsave(&helper->damage_lock, flags);
clip->x1 = min_t(u32, clip->x1, x);
clip->y1 = min_t(u32, clip->y1, y);
clip->x2 = max_t(u32, clip->x2, x + width);
clip->y2 = max_t(u32, clip->y2, y + height);
- spin_unlock_irqrestore(&helper->dirty_lock, flags);
+ spin_unlock_irqrestore(&helper->damage_lo
[PATCH v2 09/10] drm/fb-helper: Copy dma-buf map before flushing shadow fb
Copy the vmap()'ed instance of struct dma_buf_map before modifying it,
in case the implementation of vunmap() depends on the exact address.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b36d9852cdf7..d972ce75d180 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -395,14 +395,15 @@ static int drm_fb_helper_damage_blit(struct drm_fb_helper
*fb_helper,
struct drm_clip_rect *clip)
{
struct drm_client_buffer *buffer = fb_helper->buffer;
- struct dma_buf_map map;
+ struct dma_buf_map map, dst;
int ret;
ret = drm_client_buffer_vmap(buffer, &map);
if (ret)
return ret;
- drm_fb_helper_damage_blit_real(fb_helper, clip, &map);
+ dst = map;
+ drm_fb_helper_damage_blit_real(fb_helper, clip, &dst);
drm_client_buffer_vunmap(buffer);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/10] drm/fb-helper: Acquire modeset lock around shadow-buffer flushing
Flushing the fbdev's shadow buffer requires vmap'ing the BO memory, which in turn requires pinning the BO. While being pinned, the BO cannot be moved into VRAM for scanout. Consequently, a concurrent modeset operation that involves the fbdev framebuffer would likely fail. Resolve this problem be acquiring the modeset lock of the planes that use the fbdev framebuffer. On non-atomic drivers, also acquire the mode-config lock. This serializes the flushing of the framebuffer with concurrent modeset operations. v2: * only acquire struct drm_fb_helper.lock in damage blitter (Daniel, Christian) Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_fb_helper.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index d972ce75d180..6f2763467e99 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -398,16 +398,32 @@ static int drm_fb_helper_damage_blit(struct drm_fb_helper *fb_helper, struct dma_buf_map map, dst; int ret; + /* +* We have to pin the client buffer to its current location while +* flushing the shadow buffer. In the general case, concurrent +* modesetting operations could try to move the buffer and would +* fail. The modeset has to be serialized by acquiring the reservation +* object of the underlying BO here. +* +* For fbdev emulation, we only have to protect against fbdev modeset +* operations. Nothing else will involve the client buffer's BO. So it +* is sufficient to acquire struct drm_fb_helper.lock here. +*/ + mutex_lock(&fb_helper->lock); + ret = drm_client_buffer_vmap(buffer, &map); if (ret) - return ret; + goto out; dst = map; drm_fb_helper_damage_blit_real(fb_helper, clip, &dst); drm_client_buffer_vunmap(buffer); - return 0; +out: + mutex_unlock(&fb_helper->lock); + + return ret; } static void drm_fb_helper_damage_work(struct work_struct *work) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/10] drm/fb-helper: Move damage blit code and its setup into separate routine
Introduce a separate function for the blit code and its vmap setup. Done
in preparation of additional changes. No functional changes are made.
v2:
* print a single warning if damage blitter fails
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bdfdf60e7bd8..b0bde894bf39 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -391,14 +391,32 @@ static void drm_fb_helper_damage_blit_real(struct
drm_fb_helper *fb_helper,
}
}
+static int drm_fb_helper_damage_blit(struct drm_fb_helper *fb_helper,
+struct drm_clip_rect *clip)
+{
+ struct drm_client_buffer *buffer = fb_helper->buffer;
+ struct dma_buf_map map;
+ int ret;
+
+ ret = drm_client_buffer_vmap(buffer, &map);
+ if (ret)
+ return ret;
+
+ drm_fb_helper_damage_blit_real(fb_helper, clip, &map);
+
+ drm_client_buffer_vunmap(buffer);
+
+ return 0;
+}
+
static void drm_fb_helper_damage_work(struct work_struct *work)
{
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
damage_work);
+ struct drm_device *dev = helper->dev;
struct drm_clip_rect *clip = &helper->damage_clip;
struct drm_clip_rect clip_copy;
unsigned long flags;
- struct dma_buf_map map;
int ret;
spin_lock_irqsave(&helper->damage_lock, flags);
@@ -411,13 +429,10 @@ static void drm_fb_helper_damage_work(struct work_struct
*work)
if (!(clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2))
return;
- /* Generic fbdev uses a shadow buffer */
if (helper->buffer) {
- ret = drm_client_buffer_vmap(helper->buffer, &map);
- if (ret)
+ ret = drm_fb_helper_damage_blit(helper, &clip_copy);
+ if (drm_WARN_ON_ONCE(dev, ret))
return;
- drm_fb_helper_damage_blit_real(helper, &clip_copy, &map);
- drm_client_buffer_vunmap(helper->buffer);
}
if (helper->fb->funcs->dirty)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/10] drm/fb-helper: Unmap client buffer during shutdown
The fbdev helper's generic probe function establishes a mapping for
framebuffers without shadow buffer. The clean-up function did not unmap
the buffer object. Add the unmap operation.
As fbdev devices are usally released during system shutdown, this has
not been a problem in practice.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9c673f33d222..aa7af463c50d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1988,14 +1988,19 @@ static void drm_fbdev_cleanup(struct drm_fb_helper
*fb_helper)
if (!fb_helper->dev)
return;
- if (fbi && fbi->fbdefio) {
- fb_deferred_io_cleanup(fbi);
- shadow = fbi->screen_buffer;
+ if (fbi) {
+ if (fbi->fbdefio)
+ fb_deferred_io_cleanup(fbi);
+ if (drm_fbdev_use_shadow_fb(fb_helper))
+ shadow = fbi->screen_buffer;
}
drm_fb_helper_fini(fb_helper);
- vfree(shadow);
+ if (shadow)
+ vfree(shadow);
+ else
+ drm_client_buffer_vunmap(fb_helper->buffer);
drm_client_framebuffer_delete(fb_helper->buffer);
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/10] drm/fb-helper: Separate shadow-buffer flushing and calling dirty callback
Flushing the shadow framebuffer and invoking the dirty callback are two separate operations, so do them seprately. The flush operation is paired with calls to vmap and vunmap. They are not needed for the dirty callback, which performs its own invocations if necessary. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_fb_helper.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index c90185f9..bdfdf60e7bd8 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -417,13 +417,11 @@ static void drm_fb_helper_damage_work(struct work_struct *work) if (ret) return; drm_fb_helper_damage_blit_real(helper, &clip_copy, &map); + drm_client_buffer_vunmap(helper->buffer); } if (helper->fb->funcs->dirty) helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1); - - if (helper->buffer) - drm_client_buffer_vunmap(helper->buffer); } /** -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210123] drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] - flip_done time out with vmwgfx
https://bugzilla.kernel.org/show_bug.cgi?id=210123 --- Comment #4 from Stefan Mayr (stefan+ker...@mayr-stefan.de) --- I had another look at bug 208373: the inital reporter also uses vmwgfx and amdgpu is only mentioned in bug 208373, comment 2 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe
On 20/11/2020 10:18, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
>>
>> On 20/11/2020 09:06, Hans Verkuil wrote:
>>> On 19/11/2020 15:41, Daniel Vetter wrote:
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real fix
is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
tell everyone to cut over to dma-buf memory sharing for zerocopy.
userptr for normal memory will keep working as-is, this only affects
the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
videobuf2-dma-sg: Support io userptr operations on io memory").
Acked-by: Tomasz Figa
>>>
>>> Acked-by: Hans Verkuil
>>
>> Actually, cancel this Acked-by.
>>
>> So let me see if I understand this right: VM_IO | VM_PFNMAP mappings can
>> move around. There is a mmu_notifier that can be used to be notified when
>> that happens, but that can't be used with media buffers since those buffers
>> must always be available and in the same place.
>>
>> So follow_pfn is replaced by unsafe_follow_pfn to signal that what is
>> attempted
>> is unsafe and unreliable.
>>
>> If CONFIG_STRICT_FOLLOW_PFN is set, then unsafe_follow_pfn will fail, if it
>> is unset, then it writes a warning to the kernel log but just continues while
>> still unsafe.
>>
>> I am very much inclined to just drop VM_IO | VM_PFNMAP support in the media
>> subsystem. For vb2 there is a working alternative in the form of dmabuf, and
>> frankly for vb1 I don't care. If someone really needs this for a vb1 driver,
>> then they can do the work to convert that driver to vb2.
>>
>> I've added Mauro to the CC list and I'll ping a few more people to see what
>> they think, but in my opinion support for USERPTR + VM_IO | VM_PFNMAP
>> should just be killed off.
>>
>> If others would like to keep it, then frame_vector.c needs a comment before
>> the 'while' explaining why the unsafe_follow_pfn is there and that using
>> dmabuf is the proper alternative to use. That will make it easier for
>> developers to figure out why they see a kernel warning and what to do to
>> fix it, rather than having to dig through the git history for the reason.
>
> I'm happy to add a comment, but otherwise if you all want to ditch
> this, can we do this as a follow up on top? There's quite a bit of
> code that can be deleted and I'd like to not hold up this patch set
> here on that - it's already a fairly sprawling pain touching about 7
> different subsystems (ok only 6-ish now since the s390 patch landed).
> For the comment, is the explanation next to unsafe_follow_pfn not good
> enough?
No, because that doesn't mention that you should use dma-buf as a replacement.
That's really the critical piece of information I'd like to see. That doesn't
belong in unsafe_follow_pfn, it needs to be in frame_vector.c since it's
vb2 specific.
>
> So ... can I get you to un-cancel your ack?
Hmm, I really would like to see support for this to be dropped completely.
How about this: just replace follow_pfn() by -EINVAL instead of
unsafe_follow_pfn().
Add a TODO comment that this code now can be cleaned up a lot. Such a clean up
patch
can be added on top later, and actually that is something that I can do once
this
series has landed.
Regardless, frame_vector.c should mention dma-buf as a replacement in a comment
since I don't want users who hit this issue to have to dig through git logs
to find that dma-buf is the right approach.
BTW, nitpick: the subject line of this patch says 'videbuf' instead of
'videobuf'.
Regards,
Hans
>
> Thanks, Daniel
>
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> Thanks!
>>>
>>> Hans
>>>
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Laurent Dufour
Cc: Vlastimil Babka
Cc: Daniel Jordan
Cc: Michel Lespinasse
Signed-off-by: Daniel Vetter
--
v3:
- Reference the commit that enabled the zerocopy userptr use case to
make it abundandtly clear that this patch only affects that, and not
normal memory userptr. The old commit message already explained that
normal memory userptr is unaffected, but I guess that was not clear
enough.
---
drivers/media/common/videobuf2/frame_vector.c | 2 +-
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
>
Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe
On Fri, Nov 20, 2020 at 11:39 AM Hans Verkuil wrote:
>
> On 20/11/2020 10:18, Daniel Vetter wrote:
> > On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
> >>
> >> On 20/11/2020 09:06, Hans Verkuil wrote:
> >>> On 19/11/2020 15:41, Daniel Vetter wrote:
> The media model assumes that buffers are all preallocated, so that
> when a media pipeline is running we never miss a deadline because the
> buffers aren't allocated or available.
>
> This means we cannot fix the v4l follow_pfn usage through
> mmu_notifier, without breaking how this all works. The only real fix
> is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
> tell everyone to cut over to dma-buf memory sharing for zerocopy.
>
> userptr for normal memory will keep working as-is, this only affects
> the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
> videobuf2-dma-sg: Support io userptr operations on io memory").
>
> Acked-by: Tomasz Figa
> >>>
> >>> Acked-by: Hans Verkuil
> >>
> >> Actually, cancel this Acked-by.
> >>
> >> So let me see if I understand this right: VM_IO | VM_PFNMAP mappings can
> >> move around. There is a mmu_notifier that can be used to be notified when
> >> that happens, but that can't be used with media buffers since those buffers
> >> must always be available and in the same place.
> >>
> >> So follow_pfn is replaced by unsafe_follow_pfn to signal that what is
> >> attempted
> >> is unsafe and unreliable.
> >>
> >> If CONFIG_STRICT_FOLLOW_PFN is set, then unsafe_follow_pfn will fail, if it
> >> is unset, then it writes a warning to the kernel log but just continues
> >> while
> >> still unsafe.
> >>
> >> I am very much inclined to just drop VM_IO | VM_PFNMAP support in the media
> >> subsystem. For vb2 there is a working alternative in the form of dmabuf,
> >> and
> >> frankly for vb1 I don't care. If someone really needs this for a vb1
> >> driver,
> >> then they can do the work to convert that driver to vb2.
> >>
> >> I've added Mauro to the CC list and I'll ping a few more people to see what
> >> they think, but in my opinion support for USERPTR + VM_IO | VM_PFNMAP
> >> should just be killed off.
> >>
> >> If others would like to keep it, then frame_vector.c needs a comment before
> >> the 'while' explaining why the unsafe_follow_pfn is there and that using
> >> dmabuf is the proper alternative to use. That will make it easier for
> >> developers to figure out why they see a kernel warning and what to do to
> >> fix it, rather than having to dig through the git history for the reason.
> >
> > I'm happy to add a comment, but otherwise if you all want to ditch
> > this, can we do this as a follow up on top? There's quite a bit of
> > code that can be deleted and I'd like to not hold up this patch set
> > here on that - it's already a fairly sprawling pain touching about 7
> > different subsystems (ok only 6-ish now since the s390 patch landed).
> > For the comment, is the explanation next to unsafe_follow_pfn not good
> > enough?
>
> No, because that doesn't mention that you should use dma-buf as a replacement.
> That's really the critical piece of information I'd like to see. That doesn't
> belong in unsafe_follow_pfn, it needs to be in frame_vector.c since it's
> vb2 specific.
Ah makes sense, I'll add that.
> >
> > So ... can I get you to un-cancel your ack?
>
> Hmm, I really would like to see support for this to be dropped completely.
>
> How about this: just replace follow_pfn() by -EINVAL instead of
> unsafe_follow_pfn().
>
> Add a TODO comment that this code now can be cleaned up a lot. Such a clean
> up patch
> can be added on top later, and actually that is something that I can do once
> this
> series has landed.
>
> Regardless, frame_vector.c should mention dma-buf as a replacement in a
> comment
> since I don't want users who hit this issue to have to dig through git logs
> to find that dma-buf is the right approach.
>
> BTW, nitpick: the subject line of this patch says 'videbuf' instead of
> 'videobuf'.
Will fix to, and next round will have the additional -EINVAL on top.
Iirc Mauro was pretty clear that we can't just delete this, so I kinda
don't want to get stuck in this discussion with my patches :-)
-Daniel
>
> Regards,
>
> Hans
>
> >
> > Thanks, Daniel
> >
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>>
> >>> Thanks!
> >>>
> >>> Hans
> >>>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: Laurent Dufour
> Cc: Vlastimil Babk
Re: [PATCH 2/2] drm/meson: dw-hdmi: Enable the iahb clock early enough
On 20/11/2020 09:42, Marc Zyngier wrote:
> Instead of moving meson_dw_hdmi_init() around which breaks existing
> platform, let's enable the clock meson_dw_hdmi_init() depends on.
> This means we don't have to worry about this clock being enabled or
> not, depending on the boot-loader features.
>
> Fixes: b33340e33acd ("drm/meson: dw-hdmi: Ensure that clocks are enabled
> before touching the TOP registers")
> Reported-by: Guillaume Tucker
Although I am triaging kernelci bisections, it was initially
found thanks to our friendly bot. So if you're OK with this, it
would most definitely appreciate a mention:
Reported-by: "kernelci.org bot"
Thanks,
Guillaume
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
On Fri, Nov 20, 2020 at 10:39:45AM +0100, Daniel Vetter wrote: > On Fri, Nov 20, 2020 at 8:58 AM Dan Carpenter > wrote: > > > > On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote: > > > On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter > > > wrote: > > > > > > > > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote: > > > > > Hi, > > > > > > > > > > On 10/27/20 2:51 PM, Hans de Goede wrote: > > > > > > Add missing pci_iounmap() calls to properly unmap the memory on > > > > > > probe-failure and remove. > > > > > > > > > > > > Reported-by: kernel test robot > > > > > > Reported-by: Dan Carpenter > > > > > > Signed-off-by: Hans de Goede > > > > > > > > > > For some reason the spam-filter used by Red Hat's email system has > > > > > eaten > > > > > Daniel Vetter's reply to this, so let me copy and paste that from > > > > > patchwork: > > > > > > > > > > Daniel Vetter wrote: > > > > > > > > > > > I think switching over to devm would be really nice. And for pci all > > > > > > you need to do is use pcim_enable_device and delete all the cleanup > > > > > > code, and it's all done. Hand rolling device cleanup code really > > > > > > isn't > > > > > > a great idea and way too error-prone. Plus you're using lots of > > > > > > devm_ > > > > > > already. > > > > > > > > > > Good point, so I just checked and the vboxvideo code is already > > > > > using pcim_enable_device() so it looks like this is a false-positive > > > > > from the l...@intel.com bot, and Dan Carpenter missed that > > > > > pcim_enable_device() > > > > > makes all subsequent pci-resource acquiring calls behave like devm > > > > > calls, > > > > > when he forwarded the report to me. > > > > > > > > > > Tl;DR: there is no bug / leak and this patch can be dropped. > > > > > > > > > > Is there a place where I can report a bug against the l...@intel.com > > > > > bot > > > > > for this false-positive ? > > > > > > > > Ah. Thanks! > > > > > > > > This is a Smatch bug. There is a list for that sma...@vger.kernel.org > > > > but I already remove the pci_iomap() from the list of functions that > > > > needs to be unwound based on your report. > > > > > > I guess if smatch sees a pci_enable_device but not pcim_enable_device > > > on the same device as passed to pci_iomap (and a pile of other pci > > > functions) then it still must be unwound. Could smatch detect that? > > > There's a lot of pci drivers not using the managed functions, catching > > > bugs in these would be good. > > > > It's a lot of code. There would be two ways to implement this: > > > > 1) Somehow store the links to figure out the value of: > > > > devres_find(vbox->ddev.pdev.dev)->enabled > > > > That's very complicated. I'm sort of working on some of the steps > > involved but and it's probably a multi year process before it's > > possible. > > > > 2) Create a data base table with driver data, then store if the driver > > calls pcim_enable_device(). This is still a bit of work, but probably > > straight forward. Storing driver data would be useful for other things > > as well. > > Hm maybe I totally misunderstand how smatch works, but I thought you > can track additional invariants and stuff on various pointers. So I > figured you just track whether pci_enable_device has been called on a > struct pci_device *dev, and then if anyone calls pci_iomap on the same > pointer and there's no cleanup, it's a bug. For any other case you > just can't tell (since absence of pcim_enable_device might just mean > that smatch doesn't see through the maze). Or is that what you meant > with approach 2? Hm... Your idea is another option #3. It's probably less work. I'll take a look at it. regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208373] drm:drm_atomic_helper_wait_for_dependencies - drm_kms_helper - flip_done timed out
https://bugzilla.kernel.org/show_bug.cgi?id=208373 --- Comment #6 from Michel Dänzer (mic...@daenzer.net) --- The original report here is about the vmwgfx driver; issues with amdgpu should be tracked elsewhere. sander44, are you seeing any problem other than the messages? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fix kernel-doc warnings for SCALING_FILTER
This patch fixes the following kernel-doc warnings:
/home/simon/src/linux/Documentation/gpu/drm-kms:466:
./drivers/gpu/drm/drm_crtc.c:236: WARNING: Unexpected indentation.
/home/simon/src/linux/Documentation/gpu/drm-kms:466:
./drivers/gpu/drm/drm_crtc.c:237: WARNING: Block quote ends without a blank
line; unexpected unindent.
/home/simon/src/linux/Documentation/gpu/drm-kms:472:
./drivers/gpu/drm/drm_blend.c:203: WARNING: Unexpected indentation.
/home/simon/src/linux/Documentation/gpu/drm-kms:472:
./drivers/gpu/drm/drm_blend.c:204: WARNING: Block quote ends without a blank
line; unexpected unindent.
Signed-off-by: Simon Ser
Fixes: 5c759eda9b04 ("drm: Introduce plane and CRTC scaling filter properties")
Cc: Pankaj Bharadiya
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Uma Shankar
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_blend.c | 2 +-
drivers/gpu/drm/drm_crtc.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index ae2234aae93d..5c2141e9a9f4 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -196,10 +196,10 @@
* exposed and assumed to be black).
*
* SCALING_FILTER:
- *
* Indicates scaling filter to be used for plane scaler
*
* The value of this property can be one of the following:
+ *
* Default:
* Driver's default scaling filter
* Nearest Neighbor:
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f927976eca50..74090fc3aa55 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -230,14 +230,14 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc
*crtc)
*
* Setting MODE_ID to 0 will release reserved resources for the CRTC.
* SCALING_FILTER:
- * Atomic property for setting the scaling filter for CRTC scaler
+ * Atomic property for setting the scaling filter for CRTC scaler
*
- * The value of this property can be one of the following:
- * Default:
- * Driver's default scaling filter
- * Nearest Neighbor:
- * Nearest Neighbor scaling filter
+ * The value of this property can be one of the following:
*
+ * Default:
+ * Driver's default scaling filter
+ * Nearest Neighbor:
+ * Nearest Neighbor scaling filter
*/
/**
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/virtio: suffix create blob call with _ioctl like any ioctl
On Wed, Nov 18, 2020 at 05:08:05PM -0800, Gurchetan Singh wrote: > From: Anthoine Bourgeois > > For coherency, all ioctls are suffixed > > Signed-off-by: Anthoine Bourgeois All pushed to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/meson: dw-hdmi: Enable the iahb clock early enough
On 2020-11-20 10:54, Guillaume Tucker wrote:
On 20/11/2020 09:42, Marc Zyngier wrote:
Instead of moving meson_dw_hdmi_init() around which breaks existing
platform, let's enable the clock meson_dw_hdmi_init() depends on.
This means we don't have to worry about this clock being enabled or
not, depending on the boot-loader features.
Fixes: b33340e33acd ("drm/meson: dw-hdmi: Ensure that clocks are
enabled before touching the TOP registers")
Reported-by: Guillaume Tucker
Although I am triaging kernelci bisections, it was initially
found thanks to our friendly bot. So if you're OK with this, it
would most definitely appreciate a mention:
Reported-by: "kernelci.org bot"
Sure. Neil can add this when (and if) he applies these patches.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 18/21] drm/tegra: Allocate per-engine channel in core code
To avoid duplication, allocate the per-engine shared channel in the
core code instead. Once MLOCKs are implemented on Host1x side, we
can also update this to avoid allocating a shared channel when
MLOCKs are enabled.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 11 +++
drivers/gpu/drm/tegra/drm.h | 4
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 7437c67924aa..7124b0b0154b 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -887,6 +887,14 @@ static struct drm_driver tegra_drm_driver = {
int tegra_drm_register_client(struct tegra_drm *tegra,
struct tegra_drm_client *client)
{
+ /*
+* When MLOCKs are implemented, change to allocate a shared channel
+* only when MLOCKs are disabled.
+*/
+ client->shared_channel = host1x_channel_request(&client->base);
+ if (!client->shared_channel)
+ return -EBUSY;
+
mutex_lock(&tegra->clients_lock);
list_add_tail(&client->list, &tegra->clients);
client->drm = tegra;
@@ -903,6 +911,9 @@ int tegra_drm_unregister_client(struct tegra_drm *tegra,
client->drm = NULL;
mutex_unlock(&tegra->clients_lock);
+ if (client->shared_channel)
+ host1x_channel_put(client->shared_channel);
+
return 0;
}
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index b25443255be6..3fc42fd97911 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -86,8 +86,12 @@ struct tegra_drm_client {
struct list_head list;
struct tegra_drm *drm;
+ /* Set by driver */
unsigned int version;
const struct tegra_drm_client_ops *ops;
+
+ /* Set by TegraDRM core */
+ struct host1x_channel *shared_channel;
};
static inline struct tegra_drm_client *
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 13/21] gpu: host1x: Reset max value when freeing a syncpoint
With job recovery becoming optional, syncpoints may have a mismatch
between their value and max value when freed. As such, when freeing,
set the max value to the current value of the syncpoint so that it
is in a sane state for the next user.
Signed-off-by: Mikko Perttunen
---
v3:
* Use host1x_syncpt_read instead of read_min to ensure syncpoint
value is current.
---
drivers/gpu/host1x/syncpt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 8d658e5f7db2..99d31932eb34 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -385,6 +385,7 @@ static void syncpt_release(struct kref *ref)
{
struct host1x_syncpt *sp = container_of(ref, struct host1x_syncpt, ref);
+ atomic_set(&sp->max_val, host1x_syncpt_read(sp));
sp->locked = false;
mutex_lock(&sp->host->syncpt_mutex);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/21] Host1x/TegraDRM UAPI
Hi all, here's the fourth revision of the Host1x/TegraDRM UAPI proposal. The changes at a high level in this revision are: * Small bugfixes for issues reported by CI bots * Removal of not strictly required features like sync_file FDs, reservations, partial mappings etc. from the submit UAPI. * All new UAPI placed under CONFIG_DRM_TEGRA_STAGING. The test suite[1] has been updated for the changes in this revision, The series can be also found in https://github.com/cyndis/linux/commits/work/host1x-uapi-v4. Older versions: v1: https://www.spinics.net/lists/linux-tegra/msg51000.html v2: https://www.spinics.net/lists/linux-tegra/msg53061.html v3: https://www.spinics.net/lists/linux-tegra/msg54370.html Thank you, Mikko [1] https://github.com/cyndis/uapi-test Mikko Perttunen (21): gpu: host1x: Use different lock classes for each client gpu: host1x: Allow syncpoints without associated client gpu: host1x: Show number of pending waiters in debugfs gpu: host1x: Remove cancelled waiters immediately gpu: host1x: Use HW-equivalent syncpoint expiration check gpu: host1x: Cleanup and refcounting for syncpoints gpu: host1x: Introduce UAPI header gpu: host1x: Implement /dev/host1x device node gpu: host1x: DMA fences and userspace fence creation gpu: host1x: Add no-recovery mode gpu: host1x: Add job release callback gpu: host1x: Add support for syncpoint waits in CDMA pushbuffer gpu: host1x: Reset max value when freeing a syncpoint gpu: host1x: Reserve VBLANK syncpoints at initialization drm/tegra: Add new UAPI to header drm/tegra: Boot VIC during runtime PM resume drm/tegra: Set resv fields when importing/exporting GEMs drm/tegra: Allocate per-engine channel in core code drm/tegra: Implement new UAPI drm/tegra: Implement job submission part of new UAPI drm/tegra: Add job firewall drivers/gpu/drm/tegra/Makefile | 4 + drivers/gpu/drm/tegra/dc.c | 10 +- drivers/gpu/drm/tegra/drm.c| 72 +++-- drivers/gpu/drm/tegra/drm.h| 9 + drivers/gpu/drm/tegra/gem.c| 2 + drivers/gpu/drm/tegra/gr2d.c | 4 +- drivers/gpu/drm/tegra/gr3d.c | 4 +- drivers/gpu/drm/tegra/uapi.h | 63 drivers/gpu/drm/tegra/uapi/firewall.c | 197 drivers/gpu/drm/tegra/uapi/gather_bo.c | 86 + drivers/gpu/drm/tegra/uapi/gather_bo.h | 22 ++ drivers/gpu/drm/tegra/uapi/submit.c| 427 + drivers/gpu/drm/tegra/uapi/submit.h| 20 ++ drivers/gpu/drm/tegra/uapi/uapi.c | 306 ++ drivers/gpu/drm/tegra/vic.c| 118 --- drivers/gpu/host1x/Makefile| 2 + drivers/gpu/host1x/bus.c | 7 +- drivers/gpu/host1x/cdma.c | 69 +++- drivers/gpu/host1x/debug.c | 14 +- drivers/gpu/host1x/dev.c | 15 + drivers/gpu/host1x/dev.h | 16 +- drivers/gpu/host1x/fence.c | 208 drivers/gpu/host1x/fence.h | 13 + drivers/gpu/host1x/hw/cdma_hw.c| 2 +- drivers/gpu/host1x/hw/channel_hw.c | 63 ++-- drivers/gpu/host1x/hw/debug_hw.c | 11 +- drivers/gpu/host1x/intr.c | 23 +- drivers/gpu/host1x/intr.h | 2 + drivers/gpu/host1x/job.c | 79 +++-- drivers/gpu/host1x/job.h | 14 + drivers/gpu/host1x/syncpt.c| 185 ++- drivers/gpu/host1x/syncpt.h| 16 +- drivers/gpu/host1x/uapi.c | 385 ++ drivers/gpu/host1x/uapi.h | 22 ++ drivers/staging/media/tegra-video/vi.c | 8 +- include/linux/host1x.h | 47 ++- include/uapi/drm/tegra_drm.h | 338 +-- include/uapi/linux/host1x.h| 134 38 files changed, 2729 insertions(+), 288 deletions(-) create mode 100644 drivers/gpu/drm/tegra/uapi.h create mode 100644 drivers/gpu/drm/tegra/uapi/firewall.c create mode 100644 drivers/gpu/drm/tegra/uapi/gather_bo.c create mode 100644 drivers/gpu/drm/tegra/uapi/gather_bo.h create mode 100644 drivers/gpu/drm/tegra/uapi/submit.c create mode 100644 drivers/gpu/drm/tegra/uapi/submit.h create mode 100644 drivers/gpu/drm/tegra/uapi/uapi.c create mode 100644 drivers/gpu/host1x/fence.c create mode 100644 drivers/gpu/host1x/fence.h create mode 100644 drivers/gpu/host1x/uapi.c create mode 100644 drivers/gpu/host1x/uapi.h create mode 100644 include/uapi/linux/host1x.h -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 17/21] drm/tegra: Set resv fields when importing/exporting GEMs
To allow sharing of implicit fences when exporting/importing dma_buf objects, set the 'resv' fields when importing or exporting GEM objects. Signed-off-by: Mikko Perttunen --- drivers/gpu/drm/tegra/gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c index 723df142a981..4a8acd4724bd 100644 --- a/drivers/gpu/drm/tegra/gem.c +++ b/drivers/gpu/drm/tegra/gem.c @@ -423,6 +423,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device *drm, } bo->gem.import_attach = attach; + bo->gem.resv = buf->resv; return bo; @@ -675,6 +676,7 @@ struct dma_buf *tegra_gem_prime_export(struct drm_gem_object *gem, exp_info.size = gem->size; exp_info.flags = flags; exp_info.priv = gem; + exp_info.resv = gem->resv; return drm_gem_dmabuf_export(gem->dev, &exp_info); } -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 01/21] gpu: host1x: Use different lock classes for each client
To avoid false lockdep warnings, give each client lock a different
lock class, passed from the initialization site by macro.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/bus.c | 7 ---
include/linux/host1x.h | 9 -
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index e201f62d62c0..4101f64bd545 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -714,13 +714,14 @@ EXPORT_SYMBOL(host1x_driver_unregister);
* device and call host1x_device_init(), which will in turn call each client's
* &host1x_client_ops.init implementation.
*/
-int host1x_client_register(struct host1x_client *client)
+int __host1x_client_register(struct host1x_client *client,
+ struct lock_class_key *key)
{
struct host1x *host1x;
int err;
INIT_LIST_HEAD(&client->list);
- mutex_init(&client->lock);
+ __mutex_init(&client->lock, "host1x client lock", key);
client->usecount = 0;
mutex_lock(&devices_lock);
@@ -741,7 +742,7 @@ int host1x_client_register(struct host1x_client *client)
return 0;
}
-EXPORT_SYMBOL(host1x_client_register);
+EXPORT_SYMBOL(__host1x_client_register);
/**
* host1x_client_unregister() - unregister a host1x client
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 20c885d0bddc..f711fc0154f4 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -320,7 +320,14 @@ static inline struct host1x_device
*to_host1x_device(struct device *dev)
int host1x_device_init(struct host1x_device *device);
int host1x_device_exit(struct host1x_device *device);
-int host1x_client_register(struct host1x_client *client);
+int __host1x_client_register(struct host1x_client *client,
+struct lock_class_key *key);
+#define host1x_client_register(class) \
+ ({ \
+ static struct lock_class_key __key; \
+ __host1x_client_register(class, &__key); \
+ })
+
int host1x_client_unregister(struct host1x_client *client);
int host1x_client_suspend(struct host1x_client *client);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/21] gpu: host1x: Remove cancelled waiters immediately
Before this patch, cancelled waiters would only be cleaned up
once their threshold value was reached. Make host1x_intr_put_ref
process the cancellation immediately to fix this.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/intr.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/host1x/intr.c b/drivers/gpu/host1x/intr.c
index 9245add23b5d..5d328d20ce6d 100644
--- a/drivers/gpu/host1x/intr.c
+++ b/drivers/gpu/host1x/intr.c
@@ -247,13 +247,17 @@ void host1x_intr_put_ref(struct host1x *host, unsigned
int id, void *ref)
struct host1x_waitlist *waiter = ref;
struct host1x_syncpt *syncpt;
- while (atomic_cmpxchg(&waiter->state, WLS_PENDING, WLS_CANCELLED) ==
- WLS_REMOVED)
- schedule();
+ atomic_cmpxchg(&waiter->state, WLS_PENDING, WLS_CANCELLED);
syncpt = host->syncpt + id;
- (void)process_wait_list(host, syncpt,
- host1x_syncpt_load(host->syncpt + id));
+
+ spin_lock(&syncpt->intr.lock);
+ if (atomic_cmpxchg(&waiter->state, WLS_CANCELLED, WLS_HANDLED) ==
+ WLS_CANCELLED) {
+ list_del(&waiter->list);
+ kref_put(&waiter->refcount, waiter_release);
+ }
+ spin_unlock(&syncpt->intr.lock);
kref_put(&waiter->refcount, waiter_release);
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 16/21] drm/tegra: Boot VIC during runtime PM resume
With the new UAPI implementation, engines are powered on and off
when there are active jobs, and the core code handles channel
allocation. To accommodate that, boot the engine as part of
runtime PM instead of using the open_channel callback, which is
not used by the new submit path.
Signed-off-by: Mikko Perttunen
---
v3:
* runtime_get/put is now done directly from submit path, so no
callbacks are added
* Reworded.
---
drivers/gpu/drm/tegra/vic.c | 114 +---
1 file changed, 53 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index cb476da59adc..5d2ad125dca3 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -29,7 +29,6 @@ struct vic_config {
struct vic {
struct falcon falcon;
- bool booted;
void __iomem *regs;
struct tegra_drm_client client;
@@ -52,48 +51,6 @@ static void vic_writel(struct vic *vic, u32 value, unsigned
int offset)
writel(value, vic->regs + offset);
}
-static int vic_runtime_resume(struct device *dev)
-{
- struct vic *vic = dev_get_drvdata(dev);
- int err;
-
- err = clk_prepare_enable(vic->clk);
- if (err < 0)
- return err;
-
- usleep_range(10, 20);
-
- err = reset_control_deassert(vic->rst);
- if (err < 0)
- goto disable;
-
- usleep_range(10, 20);
-
- return 0;
-
-disable:
- clk_disable_unprepare(vic->clk);
- return err;
-}
-
-static int vic_runtime_suspend(struct device *dev)
-{
- struct vic *vic = dev_get_drvdata(dev);
- int err;
-
- err = reset_control_assert(vic->rst);
- if (err < 0)
- return err;
-
- usleep_range(2000, 4000);
-
- clk_disable_unprepare(vic->clk);
-
- vic->booted = false;
-
- return 0;
-}
-
static int vic_boot(struct vic *vic)
{
#ifdef CONFIG_IOMMU_API
@@ -103,9 +60,6 @@ static int vic_boot(struct vic *vic)
void *hdr;
int err = 0;
- if (vic->booted)
- return 0;
-
#ifdef CONFIG_IOMMU_API
if (vic->config->supports_sid && spec) {
u32 value;
@@ -153,8 +107,6 @@ static int vic_boot(struct vic *vic)
return err;
}
- vic->booted = true;
-
return 0;
}
@@ -308,35 +260,76 @@ static int vic_load_firmware(struct vic *vic)
return err;
}
-static int vic_open_channel(struct tegra_drm_client *client,
- struct tegra_drm_context *context)
+
+static int vic_runtime_resume(struct device *dev)
{
- struct vic *vic = to_vic(client);
+ struct vic *vic = dev_get_drvdata(dev);
int err;
- err = pm_runtime_get_sync(vic->dev);
+ err = clk_prepare_enable(vic->clk);
if (err < 0)
return err;
+ usleep_range(10, 20);
+
+ err = reset_control_deassert(vic->rst);
+ if (err < 0)
+ goto disable;
+
+ usleep_range(10, 20);
+
err = vic_load_firmware(vic);
if (err < 0)
- goto rpm_put;
+ goto assert;
err = vic_boot(vic);
if (err < 0)
- goto rpm_put;
+ goto assert;
+
+ return 0;
+
+assert:
+ reset_control_assert(vic->rst);
+disable:
+ clk_disable_unprepare(vic->clk);
+ return err;
+}
+
+static int vic_runtime_suspend(struct device *dev)
+{
+ struct vic *vic = dev_get_drvdata(dev);
+ int err;
+
+ err = reset_control_assert(vic->rst);
+ if (err < 0)
+ return err;
+
+ usleep_range(2000, 4000);
+
+ clk_disable_unprepare(vic->clk);
+
+ return 0;
+}
+
+static int vic_open_channel(struct tegra_drm_client *client,
+ struct tegra_drm_context *context)
+{
+ struct vic *vic = to_vic(client);
+ int err;
+
+ err = pm_runtime_get_sync(vic->dev);
+ if (err < 0) {
+ pm_runtime_put(vic->dev);
+ return err;
+ }
context->channel = host1x_channel_get(vic->channel);
if (!context->channel) {
- err = -ENOMEM;
- goto rpm_put;
+ pm_runtime_put(vic->dev);
+ return -ENOMEM;
}
return 0;
-
-rpm_put:
- pm_runtime_put(vic->dev);
- return err;
}
static void vic_close_channel(struct tegra_drm_context *context)
@@ -344,7 +337,6 @@ static void vic_close_channel(struct tegra_drm_context
*context)
struct vic *vic = to_vic(context->client);
host1x_channel_put(context->channel);
-
pm_runtime_put(vic->dev);
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/21] gpu: host1x: Use HW-equivalent syncpoint expiration check
Make syncpoint expiration checks always use the same logic used by
the hardware. This ensures that there are no race conditions that
could occur because of the hardware triggering a syncpoint interrupt
and then the driver disagreeing.
One situation where this could occur is if a job incremented a
syncpoint too many times -- then the hardware would trigger an
interrupt, but the driver would assume that a syncpoint value
greater than the syncpoint's max value is in the future, and not
clean up the job.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/syncpt.c | 51 ++---
1 file changed, 2 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 5982fdf64e1c..9ca0d852e32f 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -306,59 +306,12 @@ EXPORT_SYMBOL(host1x_syncpt_wait);
bool host1x_syncpt_is_expired(struct host1x_syncpt *sp, u32 thresh)
{
u32 current_val;
- u32 future_val;
smp_rmb();
current_val = (u32)atomic_read(&sp->min_val);
- future_val = (u32)atomic_read(&sp->max_val);
-
- /* Note the use of unsigned arithmetic here (mod 1<<32).
-*
-* c = current_val = min_val= the current value of the syncpoint.
-* t = thresh = the value we are checking
-* f = future_val = max_val= the value c will reach when all
-*outstanding increments have completed.
-*
-* Note that c always chases f until it reaches f.
-*
-* Dtf = (f - t)
-* Dtc = (c - t)
-*
-* Consider all cases:
-*
-* A) .c..t..f.Dtf < Dtc need to wait
-* B) .c.f..t..Dtf > Dtc expired
-* C) ..t..c.f.Dtf > Dtc expired(Dct very
large)
-*
-* Any case where f==c: always expired (for any t).Dtf == Dcf
-* Any case where t==c: always expired (for any f).Dtf >= Dtc
(because Dtc==0)
-* Any case where t==f!=c: always wait.Dtf < Dtc
(because Dtf==0,
-* Dtc!=0)
-*
-* Other cases:
-*
-* A) .t..f..c.Dtf < Dtc need to wait
-* A) .f..c..t.Dtf < Dtc need to wait
-* A) .f..t..c.Dtf > Dtc expired
-*
-* So:
-* Dtf >= Dtc implies EXPIRED (return true)
-* Dtf < Dtc implies WAIT (return false)
-*
-* Note: If t is expired then we *cannot* wait on it. We would wait
-* forever (hang the system).
-*
-* Note: do NOT get clever and remove the -thresh from both sides. It
-* is NOT the same.
-*
-* If future valueis zero, we have a client managed sync point. In that
-* case we do a direct comparison.
-*/
- if (!host1x_syncpt_client_managed(sp))
- return future_val - thresh >= current_val - thresh;
- else
- return (s32)(current_val - thresh) >= 0;
+
+ return ((current_val - thresh) & 0x8000U) == 0U;
}
int host1x_syncpt_init(struct host1x *host)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/21] gpu: host1x: DMA fences and userspace fence creation
Add an implementation of dma_fences based on syncpoints. Syncpoint
interrupts are used to signal fences. Additionally, after
software signaling has been enabled, a 30 second timeout is started.
If the syncpoint threshold is not reached within this period,
the fence is signalled with an -ETIMEDOUT error code. This is to
allow fences that would never reach their syncpoint threshold to
be cleaned up.
Additionally, add a new /dev/host1x IOCTL for creating sync_file
file descriptors backed by syncpoint fences.
Signed-off-by: Mikko Perttunen
---
v4:
* Fix _signal prototype and include it to avoid warning
* Remove use of unused local in error path
v3:
* Move declaration of host1x_fence_extract to public header
---
drivers/gpu/host1x/Makefile | 1 +
drivers/gpu/host1x/fence.c | 208
drivers/gpu/host1x/fence.h | 13 +++
drivers/gpu/host1x/intr.c | 9 ++
drivers/gpu/host1x/intr.h | 2 +
drivers/gpu/host1x/uapi.c | 103 ++
include/linux/host1x.h | 4 +
7 files changed, 340 insertions(+)
create mode 100644 drivers/gpu/host1x/fence.c
create mode 100644 drivers/gpu/host1x/fence.h
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 882f928d75e1..a48af2cefae1 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -10,6 +10,7 @@ host1x-y = \
debug.o \
mipi.o \
uapi.o \
+ fence.o \
hw/host1x01.o \
hw/host1x02.o \
hw/host1x04.o \
diff --git a/drivers/gpu/host1x/fence.c b/drivers/gpu/host1x/fence.c
new file mode 100644
index ..b2484606c311
--- /dev/null
+++ b/drivers/gpu/host1x/fence.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Syncpoint dma_fence implementation
+ *
+ * Copyright (c) 2020, NVIDIA Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "fence.h"
+#include "intr.h"
+#include "syncpt.h"
+
+DEFINE_SPINLOCK(lock);
+
+struct host1x_syncpt_fence {
+ struct dma_fence base;
+
+ atomic_t signaling;
+
+ struct host1x_syncpt *sp;
+ u32 threshold;
+
+ struct host1x_waitlist *waiter;
+ void *waiter_ref;
+
+ struct delayed_work timeout_work;
+};
+
+static const char *syncpt_fence_get_driver_name(struct dma_fence *f)
+{
+ return "host1x";
+}
+
+static const char *syncpt_fence_get_timeline_name(struct dma_fence *f)
+{
+ return "syncpoint";
+}
+
+static bool syncpt_fence_enable_signaling(struct dma_fence *f)
+{
+ struct host1x_syncpt_fence *sf =
+ container_of(f, struct host1x_syncpt_fence, base);
+ int err;
+
+ if (host1x_syncpt_is_expired(sf->sp, sf->threshold))
+ return false;
+
+ dma_fence_get(f);
+
+ /*
+* The dma_fence framework requires the fence driver to keep a
+* reference to any fences for which 'enable_signaling' has been
+* called (and that have not been signalled).
+*
+* We provide a userspace API to create arbitrary syncpoint fences,
+* so we cannot normally guarantee that all fences get signalled.
+* As such, setup a timeout, so that long-lasting fences will get
+* reaped eventually.
+*/
+ schedule_delayed_work(&sf->timeout_work, msecs_to_jiffies(3));
+
+ err = host1x_intr_add_action(sf->sp->host, sf->sp, sf->threshold,
+HOST1X_INTR_ACTION_SIGNAL_FENCE, f,
+sf->waiter, &sf->waiter_ref);
+ if (err) {
+ cancel_delayed_work_sync(&sf->timeout_work);
+ dma_fence_put(f);
+ return false;
+ }
+
+ /* intr framework takes ownership of waiter */
+ sf->waiter = NULL;
+
+ /*
+* The fence may get signalled at any time after the above call,
+* so we need to initialize all state used by signalling
+* before it.
+*/
+
+ return true;
+}
+
+static void syncpt_fence_release(struct dma_fence *f)
+{
+ struct host1x_syncpt_fence *sf =
+ container_of(f, struct host1x_syncpt_fence, base);
+
+ if (sf->waiter)
+ kfree(sf->waiter);
+
+ dma_fence_free(f);
+}
+
+const struct dma_fence_ops syncpt_fence_ops = {
+ .get_driver_name = syncpt_fence_get_driver_name,
+ .get_timeline_name = syncpt_fence_get_timeline_name,
+ .enable_signaling = syncpt_fence_enable_signaling,
+ .release = syncpt_fence_release,
+};
+
+void host1x_fence_signal(struct host1x_syncpt_fence *f)
+{
+ if (atomic_xchg(&f->signaling, 1))
+ return;
+
+ /*
+* Cancel pending timeout work - if it races, it will
+* not get 'f->signaling' and return.
+*/
+ cancel_delayed_work_sync(&f->timeout_work);
+
+ host1x_intr_put_ref(f->sp->host, f->sp->id, f->waiter_ref);
+
+ dma_fence_signal(&f->base);
+ dma_fence_put(&f->base);
[PATCH v4 12/21] gpu: host1x: Add support for syncpoint waits in CDMA pushbuffer
Add support for inserting syncpoint waits in the CDMA pushbuffer.
These waits need to be done in HOST1X class, while gather submitted
by the application execute in engine class.
Support is added by converting the gather list of job into a command
list that can include both gathers and waits. When the job is
submitted, these commands are pushed as the appropriate opcodes
on the CDMA pushbuffer.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/hw/channel_hw.c | 51 +++
drivers/gpu/host1x/hw/debug_hw.c | 9 +++-
drivers/gpu/host1x/job.c | 67 +-
drivers/gpu/host1x/job.h | 14 +++
include/linux/host1x.h | 5 ++-
5 files changed, 105 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/host1x/hw/channel_hw.c
b/drivers/gpu/host1x/hw/channel_hw.c
index bf21512e5078..d88a32f73f5e 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -55,31 +55,46 @@ static void submit_gathers(struct host1x_job *job)
#endif
unsigned int i;
- for (i = 0; i < job->num_gathers; i++) {
- struct host1x_job_gather *g = &job->gathers[i];
- dma_addr_t addr = g->base + g->offset;
- u32 op2, op3;
+ for (i = 0; i < job->num_cmds; i++) {
+ struct host1x_job_cmd *cmd = &job->cmds[i];
- op2 = lower_32_bits(addr);
- op3 = upper_32_bits(addr);
+ if (cmd->is_wait) {
+ /* TODO use modern wait */
+ host1x_cdma_push(cdma,
+host1x_opcode_setclass(HOST1X_CLASS_HOST1X,
+ host1x_uclass_wait_syncpt_r(), 1),
+host1x_class_host_wait_syncpt(cmd->wait.id,
+ cmd->wait.threshold));
+ host1x_cdma_push(
+ cdma, host1x_opcode_setclass(job->class, 0, 0),
+ HOST1X_OPCODE_NOP);
+ } else {
+ struct host1x_job_gather *g = &cmd->gather;
- trace_write_gather(cdma, g->bo, g->offset, g->words);
+ dma_addr_t addr = g->base + g->offset;
+ u32 op2, op3;
- if (op3 != 0) {
+ op2 = lower_32_bits(addr);
+ op3 = upper_32_bits(addr);
+
+ trace_write_gather(cdma, g->bo, g->offset, g->words);
+
+ if (op3 != 0) {
#if HOST1X_HW >= 6
- u32 op1 = host1x_opcode_gather_wide(g->words);
- u32 op4 = HOST1X_OPCODE_NOP;
+ u32 op1 = host1x_opcode_gather_wide(g->words);
+ u32 op4 = HOST1X_OPCODE_NOP;
- host1x_cdma_push_wide(cdma, op1, op2, op3, op4);
+ host1x_cdma_push_wide(cdma, op1, op2, op3, op4);
#else
- dev_err(dev, "invalid gather for push buffer %pad\n",
- &addr);
- continue;
+ dev_err(dev, "invalid gather for push buffer
%pad\n",
+ &addr);
+ continue;
#endif
- } else {
- u32 op1 = host1x_opcode_gather(g->words);
+ } else {
+ u32 op1 = host1x_opcode_gather(g->words);
- host1x_cdma_push(cdma, op1, op2);
+ host1x_cdma_push(cdma, op1, op2);
+ }
}
}
}
@@ -126,7 +141,7 @@ static int channel_submit(struct host1x_job *job)
struct host1x *host = dev_get_drvdata(ch->dev->parent);
trace_host1x_channel_submit(dev_name(ch->dev),
- job->num_gathers, job->num_relocs,
+ job->num_cmds, job->num_relocs,
job->syncpt->id, job->syncpt_incrs);
/* before error checks, return current max */
diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index ceb48229d14b..35952fd5597e 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -208,10 +208,15 @@ static void show_channel_gathers(struct output *o, struct
host1x_cdma *cdma)
job->first_get, job->timeout,
job->num_slots, job->num_unpins);
- for (i = 0; i < job->num_gathers; i++) {
- struct host1x_job_gather *g = &job->gathers[i];
+ for (i = 0; i < job->num_cmds; i++) {
+ struct host1x_job_gather *g;
u32 *mapped;
+ if (job->cmds[i].is_wait)
+
[PATCH v4 10/21] gpu: host1x: Add no-recovery mode
Add a new property for jobs to enable or disable recovery i.e.
CPU increments of syncpoints to max value on job timeout. This
allows for a more solid model for hanged jobs, where userspace
doesn't need to guess if a syncpoint increment happened because
the job completed, or because job timeout was triggered.
On job timeout, we stop the channel, NOP all future jobs on the
channel using the same syncpoint, mark the syncpoint as locked
and resume the channel from the next job, if any.
The future jobs are NOPed, since because we don't do the CPU
increments, the value of the syncpoint is no longer synchronized,
and any waiters would become confused if a future job incremented
the syncpoint. The syncpoint is marked locked to ensure that any
future jobs cannot increment the syncpoint either, until the
application has recognized the situation and reallocated the
syncpoint.
Signed-off-by: Mikko Perttunen
---
v3:
* Move 'locked' check inside CDMA lock to prevent race
* Add clarifying comment to NOP-patching code
---
drivers/gpu/drm/tegra/drm.c| 1 +
drivers/gpu/host1x/cdma.c | 58 ++
drivers/gpu/host1x/hw/channel_hw.c | 2 +-
drivers/gpu/host1x/job.c | 4 +++
drivers/gpu/host1x/syncpt.c| 2 ++
drivers/gpu/host1x/syncpt.h| 12 +++
include/linux/host1x.h | 9 +
7 files changed, 81 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index ceea9db341f0..7437c67924aa 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -197,6 +197,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
job->client = client;
job->class = client->class;
job->serialize = true;
+ job->syncpt_recovery = true;
/*
* Track referenced BOs so that they can be unreferenced after the
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 6e6ca774f68d..bd151c3a2a5f 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -312,10 +312,6 @@ static void update_cdma_locked(struct host1x_cdma *cdma)
bool signal = false;
struct host1x_job *job, *n;
- /* If CDMA is stopped, queue is cleared and we can return */
- if (!cdma->running)
- return;
-
/*
* Walk the sync queue, reading the sync point registers as necessary,
* to consume as many sync queue entries as possible without blocking
@@ -324,7 +320,8 @@ static void update_cdma_locked(struct host1x_cdma *cdma)
struct host1x_syncpt *sp = job->syncpt;
/* Check whether this syncpt has completed, and bail if not */
- if (!host1x_syncpt_is_expired(sp, job->syncpt_end)) {
+ if (!host1x_syncpt_is_expired(sp, job->syncpt_end) &&
+ !job->cancelled) {
/* Start timer on next pending syncpt */
if (job->timeout)
cdma_start_timer_locked(cdma, job);
@@ -413,8 +410,11 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
else
restart_addr = cdma->last_pos;
+ if (!job)
+ goto resume;
+
/* do CPU increments for the remaining syncpts */
- if (job) {
+ if (job->syncpt_recovery) {
dev_dbg(dev, "%s: perform CPU incr on pending buffers\n",
__func__);
@@ -433,8 +433,44 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
dev_dbg(dev, "%s: finished sync_queue modification\n",
__func__);
+ } else {
+ struct host1x_job *failed_job = job;
+
+ host1x_job_dump(dev, job);
+
+ host1x_syncpt_set_locked(job->syncpt);
+ failed_job->cancelled = true;
+
+ list_for_each_entry_continue(job, &cdma->sync_queue, list) {
+ unsigned int i;
+
+ if (job->syncpt != failed_job->syncpt)
+ continue;
+
+ for (i = 0; i < job->num_slots; i++) {
+ unsigned int slot = (job->first_get/8 + i) %
+ HOST1X_PUSHBUFFER_SLOTS;
+ u32 *mapped = cdma->push_buffer.mapped;
+
+ /*
+* Overwrite opcodes with 0 word writes to
+* to offset 0xbad. This does nothing but
+* has a easily detected signature in debug
+* traces.
+*/
+ mapped[2*slot+0] = 0x1bad;
+ mapped[2*slot+1] = 0x1bad;
+ }
+
+ job->cancelled = true;
+ }
+
+ wmb
Re: Linux 5.10-rc4; graphics alignment
Hi
Am 20.11.20 um 11:51 schrieb David Laight:
From: Thomas Zimmermann
Sent: 20 November 2020 10:14
...
Is there any way to bisect through the parts of the
drm merge patch into v5.10-rc1 ?
That ought to be quicker (and less error prone) than
the bisect builds I was doing.
Note that the stack 'splat' is due to a later change.
It is separate from the broken pixel alignment.
I actually saw the vga text go 'funny' while the boot
was outputting all the [OK] messages (from systemd?)
before the graphic login stole tty1 (bloody stupid
to use tty1).
I don't need to use the failing system today, I'll
have another go at isolating the failure.
You can use drm-tip for testing, where many of the DRM patches go through.
https://cgit.freedesktop.org/drm/drm-tip/
It's fairly up-to-date.
Any idea of tags either side of the 5.10 merge?
The final commit before v5.9 appears to be
Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init interface")
I'd try this as a good commit. For the bad commit, just try HEAD.
Best regards
Thomas
I have two systems with AST chips and neither shows any of the symptoms
you describe; nor do we have such reports about drivers that use a
similar stack (hibmc, bochs). Could you provide the output of
dmesg | grep drm
[2.112303] fb0: switching to astdrmfb from EFI VGA
[2.120222] ast :02:00.0: [drm] Using P2A bridge for configuration
[2.120233] ast :02:00.0: [drm] AST 2400 detected
[2.120247] ast :02:00.0: [drm] Analog VGA only
[2.120257] ast :02:00.0: [drm] dram MCLK=408 Mhz type=1 bus_width=16
[2.121121] [drm] Initialized ast 0.1.0 20120228 for :02:00.0 on minor 0
[2.125838] fbcon: astdrmfb (fb0) is primary device
[2.152179] ast :02:00.0: [drm] fb0: astdrmfb frame buffer device
[6.061034] systemd[1]: Condition check resulted in Load Kernel Module drm
being skipped.
The output is the same for both good and bad kernels.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 07/21] gpu: host1x: Introduce UAPI header
Add the userspace interface header, specifying interfaces
for allocating and accessing syncpoints from userspace,
and for creating sync_file based fences based on syncpoint
thresholds.
Signed-off-by: Mikko Perttunen
---
include/uapi/linux/host1x.h | 134
1 file changed, 134 insertions(+)
create mode 100644 include/uapi/linux/host1x.h
diff --git a/include/uapi/linux/host1x.h b/include/uapi/linux/host1x.h
new file mode 100644
index ..9c8fb9425cb2
--- /dev/null
+++ b/include/uapi/linux/host1x.h
@@ -0,0 +1,134 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* Copyright (c) 2020 NVIDIA Corporation */
+
+#ifndef _UAPI__LINUX_HOST1X_H
+#define _UAPI__LINUX_HOST1X_H
+
+#include
+#include
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+struct host1x_allocate_syncpoint {
+ /**
+* @fd: [out]
+*
+* New file descriptor representing the allocated syncpoint.
+*/
+ __s32 fd;
+
+ __u32 reserved[3];
+};
+
+struct host1x_syncpoint_info {
+ /**
+* @id: [out]
+*
+* System-global ID of the syncpoint.
+*/
+ __u32 id;
+
+ __u32 reserved[3];
+};
+
+struct host1x_syncpoint_increment {
+ /**
+* @count: [in]
+*
+* Number of times to increment the syncpoint. The syncpoint can
+* be observed at in-between values, but each increment is atomic.
+*/
+ __u32 count;
+};
+
+struct host1x_read_syncpoint {
+ /**
+* @id: [in]
+*
+* ID of the syncpoint to read.
+*/
+ __u32 id;
+
+ /**
+* @value: [out]
+*
+* Current value of the syncpoint.
+*/
+ __u32 value;
+};
+
+struct host1x_create_fence {
+ /**
+* @id: [in]
+*
+* ID of the syncpoint to create a fence for.
+*/
+ __u32 id;
+
+ /**
+* @threshold: [in]
+*
+* When the syncpoint reaches this value, the fence will be signaled.
+* The syncpoint is considered to have reached the threshold when the
+* following condition is true:
+*
+* ((value - threshold) & 0x8000U) == 0U
+*
+*/
+ __u32 threshold;
+
+ /**
+* @fence_fd: [out]
+*
+* New sync_file file descriptor containing the created fence.
+*/
+ __s32 fence_fd;
+
+ __u32 reserved[1];
+};
+
+struct host1x_fence_extract_fence {
+ __u32 id;
+ __u32 threshold;
+};
+
+struct host1x_fence_extract {
+ /**
+* @fence_fd: [in]
+*
+* sync_file file descriptor
+*/
+ __s32 fence_fd;
+
+ /**
+* @num_fences: [in,out]
+*
+* In: size of the `fences_ptr` array counted in elements.
+* Out: required size of the `fences_ptr` array counted in elements.
+*/
+ __u32 num_fences;
+
+ /**
+* @fences_ptr: [in]
+*
+* Pointer to array of `struct host1x_fence_extract_fence`.
+*/
+ __u64 fences_ptr;
+
+ __u32 reserved[2];
+};
+
+#define HOST1X_IOCTL_ALLOCATE_SYNCPOINT _IOWR('X', 0x00, struct
host1x_allocate_syncpoint)
+#define HOST1X_IOCTL_READ_SYNCPOINT _IOR ('X', 0x01, struct
host1x_read_syncpoint)
+#define HOST1X_IOCTL_CREATE_FENCE_IOWR('X', 0x02, struct
host1x_create_fence)
+#define HOST1X_IOCTL_SYNCPOINT_INFO _IOWR('X', 0x03, struct
host1x_syncpoint_info)
+#define HOST1X_IOCTL_SYNCPOINT_INCREMENT _IOWR('X', 0x04, struct
host1x_syncpoint_increment)
+#define HOST1X_IOCTL_FENCE_EXTRACT _IOWR('X', 0x05, struct
host1x_fence_extract)
+
+#if defined(__cplusplus)
+}
+#endif
+
+#endif
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 06/21] gpu: host1x: Cleanup and refcounting for syncpoints
Add reference counting for allocated syncpoints to allow keeping
them allocated while jobs are referencing them. Additionally,
clean up various places using syncpoint IDs to use host1x_syncpt
pointers instead.
Signed-off-by: Mikko Perttunen
---
v4: Update from _free to _put in VI driver as well
---
drivers/gpu/drm/tegra/dc.c | 4 +-
drivers/gpu/drm/tegra/drm.c| 17 +++---
drivers/gpu/drm/tegra/gr2d.c | 4 +-
drivers/gpu/drm/tegra/gr3d.c | 4 +-
drivers/gpu/drm/tegra/vic.c| 4 +-
drivers/gpu/host1x/cdma.c | 11 ++--
drivers/gpu/host1x/dev.h | 7 ++-
drivers/gpu/host1x/hw/cdma_hw.c| 2 +-
drivers/gpu/host1x/hw/channel_hw.c | 10 ++--
drivers/gpu/host1x/hw/debug_hw.c | 2 +-
drivers/gpu/host1x/job.c | 5 +-
drivers/gpu/host1x/syncpt.c| 75 +++---
drivers/gpu/host1x/syncpt.h| 3 ++
drivers/staging/media/tegra-video/vi.c | 8 +--
include/linux/host1x.h | 8 +--
15 files changed, 103 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 9a0b3240bc58..efb41c10dad4 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2127,7 +2127,7 @@ static int tegra_dc_init(struct host1x_client *client)
drm_plane_cleanup(primary);
host1x_client_iommu_detach(client);
- host1x_syncpt_free(dc->syncpt);
+ host1x_syncpt_put(dc->syncpt);
return err;
}
@@ -2152,7 +2152,7 @@ static int tegra_dc_exit(struct host1x_client *client)
}
host1x_client_iommu_detach(client);
- host1x_syncpt_free(dc->syncpt);
+ host1x_syncpt_put(dc->syncpt);
return 0;
}
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index ba9d1c3e7cac..ceea9db341f0 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -171,7 +171,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
struct drm_tegra_syncpt syncpt;
struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
struct drm_gem_object **refs;
- struct host1x_syncpt *sp;
+ struct host1x_syncpt *sp = NULL;
struct host1x_job *job;
unsigned int num_refs;
int err;
@@ -298,8 +298,8 @@ int tegra_drm_submit(struct tegra_drm_context *context,
goto fail;
}
- /* check whether syncpoint ID is valid */
- sp = host1x_syncpt_get(host1x, syncpt.id);
+ /* Syncpoint ref will be dropped on job release. */
+ sp = host1x_syncpt_get_by_id(host1x, syncpt.id);
if (!sp) {
err = -ENOENT;
goto fail;
@@ -308,7 +308,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
job->is_addr_reg = context->client->ops->is_addr_reg;
job->is_valid_class = context->client->ops->is_valid_class;
job->syncpt_incrs = syncpt.incrs;
- job->syncpt_id = syncpt.id;
+ job->syncpt = sp;
job->timeout = 1;
if (args->timeout && args->timeout < 1)
@@ -327,6 +327,9 @@ int tegra_drm_submit(struct tegra_drm_context *context,
args->fence = job->syncpt_end;
fail:
+ if (sp)
+ host1x_syncpt_put(sp);
+
while (num_refs--)
drm_gem_object_put(refs[num_refs]);
@@ -380,7 +383,7 @@ static int tegra_syncpt_read(struct drm_device *drm, void
*data,
struct drm_tegra_syncpt_read *args = data;
struct host1x_syncpt *sp;
- sp = host1x_syncpt_get(host, args->id);
+ sp = host1x_syncpt_get_by_id_noref(host, args->id);
if (!sp)
return -EINVAL;
@@ -395,7 +398,7 @@ static int tegra_syncpt_incr(struct drm_device *drm, void
*data,
struct drm_tegra_syncpt_incr *args = data;
struct host1x_syncpt *sp;
- sp = host1x_syncpt_get(host1x, args->id);
+ sp = host1x_syncpt_get_by_id_noref(host1x, args->id);
if (!sp)
return -EINVAL;
@@ -409,7 +412,7 @@ static int tegra_syncpt_wait(struct drm_device *drm, void
*data,
struct drm_tegra_syncpt_wait *args = data;
struct host1x_syncpt *sp;
- sp = host1x_syncpt_get(host1x, args->id);
+ sp = host1x_syncpt_get_by_id_noref(host1x, args->id);
if (!sp)
return -EINVAL;
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 1a0d3ba6e525..d857a99b21a7 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -67,7 +67,7 @@ static int gr2d_init(struct host1x_client *client)
detach:
host1x_client_iommu_detach(client);
free:
- host1x_syncpt_free(client->syncpts[0]);
+ host1x_syncpt_put(client->syncpts[0]);
put:
host1x_channel_put(gr2d->channel);
return err;
@@ -86,7 +86,7 @@ static int gr2d_exit(struct host1x_client *client)
return err;
[PATCH v4 08/21] gpu: host1x: Implement /dev/host1x device node
Add the /dev/host1x device node, implementing the following
functionality:
- Reading syncpoint values
- Allocating syncpoints (providing syncpoint FDs)
- Incrementing syncpoints (based on syncpoint FD)
Signed-off-by: Mikko Perttunen
---
v4:
* Put UAPI under CONFIG_DRM_TEGRA_STAGING
v3:
* Pass process name as syncpoint name when allocating
syncpoint.
---
drivers/gpu/host1x/Makefile | 1 +
drivers/gpu/host1x/dev.c| 9 ++
drivers/gpu/host1x/dev.h| 3 +
drivers/gpu/host1x/uapi.c | 282
drivers/gpu/host1x/uapi.h | 22 +++
include/linux/host1x.h | 2 +
6 files changed, 319 insertions(+)
create mode 100644 drivers/gpu/host1x/uapi.c
create mode 100644 drivers/gpu/host1x/uapi.h
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 096017b8789d..882f928d75e1 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -9,6 +9,7 @@ host1x-y = \
job.o \
debug.o \
mipi.o \
+ uapi.o \
hw/host1x01.o \
hw/host1x02.o \
hw/host1x04.o \
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index d0ebb70e2fdd..641317d23828 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -461,6 +461,12 @@ static int host1x_probe(struct platform_device *pdev)
goto deinit_syncpt;
}
+ err = host1x_uapi_init(&host->uapi, host);
+ if (err) {
+ dev_err(&pdev->dev, "failed to initialize uapi\n");
+ goto deinit_intr;
+ }
+
host1x_debug_init(host);
if (host->info->has_hypervisor)
@@ -480,6 +486,8 @@ static int host1x_probe(struct platform_device *pdev)
host1x_unregister(host);
deinit_debugfs:
host1x_debug_deinit(host);
+ host1x_uapi_deinit(&host->uapi);
+deinit_intr:
host1x_intr_deinit(host);
deinit_syncpt:
host1x_syncpt_deinit(host);
@@ -501,6 +509,7 @@ static int host1x_remove(struct platform_device *pdev)
host1x_unregister(host);
host1x_debug_deinit(host);
+ host1x_uapi_deinit(&host->uapi);
host1x_intr_deinit(host);
host1x_syncpt_deinit(host);
reset_control_assert(host->rst);
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 63010ae37a97..7b8b7e20e32b 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -17,6 +17,7 @@
#include "intr.h"
#include "job.h"
#include "syncpt.h"
+#include "uapi.h"
struct host1x_syncpt;
struct host1x_syncpt_base;
@@ -143,6 +144,8 @@ struct host1x {
struct list_head list;
struct device_dma_parameters dma_parms;
+
+ struct host1x_uapi uapi;
};
void host1x_hypervisor_writel(struct host1x *host1x, u32 r, u32 v);
diff --git a/drivers/gpu/host1x/uapi.c b/drivers/gpu/host1x/uapi.c
new file mode 100644
index ..27b8761c3f35
--- /dev/null
+++ b/drivers/gpu/host1x/uapi.c
@@ -0,0 +1,282 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * /dev/host1x syncpoint interface
+ *
+ * Copyright (c) 2020, NVIDIA Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dev.h"
+#include "syncpt.h"
+#include "uapi.h"
+
+#include
+
+static int syncpt_file_release(struct inode *inode, struct file *file)
+{
+ struct host1x_syncpt *sp = file->private_data;
+
+ host1x_syncpt_put(sp);
+
+ return 0;
+}
+
+static int syncpt_file_ioctl_info(struct host1x_syncpt *sp, void __user *data)
+{
+ struct host1x_syncpoint_info args;
+ unsigned long copy_err;
+
+ copy_err = copy_from_user(&args, data, sizeof(args));
+ if (copy_err)
+ return -EFAULT;
+
+ if (args.reserved[0] || args.reserved[1] || args.reserved[2])
+ return -EINVAL;
+
+ args.id = sp->id;
+
+ copy_err = copy_to_user(data, &args, sizeof(args));
+ if (copy_err)
+ return -EFAULT;
+
+ return 0;
+}
+
+static int syncpt_file_ioctl_incr(struct host1x_syncpt *sp, void __user *data)
+{
+ struct host1x_syncpoint_increment args;
+ unsigned long copy_err;
+ u32 i;
+
+ copy_err = copy_from_user(&args, data, sizeof(args));
+ if (copy_err)
+ return -EFAULT;
+
+ for (i = 0; i < args.count; i++) {
+ host1x_syncpt_incr(sp);
+ if (signal_pending(current))
+ return -EINTR;
+ }
+
+ return 0;
+}
+
+static long syncpt_file_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ void __user *data = (void __user *)arg;
+ long err;
+
+ switch (cmd) {
+ case HOST1X_IOCTL_SYNCPOINT_INFO:
+ err = syncpt_file_ioctl_info(file->private_data, data);
+ break;
+
+ case HOST1X_IOCTL_SYNCPOINT_INCREMENT:
+ err = syncpt_file_ioctl_incr(file->private_data, data);
+ break;
+
+ default:
+
[PATCH v4 21/21] drm/tegra: Add job firewall
Add a firewall that validates jobs before submission to ensure
they don't do anything they aren't allowed to do, like accessing
memory they should not access.
The firewall is functionality-wise a copy of the firewall already
implemented in gpu/host1x. It is copied here as it makes more
sense for it to live on the DRM side, as it is only needed for
userspace job submissions, and generally the data it needs to
do its job is easier to access here.
In the future, the other implementation will be removed.
Signed-off-by: Mikko Perttunen
---
v3:
* New patch
---
drivers/gpu/drm/tegra/Makefile| 1 +
drivers/gpu/drm/tegra/uapi/firewall.c | 197 ++
drivers/gpu/drm/tegra/uapi/submit.c | 4 +
drivers/gpu/drm/tegra/uapi/submit.h | 3 +
4 files changed, 205 insertions(+)
create mode 100644 drivers/gpu/drm/tegra/uapi/firewall.c
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 059322e88943..4e3295f436f1 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -5,6 +5,7 @@ tegra-drm-y := \
drm.o \
uapi/uapi.o \
uapi/submit.o \
+ uapi/firewall.o \
uapi/gather_bo.o \
gem.o \
fb.o \
diff --git a/drivers/gpu/drm/tegra/uapi/firewall.c
b/drivers/gpu/drm/tegra/uapi/firewall.c
new file mode 100644
index ..a9c5b71bc235
--- /dev/null
+++ b/drivers/gpu/drm/tegra/uapi/firewall.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2010-2020 NVIDIA Corporation */
+
+#include "../drm.h"
+#include "../uapi.h"
+
+#include "submit.h"
+
+struct tegra_drm_firewall {
+ struct tegra_drm_submit_data *submit;
+ struct tegra_drm_client *client;
+ u32 *data;
+ u32 pos;
+ u32 end;
+};
+
+static int fw_next(struct tegra_drm_firewall *fw, u32 *word)
+{
+ if (fw->pos == fw->end)
+ return -EINVAL;
+
+ *word = fw->data[fw->pos++];
+
+ return 0;
+}
+
+static bool fw_check_addr_valid(struct tegra_drm_firewall *fw, u32 offset)
+{
+ u32 i;
+
+ for (i = 0; i < fw->submit->num_used_mappings; i++) {
+ struct tegra_drm_mapping *m =
fw->submit->used_mappings[i].mapping;
+
+ if (offset >= m->iova && offset <= m->iova_end)
+ return true;
+ }
+
+ return false;
+}
+
+static int fw_check_reg(struct tegra_drm_firewall *fw, u32 offset)
+{
+ bool is_addr;
+ u32 word;
+ int err;
+
+ err = fw_next(fw, &word);
+ if (err)
+ return err;
+
+ if (!fw->client->ops->is_addr_reg)
+ return 0;
+
+ is_addr = fw->client->ops->is_addr_reg(
+ fw->client->base.dev, fw->client->base.class, offset);
+
+ if (!is_addr)
+ return 0;
+
+ if (!fw_check_addr_valid(fw, word))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int fw_check_regs_seq(struct tegra_drm_firewall *fw, u32 offset,
+u32 count, bool incr)
+{
+ u32 i;
+
+ for (i = 0; i < count; i++) {
+ if (fw_check_reg(fw, offset))
+ return -EINVAL;
+
+ if (incr)
+ offset++;
+ }
+
+ return 0;
+}
+
+static int fw_check_regs_mask(struct tegra_drm_firewall *fw, u32 offset,
+ u16 mask)
+{
+ unsigned long bmask = mask;
+ unsigned int bit;
+
+ for_each_set_bit(bit, &bmask, 16) {
+ if (fw_check_reg(fw, offset+bit))
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int fw_check_regs_imm(struct tegra_drm_firewall *fw, u32 offset)
+{
+ bool is_addr;
+
+ is_addr = fw->client->ops->is_addr_reg(fw->client->base.dev,
+ fw->client->base.class, offset);
+ if (is_addr)
+ return -EINVAL;
+
+ return 0;
+}
+
+enum {
+HOST1X_OPCODE_SETCLASS = 0x00,
+HOST1X_OPCODE_INCR = 0x01,
+HOST1X_OPCODE_NONINCR = 0x02,
+HOST1X_OPCODE_MASK = 0x03,
+HOST1X_OPCODE_IMM = 0x04,
+HOST1X_OPCODE_RESTART = 0x05,
+HOST1X_OPCODE_GATHER= 0x06,
+HOST1X_OPCODE_SETSTRMID = 0x07,
+HOST1X_OPCODE_SETAPPID = 0x08,
+HOST1X_OPCODE_SETPYLD = 0x09,
+HOST1X_OPCODE_INCR_W= 0x0a,
+HOST1X_OPCODE_NONINCR_W = 0x0b,
+HOST1X_OPCODE_GATHER_W = 0x0c,
+HOST1X_OPCODE_RESTART_W = 0x0d,
+HOST1X_OPCODE_EXTEND= 0x0e,
+};
+
+int tegra_drm_fw_validate(struct tegra_drm_client *client, u32 *data, u32
start,
+ u32 words, struct tegra_drm_submit_data *submit)
+{
+ struct tegra_drm_firewall fw = {
+ .submit = submit,
+ .client = client,
+ .data = data,
+ .pos = start,
+ .end = start+words,
+ };
+ bool payl
[PATCH v4 03/21] gpu: host1x: Show number of pending waiters in debugfs
Show the number of pending waiters in the debugfs status file.
This is useful for testing to verify that waiters do not leak
or accumulate incorrectly.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/debug.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
index 3eee4318b158..2d06a7406b3b 100644
--- a/drivers/gpu/host1x/debug.c
+++ b/drivers/gpu/host1x/debug.c
@@ -69,6 +69,7 @@ static int show_channel(struct host1x_channel *ch, void
*data, bool show_fifo)
static void show_syncpts(struct host1x *m, struct output *o)
{
+ struct list_head *pos;
unsigned int i;
host1x_debug_output(o, " syncpts \n");
@@ -76,12 +77,19 @@ static void show_syncpts(struct host1x *m, struct output *o)
for (i = 0; i < host1x_syncpt_nb_pts(m); i++) {
u32 max = host1x_syncpt_read_max(m->syncpt + i);
u32 min = host1x_syncpt_load(m->syncpt + i);
+ unsigned int waiters = 0;
- if (!min && !max)
+ spin_lock(&m->syncpt[i].intr.lock);
+ list_for_each(pos, &m->syncpt[i].intr.wait_head)
+ waiters++;
+ spin_unlock(&m->syncpt[i].intr.lock);
+
+ if (!min && !max && !waiters)
continue;
- host1x_debug_output(o, "id %u (%s) min %d max %d\n",
- i, m->syncpt[i].name, min, max);
+ host1x_debug_output(o,
+ "id %u (%s) min %d max %d (%d waiters)\n",
+ i, m->syncpt[i].name, min, max, waiters);
}
for (i = 0; i < host1x_syncpt_nb_bases(m); i++) {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 11/21] gpu: host1x: Add job release callback
Add a callback field to the job structure, to be called just before
the job is to be freed. This allows the job's submitter to clean
up any of its own state, like decrement runtime PM refcounts.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/job.c | 3 +++
include/linux/host1x.h | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index e4f16fc899b0..acf322beb56c 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -79,6 +79,9 @@ static void job_free(struct kref *ref)
{
struct host1x_job *job = container_of(ref, struct host1x_job, ref);
+ if (job->release)
+ job->release(job);
+
if (job->waiter)
host1x_intr_put_ref(job->syncpt->host, job->syncpt->id,
job->waiter);
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index fb62cc8b77dd..d7070fd65833 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -265,6 +265,10 @@ struct host1x_job {
/* Fast-forward syncpoint increments on job timeout */
bool syncpt_recovery;
+
+ /* Callback called when job is freed */
+ void (*release)(struct host1x_job *job);
+ void *user_data;
};
struct host1x_job *host1x_job_alloc(struct host1x_channel *ch,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 14/21] gpu: host1x: Reserve VBLANK syncpoints at initialization
On T20-T148 chips, the bootloader can set up a boot splash
screen with DC configured to increment syncpoint 26/27
at VBLANK. Because of this we shouldn't allow these syncpoints
to be allocated until DC has been reset and will no longer
increment them in the background.
As such, on these chips, reserve those two syncpoints at
initialization, and only mark them free once the DC
driver has indicated it's safe to do so.
Signed-off-by: Mikko Perttunen
---
v3:
* New patch
---
drivers/gpu/drm/tegra/dc.c | 6 ++
drivers/gpu/host1x/dev.c| 6 ++
drivers/gpu/host1x/dev.h| 6 ++
drivers/gpu/host1x/syncpt.c | 34 +-
include/linux/host1x.h | 3 +++
5 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index efb41c10dad4..0b23e0922c25 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2031,6 +2031,12 @@ static int tegra_dc_init(struct host1x_client *client)
struct drm_plane *cursor = NULL;
int err;
+ /*
+* DC has been reset by now, so VBLANK syncpoint can be released
+* for general use.
+*/
+ host1x_syncpt_release_vblank_reservation(client, 26 + dc->pipe);
+
/*
* XXX do not register DCs with no window groups because we cannot
* assign a primary plane to them, which in turn will cause KMS to
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 641317d23828..8b50fbb22846 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -77,6 +77,7 @@ static const struct host1x_info host1x01_info = {
.has_hypervisor = false,
.num_sid_entries = 0,
.sid_table = NULL,
+ .reserve_vblank_syncpts = true,
};
static const struct host1x_info host1x02_info = {
@@ -91,6 +92,7 @@ static const struct host1x_info host1x02_info = {
.has_hypervisor = false,
.num_sid_entries = 0,
.sid_table = NULL,
+ .reserve_vblank_syncpts = true,
};
static const struct host1x_info host1x04_info = {
@@ -105,6 +107,7 @@ static const struct host1x_info host1x04_info = {
.has_hypervisor = false,
.num_sid_entries = 0,
.sid_table = NULL,
+ .reserve_vblank_syncpts = false,
};
static const struct host1x_info host1x05_info = {
@@ -119,6 +122,7 @@ static const struct host1x_info host1x05_info = {
.has_hypervisor = false,
.num_sid_entries = 0,
.sid_table = NULL,
+ .reserve_vblank_syncpts = false,
};
static const struct host1x_sid_entry tegra186_sid_table[] = {
@@ -142,6 +146,7 @@ static const struct host1x_info host1x06_info = {
.has_hypervisor = true,
.num_sid_entries = ARRAY_SIZE(tegra186_sid_table),
.sid_table = tegra186_sid_table,
+ .reserve_vblank_syncpts = false,
};
static const struct host1x_sid_entry tegra194_sid_table[] = {
@@ -165,6 +170,7 @@ static const struct host1x_info host1x07_info = {
.has_hypervisor = true,
.num_sid_entries = ARRAY_SIZE(tegra194_sid_table),
.sid_table = tegra194_sid_table,
+ .reserve_vblank_syncpts = false,
};
static const struct of_device_id host1x_of_match[] = {
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 7b8b7e20e32b..e360bc4a25f6 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -102,6 +102,12 @@ struct host1x_info {
bool has_hypervisor; /* has hypervisor registers */
unsigned int num_sid_entries;
const struct host1x_sid_entry *sid_table;
+ /*
+* On T20-T148, the boot chain may setup DC to increment syncpoints
+* 26/27 on VBLANK. As such we cannot use these syncpoints until
+* the display driver disables VBLANK increments.
+*/
+ bool reserve_vblank_syncpts;
};
struct host1x {
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 99d31932eb34..d0be7bdbc6c9 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -52,7 +52,7 @@ struct host1x_syncpt *host1x_syncpt_alloc(struct host1x *host,
mutex_lock(&host->syncpt_mutex);
- for (i = 0; i < host->info->nb_pts && sp->name; i++, sp++)
+ for (i = 0; i < host->info->nb_pts && kref_read(&sp->ref); i++, sp++)
;
if (i >= host->info->nb_pts)
@@ -359,6 +359,11 @@ int host1x_syncpt_init(struct host1x *host)
if (!host->nop_sp)
return -ENOMEM;
+ if (host->info->reserve_vblank_syncpts) {
+ kref_init(&host->syncpt[26].ref);
+ kref_init(&host->syncpt[27].ref);
+ }
+
return 0;
}
@@ -545,3 +550,30 @@ u32 host1x_syncpt_base_id(struct host1x_syncpt_base *base)
return base->id;
}
EXPORT_SYMBOL(host1x_syncpt_base_id);
+
+static void do_nothing(struct kref *ref)
+{
+}
+
+/**
+ * host1x_syncpt_release_vblank_reservation() - Make VBLANK syncpoint
+ *
[PATCH v4 19/21] drm/tegra: Implement new UAPI
Implement the non-submission parts of the new UAPI, including
channel management and memory mapping. The UAPI is under the
CONFIG_DRM_TEGRA_STAGING config flag for now.
Signed-off-by: Mikko Perttunen
---
v4:
* New patch, split out from combined UAPI + submit patch.
---
drivers/gpu/drm/tegra/Makefile| 1 +
drivers/gpu/drm/tegra/drm.c | 41 ++--
drivers/gpu/drm/tegra/drm.h | 5 +
drivers/gpu/drm/tegra/uapi.h | 63 ++
drivers/gpu/drm/tegra/uapi/uapi.c | 306 ++
5 files changed, 400 insertions(+), 16 deletions(-)
create mode 100644 drivers/gpu/drm/tegra/uapi.h
create mode 100644 drivers/gpu/drm/tegra/uapi/uapi.c
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index d6cf202414f0..0abdb21b38b9 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -3,6 +3,7 @@ ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
tegra-drm-y := \
drm.o \
+ uapi/uapi.o \
gem.o \
fb.o \
dp.o \
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 7124b0b0154b..79416b6b6715 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -20,6 +20,7 @@
#include
#include
+#include "uapi.h"
#include "drm.h"
#include "gem.h"
@@ -33,11 +34,6 @@
#define CARVEOUT_SZ SZ_64M
#define CDMA_GATHER_FETCHES_MAX_NB 16383
-struct tegra_drm_file {
- struct idr contexts;
- struct mutex lock;
-};
-
static int tegra_atomic_check(struct drm_device *drm,
struct drm_atomic_state *state)
{
@@ -90,7 +86,8 @@ static int tegra_drm_open(struct drm_device *drm, struct
drm_file *filp)
if (!fpriv)
return -ENOMEM;
- idr_init(&fpriv->contexts);
+ idr_init(&fpriv->legacy_contexts);
+ xa_init_flags(&fpriv->contexts, XA_FLAGS_ALLOC1);
mutex_init(&fpriv->lock);
filp->driver_priv = fpriv;
@@ -432,7 +429,7 @@ static int tegra_client_open(struct tegra_drm_file *fpriv,
if (err < 0)
return err;
- err = idr_alloc(&fpriv->contexts, context, 1, 0, GFP_KERNEL);
+ err = idr_alloc(&fpriv->legacy_contexts, context, 1, 0, GFP_KERNEL);
if (err < 0) {
client->ops->close_channel(context);
return err;
@@ -487,13 +484,13 @@ static int tegra_close_channel(struct drm_device *drm,
void *data,
mutex_lock(&fpriv->lock);
- context = idr_find(&fpriv->contexts, args->context);
+ context = idr_find(&fpriv->legacy_contexts, args->context);
if (!context) {
err = -EINVAL;
goto unlock;
}
- idr_remove(&fpriv->contexts, context->id);
+ idr_remove(&fpriv->legacy_contexts, context->id);
tegra_drm_context_free(context);
unlock:
@@ -512,7 +509,7 @@ static int tegra_get_syncpt(struct drm_device *drm, void
*data,
mutex_lock(&fpriv->lock);
- context = idr_find(&fpriv->contexts, args->context);
+ context = idr_find(&fpriv->legacy_contexts, args->context);
if (!context) {
err = -ENODEV;
goto unlock;
@@ -541,7 +538,7 @@ static int tegra_submit(struct drm_device *drm, void *data,
mutex_lock(&fpriv->lock);
- context = idr_find(&fpriv->contexts, args->context);
+ context = idr_find(&fpriv->legacy_contexts, args->context);
if (!context) {
err = -ENODEV;
goto unlock;
@@ -566,7 +563,7 @@ static int tegra_get_syncpt_base(struct drm_device *drm,
void *data,
mutex_lock(&fpriv->lock);
- context = idr_find(&fpriv->contexts, args->context);
+ context = idr_find(&fpriv->legacy_contexts, args->context);
if (!context) {
err = -ENODEV;
goto unlock;
@@ -735,10 +732,21 @@ static int tegra_gem_get_flags(struct drm_device *drm,
void *data,
static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
#ifdef CONFIG_DRM_TEGRA_STAGING
- DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_gem_create,
+ DRM_IOCTL_DEF_DRV(TEGRA_CHANNEL_OPEN, tegra_drm_ioctl_channel_open,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(TEGRA_CHANNEL_CLOSE, tegra_drm_ioctl_channel_close,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(TEGRA_CHANNEL_MAP, tegra_drm_ioctl_channel_map,
DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP, tegra_gem_mmap,
+ DRM_IOCTL_DEF_DRV(TEGRA_CHANNEL_UNMAP, tegra_drm_ioctl_channel_unmap,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_drm_ioctl_gem_create,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP, tegra_drm_ioctl_gem_mmap,
+ DRM_RENDER_ALLOW),
+
+ DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE_LEGACY, tegra_gem_create,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_
[PATCH v4 02/21] gpu: host1x: Allow syncpoints without associated client
Syncpoints don't need to be associated with any client,
so remove the property, and expose host1x_syncpt_alloc.
This will allow allocating syncpoints without prior knowledge
of the engine that it will be used with.
Signed-off-by: Mikko Perttunen
---
v3:
* Clean up host1x_syncpt_alloc signature to allow specifying
a name for the syncpoint.
* Export the function.
---
drivers/gpu/host1x/syncpt.c | 22 ++
drivers/gpu/host1x/syncpt.h | 1 -
include/linux/host1x.h | 3 +++
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index fce7892d5137..5982fdf64e1c 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -42,13 +42,13 @@ static void host1x_syncpt_base_free(struct
host1x_syncpt_base *base)
base->requested = false;
}
-static struct host1x_syncpt *host1x_syncpt_alloc(struct host1x *host,
-struct host1x_client *client,
-unsigned long flags)
+struct host1x_syncpt *host1x_syncpt_alloc(struct host1x *host,
+ unsigned long flags,
+ const char *name)
{
struct host1x_syncpt *sp = host->syncpt;
+ char *full_name;
unsigned int i;
- char *name;
mutex_lock(&host->syncpt_mutex);
@@ -64,13 +64,11 @@ static struct host1x_syncpt *host1x_syncpt_alloc(struct
host1x *host,
goto unlock;
}
- name = kasprintf(GFP_KERNEL, "%02u-%s", sp->id,
-client ? dev_name(client->dev) : NULL);
- if (!name)
+ full_name = kasprintf(GFP_KERNEL, "%u-%s", sp->id, name);
+ if (!full_name)
goto free_base;
- sp->client = client;
- sp->name = name;
+ sp->name = full_name;
if (flags & HOST1X_SYNCPT_CLIENT_MANAGED)
sp->client_managed = true;
@@ -87,6 +85,7 @@ static struct host1x_syncpt *host1x_syncpt_alloc(struct
host1x *host,
mutex_unlock(&host->syncpt_mutex);
return NULL;
}
+EXPORT_SYMBOL(host1x_syncpt_alloc);
/**
* host1x_syncpt_id() - retrieve syncpoint ID
@@ -401,7 +400,7 @@ int host1x_syncpt_init(struct host1x *host)
host1x_hw_syncpt_enable_protection(host);
/* Allocate sync point to use for clearing waits for expired fences */
- host->nop_sp = host1x_syncpt_alloc(host, NULL, 0);
+ host->nop_sp = host1x_syncpt_alloc(host, 0, "reserved-nop");
if (!host->nop_sp)
return -ENOMEM;
@@ -423,7 +422,7 @@ struct host1x_syncpt *host1x_syncpt_request(struct
host1x_client *client,
{
struct host1x *host = dev_get_drvdata(client->host->parent);
- return host1x_syncpt_alloc(host, client, flags);
+ return host1x_syncpt_alloc(host, flags, dev_name(client->dev));
}
EXPORT_SYMBOL(host1x_syncpt_request);
@@ -447,7 +446,6 @@ void host1x_syncpt_free(struct host1x_syncpt *sp)
host1x_syncpt_base_free(sp->base);
kfree(sp->name);
sp->base = NULL;
- sp->client = NULL;
sp->name = NULL;
sp->client_managed = false;
diff --git a/drivers/gpu/host1x/syncpt.h b/drivers/gpu/host1x/syncpt.h
index 8e1d04dacaa0..3aa6b25b1b9c 100644
--- a/drivers/gpu/host1x/syncpt.h
+++ b/drivers/gpu/host1x/syncpt.h
@@ -33,7 +33,6 @@ struct host1x_syncpt {
const char *name;
bool client_managed;
struct host1x *host;
- struct host1x_client *client;
struct host1x_syncpt_base *base;
/* interrupt data */
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index f711fc0154f4..099eff8a06d2 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -154,6 +154,9 @@ int host1x_syncpt_wait(struct host1x_syncpt *sp, u32
thresh, long timeout,
struct host1x_syncpt *host1x_syncpt_request(struct host1x_client *client,
unsigned long flags);
void host1x_syncpt_free(struct host1x_syncpt *sp);
+struct host1x_syncpt *host1x_syncpt_alloc(struct host1x *host,
+ unsigned long flags,
+ const char *name);
struct host1x_syncpt_base *host1x_syncpt_get_base(struct host1x_syncpt *sp);
u32 host1x_syncpt_base_id(struct host1x_syncpt_base *base);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 20/21] drm/tegra: Implement job submission part of new UAPI
Implement the job submission IOCTL with a minimum feature set.
Signed-off-by: Mikko Perttunen
---
v4:
* Remove all features that are not strictly necessary.
* Split into two patches.
v3:
* Remove WRITE_RELOC. Relocations are now patched implicitly
when patching is needed.
* Directly call PM runtime APIs on devices instead of using
power_on/power_off callbacks.
* Remove incorrect mutex unlock in tegra_drm_ioctl_channel_open
* Use XA_FLAGS_ALLOC1 instead of XA_FLAGS_ALLOC
* Accommodate for removal of timeout field and inlining of
syncpt_incrs array.
* Copy entire user arrays at a time instead of going through
elements one-by-one.
* Implement waiting of DMA reservations.
* Split out gather_bo implementation into a separate file.
* Fix length parameter passed to sg_init_one in gather_bo
* Cosmetic cleanup.
---
drivers/gpu/drm/tegra/Makefile | 2 +
drivers/gpu/drm/tegra/drm.c| 2 +
drivers/gpu/drm/tegra/uapi/gather_bo.c | 86 +
drivers/gpu/drm/tegra/uapi/gather_bo.h | 22 ++
drivers/gpu/drm/tegra/uapi/submit.c| 423 +
drivers/gpu/drm/tegra/uapi/submit.h| 17 +
6 files changed, 552 insertions(+)
create mode 100644 drivers/gpu/drm/tegra/uapi/gather_bo.c
create mode 100644 drivers/gpu/drm/tegra/uapi/gather_bo.h
create mode 100644 drivers/gpu/drm/tegra/uapi/submit.c
create mode 100644 drivers/gpu/drm/tegra/uapi/submit.h
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 0abdb21b38b9..059322e88943 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -4,6 +4,8 @@ ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
tegra-drm-y := \
drm.o \
uapi/uapi.o \
+ uapi/submit.o \
+ uapi/gather_bo.o \
gem.o \
fb.o \
dp.o \
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 79416b6b6715..3077bd594560 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -740,6 +740,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_CHANNEL_UNMAP, tegra_drm_ioctl_channel_unmap,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(TEGRA_CHANNEL_SUBMIT, tegra_drm_ioctl_channel_submit,
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_drm_ioctl_gem_create,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP, tegra_drm_ioctl_gem_mmap,
diff --git a/drivers/gpu/drm/tegra/uapi/gather_bo.c
b/drivers/gpu/drm/tegra/uapi/gather_bo.c
new file mode 100644
index ..b487a0d44648
--- /dev/null
+++ b/drivers/gpu/drm/tegra/uapi/gather_bo.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2020 NVIDIA Corporation */
+
+#include
+#include
+
+#include "gather_bo.h"
+
+static struct host1x_bo *gather_bo_get(struct host1x_bo *host_bo)
+{
+ struct gather_bo *bo = container_of(host_bo, struct gather_bo, base);
+
+ kref_get(&bo->ref);
+
+ return host_bo;
+}
+
+static void gather_bo_release(struct kref *ref)
+{
+ struct gather_bo *bo = container_of(ref, struct gather_bo, ref);
+
+ kfree(bo->gather_data);
+ kfree(bo);
+}
+
+void gather_bo_put(struct host1x_bo *host_bo)
+{
+ struct gather_bo *bo = container_of(host_bo, struct gather_bo, base);
+
+ kref_put(&bo->ref, gather_bo_release);
+}
+
+static struct sg_table *
+gather_bo_pin(struct device *dev, struct host1x_bo *host_bo, dma_addr_t *phys)
+{
+ struct gather_bo *bo = container_of(host_bo, struct gather_bo, base);
+ struct sg_table *sgt;
+ int err;
+
+ if (phys) {
+ *phys = virt_to_phys(bo->gather_data);
+ return NULL;
+ }
+
+ sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt)
+ return ERR_PTR(-ENOMEM);
+
+ err = sg_alloc_table(sgt, 1, GFP_KERNEL);
+ if (err) {
+ kfree(sgt);
+ return ERR_PTR(err);
+ }
+
+ sg_init_one(sgt->sgl, bo->gather_data, bo->gather_data_words*4);
+
+ return sgt;
+}
+
+static void gather_bo_unpin(struct device *dev, struct sg_table *sgt)
+{
+ if (sgt) {
+ sg_free_table(sgt);
+ kfree(sgt);
+ }
+}
+
+static void *gather_bo_mmap(struct host1x_bo *host_bo)
+{
+ struct gather_bo *bo = container_of(host_bo, struct gather_bo, base);
+
+ return bo->gather_data;
+}
+
+static void gather_bo_munmap(struct host1x_bo *host_bo, void *addr)
+{
+}
+
+const struct host1x_bo_ops gather_bo_ops = {
+ .get = gather_bo_get,
+ .put = gather_bo_put,
+ .pin = gather_bo_pin,
+ .unpin = gather_bo_unpin,
+ .mmap = gather_bo_mmap,
+ .munmap = gather_bo_munmap,
+};
diff --git a/drivers/gpu/drm/tegra/uapi/gather_bo.h
b/drivers/gpu/drm/tegra/uapi/gather_bo.h
new file mode 100644
index ..
[PATCH v4 15/21] drm/tegra: Add new UAPI to header
Update the tegra_drm.h UAPI header, adding the new proposed UAPI.
The old staging UAPI is left in for now, with minor modification
to avoid name collisions.
Signed-off-by: Mikko Perttunen
---
v4:
* Remove features that are not strictly necessary
* Remove padding/reserved fields in IOCTL structs where
DRM's zero extension feature allows future expansion
v3:
* Remove timeout field
* Inline the syncpt_incrs array to the submit structure
* Remove WRITE_RELOC (it is now implicit)
---
include/uapi/drm/tegra_drm.h | 338 ---
1 file changed, 311 insertions(+), 27 deletions(-)
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index c4df3c3668b3..014bc393c298 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -1,24 +1,5 @@
-/*
- * Copyright (c) 2012-2013, NVIDIA CORPORATION. All rights reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- */
+/* SPDX-License-Identifier: MIT */
+/* Copyright (c) 2012-2020 NVIDIA Corporation */
#ifndef _UAPI_TEGRA_DRM_H_
#define _UAPI_TEGRA_DRM_H_
@@ -29,6 +10,8 @@
extern "C" {
#endif
+/* TegraDRM legacy UAPI. Only enabled with STAGING */
+
#define DRM_TEGRA_GEM_CREATE_TILED (1 << 0)
#define DRM_TEGRA_GEM_CREATE_BOTTOM_UP (1 << 1)
@@ -644,13 +627,13 @@ struct drm_tegra_gem_get_flags {
__u32 flags;
};
-#define DRM_TEGRA_GEM_CREATE 0x00
-#define DRM_TEGRA_GEM_MMAP 0x01
+#define DRM_TEGRA_GEM_CREATE_LEGACY0x00
+#define DRM_TEGRA_GEM_MMAP_LEGACY 0x01
#define DRM_TEGRA_SYNCPT_READ 0x02
#define DRM_TEGRA_SYNCPT_INCR 0x03
#define DRM_TEGRA_SYNCPT_WAIT 0x04
-#define DRM_TEGRA_OPEN_CHANNEL 0x05
-#define DRM_TEGRA_CLOSE_CHANNEL0x06
+#define DRM_TEGRA_OPEN_CHANNEL 0x05
+#define DRM_TEGRA_CLOSE_CHANNEL0x06
#define DRM_TEGRA_GET_SYNCPT 0x07
#define DRM_TEGRA_SUBMIT 0x08
#define DRM_TEGRA_GET_SYNCPT_BASE 0x09
@@ -659,8 +642,8 @@ struct drm_tegra_gem_get_flags {
#define DRM_TEGRA_GEM_SET_FLAGS0x0c
#define DRM_TEGRA_GEM_GET_FLAGS0x0d
-#define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
-#define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
+#define DRM_IOCTL_TEGRA_GEM_CREATE_LEGACY DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GEM_CREATE_LEGACY, struct drm_tegra_gem_create)
+#define DRM_IOCTL_TEGRA_GEM_MMAP_LEGACY DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GEM_MMAP_LEGACY, struct drm_tegra_gem_mmap)
#define DRM_IOCTL_TEGRA_SYNCPT_READ DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_SYNCPT_READ, struct drm_tegra_syncpt_read)
#define DRM_IOCTL_TEGRA_SYNCPT_INCR DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_SYNCPT_INCR, struct drm_tegra_syncpt_incr)
#define DRM_IOCTL_TEGRA_SYNCPT_WAIT DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_SYNCPT_WAIT, struct drm_tegra_syncpt_wait)
@@ -674,6 +657,307 @@ struct drm_tegra_gem_get_flags {
#define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags)
#define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags)
+/* New TegraDRM UAPI */
+
+struct drm_tegra_channel_open {
+ /**
+* @host1x_class: [in]
+*
+* Host1x class of the engine that will be programmed using this
+* channel.
+*/
+ __u32 host1x_class;
+
+ /**
+* @flags: [in]
+*
+* Flags.
+*/
+ __u32 flags;
+
+ /**
+* @channel_ctx: [out]
+*
+* Opaque identifier corresponding to the opened channel.
+*/
+ __u32 channel_ctx;
+
+ /**
+* @hardware_version: [out]
+*
+* Version of the engine hardware. This can be used by
Re: [PATCH v3] drm: document drm_mode_get_connector
On Fri, 20 Nov 2020 08:57:33 +
Simon Ser wrote:
> Document how to perform a GETCONNECTOR ioctl. Document the various
> struct fields. Also document how to perform a forced probe, and when
> should user-space do it.
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Pekka Paalanen
> ---
> include/uapi/drm/drm_mode.h | 78 ++---
> 1 file changed, 73 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index f29c1d37be67..3979389fcc4f 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -368,27 +368,95 @@ enum drm_mode_subconnector {
> #define DRM_MODE_CONNECTOR_WRITEBACK 18
> #define DRM_MODE_CONNECTOR_SPI 19
>
> +/**
> + * struct drm_mode_get_connector - Get connector metadata.
> + *
> + * User-space can perform a GETCONNECTOR ioctl to retrieve information about
> a
> + * connector. User-space is expected to retrieve encoders, modes and
> properties
> + * by performing this ioctl at least twice: the first time to retrieve the
> + * number of elements, the second time to retrieve the elements themselves.
> + *
> + * To retrieve the number of elements, set @count_props and @count_encoders
> to
> + * zero, set @count_modes to 1, and set @modes_ptr to a temporary struct
> + * drm_mode_modeinfo element.
How are the counts actually returned?
> + *
> + * To retrieve the elements, allocate arrays for @encoders_ptr, @modes_ptr,
> + * @props_ptr and @prop_values_ptr, then set @count_modes, @count_props and
> + * @count_encoders to their capacity.
> + *
> + * Performing the ioctl only twice may be racy: the number of elements may
> have
> + * changed with a hotplug event in-between the two ioctls. User-space is
> + * expected to retry the last ioctl until the number of elements stabilizes.
> + * The kernel won't fill any array which doesn't have the expected length.
How does userspace realize the kernel didn't fill in the arrays?
> + *
> + * **Force-probing a connector**
> + *
> + * If the @count_modes field is set to zero, the kernel will perform a forced
> + * probe on the connector to refresh the connector status, modes and EDID.
> + * A forced-probe can be slow and the ioctl will block. A force-probe can
> cause
> + * flickering and temporary freezes, so it should not be performed
> + * automatically.
> + *
> + * User-space shouldn't need to force-probe connectors in general: the kernel
> + * will automatically take care of probing connectors that don't support
> + * hot-plug detection when appropriate. However, user-space may force-probe
> + * connectors on user request (e.g. clicking a "Scan connectors" button, or
> + * opening a UI to manage screens).
This is well written.
> + */
> struct drm_mode_get_connector {
> -
> + /** @encoders_ptr: Pointer to ``__u32`` array of object IDs. */
> __u64 encoders_ptr;
> + /** @modes_ptr: Pointer to struct drm_mode_modeinfo array. */
> __u64 modes_ptr;
> + /** @props_ptr: Pointer to ``__u32`` array of property IDs. */
> __u64 props_ptr;
> + /** @prop_values_ptr: Pointer to ``__u64`` array of property values. */
> __u64 prop_values_ptr;
>
> + /** @count_modes: Number of modes. */
> __u32 count_modes;
> + /** @count_props: Number of properties. */
> __u32 count_props;
> + /** @count_encoders: Number of encoders. */
> __u32 count_encoders;
>
> - __u32 encoder_id; /**< Current Encoder */
> - __u32 connector_id; /**< Id */
> + /** @encoder_id: Object ID of the current encoder. */
> + __u32 encoder_id;
This is an out value, not an in value, right?
It's not immediately obvious whether any members here are in, out or
in/out values.
> + /** @connector_id: Object ID of the connector. */
> + __u32 connector_id;
> + /**
> + * @connector_type: Type of the connector.
> + *
> + * See DRM_MODE_CONNECTOR_* defines.
> + */
> __u32 connector_type;
> + /**
> + * @connector_type_id: Type-specific connector number.
> + *
> + * This is not an object ID. This is a per-type connector number. Each
> + * (type, type_id) combination is unique across all connectors of a DRM
> + * device.
> + */
> __u32 connector_type_id;
Naming facepalm, oh well...
>
> + /**
> + * @connection: Status of the connector.
> + *
> + * See enum drm_connector_status.
> + */
> __u32 connection;
> - __u32 mm_width; /**< width in millimeters */
> - __u32 mm_height; /**< height in millimeters */
> + /** @mm_width: Width of the connected sink in millimeters. */
> + __u32 mm_width;
> + /** @mm_height: Height of the connected sink in millimeters. */
> + __u32 mm_height;
These are actually more complicated than this, aren't they?
They could be zero for unknown, or both smaller than 20 (???) to
signify only aspect ratio? I've no idea, I jus
Re: [PATCH 1/3] drm/panel: s6e63m0: Fix and extend MCS table
Hi Linus, The whole series looks good to me code wise so Reviewed-by: Guido Günther but i have no means to test the changes. Cheers, -- Guido On Tue, Nov 17, 2020 at 06:56:19PM +0100, Linus Walleij wrote: > Fix up the format of the manufacturer command set table > to be TAB-indented and lowercase. Add the MCS_TEMP_SWIRE > command that we will make use of. > > Cc: Stephan Gerhold > Cc: Paweł Chmiel > Signed-off-by: Linus Walleij > --- > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > index 210e70da3a15..8fce399fb97d 100644 > --- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > @@ -23,20 +23,21 @@ > #include "panel-samsung-s6e63m0.h" > > /* Manufacturer Command Set */ > -#define MCS_ELVSS_ON0xb1 > -#define MCS_MIECTL10xc0 > -#define MCS_BCMODE 0xc1 > +#define MCS_ELVSS_ON 0xb1 > +#define MCS_TEMP_SWIRE 0xb2 > +#define MCS_MIECTL1 0xc0 > +#define MCS_BCMODE 0xc1 > #define MCS_ERROR_CHECK 0xd5 > #define MCS_READ_ID1 0xda > #define MCS_READ_ID2 0xdb > #define MCS_READ_ID3 0xdc > #define MCS_LEVEL_2_KEY 0xf0 > #define MCS_MTP_KEY 0xf1 > -#define MCS_DISCTL 0xf2 > -#define MCS_SRCCTL 0xf6 > -#define MCS_IFCTL 0xf7 > -#define MCS_PANELCTL 0xF8 > -#define MCS_PGAMMACTL 0xfa > +#define MCS_DISCTL 0xf2 > +#define MCS_SRCCTL 0xf6 > +#define MCS_IFCTL0xf7 > +#define MCS_PANELCTL 0xf8 > +#define MCS_PGAMMACTL0xfa > > #define S6E63M0_LCD_ID_VALUE_M2 0xA4 > #define S6E63M0_LCD_ID_VALUE_SM2 0xB4 > -- > 2.26.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] drm/panel: mantix and st7703 fixes and additions
Hi Linus, On Thu, Nov 19, 2020 at 09:35:17AM +0100, Linus Walleij wrote: > On Wed, Nov 18, 2020 at 9:29 AM Guido Günther wrote: > > > This adds new panel type to the mantix driver as found on the Librem 5 and > > fixes a glitch in the init sequence (affecting both panels). The fix is at > > the > > start of the series to make backporting simpler. > > It also adds a patch to make st7703 use dev_err_probe(). > > > > changes from v1 > > - as per review comments by Linus Walleij > > - fix alphabetical ordering in > > Documentation/devicetree/bindings/vendor-prefixes.yaml > > > > https://lore.kernel.org/dri-devel/CACRpkdao_TMcpRsdK=7k5fnkjse0bqwk58iwu0xsxddndcf...@mail.gmail.com/ > > - add reviewed by to all except 5/6, thanks > > The whole v2 looks fine to me, I'd give the devicetree > maintainers some slack to review the DT patches then I can > apply the whole series unless you have commit access yourself, > just tell me. I have commit access, so i can push in a couple of days. Thanks! > > For all v2 patches: > Reviewed-by: Linus Walleij > > If you have time, please review my s6e63m0 series. > https://lore.kernel.org/dri-devel/20201117175621.870085-1-linus.wall...@linaro.org/ > https://lore.kernel.org/dri-devel/20201117175621.870085-2-linus.wall...@linaro.org/ > https://lore.kernel.org/dri-devel/20201117175621.870085-3-linus.wall...@linaro.org/ Done. The panel stuff is always scary with all those magic values. -- Guido > > Yours, > Linus Walleij > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe
On 20/11/2020 11:51, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 11:39 AM Hans Verkuil wrote:
>>
>> On 20/11/2020 10:18, Daniel Vetter wrote:
>>> On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
On 20/11/2020 09:06, Hans Verkuil wrote:
> On 19/11/2020 15:41, Daniel Vetter wrote:
>> The media model assumes that buffers are all preallocated, so that
>> when a media pipeline is running we never miss a deadline because the
>> buffers aren't allocated or available.
>>
>> This means we cannot fix the v4l follow_pfn usage through
>> mmu_notifier, without breaking how this all works. The only real fix
>> is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
>> tell everyone to cut over to dma-buf memory sharing for zerocopy.
>>
>> userptr for normal memory will keep working as-is, this only affects
>> the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
>> videobuf2-dma-sg: Support io userptr operations on io memory").
>>
>> Acked-by: Tomasz Figa
>
> Acked-by: Hans Verkuil
Actually, cancel this Acked-by.
So let me see if I understand this right: VM_IO | VM_PFNMAP mappings can
move around. There is a mmu_notifier that can be used to be notified when
that happens, but that can't be used with media buffers since those buffers
must always be available and in the same place.
So follow_pfn is replaced by unsafe_follow_pfn to signal that what is
attempted
is unsafe and unreliable.
If CONFIG_STRICT_FOLLOW_PFN is set, then unsafe_follow_pfn will fail, if it
is unset, then it writes a warning to the kernel log but just continues
while
still unsafe.
I am very much inclined to just drop VM_IO | VM_PFNMAP support in the media
subsystem. For vb2 there is a working alternative in the form of dmabuf,
and
frankly for vb1 I don't care. If someone really needs this for a vb1
driver,
then they can do the work to convert that driver to vb2.
I've added Mauro to the CC list and I'll ping a few more people to see what
they think, but in my opinion support for USERPTR + VM_IO | VM_PFNMAP
should just be killed off.
If others would like to keep it, then frame_vector.c needs a comment before
the 'while' explaining why the unsafe_follow_pfn is there and that using
dmabuf is the proper alternative to use. That will make it easier for
developers to figure out why they see a kernel warning and what to do to
fix it, rather than having to dig through the git history for the reason.
>>>
>>> I'm happy to add a comment, but otherwise if you all want to ditch
>>> this, can we do this as a follow up on top? There's quite a bit of
>>> code that can be deleted and I'd like to not hold up this patch set
>>> here on that - it's already a fairly sprawling pain touching about 7
>>> different subsystems (ok only 6-ish now since the s390 patch landed).
>>> For the comment, is the explanation next to unsafe_follow_pfn not good
>>> enough?
>>
>> No, because that doesn't mention that you should use dma-buf as a
>> replacement.
>> That's really the critical piece of information I'd like to see. That doesn't
>> belong in unsafe_follow_pfn, it needs to be in frame_vector.c since it's
>> vb2 specific.
>
> Ah makes sense, I'll add that.
>
>>>
>>> So ... can I get you to un-cancel your ack?
>>
>> Hmm, I really would like to see support for this to be dropped completely.
>>
>> How about this: just replace follow_pfn() by -EINVAL instead of
>> unsafe_follow_pfn().
>>
>> Add a TODO comment that this code now can be cleaned up a lot. Such a clean
>> up patch
>> can be added on top later, and actually that is something that I can do once
>> this
>> series has landed.
>>
>> Regardless, frame_vector.c should mention dma-buf as a replacement in a
>> comment
>> since I don't want users who hit this issue to have to dig through git logs
>> to find that dma-buf is the right approach.
>>
>> BTW, nitpick: the subject line of this patch says 'videbuf' instead of
>> 'videobuf'.
>
> Will fix to, and next round will have the additional -EINVAL on top.
> Iirc Mauro was pretty clear that we can't just delete this, so I kinda
> don't want to get stuck in this discussion with my patches :-)
Ah, I found that discussion for the v2 of this series.
Yes, add that on top and we can discuss whether to Ack that -EINVAL patch or
not.
I don't see why we would want to continue supporting a broken model that is
also a security risk, as I understand it.
Tomasz, can you look at the discussion for this old RFC patch of mine:
https://patchwork.linuxtv.org/project/linux-media/patch/20200221084531.576156-9-hverkuil-ci...@xs4all.nl/
Specifically, if we just drop support for follow_pfn(), would that cause
problems for Chromium since that is apparently still using USERPTR for encoders?
Regards,
Hans
> -Daniel
>
Re: [PATCH 2/2] drm/meson: dw-hdmi: Enable the iahb clock early enough
On 20/11/2020 12:10, Marc Zyngier wrote:
> On 2020-11-20 10:54, Guillaume Tucker wrote:
>> On 20/11/2020 09:42, Marc Zyngier wrote:
>>> Instead of moving meson_dw_hdmi_init() around which breaks existing
>>> platform, let's enable the clock meson_dw_hdmi_init() depends on.
>>> This means we don't have to worry about this clock being enabled or
>>> not, depending on the boot-loader features.
>>>
>>> Fixes: b33340e33acd ("drm/meson: dw-hdmi: Ensure that clocks are enabled
>>> before touching the TOP registers")
>>> Reported-by: Guillaume Tucker
>>
>> Although I am triaging kernelci bisections, it was initially
>> found thanks to our friendly bot. So if you're OK with this, it
>> would most definitely appreciate a mention:
>>
>> Reported-by: "kernelci.org bot"
>
> Sure. Neil can add this when (and if) he applies these patches.
Yep applying to drm-misc-next and switching to `Reported-by: "kernelci.org bot"
`
Thanks
Neil
>
> Thanks,
>
> M.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe
On Fri, Nov 20, 2020 at 9:08 PM Hans Verkuil wrote:
>
> On 20/11/2020 11:51, Daniel Vetter wrote:
> > On Fri, Nov 20, 2020 at 11:39 AM Hans Verkuil wrote:
> >>
> >> On 20/11/2020 10:18, Daniel Vetter wrote:
> >>> On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil wrote:
>
> On 20/11/2020 09:06, Hans Verkuil wrote:
> > On 19/11/2020 15:41, Daniel Vetter wrote:
> >> The media model assumes that buffers are all preallocated, so that
> >> when a media pipeline is running we never miss a deadline because the
> >> buffers aren't allocated or available.
> >>
> >> This means we cannot fix the v4l follow_pfn usage through
> >> mmu_notifier, without breaking how this all works. The only real fix
> >> is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
> >> tell everyone to cut over to dma-buf memory sharing for zerocopy.
> >>
> >> userptr for normal memory will keep working as-is, this only affects
> >> the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
> >> videobuf2-dma-sg: Support io userptr operations on io memory").
> >>
> >> Acked-by: Tomasz Figa
> >
> > Acked-by: Hans Verkuil
>
> Actually, cancel this Acked-by.
>
> So let me see if I understand this right: VM_IO | VM_PFNMAP mappings can
> move around. There is a mmu_notifier that can be used to be notified when
> that happens, but that can't be used with media buffers since those
> buffers
> must always be available and in the same place.
>
> So follow_pfn is replaced by unsafe_follow_pfn to signal that what is
> attempted
> is unsafe and unreliable.
>
> If CONFIG_STRICT_FOLLOW_PFN is set, then unsafe_follow_pfn will fail, if
> it
> is unset, then it writes a warning to the kernel log but just continues
> while
> still unsafe.
>
> I am very much inclined to just drop VM_IO | VM_PFNMAP support in the
> media
> subsystem. For vb2 there is a working alternative in the form of dmabuf,
> and
> frankly for vb1 I don't care. If someone really needs this for a vb1
> driver,
> then they can do the work to convert that driver to vb2.
>
> I've added Mauro to the CC list and I'll ping a few more people to see
> what
> they think, but in my opinion support for USERPTR + VM_IO | VM_PFNMAP
> should just be killed off.
>
> If others would like to keep it, then frame_vector.c needs a comment
> before
> the 'while' explaining why the unsafe_follow_pfn is there and that using
> dmabuf is the proper alternative to use. That will make it easier for
> developers to figure out why they see a kernel warning and what to do to
> fix it, rather than having to dig through the git history for the reason.
> >>>
> >>> I'm happy to add a comment, but otherwise if you all want to ditch
> >>> this, can we do this as a follow up on top? There's quite a bit of
> >>> code that can be deleted and I'd like to not hold up this patch set
> >>> here on that - it's already a fairly sprawling pain touching about 7
> >>> different subsystems (ok only 6-ish now since the s390 patch landed).
> >>> For the comment, is the explanation next to unsafe_follow_pfn not good
> >>> enough?
> >>
> >> No, because that doesn't mention that you should use dma-buf as a
> >> replacement.
> >> That's really the critical piece of information I'd like to see. That
> >> doesn't
> >> belong in unsafe_follow_pfn, it needs to be in frame_vector.c since it's
> >> vb2 specific.
> >
> > Ah makes sense, I'll add that.
> >
> >>>
> >>> So ... can I get you to un-cancel your ack?
> >>
> >> Hmm, I really would like to see support for this to be dropped completely.
> >>
> >> How about this: just replace follow_pfn() by -EINVAL instead of
> >> unsafe_follow_pfn().
> >>
> >> Add a TODO comment that this code now can be cleaned up a lot. Such a
> >> clean up patch
> >> can be added on top later, and actually that is something that I can do
> >> once this
> >> series has landed.
> >>
> >> Regardless, frame_vector.c should mention dma-buf as a replacement in a
> >> comment
> >> since I don't want users who hit this issue to have to dig through git logs
> >> to find that dma-buf is the right approach.
> >>
> >> BTW, nitpick: the subject line of this patch says 'videbuf' instead of
> >> 'videobuf'.
> >
> > Will fix to, and next round will have the additional -EINVAL on top.
> > Iirc Mauro was pretty clear that we can't just delete this, so I kinda
> > don't want to get stuck in this discussion with my patches :-)
>
> Ah, I found that discussion for the v2 of this series.
>
> Yes, add that on top and we can discuss whether to Ack that -EINVAL patch or
> not.
>
> I don't see why we would want to continue supporting a broken model that is
> also a security risk, as I understand it.
>
> Tomasz, can you look at the discussion for this old RFC pa
Re: [PATCH 1/2] drm/meson: dw-hdmi: Disable clocks on driver teardown
On 20/11/2020 10:42, Marc Zyngier wrote:
> The HDMI driver request clocks early, but never disable them, leaving
> the clocks on even when the driver is removed.
>
> Fix it by slightly refactoring the clock code, and register a devm
> action that will eventually disable/unprepare the enabled clocks.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 43 ++-
> 1 file changed, 29 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 7f8eea494147..29623b309cb1 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -145,8 +145,6 @@ struct meson_dw_hdmi {
> struct reset_control *hdmitx_apb;
> struct reset_control *hdmitx_ctrl;
> struct reset_control *hdmitx_phy;
> - struct clk *hdmi_pclk;
> - struct clk *venci_clk;
> struct regulator *hdmi_supply;
> u32 irq_stat;
> struct dw_hdmi *hdmi;
> @@ -946,6 +944,29 @@ static void meson_disable_regulator(void *data)
> regulator_disable(data);
> }
>
> +static void meson_disable_clk(void *data)
> +{
> + clk_disable_unprepare(data);
> +}
> +
> +static int meson_enable_clk(struct device *dev, char *name)
> +{
> + struct clk *clk;
> + int ret;
> +
> + clk = devm_clk_get(dev, name);
> + if (IS_ERR(clk)) {
> + dev_err(dev, "Unable to get %s pclk\n", name);
> + return PTR_ERR(clk);
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (!ret)
> + ret = devm_add_action_or_reset(dev, meson_disable_clk, clk);
> +
> + return ret;
> +}
> +
> static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
> void *data)
> {
> @@ -1026,19 +1047,13 @@ static int meson_dw_hdmi_bind(struct device *dev,
> struct device *master,
> if (IS_ERR(meson_dw_hdmi->hdmitx))
> return PTR_ERR(meson_dw_hdmi->hdmitx);
>
> - meson_dw_hdmi->hdmi_pclk = devm_clk_get(dev, "isfr");
> - if (IS_ERR(meson_dw_hdmi->hdmi_pclk)) {
> - dev_err(dev, "Unable to get HDMI pclk\n");
> - return PTR_ERR(meson_dw_hdmi->hdmi_pclk);
> - }
> - clk_prepare_enable(meson_dw_hdmi->hdmi_pclk);
> + ret = meson_enable_clk(dev, "isfr");
> + if (ret)
> + return ret;
>
> - meson_dw_hdmi->venci_clk = devm_clk_get(dev, "venci");
> - if (IS_ERR(meson_dw_hdmi->venci_clk)) {
> - dev_err(dev, "Unable to get venci clk\n");
> - return PTR_ERR(meson_dw_hdmi->venci_clk);
> - }
> - clk_prepare_enable(meson_dw_hdmi->venci_clk);
> + ret = meson_enable_clk(dev, "venci");
> + if (ret)
> + return ret;
>
> dw_plat_data->regm = devm_regmap_init(dev, NULL, meson_dw_hdmi,
> &meson_dw_hdmi_regmap_config);
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/meson: dw-hdmi: Enable the iahb clock early enough
On 20/11/2020 10:42, Marc Zyngier wrote:
> Instead of moving meson_dw_hdmi_init() around which breaks existing
> platform, let's enable the clock meson_dw_hdmi_init() depends on.
> This means we don't have to worry about this clock being enabled or
> not, depending on the boot-loader features.
>
> Fixes: b33340e33acd ("drm/meson: dw-hdmi: Ensure that clocks are enabled
> before touching the TOP registers")
> Reported-by: Guillaume Tucker
> Tested-by: Guillaume Tucker
> Signed-off-by: Marc Zyngier
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 29623b309cb1..aad75a22dc33 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -1051,6 +1051,10 @@ static int meson_dw_hdmi_bind(struct device *dev,
> struct device *master,
> if (ret)
> return ret;
>
> + ret = meson_enable_clk(dev, "iahb");
> + if (ret)
> + return ret;
> +
> ret = meson_enable_clk(dev, "venci");
> if (ret)
> return ret;
> @@ -1086,6 +1090,8 @@ static int meson_dw_hdmi_bind(struct device *dev,
> struct device *master,
>
> encoder->possible_crtcs = BIT(0);
>
> + meson_dw_hdmi_init(meson_dw_hdmi);
> +
> DRM_DEBUG_DRIVER("encoder initialized\n");
>
> /* Bridge / Connector */
> @@ -1110,8 +1116,6 @@ static int meson_dw_hdmi_bind(struct device *dev,
> struct device *master,
> if (IS_ERR(meson_dw_hdmi->hdmi))
> return PTR_ERR(meson_dw_hdmi->hdmi);
>
> - meson_dw_hdmi_init(meson_dw_hdmi);
> -
> next_bridge = of_drm_find_bridge(pdev->dev.of_node);
> if (next_bridge)
> drm_bridge_attach(encoder, next_bridge,
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 5.10-rc4; graphics alignment
Hi
Am 20.11.20 um 12:45 schrieb David Laight:
From: Thomas Zimmermann
Sent: 20 November 2020 11:27
...
You can use drm-tip for testing, where many of the DRM patches go through.
https://cgit.freedesktop.org/drm/drm-tip/
It's fairly up-to-date.
Any idea of tags either side of the 5.10 merge?
The final commit before v5.9 appears to be
Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init interface")
I'd try this as a good commit. For the bad commit, just try HEAD.
HEAD off that tree works.
Colours ok and no stack backtrace.
Ideas??
The good news is that it's been fixed. All you have to do is wait for
the fix to hit upstream.
Did you try the patch that Dave linked? If not, go back to v5.10-rc4 and
do
git am
The patch is attached. Please report back if this fixes the issue.
Best regards
Thomas
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
--- Begin Message ---
From: Dave Airlie
In 7053e0eab473119503f6565b4e398f9a73122481
drm/vram-helper: stop using TTM placement flags
it appears the flags got mixed up.
This should fix a regression on ast
[ 64.782340] WARNING: CPU: 51 PID: 1964 at
drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40
[drm_vram_helper]
[ 64.782411] CPU: 51 PID: 1964 Comm: Xorg Not tainted 5.10.0-rc3 #12
[ 64.782413] Hardware name: To be filled.
[ 64.782419] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper]
[ 64.782424] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48
8b 87 80 01 00 00 5d 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31
c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 87 18 06
[ 64.782427] RSP: 0018:a9128909fa68 EFLAGS: 00010246
[ 64.782431] RAX: 0002 RBX: 95a5c25e1ec0 RCX: c02b6600
[ 64.782433] RDX: 959e49824000 RSI: 95a5c25e0b40 RDI: 959e4b1c2c00
[ 64.782434] RBP: a9128909fa68 R08: 0040 R09: 95a9c5dcb688
[ 64.782436] R10: R11: 0001 R12: 959e49824000
[ 64.782437] R13: R14: R15: 95a5c5c56f00
[ 64.782440] FS: 7f485d466a80() GS:95a9afcc()
knlGS:
[ 64.782442] CS: 0010 DS: ES: CR0: 80050033
[ 64.782444] CR2: 7f485e202000 CR3: 000c82a0e000 CR4: 003506e0
[ 64.782446] Call Trace:
[ 64.782455] ast_cursor_page_flip+0x22/0x100 [ast]
[ 64.782460] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast]
[ 64.782477] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper]
[ 64.782493] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper]
[ 64.782507] commit_tail+0x99/0x130 [drm_kms_helper]
[ 64.782521] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper]
[ 64.782551] drm_atomic_commit+0x4a/0x50 [drm]
[ 64.782565] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper]
[ 64.782592] __setplane_atomic+0xcc/0x110 [drm]
[ 64.782619] drm_mode_cursor_universal+0x13e/0x260 [drm]
[ 64.782647] drm_mode_cursor_common+0xef/0x220 [drm]
[ 64.782654] ? tomoyo_path_number_perm+0x6f/0x200
[ 64.782680] ? drm_mode_cursor_ioctl+0x60/0x60 [drm]
[ 64.782706] drm_mode_cursor2_ioctl+0xe/0x10 [drm]
[ 64.782727] drm_ioctl_kernel+0xae/0xf0 [drm]
[ 64.782749] drm_ioctl+0x241/0x3f0 [drm]
[ 64.782774] ? drm_mode_cursor_ioctl+0x60/0x60 [drm]
[ 64.782781] ? tomoyo_file_ioctl+0x19/0x20
[ 64.782787] __x64_sys_ioctl+0x91/0xc0
[ 64.782792] do_syscall_64+0x38/0x90
[ 64.782797] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Dave Airlie
Cc: Wen Pu
Cc: David Laight
Cc: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 50cad0e4a92e..2896a057b771 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -140,7 +140,7 @@ static void drm_gem_vram_placement(struct
drm_gem_vram_object *gbo,
unsigned int c = 0;
if (pl_flag & DRM_GEM_VRAM_PL_FLAG_TOPDOWN)
- pl_flag = TTM_PL_FLAG_TOPDOWN;
+ invariant_flag = TTM_PL_FLAG_TOPDOWN;
gbo->placement.placement = gbo->placements;
gbo->placement.busy_placement = gbo->placements;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--- End Message ---
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mai
