Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1441058pxj; Fri, 21 May 2021 14:31:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzk0G1xQJK7ZwlwB5WHkgX12YSyJ8yNfhfdicWOB6HOejh6R4qlLm4kmUT2n0pzhc6YCN69 X-Received: by 2002:a02:c73a:: with SMTP id h26mr7200887jao.95.1621632661354; Fri, 21 May 2021 14:31:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621632661; cv=none; d=google.com; s=arc-20160816; b=gHU+swpXDRS0xqbP7VPZTgM2LQLWmOPdOGIVAzVoPUXht/QOYr0SD7sGhi/ueEs55S ojLl03ROPtm0JaEFqrlYr0i8hL7tpfLVLxLa7jRFLvQ66tZGiV9VJYDk74fXCQT3ihka QjMnSh18AAXCr/XyW2Y6ehExFFUOojTrdjx0nHAYIH35YZutaN9V64vEVFxQU+beb7Mq gXq5+w27DGhTOP1bu6dQmeJQ/wev6OrNXTkVlYlwo+Nva+dnBBj81lkZ7//XgZWBGfvc dVLgGrUqKx4x5q8eh2xzk68cY1T6je/407FhHr2uKoXDZkrSkgYlnr3/SXR4bkijgFkG XDHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:user-agent:from :references:in-reply-to:mime-version:dkim-signature; bh=B3jduID57ZvHsMi3x4uB8b1Uc3RzS8uHWNJ1a8k5L9c=; b=EVlYl/9/NNZNh367oUTpB1l4ch+ZCYvZUF5U1JELZbpk+ngR/aJ+kqrggSca+iSuwc x+csi169ZEB4IkszQ2ZP8mFV1XxSxTd0KLHpIHT+FsP7pIopQxzhLXmB1SM4395Bk/iy 9Q8mllEnKOyTe6nmnjaxa3N1zxtURLWeM49GeMu48XYZgWijxcuK3YroAAltcL7XLCDL a7yXDBsI2OFtSxX8q3uBKRao5UCZEWxEAZBaG+2DhRYwbPoO/kPIwz+VesdWUBIXuQ8s pnKBzWtBtH7UoYdFTLe4zajo4YahBh/3PaHDwGJf0n+OnqTAKWTHgjIKaUvgxHqNbRhG FCAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Vq+Ujoae; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w3si6647181iov.75.2021.05.21.14.30.49; Fri, 21 May 2021 14:31:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Vq+Ujoae; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229517AbhEUUzk (ORCPT + 99 others); Fri, 21 May 2021 16:55:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229976AbhEUUzj (ORCPT ); Fri, 21 May 2021 16:55:39 -0400 Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0B55C061574 for ; Fri, 21 May 2021 13:54:15 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id d21so20851108oic.11 for ; Fri, 21 May 2021 13:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=B3jduID57ZvHsMi3x4uB8b1Uc3RzS8uHWNJ1a8k5L9c=; b=Vq+UjoaepuatCdv+jF9L93kUcjSzg5FxbSLlu/3chM+ilyPCC/wlYyA14tE0wP39He wrzMHJgK2waajEWhwE18K6Wxi2T9TMFikGCK6UFbgsaDLx9LK+GS7CkKuI201AgR0w2T jlJ1jgX4kWw0hmavhTK6U2i2IoRHRxe1QzEiA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=B3jduID57ZvHsMi3x4uB8b1Uc3RzS8uHWNJ1a8k5L9c=; b=c1Ev4x11FHbmNrEJRyjh5FsTNaL201J+9ygiJxY8Na3jhRgcEXcDabI6vi1hrMbAyb TDedWEoaWiWQ3mvY9S++GUnzcBTKfQeyuSBAn/Gst5yHttcfFtIdF0fveSp42IltBgUG S+xd2zeBTvoeBHniBcM4SJNm++CYKqLt82psRf27L4dwIrl5i7w0Zj+fb65lGumv4OY3 mKNQ5hM9NPuupAzQeUfcMaUF45LWSdGr2NYLzx+CojqeZ1B45DdptaTVMukdFKAf9C7q NwnwhZrnGEXgxsOOq5VHGmayvmE7HXcTtCq7nVJv3QSUnxcwSc4vNT+qVFsmTDAWKHX1 Vkdg== X-Gm-Message-State: AOAM530KtFB+8MEjkAPgtECk6C2/okHPUy2Tlvdk9l+UXI9n6mZiuyTh CfJnaqvH9YaMQDM1ApXOjlXBfqeMUMhkVoCmMDvbFA== X-Received: by 2002:aca:654d:: with SMTP id j13mr3627644oiw.125.1621630455411; Fri, 21 May 2021 13:54:15 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 May 2021 13:54:14 -0700 MIME-Version: 1.0 In-Reply-To: References: <1621013713-6860-1-git-send-email-khsieh@codeaurora.org> <5d341df202facb3240a72cfb35e18167@codeaurora.org> <1e9970ee1a7109e336bc6ed51e727442@codeaurora.org> From: Stephen Boyd User-Agent: alot/0.9.1 Date: Fri, 21 May 2021 13:54:14 -0700 Message-ID: Subject: Re: [PATCH v4 1/2] drm/msm/dp: handle irq_hpd with sink_count = 0 correctly To: khsieh@codeaurora.org Cc: agross@kernel.org, bjorn.andersson@linaro.org, robdclark@gmail.com, sean@poorly.run, vkoul@kernel.org, abhinavk@codeaurora.org, aravindh@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting khsieh@codeaurora.org (2021-05-21 12:45:35) > On 2021-05-21 12:18, Stephen Boyd wrote: > > Quoting khsieh@codeaurora.org (2021-05-21 08:21:58) > >> > > >> > Ok. So you're saying that we want to put both events on the queue > >> > regardless, and put IRQ_HPD there first because we want to check the > >> > status bit? Doesn't reading the status bit require the dongle to be > >> > connected though? So if an unplug came in along with an irq_hpd we may > >> > queue both the irq_hpd and the unplug, but when it comes time to > >> > process > >> > the irq_hpd in the kthread the link will be gone and so trying the dpcd > >> > read for the link status will fail? > >> > > >> yes, > >> we had a previous bug with this scenarios already. > >> https://partnerissuetracker.corp.google.com/issues/170598152 > >> At this case, dongle produce two interrupts, irq_hpd followed by > >> unplug > >> immediately (not presented at isr status register at same time), at > >> the > >> time dongle unplugged form DTU. > >> But due to dp ctrl reset at handling irq_hpd which cause unplug mask > >> bit > >> be cleared so that unplug interrupt got lost. > >> > > > > Again, wouldn't that be too late if the hardirq handler is delayed to > > the point that the two irqs are pending in the isr status register? > > yes, > but that not much dp driver can do. > As long as DP driver can recovery (shut down gracefully) and ready for > next plugin, then i think it should be fine. > Yes. I'm trying to make the point that the least the DP driver could do would be to mask the interrupts for HPD IRQ when unplug irq happens at hardirq context and also ignore HPD IRQ when unplug is also there. And going even further, it feels like we should only enable the unplug irq once a plug in irq happens, and vice versa, so that we don't get into the case where a super long delayed irq sees all three bits: plug, unplug, and hpd irq.