Received: by 10.223.176.46 with SMTP id f43csp2303253wra; Thu, 25 Jan 2018 07:55:14 -0800 (PST) X-Google-Smtp-Source: AH8x226G0JMmeFgeJxmibXadxWAxhiGrkiPjbOAJ7vKB5+5NhVbuhdGd7G9D9/Yp/7yHutceTZW4 X-Received: by 10.99.153.1 with SMTP id d1mr3552012pge.190.1516895714253; Thu, 25 Jan 2018 07:55:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516895714; cv=none; d=google.com; s=arc-20160816; b=HkplaLWKzpWtGXGF4lf7fx80OZPREfWYKmVHIByz2Lr6x1eL4opMN14douh8VeT9Ul 88ZMMei1no7y3JuvR9xX/4DcEQcUhQAlUADobwppwTz522QGGw9DZwc6XIZZzYdhVEqa 6xuD2uluhrT6xdOQpef2AjZhSOdIB8ynHlgjSKcXD1OPHdkO887E+7KpqIj9lRRIlDUd i3ifZcrHfMICa8fu6ZoVVqNR7BvpXCXd1p1dOrbvnpuinr0TKkWX8omz5zpEame8kbiL r/QWhedKoLBKyK2ZSG2k9xeSCJsBWR0yCz5oTpEGAHComKlulIFP4GgnhvkCT/NwOis9 4Ozg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:dkim-signature:dkim-signature :arc-authentication-results; bh=eLKVdGbb4m6czSqVoqM0iLluO2NU07yDLskkJ9JwjIw=; b=nkY2PQ2QOsmdlisTkTLb5V8JHogIEPajUjb3eGzy7StaiLaRmdzrOXpZGlPMcwk+El AssfDWf/CHGiyzI3CEHIAac64b8cipAj9KsCRW0Sq++dJ0LaH3SErQfJZO4D+SFJG1Eq 9efuP3Pa8WfD8w288xpquqwzNewlap1BDDWENknxItPt8hs1KtPufgcTiot+jCT8pXkY oSErM+2MFis3IPc4MuwbbyW6G/EKrCcCYspVnVKHERJFsTrHqyPYVjAjWyCBcVow+3GQ 2q8ZUz5iwVo0qmEwEYbIfETduBcTrNNGzsnpwf792PG9eJD5fZnSP1EOk5CuNBNqeNL7 gxGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=MTemV7Ec; dkim=pass header.i=@codeaurora.org header.s=default header.b=MTemV7Ec; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a138si4777617pfd.161.2018.01.25.07.55.00; Thu, 25 Jan 2018 07:55:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=MTemV7Ec; dkim=pass header.i=@codeaurora.org header.s=default header.b=MTemV7Ec; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751316AbeAYPyc (ORCPT + 99 others); Thu, 25 Jan 2018 10:54:32 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:45890 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750851AbeAYPya (ORCPT ); Thu, 25 Jan 2018 10:54:30 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 9DCA960A5F; Thu, 25 Jan 2018 15:54:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1516895669; bh=eLKVdGbb4m6czSqVoqM0iLluO2NU07yDLskkJ9JwjIw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MTemV7EcFv3fvMJ72QwHtwDKLnSASY1rXaZKX7Bk1FqORKJxlzaFdRXb5DrJ3yqcL UBPVlQFcsJu2C6wtmbVAN2HdAY8UBic3ebvfA8NnwnB3h1LbJWCU2wXTGENungjsMc FnIFt9G2CmUJ54G4UtP6nEgduGh8a9mwIG6q3R+U= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from localhost (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ilina@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id F0EFF60A06; Thu, 25 Jan 2018 15:54:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1516895669; bh=eLKVdGbb4m6czSqVoqM0iLluO2NU07yDLskkJ9JwjIw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MTemV7EcFv3fvMJ72QwHtwDKLnSASY1rXaZKX7Bk1FqORKJxlzaFdRXb5DrJ3yqcL UBPVlQFcsJu2C6wtmbVAN2HdAY8UBic3ebvfA8NnwnB3h1LbJWCU2wXTGENungjsMc FnIFt9G2CmUJ54G4UtP6nEgduGh8a9mwIG6q3R+U= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org F0EFF60A06 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=ilina@codeaurora.org Date: Thu, 25 Jan 2018 15:54:28 +0000 From: Lina Iyer To: Sudeep Holla Cc: Thomas Gleixner , Jason Cooper , Marc Zyngier , open list , linux-arm-msm@vger.kernel.org, Stephen Boyd , "Nayak, Rajendra" , asathyak@codeaurora.org Subject: Re: [PATCH RFC 0/4] irqchip: qcom: add support for PDC interrupt controller Message-ID: <20180125155428.GC24587@codeaurora.org> References: <20180123175656.11942-1-ilina@codeaurora.org> <20180123184442.GA12243@codeaurora.org> <494fa715-aff0-19f2-0ee9-78d8c0b33775@arm.com> <20180124174310.GA24587@codeaurora.org> <1ee07421-444d-adf7-bf6f-8a35c4884c14@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1ee07421-444d-adf7-bf6f-8a35c4884c14@arm.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 24 2018 at 17:54 +0000, Sudeep Holla wrote: > > >On 24/01/18 17:43, Lina Iyer wrote: >> On Wed, Jan 24 2018 at 10:10 +0000, Sudeep Holla wrote: >>> >>> >>> On 23/01/18 18:44, Lina Iyer wrote: >>>> On Tue, Jan 23 2018 at 18:15 +0000, Sudeep Holla wrote: >>> Also when will this PDC wakeup interrupts get configured ? >>> >> The platform drivers configure the IRQ as a wake source and if the IRQ >> is one of those listed as routed to the PDC, the PDC is configured to >> sense the interrupt and when the application processor domain is powered >> on and the GIC can sense the interrupts, it is replayed to the GIC, >> which then wakes up the processor. >> > >Now why can't this be done in the firmware entirely, if it can >save/restore GIC state. > That is because platform drivers make the choice of which interrupts are wake up capable at runtime, based on the usecase. They have to have a way to tell the firmware to do that. Earlier we used IPC to tell the remote processor to handle that. Now we do that by writing to the registers locally from Linux. >>> OK, understood. By transparent, I mean firmware can copy the interrupts >>> enabled in the GIC to the PDC. It need not be kernel driven. >>> >> Yes, through the hierarchy. >> > >/me confused. Are you saying it's possible for f/w to copy wakeup >sources from GIC to PDC or not ? > Platform drivers leave their interrupts enabled at the GIC. Only interrupts that are wakeup capable are of interest when the processor is powered down. The remote processor (or f/w) will need to know the set of wakeup capable interrupts and then configure the PDC by copying from GIC. As mentioned earlier, it is simplified by letting Linux write to the PDC reqisters directly. >> Yes. There is a partition and protected. So only permitted ELs can write >> to the registers. This is done by the firmware at boot. >> > >Just for myself to understand better, so you have multiple partitions in >PDC and one of them is given to EL1 or it just has one partition and >that can be configured so that only permitted ELx is allowed to access >it(in your case it's EL1) > Yes. Thanks, Lina