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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 4B6B5C352A3 for ; Tue, 11 Feb 2020 13:04:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2AEFF20873 for ; Tue, 11 Feb 2020 13:04:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728673AbgBKNET (ORCPT ); Tue, 11 Feb 2020 08:04:19 -0500 Received: from foss.arm.com ([217.140.110.172]:45682 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728521AbgBKNET (ORCPT ); Tue, 11 Feb 2020 08:04:19 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D941130E; Tue, 11 Feb 2020 05:04:18 -0800 (PST) Received: from [192.168.1.123] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 583D83F6CF; Tue, 11 Feb 2020 05:04:13 -0800 (PST) Subject: Re: [PATCHv9 00/12] PCI: Recode Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs To: Laurentiu Tudor , Li Yang , Olof Johansson Cc: "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , Lorenzo Pieralisi , "arnd@arndb.de" , "m.karthikeyan@mobiveil.co.in" , "linux-pci@vger.kernel.org" , "Z.q. Hou" , "l.subrahmanya@mobiveil.co.in" , "will.deacon@arm.com" , Russell King - ARM Linux admin , "linux-kernel@vger.kernel.org" , "M.h. Lian" , "robh+dt@kernel.org" , Xiaowei Bao , "catalin.marinas@arm.com" , "bhelgaas@google.com" , "andrew.murray@arm.com" , "shawnguo@kernel.org" , Mingkai Hu , "linux-arm-kernel@lists.infradead.org" References: <20191120034451.30102-1-Zhiqiang.Hou@nxp.com> <20200110153347.GA29372@e121166-lin.cambridge.arm.com> <20200210152257.GD25745@shell.armlinux.org.uk> From: Robin Murphy Message-ID: Date: Tue, 11 Feb 2020 13:04:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 2020-02-11 12:13 pm, Laurentiu Tudor wrote: [...] >> This is a known issue about DPAA2 MC bus not working well with SMMU >> based IO mapping.  Adding Laurentiu to the chain who has been looking >> into this issue. > > Yes, I'm closely following the issue. I actually have a workaround > (attached) but haven't submitted as it will probably raise a lot of > eyebrows. In the mean time I'm following some discussions [1][2][3] on > the iommu list which seem to try to tackle what appears to be a similar > issue but with framebuffers. My hope is that we will be able to leverage > whatever turns out. Indeed it's more general than framebuffers - in fact there was a specific requirement from the IORT side to accommodate network/storage controllers with in-memory firmware/configuration data/whatever set up by the bootloader that want to be handed off 'live' to Linux because the overhead of stopping and restarting them is impractical. Thus this DPAA2 setup is very much within scope of the desired solution, so please feel free to join in (particularly on the DT parts) :) As for right now, note that your patch would only be a partial mitigation to slightly reduce the fault window but not remove it entirely. To be robust the SMMU driver *has* to know about live streams before the first arm_smmu_reset() - hence the need for generic firmware bindings - so doing anything from the MC driver is already too late (and indeed the current iommu_request_dm_for_dev() mechanism is itself a microcosm of the same problem). > In the mean time, can you try the workaround Leo suggested? Agreed, I'd imagine the command-line option is probably the best choice for these platforms, since it's likely to be easier to set that by default in the bootloader than faff with rebuilding generic kernel configs. Robin. > [1] https://patchwork.kernel.org/patch/11327667/ > [2] https://patchwork.kernel.org/patch/10967729/ > [3] https://patchwork.kernel.org/cover/11279577/ > > --- > Best Regards, Laurentiu > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >