Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752727AbcKYGd0 (ORCPT ); Fri, 25 Nov 2016 01:33:26 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:35172 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752572AbcKYGdU (ORCPT ); Fri, 25 Nov 2016 01:33:20 -0500 MIME-Version: 1.0 X-Originating-IP: [2a02:168:56b5:0:ac27:b86c:7764:9429] In-Reply-To: <1659700.XqUPVvtxXc@avalon> References: <1479775052-28194-1-git-send-email-john.stultz@linaro.org> <3450618.hbnl5lRf5h@avalon> <20161123075537.2wsk6hwdjntyrjl4@phenom.ffwll.local> <1659700.XqUPVvtxXc@avalon> From: Daniel Vetter Date: Fri, 25 Nov 2016 07:33:18 +0100 X-Google-Sender-Auth: JAvskfXJqq_EcP5CBZWdtRTQcm4 Message-ID: Subject: Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on To: Laurent Pinchart Cc: John Stultz , lkml , David Airlie , Archit Taneja , Wolfram Sang , Lars-Peter Clausen , "dri-devel@lists.freedesktop.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1077 Lines: 24 On Fri, Nov 25, 2016 at 1:23 AM, Laurent Pinchart 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