From: Marc Zyngier <maz@kernel.org> To: Chris Packham <Chris.Packham@alliedtelesis.co.nz> Cc: "robh+dt@kernel.org" <robh+dt@kernel.org>, "krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "will@kernel.org" <will@kernel.org>, "andrew@lunn.ch" <andrew@lunn.ch>, "gregory.clement@bootlin.com" <gregory.clement@bootlin.com>, "sebastian.hesselbarth@gmail.com" <sebastian.hesselbarth@gmail.com>, "kostap@marvell.com" <kostap@marvell.com>, "robert.marko@sartura.hr" <robert.marko@sartura.hr>, "vadym.kochan@plvision.eu" <vadym.kochan@plvision.eu>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v7 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board Date: Tue, 17 May 2022 07:42:54 +0100 [thread overview] Message-ID: <87mtfgmzgx.wl-maz@kernel.org> (raw) In-Reply-To: <db5c3366-ac81-261b-ff32-3ccf94a930f6@alliedtelesis.co.nz> On Mon, 16 May 2022 22:56:44 +0100, Chris Packham <Chris.Packham@alliedtelesis.co.nz> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Chris Packham <Chris.Packham@alliedtelesis.co.nz> Cc: "robh+dt@kernel.org" <robh+dt@kernel.org>, "krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "will@kernel.org" <will@kernel.org>, "andrew@lunn.ch" <andrew@lunn.ch>, "gregory.clement@bootlin.com" <gregory.clement@bootlin.com>, "sebastian.hesselbarth@gmail.com" <sebastian.hesselbarth@gmail.com>, "kostap@marvell.com" <kostap@marvell.com>, "robert.marko@sartura.hr" <robert.marko@sartura.hr>, "vadym.kochan@plvision.eu" <vadym.kochan@plvision.eu>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v7 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board Date: Tue, 17 May 2022 07:42:54 +0100 [thread overview] Message-ID: <87mtfgmzgx.wl-maz@kernel.org> (raw) In-Reply-To: <db5c3366-ac81-261b-ff32-3ccf94a930f6@alliedtelesis.co.nz> On Mon, 16 May 2022 22:56:44 +0100, Chris Packham <Chris.Packham@alliedtelesis.co.nz> 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-17 6:43 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-12 4:24 [PATCH v7 0/3] arm64: mvebu: Support for Marvell 98DX2530 (and variants) Chris Packham 2022-05-12 4:24 ` Chris Packham 2022-05-12 4:24 ` [PATCH v7 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles Chris Packham 2022-05-12 4:24 ` Chris Packham 2022-05-13 9:12 ` Krzysztof Kozlowski 2022-05-13 9:12 ` Krzysztof Kozlowski 2022-05-12 4:25 ` [PATCH v7 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board Chris Packham 2022-05-12 4:25 ` Chris Packham 2022-05-12 7:38 ` Marc Zyngier 2022-05-12 7:38 ` Marc Zyngier 2022-05-12 22:10 ` Chris Packham 2022-05-12 22:10 ` Chris Packham 2022-05-13 1:26 ` Chris Packham 2022-05-13 1:26 ` Chris Packham 2022-05-16 9:48 ` Marc Zyngier 2022-05-16 9:48 ` Marc Zyngier 2022-05-16 21:56 ` Chris Packham 2022-05-16 21:56 ` Chris Packham 2022-05-17 6:42 ` Marc Zyngier [this message] 2022-05-17 6:42 ` Marc Zyngier 2022-05-17 22:56 ` Chris Packham 2022-05-17 22:56 ` Chris Packham 2022-05-18 7:11 ` Marc Zyngier 2022-05-18 7:11 ` Marc Zyngier 2022-05-12 4:25 ` [PATCH v7 3/3] arm64: marvell: enable the 98DX2530 pinctrl driver Chris Packham 2022-05-12 4:25 ` Chris Packham
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87mtfgmzgx.wl-maz@kernel.org \ --to=maz@kernel.org \ --cc=Chris.Packham@alliedtelesis.co.nz \ --cc=andrew@lunn.ch \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=gregory.clement@bootlin.com \ --cc=kostap@marvell.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=robert.marko@sartura.hr \ --cc=robh+dt@kernel.org \ --cc=sebastian.hesselbarth@gmail.com \ --cc=vadym.kochan@plvision.eu \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.