On Fri, Nov 25, 2016 at 1:23 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: >> > Daniel, why do we have an API the is clearly related to interrupt handling >> > but requires the caller to implement a workqueue ? >> >> Because in general you need that workqueue anyway, and up to now there was >> no driver ever who didn't have a work-queue already. > > None of the bridge drivers in drivers/gpu/drm/bridge/ have workqueues. They > call the HPD helpers from a threaded interrupt handler though. Sleeping in > that context is fine, calling functions that might rely on interrupts from the > same device to signal completion (such as reading EDID through .get_modes()) > isn't. Hm, as long as they all use the bit-banging interfaces they'll probably be all fine. For everyone else you need multiple layers of work items to make sure you never end up stalling in an interrupt vs. holding-mode_config.mutex deadlock. So still not convinced we need this ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
