Re: [PATCH v11 00/24] drm/rockchip: RK356x VOP2 support

From: Peter Geis <pgwipeout@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Maya Matuszczyk <maccraft123mc@gmail.com>,
	Heiko Stuebner <heiko@sntech.de>,
	dri-devel@lists.freedesktop.org,
	 arm-mail-list <linux-arm-kernel@lists.infradead.org>,
	 "open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	 devicetree <devicetree@vger.kernel.org>,
	kernel@pengutronix.de,  Andy Yan <andy.yan@rock-chips.com>,
	 Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	 Michael Riesch <michael.riesch@wolfvision.net>,
	Sandy Huang <hjc@rock-chips.com>
Subject: Re: [PATCH v11 00/24] drm/rockchip: RK356x VOP2 support
Date: Fri, 20 May 2022 07:56:24 -0400	[thread overview]
Message-ID: <CAMdYzYrcku+F048macOcedQ-pVo+GMC+5iwODMhxJXtvY_zZTQ@mail.gmail.com> (raw)
In-Reply-To: <20220520101200.GI25578@pengutronix.de>

On Fri, May 20, 2022 at 6:12 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> Hi Maya,
>
> On Fri, May 20, 2022 at 12:02:33PM +0200, Maya Matuszczyk wrote:
> > Hello,
> >
> > wt., 17 maj 2022 o 20:28 Heiko Stuebner <heiko@sntech.de> napisał(a):
> > >
> > > Am Freitag, 22. April 2022, 09:28:17 CEST schrieb Sascha Hauer:
> > > > It's v11 time. There's only one small change to v10. Discussion seems to
> > > > have settled now. Is there anything left that prevents the series from
> > > > being merged? I'd really like to have it in during the next merge
> > > > window.
> > > >
> > > > This series still depends on:
> > > > drm/rockchip: Refactor IOMMU initialisation (https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html)
> > > > arm64: dts: rockchip: add basic dts for the radxa rock3 model a
> > > >
> > > > Sascha
> > >
> > > I've now picked up everything except the hdmi-rate stuff in some way.
> > > The driver changes will go into 5.19 and the DT-changes into 5.20.
> > >
> > > I'll now move the series out of my focus and would expect further
> > > hdmi rate voodoo to start a new series :-) .
> > >
> > > Thanks to all involved for working on this.
> > > Heiko
> >
> > What do I need besides this patch series, mentioned before IOMMU refactor,
> > and DTS changes for MIPI-DSI support on RK356x?
> > I'm working on mainline kernel support for a a RK3566 board with
> > a DSI display.
>
> Apart from these patches you'll need updates for the DSI. I've pushed
> these once to
> https://git.pengutronix.de/cgit/sha/linux/log/?h=rockchip-vop2-mipi
> Particularly I think you need:
>
> 383ff250345f0 drm: rockchip: dw-mipi-dsi: Call host attach from probe
> e79a16ead833d dw-mipi-dsi-rockchip: increase bandwidth
> ac400bdd8d0cb drm: rockchip: dw-mipi-dsi-rockchip: Add rk3568 support
> b6b7fabbc9fe2 drm: panel-simple: Add init sequence support
> 3c13a030e92f3 arm64: dts: rockchip: rk3568-evb: Add Display support
> 3433935a31675 arm64: dts: rockchip: rk356x: Add dsi nodes
>
> I'm not sure how well these fit onto the current state. I'll likely
> update the branch when the VOP2 has hit mainline after the next merge
> window. I have no plans currently to upstream the DSI bits though.

Yeah DSI needs a bit of love with the merged version. Even updating
the series to the new version we get a null pointer exception:

