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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D68CCCD6E67 for ; Wed, 11 Oct 2023 13:10:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234937AbjJKNK1 (ORCPT ); Wed, 11 Oct 2023 09:10:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232123AbjJKNKZ (ORCPT ); Wed, 11 Oct 2023 09:10:25 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B965F8F for ; Wed, 11 Oct 2023 06:10:22 -0700 (PDT) Received: from canpemm500009.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4S5Cjt2FQ4zrT8m; Wed, 11 Oct 2023 21:07:46 +0800 (CST) Received: from [10.67.121.177] (10.67.121.177) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Wed, 11 Oct 2023 21:10:20 +0800 CC: , Marc Zyngier , , , , , , , , , , Subject: Re: [RFC PATCH 0/3] Add HiSilicon system timer driver To: Mark Rutland References: <20231010123033.23258-1-yangyicong@huawei.com> <874jiymo2l.wl-maz@kernel.org> From: Yicong Yang Message-ID: Date: Wed, 11 Oct 2023 21:10:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.177] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To canpemm500009.china.huawei.com (7.192.105.203) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On 2023/10/11 18:38, Mark Rutland wrote: > On Wed, Oct 11, 2023 at 10:10:11AM +0800, Yicong Yang wrote: >> On 2023/10/11 0:36, Marc Zyngier wrote: >>> On Tue, 10 Oct 2023 13:30:30 +0100, >>> Yicong Yang wrote: >>>> >>>> From: Yicong Yang >>>> >>>> HiSilicon system timer is a memory mapped platform timer compatible with >>>> the arm's generic timer specification. The timer supports both SPI and >>>> LPI interrupt and can be enumerated through ACPI DSDT table. Since the >>>> timer is fully compatible with the spec, it can reuse most codes of the >>>> arm_arch_timer driver. However since the arm_arch_timer driver only >>>> supports GTDT and SPI interrupt, this series support the HiSilicon system >>>> timer by: >>>> >>>> - refactor some of the arm_arch_timer codes and export the function to >>>> register a arch memory timer by other drivers >>>> - retrieve the IO memory and interrupt resource through DSDT in a separate >>>> driver, then setup and register the clockevent device reuse the arm_arch_timer >>>> function >>>> >>>> Using LPI for the timer is mentioned in BSA Spec section 3.8.1 (DEN0094C 1.0C). >>> >>> This strikes me as pretty odd. LPIs are, by definition, *edge* >>> triggered. The timer interrupt must be *level* triggered. So there >>> must be some bridge in the middle that is going to regenerate edges on >>> EOI, and that cannot be architectural. >>> >>> What am I missing? >> >> In our case, if the timer is working on LPI mode, it's not directly connected >> to the GIC. It'll be wired to hisi-mbigen irqchip which will send LPIs to the >> GIC. > > In that case, the timerr itself isn't using an LPI: it's wired to a secondary > interrupt controller, and the secondary interrupt controller is using an LPI. > > The BSA doesn't describe that as a permitted configuration. > > I think there are two problems here: > > (1) The BSA spec is wrong, and shouldn't say "or LPI" here as it simply doesn't > make sense. > > I think this should be fixed by removing the "or LPI" wording form the BSA > spec for this interrupt. > > (2) This platform is not compatible with the BSA, and is not compatible with > the existing ACPI bindings in the GTDT. > > Do you actually need this wakeup timer? > Thanks for the quick feedback! So the LPI timer mentioned in the BSA spec is probably a mistake and our LPI mode is not compatible to the BSA spec. Then I need to discuss with my team and re-evaluate the solution for the LPI mode of the timer. Thanks, Yicong