[PATCH] Implement .format_mod_supported in mxsfb
This will make sure applications which use the IN_FORMATS blob
to figure out which modifiers they can use will pick up the
linear modifier which is needed by mxsfb. Such applications
will not work otherwise if an incompatible implicit modifier
ends up being selected.
Signed-off-by: Daniel Abrecht
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 956f631997f2..fc4b1626261b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -484,6 +484,13 @@ static void
mxsfb_plane_overlay_atomic_update(struct drm_plane *plane,
writel(ctrl, mxsfb->base + LCDC_AS_CTRL);
}
+static bool mxsfb_format_mod_supported(struct drm_plane *plane,
+ uint32_t format,
+ uint64_t modifier)
+{
+ return modifier == DRM_FORMAT_MOD_LINEAR;
+}
+
static const struct drm_plane_helper_funcs
mxsfb_plane_primary_helper_funcs = {
.atomic_check = mxsfb_plane_atomic_check,
.atomic_update = mxsfb_plane_primary_atomic_update,
@@ -495,6 +502,7 @@ static const struct drm_plane_helper_funcs
mxsfb_plane_overlay_helper_funcs = {
};
static const struct drm_plane_funcs mxsfb_plane_funcs = {
+ .format_mod_supported = mxsfb_format_mod_supported,
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy= drm_plane_cleanup,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 10/10] drm/fb_helper: Support framebuffers in I/O memory
Hi Thomas.
On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for the type of memory and call the rsp
> fb_sys_ of fb_cfb_ functions. Read and write operations are implemented
> internally by DRM's fbdev helper.
>
> For drivers that employ a shadow buffer, fbdev's blit function retrieves
> the framebuffer address as struct dma_buf_map, and uses dma_buf_map
> interfaces to access the buffer.
>
> The bochs driver on sparc64 uses a workaround to flag the framebuffer as
> I/O memory and avoid a HW exception. With the introduction of struct
> dma_buf_map, this is not required any longer. The patch removes the rsp
> code from both, bochs and fbdev.
>
> v5:
> * implement fb_read/fb_write internally (Daniel, Sam)
> v4:
> * move dma_buf_map changes into separate patch (Daniel)
> * TODO list: comment on fbdev updates (Daniel)
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: Sam Ravnborg
Reviewed-by: Sam Ravnborg
But see a few comments below on naming for you to consider.
Sam
> ---
> Documentation/gpu/todo.rst| 19 ++-
> drivers/gpu/drm/bochs/bochs_kms.c | 1 -
> drivers/gpu/drm/drm_fb_helper.c | 227 --
> include/drm/drm_mode_config.h | 12 --
> 4 files changed, 230 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7e6fc3c04add..638b7f704339 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
>
>
> Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
> -atomic modesetting and GEM vmap support. Current generic fbdev emulation
> -expects the framebuffer in system memory (or system-like memory).
> +atomic modesetting and GEM vmap support. Historically, generic fbdev
> emulation
> +expected the framebuffer in system memory or system-like memory. By employing
> +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
> +as well.
>
> Contact: Maintainer of the driver you plan to convert
>
> Level: Intermediate
>
> +Reimplement functions in drm_fbdev_fb_ops without fbdev
> +---
> +
> +A number of callback functions in drm_fbdev_fb_ops could benefit from
> +being rewritten without dependencies on the fbdev module. Some of the
> +helpers could further benefit from using struct dma_buf_map instead of
> +raw pointers.
> +
> +Contact: Thomas Zimmermann , Daniel Vetter
> +
> +Level: Advanced
> +
> +
> drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
> -
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 13d0d04c4457..853081d186d5 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
> bochs->dev->mode_config.preferred_depth = 24;
> bochs->dev->mode_config.prefer_shadow = 0;
> bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> - bochs->dev->mode_config.fbdev_use_iomem = true;
> bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>
> bochs->dev->mode_config.funcs = _mode_funcs;
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 6212cd7cde1d..1d3180841778 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
> work_struct *work)
> }
>
> static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
> - struct drm_clip_rect *clip)
> + struct drm_clip_rect *clip,
> + struct dma_buf_map *dst)
> {
> struct drm_framebuffer *fb = fb_helper->fb;
> unsigned int cpp = fb->format->cpp[0];
> size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> void *src = fb_helper->fbdev->screen_buffer + offset;
> - void *dst = fb_helper->buffer->map.vaddr + offset;
> size_t len = (clip->x2 - clip->x1) * cpp;
> unsigned int y;
>
> - for (y = clip->y1; y < clip->y2; y++) {
> - if (!fb_helper->dev->mode_config.fbdev_use_iomem)
> - memcpy(dst, src, len);
> - else
> - memcpy_toio((void __iomem *)dst, src, len);
> + dma_buf_map_incr(dst, offset); /* go to first pixel within clip rect */
>
> + for (y = clip->y1; y < clip->y2; y++) {
> +
Re: WARNING in dma_map_page_attrs
CC: rdma, looks like rdma from the stack trace On Fri, 23 Oct 2020 20:07:17 -0700 syzbot wrote: > syzbot has found a reproducer for the following issue on: > > HEAD commit:3cb12d27 Merge tag 'net-5.10-rc1' of git://git.kernel.org/.. > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=1312539050 > kernel config: https://syzkaller.appspot.com/x/.config?x=46c6fea3eb827ae1 > dashboard link: https://syzkaller.appspot.com/bug?extid=34dc2fea3478e659af01 > compiler: gcc (GCC) 10.1.0-syz 20200507 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1685866450 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11f402ef90 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+34dc2fea3478e659a...@syzkaller.appspotmail.com > > netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 > netdevsim netdevsim0 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 > netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 > infiniband syz2: set active > infiniband syz2: added macvlan0 > [ cut here ] > WARNING: CPU: 1 PID: 8488 at kernel/dma/mapping.c:149 > dma_map_page_attrs+0x493/0x700 kernel/dma/mapping.c:149 > Modules linked in: > CPU: 1 PID: 8488 Comm: syz-executor144 Not tainted 5.9.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:dma_map_page_attrs+0x493/0x700 kernel/dma/mapping.c:149 > Code: 80 3c 10 00 0f 85 ed 01 00 00 48 8b 1d 86 38 e9 0c e9 2d fc ff ff 48 89 > c3 e9 d1 fd ff ff e8 04 11 12 00 0f 0b e8 fd 10 12 00 <0f> 0b 49 c7 c4 ff ff > ff ff e9 d5 fd ff ff e8 ea 10 12 00 48 8d 7b > RSP: 0018:c9fdec68 EFLAGS: 00010293 > RAX: RBX: 894d1060 RCX: 815df1e3 > RDX: 8880208c1a40 RSI: 815df5b3 RDI: 8880196f8b00 > RBP: 88801412d800 R08: 0002 R09: > R10: 0002 R11: R12: ea504b40 > R13: 8880196f86e8 R14: 08b8 R15: 0002 > FS: 01b26880() GS:8880b9f0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 22c0 CR3: 22446000 CR4: 001506e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > dma_map_single_attrs include/linux/dma-mapping.h:279 [inline] > ib_dma_map_single include/rdma/ib_verbs.h:3967 [inline] > ib_mad_post_receive_mads+0x23f/0xd60 drivers/infiniband/core/mad.c:2715 > ib_mad_port_start drivers/infiniband/core/mad.c:2862 [inline] > ib_mad_port_open drivers/infiniband/core/mad.c:3016 [inline] > ib_mad_init_device+0x72b/0x1400 drivers/infiniband/core/mad.c:3092 > add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:680 > enable_device_and_get+0x1d5/0x3c0 drivers/infiniband/core/device.c:1301 > ib_register_device drivers/infiniband/core/device.c:1376 [inline] > ib_register_device+0x7a7/0xa40 drivers/infiniband/core/device.c:1335 > rxe_register_device+0x46d/0x570 drivers/infiniband/sw/rxe/rxe_verbs.c:1182 > rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 > rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:507 > rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] > rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 > nldev_newlink+0x30e/0x540 drivers/infiniband/core/nldev.c:1555 > rdma_nl_rcv_msg+0x367/0x690 drivers/infiniband/core/netlink.c:195 > rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] > rdma_nl_rcv+0x2f2/0x440 drivers/infiniband/core/netlink.c:259 > netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] > netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 > netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 > sock_sendmsg_nosec net/socket.c:651 [inline] > sock_sendmsg+0xcf/0x120 net/socket.c:671 > sys_sendmsg+0x6e8/0x810 net/socket.c:2353 > ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 > __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x443699 > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 > 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f > 83 db 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7ffc067db418 EFLAGS: 0246 ORIG_RAX: 002e > RAX: ffda RBX: 0003 RCX: 00443699 > RDX: RSI: 22c0 RDI: 0003 > RBP: 7ffc067db420 R08: 01bb R09: 01bb > R10: R11: 0246 R12: 7ffc067db430 > R13: R14: R15: > ___ dri-devel mailing
Re: [PATCH] drm/i915: Fix a crash in shmem_pin_map() error handling
On Fri, Oct 23, 2020 at 02:19:41PM +0200, Christoph Hellwig wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
> > b/drivers/gpu/drm/i915/gt/shmem_utils.c
> > index f011ea42487e..7eb542018219 100644
> > --- a/drivers/gpu/drm/i915/gt/shmem_utils.c
> > +++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
> > @@ -52,8 +52,9 @@ struct file *shmem_create_from_object(struct
> > drm_i915_gem_object *obj)
> > void *shmem_pin_map(struct file *file)
> > {
> > struct page **pages;
> > - size_t n_pages, i;
> > + size_t n_pages;
> > void *vaddr;
> > + int i;
> >
> > n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
> > pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
>
> This assumes we never have more than INT_MAX worth of pages before
> a failure.
Doh. Yeah. My bad.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/radeon: Add new callback that exposes vddc
Hello,
I've resent the patches in the correct format. Please review.
- Sandeep
On Fri, 9 Oct 2020 at 13:14, Sandeep Raghuraman wrote:
>
> This patch adds a callback for reporting vddc, to the dpm field of the
> radeon_asic structure.
>
> Signed-off-by: Sandeep Raghuraman
>
> ---
> drivers/gpu/drm/radeon/radeon.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index cc4f58d16589..85a1cafdf303 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1992,6 +1992,7 @@ struct radeon_asic {
> int (*get_fan_speed_percent)(struct radeon_device *rdev, u32
> *speed);
> u32 (*get_current_sclk)(struct radeon_device *rdev);
> u32 (*get_current_mclk)(struct radeon_device *rdev);
> + u16 (*get_current_vddc)(struct radeon_device *rdev);
> } dpm;
> /* pageflipping */
> struct {
> --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: [PATCH] gpu/drm/mgag200:remove break after return
Hi Bernard.
On Fri, Oct 23, 2020 at 03:48:49PM +0800, Bernard wrote:
>
>
> From: Thomas Zimmermann
> Date: 2020-10-23 15:13:30
> To: Bernard Zhao ,Dave Airlie ,David
> Airlie ,Daniel Vetter
> ,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
> Cc: opensource.ker...@vivo.com
> Subject: Re: [PATCH] gpu/drm/mgag200:remove break after return>Hi
> >
> >On 23.10.20 09:00, Bernard Zhao wrote:
> >> In function mgag200_set_pci_regs, there are some switch cases
> >> returned, then break. These break will never run.
> >> This patch is to make the code a bit readable.
> >>
> >> Signed-off-by: Bernard Zhao
> >> ---
> >> drivers/gpu/drm/mgag200/mgag200_mode.c | 5 +
> >> 1 file changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> >> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> >> index 38672f9e5c4f..de873a5d276e 100644
> >> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> >> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> >> @@ -794,20 +794,17 @@ static int mgag200_crtc_set_plls(struct mga_device
> >> *mdev, long clock)
> >>case G200_SE_A:
> >>case G200_SE_B:
> >>return mga_g200se_set_plls(mdev, clock);
> >> - break;
> >>case G200_WB:
> >>case G200_EW3:
> >>return mga_g200wb_set_plls(mdev, clock);
> >> - break;
> >>case G200_EV:
> >>return mga_g200ev_set_plls(mdev, clock);
> >> - break;
> >>case G200_EH:
> >>case G200_EH3:
> >>return mga_g200eh_set_plls(mdev, clock);
> >> - break;
> >>case G200_ER:
> >>return mga_g200er_set_plls(mdev, clock);
> >> + default:
> >
> >No default case here. If one of the enum values is not handled by the
> >switch, the compiler should warn about it.
>
> Hi
>
> For this point I was a little confused, about this switch variable
> "mdev->type", my understanding is that this variable`s value can be certain
> only when the code is running.
> How does the compiler warn this("If one of the enum values is not handled")
> before the code runs?
If the switch/case does not include "G200_ER" then the compiler can see
one enum value is missing from the list and can warn.
As a test - Try to drop the default and drop G200_ER - then the
compiler (hopefully) will warn.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: add __user annotation in radeon_ttm_vram_read
Keep sparse happy by preserving the __user annotation when casting. Reported-by: kernel test robot Signed-off-by: Rasmus Villemoes --- kernel test robot has already started spamming me due to 9c5743dff. If I don't fix those warnings I'll keep getting those emails for months, so let me do the easy ones. drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 36150b7f31a90aa1eece..ecfe88b0a35d8f317712 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -1005,7 +1005,7 @@ static ssize_t radeon_ttm_vram_read(struct file *f, char __user *buf, value = RREG32(RADEON_MM_DATA); spin_unlock_irqrestore(>mmio_idx_lock, flags); - r = put_user(value, (uint32_t *)buf); + r = put_user(value, (uint32_t __user *)buf); if (r) return r; -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow
On 10/22/20 12:42 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > The new >8k CEA modes have dotclocks reaching 5.94 GHz, which > means our clock*1000 will now overflow the 32bit unsigned > integer. Switch to 64bit maths to avoid it. > > Cc: sta...@vger.kernel.org > Reported-by: Randy Dunlap > Signed-off-by: Ville Syrjälä This cures the problem that I reported. Thanks. Tested-by: Randy Dunlap > --- > An interesting question how many other place might suffer from similar > overflows. I think i915 should be mostly OK. The one place I know we use > Hz instead kHz is the hsw DPLL code, which I would prefer we also change > to use kHz. The other concern is whether we have any potential overflows > before we check this against the platform's max dotclock. > > I do have this unreviewed igt series > https://patchwork.freedesktop.org/series/69531/ which extends the > current testing with some other forms of invalid modes. Could probably > extend that with a mode.clock=INT_MAX test to see if anything else might > trip up. > > No idea about other drivers. > > drivers/gpu/drm/drm_modes.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index 501b4fe55a3d..511cde5c7fa6 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -762,7 +762,7 @@ int drm_mode_vrefresh(const struct drm_display_mode *mode) > if (mode->htotal == 0 || mode->vtotal == 0) > return 0; > > - num = mode->clock * 1000; > + num = mode->clock; > den = mode->htotal * mode->vtotal; > > if (mode->flags & DRM_MODE_FLAG_INTERLACE) > @@ -772,7 +772,7 @@ int drm_mode_vrefresh(const struct drm_display_mode *mode) > if (mode->vscan > 1) > den *= mode->vscan; > > - return DIV_ROUND_CLOSEST(num, den); > + return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(num, 1000), den); > } > EXPORT_SYMBOL(drm_mode_vrefresh); > > -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] Add DRM/DSI support for MT8167 SoC
This series adds support for DSI on the MT8167 SoC. HDMI is not yet supported as secondary display path. mmsys is not supported by this series and will be sent in a seperate series based on [0]. [0] https://patchwork.kernel.org/project/linux-mediatek/list/?series=360447 Changelog: V2: removed 3 patches Fabien Parent (5): dt-bindings: display: mediatek: disp: add documentation for MT8167 SoC dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC drm/mediatek: add disp-color MT8167 support drm/mediatek: add DDP support for MT8167 drm/mediatek: Add support for main DDP path on MT8167 .../display/mediatek/mediatek,disp.txt| 4 +- .../display/mediatek/mediatek,dsi.txt | 4 +- drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +++ drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 47 +++ drivers/gpu/drm/mediatek/mtk_drm_drv.c| 38 +++ 5 files changed, 96 insertions(+), 4 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm/adi: axi-hdmi-tx: Add support for AXI HDMI TX IP core
Thank you Sam for your review, I'll send now V2 implementing all your remarks. Best regards, Bogdan > > Hi Bogdan > > On Mon, Oct 05, 2020 at 05:12:08PM +0300, Bogdan Togorean wrote: > > From: Lars-Peter Clausen > > > > The AXI HDMI HDL driver is the driver for the HDL graphics core which is > > used on various FPGA designs. It's mostly used to interface with the > > ADV7511 driver on some Zynq boards (e.g. ZC702 & ZedBoard). > > > > Link: > > https://wiki.analog.com/resources/tools-software/linux-drivers/drm/hdl- > axi-hdmi > > Link: https://wiki.analog.com/resources/fpga/docs/axi_hdmi_tx > > Thanks for submitting the driver - a few high level comments after > browsing the driver: > > - Use drmm_mode_config_init() to utilize new cleanup > - Look at other uses of drm_driver - there is macros that makes this > much simpler / smaller > - Use devm_drm_dev_alloc() to allocate axi_hdmi_tx_private > To do so embed drm_device in axi_hdmi_tx_private - which is the way to > do it today > - Do not use ddev->dev_private, it is deprecated > - Use dev_err_probe() when you risk to see a PROBE_DEFER > - In all include blocks sort the include alphabetically > - Use the new interface to drm_bridge_attach() - where display driver > creates the connector > - See if the Kconfig selects can be trimmed - the framebuffer releated > selects looks wrong (others get it wrong too) > - Check if you can use the simple encoder - see > drm_simple_encoder_init() > > If this is a simple one plane, one crtc display driver then it should > use the drm_simple_* support. Or the changelog should explain why not. > > We want the drivers as simple as we can - and they shall use as much of > the helper infrastructure as they can. > > We continue to develop the helper infrastructure so it is expected that > there is some lacking behind as is the case here. > > Sam > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/mediatek: add DDP support for MT8167
Add DDP support for MT8167 SoC.
Signed-off-by: Fabien Parent
---
Changelog:
V2: don't set DDP_MUTEX_SOF_DSI{1,2,3} since they are not available on MT8167
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 47 ++
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 014c1bbe1df2..1f99db6b1a42 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -25,6 +25,19 @@
#define INT_MUTEX BIT(1)
+#define MT8167_MUTEX_MOD_DISP_PWM 1
+#define MT8167_MUTEX_MOD_DISP_OVL0 6
+#define MT8167_MUTEX_MOD_DISP_OVL1 7
+#define MT8167_MUTEX_MOD_DISP_RDMA08
+#define MT8167_MUTEX_MOD_DISP_RDMA19
+#define MT8167_MUTEX_MOD_DISP_WDMA010
+#define MT8167_MUTEX_MOD_DISP_CCORR11
+#define MT8167_MUTEX_MOD_DISP_COLOR12
+#define MT8167_MUTEX_MOD_DISP_AAL 13
+#define MT8167_MUTEX_MOD_DISP_GAMMA14
+#define MT8167_MUTEX_MOD_DISP_DITHER 15
+#define MT8167_MUTEX_MOD_DISP_UFOE 16
+
#define MT8173_MUTEX_MOD_DISP_OVL0 11
#define MT8173_MUTEX_MOD_DISP_OVL1 12
#define MT8173_MUTEX_MOD_DISP_RDMA013
@@ -73,6 +86,8 @@
#define MUTEX_SOF_DPI1 4
#define MUTEX_SOF_DSI2 5
#define MUTEX_SOF_DSI3 6
+#define MT8167_MUTEX_SOF_DPI0 2
+#define MT8167_MUTEX_SOF_DPI1 3
struct mtk_disp_mutex {
@@ -135,6 +150,21 @@ static const unsigned int
mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
};
+static const unsigned int mt8167_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT8167_MUTEX_MOD_DISP_AAL,
+ [DDP_COMPONENT_CCORR] = MT8167_MUTEX_MOD_DISP_CCORR,
+ [DDP_COMPONENT_COLOR0] = MT8167_MUTEX_MOD_DISP_COLOR,
+ [DDP_COMPONENT_DITHER] = MT8167_MUTEX_MOD_DISP_DITHER,
+ [DDP_COMPONENT_GAMMA] = MT8167_MUTEX_MOD_DISP_GAMMA,
+ [DDP_COMPONENT_OVL0] = MT8167_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL1] = MT8167_MUTEX_MOD_DISP_OVL1,
+ [DDP_COMPONENT_PWM0] = MT8167_MUTEX_MOD_DISP_PWM,
+ [DDP_COMPONENT_RDMA0] = MT8167_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT8167_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_UFOE] = MT8167_MUTEX_MOD_DISP_UFOE,
+ [DDP_COMPONENT_WDMA0] = MT8167_MUTEX_MOD_DISP_WDMA0,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -163,6 +193,13 @@ static const unsigned int
mt2712_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
[DDP_MUTEX_SOF_DSI3] = MUTEX_SOF_DSI3,
};
+static const unsigned int mt8167_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
+ [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
+ [DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
+ [DDP_MUTEX_SOF_DPI0] = MT8167_MUTEX_SOF_DPI0,
+ [DDP_MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
+};
+
static const struct mtk_ddp_data mt2701_ddp_driver_data = {
.mutex_mod = mt2701_mutex_mod,
.mutex_sof = mt2712_mutex_sof,
@@ -177,6 +214,14 @@ static const struct mtk_ddp_data mt2712_ddp_driver_data = {
.mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
};
+static const struct mtk_ddp_data mt8167_ddp_driver_data = {
+ .mutex_mod = mt8167_mutex_mod,
+ .mutex_sof = mt8167_mutex_sof,
+ .mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
+ .mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
+ .no_clk = true,
+};
+
static const struct mtk_ddp_data mt8173_ddp_driver_data = {
.mutex_mod = mt8173_mutex_mod,
.mutex_sof = mt2712_mutex_sof,
@@ -400,6 +445,8 @@ static const struct of_device_id ddp_driver_dt_match[] = {
.data = _ddp_driver_data},
{ .compatible = "mediatek,mt2712-disp-mutex",
.data = _ddp_driver_data},
+ { .compatible = "mediatek,mt8167-disp-mutex",
+ .data = _ddp_driver_data},
{ .compatible = "mediatek,mt8173-disp-mutex",
.data = _ddp_driver_data},
{},
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: dw_hdmi: fix incorrect clock in vpll clock error message
Error message incorrectly refers to grf clock instead of vpll clock.
Signed-off-by: Jonathan Liu
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 23de359a1dec..830bdd5e9b7c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -202,7 +202,7 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
*hdmi)
} else if (PTR_ERR(hdmi->vpll_clk) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
} else if (IS_ERR(hdmi->vpll_clk)) {
- DRM_DEV_ERROR(hdmi->dev, "failed to get grf clock\n");
+ DRM_DEV_ERROR(hdmi->dev, "failed to get vpll clock\n");
return PTR_ERR(hdmi->vpll_clk);
}
--
2.29.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/mediatek: add disp-color MT8167 support
Add support for disp-color on MT8167 SoC.
Signed-off-by: Fabien Parent
Reviewed-by: Chun-Kuang Hu
---
Changelog:
V2: No change
drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 3ae9c810845b..a1227cefbf31 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -16,6 +16,7 @@
#define DISP_COLOR_CFG_MAIN0x0400
#define DISP_COLOR_START_MT27010x0f00
+#define DISP_COLOR_START_MT81670x0400
#define DISP_COLOR_START_MT81730x0c00
#define DISP_COLOR_START(comp) ((comp)->data->color_offset)
#define DISP_COLOR_WIDTH(comp) (DISP_COLOR_START(comp) + 0x50)
@@ -148,6 +149,10 @@ static const struct mtk_disp_color_data
mt2701_color_driver_data = {
.color_offset = DISP_COLOR_START_MT2701,
};
+static const struct mtk_disp_color_data mt8167_color_driver_data = {
+ .color_offset = DISP_COLOR_START_MT8167,
+};
+
static const struct mtk_disp_color_data mt8173_color_driver_data = {
.color_offset = DISP_COLOR_START_MT8173,
};
@@ -155,6 +160,8 @@ static const struct mtk_disp_color_data
mt8173_color_driver_data = {
static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-color",
.data = _color_driver_data},
+ { .compatible = "mediatek,mt8167-disp-color",
+ .data = _color_driver_data},
{ .compatible = "mediatek,mt8173-disp-color",
.data = _color_driver_data},
{},
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/: Constify struct drm_driver
On Fri, Oct 23, 2020 at 02:28:11PM +0200, Daniel Vetter wrote: > Only the following drivers aren't converted: > - amdgpu, because of the driver_feature mangling due to virt support > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > platforms where it's supported (i.e. again driver_feature mangling) > - vc4, again because of driver_feature mangling > - qxl, because the ioctl table is somewhere else and moving that is > maybe a bit too much, hence the num_ioctls assignment prevents a > const driver structure. > > Note that for armada I also went ahead and made the ioctl array const. > > Only cc'ing the driver people who've not been converted (everyone else > is way too much). > > Signed-off-by: Daniel Vetter > Cc: Dave Airlie > Cc: Gerd Hoffmann > Cc: virtualizat...@lists.linux-foundation.org > Cc: Harry Wentland > Cc: Leo Li > Cc: Alex Deucher > Cc: Christian König > Cc: Eric Anholt > Cc: Maxime Ripard > Cc: Ben Skeggs > Cc: nouv...@lists.freedesktop.org > Signed-off-by: Daniel Vetter Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm: Compile out legacy chunks from struct drm_device
On Fri, Oct 23, 2020 at 02:28:08PM +0200, Daniel Vetter wrote: > This means some very few #ifdef in code, but it allows us to > enlist the compiler to make sure this stuff isn't used anymore. > > More important, only legacy drivers change drm_device (for the > legacy_dev_list shadow attach management), therefore this is > prep to allow modern drivers to have a const driver struct. Which > is nice, because there's a ton of function pointers in there. > > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Signed-off-by: Daniel Vetter Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm: Allow const struct drm_driver
On Fri, Oct 23, 2020 at 02:28:10PM +0200, Daniel Vetter wrote: > It's nice if a big function/ioctl table like this is const. Only > downside here is that we need a few more #ifdef to paper over the > differences when CONFIG_DRM_LEGACY is enabled. Maybe provides more > motivation to sunset that horror show :-) > > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Signed-off-by: Daniel Vetter Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] drm/mediatek: Add support for main DDP path on MT8167
Add the main (DSI) drm display path for MT8167.
Signed-off-by: Fabien Parent
---
Changelog:
V2: No change
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 59c85c63b7cc..3952435093fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -112,6 +112,17 @@ static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] =
{
DDP_COMPONENT_PWM2,
};
+static enum mtk_ddp_comp_id mt8167_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_DSI0,
+};
+
static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
@@ -163,6 +174,11 @@ static const struct mtk_mmsys_driver_data
mt8173_mmsys_driver_data = {
.ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext),
};
+static const struct mtk_mmsys_driver_data mt8167_mmsys_driver_data = {
+ .main_path = mt8167_mtk_ddp_main,
+ .main_len = ARRAY_SIZE(mt8167_mtk_ddp_main),
+};
+
static int mtk_drm_kms_init(struct drm_device *drm)
{
struct mtk_drm_private *private = drm->dev_private;
@@ -401,26 +417,42 @@ static const struct component_master_ops mtk_drm_ops = {
static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
.data = (void *)MTK_DISP_OVL },
+ { .compatible = "mediatek,mt8167-disp-ovl",
+ .data = (void *)MTK_DISP_OVL },
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = (void *)MTK_DISP_OVL },
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = (void *)MTK_DISP_RDMA },
+ { .compatible = "mediatek,mt8167-disp-rdma",
+ .data = (void *)MTK_DISP_RDMA },
{ .compatible = "mediatek,mt8173-disp-rdma",
.data = (void *)MTK_DISP_RDMA },
{ .compatible = "mediatek,mt8173-disp-wdma",
.data = (void *)MTK_DISP_WDMA },
+ { .compatible = "mediatek,mt8167-disp-ccorr",
+ .data = (void *)MTK_DISP_CCORR },
{ .compatible = "mediatek,mt2701-disp-color",
.data = (void *)MTK_DISP_COLOR },
+ { .compatible = "mediatek,mt8167-disp-color",
+ .data = (void *)MTK_DISP_COLOR },
{ .compatible = "mediatek,mt8173-disp-color",
.data = (void *)MTK_DISP_COLOR },
+ { .compatible = "mediatek,mt8167-disp-aal",
+ .data = (void *)MTK_DISP_AAL},
{ .compatible = "mediatek,mt8173-disp-aal",
.data = (void *)MTK_DISP_AAL},
+ { .compatible = "mediatek,mt8167-disp-gamma",
+ .data = (void *)MTK_DISP_GAMMA, },
{ .compatible = "mediatek,mt8173-disp-gamma",
.data = (void *)MTK_DISP_GAMMA, },
+ { .compatible = "mediatek,mt8167-disp-dither",
+ .data = (void *)MTK_DISP_DITHER },
{ .compatible = "mediatek,mt8173-disp-ufoe",
.data = (void *)MTK_DISP_UFOE },
{ .compatible = "mediatek,mt2701-dsi",
.data = (void *)MTK_DSI },
+ { .compatible = "mediatek,mt8167-dsi",
+ .data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8173-dsi",
.data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt2701-dpi",
@@ -431,10 +463,14 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2712-disp-mutex",
.data = (void *)MTK_DISP_MUTEX },
+ { .compatible = "mediatek,mt8167-disp-mutex",
+ .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-mutex",
.data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2701-disp-pwm",
.data = (void *)MTK_DISP_BLS },
+ { .compatible = "mediatek,mt8167-disp-pwm",
+ .data = (void *)MTK_DISP_PWM },
{ .compatible = "mediatek,mt8173-disp-pwm",
.data = (void *)MTK_DISP_PWM },
{ .compatible = "mediatek,mt8173-disp-od",
@@ -449,6 +485,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
.data = _mmsys_driver_data},
{ .compatible = "mediatek,mt2712-mmsys",
.data = _mmsys_driver_data},
+ { .compatible = "mediatek,mt8167-mmsys",
+ .data = _mmsys_driver_data},
{ .compatible = "mediatek,mt8173-mmsys",
.data = _mmsys_driver_data},
{ }
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC
Add binding documentation for the MT8167 SoC. Signed-off-by: Fabien Parent --- Changelog: V2: removed part that added a new clock .../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt index f06f24d405a5..6a10de812158 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt @@ -7,7 +7,7 @@ channel output. Required properties: - compatible: "mediatek,-dsi" -- the supported chips are mt2701, mt7623, mt8173 and mt8183. +- the supported chips are mt2701, mt7623, mt8167, mt8173 and mt8183. - reg: Physical base address and length of the controller's registers - interrupts: The interrupt signal from the function block. - clocks: device clocks @@ -26,7 +26,7 @@ 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. +- the supported chips are mt2701, 7623, mt8167, 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 -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/4] RDMA/umem: Support importing dma-buf as user memory region
On Fri, Oct 23, 2020 at 06:49:11PM +0200, Daniel Vetter wrote:
> > +struct ib_umem *ib_umem_dmabuf_get(struct ib_device *device,
> > + unsigned long offset, size_t size,
> > + int fd, int access,
> > + const struct dma_buf_attach_ops *ops)
> > +{
> > + struct dma_buf *dmabuf;
> > + struct ib_umem_dmabuf *umem_dmabuf;
> > + struct ib_umem *umem;
> > + unsigned long end;
> > + long ret;
> > +
> > + if (check_add_overflow(offset, (unsigned long)size, ))
> > + return ERR_PTR(-EINVAL);
> > +
> > + if (unlikely(PAGE_ALIGN(end) < PAGE_SIZE))
> > + return ERR_PTR(-EINVAL);
> > +
> > + if (unlikely(!ops || !ops->move_notify))
> > + return ERR_PTR(-EINVAL);
> > +
> > +#ifdef CONFIG_DMA_VIRT_OPS
> > + if (device->dma_device->dma_ops == _virt_ops)
> > + return ERR_PTR(-EINVAL);
> > +#endif
>
> Maybe I'm confused, but should we have this check in dma_buf_attach, or at
> least in dma_buf_dynamic_attach? The p2pdma functions use that too, and I
> can't imagine how zerocopy should work (which is like the entire point of
> dma-buf) when we have dma_virt_ops.
The problem is we have RDMA drivers that assume SGL's have a valid
struct page, and these hacky/wrong P2P sgls that DMABUF creates cannot
be passed into those drivers.
But maybe this is just a 'drivers are using it wrong' if they call
this function and expect struct pages..
The check in the p2p stuff was done to avoid this too, but it was on a
different flow.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in dma_map_page_attrs
syzbot has found a reproducer for the following issue on: HEAD commit:3cb12d27 Merge tag 'net-5.10-rc1' of git://git.kernel.org/.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=1312539050 kernel config: https://syzkaller.appspot.com/x/.config?x=46c6fea3eb827ae1 dashboard link: https://syzkaller.appspot.com/bug?extid=34dc2fea3478e659af01 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1685866450 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11f402ef90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+34dc2fea3478e659a...@syzkaller.appspotmail.com netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 infiniband syz2: set active infiniband syz2: added macvlan0 [ cut here ] WARNING: CPU: 1 PID: 8488 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x493/0x700 kernel/dma/mapping.c:149 Modules linked in: CPU: 1 PID: 8488 Comm: syz-executor144 Not tainted 5.9.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dma_map_page_attrs+0x493/0x700 kernel/dma/mapping.c:149 Code: 80 3c 10 00 0f 85 ed 01 00 00 48 8b 1d 86 38 e9 0c e9 2d fc ff ff 48 89 c3 e9 d1 fd ff ff e8 04 11 12 00 0f 0b e8 fd 10 12 00 <0f> 0b 49 c7 c4 ff ff ff ff e9 d5 fd ff ff e8 ea 10 12 00 48 8d 7b RSP: 0018:c9fdec68 EFLAGS: 00010293 RAX: RBX: 894d1060 RCX: 815df1e3 RDX: 8880208c1a40 RSI: 815df5b3 RDI: 8880196f8b00 RBP: 88801412d800 R08: 0002 R09: R10: 0002 R11: R12: ea504b40 R13: 8880196f86e8 R14: 08b8 R15: 0002 FS: 01b26880() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 22c0 CR3: 22446000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: dma_map_single_attrs include/linux/dma-mapping.h:279 [inline] ib_dma_map_single include/rdma/ib_verbs.h:3967 [inline] ib_mad_post_receive_mads+0x23f/0xd60 drivers/infiniband/core/mad.c:2715 ib_mad_port_start drivers/infiniband/core/mad.c:2862 [inline] ib_mad_port_open drivers/infiniband/core/mad.c:3016 [inline] ib_mad_init_device+0x72b/0x1400 drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:680 enable_device_and_get+0x1d5/0x3c0 drivers/infiniband/core/device.c:1301 ib_register_device drivers/infiniband/core/device.c:1376 [inline] ib_register_device+0x7a7/0xa40 drivers/infiniband/core/device.c:1335 rxe_register_device+0x46d/0x570 drivers/infiniband/sw/rxe/rxe_verbs.c:1182 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:507 rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldev_newlink+0x30e/0x540 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x367/0x690 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x2f2/0x440 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x443699 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc067db418 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00443699 RDX: RSI: 22c0 RDI: 0003 RBP: 7ffc067db420 R08: 01bb R09: 01bb R10: R11: 0246 R12: 7ffc067db430 R13: R14: R15: ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:Re: [PATCH] gpu/drm/mgag200:remove break after return
From: Thomas Zimmermann
Date: 2020-10-23 15:13:30
To: Bernard Zhao ,Dave Airlie ,David
Airlie ,Daniel Vetter
,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc: opensource.ker...@vivo.com
Subject: Re: [PATCH] gpu/drm/mgag200:remove break after return>Hi
>
>On 23.10.20 09:00, Bernard Zhao wrote:
>> In function mgag200_set_pci_regs, there are some switch cases
>> returned, then break. These break will never run.
>> This patch is to make the code a bit readable.
>>
>> Signed-off-by: Bernard Zhao
>> ---
>> drivers/gpu/drm/mgag200/mgag200_mode.c | 5 +
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
>> b/drivers/gpu/drm/mgag200/mgag200_mode.c
>> index 38672f9e5c4f..de873a5d276e 100644
>> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
>> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
>> @@ -794,20 +794,17 @@ static int mgag200_crtc_set_plls(struct mga_device
>> *mdev, long clock)
>> case G200_SE_A:
>> case G200_SE_B:
>> return mga_g200se_set_plls(mdev, clock);
>> -break;
>> case G200_WB:
>> case G200_EW3:
>> return mga_g200wb_set_plls(mdev, clock);
>> -break;
>> case G200_EV:
>> return mga_g200ev_set_plls(mdev, clock);
>> -break;
>> case G200_EH:
>> case G200_EH3:
>> return mga_g200eh_set_plls(mdev, clock);
>> -break;
>> case G200_ER:
>> return mga_g200er_set_plls(mdev, clock);
>> +default:
>
>No default case here. If one of the enum values is not handled by the
>switch, the compiler should warn about it.
Hi
For this point I was a little confused, about this switch variable
"mdev->type", my understanding is that this variable`s value can be certain
only when the code is running.
How does the compiler warn this("If one of the enum values is not handled")
before the code runs?
BR//Bernard
>Best regards
>Thomas
>
>> break;
>> }
>>
>>
>
>--
>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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] dt-bindings: display: mediatek: disp: add documentation for MT8167 SoC
Add binding documentation for the MT8167 SoC Signed-off-by: Fabien Parent Reviewed-by: Chun-Kuang Hu --- Changelog: V2: No change .../devicetree/bindings/display/mediatek/mediatek,disp.txt| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 121220745d46..33977e15bebd 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -43,7 +43,7 @@ Required properties (all function blocks): "mediatek,-dpi" - DPI controller, see mediatek,dpi.txt "mediatek,-disp-mutex"- display mutex "mediatek,-disp-od" - overdrive - the supported chips are mt2701, mt7623, mt2712 and mt8173. + the supported chips are mt2701, mt7623, mt2712, mt8167 and mt8173. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for merge and split function blocks). @@ -59,7 +59,7 @@ Required properties (DMA function blocks): "mediatek,-disp-ovl" "mediatek,-disp-rdma" "mediatek,-disp-wdma" - the supported chips are mt2701 and mt8173. + the supported chips are mt2701, mt8167 and mt8173. - larb: Should contain a phandle pointing to the local arbiter device as defined in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt - iommus: Should point to the respective IOMMU block with master port as -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: More whitespace clean-ups in schema files
On Fri, 23 Oct 2020 14:22:58 -0500 Rob Herring wrote: > Clean-up incorrect indentation, extra spaces, and missing EOF newline in > schema files. Most of the clean-ups are for list indentation which > should always be 2 spaces more than the preceding keyword. > > Found with yamllint (now integrated into the checks). > > Cc: linux-arm-ker...@lists.infradead.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-g...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@lists.infradead.org > Cc: linux-ser...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring Acked-by: Jonathan Cameron #for-iio > --- > .../display/bridge/toshiba,tc358775.yaml | 18 ++-- > .../display/panel/ilitek,ili9881c.yaml| 5 +- > .../devicetree/bindings/eeprom/at25.yaml | 6 +- > .../bindings/gpio/kontron,sl28cpld-gpio.yaml | 4 +- > .../devicetree/bindings/i2c/ingenic,i2c.yaml | 8 +- > .../bindings/iio/adc/adi,ad7291.yaml | 3 +- > .../bindings/iio/adc/adi,ad7768-1.yaml| 3 +- > .../bindings/iio/adc/cosmic,10001-adc.yaml| 4 +- > .../bindings/iio/adc/holt,hi8435.yaml | 2 +- > .../interrupt-controller/ti,pruss-intc.yaml | 12 +-- > .../devicetree/bindings/mfd/ene-kb3930.yaml | 2 +- > .../devicetree/bindings/mmc/arasan,sdhci.yaml | 8 +- > .../devicetree/bindings/mmc/sdhci-am654.yaml | 15 ++- > .../pci/socionext,uniphier-pcie-ep.yaml | 18 ++-- > .../phy/socionext,uniphier-ahci-phy.yaml | 6 +- > .../devicetree/bindings/phy/ti,omap-usb2.yaml | 20 ++-- > .../pinctrl/actions,s500-pinctrl.yaml | 102 +- > .../bindings/pinctrl/pinctrl-mt8192.yaml | 2 +- > .../pinctrl/qcom,msm8226-pinctrl.yaml | 6 +- > .../pinctrl/toshiba,visconti-pinctrl.yaml | 24 ++--- > .../bindings/power/reset/reboot-mode.yaml | 6 +- > .../power/supply/ingenic,battery.yaml | 8 +- > .../power/supply/summit,smb347-charger.yaml | 16 +-- > .../bindings/riscv/sifive-l2-cache.yaml | 4 +- > .../devicetree/bindings/rng/imx-rng.yaml | 6 +- > .../bindings/serial/fsl-imx-uart.yaml | 34 +++--- > .../bindings/sound/mchp,spdifrx.yaml | 4 +- > .../bindings/sound/mchp,spdiftx.yaml | 4 +- > .../bindings/sound/qcom,lpass-cpu.yaml| 40 +++ > .../devicetree/bindings/timer/arm,sp804.yaml | 12 +-- > .../devicetree/bindings/usb/cdns,usb3.yaml| 4 +- > .../devicetree/bindings/usb/ti,hd3ss3220.yaml | 2 +- > .../devicetree/bindings/w1/fsl-imx-owire.yaml | 8 +- > 33 files changed, 210 insertions(+), 206 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml > index 31f085d8ab13..526bbd63924b 100644 > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml > @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# > title: Toshiba TC358775 DSI to LVDS bridge bindings > > maintainers: > - - Vinay Simha BN > + - Vinay Simha BN > > description: | > This binding supports DSI to LVDS bridge TC358775 > @@ -29,7 +29,7 @@ properties: > >vdd-supply: > maxItems: 1 > -description: 1.2V LVDS Power Supply > +description: 1.2V LVDS Power Supply > >vddio-supply: > maxItems: 1 > @@ -77,13 +77,13 @@ properties: >- port@1 > > required: > - - compatible > - - reg > - - vdd-supply > - - vddio-supply > - - stby-gpios > - - reset-gpios > - - ports > + - compatible > + - reg > + - vdd-supply > + - vddio-supply > + - stby-gpios > + - reset-gpios > + - ports > > examples: > - | > diff --git > a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml > index c60b3bd74337..b2fcec4f22fd 100644 > --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml > @@ -13,9 +13,8 @@ properties: >compatible: > items: >- enum: > -- bananapi,lhr050h41 > -- feixin,k101-im2byl02 > - > + - bananapi,lhr050h41 > + - feixin,k101-im2byl02 >- const: ilitek,ili9881c > >backlight: true > diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml > b/Documentation/devicetree/bindings/eeprom/at25.yaml > index 9810619a2b5c..744973637678 100644 > --- a/Documentation/devicetree/bindings/eeprom/at25.yaml > +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml > @@ -81,14 +81,14 @@ properties: >at25,byte-len: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > -
