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 5B110C433F5 for ; Tue, 17 May 2022 06:43:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231146AbiEQGnJ (ORCPT ); Tue, 17 May 2022 02:43:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240062AbiEQGnE (ORCPT ); Tue, 17 May 2022 02:43:04 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A3CB403ED; Mon, 16 May 2022 23:43:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id B4FA1CE1839; Tue, 17 May 2022 06:43:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBBB0C34117; Tue, 17 May 2022 06:42:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652769779; bh=IkgpZRMDRokE+i/qDVN1ZJ1bBXEnwTYuhU5I2MyVykw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BBbc+U3g516zRPvEHx6rR68oL63QDxOu6wmXrjg6ADJO7EZDspBWQFoopYxLpfGQx frdUv3YMua7gwvI8cgEtySJErWg9kk/jBfUpAzku6n2SQy2UtstYXKprFU0VppTMKC 7nRo9uSZldhoaC+FyNxb0siRDcErTgLlWWNbxyWRMHBk6Yxv+gxIogOWMBIyYiQb5c uleQ7S5GU5lEjEki14B7DlRx963LKsGu+T28cPvbcbMvPA/O6Rk6y2Ktubww4I2rqk 9Gsz4/vNTxLzm71kpUqX5jtMnneLgFsoPoVCDnqkD25GjHaDm1SQRK26KKH34jXa9M Jav6CRyXFQsXA== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nqqv1-00Bp6o-EV; Tue, 17 May 2022 07:42:55 +0100 Date: Tue, 17 May 2022 07:42:54 +0100 Message-ID: <87mtfgmzgx.wl-maz@kernel.org> From: Marc Zyngier To: Chris Packham Cc: "robh+dt@kernel.org" , "krzysztof.kozlowski+dt@linaro.org" , "catalin.marinas@arm.com" , "will@kernel.org" , "andrew@lunn.ch" , "gregory.clement@bootlin.com" , "sebastian.hesselbarth@gmail.com" , "kostap@marvell.com" , "robert.marko@sartura.hr" , "vadym.kochan@plvision.eu" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v7 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board In-Reply-To: References: <20220512042501.3339775-1-chris.packham@alliedtelesis.co.nz> <20220512042501.3339775-3-chris.packham@alliedtelesis.co.nz> <87wnermc9c.wl-maz@kernel.org> <5c01f20a-acd3-da15-081d-7cf878f8a77a@alliedtelesis.co.nz> <87mtfh6c58.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: Chris.Packham@alliedtelesis.co.nz, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, catalin.marinas@arm.com, will@kernel.org, andrew@lunn.ch, gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com, kostap@marvell.com, robert.marko@sartura.hr, vadym.kochan@plvision.eu, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, 16 May 2022 22:56:44 +0100, Chris Packham wrote: > > >>>> Please fix your firmware to program CNTFRQ_EL0, and > >>>> remove this useless property. > >>> I'm kind of at the mercy of what Marvell have provided for ATF. I am > >>> working on the bootloader portion in parallel and am getting things > >>> ready for submitting the u-boot support upstream. I was hoping to > >>> leave ATF alone I can at least see if they haven't fixed this already > >>> (the original dtsi I started with was fairly old) and if they haven't > >>> I'll raise it via their support system. > >> Seems to work fine without the clock so I'll drop it. > > Thanks. If you can, please verify that this is set on both CPUs (I > > have seen plenty of firmware only setting it on CPU0 in the past). > The arch_timer interrupts are counting up on both CPUs and things > generally seem to be getting scheduled (I don't have much of a userland > at the moment so it's not exactly a stress test). Do you think that is > sufficient to say the clock property is unnecessary and whatever > firmware I have is working as expected. No, the counter always count, and CNTFRQ_EL0 is only an indication of the frequency for SW to find out. You can directly read CNTFRQ_EL0 from userspace on each CPU and find whether they have the same value. > >>>> You are also missing a PPI for the EL2 virtual timer which is present > >>>> on any ARMv8.1+ CPU (and since this system is using A55, it definitely > >>>> has it). > >>>> > >>>> [...] > >>> Will add. > >> I assume you're talking about the 5th PPI per the > >> timer/arm,arch_timer.yaml ("hypervisor virtual timer irq"). > > Indeed. > > > >> Helpfully > >> Marvell don't include the PPI interrupt numbers in their datasheet. But > >> then I also notice that none of the other boards that have a > >> "arm,armv8-timer" provide a 5th interrupt either, have I misunderstood > >> something? > > This was only recently added to the DT binding, but the interrupt > > definitely exist at the CPU level for anything that implements ARMv8.1 > > and up. AFAIK, the M1 is the only machine to expose this interrupt in > > DT, but this doesn't mean the interrupt doesn't exist on all the other > > systems that have the same architecture revision. > > > > If you have contacts in Marvell, maybe try and find out whether they > > have simply decided not to wire the interrupt (I wouldn't be > > surprised). In this case, please add a comment. > > I've reached out via their customer support portal. So far they just > want to know why I'm refusing to use their out of date SDK (maybe I > should direct them at some of Jon Corbet's presentations :P). The fact that they are asking is already saying everything there is to know, sadly... > These integrated chips are sometimes a bit problematic because the > support goes via the Switching group but these questions are really > about IP blocks that have been taken from the SoC group. It may take a > while before I get a response from someone that actually knows the > internals. Fair enough. Until then, please drop a comment in the DT indicating that the fate of this PPI is unknown. If you eventually find out, just add it to the DT (it is easy to add things, much harder to remove them). Thanks, M. -- Without deviation from the norm, progress is not possible.