On 10/12/2020 09:34, Tomi Valkeinen wrote: > But we don't have anything stopping omap_dsi_host_transfer being called after the whole bridge has > been detached (or called before attach). So, if we have a guarantee that the panels won't be doing > dsi transfers before/during bridge attach or after/during bridge detach, we have no issue. If we > don't have such a guarantee, it's broken. > > I'll try to figure out if there's such a guarantee, but maybe it's safer to add a flag to indicate > if the bridge is available, and check that during omap_dsi_host_transfer. I don't think this can happen. I mixed up the bridge attach/detach and the dsi host attach/detach. The cancel_delayed_work_sync happens in omap_dsi_host_detach, and I think it's a sensible expectation that the panel won't first do mipi_dsi_detach(), and then try to do DSI transfers. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
