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 BCCB6C4332F for ; Fri, 6 May 2022 07:41:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1389637AbiEFHon (ORCPT ); Fri, 6 May 2022 03:44:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1389632AbiEFHom (ORCPT ); Fri, 6 May 2022 03:44:42 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECC295DA51 for ; Fri, 6 May 2022 00:40:59 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id bq30so11209817lfb.3 for ; Fri, 06 May 2022 00:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=yq4oJMCDfCqiuSYPrGiR7TdBoQ/AyiNCejA6X9Nl+ck=; b=dorWGvetxsGHiee41vHh66trGajA/WXxHaOioCCMFnhLOgLF6l/cV99tZXnLtV0BmF PAsja2Dl0CXAnTSrT8yRsPGa8iwAuT7/H0jCoSLoJK0PUwnFDF3AxxSA3VEP9tTesybY uWRbNG+JjmP4NPtPDHx+m+AMyuxsnnamZV+64uujGSzZuB0cM8FTs8OKJMk6AzZ81kjz Eeq7kxVE1d7YbJ9WH112miBPug2PYTcYjktR+s4LrHHqKqBHoQmdBmixBynslQX2oXjo TCBV73G4ZQmlwajOcDRSjW5PX5vxI511uB6+496bT30FVQovW+CKnrK2lg05xmQ1PFog Y9Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=yq4oJMCDfCqiuSYPrGiR7TdBoQ/AyiNCejA6X9Nl+ck=; b=IcREJKZBPXC1iafLs+NcBXN57R+c3GpKZqusC0S9rrVkiywzLpsf+VjalNBUJCeCHl 9WWK5wojRu1mQWkexQyYyKw+5PD1shCXxgT2xs7CG4j78+qG4rby7H7RLnc9NQohxaFx eBshESOuuc4DgQdg0Jt0sMZPN396+8fZ8TfO6I5oUJM7tC3kyzYz/MaX17ebBI0/Gj4C FHKB/i8qhIptnfsZ880U7n9ZWUguTOavIBhYd+L6AdNk3fvx5FcCt8olNIq0Kwu3fdRJ 4evWnR8GkHn0LhCk43gTsGYRlFt8WpXYCBJYul1lPMTGAYQnrbjuCYpB8M4ZV/JB61cO LGcQ== X-Gm-Message-State: AOAM532Tn/b5VDffPTuFi0Z4OI9Ker/Mumo2VhaFAZUyd3w0r9n1qsPA 4TeMDR2026H+31v9BQYtsEYE1Q== X-Google-Smtp-Source: ABdhPJx6qUi9SRLbyFFX1g/1yaeZbkNDkB/nwXSfN7TIJM0D6xR1485+MD2fKPk/lbQ9P98gpQLvnA== X-Received: by 2002:a05:6512:2386:b0:473:a4e3:d4aa with SMTP id c6-20020a056512238600b00473a4e3d4aamr1639490lfv.448.1651822858278; Fri, 06 May 2022 00:40:58 -0700 (PDT) Received: from [192.168.1.211] ([37.153.55.125]) by smtp.gmail.com with ESMTPSA id bt24-20020a056512261800b0047255d2113asm570118lfb.105.2022.05.06.00.40.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 00:40:57 -0700 (PDT) Message-ID: Date: Fri, 6 May 2022 10:40:56 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v7 5/7] PCI: qcom: Handle MSIs routed to multiple GIC interrupts Content-Language: en-GB To: Rob Herring Cc: Andy Gross , Bjorn Andersson , Krzysztof Kozlowski , Jingoo Han , Gustavo Pimentel , Lorenzo Pieralisi , Bjorn Helgaas , Stanimir Varbanov , Manivannan Sadhasivam , Vinod Koul , linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org, devicetree@vger.kernel.org References: <20220505135407.1352382-1-dmitry.baryshkov@linaro.org> <20220505135407.1352382-6-dmitry.baryshkov@linaro.org> From: Dmitry Baryshkov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 06/05/2022 00:26, Rob Herring wrote: > On Thu, May 05, 2022 at 04:54:05PM +0300, Dmitry Baryshkov wrote: >> On some of Qualcomm platforms each group of 32 MSI vectors is routed to the >> separate GIC interrupt. Thus to receive higher MSI vectors properly, >> add separate msi_host_init()/msi_host_deinit() handling additional host >> IRQs. > > msi_host_init() has 1 user (keystone) as it doesn't use the DWC MSI > controller. But QCom does given the access to PCIE_MSI_INTR0_STATUS, > so mutiple MSI IRQ outputs must have been added in newer versions of the > DWC IP. If so, it's only a matter of time for another platform to > do the same thing. Maybe someone from Synopsys could confirm? This is a valid question, and if you check, first iterations of this patchset had this in the dwc core ([1], [2]). Exactly for the reason this might be usable for other platforms. Then I did some research for other platforms using DWC PCIe IP core. For example, both Tegra Xavier and iMX6 support up to 256 MSI vectors, they use DWC MSI IRQ controller. The iMX6 TRM explicitly describes using different MSI groups for different endpoints. The diagram shows 8 MSI IRQ signal lines. However in the end the signals from all groups are OR'ed to form a single host msi_ctrl_int. Thus currently I suppose that using multiple MSI IRQs is a peculiarity of Qualcomm platform. > > Therefore this should all be handled in the DWC core. In general, I > don't want to see more users nor more ops if we don't have to. Let's not > create ops for what can be handled as data. AFAICT, this is just number > of MSIs and # of MSIs per IRQ. It seems plausible another platform could > do something similar and supporting it in the core code wouldn't > negatively impact other platforms. I wanted to balance adding additional ops vs complicating the core for other platforms. And I still suppose that platform specifics should go to the platform driver. However if you prefer [1] and [2], we can go back to that implementation. [1]: https://lore.kernel.org/linux-arm-msm/20220427121653.3158569-2-dmitry.baryshkov@linaro.org/[2]: https://lore.kernel.org/linux-arm-msm/20220427121653.3158569-3-dmitry.baryshkov@linaro.org/ -- With best wishes Dmitry