Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp11243imm; Thu, 12 Jul 2018 13:07:21 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdjEpKdkOstFwMK2dsJZvj2dl0RFPXqJ0mHoHfvcxsKA4/RVNpVj7n3Jcvr4HUQnZyrq0M3 X-Received: by 2002:a62:1314:: with SMTP id b20-v6mr3880481pfj.230.1531426041725; Thu, 12 Jul 2018 13:07:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531426041; cv=none; d=google.com; s=arc-20160816; b=lf65hifxUlTRSOgcTgN18uY/ezUJTL2ywi8bHbU2+OjdXGk7CVPuoRI1yHUmx0JFWW GjUFr5BRzZi12+MLcKyzh9swaC9V1IKjF3Fijoeq9tJO4GQH6ocz+FobzM8YV20HasDI LxZaXztwA7u9PeZsFmibVWTpHzXJ53jcJOiLQz07d2XpqhxnZchLJEk+TpqMGdDN6WbK XVZgTsfmEsFmUwwMqFztnxk1DtMoi4Im6L4lnuBkc2S2HFBuTTgGoCUhd0StcYNIxgfI YoMYnpFYFbW08n1CraGeG2PR+oN7PYZYp+svDVoD54Gdfha5/VrKCu2CB3uoAiKmzPmf 4Ccw== 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=hnqF7NTU0K3GSZU7lMV+WAI9sRyHeB6h2NdiCs+eHNE=; b=XntY4bcUqWKgVUzqk4ZyyM4Ce6cS45zFdMYxqTIwPB7Af+0boNC03TC7lztN9PaAc3 kBpML6QlZOQPXzhqrjRdiBmWYRJxQ+6wIZUt/lc13r/gIjbtVuFkj3gIyC0ZzwYttf4v 7ZwrKTFvhsI8HMBIRV51Ist3aXaqn21mhXSpKLCOACVEUoYrZoVKEojm7MQR7hQdBURf gCMySmqHWHcOJLSSzyzeX/MfPzsRoTlbUObuUL3nOFOdMq22XEMMhYhs1U9D7KUGGR1v TZ5e+gwXw5JTCnbq+nkLjg6kr530s0SsfZ8I4bQ9OlaF2fTJ9O2SMdmh/ZTx7AB8Vt0l 00Qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=fH4pW69z; dkim=pass header.i=@codeaurora.org header.s=default header.b=fH4pW69z; 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 98-v6si21504714pls.430.2018.07.12.13.06.33; Thu, 12 Jul 2018 13:07:21 -0700 (PDT) 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=fH4pW69z; dkim=pass header.i=@codeaurora.org header.s=default header.b=fH4pW69z; 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 S1732526AbeGLUPj (ORCPT + 99 others); Thu, 12 Jul 2018 16:15:39 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58162 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732249AbeGLUPj (ORCPT ); Thu, 12 Jul 2018 16:15:39 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 5ACA360B6B; Thu, 12 Jul 2018 20:04:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1531425873; bh=A1wAqMLm9duPJD9A78Ueky/EVya5Up3X8vNp9EscHZ8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fH4pW69z6/7cRm3N+DajyJIHu2j2UT3Fm3uy0edJEi8DuPhY844Dmfsjo8kgR76dT YcN/6Acc4vxwGPm3crW4jVMCl5tvZlLeYjV3Ko7uei5Tg1tjblw+sH0rZgjMYWUuNe hajWrciyEX2+BUkn1+pjG+0sX4G0SQt0xsfyl0Ng= 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 CBEAC6074D; Thu, 12 Jul 2018 20:04:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1531425873; bh=A1wAqMLm9duPJD9A78Ueky/EVya5Up3X8vNp9EscHZ8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fH4pW69z6/7cRm3N+DajyJIHu2j2UT3Fm3uy0edJEi8DuPhY844Dmfsjo8kgR76dT YcN/6Acc4vxwGPm3crW4jVMCl5tvZlLeYjV3Ko7uei5Tg1tjblw+sH0rZgjMYWUuNe hajWrciyEX2+BUkn1+pjG+0sX4G0SQt0xsfyl0Ng= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org CBEAC6074D 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, 12 Jul 2018 14:04:32 -0600 From: Lina Iyer To: Evan Green Cc: Bjorn Andersson , Linus Walleij , linux-arm-msm@vger.kernel.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, swboyd@chromium.org Subject: Re: [PATCH] pinctrl: msm: Pass along set_wake failures Message-ID: <20180712200432.GA887@codeaurora.org> References: <20180619234349.166190-1-evgreen@chromium.org> <20180709173022.GH2050@tuxbook-pro> <20180710203805.GA14825@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 12 2018 at 10:31 -0600, Evan Green wrote: >On Tue, Jul 10, 2018 at 1:38 PM Lina Iyer wrote: >> >> On Tue, Jul 10 2018 at 12:53 -0600, Evan Green wrote: >> >On Mon, Jul 9, 2018 at 10:27 AM Bjorn Andersson >> > wrote: >> >Our understanding is the downstream kernel had an interrupt hierarchy >> >of GIC > PDC > TLMM & everybody else. In the downstream world PDC >> >acted transparently, forwarding most requests directly onto the GIC, >> >but quietly handling wake interrupts as well. With the upstream PDC >> >driver, the #interrupt-cells got changed to 2, and it seemed like >> >folks didn't like the idea that PDC was acting transparently. Correct >> >me if I'm wrong there. So now we're sort of unsure about how to wire >> >in PDC. If we make everybody an interrupt child of PDC, then we lose >> >the ability to specify the third GIC parameter, and we're stuck >> >expressing interrupts with respect to PDC pins, which is an awkward >> >mental translation. >> Its an unfortunate side effect of the design. Drivers will have to >> request the PDC pin for wakeup IRQs. > >Would they use the PDC pin to request their regular interrupt, and the >PDC would turn around and ask the GIC for them, and also enable the >wakeup interrupt?> Yes, drivers would need to request a PDC pin since using the interrupts-extended format and then enable that interrupt was a wakeup interrupt. > Or would devices have some sort of separate entry for wakeup > interrupts? Not sure how you mean. If it's the DT you are asking, then yes, they would need to have a separate entry in DT. wake-device { interrupts-extended = <&pdc 2 IRQ_TYPE_LEVEL_HIGH>; }; See Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt Thanks, Lina