From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F252EC433E0 for ; Wed, 23 Dec 2020 01:09:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B05F9222BB for ; Wed, 23 Dec 2020 01:09:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B05F9222BB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jms.id.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=x6590VoVgWJn+c/JbTHLYeNq5xUmxVmtjT0oGMo+zm8=; b=bPdRa7CPAXye7UynORhHDK9be YFnheOtoTWcY3c40MIepSV9d2QyxNHeAnCkTHVsLFkOWxRxm2qWiQFmPnQAjYtb9YnnClHhKoHa3g 6MR4giyUoGGjM+h0Bw6fsYrilof6zw7d8oORf4Y5WZX8ggym3DyCF4aUhMBHGCupuf3Jb+GkcWXcA aO/TiXJw29VVHRoQbC2GQZzXdPVuZxxBFDkOZMFQXMo3llJECXnZwQs6er0sq5AmK3qsWshXeqE+W n8DaT6ajwo80TWwIZ3NIzS5yl4NvsK4u7qnVucVqNyJ6qLmyWcSMpFbSfzr47zNWWuNbjC7hNzCAc rczchcl4A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1krscj-0007Yc-U2; Wed, 23 Dec 2020 01:07:29 +0000 Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1krsch-0007Xi-09 for linux-arm-kernel@lists.infradead.org; Wed, 23 Dec 2020 01:07:28 +0000 Received: by mail-qk1-x72e.google.com with SMTP id v126so9211457qkd.11 for ; Tue, 22 Dec 2020 17:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jms.id.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b/IvHYt4zK7qrtLu/dIFfw1GWqSkerWH38ekPT2Fi8I=; b=FBLHaVSF9xVVMTPm3bwINQWKYKnm6a0cqbzSMhkX4GAX1RksMdNDHK2JguD4n/leut wlBTQBhTNkQsp0XAj9f0Bt/qO9vdusmj3o0Ux3Upl2JiPoIAl3XqFlMHYjgW8/uZsegf QxFHw0SsUQbzVaGUra6Z8zNUIOI/R8fDTVsBE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b/IvHYt4zK7qrtLu/dIFfw1GWqSkerWH38ekPT2Fi8I=; b=L29MNYYIDBIyzOe++CC0wZEaQbPHARO1pgL3+HLuba7C/6V/zsjXO70LaI6+JAEQ/s kfKrjv7ookA4aJLgM9CwEhbpBZw2mABOfaTFjvzEThKfeSrkrAiJjCN+bK/hOL+UizwU rAIRWuv+m/yOrUPmDKveKnzPNDKpdWzRHm7Q3cxg2s2gQrjxdeRpUT4pQu81KXfjsZVN j8IUlRZeErKSHM3tfy706pOAcCpcrNKKEJCr9zhYSvnq4jabf26mKcWBcZNKqKwg7c3z 67euyXaXV6UtNtnZxCr9fpqOefk4Uvcoltk8N2c/qXwZgcs4srazCe2Z0VbUVow1E0df xpLw== X-Gm-Message-State: AOAM533aybgcsX5QUpl4ascWfMmsXdhUIowL3Gpso9oDiZDczfyMJmnh Gt19E2XdY9YhleFso/8ZYWybwRIAOTKSK1pr3Nw= X-Google-Smtp-Source: ABdhPJweuxZG5b2ckpgGQ3CTgEg8EXlZp8qF2RXEjdc10DG4PVJk9A5cd6eJ1QbThAHKMa5XdNdfQsCKrqo435qrsp0= X-Received: by 2002:a37:6790:: with SMTP id b138mr24838589qkc.465.1608685644841; Tue, 22 Dec 2020 17:07:24 -0800 (PST) MIME-Version: 1.0 References: <20201215024542.18888-1-zev@bewilderbeest.net> <20201215024542.18888-3-zev@bewilderbeest.net> <20201222191433.3dgnfwyrod4tnvaf@hatter.bewilderbeest.net> In-Reply-To: <20201222191433.3dgnfwyrod4tnvaf@hatter.bewilderbeest.net> From: Joel Stanley Date: Wed, 23 Dec 2020 01:07:12 +0000 Message-ID: Subject: Re: [PATCH 2/3] aspeed-video: clear spurious interrupt bits unconditionally To: Zev Weiss , Ryan Chen X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201222_200727_275685_EDF2A62C X-CRM114-Status: GOOD ( 21.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jae Hyun Yoo , linux-aspeed , Andrew Jeffery , OpenBMC Maillist , Eddie James , Linux Kernel Mailing List , Mauro Carvalho Chehab , Linux ARM , linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 22 Dec 2020 at 19:14, Zev Weiss wrote: > > On Mon, Dec 21, 2020 at 10:47:37PM CST, Joel Stanley wrote: > >On Tue, 15 Dec 2020 at 02:46, Zev Weiss wrote: > >> > >> Instead of testing and conditionally clearing them one by one, we can > >> instead just unconditionally clear them all at once. > >> > >> Signed-off-by: Zev Weiss > > > >I had a poke at the assembly and it looks like GCC is clearing the > >bits unconditionally anyway, so removing the tests provides no change. > > > >Combining them is a good further optimization. > > > >Reviewed-by: Joel Stanley > > > >A question unrelated to this patch: Do you know why the driver doesn't > >clear the status bits in the interrupt handler? I would expect it to > >write the value of sts back to the register to ack the pending > >interrupt. > > > > No, I don't, and I was sort of wondering the same thing actually -- I'm > not deeply familiar with this hardware or driver though, so I was a bit > hesitant to start messing with things. (Though maybe doing so would > address the "stickiness" aspect when it does manifest.) Perhaps Eddie > or Jae can shed some light here? I think you're onto something here - this would be why the status bits seem to stick until the device is reset. Until Aspeed can clarify if this is a hardware or software issue, I suggest we ack the bits and log a message when we see them, instead of always ignoring them without taking any action. Can you write a patch that changes the interrupt handler to ack status bits as it handles each of them? > > > Zev > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel