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.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 C5B7AC3A589 for ; Tue, 20 Aug 2019 13:01:02 +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 9ABCE22D6D for ; Tue, 20 Aug 2019 13:01:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="I3I+RUvg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9ABCE22D6D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wCp7JDMMe8B9zQ3hxCaKsGYCqLLnw538lj2tTasxIoM=; b=I3I+RUvga5POZZEytodd7TJBU RreCJ3+cpQmGdJzeVOZTasz9/n+pO69Wt3fhBcankO7ea14mEaRlm0+zXOWP9BrJXcBk7P0J0/V3R 6zvyz/q2ruQvxfFc0/S+930DIMjRX8ERV0iwJpo/N6hl3lI/7J14kyNLDdwpQaqesUI4xHIpKwsi6 Nz4vD2Q5Y4sg+0tzFQ7OO5oTRPexM3TdLTH+dabTGoEudFFqZkrz4WyR6/fAqXpmZgISXmoJnUZqw 7JEECvUyakswhkTmAMpc2vcRwJz+oxFxlMWgvys9+CUsXXqJiY/ORyjbhjBF1A53Dju7krac8MZMj oVzRFu4Nw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i03l0-0001vU-4w; Tue, 20 Aug 2019 13:01:02 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i03kx-0001uo-Jw for linux-arm-kernel@lists.infradead.org; Tue, 20 Aug 2019 13:01:00 +0000 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 62189344; Tue, 20 Aug 2019 06:00:53 -0700 (PDT) Received: from [10.1.197.57] (e110467-lin.cambridge.arm.com [10.1.197.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 206CA3F246; Tue, 20 Aug 2019 06:00:51 -0700 (PDT) Subject: Re: [PATCH v2 17/17] iommu/arm-smmu: Add context init implementation hook To: Vivek Gautam , will@kernel.org References: <8306f3f1-925c-0b02-8103-9d4a510005b2@codeaurora.org> From: Robin Murphy Message-ID: <8bd76c3e-823d-86b2-785e-e80685edfa6c@arm.com> Date: Tue, 20 Aug 2019 14:00:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8306f3f1-925c-0b02-8103-9d4a510005b2@codeaurora.org> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190820_060059_698728_542CA377 X-CRM114-Status: GOOD ( 21.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: robdclark@gmail.com, gregory.clement@bootlin.com, bjorn.andersson@linaro.org, iommu@lists.linux-foundation.org, jcrouse@codeaurora.org, joro@8bytes.org, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 20/08/2019 11:15, Vivek Gautam wrote: [...] > Hi Robin, > > Sorry for responding late to this series. I have couple of doubts here > that I wanted to discuss. > > Are we standardizing these implementation specific ops? Each vendor > implementations will have something peculiar to take care. Things are > good right now with 'reset', 'cfg_probe', and 'init_context' hooks. > But, on top of vendor implementation details, there can be SoC specific > errata changes that need to be added. The idea behind the impl hooks is to try to have them in logical places which should be suitable for multiple different workarounds (e.g. init_context is arranged to allow replacing smmu_domain->tlb_ops) - I want to avoid proliferating dozens of them that end up each being specific to individual workarounds, but that's not to say that the design we're starting with here is by any means complete or final. We're almost certainly going to evolve more hooks (and possibly adjust the current ones) in future. > Moreover, adding implementation data based on __model__ may not suffice > for long. Do you suggest adding any other data variable in the > ARM_SMMU_MATCH_DATA? As commented in the code, the setup for the existing quirks works out to be deceptively simple, and it can and will change. Ultimately I'm fully expecting to end up with complex logic hanging off arm_smmu_impl_init() to detect the integration details and compose sets of impl hooks in various ways as appropriate - I doubt that it's going to be practical or even possible to have static data for *every* possibility. The fundamental shape of the code is based on "model" quirks being more general than "integration" quirks, such that the latter should be in a position to dynamically inherit (or statically replace, in simple cases) the hooks of the former. > To show SoC specific needs, I have the change attached in this email to > take care of the SDM845 'wait-for-safe' sequence. > Please take a look. Other than that introducing QCOM_SMMU500 seems to be redundant, and whether it also needs ACPI-based detection, that certainly seems fairly reasonable for a simple isolated workaround. However, is the firmware call really a one-off probe-time thing? If the firmware does take care of preserving the wait-for-safe state across suspend/resume/hibernate/etc. then fair enough, but I would have assumed that the reset hook would be the more likely place to put it. Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel