Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
On Wed, Jun 03, 2020 at 10:16:17AM +0200, Daniel Vetter wrote: > On Tue, Jun 02, 2020 at 08:13:17PM +0300, Laurent Pinchart wrote: > > Hi Daniel, > > > > On Tue, Jun 02, 2020 at 03:12:37PM +0200, Daniel Vetter wrote: > > > On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote: > > > > On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote: > > > > > On 2020-03-09 20:51, Laurent Pinchart wrote: > > > > > > Replace the manual connector implementation based on drm_panel with > > > > > > the > > > > > > drm_panel_bridge helper. This simplifies the mxsfb driver by > > > > > > removing > > > > > > connector-related code, and standardizing all pipeline control > > > > > > operations on bridges. > > > > > > > > > > > > A hack is needed to get hold of the connector, as that's our only > > > > > > source > > > > > > of bus flags and formats for now. As soon as the bridge API > > > > > > provides us > > > > > > with that information this can be fixed. > > > > > > > > > > This seems like a nice simplification. > > > > > > > > > > I gave this a go applied on today's drm-misc-next using a Colibri iMX7 > > > > > (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of > > > > > the simple panel driver. I get this when booting: > > > > > > > > > > [2.976698] [drm] Supports vblank timestamp caching Rev 2 > > > > > (21.10.2013). > > > > > [2.983526] [ cut here ] > > > > > [2.988180] WARNING: CPU: 0 PID: 1 at > > > > > drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28 > > > > > [2.998059] Modules linked in: > > > > > [3.001159] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > > > > 5.6.0-rc5-yocto-standard-01250-ga4ce5db7c9f1 #29 > > > > > [3.010493] Hardware name: Freescale i.MX7 Dual (Device Tree) > > > > > [3.016281] [] (unwind_backtrace) from [] > > > > > (show_stack+0xb/0xc) > > > > > [3.023887] [] (show_stack) from [] > > > > > (dump_stack+0x63/0x70) > > > > > [3.031144] [] (dump_stack) from [] > > > > > (__warn+0x9d/0xb0) > > > > > [3.038047] [] (__warn) from [] > > > > > (warn_slowpath_fmt+0x6b/0x70) > > > > > [3.045564] [] (warn_slowpath_fmt) from [] > > > > > (devm_drm_panel_bridge_add+0x25/0x28) > > > > > [3.054736] [] (devm_drm_panel_bridge_add) from > > > > > [] (mxsfb_probe+0x197/0x2e0) > > > > > [3.063559] [] (mxsfb_probe) from [] > > > > > (platform_drv_probe+0x2d/0x60) > > > > > [3.071598] [] (platform_drv_probe) from [] > > > > > (really_probe+0x1dd/0x330) > > > > > [3.079897] [] (really_probe) from [] > > > > > (driver_probe_device+0x4f/0x154) > > > > > [3.088195] [] (driver_probe_device) from [] > > > > > (device_driver_attach+0x37/0x44) > > > > > [3.097101] [] (device_driver_attach) from [] > > > > > (__driver_attach+0x7b/0xec) > > > > > [3.105660] [] (__driver_attach) from [] > > > > > (bus_for_each_dev+0x3d/0x64) > > > > > [3.113870] [] (bus_for_each_dev) from [] > > > > > (bus_add_driver+0xef/0x160) > > > > > [3.122081] [] (bus_add_driver) from [] > > > > > (driver_register+0x35/0x9c) > > > > > [3.130119] [] (driver_register) from [] > > > > > (do_one_initcall+0x3d/0x1e4) > > > > > [3.138333] [] (do_one_initcall) from [] > > > > > (kernel_init_freeable+0x1b3/0x1fc) > > > > > [3.147069] [] (kernel_init_freeable) from [] > > > > > (kernel_init+0x7/0xd0) > > > > > [3.155194] [] (kernel_init) from [] > > > > > (ret_from_fork+0x11/0x38) > > > > > [3.162789] Exception stack(0xec0e3fb0 to 0xec0e3ff8) > > > > > [3.167862] 3fa0: > > > > > > > > > > [3.176071] 3fc0: > > > > > > > > > > [3.184278] 3fe0: 0013 > > > > > > > > > > [3.191029] ---[ end trace b69e1f44de470959 ]--- > > > > > [3.195671] mxsfb 3073.lcdif: Cannot connect bridge: -19 > > > > > > > > > > Should we maybe use devm_drm_panel_bridge_add_typed? > > > > > > > > As Sam reported, this is caused by the panel not setting connector_type. > > > > We could use devm_drm_panel_bridge_add_typed(), even if I like the > > > > warning as it uncovers the problematic panels and gets them fixed. What > > > > would be your preference ? > > > > > > Adding warnings everywhere is kinda uncool, at least my experience is that > > > if there's too much you get warning overload and train people to ignore > > > them. > > > > > > Imo either hide the wwarning for now, or if it's not too much work, review > > > all the panel drivers and make sure they set the connector type somewhere. > > > > All panel drivers but panel-simple set the connector type. For > > panel-simple, the type is stored in the panel_desc panel description, > > and out of the 123 supported panels, only 48 have a connector type. I've > > just sent a patch to fix this for the 7 DSI panels, so only 68 panels
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
On Tue, Jun 02, 2020 at 08:13:17PM +0300, Laurent Pinchart wrote: > Hi Daniel, > > On Tue, Jun 02, 2020 at 03:12:37PM +0200, Daniel Vetter wrote: > > On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote: > > > On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote: > > > > On 2020-03-09 20:51, Laurent Pinchart wrote: > > > > > Replace the manual connector implementation based on drm_panel with > > > > > the > > > > > drm_panel_bridge helper. This simplifies the mxsfb driver by removing > > > > > connector-related code, and standardizing all pipeline control > > > > > operations on bridges. > > > > > > > > > > A hack is needed to get hold of the connector, as that's our only > > > > > source > > > > > of bus flags and formats for now. As soon as the bridge API provides > > > > > us > > > > > with that information this can be fixed. > > > > > > > > This seems like a nice simplification. > > > > > > > > I gave this a go applied on today's drm-misc-next using a Colibri iMX7 > > > > (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of > > > > the simple panel driver. I get this when booting: > > > > > > > > [2.976698] [drm] Supports vblank timestamp caching Rev 2 > > > > (21.10.2013). > > > > [2.983526] [ cut here ] > > > > [2.988180] WARNING: CPU: 0 PID: 1 at > > > > drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28 > > > > [2.998059] Modules linked in: > > > > [3.001159] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > > > 5.6.0-rc5-yocto-standard-01250-ga4ce5db7c9f1 #29 > > > > [3.010493] Hardware name: Freescale i.MX7 Dual (Device Tree) > > > > [3.016281] [] (unwind_backtrace) from [] > > > > (show_stack+0xb/0xc) > > > > [3.023887] [] (show_stack) from [] > > > > (dump_stack+0x63/0x70) > > > > [3.031144] [] (dump_stack) from [] > > > > (__warn+0x9d/0xb0) > > > > [3.038047] [] (__warn) from [] > > > > (warn_slowpath_fmt+0x6b/0x70) > > > > [3.045564] [] (warn_slowpath_fmt) from [] > > > > (devm_drm_panel_bridge_add+0x25/0x28) > > > > [3.054736] [] (devm_drm_panel_bridge_add) from > > > > [] (mxsfb_probe+0x197/0x2e0) > > > > [3.063559] [] (mxsfb_probe) from [] > > > > (platform_drv_probe+0x2d/0x60) > > > > [3.071598] [] (platform_drv_probe) from [] > > > > (really_probe+0x1dd/0x330) > > > > [3.079897] [] (really_probe) from [] > > > > (driver_probe_device+0x4f/0x154) > > > > [3.088195] [] (driver_probe_device) from [] > > > > (device_driver_attach+0x37/0x44) > > > > [3.097101] [] (device_driver_attach) from [] > > > > (__driver_attach+0x7b/0xec) > > > > [3.105660] [] (__driver_attach) from [] > > > > (bus_for_each_dev+0x3d/0x64) > > > > [3.113870] [] (bus_for_each_dev) from [] > > > > (bus_add_driver+0xef/0x160) > > > > [3.122081] [] (bus_add_driver) from [] > > > > (driver_register+0x35/0x9c) > > > > [3.130119] [] (driver_register) from [] > > > > (do_one_initcall+0x3d/0x1e4) > > > > [3.138333] [] (do_one_initcall) from [] > > > > (kernel_init_freeable+0x1b3/0x1fc) > > > > [3.147069] [] (kernel_init_freeable) from [] > > > > (kernel_init+0x7/0xd0) > > > > [3.155194] [] (kernel_init) from [] > > > > (ret_from_fork+0x11/0x38) > > > > [3.162789] Exception stack(0xec0e3fb0 to 0xec0e3ff8) > > > > [3.167862] 3fa0: > > > > > > > > [3.176071] 3fc0: > > > > > > > > [3.184278] 3fe0: 0013 > > > > > > > > [3.191029] ---[ end trace b69e1f44de470959 ]--- > > > > [3.195671] mxsfb 3073.lcdif: Cannot connect bridge: -19 > > > > > > > > Should we maybe use devm_drm_panel_bridge_add_typed? > > > > > > As Sam reported, this is caused by the panel not setting connector_type. > > > We could use devm_drm_panel_bridge_add_typed(), even if I like the > > > warning as it uncovers the problematic panels and gets them fixed. What > > > would be your preference ? > > > > Adding warnings everywhere is kinda uncool, at least my experience is that > > if there's too much you get warning overload and train people to ignore > > them. > > > > Imo either hide the wwarning for now, or if it's not too much work, review > > all the panel drivers and make sure they set the connector type somewhere. > > All panel drivers but panel-simple set the connector type. For > panel-simple, the type is stored in the panel_desc panel description, > and out of the 123 supported panels, only 48 have a connector type. I've > just sent a patch to fix this for the 7 DSI panels, so only 68 panels to > go :-) This will require trying to find the corresponding datasheets, so > that's a large effort for a single developer. That's why I was hoping a > WARN_ON() could help distributing the work :-) I hear your concern > though, and I'll set a default in this driver for
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
Hi Stefan, On Tue, Jun 02, 2020 at 04:34:07PM +0200, Stefan Agner wrote: > On 2020-06-02 15:12, Daniel Vetter wrote: > > On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote: > >> On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote: > >>> On 2020-03-09 20:51, Laurent Pinchart wrote: > Replace the manual connector implementation based on drm_panel with the > drm_panel_bridge helper. This simplifies the mxsfb driver by removing > connector-related code, and standardizing all pipeline control > operations on bridges. > > A hack is needed to get hold of the connector, as that's our only source > of bus flags and formats for now. As soon as the bridge API provides us > with that information this can be fixed. > >>> > >>> This seems like a nice simplification. > >>> > >>> I gave this a go applied on today's drm-misc-next using a Colibri iMX7 > >>> (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of > >>> the simple panel driver. I get this when booting: > >>> > >>> [2.976698] [drm] Supports vblank timestamp caching Rev 2 > >>> (21.10.2013). > >>> [2.983526] [ cut here ] > >>> [2.988180] WARNING: CPU: 0 PID: 1 at > >>> drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28 > >>> [2.998059] Modules linked in: > >>> [3.001159] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > >>> 5.6.0-rc5-yocto-standard-01250-ga4ce5db7c9f1 #29 > >>> [3.010493] Hardware name: Freescale i.MX7 Dual (Device Tree) > >>> [3.016281] [] (unwind_backtrace) from [] > >>> (show_stack+0xb/0xc) > >>> [3.023887] [] (show_stack) from [] > >>> (dump_stack+0x63/0x70) > >>> [3.031144] [] (dump_stack) from [] > >>> (__warn+0x9d/0xb0) > >>> [3.038047] [] (__warn) from [] > >>> (warn_slowpath_fmt+0x6b/0x70) > >>> [3.045564] [] (warn_slowpath_fmt) from [] > >>> (devm_drm_panel_bridge_add+0x25/0x28) > >>> [3.054736] [] (devm_drm_panel_bridge_add) from > >>> [] (mxsfb_probe+0x197/0x2e0) > >>> [3.063559] [] (mxsfb_probe) from [] > >>> (platform_drv_probe+0x2d/0x60) > >>> [3.071598] [] (platform_drv_probe) from [] > >>> (really_probe+0x1dd/0x330) > >>> [3.079897] [] (really_probe) from [] > >>> (driver_probe_device+0x4f/0x154) > >>> [3.088195] [] (driver_probe_device) from [] > >>> (device_driver_attach+0x37/0x44) > >>> [3.097101] [] (device_driver_attach) from [] > >>> (__driver_attach+0x7b/0xec) > >>> [3.105660] [] (__driver_attach) from [] > >>> (bus_for_each_dev+0x3d/0x64) > >>> [3.113870] [] (bus_for_each_dev) from [] > >>> (bus_add_driver+0xef/0x160) > >>> [3.122081] [] (bus_add_driver) from [] > >>> (driver_register+0x35/0x9c) > >>> [3.130119] [] (driver_register) from [] > >>> (do_one_initcall+0x3d/0x1e4) > >>> [3.138333] [] (do_one_initcall) from [] > >>> (kernel_init_freeable+0x1b3/0x1fc) > >>> [3.147069] [] (kernel_init_freeable) from [] > >>> (kernel_init+0x7/0xd0) > >>> [3.155194] [] (kernel_init) from [] > >>> (ret_from_fork+0x11/0x38) > >>> [3.162789] Exception stack(0xec0e3fb0 to 0xec0e3ff8) > >>> [3.167862] 3fa0: > >>> > >>> [3.176071] 3fc0: > >>> > >>> [3.184278] 3fe0: 0013 > >>> > >>> [3.191029] ---[ end trace b69e1f44de470959 ]--- > >>> [3.195671] mxsfb 3073.lcdif: Cannot connect bridge: -19 > >>> > >>> Should we maybe use devm_drm_panel_bridge_add_typed? > >> > >> As Sam reported, this is caused by the panel not setting connector_type. > >> We could use devm_drm_panel_bridge_add_typed(), even if I like the > >> warning as it uncovers the problematic panels and gets them fixed. What > >> would be your preference ? > > > > Adding warnings everywhere is kinda uncool, at least my experience is that > > if there's too much you get warning overload and train people to ignore > > them. > > > > Imo either hide the wwarning for now, or if it's not too much work, review > > all the panel drivers and make sure they set the connector type somewhere. > > Warnings are kinda ok once you're pretty sure you got them all, and want > > to make sure newly added drivers get this all right. But not before we've > > reached that. > > I am with Daniel on this, too many warnings make users blind of them, so > we should save them when really attention is needed. > > I guess the only question which connector type we should default to. I > think DRM_MODE_CONNECTOR_DPI make sense for this IP. Yes, that makes sense. I'll fix this in v3, but will wait until you review the remaining patches from v2 before sending v3 out. > >>> Two more comments below. > >>> > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/mxsfb/Makefile| 2 +- > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 105 ++ >
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
Hi Daniel, On Tue, Jun 02, 2020 at 03:12:37PM +0200, Daniel Vetter wrote: > On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote: > > On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote: > > > On 2020-03-09 20:51, Laurent Pinchart wrote: > > > > Replace the manual connector implementation based on drm_panel with the > > > > drm_panel_bridge helper. This simplifies the mxsfb driver by removing > > > > connector-related code, and standardizing all pipeline control > > > > operations on bridges. > > > > > > > > A hack is needed to get hold of the connector, as that's our only source > > > > of bus flags and formats for now. As soon as the bridge API provides us > > > > with that information this can be fixed. > > > > > > This seems like a nice simplification. > > > > > > I gave this a go applied on today's drm-misc-next using a Colibri iMX7 > > > (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of > > > the simple panel driver. I get this when booting: > > > > > > [2.976698] [drm] Supports vblank timestamp caching Rev 2 > > > (21.10.2013). > > > [2.983526] [ cut here ] > > > [2.988180] WARNING: CPU: 0 PID: 1 at > > > drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28 > > > [2.998059] Modules linked in: > > > [3.001159] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > > 5.6.0-rc5-yocto-standard-01250-ga4ce5db7c9f1 #29 > > > [3.010493] Hardware name: Freescale i.MX7 Dual (Device Tree) > > > [3.016281] [] (unwind_backtrace) from [] > > > (show_stack+0xb/0xc) > > > [3.023887] [] (show_stack) from [] > > > (dump_stack+0x63/0x70) > > > [3.031144] [] (dump_stack) from [] > > > (__warn+0x9d/0xb0) > > > [3.038047] [] (__warn) from [] > > > (warn_slowpath_fmt+0x6b/0x70) > > > [3.045564] [] (warn_slowpath_fmt) from [] > > > (devm_drm_panel_bridge_add+0x25/0x28) > > > [3.054736] [] (devm_drm_panel_bridge_add) from > > > [] (mxsfb_probe+0x197/0x2e0) > > > [3.063559] [] (mxsfb_probe) from [] > > > (platform_drv_probe+0x2d/0x60) > > > [3.071598] [] (platform_drv_probe) from [] > > > (really_probe+0x1dd/0x330) > > > [3.079897] [] (really_probe) from [] > > > (driver_probe_device+0x4f/0x154) > > > [3.088195] [] (driver_probe_device) from [] > > > (device_driver_attach+0x37/0x44) > > > [3.097101] [] (device_driver_attach) from [] > > > (__driver_attach+0x7b/0xec) > > > [3.105660] [] (__driver_attach) from [] > > > (bus_for_each_dev+0x3d/0x64) > > > [3.113870] [] (bus_for_each_dev) from [] > > > (bus_add_driver+0xef/0x160) > > > [3.122081] [] (bus_add_driver) from [] > > > (driver_register+0x35/0x9c) > > > [3.130119] [] (driver_register) from [] > > > (do_one_initcall+0x3d/0x1e4) > > > [3.138333] [] (do_one_initcall) from [] > > > (kernel_init_freeable+0x1b3/0x1fc) > > > [3.147069] [] (kernel_init_freeable) from [] > > > (kernel_init+0x7/0xd0) > > > [3.155194] [] (kernel_init) from [] > > > (ret_from_fork+0x11/0x38) > > > [3.162789] Exception stack(0xec0e3fb0 to 0xec0e3ff8) > > > [3.167862] 3fa0: > > > > > > [3.176071] 3fc0: > > > > > > [3.184278] 3fe0: 0013 > > > > > > [3.191029] ---[ end trace b69e1f44de470959 ]--- > > > [3.195671] mxsfb 3073.lcdif: Cannot connect bridge: -19 > > > > > > Should we maybe use devm_drm_panel_bridge_add_typed? > > > > As Sam reported, this is caused by the panel not setting connector_type. > > We could use devm_drm_panel_bridge_add_typed(), even if I like the > > warning as it uncovers the problematic panels and gets them fixed. What > > would be your preference ? > > Adding warnings everywhere is kinda uncool, at least my experience is that > if there's too much you get warning overload and train people to ignore > them. > > Imo either hide the wwarning for now, or if it's not too much work, review > all the panel drivers and make sure they set the connector type somewhere. All panel drivers but panel-simple set the connector type. For panel-simple, the type is stored in the panel_desc panel description, and out of the 123 supported panels, only 48 have a connector type. I've just sent a patch to fix this for the 7 DSI panels, so only 68 panels to go :-) This will require trying to find the corresponding datasheets, so that's a large effort for a single developer. That's why I was hoping a WARN_ON() could help distributing the work :-) I hear your concern though, and I'll set a default in this driver for the time being. > Warnings are kinda ok once you're pretty sure you got them all, and want > to make sure newly added drivers get this all right. But not before we've > reached that. > > > > Two more comments below. > > > > > > > Signed-off-by: Laurent Pinchart > > > > --- > > > >
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
On 2020-06-02 15:12, Daniel Vetter wrote: > On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote: >> Hi Stefan, >> >> On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote: >> > On 2020-03-09 20:51, Laurent Pinchart wrote: >> > > Replace the manual connector implementation based on drm_panel with the >> > > drm_panel_bridge helper. This simplifies the mxsfb driver by removing >> > > connector-related code, and standardizing all pipeline control >> > > operations on bridges. >> > > >> > > A hack is needed to get hold of the connector, as that's our only source >> > > of bus flags and formats for now. As soon as the bridge API provides us >> > > with that information this can be fixed. >> > >> > This seems like a nice simplification. >> > >> > I gave this a go applied on today's drm-misc-next using a Colibri iMX7 >> > (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of >> > the simple panel driver. I get this when booting: >> > >> > [2.976698] [drm] Supports vblank timestamp caching Rev 2 >> > (21.10.2013). >> > [2.983526] [ cut here ] >> > [2.988180] WARNING: CPU: 0 PID: 1 at >> > drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28 >> > [2.998059] Modules linked in: >> > [3.001159] CPU: 0 PID: 1 Comm: swapper/0 Not tainted >> > 5.6.0-rc5-yocto-standard-01250-ga4ce5db7c9f1 #29 >> > [3.010493] Hardware name: Freescale i.MX7 Dual (Device Tree) >> > [3.016281] [] (unwind_backtrace) from [] >> > (show_stack+0xb/0xc) >> > [3.023887] [] (show_stack) from [] >> > (dump_stack+0x63/0x70) >> > [3.031144] [] (dump_stack) from [] >> > (__warn+0x9d/0xb0) >> > [3.038047] [] (__warn) from [] >> > (warn_slowpath_fmt+0x6b/0x70) >> > [3.045564] [] (warn_slowpath_fmt) from [] >> > (devm_drm_panel_bridge_add+0x25/0x28) >> > [3.054736] [] (devm_drm_panel_bridge_add) from >> > [] (mxsfb_probe+0x197/0x2e0) >> > [3.063559] [] (mxsfb_probe) from [] >> > (platform_drv_probe+0x2d/0x60) >> > [3.071598] [] (platform_drv_probe) from [] >> > (really_probe+0x1dd/0x330) >> > [3.079897] [] (really_probe) from [] >> > (driver_probe_device+0x4f/0x154) >> > [3.088195] [] (driver_probe_device) from [] >> > (device_driver_attach+0x37/0x44) >> > [3.097101] [] (device_driver_attach) from [] >> > (__driver_attach+0x7b/0xec) >> > [3.105660] [] (__driver_attach) from [] >> > (bus_for_each_dev+0x3d/0x64) >> > [3.113870] [] (bus_for_each_dev) from [] >> > (bus_add_driver+0xef/0x160) >> > [3.122081] [] (bus_add_driver) from [] >> > (driver_register+0x35/0x9c) >> > [3.130119] [] (driver_register) from [] >> > (do_one_initcall+0x3d/0x1e4) >> > [3.138333] [] (do_one_initcall) from [] >> > (kernel_init_freeable+0x1b3/0x1fc) >> > [3.147069] [] (kernel_init_freeable) from [] >> > (kernel_init+0x7/0xd0) >> > [3.155194] [] (kernel_init) from [] >> > (ret_from_fork+0x11/0x38) >> > [3.162789] Exception stack(0xec0e3fb0 to 0xec0e3ff8) >> > [3.167862] 3fa0: >> > >> > [3.176071] 3fc0: >> > >> > [3.184278] 3fe0: 0013 >> > >> > [3.191029] ---[ end trace b69e1f44de470959 ]--- >> > [3.195671] mxsfb 3073.lcdif: Cannot connect bridge: -19 >> > >> > Should we maybe use devm_drm_panel_bridge_add_typed? >> >> As Sam reported, this is caused by the panel not setting connector_type. >> We could use devm_drm_panel_bridge_add_typed(), even if I like the >> warning as it uncovers the problematic panels and gets them fixed. What >> would be your preference ? > > Adding warnings everywhere is kinda uncool, at least my experience is that > if there's too much you get warning overload and train people to ignore > them. > > Imo either hide the wwarning for now, or if it's not too much work, review > all the panel drivers and make sure they set the connector type somewhere. > Warnings are kinda ok once you're pretty sure you got them all, and want > to make sure newly added drivers get this all right. But not before we've > reached that. I am with Daniel on this, too many warnings make users blind of them, so we should save them when really attention is needed. I guess the only question which connector type we should default to. I think DRM_MODE_CONNECTOR_DPI make sense for this IP. -- Stefan > > Cheers, Daniel > >> >> > Two more comments below. >> > >> > > Signed-off-by: Laurent Pinchart >> > > --- >> > > drivers/gpu/drm/mxsfb/Makefile| 2 +- >> > > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 105 ++ >> > > drivers/gpu/drm/mxsfb/mxsfb_drv.h | 5 +- >> > > drivers/gpu/drm/mxsfb/mxsfb_out.c | 99 >> > > 4 files changed, 53 insertions(+), 158 deletions(-) >> > > delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_out.c >> > > >> > >
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote: > Hi Stefan, > > On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote: > > On 2020-03-09 20:51, Laurent Pinchart wrote: > > > Replace the manual connector implementation based on drm_panel with the > > > drm_panel_bridge helper. This simplifies the mxsfb driver by removing > > > connector-related code, and standardizing all pipeline control > > > operations on bridges. > > > > > > A hack is needed to get hold of the connector, as that's our only source > > > of bus flags and formats for now. As soon as the bridge API provides us > > > with that information this can be fixed. > > > > This seems like a nice simplification. > > > > I gave this a go applied on today's drm-misc-next using a Colibri iMX7 > > (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of > > the simple panel driver. I get this when booting: > > > > [2.976698] [drm] Supports vblank timestamp caching Rev 2 > > (21.10.2013). > > [2.983526] [ cut here ] > > [2.988180] WARNING: CPU: 0 PID: 1 at > > drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28 > > [2.998059] Modules linked in: > > [3.001159] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > 5.6.0-rc5-yocto-standard-01250-ga4ce5db7c9f1 #29 > > [3.010493] Hardware name: Freescale i.MX7 Dual (Device Tree) > > [3.016281] [] (unwind_backtrace) from [] > > (show_stack+0xb/0xc) > > [3.023887] [] (show_stack) from [] > > (dump_stack+0x63/0x70) > > [3.031144] [] (dump_stack) from [] > > (__warn+0x9d/0xb0) > > [3.038047] [] (__warn) from [] > > (warn_slowpath_fmt+0x6b/0x70) > > [3.045564] [] (warn_slowpath_fmt) from [] > > (devm_drm_panel_bridge_add+0x25/0x28) > > [3.054736] [] (devm_drm_panel_bridge_add) from > > [] (mxsfb_probe+0x197/0x2e0) > > [3.063559] [] (mxsfb_probe) from [] > > (platform_drv_probe+0x2d/0x60) > > [3.071598] [] (platform_drv_probe) from [] > > (really_probe+0x1dd/0x330) > > [3.079897] [] (really_probe) from [] > > (driver_probe_device+0x4f/0x154) > > [3.088195] [] (driver_probe_device) from [] > > (device_driver_attach+0x37/0x44) > > [3.097101] [] (device_driver_attach) from [] > > (__driver_attach+0x7b/0xec) > > [3.105660] [] (__driver_attach) from [] > > (bus_for_each_dev+0x3d/0x64) > > [3.113870] [] (bus_for_each_dev) from [] > > (bus_add_driver+0xef/0x160) > > [3.122081] [] (bus_add_driver) from [] > > (driver_register+0x35/0x9c) > > [3.130119] [] (driver_register) from [] > > (do_one_initcall+0x3d/0x1e4) > > [3.138333] [] (do_one_initcall) from [] > > (kernel_init_freeable+0x1b3/0x1fc) > > [3.147069] [] (kernel_init_freeable) from [] > > (kernel_init+0x7/0xd0) > > [3.155194] [] (kernel_init) from [] > > (ret_from_fork+0x11/0x38) > > [3.162789] Exception stack(0xec0e3fb0 to 0xec0e3ff8) > > [3.167862] 3fa0: > > > > [3.176071] 3fc0: > > > > [3.184278] 3fe0: 0013 > > > > [3.191029] ---[ end trace b69e1f44de470959 ]--- > > [3.195671] mxsfb 3073.lcdif: Cannot connect bridge: -19 > > > > Should we maybe use devm_drm_panel_bridge_add_typed? > > As Sam reported, this is caused by the panel not setting connector_type. > We could use devm_drm_panel_bridge_add_typed(), even if I like the > warning as it uncovers the problematic panels and gets them fixed. What > would be your preference ? Adding warnings everywhere is kinda uncool, at least my experience is that if there's too much you get warning overload and train people to ignore them. Imo either hide the wwarning for now, or if it's not too much work, review all the panel drivers and make sure they set the connector type somewhere. Warnings are kinda ok once you're pretty sure you got them all, and want to make sure newly added drivers get this all right. But not before we've reached that. Cheers, Daniel > > > Two more comments below. > > > > > Signed-off-by: Laurent Pinchart > > > --- > > > drivers/gpu/drm/mxsfb/Makefile| 2 +- > > > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 105 ++ > > > drivers/gpu/drm/mxsfb/mxsfb_drv.h | 5 +- > > > drivers/gpu/drm/mxsfb/mxsfb_out.c | 99 > > > 4 files changed, 53 insertions(+), 158 deletions(-) > > > delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_out.c > > > > > > diff --git a/drivers/gpu/drm/mxsfb/Makefile > > > b/drivers/gpu/drm/mxsfb/Makefile > > > index ff6e358088fa..811584e54ad1 100644 > > > --- a/drivers/gpu/drm/mxsfb/Makefile > > > +++ b/drivers/gpu/drm/mxsfb/Makefile > > > @@ -1,3 +1,3 @@ > > > # SPDX-License-Identifier: GPL-2.0-only > > > -mxsfb-y := mxsfb_drv.o mxsfb_crtc.o mxsfb_out.o > > > +mxsfb-y := mxsfb_drv.o mxsfb_crtc.o > > > obj-$(CONFIG_DRM_MXSFB) +=
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
Hi Stefan,
On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote:
> On 2020-03-09 20:51, Laurent Pinchart wrote:
> > Replace the manual connector implementation based on drm_panel with the
> > drm_panel_bridge helper. This simplifies the mxsfb driver by removing
> > connector-related code, and standardizing all pipeline control
> > operations on bridges.
> >
> > A hack is needed to get hold of the connector, as that's our only source
> > of bus flags and formats for now. As soon as the bridge API provides us
> > with that information this can be fixed.
>
> This seems like a nice simplification.
>
> I gave this a go applied on today's drm-misc-next using a Colibri iMX7
> (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of
> the simple panel driver. I get this when booting:
>
> [2.976698] [drm] Supports vblank timestamp caching Rev 2
> (21.10.2013).
> [2.983526] [ cut here ]
> [2.988180] WARNING: CPU: 0 PID: 1 at
> drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28
> [2.998059] Modules linked in:
> [3.001159] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 5.6.0-rc5-yocto-standard-01250-ga4ce5db7c9f1 #29
> [3.010493] Hardware name: Freescale i.MX7 Dual (Device Tree)
> [3.016281] [] (unwind_backtrace) from []
> (show_stack+0xb/0xc)
> [3.023887] [] (show_stack) from []
> (dump_stack+0x63/0x70)
> [3.031144] [] (dump_stack) from []
> (__warn+0x9d/0xb0)
> [3.038047] [] (__warn) from []
> (warn_slowpath_fmt+0x6b/0x70)
> [3.045564] [] (warn_slowpath_fmt) from []
> (devm_drm_panel_bridge_add+0x25/0x28)
> [3.054736] [] (devm_drm_panel_bridge_add) from
> [] (mxsfb_probe+0x197/0x2e0)
> [3.063559] [] (mxsfb_probe) from []
> (platform_drv_probe+0x2d/0x60)
> [3.071598] [] (platform_drv_probe) from []
> (really_probe+0x1dd/0x330)
> [3.079897] [] (really_probe) from []
> (driver_probe_device+0x4f/0x154)
> [3.088195] [] (driver_probe_device) from []
> (device_driver_attach+0x37/0x44)
> [3.097101] [] (device_driver_attach) from []
> (__driver_attach+0x7b/0xec)
> [3.105660] [] (__driver_attach) from []
> (bus_for_each_dev+0x3d/0x64)
> [3.113870] [] (bus_for_each_dev) from []
> (bus_add_driver+0xef/0x160)
> [3.122081] [] (bus_add_driver) from []
> (driver_register+0x35/0x9c)
> [3.130119] [] (driver_register) from []
> (do_one_initcall+0x3d/0x1e4)
> [3.138333] [] (do_one_initcall) from []
> (kernel_init_freeable+0x1b3/0x1fc)
> [3.147069] [] (kernel_init_freeable) from []
> (kernel_init+0x7/0xd0)
> [3.155194] [] (kernel_init) from []
> (ret_from_fork+0x11/0x38)
> [3.162789] Exception stack(0xec0e3fb0 to 0xec0e3ff8)
> [3.167862] 3fa0:
>
> [3.176071] 3fc0:
>
> [3.184278] 3fe0: 0013
>
> [3.191029] ---[ end trace b69e1f44de470959 ]---
> [3.195671] mxsfb 3073.lcdif: Cannot connect bridge: -19
>
> Should we maybe use devm_drm_panel_bridge_add_typed?
As Sam reported, this is caused by the panel not setting connector_type.
We could use devm_drm_panel_bridge_add_typed(), even if I like the
warning as it uncovers the problematic panels and gets them fixed. What
would be your preference ?
> Two more comments below.
>
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/mxsfb/Makefile| 2 +-
> > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 105 ++
> > drivers/gpu/drm/mxsfb/mxsfb_drv.h | 5 +-
> > drivers/gpu/drm/mxsfb/mxsfb_out.c | 99
> > 4 files changed, 53 insertions(+), 158 deletions(-)
> > delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_out.c
> >
> > diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
> > index ff6e358088fa..811584e54ad1 100644
> > --- a/drivers/gpu/drm/mxsfb/Makefile
> > +++ b/drivers/gpu/drm/mxsfb/Makefile
> > @@ -1,3 +1,3 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > -mxsfb-y := mxsfb_drv.o mxsfb_crtc.o mxsfb_out.o
> > +mxsfb-y := mxsfb_drv.o mxsfb_crtc.o
> > obj-$(CONFIG_DRM_MXSFB)+= mxsfb.o
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > index 2e6068d96034..cffc70257bd3 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > @@ -29,7 +29,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -100,29 +99,11 @@ static void mxsfb_pipe_enable(struct
> > drm_simple_display_pipe *pipe,
> > struct drm_crtc_state *crtc_state,
> > struct drm_plane_state *plane_state)
> > {
> > - struct drm_connector *connector;
> > struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
> > struct drm_device *drm =
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
On 2020-03-23 22:38, Sam Ravnborg wrote: > Hi Stefan. > > On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote: >> On 2020-03-09 20:51, Laurent Pinchart wrote: >> > Replace the manual connector implementation based on drm_panel with the >> > drm_panel_bridge helper. This simplifies the mxsfb driver by removing >> > connector-related code, and standardizing all pipeline control >> > operations on bridges. >> > >> > A hack is needed to get hold of the connector, as that's our only source >> > of bus flags and formats for now. As soon as the bridge API provides us >> > with that information this can be fixed. >> >> This seems like a nice simplification. >> >> I gave this a go applied on today's drm-misc-next using a Colibri iMX7 >> (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of >> the simple panel driver. I get this when booting: >> >> [2.976698] [drm] Supports vblank timestamp caching Rev 2 >> (21.10.2013). >> [2.983526] [ cut here ] >> [2.988180] WARNING: CPU: 0 PID: 1 at >> drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28 > > ... > > I think you hit one of the panels that does not yet specify a > connector_type. > > If this is the case, we should fix the definition in panel-simple. Yes, this indeed the case, I used the "logictechno,lt161010-2nhc" compatible string. Will get this fixed! But I think its still worth defining a default in the driver as DPI is what this IP outputs... -- Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
Hi Stefan. On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote: > On 2020-03-09 20:51, Laurent Pinchart wrote: > > Replace the manual connector implementation based on drm_panel with the > > drm_panel_bridge helper. This simplifies the mxsfb driver by removing > > connector-related code, and standardizing all pipeline control > > operations on bridges. > > > > A hack is needed to get hold of the connector, as that's our only source > > of bus flags and formats for now. As soon as the bridge API provides us > > with that information this can be fixed. > > This seems like a nice simplification. > > I gave this a go applied on today's drm-misc-next using a Colibri iMX7 > (imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of > the simple panel driver. I get this when booting: > > [2.976698] [drm] Supports vblank timestamp caching Rev 2 > (21.10.2013). > [2.983526] [ cut here ] > [2.988180] WARNING: CPU: 0 PID: 1 at > drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28 ... I think you hit one of the panels that does not yet specify a connector_type. If this is the case, we should fix the definition in panel-simple. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/21] drm: mxsfb: Use drm_panel_bridge
On 2020-03-09 20:51, Laurent Pinchart wrote:
> Replace the manual connector implementation based on drm_panel with the
> drm_panel_bridge helper. This simplifies the mxsfb driver by removing
> connector-related code, and standardizing all pipeline control
> operations on bridges.
>
> A hack is needed to get hold of the connector, as that's our only source
> of bus flags and formats for now. As soon as the bridge API provides us
> with that information this can be fixed.
This seems like a nice simplification.
I gave this a go applied on today's drm-misc-next using a Colibri iMX7
(imx7d-colibri-emmc-eval-v3.dts device tree). This device makes use of
the simple panel driver. I get this when booting:
[2.976698] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
[2.983526] [ cut here ]
[2.988180] WARNING: CPU: 0 PID: 1 at
drivers/gpu/drm/bridge/panel.c:267 devm_drm_panel_bridge_add+0x25/0x28
[2.998059] Modules linked in:
[3.001159] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.6.0-rc5-yocto-standard-01250-ga4ce5db7c9f1 #29
[3.010493] Hardware name: Freescale i.MX7 Dual (Device Tree)
[3.016281] [] (unwind_backtrace) from []
(show_stack+0xb/0xc)
[3.023887] [] (show_stack) from []
(dump_stack+0x63/0x70)
[3.031144] [] (dump_stack) from []
(__warn+0x9d/0xb0)
[3.038047] [] (__warn) from []
(warn_slowpath_fmt+0x6b/0x70)
[3.045564] [] (warn_slowpath_fmt) from []
(devm_drm_panel_bridge_add+0x25/0x28)
[3.054736] [] (devm_drm_panel_bridge_add) from
[] (mxsfb_probe+0x197/0x2e0)
[3.063559] [] (mxsfb_probe) from []
(platform_drv_probe+0x2d/0x60)
[3.071598] [] (platform_drv_probe) from []
(really_probe+0x1dd/0x330)
[3.079897] [] (really_probe) from []
(driver_probe_device+0x4f/0x154)
[3.088195] [] (driver_probe_device) from []
(device_driver_attach+0x37/0x44)
[3.097101] [] (device_driver_attach) from []
(__driver_attach+0x7b/0xec)
[3.105660] [] (__driver_attach) from []
(bus_for_each_dev+0x3d/0x64)
[3.113870] [] (bus_for_each_dev) from []
(bus_add_driver+0xef/0x160)
[3.122081] [] (bus_add_driver) from []
(driver_register+0x35/0x9c)
[3.130119] [] (driver_register) from []
(do_one_initcall+0x3d/0x1e4)
[3.138333] [] (do_one_initcall) from []
(kernel_init_freeable+0x1b3/0x1fc)
[3.147069] [] (kernel_init_freeable) from []
(kernel_init+0x7/0xd0)
[3.155194] [] (kernel_init) from []
(ret_from_fork+0x11/0x38)
[3.162789] Exception stack(0xec0e3fb0 to 0xec0e3ff8)
[3.167862] 3fa0:
[3.176071] 3fc0:
[3.184278] 3fe0: 0013
[3.191029] ---[ end trace b69e1f44de470959 ]---
[3.195671] mxsfb 3073.lcdif: Cannot connect bridge: -19
Should we maybe use devm_drm_panel_bridge_add_typed?
Two more comments below.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/mxsfb/Makefile| 2 +-
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 105 ++
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 5 +-
> drivers/gpu/drm/mxsfb/mxsfb_out.c | 99
> 4 files changed, 53 insertions(+), 158 deletions(-)
> delete mode 100644 drivers/gpu/drm/mxsfb/mxsfb_out.c
>
> diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
> index ff6e358088fa..811584e54ad1 100644
> --- a/drivers/gpu/drm/mxsfb/Makefile
> +++ b/drivers/gpu/drm/mxsfb/Makefile
> @@ -1,3 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -mxsfb-y := mxsfb_drv.o mxsfb_crtc.o mxsfb_out.o
> +mxsfb-y := mxsfb_drv.o mxsfb_crtc.o
> obj-$(CONFIG_DRM_MXSFB) += mxsfb.o
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 2e6068d96034..cffc70257bd3 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -29,7 +29,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -100,29 +99,11 @@ static void mxsfb_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> struct drm_crtc_state *crtc_state,
> struct drm_plane_state *plane_state)
> {
> - struct drm_connector *connector;
> struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
> struct drm_device *drm = pipe->plane.dev;
>
> - if (!mxsfb->connector) {
> - list_for_each_entry(connector,
> - >mode_config.connector_list,
> - head)
> - if (connector->encoder == >pipe.encoder) {
> - mxsfb->connector = connector;
> - break;
> - }
> - }
> -
> - if (!mxsfb->connector) {
> - dev_warn(drm->dev, "No connector attached, using default\n");
> -
