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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH autolearn=unavailable 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 DB8DAC4321A for ; Mon, 10 Jun 2019 23:21:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B2EB120859 for ; Mon, 10 Jun 2019 23:21:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Ia88klZi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390632AbfFJXVt (ORCPT ); Mon, 10 Jun 2019 19:21:49 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:37897 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390500AbfFJXVs (ORCPT ); Mon, 10 Jun 2019 19:21:48 -0400 Received: by mail-pg1-f195.google.com with SMTP id v11so5820132pgl.5 for ; Mon, 10 Jun 2019 16:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=message-id:mime-version:content-transfer-encoding:in-reply-to :references:from:cc:subject:to:user-agent:date; bh=plP4lWzyc7KaP3+pJsQZD0STOQAjwlX5Lih5GcMmDJ4=; b=Ia88klZiLqqn+j77ynmisXpWoRAoBA5Tnwyh4ijmhp1xxV5oj/ZHXH5U4RrplyPA6+ Z+mqWkKamnG/AIiu28TZklif0bd8WbDTYKsy8jZzAna1LBBoyo+m03ej5AWiXoXSyVSa NFATkigEqY6q686cS9NUJNWt83mNDeVPPI5x8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version :content-transfer-encoding:in-reply-to:references:from:cc:subject:to :user-agent:date; bh=plP4lWzyc7KaP3+pJsQZD0STOQAjwlX5Lih5GcMmDJ4=; b=kF5Amj5jc13ZtAoSa8yD6QrvH7wFnLzGIZTaXkxNRK0jy1zeG1bYjUMUmWLIpHC5vt 8ORCO6U4IZfupNFfqZofgqDbMCM8ejz64JQkvdbd3jXpmT/fw1PaNN2QMvklrNfVmwtd bcfTSNsxfMCOm+kLP0zs3PZ4zIzuqGK+pTJpREnw78QoWaadbarTDPJHlGkjmAyqIUn6 em0z8YqND/YA8iRN4lqkac9XTSYXsGjzQkWjB64nFA86eL2mO5IdPY8xD9DfbJxQozBz GTvX5jbtOF5/spoJ9bN4NT03rOfSaWDACdbS7JU/PkVykFv1AjVz0j4ie3Q6zW3WZU1d oimQ== X-Gm-Message-State: APjAAAWpYRAQvqc2RyTg63rnBVPmwBGsjwZ1LoFUsm6UlVsNjjbxRYBg hOCRAOAL9IJqZoituF5v0wg9Yw== X-Google-Smtp-Source: APXvYqzSvKTSLb5deeAUwGfek6GUKMKTsYrNks5Xjyq7zYVzKqmuGUE+s2P4LvkW270Mqa8KPtKdcQ== X-Received: by 2002:a62:2ec4:: with SMTP id u187mr75848316pfu.84.1560208907972; Mon, 10 Jun 2019 16:21:47 -0700 (PDT) Received: from chromium.org ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id c6sm18136367pfm.163.2019.06.10.16.21.46 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 10 Jun 2019 16:21:46 -0700 (PDT) Message-ID: <5cfee60a.1c69fb81.584d9.cf12@mx.google.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20190604222939.195471-1-swboyd@chromium.org> <20190604223700.GE4814@minitux> <5cf6f4bb.1c69fb81.c39da.5496@mx.google.com> <5cf82c6f.1c69fb81.9e342.dbda@mx.google.com> From: Stephen Boyd Cc: Bjorn Andersson , Andy Gross , open list , linux-arm-msm , Sibi Sankar Subject: Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1 To: Vivek Gautam User-Agent: alot/0.8.1 Date: Mon, 10 Jun 2019 16:21:45 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Vivek Gautam (2019-06-06 04:17:16) > Hi Stephen, >=20 > On Thu, Jun 6, 2019 at 2:27 AM Stephen Boyd wrote: > > > > Quoting Vivek Gautam (2019-06-04 21:55:26) > > > > > > > > Cheza will throw faults for anything that is programmed with TZ on mtp > > > as all of that should be handled in HLOS. The firmwares of all these > > > peripherals assume that the SID reservation is done (whether in TZ or= HLOS). > > > > > > I am inclined to moving the iommus property for all 'TZ' to board dts= files. > > > MTP wouldn't need those SIDs. So, the SOC level dtsi will have just t= he > > > HLOS SIDs. > > > > So you're saying you'd like to have the SID be <&apps_smmu 0x6c3 0x0> in > > the sdm845.dtsi file and then override this on Cheza because our SID is > > different (possibly because we don't use GSI)? Why can't we program the > > SID in Cheza firmware to match the "HLOS" SID of 0x6c3? >=20 > Sorry my bad, I missed the overriding part. > May be we add the lists of SIDs in board dts only. So, cheza dts will > have all these SIDs - > <&apps_smmu 0x6c0 0x3> // for both 0x6c0 (TZ) and 0x6c3 (HLOS) > <&apps_smmu 0x6d6 0x0> // if we want to use the GSI dma. > and > MTP will have > <&apps_smmu 0x6c3 0x0> > <&apps_smmu 0x6d6 0x0> > WDUT? I'd prefer to fix the firmware so that the HLOS SID is used even on this board. Making Cheza use something different from MTP doesn't sound so good. Do you know how that works? Is there some configuration register or something that I should be looking for to see why the SID is not the HLOS one? It's definitely generating SIDs for the TZ SID (0x6c0), but I'd like to make sure that we can't change it because it's tied to some hardware signal like the NS bit and/or the Execution Level. Hopefully it's a config and then our difference from MTP can be minimized. As far as I can tell, HLOS on SDM845 has always used GPI (yet another DMA engine) to do the DMA transfers. And the GPI is the hardware block that uses the SID of 0x6d6 above, so putting that into iommus for the geniqup doesn't make any sense given that GPI is another node. Can you confirm this is the case? Furthermore, the SID of 0x6c3 sounds untested? Has it ever been generated on SDM845 MTP? If we ever support GPI, I'd expect to see something like this in DT: gpi_dma: gpi@a00000 { reg =3D <0x00a00000 0x60000>; iommus =3D <&apps_smmu 0x6d6 0x0>; ... }; geniqup@ac0000 { reg =3D <0x00ac0000 0x6000>; iommus =3D <&apps_smmu 0x6c3 0x0>; i2c@....{ dmas =3D <&gpi_dma ....>; }; But now I'm worried that the geniqup needs the proper geniqup wrapper clks to talk to it. Most likely the GPI is embedded inside the geniqup wrapper and sits right next to the bus to do bus DMA mastering. From the DT side, it means we should either put it inside the geniqup node, or we should add the wrapper clks to the GPI node and hope things work out with regards to clks and shared resources being used at the right time. If we're left with trying to figure out how to express the different SIDs depending on the CPU execution state then it may be easier to push for GPI upstreaming and use that dma engine to "fold" the SID numberspace into one SID for the GPI. This would avoid having to deal with the HLOS vs. TZ SID problem by adding a whole other driver. Or we could just rip out the non-GPI DMA support in this driver because the SID is all confused.