| Message ID | 20201016103917.26838-1-nikhil.nd@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/tidss: Use new connector model for tidss | expand |
Hi Nikhil, On 16/10/2020 13:39, Nikhil Devshatwar wrote: > This series moves the tidss to using new connectoe model, where the > SoC driver (tidss) creates the connector and all the bridges are > attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR > > Since the bridges do not create the connector, the bus format and > bus_flag is set after the format negotiation. > Support format negotiations in the tfp410 and mhdp bridge drivers. > > Nikhil Devshatwar (5): > drm/tidss: Move to newer connector model > drm/tidss: Set bus_format correctly from bridge/connector > drm: bridge: Propagate the bus flags from bridge->timings > drm/bridge: tfp410: Support format negotiation > drm/bridge: mhdp8564: Support format negotiation I think the patch order could be a bit different. If you first change the tidss to use the new connector model, and only afterwards fix the bridges we use, then there's a time when the displays won't work. Also, with J7 EVM and DP, when I unload the modules I see: [ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option) [ 43.245591] CPU: 0 PID: 349 Comm: irq/31-mhdp8546 Not tainted 5.9.0-rc5-00605-g08a291316f86 #4 [ 43.254186] Hardware name: Texas Instruments K3 J721E SoC (DT) [ 43.260006] Call trace: [ 43.262453] dump_backtrace+0x0/0x1d8 [ 43.266107] show_stack+0x18/0x28 [ 43.269416] dump_stack+0xe0/0x14c [ 43.272810] __report_bad_irq+0x4c/0xdc [ 43.276637] note_interrupt+0x2cc/0x388 [ 43.280465] handle_irq_event_percpu+0x88/0x90 [ 43.284898] handle_irq_event+0x48/0xf8 [ 43.288725] handle_fasteoi_irq+0xcc/0x180 [ 43.292811] generic_handle_irq+0x30/0x48 [ 43.296811] __handle_domain_irq+0x94/0x108 [ 43.300986] gic_handle_irq+0x60/0x158 [ 43.304726] el1_irq+0xbc/0x180 [ 43.307862] _raw_spin_unlock_irq+0x48/0x90 [ 43.312035] irq_finalize_oneshot.part.0+0x68/0x108 [ 43.316903] irq_thread_fn+0x60/0xa0 [ 43.320469] irq_thread+0x1b8/0x248 [ 43.323949] kthread+0x128/0x160 [ 43.327169] ret_from_fork+0x10/0x34 [ 43.330735] handlers: [ 43.333020] [<000000005367c4f9>] irq_default_primary_handler threaded [<000000007e02b601>] cdns_mhdp_irq_handler [cdns_mhdp8546] [ 43.344607] Disabling IRQ #31 Tomi
On 15:11-20201019, Tomi Valkeinen wrote: > Hi Nikhil, > > On 16/10/2020 13:39, Nikhil Devshatwar wrote: > > This series moves the tidss to using new connectoe model, where the > > SoC driver (tidss) creates the connector and all the bridges are > > attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR > > > > Since the bridges do not create the connector, the bus format and > > bus_flag is set after the format negotiation. > > Support format negotiations in the tfp410 and mhdp bridge drivers. > > > > Nikhil Devshatwar (5): > > drm/tidss: Move to newer connector model > > drm/tidss: Set bus_format correctly from bridge/connector > > drm: bridge: Propagate the bus flags from bridge->timings > > drm/bridge: tfp410: Support format negotiation > > drm/bridge: mhdp8564: Support format negotiation > > I think the patch order could be a bit different. If you first change the tidss to use the new > connector model, and only afterwards fix the bridges we use, then there's a time when the displays > won't work. > Agreed. I will change the order in next version > Also, with J7 EVM and DP, when I unload the modules I see: > I confirm the same issue. I doubt if it is because of the change I did. Will try to revert the patches and confirm again > [ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option) > [ 43.245591] CPU: 0 PID: 349 Comm: irq/31-mhdp8546 Not tainted 5.9.0-rc5-00605-g08a291316f86 #4 > [ 43.254186] Hardware name: Texas Instruments K3 J721E SoC (DT) > [ 43.260006] Call trace: > [ 43.262453] dump_backtrace+0x0/0x1d8 > [ 43.266107] show_stack+0x18/0x28 > [ 43.269416] dump_stack+0xe0/0x14c > [ 43.272810] __report_bad_irq+0x4c/0xdc > [ 43.276637] note_interrupt+0x2cc/0x388 > [ 43.280465] handle_irq_event_percpu+0x88/0x90 > [ 43.284898] handle_irq_event+0x48/0xf8 > [ 43.288725] handle_fasteoi_irq+0xcc/0x180 > [ 43.292811] generic_handle_irq+0x30/0x48 > [ 43.296811] __handle_domain_irq+0x94/0x108 > [ 43.300986] gic_handle_irq+0x60/0x158 > [ 43.304726] el1_irq+0xbc/0x180 > [ 43.307862] _raw_spin_unlock_irq+0x48/0x90 > [ 43.312035] irq_finalize_oneshot.part.0+0x68/0x108 > [ 43.316903] irq_thread_fn+0x60/0xa0 > [ 43.320469] irq_thread+0x1b8/0x248 > [ 43.323949] kthread+0x128/0x160 > [ 43.327169] ret_from_fork+0x10/0x34 > [ 43.330735] handlers: > [ 43.333020] [<000000005367c4f9>] irq_default_primary_handler threaded [<000000007e02b601>] > cdns_mhdp_irq_handler [cdns_mhdp8546] > [ 43.344607] Disabling IRQ #31 > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 28/10/2020 16:19, Nikhil Devshatwar wrote: >> Also, with J7 EVM and DP, when I unload the modules I see: >> > I confirm the same issue. > I doubt if it is because of the change I did. > Will try to revert the patches and confirm again My guess is that it's not your patches as such, but that the mhdp driver does not do irq related cleanups properly and your patches bring the issue up. Tomi