[PATCH v4 3/3] memory: mtk-smi: Add mt8192 support
Add mt8192 smi support.
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 691e4c344cf8..ac350f8d1e20 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -268,6 +268,10 @@ static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 =
{
/* IPU0 | IPU1 | CCU */
};
+static const struct mtk_smi_larb_gen mtk_smi_larb_mt8192 = {
+ .config_port= mtk_smi_larb_config_port_gen2_general,
+};
+
static const struct of_device_id mtk_smi_larb_of_ids[] = {
{
.compatible = "mediatek,mt8167-smi-larb",
@@ -293,6 +297,10 @@ static const struct of_device_id mtk_smi_larb_of_ids[] = {
.compatible = "mediatek,mt8183-smi-larb",
.data = _smi_larb_mt8183
},
+ {
+ .compatible = "mediatek,mt8192-smi-larb",
+ .data = _smi_larb_mt8192
+ },
{}
};
@@ -432,6 +440,13 @@ static const struct mtk_smi_common_plat
mtk_smi_common_mt8183 = {
F_MMU1_LARB(7),
};
+static const struct mtk_smi_common_plat mtk_smi_common_mt8192 = {
+ .gen = MTK_SMI_GEN2,
+ .has_gals = true,
+ .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
+ F_MMU1_LARB(6),
+};
+
static const struct of_device_id mtk_smi_common_of_ids[] = {
{
.compatible = "mediatek,mt8173-smi-common",
@@ -457,6 +472,10 @@ static const struct of_device_id mtk_smi_common_of_ids[] =
{
.compatible = "mediatek,mt8183-smi-common",
.data = _smi_common_mt8183,
},
+ {
+ .compatible = "mediatek,mt8192-smi-common",
+ .data = _smi_common_mt8192,
+ },
{}
};
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 2/3] dt-bindings: memory: mediatek: Add mt8192 support
Add mt8192 smi support in the bindings. Signed-off-by: Yong Wu Reviewed-by: Rob Herring --- .../bindings/memory-controllers/mediatek,smi-common.yaml | 4 +++- .../bindings/memory-controllers/mediatek,smi-larb.yaml| 2 ++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index e050a0c2aed6..a5b5adce0310 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -16,7 +16,7 @@ description: |+ MediaTek SMI have two generations of HW architecture, here is the list which generation the SoCs use: generation 1: mt2701 and mt7623. - generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183. + generation 2: mt2712, mt6779, mt8167, mt8173, mt8183 and mt8192. There's slight differences between the two SMI, for generation 2, the register which control the iommu port is at each larb's register base. But @@ -35,6 +35,7 @@ properties: - mediatek,mt8167-smi-common - mediatek,mt8173-smi-common - mediatek,mt8183-smi-common + - mediatek,mt8192-smi-common - description: for mt7623 items: @@ -98,6 +99,7 @@ allOf: enum: - mediatek,mt6779-smi-common - mediatek,mt8183-smi-common + - mediatek,mt8192-smi-common then: properties: diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index a11a105e872f..0376700e2cd2 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -23,6 +23,7 @@ properties: - mediatek,mt8167-smi-larb - mediatek,mt8173-smi-larb - mediatek,mt8183-smi-larb + - mediatek,mt8192-smi-larb - description: for mt7623 items: @@ -106,6 +107,7 @@ allOf: - mediatek,mt2712-smi-larb - mediatek,mt6779-smi-larb - mediatek,mt8167-smi-larb + - mediatek,mt8192-smi-larb then: required: -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 0/3] MT8192 SMI support
This patchset mainly adds SMI support for mt8192. It comes from the patchset[1]. I seperate the smi part into this patchset. And the two part(IOMMU/SMI) patchset don't depend on each other. Rebase on v5.10-rc1. changenote: v4: add if-then segment in the binding. v3: [1]. [1] https://lore.kernel.org/linux-iommu/20200930070647.10188-1-yong...@mediatek.com/ Yong Wu (3): dt-bindings: memory: mediatek: Convert SMI to DT schema dt-bindings: memory: mediatek: Add mt8192 support memory: mtk-smi: Add mt8192 support .../mediatek,smi-common.txt | 50 -- .../mediatek,smi-common.yaml | 142 ++ .../memory-controllers/mediatek,smi-larb.txt | 50 -- .../memory-controllers/mediatek,smi-larb.yaml | 131 drivers/memory/mtk-smi.c | 19 +++ 5 files changed, 292 insertions(+), 100 deletions(-) delete mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml delete mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml -- 2.18.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: WARNING in dma_map_page_attrs
> From: h...@lst.de > Sent: Wednesday, October 28, 2020 11:01 PM > > On Tue, Oct 27, 2020 at 12:52:30PM +, Parav Pandit wrote: > > > > > From: h...@lst.de > > > Sent: Tuesday, October 27, 2020 1:41 PM > > > > > > On Mon, Oct 26, 2020 at 05:23:48AM +, Parav Pandit wrote: > > > > Hi Christoph, > > > > > > > > > From: Jakub Kicinski > > > > > Sent: Saturday, October 24, 2020 11:45 PM > > > > > > > > > > CC: rdma, looks like rdma from the stack trace > > > > > > > > > > On Fri, 23 Oct 2020 20:07:17 -0700 syzbot wrote: > > > > > > syzbot has found a reproducer for the following issue on: > > > > > > > > > > > > HEAD commit:3cb12d27 Merge tag 'net-5.10-rc1' of > > > git://git.kernel.org/.. > > > > > > > > In [1] you mentioned that dma_mask should not be set for > dma_virt_ops. > > > > So patch [2] removed it. > > > > > > > > But check to validate the dma mask for all dma_ops was added in [3]. > > > > > > > > What is the right way? Did I misunderstood your comment about > > > dma_mask in [1]? > > > > > > No, I did not say we don't need the mask. I said copying over the > > > various dma-related fields from the parent is bogus. > > > > > > I think rxe (and ther other drivers/infiniband/sw drivers) need a > > > simple dma_coerce_mask_and_coherent and nothing else. > > > > I see. Does below fix make sense? > > Is DMA_MASK_NONE correct? > > DMA_MASK_NONE is gone in 5.10. I think you want DMA_BIT_MASK(64). > That isn't actually correct for 32-bit platforms, but good enough. Ok. thanks for the input. Sending updated fix to set 64-bit mask for 64-bit platform and 32-bit mask otherwise. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 01/24] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema
On Fri, 2020-10-02 at 12:58 +0200, Krzysztof Kozlowski wrote: > On Wed, Sep 30, 2020 at 03:06:24PM +0800, Yong Wu wrote: > > Convert MediaTek IOMMU to DT schema. > > > > Signed-off-by: Yong Wu > > --- > > .../bindings/iommu/mediatek,iommu.txt | 103 > > .../bindings/iommu/mediatek,iommu.yaml| 154 ++ > > 2 files changed, 154 insertions(+), 103 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/iommu/mediatek,iommu.txt > > create mode 100644 > > Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > > ... > > diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > > b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > > new file mode 100644 > > index ..eae773ad53a3 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > > @@ -0,0 +1,154 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > You relicense GPLv2 content so you need acks/signed-offs from every > author: > > - Fabien Parent > - Chao Hao > - Matthias Brugger > - Honghui Zhang > (assuming yours is implicit). > > Please resend CC-ing all the people. Sorry, I really missed this mail. I have sent v4 only for smi. the iommu part still need some time. The license "GPL-2.0-only OR BSD-2-Clause" is requested when we run check_patch. That means each converting YAML need all contributors' ack/SoB? I have added their CC in v4 smi binding except honghui whose address is not avalable now. I will act for him. > > > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/iommu/mediatek,iommu.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: MediaTek IOMMU Architecture Implementation > > + [snip..] > > + mediatek,larbs: > > +$ref: /schemas/types.yaml#/definitions/phandle-array > > +description: | > > + List of phandle to the local arbiters in the current Socs. > > + Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It must > > sort > > + according to the local arbiter index, like larb0, larb1, larb2... > > How many items? I will add maxitems property. Thanks. > > Best regards, > Krzysztof > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv7 7/7] iommu: arm-smmu-impl: Add a space before open parenthesis
Fix the checkpatch warning for space required before the open
parenthesis.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index ffaf3f91ba52..f16da4a21270 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -12,7 +12,7 @@
static int arm_smmu_gr0_ns(int offset)
{
- switch(offset) {
+ switch (offset) {
case ARM_SMMU_GR0_sCR0:
case ARM_SMMU_GR0_sACR:
case ARM_SMMU_GR0_sGFSR:
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/3] drm: panfrost: Coherency support
On 22/09/2020 16:16, Robin Murphy wrote: > Hi all, > > Here's a quick v2 with the tags so far picked up and some inline > commentary about the shareability domains for the pagetable code. > > Robin. > > > Robin Murphy (3): > iommu/io-pgtable-arm: Support coherency for Mali LPAE > drm/panfrost: Support cache-coherent integrations > arm64: dts: meson: Describe G12b GPU as coherent > > arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4 > drivers/gpu/drm/panfrost/panfrost_device.h | 1 + > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 ++ > drivers/gpu/drm/panfrost/panfrost_gem.c | 2 ++ > drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 + > drivers/iommu/io-pgtable-arm.c | 11 ++- > 6 files changed, 20 insertions(+), 1 deletion(-) > Applying to drm-misc-next Thanks ! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 1/3] dt-bindings: memory: mediatek: Convert SMI to DT schema
Convert MediaTek SMI to DT schema.
CC: Fabien Parent
CC: Ming-Fan Chen
CC: Matthias Brugger
Signed-off-by: Yong Wu
---
.../mediatek,smi-common.txt | 50 ---
.../mediatek,smi-common.yaml | 140 ++
.../memory-controllers/mediatek,smi-larb.txt | 50 ---
.../memory-controllers/mediatek,smi-larb.yaml | 129
4 files changed, 269 insertions(+), 100 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
create mode 100644
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
delete mode 100644
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
create mode 100644
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
diff --git
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
deleted file mode 100644
index dbafffe3f41e..
---
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-SMI (Smart Multimedia Interface) Common
-
-The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
-
-Mediatek SMI have two generations of HW architecture, here is the list
-which generation the SoCs use:
-generation 1: mt2701 and mt7623.
-generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183.
-
-There's slight differences between the two SMI, for generation 2, the
-register which control the iommu port is at each larb's register base. But
-for generation 1, the register is at smi ao base(smi always on register
-base). Besides that, the smi async clock should be prepared and enabled for
-SMI generation 1 to transform the smi clock into emi clock domain, but that is
-not needed for SMI generation 2.
-
-Required properties:
-- compatible : must be one of :
- "mediatek,mt2701-smi-common"
- "mediatek,mt2712-smi-common"
- "mediatek,mt6779-smi-common"
- "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
- "mediatek,mt8167-smi-common"
- "mediatek,mt8173-smi-common"
- "mediatek,mt8183-smi-common"
-- reg : the register and size of the SMI block.
-- power-domains : a phandle to the power domain of this local arbiter.
-- clocks : Must contain an entry for each entry in clock-names.
-- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries
- for generation 2 smi HW as follows:
- - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
- the register.
- - "smi" : It's the clock for transfer data and command.
- They may be the same if both source clocks are the same.
- - "async" : asynchronous clock, it help transform the smi clock into the emi
- clock domain, this clock is only needed by generation 1 smi HW.
- and these 2 option clocks for generation 2 smi HW:
- - "gals0": the path0 clock of GALS(Global Async Local Sync).
- - "gals1": the path1 clock of GALS(Global Async Local Sync).
- Here is the list which has this GALS: mt6779 and mt8183.
-
-Example:
- smi_common: smi@14022000 {
- compatible = "mediatek,mt8173-smi-common";
- reg = <0 0x14022000 0 0x1000>;
- power-domains = < MT8173_POWER_DOMAIN_MM>;
- clocks = < CLK_MM_SMI_COMMON>,
-< CLK_MM_SMI_COMMON>;
- clock-names = "apb", "smi";
- };
diff --git
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
new file mode 100644
index ..e050a0c2aed6
--- /dev/null
+++
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/mediatek,smi-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SMI (Smart Multimedia Interface) Common
+
+maintainers:
+ - Yong Wu
+
+description: |+
+ The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml
+
+ MediaTek SMI have two generations of HW architecture, here is the list
+ which generation the SoCs use:
+ generation 1: mt2701 and mt7623.
+ generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183.
+
+ There's slight differences between the two SMI, for generation 2, the
+ register which control the iommu port is at each larb's register base. But
+ for generation 1, the register is at smi ao base(smi always on register
+ base). Besides that, the smi async clock should be prepared and enabled for
+ SMI generation 1 to transform the smi clock into emi clock domain, but that
is
+ not needed for SMI generation 2.
+
+properties:
+ compatible:
+oneOf:
+ - enum:
Re: [PATCH v2 5/5] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
On Wed, Oct 28, 2020 at 6:51 AM Will Deacon wrote: > On Tue, Oct 27, 2020 at 10:53:47PM -0700, John Stultz wrote: > > Alternatively, I'm considering trying to switch the module dependency > > annotation so that the CONFIG_QCOM_SCM modularity depends on ARM_SMMU > > being a module. But that is sort of putting the restriction on the > > callee instead of the caller (sort of flipping the meaning of the > > depends), which feels prone to later trouble (and with multiple users > > of CONFIG_QCOM_SCM needing similar treatment, it would make it > > difficult to discover the right combination of configs needed to allow > > it to be a module). > > > > Anyway, I wanted to reach out to see if you had any further ideas > > here. Sorry for letting such a large time gap pass! > > Well we can always go with your original hack, if it helps? > > https://lore.kernel.org/linux-iommu/20200714075603.GE4277@willie-the-truck/ Yea. After trying a few more ideas that didn't pan out, I think I'm going to fall back to that. :( thanks -john ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: Clarify .of_xlate assumptions
Hi Robin, On 29.10.2020 16:34, Robin Murphy wrote: > A common idiom for .of_xlate is to use of_find_device_by_node() to > retrieve the relevant IOMMU instance data when translating IOMMU > specifiers for a client device. Although it's slightly roundabout, > this is simply looking up something we know exists - if it *were* > to return NULL, that would mean that no platform device is associated > with the given DT node, therefore the driver couldn't have probed > and called iommu_device_register() with the ops that .of_xlate was > called from in the first place. By construction, we can also assume > that the instance data for any registered IOMMU must be valid. > > This isn't necessarily obvious at first glance, though, so add some > comments to document these assumptions in-place. > > Suggested-by: Yu Kuai > Signed-off-by: Robin Murphy > --- > drivers/iommu/arm/arm-smmu/qcom_iommu.c | 7 --- > drivers/iommu/exynos-iommu.c| 15 ++- Acked-by: Marek Szyprowski > drivers/iommu/ipmmu-vmsa.c | 13 ++--- > drivers/iommu/mtk_iommu.c | 8 > drivers/iommu/rockchip-iommu.c | 5 - > drivers/iommu/sun50i-iommu.c| 5 - > 6 files changed, 28 insertions(+), 25 deletions(-) > > Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 1/2] pinctrl: qcom: Allow pinctrl-msm code to be loadable as a module
Tweaks to allow pinctrl-msm code to be loadable as a module. This is needed in order to support having the qcom-scm driver, which pinctrl-msm calls into, configured as a module. This requires that we tweak Kconfigs selecting PINCTRL_MSM to also depend on QCOM_SCM || QCOM_SCM=n so that we match the module setting of QCOM_SCM. Unlike the previous revision of this patch: https://lore.kernel.org/lkml/20200625001039.56174-5-john.stu...@linaro.org/ this version reworks PINCTRL_MSM to be a visible option and instead of having the various SoC specific drivers select PINCTRL_MSM, this switches those configs to depend on PINCTRL_MSM. This avoids adding the oddish looking: "depend on QCOM_SCM || QCOM_SCM=n" to every SoC specific driver, as that becomes a maintenance headache. Cc: Andy Gross Cc: Bjorn Andersson Cc: Joerg Roedel Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Cc: Linus Walleij Cc: Maulik Shah Cc: Lina Iyer Cc: Saravana Kannan Cc: Todd Kjos Cc: Greg Kroah-Hartman Cc: linux-arm-...@vger.kernel.org Cc: iommu@lists.linux-foundation.org Cc: linux-g...@vger.kernel.org Signed-off-by: John Stultz --- v2: * Module description and whitespace fixes suggested by Bjorn * Added QCOM_SCM || QCOM_SCM=n bits on Kconfigs selecting PINCTRL_MSM. Reported by both Todd and Bjorn. v3: * Make sure the QCOM_SCM || QCOM_SCM=n trick is commented v4: * Rework "select PINCTRL_MSM" to "depends on PINCTRL_MSM" to consolidate the QCOM_SCM dependency. --- drivers/pinctrl/qcom/Kconfig | 49 +++--- drivers/pinctrl/qcom/pinctrl-msm.c | 2 ++ 2 files changed, 27 insertions(+), 24 deletions(-) diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig index 5fe7b8aaf69d8..8bb786ed152dd 100644 --- a/drivers/pinctrl/qcom/Kconfig +++ b/drivers/pinctrl/qcom/Kconfig @@ -2,7 +2,8 @@ if (ARCH_QCOM || COMPILE_TEST) config PINCTRL_MSM - bool + tristate "Qualcomm core pin controller driver" + depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y select PINMUX select PINCONF select GENERIC_PINCONF @@ -13,7 +14,7 @@ config PINCTRL_MSM config PINCTRL_APQ8064 tristate "Qualcomm APQ8064 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm TLMM block found in the Qualcomm APQ8064 platform. @@ -21,7 +22,7 @@ config PINCTRL_APQ8064 config PINCTRL_APQ8084 tristate "Qualcomm APQ8084 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm TLMM block found in the Qualcomm APQ8084 platform. @@ -29,7 +30,7 @@ config PINCTRL_APQ8084 config PINCTRL_IPQ4019 tristate "Qualcomm IPQ4019 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm TLMM block found in the Qualcomm IPQ4019 platform. @@ -37,7 +38,7 @@ config PINCTRL_IPQ4019 config PINCTRL_IPQ8064 tristate "Qualcomm IPQ8064 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm TLMM block found in the Qualcomm IPQ8064 platform. @@ -45,7 +46,7 @@ config PINCTRL_IPQ8064 config PINCTRL_IPQ8074 tristate "Qualcomm Technologies, Inc. IPQ8074 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm Technologies Inc. TLMM block found on the @@ -55,7 +56,7 @@ config PINCTRL_IPQ8074 config PINCTRL_IPQ6018 tristate "Qualcomm Technologies, Inc. IPQ6018 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm Technologies Inc. TLMM block found on the @@ -65,7 +66,7 @@ config PINCTRL_IPQ6018 config PINCTRL_MSM8226 tristate "Qualcomm 8226 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm Technologies Inc TLMM block found on the Qualcomm @@ -74,7 +75,7 @@ config PINCTRL_MSM8226 config PINCTRL_MSM8660 tristate "Qualcomm 8660 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux,
[PATCH v4 2/2] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
Allow the qcom_scm driver to be loadable as a permenent module.
This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to
ensure that drivers that call into the qcom_scm driver are
also built as modules. While not ideal in some cases its the
only safe way I can find to avoid build errors without having
those drivers select QCOM_SCM and have to force it on (as
QCOM_SCM=n can be valid for those drivers).
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Linus Walleij
Cc: Maulik Shah
Cc: Lina Iyer
Cc: Saravana Kannan
Cc: Todd Kjos
Cc: Greg Kroah-Hartman
Cc: linux-arm-...@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Cc: linux-g...@vger.kernel.org
Acked-by: Greg Kroah-Hartman
Signed-off-by: John Stultz
---
v3: Fix __arm_smccc_smc build issue reported by
kernel test robot
v4: Add "depends on QCOM_SCM || !QCOM_SCM" bit to ath10k
config that requires it.
---
drivers/firmware/Kconfig| 4 ++--
drivers/firmware/Makefile | 3 ++-
drivers/firmware/qcom_scm.c | 4
drivers/iommu/Kconfig | 2 ++
drivers/net/wireless/ath/ath10k/Kconfig | 1 +
5 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 3315e3c215864..5e369928bc567 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -235,8 +235,8 @@ config INTEL_STRATIX10_RSU
Say Y here if you want Intel RSU support.
config QCOM_SCM
- bool
- depends on ARM || ARM64
+ tristate "Qcom SCM driver"
+ depends on (ARM && HAVE_ARM_SMCCC) || ARM64
select RESET_CONTROLLER
config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 5e013b6a3692e..523173cbff335 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -17,7 +17,8 @@ obj-$(CONFIG_ISCSI_IBFT) += iscsi_ibft.o
obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o
obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
obj-$(CONFIG_FW_CFG_SYSFS) += qemu_fw_cfg.o
-obj-$(CONFIG_QCOM_SCM) += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
+obj-$(CONFIG_QCOM_SCM) += qcom-scm.o
+qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 7be48c1bec96d..6f431b73e617d 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -1280,6 +1280,7 @@ static const struct of_device_id qcom_scm_dt_match[] = {
{ .compatible = "qcom,scm" },
{}
};
+MODULE_DEVICE_TABLE(of, qcom_scm_dt_match);
static struct platform_driver qcom_scm_driver = {
.driver = {
@@ -1295,3 +1296,6 @@ static int __init qcom_scm_init(void)
return platform_driver_register(_scm_driver);
}
subsys_initcall(qcom_scm_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. SCM driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 04878caf6da49..c64d7a2b65134 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -248,6 +248,7 @@ config SPAPR_TCE_IOMMU
config ARM_SMMU
tristate "ARM Ltd. System MMU (SMMU) Support"
depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
+ depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
@@ -375,6 +376,7 @@ config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
+ depends on QCOM_SCM=y
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU
diff --git a/drivers/net/wireless/ath/ath10k/Kconfig
b/drivers/net/wireless/ath/ath10k/Kconfig
index 40f91bc8514d8..a490e78890017 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -44,6 +44,7 @@ config ATH10K_SNOC
tristate "Qualcomm ath10k SNOC support"
depends on ATH10K
depends on ARCH_QCOM || COMPILE_TEST
+ depends on QCOM_QCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
select QCOM_QMI_HELPERS
help
This module adds support for integrated WCN3990 chip connected
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v6 4/5] iommu/vt-d: Add iommu_ops support for subdevice bus
> From: Lu Baolu
> Sent: Friday, October 30, 2020 12:58 PM
>
> The iommu_ops will only take effect when INTEL_IOMMU_SCALABLE_IOV
> kernel
> option is selected. It applies to any device passthrough framework which
> implements an underlying bus for the subdevices.
>
> - Subdevice probe:
> When a subdevice is created and added to the bus, iommu_probe_device()
> will be called, where the device will be probed by the iommu core. An
> iommu group will be allocated and the device will be added to it. The
> default domain won't be allocated since there's no use case of using a
> subdevice in the host kernel at this time being. However, it's pretty
> easy to add this support later.
>
> - Domain alloc/free/map/unmap/iova_to_phys operations:
> For such ops, we just reuse those for PCI/PCIe devices.
One question. Just be curious whether every IOMMU vendor supports
only one iommu_ops for all bus types. For Intel obviously the answer is
yes. But if a vendor supports bus-type specific iommu_ops for physical
devices, this may impose a restriction to VFIO or other passthrough
frameworks, because VFIO today maintains only one mdev bus while the
parent devices could come from different bus types. In the end the ops
for subdevice should be same as the one used for the parent. Then it may
require VFIO to organize subdevices based on parent bus types.
>
> - Domain attach/detach operations:
> It depends on whether the parent device supports IOMMU_DEV_FEAT_AUX
> feature. If so, the domain will be attached to the parent device as an
> aux-domain; Otherwise, it will be attached to the parent as a primary
> domain.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/Kconfig | 13
> drivers/iommu/intel/Makefile | 1 +
> drivers/iommu/intel/iommu.c | 5 ++
> drivers/iommu/intel/siov.c | 119 +++
> include/linux/intel-iommu.h | 4 ++
> 5 files changed, 142 insertions(+)
> create mode 100644 drivers/iommu/intel/siov.c
>
> diff --git a/drivers/iommu/intel/Kconfig b/drivers/iommu/intel/Kconfig
> index 28a3d1596c76..94edc332f558 100644
> --- a/drivers/iommu/intel/Kconfig
> +++ b/drivers/iommu/intel/Kconfig
> @@ -86,3 +86,16 @@ config INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
> is not selected, scalable mode support could also be enabled by
> passing intel_iommu=sm_on to the kernel. If not sure, please use
> the default value.
> +
> +config INTEL_IOMMU_SCALABLE_IOV
INTEL_IOMMU_SUBDEVICE? if just talking from IOMMU p.o.v...
> + bool "Support for Intel Scalable I/O Virtualization"
> + depends on INTEL_IOMMU
> + select VFIO
> + select VFIO_MDEV
> + select VFIO_MDEV_DEVICE
> + help
> + Intel Scalable I/O virtualization (SIOV) is a hardware-assisted
> + PCIe subdevices virtualization. With each subdevice tagged with
> + an unique ID(PCI/PASID) the VT-d hardware could identify, hence
> + isolate DMA transactions from different subdevices on a same PCIe
> + device. Selecting this option will enable the support.
> diff --git a/drivers/iommu/intel/Makefile b/drivers/iommu/intel/Makefile
> index fb8e1e8c8029..f216385d5d59 100644
> --- a/drivers/iommu/intel/Makefile
> +++ b/drivers/iommu/intel/Makefile
> @@ -4,4 +4,5 @@ obj-$(CONFIG_INTEL_IOMMU) += iommu.o pasid.o
> obj-$(CONFIG_INTEL_IOMMU) += trace.o
> obj-$(CONFIG_INTEL_IOMMU_DEBUGFS) += debugfs.o
> obj-$(CONFIG_INTEL_IOMMU_SVM) += svm.o
> +obj-$(CONFIG_INTEL_IOMMU_SCALABLE_IOV) += siov.o
> obj-$(CONFIG_IRQ_REMAP) += irq_remapping.o
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 1454fe74f3ba..dafd8069c2af 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -4298,6 +4298,11 @@ int __init intel_iommu_init(void)
> up_read(_global_lock);
>
> bus_set_iommu(_bus_type, _iommu_ops);
> +
> +#ifdef CONFIG_INTEL_IOMMU_SCALABLE_IOV
> + intel_siov_init();
> +#endif /* CONFIG_INTEL_IOMMU_SCALABLE_IOV */
> +
> if (si_domain && !hw_pass_through)
> register_memory_notifier(_iommu_memory_nb);
> cpuhp_setup_state(CPUHP_IOMMU_INTEL_DEAD,
> "iommu/intel:dead", NULL,
> diff --git a/drivers/iommu/intel/siov.c b/drivers/iommu/intel/siov.c
> new file mode 100644
> index ..b9470e7ab3d6
> --- /dev/null
> +++ b/drivers/iommu/intel/siov.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/**
> + * siov.c - Intel Scalable I/O virtualization support
> + *
> + * Copyright (C) 2020 Intel Corporation
> + *
> + * Author: Lu Baolu
> + */
> +
> +#define pr_fmt(fmt) "DMAR: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +
> +static struct device *subdev_lookup_parent(struct device *dev)
> +{
> + if (dev->bus == _bus_type)
> + return mdev_parent_dev(mdev_from_dev(dev));
What about finding the parent through device core? Then the logic
should work for all subdevice frameworks.
> +
> + return NULL;
>
RE: [PATCH v6 5/5] vfio/type1: Use mdev bus iommu_ops for IOMMU callbacks
> From: Lu Baolu
> Sent: Friday, October 30, 2020 12:58 PM
>
> With the IOMMU driver registering iommu_ops for the mdev_bus, the
> IOMMU
> operations on an mdev could be done in the same way as any normal device
> (for example, PCI/PCIe). There's no need to distinguish an mdev from
> others for iommu operations. Remove the unnecessary code.
This is really a nice cleanup as the output of this change! :)
Thanks
Kevin
>
> Signed-off-by: Lu Baolu
> ---
> drivers/vfio/mdev/mdev_core.c| 18 -
> drivers/vfio/mdev/mdev_driver.c | 6 ++
> drivers/vfio/mdev/mdev_private.h | 1 -
> drivers/vfio/vfio_iommu_type1.c | 128 +++
> include/linux/mdev.h | 14
> 5 files changed, 18 insertions(+), 149 deletions(-)
>
> diff --git a/drivers/vfio/mdev/mdev_core.c
> b/drivers/vfio/mdev/mdev_core.c
> index 6b9ab71f89e7..f4fd5f237c49 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -386,24 +386,6 @@ int mdev_device_remove(struct device *dev)
> return 0;
> }
>
> -int mdev_set_iommu_device(struct device *dev, struct device
> *iommu_device)
> -{
> - struct mdev_device *mdev = to_mdev_device(dev);
> -
> - mdev->iommu_device = iommu_device;
> -
> - return 0;
> -}
> -EXPORT_SYMBOL(mdev_set_iommu_device);
> -
> -struct device *mdev_get_iommu_device(struct device *dev)
> -{
> - struct mdev_device *mdev = to_mdev_device(dev);
> -
> - return mdev->iommu_device;
> -}
> -EXPORT_SYMBOL(mdev_get_iommu_device);
> -
> static int __init mdev_init(void)
> {
> return mdev_bus_register();
> diff --git a/drivers/vfio/mdev/mdev_driver.c
> b/drivers/vfio/mdev/mdev_driver.c
> index 0d3223aee20b..487402f16355 100644
> --- a/drivers/vfio/mdev/mdev_driver.c
> +++ b/drivers/vfio/mdev/mdev_driver.c
> @@ -18,6 +18,9 @@ static int mdev_attach_iommu(struct mdev_device
> *mdev)
> int ret;
> struct iommu_group *group;
>
> + if (iommu_present(_bus_type))
> + return 0;
> +
> group = iommu_group_alloc();
> if (IS_ERR(group))
> return PTR_ERR(group);
> @@ -33,6 +36,9 @@ static int mdev_attach_iommu(struct mdev_device
> *mdev)
>
> static void mdev_detach_iommu(struct mdev_device *mdev)
> {
> + if (iommu_present(_bus_type))
> + return;
> +
> iommu_group_remove_device(>dev);
> dev_info(>dev, "MDEV: detaching iommu\n");
> }
> diff --git a/drivers/vfio/mdev/mdev_private.h
> b/drivers/vfio/mdev/mdev_private.h
> index 7d922950caaf..efe0aefdb52f 100644
> --- a/drivers/vfio/mdev/mdev_private.h
> +++ b/drivers/vfio/mdev/mdev_private.h
> @@ -31,7 +31,6 @@ struct mdev_device {
> void *driver_data;
> struct list_head next;
> struct kobject *type_kobj;
> - struct device *iommu_device;
> bool active;
> };
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c
> b/drivers/vfio/vfio_iommu_type1.c
> index bb2684cc245e..e231b7070ca5 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -100,7 +100,6 @@ struct vfio_dma {
> struct vfio_group {
> struct iommu_group *iommu_group;
> struct list_headnext;
> - boolmdev_group; /* An mdev group */
> boolpinned_page_dirty_scope;
> };
>
> @@ -1675,102 +1674,6 @@ static bool vfio_iommu_has_sw_msi(struct
> list_head *group_resv_regions,
> return ret;
> }
>
> -static struct device *vfio_mdev_get_iommu_device(struct device *dev)
> -{
> - struct device *(*fn)(struct device *dev);
> - struct device *iommu_device;
> -
> - fn = symbol_get(mdev_get_iommu_device);
> - if (fn) {
> - iommu_device = fn(dev);
> - symbol_put(mdev_get_iommu_device);
> -
> - return iommu_device;
> - }
> -
> - return NULL;
> -}
> -
> -static int vfio_mdev_attach_domain(struct device *dev, void *data)
> -{
> - struct iommu_domain *domain = data;
> - struct device *iommu_device;
> -
> - iommu_device = vfio_mdev_get_iommu_device(dev);
> - if (iommu_device) {
> - if (iommu_dev_feature_enabled(iommu_device,
> IOMMU_DEV_FEAT_AUX))
> - return iommu_aux_attach_device(domain,
> iommu_device);
> - else
> - return iommu_attach_device(domain,
> iommu_device);
> - }
> -
> - return -EINVAL;
> -}
> -
> -static int vfio_mdev_detach_domain(struct device *dev, void *data)
> -{
> - struct iommu_domain *domain = data;
> - struct device *iommu_device;
> -
> - iommu_device = vfio_mdev_get_iommu_device(dev);
> - if (iommu_device) {
> - if (iommu_dev_feature_enabled(iommu_device,
> IOMMU_DEV_FEAT_AUX))
> - iommu_aux_detach_device(domain, iommu_device);
> - else
> - iommu_detach_device(domain, iommu_device);
> - }
> -
> - return 0;
> -}
> -
> -static int vfio_iommu_attach_group(struct vfio_domain
Re: [PATCH v4 2/2] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
> diff --git a/drivers/net/wireless/ath/ath10k/Kconfig > b/drivers/net/wireless/ath/ath10k/Kconfig > index 40f91bc8514d8..a490e78890017 100644 > --- a/drivers/net/wireless/ath/ath10k/Kconfig > +++ b/drivers/net/wireless/ath/ath10k/Kconfig > @@ -44,6 +44,7 @@ config ATH10K_SNOC > tristate "Qualcomm ath10k SNOC support" > depends on ATH10K > depends on ARCH_QCOM || COMPILE_TEST > + depends on QCOM_QCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y Doh. Apologies! I flubbed this line (SCM not QCM). I'll fix and resend tomorrow. thanks -john ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv7 4/7] drm/msm/a6xx: Add support for using system cache(LLC)
From: Sharat Masetty
The last level system cache can be partitioned to 32 different
slices of which GPU has two slices preallocated. One slice is
used for caching GPU buffers and the other slice is used for
caching the GPU SMMU pagetables. This talks to the core system
cache driver to acquire the slice handles, configure the SCID's
to those slices and activates and deactivates the slices upon
GPU power collapse and restore.
Some support from the IOMMU driver is also needed to make use
of the system cache to set the right TCR attributes. GPU then
has the ability to override a few cacheability parameters which
it does to override write-allocate to write-no-allocate as the
GPU hardware does not benefit much from it.
DOMAIN_ATTR_SYS_CACHE is another domain level attribute used by the
IOMMU driver to set the right attributes to cache the hardware
pagetables into the system cache.
Signed-off-by: Sharat Masetty
[saiprakash.ranjan: fix to set attr before device attach to iommu and rebase]
Signed-off-by: Sai Prakash Ranjan
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 83 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 4 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 17 +
3 files changed, 104 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 948f3656c20c..95c98c642876 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -8,7 +8,9 @@
#include "a6xx_gpu.h"
#include "a6xx_gmu.xml.h"
+#include
#include
+#include
#define GPU_PAS_ID 13
@@ -1022,6 +1024,79 @@ static irqreturn_t a6xx_irq(struct msm_gpu *gpu)
return IRQ_HANDLED;
}
+static void a6xx_llc_rmw(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 mask, u32 or)
+{
+ return msm_rmw(a6xx_gpu->llc_mmio + (reg << 2), mask, or);
+}
+
+static void a6xx_llc_write(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 value)
+{
+ return msm_writel(value, a6xx_gpu->llc_mmio + (reg << 2));
+}
+
+static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
+{
+ llcc_slice_deactivate(a6xx_gpu->llc_slice);
+ llcc_slice_deactivate(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
+{
+ u32 cntl1_regval = 0;
+
+ if (IS_ERR(a6xx_gpu->llc_mmio))
+ return;
+
+ if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
+ u32 gpu_scid = llcc_get_slice_id(a6xx_gpu->llc_slice);
+
+ gpu_scid &= 0x1f;
+ cntl1_regval = (gpu_scid << 0) | (gpu_scid << 5) | (gpu_scid <<
10) |
+ (gpu_scid << 15) | (gpu_scid << 20);
+ }
+
+ if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
+ u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+
+ gpuhtw_scid &= 0x1f;
+ cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+ }
+
+ if (cntl1_regval) {
+ /*
+* Program the slice IDs for the various GPU blocks and GPU MMU
+* pagetables
+*/
+ a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
+
+ /*
+* Program cacheability overrides to not allocate cache lines on
+* a write miss
+*/
+ a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0,
0xF, 0x03);
+ }
+}
+
+static void a6xx_llc_slices_destroy(struct a6xx_gpu *a6xx_gpu)
+{
+ llcc_slice_putd(a6xx_gpu->llc_slice);
+ llcc_slice_putd(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_slices_init(struct platform_device *pdev,
+ struct a6xx_gpu *a6xx_gpu)
+{
+ a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
+ if (IS_ERR(a6xx_gpu->llc_mmio))
+ return;
+
+ a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
+ a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
+
+ if (IS_ERR(a6xx_gpu->llc_slice) && IS_ERR(a6xx_gpu->htw_llc_slice))
+ a6xx_gpu->llc_mmio = ERR_PTR(-EINVAL);
+}
+
static int a6xx_pm_resume(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1038,6 +1113,8 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
msm_gpu_resume_devfreq(gpu);
+ a6xx_llc_activate(a6xx_gpu);
+
return 0;
}
@@ -1048,6 +1125,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
trace_msm_gpu_suspend(0);
+ a6xx_llc_deactivate(a6xx_gpu);
+
devfreq_suspend_device(gpu->devfreq.devfreq);
return a6xx_gmu_stop(a6xx_gpu);
@@ -1091,6 +1170,8 @@ static void a6xx_destroy(struct msm_gpu *gpu)
drm_gem_object_put(a6xx_gpu->shadow_bo);
}
+ a6xx_llc_slices_destroy(a6xx_gpu);
+
a6xx_gmu_remove(a6xx_gpu);
adreno_gpu_cleanup(adreno_gpu);
@@ -1209,6 +1290,8 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device
[PATCHv7 0/7] System Cache support for GPU and required SMMU support
Some hardware variants contain a system cache or the last level cache(llc). This cache is typically a large block which is shared by multiple clients on the SOC. GPU uses the system cache to cache both the GPU data buffers(like textures) as well the SMMU pagetables. This helps with improved render performance as well as lower power consumption by reducing the bus traffic to the system memory. The system cache architecture allows the cache to be split into slices which then be used by multiple SOC clients. This patch series is an effort to enable and use two of those slices preallocated for the GPU, one for the GPU data buffers and another for the GPU SMMU hardware pagetables. Patch 1 - Patch 5 adds system cache support in SMMU and GPU driver. Patch 6 and 7 are minor cleanups for arm-smmu impl. Changes in v7: * Squash Jordan's patch to support MMU500 targets * Rebase on top of for-joerg/arm-smmu/updates and Jordan's short series for adreno-smmu impl Changes in v6: * Move table to arm-smmu-qcom (Robin) Changes in v5: * Drop cleanup of blank lines since it was intentional (Robin) * Rebase again on top of msm-next-pgtables as it moves pretty fast Changes in v4: * Drop IOMMU_SYS_CACHE prot flag * Rebase on top of https://gitlab.freedesktop.org/drm/msm/-/tree/msm-next-pgtables Changes in v3: * Fix domain attribute setting to before iommu_attach_device() * Fix few code style and checkpatch warnings * Rebase on top of Jordan's latest split pagetables and per-instance pagetables support Changes in v2: * Addressed review comments and rebased on top of Jordan's split pagetables series Jordan Crouse (1): drm/msm/a6xx: Add support for using system cache on MMU500 based targets Sai Prakash Ranjan (4): iommu/io-pgtable-arm: Add support to use system cache iommu/arm-smmu: Add domain attribute for system cache iommu: arm-smmu-impl: Use table to list QCOM implementations iommu: arm-smmu-impl: Add a space before open parenthesis Sharat Masetty (2): drm/msm: rearrange the gpu_rmw() function drm/msm/a6xx: Add support for using system cache(LLC) drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 109 + drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 5 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 17 drivers/gpu/drm/msm/msm_drv.c | 8 ++ drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gpu.h | 5 +- drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 11 +-- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 +++- drivers/iommu/arm/arm-smmu/arm-smmu.c | 17 drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 +- drivers/iommu/io-pgtable-arm.c | 7 +- include/linux/io-pgtable.h | 4 + include/linux/iommu.h | 1 + 13 files changed, 188 insertions(+), 20 deletions(-) base-commit: f9081b8ff5934b8d69c748d0200e844cadd2c667 prerequisite-patch-id: db09851f375ca5efde35f2e5c21b3959eed7d8a8 prerequisite-patch-id: 55c6af17808c2047b67cdbd04af5541156ef496e prerequisite-patch-id: e82c1e678da701e112ac255ea966c6797d975692 prerequisite-patch-id: f7978f5f2fb06528b7a1f75fa4255e386a30b91a -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv7 5/7] drm/msm/a6xx: Add support for using system cache on MMU500 based targets
From: Jordan Crouse
This is an extension to the series [1] to enable the System Cache (LLC) for
Adreno a6xx targets.
GPU targets with an MMU-500 attached have a slightly different process for
enabling system cache. Use the compatible string on the IOMMU phandle
to see if an MMU-500 is attached and modify the programming sequence
accordingly.
[1] https://patchwork.freedesktop.org/series/83037/
Signed-off-by: Jordan Crouse
Signed-off-by: Sai Prakash Ranjan
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
2 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 95c98c642876..3f8b92da8cba 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1042,6 +1042,8 @@ static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
{
+ struct adreno_gpu *adreno_gpu = _gpu->base;
+ struct msm_gpu *gpu = _gpu->base;
u32 cntl1_regval = 0;
if (IS_ERR(a6xx_gpu->llc_mmio))
@@ -1055,11 +1057,17 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
(gpu_scid << 15) | (gpu_scid << 20);
}
+ /*
+* For targets with a MMU500, activate the slice but don't program the
+* register. The XBL will take care of that.
+*/
if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
- u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+ if (!a6xx_gpu->have_mmu500) {
+ u32 gpuhtw_scid =
llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
- gpuhtw_scid &= 0x1f;
- cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+ gpuhtw_scid &= 0x1f;
+ cntl1_regval |= FIELD_PREP(GENMASK(29, 25),
gpuhtw_scid);
+ }
}
if (cntl1_regval) {
@@ -1067,13 +1075,20 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
* Program the slice IDs for the various GPU blocks and GPU MMU
* pagetables
*/
- a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
-
- /*
-* Program cacheability overrides to not allocate cache lines on
-* a write miss
-*/
- a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0,
0xF, 0x03);
+ if (a6xx_gpu->have_mmu500)
+ gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL1, GENMASK(24, 0),
+ cntl1_regval);
+ else {
+ a6xx_llc_write(a6xx_gpu,
+ REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
+
+ /*
+* Program cacheability overrides to not allocate cache
+* lines on a write miss
+*/
+ a6xx_llc_rmw(a6xx_gpu,
+ REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF,
0x03);
+ }
}
}
@@ -1086,10 +1101,21 @@ static void a6xx_llc_slices_destroy(struct a6xx_gpu
*a6xx_gpu)
static void a6xx_llc_slices_init(struct platform_device *pdev,
struct a6xx_gpu *a6xx_gpu)
{
+ struct device_node *phandle;
+
a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
if (IS_ERR(a6xx_gpu->llc_mmio))
return;
+ /*
+* There is a different programming path for targets with an mmu500
+* attached, so detect if that is the case
+*/
+ phandle = of_parse_phandle(pdev->dev.of_node, "iommus", 0);
+ a6xx_gpu->have_mmu500 = (phandle &&
+ of_device_is_compatible(phandle, "arm,mmu-500"));
+ of_node_put(phandle);
+
a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 9e6079af679c..e793d329e77b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -32,6 +32,7 @@ struct a6xx_gpu {
void __iomem *llc_mmio;
void *llc_slice;
void *htw_llc_slice;
+ bool have_mmu500;
};
#define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv7 2/7] iommu/arm-smmu: Add domain attribute for system cache
Add iommu domain attribute for using system cache aka last level
cache by client drivers like GPU to set right attributes for caching
the hardware pagetables into the system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 17 +
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
include/linux/iommu.h | 1 +
3 files changed, 19 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index b1cf8f0abc29..070d13f80c7e 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -789,6 +789,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain
*domain,
if (smmu_domain->non_strict)
pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
+ if (smmu_domain->sys_cache)
+ pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_SYS_CACHE;
+
pgtbl_ops = alloc_io_pgtable_ops(fmt, _cfg, smmu_domain);
if (!pgtbl_ops) {
ret = -ENOMEM;
@@ -1520,6 +1523,9 @@ static int arm_smmu_domain_get_attr(struct iommu_domain
*domain,
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
*(int *)data = smmu_domain->non_strict;
return 0;
+ case DOMAIN_ATTR_SYS_CACHE:
+ *((int *)data) = smmu_domain->sys_cache;
+ return 0;
default:
return -ENODEV;
}
@@ -1551,6 +1557,17 @@ static int arm_smmu_domain_set_attr(struct iommu_domain
*domain,
else
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
break;
+ case DOMAIN_ATTR_SYS_CACHE:
+ if (smmu_domain->smmu) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+
+ if (*((int *)data))
+ smmu_domain->sys_cache = true;
+ else
+ smmu_domain->sys_cache = false;
+ break;
default:
ret = -ENODEV;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 885840f3bec8..dfc44d806671 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -373,6 +373,7 @@ struct arm_smmu_domain {
struct mutexinit_mutex; /* Protects smmu pointer */
spinlock_t cb_lock; /* Serialises ATS1* ops and
TLB syncs */
struct iommu_domain domain;
+ boolsys_cache;
};
struct arm_smmu_master_cfg {
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b95a6f8db6ff..4f4bb9c6f8f6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -118,6 +118,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING,/* two stages of translation */
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
+ DOMAIN_ATTR_SYS_CACHE,
DOMAIN_ATTR_MAX,
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv7 6/7] iommu: arm-smmu-impl: Use table to list QCOM implementations
Use table and of_match_node() to match qcom implementation
instead of multiple of_device_compatible() calls for each
QCOM SMMU implementation.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 9 +
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 -
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 -
3 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index d199b4bff15d..ffaf3f91ba52 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -217,14 +217,7 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
if (of_device_is_compatible(np, "nvidia,tegra194-smmu"))
return nvidia_smmu_impl_init(smmu);
- if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
- of_device_is_compatible(np, "qcom,sc7180-smmu-500") ||
- of_device_is_compatible(np, "qcom,sm8150-smmu-500") ||
- of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
- return qcom_smmu_impl_init(smmu);
-
- if (of_device_is_compatible(smmu->dev->of_node, "qcom,adreno-smmu"))
- return qcom_adreno_smmu_impl_init(smmu);
+ smmu = qcom_smmu_impl_init(smmu);
if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = _mmu500_impl;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 0f763d555c92..221e2a6a3231 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -314,12 +314,23 @@ static struct arm_smmu_device *qcom_smmu_create(struct
arm_smmu_device *smmu,
return >smmu;
}
+static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
+ { .compatible = "qcom,sc7180-smmu-500" },
+ { .compatible = "qcom,sdm845-smmu-500" },
+ { .compatible = "qcom,sm8150-smmu-500" },
+ { .compatible = "qcom,sm8250-smmu-500" },
+ { }
+};
+
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
{
- return qcom_smmu_create(smmu, _smmu_impl);
-}
+ const struct device_node *np = smmu->dev->of_node;
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device
*smmu)
-{
- return qcom_smmu_create(smmu, _adreno_smmu_impl);
+ if (of_match_node(qcom_smmu_impl_of_match, np))
+ return qcom_smmu_create(smmu, _smmu_impl);
+
+ if (of_device_is_compatible(np, "qcom,adreno-smmu"))
+ return qcom_smmu_create(smmu, _adreno_smmu_impl);
+
+ return smmu;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index dfc44d806671..43b2411e65cc 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -525,7 +525,6 @@ static inline void arm_smmu_writeq(struct arm_smmu_device
*smmu, int page,
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu);
struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu);
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu);
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device
*smmu);
void arm_smmu_write_context_bank(struct arm_smmu_device *smmu, int idx);
int arm_mmu500_reset(struct arm_smmu_device *smmu);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv7 1/7] iommu/io-pgtable-arm: Add support to use system cache
Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
attributes set in TCR for the page table walker when
using system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm.c | 7 ++-
include/linux/io-pgtable.h | 4
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index a7a9bc08dcd1..a356caf1683a 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -761,7 +761,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg,
void *cookie)
if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NON_STRICT |
- IO_PGTABLE_QUIRK_ARM_TTBR1))
+ IO_PGTABLE_QUIRK_ARM_TTBR1 |
+ IO_PGTABLE_QUIRK_SYS_CACHE))
return NULL;
data = arm_lpae_alloc_pgtable(cfg);
@@ -773,6 +774,10 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg,
void *cookie)
tcr->sh = ARM_LPAE_TCR_SH_IS;
tcr->irgn = ARM_LPAE_TCR_RGN_WBWA;
tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
+ } else if (cfg->quirks & IO_PGTABLE_QUIRK_SYS_CACHE) {
+ tcr->sh = ARM_LPAE_TCR_SH_OS;
+ tcr->irgn = ARM_LPAE_TCR_RGN_NC;
+ tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
} else {
tcr->sh = ARM_LPAE_TCR_SH_OS;
tcr->irgn = ARM_LPAE_TCR_RGN_NC;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 4cde111e425b..86631f711e05 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -86,6 +86,9 @@ struct io_pgtable_cfg {
*
* IO_PGTABLE_QUIRK_ARM_TTBR1: (ARM LPAE format) Configure the table
* for use in the upper half of a split address space.
+*
+* IO_PGTABLE_QUIRK_SYS_CACHE: Override the attributes set in TCR for
+* the page table walker when using system cache.
*/
#define IO_PGTABLE_QUIRK_ARM_NS BIT(0)
#define IO_PGTABLE_QUIRK_NO_PERMS BIT(1)
@@ -93,6 +96,7 @@ struct io_pgtable_cfg {
#define IO_PGTABLE_QUIRK_ARM_MTK_EXTBIT(3)
#define IO_PGTABLE_QUIRK_NON_STRICT BIT(4)
#define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5)
+ #define IO_PGTABLE_QUIRK_SYS_CACHE BIT(6)
unsigned long quirks;
unsigned long pgsize_bitmap;
unsigned intias;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv7 3/7] drm/msm: rearrange the gpu_rmw() function
From: Sharat Masetty
The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.
Signed-off-by: Sharat Masetty
Reviewed-by: Jordan Crouse
Signed-off-by: Sai Prakash Ranjan
---
drivers/gpu/drm/msm/msm_drv.c | 8
drivers/gpu/drm/msm/msm_drv.h | 1 +
drivers/gpu/drm/msm/msm_gpu.h | 5 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 49685571dc0e..a1e22b974b77 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -180,6 +180,14 @@ u32 msm_readl(const void __iomem *addr)
return val;
}
+void msm_rmw(void __iomem *addr, u32 mask, u32 or)
+{
+ u32 val = msm_readl(addr);
+
+ val &= ~mask;
+ msm_writel(val | or, addr);
+}
+
struct msm_vblank_work {
struct work_struct work;
int crtc_id;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b9dd8f8f4887..655b3b0424a1 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -478,6 +478,7 @@ void __iomem *msm_ioremap_quiet(struct platform_device
*pdev, const char *name,
const char *dbgname);
void msm_writel(u32 data, void __iomem *addr);
u32 msm_readl(const void __iomem *addr);
+void msm_rmw(void __iomem *addr, u32 mask, u32 or);
struct msm_gpu_submitqueue;
int msm_submitqueue_init(struct drm_device *drm, struct msm_file_private *ctx);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 6c9e1fdc1a76..b2b419277953 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -246,10 +246,7 @@ static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
static inline void gpu_rmw(struct msm_gpu *gpu, u32 reg, u32 mask, u32 or)
{
- uint32_t val = gpu_read(gpu, reg);
-
- val &= ~mask;
- gpu_write(gpu, reg, val | or);
+ msm_rmw(gpu->mmio + (reg << 2), mask, or);
}
static inline u64 gpu_read64(struct msm_gpu *gpu, u32 lo, u32 hi)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 01/14] docs: Document IO Address Space ID (IOASID) APIs
On Mon, Oct 26, 2020 at 02:05:06PM -0700, Jacob Pan wrote: > > This looks good to me, with small comments below. > > > Can I add your Reviewed-by tag after addressing the comments? Yes sure, this took forever to review so I'm happy not to do another pass :) > > > +Each IOASID set is created with a token, which can be one of the > > > +following token types: > > > + > > > + - IOASID_SET_TYPE_NULL (Arbitrary u64 value) > > > > Maybe NULL isn't the best name then. NONE? > > > Agreed, 'NONE' makes more sense. Although patch 5 only allows a NULL token for this type. So the name seems fine, you could just fix this description. > > > +IOASID core has the notion of "custom allocator" such that guest can > > > +register virtual command allocator that precedes the default one. > > > > "Supersedes", rather than "precedes"? > > > My understanding is that 'supersede' means replace something but 'precede' > means get in front of something. I do want to emphasis that the custom > allocator takes precedence over the default allocator. Right it's ambiguous. The custom allocator does entirely replace the allocation action, but the default one is still used for storage. Anyway, you can leave this. > > > +Let's examine the IOASID life cycle again when free happens *before* > > > +unbind. This could be a result of misbehaving guests or crash. Assuming > > > +VFIO cannot enforce unbind->free order. Notice that the setup part up > > > +until step #12 is identical to the normal case, the flow below starts > > > +with step 13. > > > + > > > +:: > > > + > > > + VFIOIOMMUKVMVDCMIOASID Ref > > > + .. > > > + 13 GUEST STARTS DMA -- > > > + 14 *GUEST MISBEHAVES!!!* > > > + 15 ioasid_free() > > > + 16 ioasid_notify(FREE) > > > + 17 mark_free_pending > > > (1) > > > > Could we use superscript ¹²³⁴ for footnotes? These look like function > > parameters > > > yes, much better > > > > + 18 kvm_nb_handler(FREE) > > > + 19 vmcs_update_atomic() > > > + 20 ioasid_put_locked() -> 3 > > > + 21 vdcm_nb_handler(FREE) > > > + 22iomm_nb_handler(FREE) > > > > iommu_nb_handler > > > got it > > > > + 23 ioasid_free() returns(2) schedule_work() 2 > > > > I completely lost track here, couldn't figure out in which direction to > > read the diagram. What work is scheduled? > The time line goes downward but we only control the notification order in > terms of when the events are received. Some completions are async thus out > of order done by work items. The only in-order completion is the KVM update > of its PASID translation table. > > After #23, the async works are scheduled to complete clean up work outside > the spinlock(held by the caller of the atomic notifier). > > Any suggestions to improve the readability of the time line? Maybe explain what happens from line 23: ioasid_free() schedules... a FREE notification? Which happens on line 24 (corresponding to the second schedule_work()?) and is handled by (a) VDCM to clear the device context and (b) IOMMU to clear the PASID context, both ending up dropping their ref. > > > Why does the IOMMU driver drop > > its reference to the IOASID before unbdind_gpasid()? > > > This is the exception case where userspace issues IOASID free before > unbind_gpasid(). The equivalent of unbind is performed in the IOASID_FREE > notification handler. In IOASID_FREE handler, reference is dropped and > private data deleted. After that, if unbind comes to IOMMU driver, it will > not find IOASID private data therefore just return. Right ok. As you noted below the damage is caused by and limited to the guest, so I think it's fine. > > > > + 24schedule_work()vdev_clear_wk(hpasid) > > > + 25teardown_pasid_wk() > > > + 26 ioasid_put() -> 1 > > > + 27ioasid_put() 0 > > > + 28 Reclaimed > > > + 29 unbind_gpasid() > > > + 30iommu_unbind()->ioasid_find() Fails(3) > > > + -- New Life Cycle Begin > > > + > > > +Note: > > > + > > > +1. By marking IOASID FREE_PENDING at step #17, no new references can be > > > + held. ioasid_get/find() will return -ENOENT; > > > > s/held/taken > > > Got it. > > > Thanks, > > Jean > > > > > +2. After step #23, all events can go out of order. Shall not affect > > > + the outcome. > > > +3. IOMMU driver fails to find private data for unbinding. If unbind is > > > + called after the same IOASID is
[PATCH] [v3] x86: apic: avoid -Wshadow warning in header
From: Arnd Bergmann
There are hundreds of warnings in a W=2 build about a local
variable shadowing the global 'apic' definition:
arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
declaration [-Wshadow]
Avoid this by renaming the global 'apic' variable to the more descriptive
'x86_local_apic'. It was originally called 'genapic', but both that
and the current 'apic' seem to be a little overly generic for a global
variable.
Fixes: c48f14966cc4 ("KVM: inline kvm_apic_present() and kvm_lapic_enabled()")
Fixes: c8d46cf06dc2 ("x86: rename 'genapic' to 'apic'")
Signed-off-by: Arnd Bergmann
---
v3: rename the global from x86_system_apic to x86_local_apic
v2: rename the global instead of the local variable in the header
This is only tested in an allmodconfig build, after fixing up a
few mistakes in the original search It's likely that I
missed a few others, but this version should be sufficient to
decide whether this is a good idea in the first place, as well
as if there are better ideas for the new name.
---
arch/x86/hyperv/hv_apic.c | 2 ++
arch/x86/hyperv/hv_spinlock.c | 4 ++--
arch/x86/include/asm/apic.h | 18 +-
arch/x86/kernel/acpi/boot.c | 2 +-
arch/x86/kernel/apic/apic.c | 18 +-
arch/x86/kernel/apic/apic_flat_64.c | 8
arch/x86/kernel/apic/apic_numachip.c | 4 ++--
arch/x86/kernel/apic/bigsmp_32.c | 2 +-
arch/x86/kernel/apic/hw_nmi.c | 2 +-
arch/x86/kernel/apic/io_apic.c| 19 ++-
arch/x86/kernel/apic/ipi.c| 22 +++---
arch/x86/kernel/apic/msi.c| 2 +-
arch/x86/kernel/apic/probe_32.c | 20 ++--
arch/x86/kernel/apic/probe_64.c | 12 ++--
arch/x86/kernel/apic/vector.c | 8
arch/x86/kernel/apic/x2apic_cluster.c | 3 ++-
arch/x86/kernel/apic/x2apic_phys.c| 2 +-
arch/x86/kernel/apic/x2apic_uv_x.c| 2 +-
arch/x86/kernel/cpu/common.c | 14 --
arch/x86/kernel/cpu/mce/inject.c | 4 ++--
arch/x86/kernel/cpu/topology.c| 8
arch/x86/kernel/irq_work.c| 2 +-
arch/x86/kernel/kvm.c | 6 +++---
arch/x86/kernel/nmi_selftest.c| 2 +-
arch/x86/kernel/smpboot.c | 20 +++-
arch/x86/kernel/vsmp_64.c | 2 +-
arch/x86/kvm/vmx/vmx.c| 2 +-
arch/x86/mm/srat.c| 2 +-
arch/x86/platform/uv/uv_irq.c | 4 ++--
arch/x86/platform/uv/uv_nmi.c | 2 +-
arch/x86/xen/apic.c | 8
drivers/iommu/amd/iommu.c | 10 ++
drivers/iommu/intel/irq_remapping.c | 4 ++--
33 files changed, 125 insertions(+), 115 deletions(-)
diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 284e73661a18..9df6ed521048 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -254,6 +254,8 @@ static void hv_send_ipi_self(int vector)
void __init hv_apic_init(void)
{
+ struct apic *apic = x86_local_apic;
+
if (ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) {
pr_info("Hyper-V: Using IPI hypercalls\n");
/*
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index f3270c1fc48c..01576e14460e 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -20,7 +20,7 @@ static bool __initdata hv_pvspin = true;
static void hv_qlock_kick(int cpu)
{
- apic->send_IPI(cpu, X86_PLATFORM_IPI_VECTOR);
+ x86_local_apic->send_IPI(cpu, X86_PLATFORM_IPI_VECTOR);
}
static void hv_qlock_wait(u8 *byte, u8 val)
@@ -64,7 +64,7 @@ PV_CALLEE_SAVE_REGS_THUNK(hv_vcpu_is_preempted);
void __init hv_init_spinlocks(void)
{
- if (!hv_pvspin || !apic ||
+ if (!hv_pvspin || !x86_local_apic ||
!(ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) ||
!(ms_hyperv.features & HV_MSR_GUEST_IDLE_AVAILABLE)) {
pr_info("PV spinlocks disabled\n");
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 4e3099d9ae62..34294fc8f2da 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -361,7 +361,7 @@ struct apic {
* always just one such driver in use - the kernel decides via an
* early probing process which one it picks - and then sticks to it):
*/
-extern struct apic *apic;
+extern struct apic *x86_local_apic;
/*
* APIC drivers are probed based on how they are listed in the .apicdrivers
@@ -395,37 +395,37 @@ extern int lapic_can_unplug_cpu(void);
static inline u32 apic_read(u32 reg)
{
- return apic->read(reg);
+ return x86_local_apic->read(reg);
}
static inline void apic_write(u32 reg, u32 val)
{
- apic->write(reg, val);
+ x86_local_apic->write(reg, val);
}
static inline void apic_eoi(void)
{
-
Re: [PATCH v2 5/5] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
On 2020-10-30 01:02, John Stultz wrote: On Wed, Oct 28, 2020 at 7:51 AM Robin Murphy wrote: Hmm, perhaps I'm missing something here, but even if the config options *do* line up, what prevents arm-smmu probing before qcom-scm and dereferencing NULL in qcom_scm_qsmmu500_wait_safe_toggle() before __scm is initialised? Oh man, this spun me on a "wait, but how does it all work!" trip. :) So in the non-module case, the qcom_scm driver is a subsys_initcall and the arm-smmu is a module_platform_driver, so the ordering works out. In the module case, the arm-smmu code isn't loaded until the qcom_scm driver finishes probing due to the symbol dependency handling. My point is that module load != driver probe. AFAICS you could disable drivers_autoprobe, load both modules, bind the SMMU to its driver first, and boom! To double check this, I added a big msleep at the top of the qcom_scm_probe to try to open the race window you described, but the arm_smmu_device_probe() doesn't run until after qcom_scm_probe completes. I don't think asynchronous probing is enabled by default, so indeed I would expect that to still happen to work ;) So at least as a built in / built in, or a module/module case its ok. And in the case where arm-smmu is a module and qcom_scm is built in that's ok too. In the built-in case, I'm sure it happens to work out similarly because the order of nodes in the DTB tends to be the order in which devices are autoprobed. Again, async probe might be enough to break things; manually binding drivers definitely should; moving the firmware node to the end of the DTB probably would as well. Its just the case my patch is trying to prevent is where arm-smmu is built in, but qcom_scm is a module that it can't work (due to build errors in missing symbols, or if we tried to use function pointers to plug in the qcom_scm - the lack of initialization ordering). Hopefully that addresses your concern? Let me know if I'm still missing something. What I was dancing around is that the SCM API (and/or its users) appears to need a general way to tell whether SCM is ready or not, because the initialisation ordering problem is there anyway. Neither Kconfig nor the module loader can solve that. One possible self-contained workaround would be to see if an SCM DT node exists, see if a corresponding device exists, and see if that device has a driver bound. It's a little ugly, and strictly it still doesn't tell you that the _right_ driver is bound, but at least it's a lot more robust than implicitly relying on DT order, default probing behaviours, and hope. Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] dma-mapping: add benchmark support for streaming DMA APIs
On 2020-10-29 21:39, Song Bao Hua (Barry Song) wrote:
[...]
+struct map_benchmark {
+ __u64 map_nsec;
+ __u64 unmap_nsec;
+ __u32 threads; /* how many threads will do map/unmap in parallel */
+ __u32 seconds; /* how long the test will last */
+ int node; /* which numa node this benchmark will run on */
+ __u64 expansion[10];/* For future use */
+};
I'm no expert on userspace ABIs (and what little experience I do have is
mostly of Win32...), so hopefully someone else will comment if there's
anything of concern here. One thing I wonder is that there's a fair
likelihood of functionality evolving here over time, so might it be
appropriate to have some sort of explicit versioning parameter for
robustness?
I copied that from gup_benchmark. There is no this kind of code to
compare version.
I believe there is a likelihood that kernel module is changed but users
are still using old userspace tool, this might lead to the incompatible
data structure.
But not sure if it is a big problem :-)
Yeah, like I say I don't really have a good feeling for what would be
best here, I'm just thinking of what I do know and wary of the potential
for a "640 bits ought to be enough for anyone" issue ;)
+struct map_benchmark_data {
+ struct map_benchmark bparam;
+ struct device *dev;
+ struct dentry *debugfs;
+ atomic64_t total_map_nsecs;
+ atomic64_t total_map_loops;
+ atomic64_t total_unmap_nsecs;
+ atomic64_t total_unmap_loops;
+};
+
+static int map_benchmark_thread(void *data)
+{
+ struct page *page;
+ dma_addr_t dma_addr;
+ struct map_benchmark_data *map = data;
+ int ret = 0;
+
+ page = alloc_page(GFP_KERNEL);
+ if (!page)
+ return -ENOMEM;
+
+ while (!kthread_should_stop()) {
+ ktime_t map_stime, map_etime, unmap_stime, unmap_etime;
+
+ map_stime = ktime_get();
+ dma_addr = dma_map_page(map->dev, page, 0, PAGE_SIZE,
DMA_BIDIRECTIONAL);
Note that for a non-coherent device, this will give an underestimate of
the real-world overhead of BIDIRECTIONAL or TO_DEVICE mappings, since
the page will never be dirty in the cache (except possibly the very
first time through).
Agreed. I'd like to add a DIRECTION parameter like "-d 0", "-d 1" after we have
this basic framework.
That wasn't so much about the direction itself, just that if it's
anything other than FROM_DEVICE, we should probably do something to
dirty the buffer by a reasonable amount before each map. Otherwise the
measured performance is going to be unrealistic on many systems.
[...]
+ atomic64_add((long long)ktime_to_ns(ktime_sub(unmap_etime,
unmap_stime)),
+ >total_unmap_nsecs);
+ atomic64_inc(>total_map_loops);
+ atomic64_inc(>total_unmap_loops);
I think it would be worth keeping track of the variances as well - it
can be hard to tell if a reasonable-looking average is hiding terrible
worst-case behaviour.
This is a sensible requirement. I believe it is better to be handled by the
existing kernel tracing method.
Maybe we need a histogram like:
Delay sample count
1-2us 1000 ***
2-3us 2000 ***
3-4us 100 *
.
This will be more precise than the maximum latency in the worst
case.
I'd believe this can be handled by:
tracepoint A
Map
Tracepoint B
Tracepoint C
Unmap
Tracepoint D
Let the userspace ebpf to draw the histogram for the delta of B-A and D-C.
So I am planning to put this requirement into todo list and write an userspace
ebpf/bcc script for histogram and put in tools/ directory.
Please give your comments on this.
Right, I wasn't suggesting trying to homebrew a full data collection
system here - I agree there are better tools for that already - just
that it's basically free to track a sum of squares alongside a sum, so
that we can trivially calculate a useful variance (or standard
deviation) figure alongside the mean at the end.
[...]
+ for (i = 0; i < threads; i++) {
+ tsk[i] = kthread_create_on_node(map_benchmark_thread, map,
+ map->bparam.node, "dma-map-benchmark/%d", i);
+ if (IS_ERR(tsk[i])) {
+ dev_err(map->dev, "create dma_map thread failed\n");
+ return PTR_ERR(tsk[i]);
+ }
+
+ if (node != NUMA_NO_NODE && node_online(node))
+ kthread_bind_mask(tsk[i], cpu_mask);
+
+ wake_up_process(tsk[i]);
Might it be better to create all the threads first, *then* start kicking
them?
The difficulty is that we don't know how many threads we should create as
the thread number is a parameter to test the contention of IOMMU driver.
In my test case, I'd like to test things like
One thread
Two threads
8 threads
12 threads
16 threads...
On the other hand, I
Re: [PATCH v2 2/2] iommu/vt-d: Fix a bug for PDP check in prq_event_thread
On 10/30/20 10:37 AM, Yi Sun wrote:
From: "Liu, Yi L"
In prq_event_thread(), the QI_PGRP_PDP is wrongly set by
'req->pasid_present' which should be replaced to
'req->priv_data_present'.
Fixes: 5b438f4ba315 ("iommu/vt-d: Support page request in scalable mode")
Signed-off-by: Liu, Yi L
Signed-off-by: Yi Sun
Cc: sta...@ver.kernel.org
Acked-by: Lu Baolu
Best regards,
baolu
---
drivers/iommu/intel/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 7584669..3242ebd 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -1035,7 +1035,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
resp.qw0 = QI_PGRP_PASID(req->pasid) |
QI_PGRP_DID(req->rid) |
QI_PGRP_PASID_P(req->pasid_present) |
- QI_PGRP_PDP(req->pasid_present) |
+ QI_PGRP_PDP(req->priv_data_present) |
QI_PGRP_RESP_CODE(result) |
QI_PGRP_RESP_TYPE;
resp.qw1 = QI_PGRP_IDX(req->prg_index) |
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 1/3] dt-bindings: memory: mediatek: Convert SMI to DT schema
On Fri, 30 Oct 2020 17:12:52 +0800, Yong Wu wrote: > Convert MediaTek SMI to DT schema. > > CC: Fabien Parent > CC: Ming-Fan Chen > CC: Matthias Brugger > Signed-off-by: Yong Wu > --- > .../mediatek,smi-common.txt | 50 --- > .../mediatek,smi-common.yaml | 140 ++ > .../memory-controllers/mediatek,smi-larb.txt | 50 --- > .../memory-controllers/mediatek,smi-larb.yaml | 129 > 4 files changed, 269 insertions(+), 100 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt > create mode 100644 > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml > delete mode 100644 > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt > create mode 100644 > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml:84:8: [warning] wrong indentation: expected 6 but found 7 (indentation) ./Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml:98:13: [warning] wrong indentation: expected 10 but found 12 (indentation) ./Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml:41:8: [warning] wrong indentation: expected 6 but found 7 (indentation) dtschema/dtc warnings/errors: See https://patchwork.ozlabs.org/patch/1390887 The base for the patch is generally the last rc1. Any dependencies should be noted. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 2/5] iommu: Use bus iommu ops for aux related callback
On Fri, Oct 30, 2020 at 05:55:53AM +, Tian, Kevin wrote: > > From: Lu Baolu > > Sent: Friday, October 30, 2020 12:58 PM > > > > The aux-domain apis were designed for macro driver where the subdevices > > are created and used inside a device driver. Use the device's bus iommu > > ops instead of that in iommu domain for various callbacks. > > IIRC there are only two users on these apis. One is VFIO, and the other > is on the ARM side (not checked in yet). Jean, can you help confirm > whether ARM-side usage still relies on aux apis even with this change? No, I have something out of tree but no plan to upstream it anymore, and the SMMUv2 implementation is out as well: https://lore.kernel.org/linux-iommu/20200713173556.gc3...@jcrouse1-lnx.qualcomm.com/ > If no, possibly they can be removed completely? No objection from me. They can be added back later (I still belive adding PASID to the DMA API would be nice to have once more HW implements it). Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/2] iommu/vt-d: Fix sid not set issue in intel_svm_bind_gpasid()
On 10/30/20 10:37 AM, Yi Sun wrote:
From: Liu Yi L
Should get correct sid and set it into sdev. Because we execute
'sdev->sid != req->rid' in the loop of prq_event_thread().
Fixes: eb8d93ea3c1d ("iommu/vt-d: Report page request faults for guest SVA")
Signed-off-by: Liu Yi L
Signed-off-by: Yi Sun
Cc: sta...@ver.kernel.org
Acked-by: Lu Baolu
Best regards,
baolu
---
drivers/iommu/intel/svm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index f1861fa..7584669 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -279,6 +279,7 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
struct intel_iommu *iommu = device_to_iommu(dev, NULL, NULL);
struct intel_svm_dev *sdev = NULL;
struct dmar_domain *dmar_domain;
+ struct device_domain_info *info;
struct intel_svm *svm = NULL;
int ret = 0;
@@ -310,6 +311,10 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain, struct device *dev,
if (data->hpasid <= 0 || data->hpasid >= PASID_MAX)
return -EINVAL;
+ info = get_domain_info(dev);
+ if (!info)
+ return -EINVAL;
+
dmar_domain = to_dmar_domain(domain);
mutex_lock(_mutex);
@@ -357,6 +362,7 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
goto out;
}
sdev->dev = dev;
+ sdev->sid = PCI_DEVID(info->bus, info->devfn);
/* Only count users if device has aux domains */
if (iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX))
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 6/7] arm64: mm: Set ZONE_DMA size based on early IORT scan
On Thu, Oct 29, 2020 at 06:25:49PM +0100, Nicolas Saenz Julienne wrote:
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9929ff50c0c0..05fe4a076bab 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1718,3 +1718,55 @@ void __init acpi_iort_init(void)
>
> iort_init_platform_devices();
> }
> +
> +#ifdef CONFIG_ZONE_DMA
> +/*
> + * Check the IORT whether any devices exist whose DMA mask is < 32 bits.
> + * If so, return the smallest value encountered, or 32 otherwise.
> + */
> +unsigned int __init acpi_iort_get_zone_dma_size(void)
> +{
> + struct acpi_table_iort *iort;
> + struct acpi_iort_node *node, *end;
> + acpi_status status;
> + u8 limit = 32;
Nitpick: can we not return PHYS_ADDR_MAX here, for consistency with
of_dma_get_max_cpu_address()? There wouldn't be any functional change.
--
Catalin
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] [v2] x86: apic: avoid -Wshadow warning in header
On 29/10/20 23:12, David Laight wrote: >> https://godbolt.org/z/4dzPbM >> >> With -fno-strict-aliasing, the compiler reloads the pointer if you write >> to the start of what it points to, but not if you write to later >> elements. > I guess it assumes that global data doesn't overlap. Yeah, setting p = (struct s *) ((char *)) - 8; invokes undefined behavior _for a different reason than strict aliasing_ (it's a pointer that is based on "p" but points before its start or after one byte past its end). So the compiler assumes that only the first few bytes of a global can overlap it. If you change the size of the fields from long to char in the compiler explorer link above, every field forces a reload of the global. Paolo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 1/5] vfio/mdev: Register mdev bus earlier during boot
On Fri, 30 Oct 2020 12:58:05 +0800
Lu Baolu wrote:
> Move mdev bus registration earlier than IOMMU probe processing so that
> the IOMMU drivers could be able to set iommu_ops for the mdev bus. This
> only applies when vfio-mdev module is setected to be built-in.
>
> Signed-off-by: Lu Baolu
> ---
Most kernels will build this as a module, so having different behavior
and apparently different IOMMU support for built-in vs module is
broken. Thanks,
Alex
> drivers/vfio/mdev/mdev_core.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index b558d4cfd082..6b9ab71f89e7 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -417,8 +417,12 @@ static void __exit mdev_exit(void)
> mdev_bus_unregister();
> }
>
> +#if IS_BUILTIN(CONFIG_VFIO_MDEV)
> +postcore_initcall(mdev_init)
> +#else
> module_init(mdev_init)
> module_exit(mdev_exit)
> +#endif /* IS_BUILTIN(CONFIG_VFIO_MDEV) */
>
> MODULE_VERSION(DRIVER_VERSION);
> MODULE_LICENSE("GPL v2");
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 0/7] arm64: Default to 32-bit wide ZONE_DMA
On Thu, Oct 29, 2020 at 06:25:43PM +0100, Nicolas Saenz Julienne wrote:
> Ard Biesheuvel (1):
> arm64: mm: Set ZONE_DMA size based on early IORT scan
>
> Nicolas Saenz Julienne (6):
> arm64: mm: Move reserve_crashkernel() into mem_init()
> arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
> of/address: Introduce of_dma_get_max_cpu_address()
> of: unittest: Add test for of_dma_get_max_cpu_address()
> arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges
> mm: Remove examples from enum zone_type comment
Thanks for putting this together. I had a minor comment but the patches
look fine to me. We still need an ack from Rob on the DT patch and I can
queue the series for 5.11.
Could you please also test the patch below on top of this series? It's
the removal of the implied DMA offset in the max_zone_phys()
calculation.
--8<-
>From 3ae252d888be4984a612236124f5b099e804c745 Mon Sep 17 00:00:00 2001
From: Catalin Marinas
Date: Fri, 30 Oct 2020 18:07:34 +
Subject: [PATCH] arm64: Ignore any DMA offsets in the max_zone_phys()
calculation
Currently, the kernel assumes that if RAM starts above 32-bit (or
zone_bits), there is still a ZONE_DMA/DMA32 at the bottom of the RAM and
such constrained devices have a hardwired DMA offset. In practice, we
haven't noticed any such hardware so let's assume that we can expand
ZONE_DMA32 to the available memory if no RAM below 4GB. Similarly,
ZONE_DMA is expanded to the 4GB limit if no RAM addressable by
zone_bits.
Signed-off-by: Catalin Marinas
---
arch/arm64/mm/init.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 095540667f0f..362160e16fb2 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -175,14 +175,21 @@ static void __init reserve_elfcorehdr(void)
#endif /* CONFIG_CRASH_DUMP */
/*
- * Return the maximum physical address for a zone with a given address size
- * limit. It currently assumes that for memory starting above 4G, 32-bit
- * devices will use a DMA offset.
+ * Return the maximum physical address for a zone accessible by the given bits
+ * limit. If the DRAM starts above 32-bit, expand the zone to the maximum
+ * available memory, otherwise cap it at 32-bit.
*/
static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
{
- phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63,
zone_bits);
- return min(offset + (1ULL << zone_bits), memblock_end_of_DRAM());
+ phys_addr_t zone_mask = (1ULL << zone_bits) - 1;
+ phys_addr_t phys_start = memblock_start_of_DRAM();
+
+ if (!(phys_start & U32_MAX))
+ zone_mask = PHYS_ADDR_MAX;
+ else if (!(phys_start & zone_mask))
+ zone_mask = U32_MAX;
+
+ return min(zone_mask + 1, memblock_end_of_DRAM());
}
static void __init zone_sizes_init(unsigned long min, unsigned long max)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/vt-d: Avoid GFP_ATOMIC where it is not needed
There is no reason to use GFP_ATOMIC in a 'suspend' function.
Use GFP_KERNEL instead to give more opportunities to allocate the
requested memory.
Signed-off-by: Christophe JAILLET
---
Should GFP_ATOMIC be mandatory here, a comment explaining why would be great
---
drivers/iommu/intel/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index f8177c59d229..cd2a82ed78b5 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4114,7 +4114,7 @@ static int iommu_suspend(void)
for_each_active_iommu(iommu, drhd) {
iommu->iommu_state = kcalloc(MAX_SR_DMAR_REGS, sizeof(u32),
-GFP_ATOMIC);
+GFP_KERNEL);
if (!iommu->iommu_state)
goto nomem;
}
--
2.27.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 5/5] vfio/type1: Use mdev bus iommu_ops for IOMMU callbacks
On Fri, 30 Oct 2020 06:16:28 + "Tian, Kevin" wrote: > > From: Lu Baolu > > Sent: Friday, October 30, 2020 12:58 PM > > > > With the IOMMU driver registering iommu_ops for the mdev_bus, the > > IOMMU > > operations on an mdev could be done in the same way as any normal device > > (for example, PCI/PCIe). There's no need to distinguish an mdev from > > others for iommu operations. Remove the unnecessary code. > > This is really a nice cleanup as the output of this change! :) It's easy to remove a bunch of code when the result is breaking everyone else. Please share with me how SR-IOV backed mdevs continue to work on AMD platforms, or how they might work on ARM platforms, when siov_iommu_ops (VT-d only) becomes the one and only provider of iommu_ops on the mdev bus. Hard NAK on this series. Thanks, Alex ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 4/5] iommu/vt-d: Add iommu_ops support for subdevice bus
On Fri, 30 Oct 2020 12:58:08 +0800
Lu Baolu wrote:
> +static const struct iommu_ops siov_iommu_ops = {
> + .capable= intel_iommu_capable,
> + .domain_alloc = siov_iommu_domain_alloc,
> + .domain_free= intel_iommu_domain_free,
> + .attach_dev = siov_iommu_attach_device,
> + .detach_dev = siov_iommu_detach_device,
> + .map= intel_iommu_map,
> + .unmap = intel_iommu_unmap,
> + .iova_to_phys = intel_iommu_iova_to_phys,
> + .probe_device = siov_iommu_probe_device,
> + .release_device = siov_iommu_release_device,
> + .get_resv_regions = siov_iommu_get_resv_regions,
> + .put_resv_regions = generic_iommu_put_resv_regions,
> + .device_group = generic_device_group,
> + .pgsize_bitmap = (~0xFFFUL),
> +};
> +
> +void intel_siov_init(void)
> +{
> + if (!scalable_mode_support() || !iommu_pasid_support())
> + return;
> +
> + bus_set_iommu(_bus_type, _iommu_ops);
> + pr_info("Intel(R) Scalable I/O Virtualization supported\n");
> +}
How can you presume to take over iommu_ops for an entire virtual bus?
This also forces mdev and all the dependencies of mdev to be built into
the kernel. I don't find that acceptable. Thanks,
Alex
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v5 2/2] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
Allow the qcom_scm driver to be loadable as a permenent module.
This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to
ensure that drivers that call into the qcom_scm driver are
also built as modules. While not ideal in some cases its the
only safe way I can find to avoid build errors without having
those drivers select QCOM_SCM and have to force it on (as
QCOM_SCM=n can be valid for those drivers).
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Linus Walleij
Cc: Vinod Koul
Cc: Kalle Valo
Cc: Maulik Shah
Cc: Lina Iyer
Cc: Saravana Kannan
Cc: Todd Kjos
Cc: Greg Kroah-Hartman
Cc: linux-arm-...@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Cc: linux-g...@vger.kernel.org
Acked-by: Greg Kroah-Hartman
Signed-off-by: John Stultz
---
v3:
* Fix __arm_smccc_smc build issue reported by
kernel test robot
v4:
* Add "depends on QCOM_SCM || !QCOM_SCM" bit to ath10k
config that requires it.
v5:
* Fix QCOM_QCM typo in Kconfig, it should be QCOM_SCM
---
drivers/firmware/Kconfig| 4 ++--
drivers/firmware/Makefile | 3 ++-
drivers/firmware/qcom_scm.c | 4
drivers/iommu/Kconfig | 2 ++
drivers/net/wireless/ath/ath10k/Kconfig | 1 +
5 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 3315e3c215864..5e369928bc567 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -235,8 +235,8 @@ config INTEL_STRATIX10_RSU
Say Y here if you want Intel RSU support.
config QCOM_SCM
- bool
- depends on ARM || ARM64
+ tristate "Qcom SCM driver"
+ depends on (ARM && HAVE_ARM_SMCCC) || ARM64
select RESET_CONTROLLER
config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 5e013b6a3692e..523173cbff335 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -17,7 +17,8 @@ obj-$(CONFIG_ISCSI_IBFT) += iscsi_ibft.o
obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o
obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
obj-$(CONFIG_FW_CFG_SYSFS) += qemu_fw_cfg.o
-obj-$(CONFIG_QCOM_SCM) += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
+obj-$(CONFIG_QCOM_SCM) += qcom-scm.o
+qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 7be48c1bec96d..6f431b73e617d 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -1280,6 +1280,7 @@ static const struct of_device_id qcom_scm_dt_match[] = {
{ .compatible = "qcom,scm" },
{}
};
+MODULE_DEVICE_TABLE(of, qcom_scm_dt_match);
static struct platform_driver qcom_scm_driver = {
.driver = {
@@ -1295,3 +1296,6 @@ static int __init qcom_scm_init(void)
return platform_driver_register(_scm_driver);
}
subsys_initcall(qcom_scm_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. SCM driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 04878caf6da49..c64d7a2b65134 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -248,6 +248,7 @@ config SPAPR_TCE_IOMMU
config ARM_SMMU
tristate "ARM Ltd. System MMU (SMMU) Support"
depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
+ depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
@@ -375,6 +376,7 @@ config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
+ depends on QCOM_SCM=y
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU
diff --git a/drivers/net/wireless/ath/ath10k/Kconfig
b/drivers/net/wireless/ath/ath10k/Kconfig
index 40f91bc8514d8..741289e385d59 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -44,6 +44,7 @@ config ATH10K_SNOC
tristate "Qualcomm ath10k SNOC support"
depends on ATH10K
depends on ARCH_QCOM || COMPILE_TEST
+ depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
select QCOM_QMI_HELPERS
help
This module adds support for integrated WCN3990 chip connected
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v5 1/2] pinctrl: qcom: Allow pinctrl-msm code to be loadable as a module
Tweaks to allow pinctrl-msm code to be loadable as a module. This is needed in order to support having the qcom-scm driver, which pinctrl-msm calls into, configured as a module. This requires that we tweak Kconfigs selecting PINCTRL_MSM to also depend on QCOM_SCM || QCOM_SCM=n so that we match the module setting of QCOM_SCM. Unlike the previous revision of this patch: https://lore.kernel.org/lkml/20200625001039.56174-5-john.stu...@linaro.org/ this version reworks PINCTRL_MSM to be a visible option and instead of having the various SoC specific drivers select PINCTRL_MSM, this switches those configs to depend on PINCTRL_MSM. This avoids adding the oddish looking: "depend on QCOM_SCM || QCOM_SCM=n" to every SoC specific driver, as that becomes a maintenance headache. We also add PINCTRL_MSM to the arm64 defconfig to avoid surprises as otherwise PINCTRL_MSM/IPQ* options previously enabled, will be off. Cc: Catalin Marinas Cc: Will Deacon Cc: Andy Gross Cc: Bjorn Andersson Cc: Joerg Roedel Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Cc: Linus Walleij Cc: Vinod Koul Cc: Kalle Valo Cc: Maulik Shah Cc: Lina Iyer Cc: Saravana Kannan Cc: Todd Kjos Cc: Greg Kroah-Hartman Cc: linux-arm-...@vger.kernel.org Cc: iommu@lists.linux-foundation.org Cc: linux-g...@vger.kernel.org Signed-off-by: John Stultz --- v2: * Module description and whitespace fixes suggested by Bjorn * Added QCOM_SCM || QCOM_SCM=n bits on Kconfigs selecting PINCTRL_MSM. Reported by both Todd and Bjorn. v3: * Make sure the QCOM_SCM || QCOM_SCM=n trick is commented v4: * Rework "select PINCTRL_MSM" to "depends on PINCTRL_MSM" to consolidate the QCOM_SCM dependency. v5: * Add PINCTRL_MSM to arm64 defconfig --- arch/arm64/configs/defconfig | 1 + drivers/pinctrl/qcom/Kconfig | 49 +++--- drivers/pinctrl/qcom/pinctrl-msm.c | 2 ++ 3 files changed, 28 insertions(+), 24 deletions(-) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 17a2df6a263e8..45768828fdb8e 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -483,6 +483,7 @@ CONFIG_PINCTRL_IMX8MP=y CONFIG_PINCTRL_IMX8MQ=y CONFIG_PINCTRL_IMX8QXP=y CONFIG_PINCTRL_IMX8DXL=y +CONFIG_PINCTRL_MSM=y CONFIG_PINCTRL_IPQ8074=y CONFIG_PINCTRL_IPQ6018=y CONFIG_PINCTRL_MSM8916=y diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig index 5fe7b8aaf69d8..8bb786ed152dd 100644 --- a/drivers/pinctrl/qcom/Kconfig +++ b/drivers/pinctrl/qcom/Kconfig @@ -2,7 +2,8 @@ if (ARCH_QCOM || COMPILE_TEST) config PINCTRL_MSM - bool + tristate "Qualcomm core pin controller driver" + depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y select PINMUX select PINCONF select GENERIC_PINCONF @@ -13,7 +14,7 @@ config PINCTRL_MSM config PINCTRL_APQ8064 tristate "Qualcomm APQ8064 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm TLMM block found in the Qualcomm APQ8064 platform. @@ -21,7 +22,7 @@ config PINCTRL_APQ8064 config PINCTRL_APQ8084 tristate "Qualcomm APQ8084 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm TLMM block found in the Qualcomm APQ8084 platform. @@ -29,7 +30,7 @@ config PINCTRL_APQ8084 config PINCTRL_IPQ4019 tristate "Qualcomm IPQ4019 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm TLMM block found in the Qualcomm IPQ4019 platform. @@ -37,7 +38,7 @@ config PINCTRL_IPQ4019 config PINCTRL_IPQ8064 tristate "Qualcomm IPQ8064 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm TLMM block found in the Qualcomm IPQ8064 platform. @@ -45,7 +46,7 @@ config PINCTRL_IPQ8064 config PINCTRL_IPQ8074 tristate "Qualcomm Technologies, Inc. IPQ8074 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for the Qualcomm Technologies Inc. TLMM block found on the @@ -55,7 +56,7 @@ config PINCTRL_IPQ8074 config PINCTRL_IPQ6018 tristate "Qualcomm Technologies, Inc. IPQ6018 pin controller driver" depends on GPIOLIB && OF - select PINCTRL_MSM + depends on PINCTRL_MSM help This is the pinctrl, pinmux, pinconf and gpiolib driver for
[RFC][PATCH 1/2] arm-smmu-qcom: Ensure the qcom_scm driver has finished probing
Robin Murphy pointed out that if the arm-smmu driver probes before
the qcom_scm driver, we may call qcom_scm_qsmmu500_wait_safe_toggle()
before the __scm is initialized.
Now, getting this to happen is a bit contrived, as in my efforts it
required enabling asynchronous probing for both drivers, moving the
firmware dts node to the end of the dtsi file, as well as forcing a
long delay in the qcom_scm_probe function.
With those tweaks we ran into the following crash:
[2.631040] arm-smmu 1500.iommu: Stage-1: 48-bit VA -> 48-bit IPA
[2.633372] Unable to handle kernel NULL pointer dereference at virtual
address
...
[2.633402] [] user address but active_mm is swapper
[2.633409] Internal error: Oops: 9605 [#1] PREEMPT SMP
[2.633415] Modules linked in:
[2.633427] CPU: 5 PID: 117 Comm: kworker/u16:2 Tainted: GW
5.10.0-rc1-mainline-00025-g272a618fc36-dirty #3971
[2.633430] Hardware name: Thundercomm Dragonboard 845c (DT)
[2.633448] Workqueue: events_unbound async_run_entry_fn
[2.633456] pstate: 80c5 (Nzcv daif +PAN +UAO -TCO BTYPE=--)
[2.633465] pc : qcom_scm_qsmmu500_wait_safe_toggle+0x78/0xb0
[2.633473] lr : qcom_smmu500_reset+0x58/0x78
[2.633476] sp : ffc0105a3b60
...
[2.633567] Call trace:
[2.633572] qcom_scm_qsmmu500_wait_safe_toggle+0x78/0xb0
[2.633576] qcom_smmu500_reset+0x58/0x78
[2.633581] arm_smmu_device_reset+0x194/0x270
[2.633585] arm_smmu_device_probe+0xc94/0xeb8
[2.633592] platform_drv_probe+0x58/0xa8
[2.633597] really_probe+0xec/0x398
[2.633601] driver_probe_device+0x5c/0xb8
[2.633606] __driver_attach_async_helper+0x64/0x88
[2.633610] async_run_entry_fn+0x4c/0x118
[2.633617] process_one_work+0x20c/0x4b0
[2.633621] worker_thread+0x48/0x460
[2.633628] kthread+0x14c/0x158
[2.633634] ret_from_fork+0x10/0x18
[2.633642] Code: a9034fa0 d0007f73 29107fa0 91342273 (f9400020)
To avoid this, this patch adds a check on qcom_scm_is_available() in
the qcom_smmu_impl_init() function, returning -EPROBE_DEFER if its
not ready.
This allows the driver to try to probe again later after qcom_scm has
finished probing.
Cc: Robin Murphy
Cc: Will Deacon
Cc: Andy Gross
Cc: Maulik Shah
Cc: Bjorn Andersson
Cc: Saravana Kannan
Cc: Marc Zyngier
Cc: Lina Iyer
Cc: iommu@lists.linux-foundation.org
Cc: linux-arm-msm
Reported-by: Robin Murphy
Signed-off-by: John Stultz
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 66ba4870659f4..ef37ccfa82562 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -159,6 +159,10 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct
arm_smmu_device *smmu)
{
struct qcom_smmu *qsmmu;
+ /* Check to make sure qcom_scm has finished probing */
+ if (!qcom_scm_is_available())
+ return ERR_PTR(-EPROBE_DEFER);
+
qsmmu = devm_kzalloc(smmu->dev, sizeof(*qsmmu), GFP_KERNEL);
if (!qsmmu)
return ERR_PTR(-ENOMEM);
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC][PATCH 2/2] iommu: Avoid crash if iommu_group is null
In trying to handle a possible driver probe ordering issue brought up by Robin Murphy, I ran across a separate null pointer crash in the iommu core in iommu_group_remove_device(): [2.732803] dwc3-qcom a6f8800.usb: failed to get usb-ddr path: -517 [2.739281] Unable to handle kernel NULL pointer dereference at virtual address 00c0 ... [2.775619] [00c0] user address but active_mm is swapper [2.782039] Internal error: Oops: 9605 [#1] PREEMPT SMP [2.787670] Modules linked in: [2.790769] CPU: 6 PID: 1 Comm: swapper/0 Tainted: GW 5.10.0-rc1-mainline-00025-g272a618fc36-dirty #3973 [2.801719] Hardware name: Thundercomm Dragonboard 845c (DT) [2.807431] pstate: 00c5 (nzcv daif +PAN +UAO -TCO BTYPE=--) [2.813508] pc : iommu_group_remove_device+0x30/0x1b0 [2.818611] lr : iommu_release_device+0x4c/0x78 [2.823189] sp : ffc01005b950 ... [2.907082] Call trace: [2.909566] iommu_group_remove_device+0x30/0x1b0 [2.914323] iommu_release_device+0x4c/0x78 [2.918559] iommu_bus_notifier+0xe8/0x108 [2.922708] blocking_notifier_call_chain+0x78/0xb8 [2.927641] device_del+0x2ac/0x3d0 [2.931177] platform_device_del.part.9+0x20/0x98 [2.935933] platform_device_unregister+0x2c/0x40 [2.940694] of_platform_device_destroy+0xd8/0xe0 [2.945450] device_for_each_child_reverse+0x58/0xb0 [2.950471] of_platform_depopulate+0x4c/0x78 [2.954886] dwc3_qcom_probe+0x93c/0xcb8 [2.958858] platform_drv_probe+0x58/0xa8 [2.962917] really_probe+0xec/0x398 [2.966531] driver_probe_device+0x5c/0xb8 [2.970677] device_driver_attach+0x74/0x98 [2.974911] __driver_attach+0x60/0xe8 [2.978700] bus_for_each_dev+0x84/0xd8 [2.982581] driver_attach+0x30/0x40 [2.986194] bus_add_driver+0x160/0x208 [2.990076] driver_register+0x64/0x110 [2.993957] __platform_driver_register+0x58/0x68 [2.998716] dwc3_qcom_driver_init+0x20/0x28 [3.003041] do_one_initcall+0x6c/0x2d0 [3.006925] kernel_init_freeable+0x214/0x268 [3.011339] kernel_init+0x18/0x118 [3.014876] ret_from_fork+0x10/0x18 [3.018495] Code: d0006a21 f9417295 91130021 910162b6 (b940c2a2) In the case above, the arm-smmu driver fails to probe with EPROBE_DEFER, and I'm guessing I'm guessing that causes iommu_group_add_device() to fail and sets the dev->iommu_group = NULL, then somehow we hit iommu_group_remove_device() and trip over the null value? I'm not really sure... Anyway, adding the null check seems to avoid the issue and the system boots fine after the arm-smmu driver later reprobed. Feedback or better ideas for a solution would be appreciated! Cc: Robin Murphy Cc: Will Deacon Cc: Andy Gross Cc: Maulik Shah Cc: Bjorn Andersson Cc: Saravana Kannan Cc: Marc Zyngier Cc: Lina Iyer Cc: iommu@lists.linux-foundation.org Cc: linux-arm-msm Signed-off-by: John Stultz --- drivers/iommu/iommu.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 8c470f451a323..44639b88e77db 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -877,6 +877,10 @@ void iommu_group_remove_device(struct device *dev) struct iommu_group *group = dev->iommu_group; struct group_device *tmp_device, *device = NULL; + /* Avoid crash if iommu_group value is null */ + if (!group) + return; + dev_info(dev, "Removing from iommu group %d\n", group->id); /* Pre-notify listeners that a device is being removed. */ -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 5/5] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
On Fri, Oct 30, 2020 at 7:12 AM Robin Murphy wrote: > On 2020-10-30 01:02, John Stultz wrote: > > On Wed, Oct 28, 2020 at 7:51 AM Robin Murphy wrote: > >> Hmm, perhaps I'm missing something here, but even if the config options > >> *do* line up, what prevents arm-smmu probing before qcom-scm and > >> dereferencing NULL in qcom_scm_qsmmu500_wait_safe_toggle() before __scm > >> is initialised? > > > > Oh man, this spun me on a "wait, but how does it all work!" trip. :) > > > > So in the non-module case, the qcom_scm driver is a subsys_initcall > > and the arm-smmu is a module_platform_driver, so the ordering works > > out. > > > > In the module case, the arm-smmu code isn't loaded until the qcom_scm > > driver finishes probing due to the symbol dependency handling. > > My point is that module load != driver probe. AFAICS you could disable > drivers_autoprobe, load both modules, bind the SMMU to its driver first, > and boom! > > > To double check this, I added a big msleep at the top of the > > qcom_scm_probe to try to open the race window you described, but the > > arm_smmu_device_probe() doesn't run until after qcom_scm_probe > > completes. > > I don't think asynchronous probing is enabled by default, so indeed I > would expect that to still happen to work ;) > > > So at least as a built in / built in, or a module/module case its ok. > > And in the case where arm-smmu is a module and qcom_scm is built in > > that's ok too. > > In the built-in case, I'm sure it happens to work out similarly because > the order of nodes in the DTB tends to be the order in which devices are > autoprobed. Again, async probe might be enough to break things; manually > binding drivers definitely should; moving the firmware node to the end > of the DTB probably would as well. So, with modules, I turned on async probing for the two drivers, as well as moved the firmware node to the end of the dtb, and couldn't manage to trip it up even with a 6 second delay in the qcom_scm probe function. It was only when doing the same with everything built in that I did manage to trigger the issue. So yes, you're right! And it is an issue more easily tripped with everything built in statically (and not really connected to this patch series). > > Its just the case my patch is trying to prevent is where arm-smmu is > > built in, but qcom_scm is a module that it can't work (due to build > > errors in missing symbols, or if we tried to use function pointers to > > plug in the qcom_scm - the lack of initialization ordering). > > > > Hopefully that addresses your concern? Let me know if I'm still > > missing something. > > What I was dancing around is that the SCM API (and/or its users) appears > to need a general way to tell whether SCM is ready or not, because the > initialisation ordering problem is there anyway. Neither Kconfig nor the > module loader can solve that. Hrm... There is qcom_scm_is_available(). I tried adding a check for that in qcom_smmu_impl_init() and return EPROBE_DEFER if it fails, but I then hit a separate crash (tripping in iommu_group_remove_device on a null dev->iommu_group value). But after adding a check for that, it seems to be working... I'll try to spin up a separate patch here for that in a second. thanks -john ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