[    2.304528] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000250
[    2.305311] Mem abort info:
[    2.305563]   ESR = 0x96000005
[    2.305839]   EC = 0x25: DABT (current EL), IL = 32 bits
[    2.306311]   SET = 0, FnV = 0
[    2.306586]   EA = 0, S1PTW = 0
[    2.306868]   FSC = 0x05: level 1 translation fault
[    2.307301] Data abort info:
[    2.307559]   ISV = 0, ISS = 0x00000005
[    2.307926]   CM = 0, WnR = 0
[    2.308197] [0000000000000250] user address but active_mm is swapper
[    2.308763] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[    2.309260] Modules linked in:
[    2.309541] CPU: 0 PID: 51 Comm: kworker/u8:1 Not tainted
5.18.0-rc2-00072-g4d2476a40e3e-dirty #307
[    2.310343] Hardware name: Pine64 RK3566 Quartz64-A Board (DT)
[    2.310862] Workqueue: events_unbound deferred_probe_work_func
[    2.311391] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    2.312010] pc : __drm_crtc_init_with_planes+0x44/0x2d0
[    2.312482] lr : drm_crtc_init_with_planes+0x64/0x94
[    2.312929] sp : ffffffc00aaa3830
[    2.313226] x29: ffffffc00aaa3830 x28: 0000000000000001 x27: ffffffc00aaa38c0
[    2.313866] x26: ffffffc009950fb0 x25: ffffff8100f24080 x24: ffffffc009452748
[    2.314504] x23: ffffffc009950fb0 x22: 0000000000000000 x21: 0000000000000008
[    2.315142] x20: ffffff8100d1e800 x19: ffffff8100f244e8 x18: 00000000fffffffd
[    2.315781] x17: 08000000000000d1 x16: 0800000000000091 x15: 0000000000000020
[    2.316419] x14: 0000000000000000 x13: ffffff8100f24478 x12: ffffff8100f2445d
[    2.317057] x11: ffffffc00aaa3920 x10: ffffffc00aaa3920 x9 : ffffffc008843994
[    2.317694] x8 : ffffffc00aaa3910 x7 : ffffffc00aaa3910 x6 : ffffffc00aaa38c0
[    2.318333] x5 : ffffffc009950fb0 x4 : ffffffc0094522a0 x3 : 0000000000000000
[    2.318970] x2 : 0000000000000008 x1 : ffffff8100f244e8 x0 : ffffff8100d1e800
[    2.319609] Call trace:
[    2.319829]  __drm_crtc_init_with_planes+0x44/0x2d0
[    2.320268]  drm_crtc_init_with_planes+0x64/0x94
[    2.320684]  vop2_bind+0x61c/0x960
[    2.320996]  component_bind_all+0x10c/0x270
[    2.321374]  rockchip_drm_bind+0xc0/0x20c
[    2.321738]  try_to_bring_up_aggregate_device+0x16c/0x1e0
[    2.322221]  __component_add+0xac/0x17c
[    2.322568]  component_add+0x20/0x30
[    2.322890]  dw_mipi_dsi_rockchip_host_attach+0x60/0x11c
[    2.323365]  dw_mipi_dsi_host_attach+0x80/0xd4
[    2.323767]  mipi_dsi_attach+0x34/0x50
[    2.324107]  feiyang_dsi_probe+0x100/0x17c
[    2.324476]  mipi_dsi_drv_probe+0x2c/0x40
[    2.324838]  really_probe.part.0+0xa4/0x2a0
[    2.325215]  __driver_probe_device+0xa0/0x150
[    2.325607]  driver_probe_device+0x48/0x150
[    2.325983]  __device_attach_driver+0xc0/0x130
[    2.326381]  bus_for_each_drv+0x84/0xe0
[    2.326729]  __device_attach+0xe4/0x190
[    2.327075]  device_initial_probe+0x20/0x30
[    2.327451]  bus_probe_device+0xa4/0xb0
[    2.327798]  deferred_probe_work_func+0x94/0xcc
[    2.328204]  process_one_work+0x1dc/0x450
[    2.328569]  worker_thread+0x2d0/0x450
[    2.328909]  kthread+0x100/0x110
[    2.329204]  ret_from_fork+0x10/0x20
[    2.329534] Code: aa0503fa f9002bfb aa0603fb b40000c2 (b9424840)
[    2.330077] ---[ end trace 0000000000000000 ]---

Which equates to:
(gdb) l *__drm_crtc_init_with_planes+0x44
0xffffffc0088436ac is in __drm_crtc_init_with_planes
(drivers/gpu/drm/drm_crtc.c:254).
249                                            const char *name, va_list ap)
250     {
251             struct drm_mode_config *config = &dev->mode_config;
252             int ret;
253
254             WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
255             WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
256
257             /* crtc index is used with 32bit bitmasks */
258             if (WARN_ON(config->num_crtc >= 32))

Of course it's entirely possible I missed something here in my port to
the latest version. But if this is configuration in the device tree it
strikes me as odd that a NPE could be triggered.

>
> Regards,
>  Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel