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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 89468C43214 for ; Thu, 5 Aug 2021 15:30:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 73F3861078 for ; Thu, 5 Aug 2021 15:30:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242048AbhHEPaw (ORCPT ); Thu, 5 Aug 2021 11:30:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240747AbhHEPat (ORCPT ); Thu, 5 Aug 2021 11:30:49 -0400 Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63B3FC061765 for ; Thu, 5 Aug 2021 08:30:35 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id y1so3313925vsc.1 for ; Thu, 05 Aug 2021 08:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2HwiUKZxqy53dDfBp1901/849S4t5mjJtJjeA2wMPec=; b=wg/GjsYLif0ZYYHMg3KnRLOxv3tYLMjO5yw61rpFo2U6f/PHccXPTRMbf7TjDmFtIy SaTMUBl6mtykhQHxwVxwXJdpsqEsHECguuguS4suj2+mcgflMfdF0s+ZKBY/mMwQDdPU akilIu+Sq0Sui1mKolQYpIPGxSkmZDxq5dA+WIymASwSwHXudWOYS2o/qCTkvAHocnl3 C/RrpZm24VqvSY06dlB6yx07zS4xtnbXplFKA/cAVOVuu+r+47pbvV9OUzUTh6gqIuEK Ra4N9BqLgbBx/+PV59gv17Jp1pvOjvaqtB6MrhpxChT5YJ6s07YTularepv+VbeBnprM biwg== 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=2HwiUKZxqy53dDfBp1901/849S4t5mjJtJjeA2wMPec=; b=UpLDEm+8Goaim+0EG3zGvetiIvXLcKMZA1lD4W/yJwWN3HB2Bl60HsPS/Vl7C/lez8 Gxu3qo8G7ecWA1bERD/idLULenJqXn8RpeI4OQ/xU7RpxXsMxHr19Jo1pTpfg9VN8IAB zdQVdiyNns7o/DP0LzY9COD99Ik3J2TByVjUIAdZDTX5oWdFpPUHZ69vGi1BfJt/kTER OlxhAYTkLY+y+vz7k3TREokh60GkZZV0J5kMnnYnQ9gr57b4dXz/zkA5UVpkwPNmLoza x+epJv1d8r+I/TUkc3KT5ZQB2O5thYiMMx/zaKDuCK00MT8VdEIm9aYx30aGF0WXAMoN AfTA== X-Gm-Message-State: AOAM533bxohYAnHxwYhGQi2yn4rU1aO/ytok5prSoa9vLFv5TsURpkQS n87rlgeSqqysF5ZsKLUpooh16Y360OljJ3g/CqFPMg== X-Google-Smtp-Source: ABdhPJz7ndSuSpMNkkGlw9G/nEeHBUu9O9atQyI5vE3atZWBaEoYd/rSmKp8dYwaj/T41dDFjGZta+VdrhSjdEuiiNo= X-Received: by 2002:a67:de06:: with SMTP id q6mr5210772vsk.57.1628177434529; Thu, 05 Aug 2021 08:30:34 -0700 (PDT) MIME-Version: 1.0 References: <20210730144922.29111-1-semen.protsenko@linaro.org> <20210730144922.29111-13-semen.protsenko@linaro.org> <15871f8ced3c757fad1ab3b6e62c4e64@misterjones.org> <87k0l1w8y5.wl-maz@kernel.org> <87y29gbas7.wl-maz@kernel.org> In-Reply-To: <87y29gbas7.wl-maz@kernel.org> From: Sam Protsenko Date: Thu, 5 Aug 2021 18:30:23 +0300 Message-ID: Subject: Re: [PATCH 12/12] arm64: dts: exynos: Add Exynos850 SoC support To: Marc Zyngier Cc: Sylwester Nawrocki , Chanwoo Choi , Krzysztof Kozlowski , Linus Walleij , Tomasz Figa , Rob Herring , Stephen Boyd , Michael Turquette , Jiri Slaby , Greg Kroah-Hartman , Charles Keepax , Ryu Euiyoul , Tom Gall , Sumit Semwal , John Stultz , Amit Pundir , devicetree , linux-arm Mailing List , linux-clk , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , Linux Samsung SOC , "open list:SERIAL DRIVERS" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 5 Aug 2021 at 10:39, Marc Zyngier wrote: > > On Wed, 04 Aug 2021 19:37:24 +0100, > Sam Protsenko wrote: > > > > On Wed, 4 Aug 2021 at 18:01, Marc Zyngier wrote: > > > > > > On Wed, 04 Aug 2021 15:39:38 +0100, > > > Sam Protsenko wrote: > > > > > > > > You are also missing the hypervisor virtual timer interrupt. > > > > > > > > > > > > > Checked SoC TRM, there is no PPI for hypervisor virtual timer > > > > interrupt, and no mentioning of it at all. Likewise, I checked ARMv8 > > > > ARM and TRM, almost no description of it. Also, I checked other > > > > platforms, and seems like everyone does the same (having only 4 > > > > interrupts). And I wasn't able to find any documentation on that, so I > > > > guess I'll leave it as is, if you don't mind. > > > > > > I *do* mind, and other DTs being wrong isn't a good enough excuse! ;-) > > > > > > From the ARMv8 ARM (ARM DDI 0487G.b) > > > > > > D11.2.4 Timers > > > > > > In an implementation of the Generic Timer that includes EL3, if EL3 > > > can use AArch64, the following timers are implemented: > > > > > > * An EL1 physical timer, that: > > > - In Secure state, can be accessed from EL1. > > > - In Non-secure state, can be accessed from EL1 unless those > > > accesses are trapped to EL2. > > > When this timer can be accessed from EL1, an EL1 control > > > determines whether it can be accessed from EL0. > > > * A Non-secure EL2 physical timer. > > > * A Secure EL3 physical timer. An EL3 control determines whether this > > > register is accessible from Secure EL1. > > > * An EL1 virtual timer. > > > * When FEAT_VHE is implemented, a Non-secure EL2 virtual timer. > > > * When FEAT_SEL2 is implemented, a Secure EL2 physical timer. > > > * When FEAT_SEL2 is implemented, a Secure EL2 virtual timer. > > > > > > > > > Cortex-A55 being an ARMv8.2 implementation, it has FEAT_VHE, and thus > > > it does have a NS-EL2 virtual timer. This is further confirmed by the > > > TRM which documents CNTHV*_EL2 as valid system registers[1]. > > > > > > So the timer exists, the signal is routed out of the core, and it > > > is likely that it is connected to the GIC. > > > > > > If the designers have omitted it, then it needs to be documented as > > > such. > > > > > > > Ok, I've checked thoroughly all docs again, and it seems like there is > > no dedicated PPI number for this "EL2 Hypervisor Virtual Timer" in > > Exynos850 SoC. The timer instance itself might exist of course, but > > interrupt line is probably wasn't connected to GIC by SoC designers, > > at least it's not documented. > > Can you try and check this? You can directly program the virtual timer > so that it has a pending interrupt, and then check the pending > register on the same CPU to see if there is anything appearing there. > > > Moreover, from [1,2] it looks like if it were existing it would have > > been PPI=12 (INTID=28). But in GIC-400 TRM this PPI is assigned to > > "Legacy FIQ signal", > > No. That's only if you set the bypass bits in GICD_CTLR, which nobody > with half a brain would consider doing. > > > and all there is no PPI for Hypervisor Virtual > > Timer documented there as well. In Exynos850 TRM the source for this > > PPI's interrupt source is marked as "-", which means it's not used. > > > > So if you know something that I don't know -- please point me out the > > doc where this PPI line is documented. Otherwise I can add the comment > > to device tree, stating that this interrupt line is not present in > > SoC's GIC, i.e. something like this: > > > > 8<------------------------------------------------------------------------------->8 > > timer { > > compatible = "arm,armv8-timer"; > > interrupts = > IRQ_TYPE_LEVEL_LOW)>, > > > IRQ_TYPE_LEVEL_LOW)>, > > > IRQ_TYPE_LEVEL_LOW)>, > > > IRQ_TYPE_LEVEL_LOW)>; > > /* Hypervisor Virtual Timer PPI is not present in this SoC GIC */ > > }; > > 8<------------------------------------------------------------------------------->8 > > > > Is that ok with you? > > I'd rather you verify the above first. And if you can't, I'd like a > comment that is a bit more explicit: > I'm afraid I won't be able to verify your idea: seems like CNTHV_EL2 can be only modified (or read) in EL2. I tried to read that reg anyway, which unsurprisingly resulted in el1_undef() BUG. The kernel on my board is running in EL1, and I don't have access to the source code for EL3 bootloaders. I have the source code for the last bootloader, but it's already running in EL1. > /* The vendor couldn't be bothered to wire the EL2 Virtual Timers */ > I'll add the comment as you suggested. I propose we come back to this issue later, either when the need for HV timer arises or when I have some means to test your theory about existing PPI. Thanks! > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible. 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=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 E9B08C4338F for ; Thu, 5 Aug 2021 15:32:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 B113360F35 for ; Thu, 5 Aug 2021 15:32:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B113360F35 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc: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=PW55ChDvKY+/YzgzCcjnGnFqCLaQOs37q8AYUqbKkhU=; b=eF/NzqUfjfphgG acaqDptAddaDRVVDSuI8xUw47U4V8tkrjeDGcQnBUOvRZS5GGmi907rv+xWTYK9BYN7USYNCof3tv kEl0BAKZYK+r7QVuugFxdcB7v3CNXnCGwxFt1m+NrDkW2p6TR10lCDjBgjKojnmFM/xXPgaBynn1/ EhFu6W5BlNzPxQAjMYSrroBBTa/3TUvfoOIhFOOC3xAHiZlxXhwn5VWvIF9IjHsTnTDJ2eXSGmwBN Dw3S0k0X3Ya7VaPlAkSle253+GjWkq6IZsiwGiDJDnQWczhLVUNZPBVfepBG3rTpWL/AYNffIrCNd NW9Gee5lWaXVBCkBvtcA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mBfKS-00A430-Be; Thu, 05 Aug 2021 15:30:40 +0000 Received: from mail-vs1-xe2e.google.com ([2607:f8b0:4864:20::e2e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mBfKO-00A42b-Q8 for linux-arm-kernel@lists.infradead.org; Thu, 05 Aug 2021 15:30:38 +0000 Received: by mail-vs1-xe2e.google.com with SMTP id h7so1960151vso.13 for ; Thu, 05 Aug 2021 08:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2HwiUKZxqy53dDfBp1901/849S4t5mjJtJjeA2wMPec=; b=wg/GjsYLif0ZYYHMg3KnRLOxv3tYLMjO5yw61rpFo2U6f/PHccXPTRMbf7TjDmFtIy SaTMUBl6mtykhQHxwVxwXJdpsqEsHECguuguS4suj2+mcgflMfdF0s+ZKBY/mMwQDdPU akilIu+Sq0Sui1mKolQYpIPGxSkmZDxq5dA+WIymASwSwHXudWOYS2o/qCTkvAHocnl3 C/RrpZm24VqvSY06dlB6yx07zS4xtnbXplFKA/cAVOVuu+r+47pbvV9OUzUTh6gqIuEK Ra4N9BqLgbBx/+PV59gv17Jp1pvOjvaqtB6MrhpxChT5YJ6s07YTularepv+VbeBnprM biwg== 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=2HwiUKZxqy53dDfBp1901/849S4t5mjJtJjeA2wMPec=; b=P9bHZ6UmBcmcYqGtRsDYLQz19GCD/GMOA2Rcrgw8pmaNOVcBqTQIwOTxjLZKuiJkky EcNGuDZzgDZ4vQDhnZzPsHfTQKcKxG3lCxag+gbnKDKnfKg/LIqYndUDHXiNhJbbHhKj 7MpOrj85gVIyDjhpecONOITcUS0valXBFhd4+ytI0owoOscJhieQ9oIJbPaynYOPzGy/ +fZ3YeiDQrl5nCEL0q2qK6dQnxyAZTC+h4BpEhHQmx2i72ejkENC4vti4cq93VM2DXQ5 bnbVBkt79VKh77KRLUs7cIoe70UIwWKV8GayfTCnqhX7PGkRCfi/2yd69sSFzVUpy4lJ 6vpw== X-Gm-Message-State: AOAM530FrhVFi5cb4g0TOa1X6TY/x7m+7aoLf/De2qcZwD81Y/M4qYDC 7Hw6AuxsrQeCKPytIL3lN7Uny61nlHSIxm1EoBFfjw== X-Google-Smtp-Source: ABdhPJz7ndSuSpMNkkGlw9G/nEeHBUu9O9atQyI5vE3atZWBaEoYd/rSmKp8dYwaj/T41dDFjGZta+VdrhSjdEuiiNo= X-Received: by 2002:a67:de06:: with SMTP id q6mr5210772vsk.57.1628177434529; Thu, 05 Aug 2021 08:30:34 -0700 (PDT) MIME-Version: 1.0 References: <20210730144922.29111-1-semen.protsenko@linaro.org> <20210730144922.29111-13-semen.protsenko@linaro.org> <15871f8ced3c757fad1ab3b6e62c4e64@misterjones.org> <87k0l1w8y5.wl-maz@kernel.org> <87y29gbas7.wl-maz@kernel.org> In-Reply-To: <87y29gbas7.wl-maz@kernel.org> From: Sam Protsenko Date: Thu, 5 Aug 2021 18:30:23 +0300 Message-ID: Subject: Re: [PATCH 12/12] arm64: dts: exynos: Add Exynos850 SoC support To: Marc Zyngier Cc: Sylwester Nawrocki , Chanwoo Choi , Krzysztof Kozlowski , Linus Walleij , Tomasz Figa , Rob Herring , Stephen Boyd , Michael Turquette , Jiri Slaby , Greg Kroah-Hartman , Charles Keepax , Ryu Euiyoul , Tom Gall , Sumit Semwal , John Stultz , Amit Pundir , devicetree , linux-arm Mailing List , linux-clk , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , Linux Samsung SOC , "open list:SERIAL DRIVERS" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210805_083036_930368_BE94CB14 X-CRM114-Status: GOOD ( 53.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Thu, 5 Aug 2021 at 10:39, Marc Zyngier wrote: > > On Wed, 04 Aug 2021 19:37:24 +0100, > Sam Protsenko wrote: > > > > On Wed, 4 Aug 2021 at 18:01, Marc Zyngier wrote: > > > > > > On Wed, 04 Aug 2021 15:39:38 +0100, > > > Sam Protsenko wrote: > > > > > > > > You are also missing the hypervisor virtual timer interrupt. > > > > > > > > > > > > > Checked SoC TRM, there is no PPI for hypervisor virtual timer > > > > interrupt, and no mentioning of it at all. Likewise, I checked ARMv8 > > > > ARM and TRM, almost no description of it. Also, I checked other > > > > platforms, and seems like everyone does the same (having only 4 > > > > interrupts). And I wasn't able to find any documentation on that, so I > > > > guess I'll leave it as is, if you don't mind. > > > > > > I *do* mind, and other DTs being wrong isn't a good enough excuse! ;-) > > > > > > From the ARMv8 ARM (ARM DDI 0487G.b) > > > > > > D11.2.4 Timers > > > > > > In an implementation of the Generic Timer that includes EL3, if EL3 > > > can use AArch64, the following timers are implemented: > > > > > > * An EL1 physical timer, that: > > > - In Secure state, can be accessed from EL1. > > > - In Non-secure state, can be accessed from EL1 unless those > > > accesses are trapped to EL2. > > > When this timer can be accessed from EL1, an EL1 control > > > determines whether it can be accessed from EL0. > > > * A Non-secure EL2 physical timer. > > > * A Secure EL3 physical timer. An EL3 control determines whether this > > > register is accessible from Secure EL1. > > > * An EL1 virtual timer. > > > * When FEAT_VHE is implemented, a Non-secure EL2 virtual timer. > > > * When FEAT_SEL2 is implemented, a Secure EL2 physical timer. > > > * When FEAT_SEL2 is implemented, a Secure EL2 virtual timer. > > > > > > > > > Cortex-A55 being an ARMv8.2 implementation, it has FEAT_VHE, and thus > > > it does have a NS-EL2 virtual timer. This is further confirmed by the > > > TRM which documents CNTHV*_EL2 as valid system registers[1]. > > > > > > So the timer exists, the signal is routed out of the core, and it > > > is likely that it is connected to the GIC. > > > > > > If the designers have omitted it, then it needs to be documented as > > > such. > > > > > > > Ok, I've checked thoroughly all docs again, and it seems like there is > > no dedicated PPI number for this "EL2 Hypervisor Virtual Timer" in > > Exynos850 SoC. The timer instance itself might exist of course, but > > interrupt line is probably wasn't connected to GIC by SoC designers, > > at least it's not documented. > > Can you try and check this? You can directly program the virtual timer > so that it has a pending interrupt, and then check the pending > register on the same CPU to see if there is anything appearing there. > > > Moreover, from [1,2] it looks like if it were existing it would have > > been PPI=12 (INTID=28). But in GIC-400 TRM this PPI is assigned to > > "Legacy FIQ signal", > > No. That's only if you set the bypass bits in GICD_CTLR, which nobody > with half a brain would consider doing. > > > and all there is no PPI for Hypervisor Virtual > > Timer documented there as well. In Exynos850 TRM the source for this > > PPI's interrupt source is marked as "-", which means it's not used. > > > > So if you know something that I don't know -- please point me out the > > doc where this PPI line is documented. Otherwise I can add the comment > > to device tree, stating that this interrupt line is not present in > > SoC's GIC, i.e. something like this: > > > > 8<------------------------------------------------------------------------------->8 > > timer { > > compatible = "arm,armv8-timer"; > > interrupts = > IRQ_TYPE_LEVEL_LOW)>, > > > IRQ_TYPE_LEVEL_LOW)>, > > > IRQ_TYPE_LEVEL_LOW)>, > > > IRQ_TYPE_LEVEL_LOW)>; > > /* Hypervisor Virtual Timer PPI is not present in this SoC GIC */ > > }; > > 8<------------------------------------------------------------------------------->8 > > > > Is that ok with you? > > I'd rather you verify the above first. And if you can't, I'd like a > comment that is a bit more explicit: > I'm afraid I won't be able to verify your idea: seems like CNTHV_EL2 can be only modified (or read) in EL2. I tried to read that reg anyway, which unsurprisingly resulted in el1_undef() BUG. The kernel on my board is running in EL1, and I don't have access to the source code for EL3 bootloaders. I have the source code for the last bootloader, but it's already running in EL1. > /* The vendor couldn't be bothered to wire the EL2 Virtual Timers */ > I'll add the comment as you suggested. I propose we come back to this issue later, either when the need for HV timer arises or when I have some means to test your theory about existing PPI. Thanks! > 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