Re: [PATCH 4/7] dt-bindings: renesas,rcar-dmac: R-Car V3U is R-Car Gen4

2022-05-16 Thread Vinod Koul 
On 02-05-22, 15:34, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family.  Hence move its compatible value to the R-Car Gen4 section.

Applied, thanks

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] dt-bindings: Improve phandle-array schemas

2022-01-19 Thread Vinod Koul 
On 18-01-22, 19:50, Rob Herring wrote:
> The 'phandle-array' type is a bit ambiguous. It can be either just an
> array of phandles or an array of phandles plus args. Many schemas for
> phandle-array properties aren't clear in the schema which case applies
> though the description usually describes it.
> 
> The array of phandles case boils down to needing:
> 
> items:
>   maxItems: 1
> 
> The phandle plus args cases should typically take this form:
> 
> items:
>   - items:
>   - description: A phandle
>   - description: 1st arg cell
>   - description: 2nd arg cell
> 
> With this change, some examples need updating so that the bracketing of
> property values matches the schema.

Acked-By: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [patch V3 34/35] soc: ti: ti_sci_inta_msi: Get rid of ti_sci_inta_msi_get_virq()

2021-12-12 Thread Vinod Koul 
On 10-12-21, 23:19, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> Just use the core function msi_get_virq().

Acked-By: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [patch V3 35/35] dmaengine: qcom_hidma: Cleanup MSI handling

2021-12-12 Thread Vinod Koul 
On 10-12-21, 23:19, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> There is no reason to walk the MSI descriptors to retrieve the interrupt
> number for a device. Use msi_get_virq() instead.

Acked-By: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [patch V3 29/35] dmaengine: mv_xor_v2: Get rid of msi_desc abuse

2021-12-12 Thread Vinod Koul 
On 10-12-21, 23:19, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> Storing a pointer to the MSI descriptor just to keep track of the Linux
> interrupt number is daft. Use msi_get_virq() instead.

Acked-By: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 4/4] dmaengine: idxd: Use DMA API for in-kernel DMA with PASID

2021-12-07 Thread Vinod Koul 
On 07-12-21, 16:27, Dave Jiang wrote:
> 
> On 12/7/2021 6:47 AM, Jacob Pan wrote:
> > In-kernel DMA should be managed by DMA mapping API. The existing kernel
> > PASID support is based on the SVA machinery in SVA lib that is intended
> > for user process SVA. The binding between a kernel PASID and kernel
> > mapping has many flaws. See discussions in the link below.
> > 
> > This patch utilizes iommu_enable_pasid_dma() to enable DSA to perform DMA
> > requests with PASID under the same mapping managed by DMA mapping API.
> > In addition, SVA-related bits for kernel DMA are removed. As a result,
> > DSA users shall use DMA mapping API to obtain DMA handles instead of
> > using kernel virtual addresses.
> > 
> > Link: 
> > https://lore.kernel.org/linux-iommu/20210511194726.gp1002...@nvidia.com/
> > Signed-off-by: Jacob Pan 
> 
> Acked-by: Dave Jiang 
> 
> Also cc Vinod and dmaengine@vger

Pls resend collecting acks. I dont have this in my queue

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/2] iommu: arm-smmu-impl: Add SM8450 qcom iommu implementation

2021-11-30 Thread Vinod Koul 
Add SM8450 qcom iommu implementation to the table of
qcom_smmu_impl_of_match table which brings in iommu support for
SM8450 SoC

Signed-off-by: Vinod Koul 
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index ca736b065dd0..4aee83330629 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -415,6 +415,7 @@ static const struct of_device_id __maybe_unused 
qcom_smmu_impl_of_match[] = {
{ .compatible = "qcom,sm8150-smmu-500" },
{ .compatible = "qcom,sm8250-smmu-500" },
{ .compatible = "qcom,sm8350-smmu-500" },
+   { .compatible = "qcom,sm8450-smmu-500" },
{ }
 };
 
-- 
2.31.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 1/2] dt-bindings: arm-smmu: Add compatible for SM8450 SoC

2021-11-30 Thread Vinod Koul 
Add the SoC specific compatible for SM8450 implementing
arm,mmu-500.

Signed-off-by: Vinod Koul 
---
 Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml 
b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index f66a3effba73..8d15b281b0ac 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -42,6 +42,7 @@ properties:
   - qcom,sm8150-smmu-500
   - qcom,sm8250-smmu-500
   - qcom,sm8350-smmu-500
+  - qcom,sm8450-smmu-500
   - const: arm,mmu-500
   - description: Qcom Adreno GPUs implementing "arm,smmu-v2"
 items:
-- 
2.31.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 0/2] Add support from SM8450 IOMMU

2021-11-30 Thread Vinod Koul 
This adds the binding and support for IOMMU found in SM8450 SoC

Vinod Koul (2):
  dt-bindings: arm-smmu: Add compatible for SM8450 SoC
  iommu: arm-smmu-impl: Add SM8450 qcom iommu implementation

 Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c| 1 +
 2 files changed, 2 insertions(+)

-- 
2.31.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems

2021-06-16 Thread Vinod Koul 
On 15-06-21, 13:15, Rob Herring wrote:
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final schema adding any unspecified minItems/maxItems.
> 
> This condition is partially checked with the meta-schema already, but
> only if both 'minItems' and 'maxItems' are equal to the 'items' length.
> An improved meta-schema is pending.

>  .../devicetree/bindings/dma/renesas,rcar-dmac.yaml  | 1 -

>  Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml| 1 -
>  Documentation/devicetree/bindings/phy/mediatek,tphy.yaml| 2 --
>  .../devicetree/bindings/phy/phy-cadence-sierra.yaml | 2 --
>  .../devicetree/bindings/phy/phy-cadence-torrent.yaml| 4 
>  .../devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml| 1 -
>  .../devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml| 1 -
>  Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 1 -
>  Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml   | 2 --
>  Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 2 --
>  Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml | 1 -

Acked-By: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid()

2021-06-03 Thread Vinod Koul 
On 03-06-21, 13:42, Borislav Petkov wrote:
> On Thu, Jun 03, 2021 at 04:50:26PM +0530, Vinod Koul wrote:
> > Applied, thanks
> 
> Actually, I'd prefer if I take it through the tip tree:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/urgent
> 
> because it is needed for the following patch by tglx:
> 
> 6867ee8bcb75 x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove 
> update_pasid()
> db099bafbf5e dmaengine: idxd: Use cpu_feature_enabled()
> 
> if you don't mind.
> 
> I'll be sending this to Linus this weekend.

Okay dropped now..

You can add:

Acked-By: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid()

2021-06-03 Thread Vinod Koul 
On 02-06-21, 12:14, Borislav Petkov wrote:
> ---
> From: Borislav Petkov 
> Date: Wed, 2 Jun 2021 12:07:52 +0200
> Subject: [PATCH] dmaengine: idxd: Use cpu_feature_enabled()
> 
> When testing x86 feature bits, use cpu_feature_enabled() so that
> build-disabled features can remain off, regardless of what CPUID says.

Applied, thanks

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 14/30] Revert "s3c24xx-dma.c: Fix a typo"

2021-03-30 Thread Vinod Koul 
On 29-03-21, 05:23, Bhaskar Chowdhury wrote:
> s/transferred/transfered/
> 
> This reverts commit a2ddb8aea8106bd5552f8516ad7a8a26b9282a8f.

This is not upstream, why not squash in. Also would make sense to write
sensible changelog and not phrases and use the right subsystem
conventions!

Droped the series now


-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas

2021-02-03 Thread Vinod Koul 
On 02-02-21, 14:55, Rob Herring wrote:
> Properties in if/then schemas weren't getting checked by the meta-schemas.
> Enabling meta-schema checks finds several errors.
> 
> The use of an 'items' schema (as opposed to the list form) is wrong in
> some cases as it applies to all entries. 'contains' is the correct schema
> to use in the case of multiple entries.
> 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Eric Anholt 
> Cc: Nicolas Saenz Julienne 
> Cc: Florian Fainelli 
> Cc: Ray Jui 
> Cc: Scott Branden 
> Cc: Pavel Machek 
> Cc: Ulf Hansson 
> Cc: Kishon Vijay Abraham I 
> Cc: Vinod Koul 
> Cc: Geert Uytterhoeven 
> Cc: Linus Walleij 
> Cc: Daniel Lezcano 
> Cc: linux-cry...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-l...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/crypto/allwinner,sun8i-ce.yaml   | 3 +--
>  .../devicetree/bindings/display/brcm,bcm2835-hvs.yaml| 2 +-
>  Documentation/devicetree/bindings/leds/ti,tca6507.yaml   | 1 +
>  Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml  | 2 +-
>  Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml | 3 +--
>  .../devicetree/bindings/phy/renesas,usb2-phy.yaml| 5 ++---

For phy:

Acked-By: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 1/2] dt-bindings: arm-smmu: Add sm8350 compatible string

2021-01-15 Thread Vinod Koul 
Add compatible string for sm8350 iommu to documentation.

Signed-off-by: Vinod Koul 
---
 Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml 
b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 3b63f2ae24db..161a5d389808 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -37,6 +37,7 @@ properties:
   - qcom,sdm845-smmu-500
   - qcom,sm8150-smmu-500
   - qcom,sm8250-smmu-500
+  - qcom,sm8350-smmu-500
   - const: arm,mmu-500
   - description: Qcom Adreno GPUs implementing "arm,smmu-v2"
 items:
-- 
2.26.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/2] iommu: arm-smmu-impl: Add SM8350 qcom iommu implementation

2021-01-15 Thread Vinod Koul 
Add SM8350 qcom iommu implementation to the table of
qcom_smmu_impl_of_match table which brings in iommu support for SM8350
SoC

Signed-off-by: Vinod Koul 
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 5dff7ffbef11..8044a9bfca66 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -327,6 +327,7 @@ static const struct of_device_id __maybe_unused 
qcom_smmu_impl_of_match[] = {
{ .compatible = "qcom,sdm845-smmu-500" },
{ .compatible = "qcom,sm8150-smmu-500" },
{ .compatible = "qcom,sm8250-smmu-500" },
+   { .compatible = "qcom,sm8350-smmu-500" },
{ }
 };
 
-- 
2.26.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 4/9] dt-bindings: dma: renesas,rcar-dmac: Document R8A774E1 bindings

2020-07-15 Thread Vinod Koul 
On 13-07-20, 22:35, Lad Prabhakar wrote:
> Renesas RZ/G2H (R8A774E1) SoC also has the R-Car gen3 compatible
> DMA controllers, therefore document RZ/G2H specific bindings.

Applied, thanks

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 4/5] iommu/arm-smmu-qcom: Consstently initialize stream mappings

2020-07-09 Thread Vinod Koul 
On 08-07-20, 22:01, Bjorn Andersson wrote:
> Firmware that traps writes to S2CR to translate BYPASS into FAULT also
> ignores writes of type FAULT. As such booting with "disable_bypass" set
> will result in all S2CR registers left as configured by the bootloader.
> 
> This has been seen to result in indeterministic results, as these
> mappings might linger and reference context banks that Linux is
> reconfiguring.
> 
> Use the fact that BYPASS writes result in FAULT type to force all stream
> mappings to FAULT.

s/Consstently/Consistently in patch subject

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 0/5] iommu/arm-smmu: Support maintaining bootloader mappings

2020-07-09 Thread Vinod Koul 
On 08-07-20, 22:01, Bjorn Andersson wrote:
> Based on previous attempts and discussions this is the latest attempt at
> inheriting stream mappings set up by the bootloader, for e.g. boot splash or
> efifb.
> 
> The first patch is an implementation of Robin's suggestion that we should just
> mark the relevant stream mappings as BYPASS. Relying on something else to set
> up the stream mappings wanted - e.g. by reading it back in platform specific
> implementation code.
> 
> The series then tackles the problem seen in most versions of Qualcomm 
> firmware,
> that the hypervisor intercepts BYPASS writes and turn them into FAULTs. It 
> does
> this by allocating context banks for identity domains as well, with 
> translation
> disabled.
> 
> Lastly it amends the stream mapping initialization code to allocate a specific
> identity domain that is used for any mappings inherited from the bootloader, 
> if
> above Qualcomm quirk is required.
> 
> 
> The series has been tested and shown to allow booting SDM845, SDM850, SM8150,
> SM8250 with boot splash screen setup by the bootloader. Specifically it also
> allows the Lenovo Yoga C630 to boot with SMMU and efifb enabled.

This resolves issue on RB3 for me so:

Tested-by: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC][PATCH 5/5] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-07-03 Thread Vinod Koul 
On 03-07-20, 13:23, Will Deacon wrote:
> On Tue, Jun 16, 2020 at 01:52:32PM -0700, John Stultz wrote:
> > On Tue, Jun 16, 2020 at 12:55 AM Marc Zyngier  wrote:
> > > On 2020-06-16 07:13, John Stultz wrote:
> > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > > > index b510f67dfa49..714893535dd2 100644
> > > > --- a/drivers/iommu/Kconfig
> > > > +++ b/drivers/iommu/Kconfig
> > > > @@ -381,6 +381,7 @@ config SPAPR_TCE_IOMMU
> > > >  config ARM_SMMU
> > > >   tristate "ARM Ltd. System MMU (SMMU) Support"
> > > >   depends on (ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)) 
> > > > &&
> > > > MMU
> > > > + depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
> > >
> > > This looks a bit ugly. Could you explain why we need this at the SMMU
> > > level? I'd have expected the dependency to flow the other way around...
> > 
> > Yea, so the arm-smmu-qcom.c file calls directly into the qcom-scm code
> > via qcom_scm_qsmmu500_wait_safe_toggle()
> >   
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/arm-smmu-qcom.c?h=v5.8-rc1#n44
> > 
> > So if ARM_SMMU=y and QCOM_SCM=m we get:
> > drivers/iommu/arm-smmu-qcom.o: In function `qcom_smmu500_reset':
> > arm-smmu-qcom.c:(.text+0xb4): undefined reference to
> > `qcom_scm_qsmmu500_wait_safe_toggle'
> > 
> > Do you have a suggestion for an alternative approach?
> 
> Can you use symbol_get() or something like that? How are module dependencies
> handled by other drivers?

So drivers deal with this by making rules in Kconfig which will prohibit
this case. QCOM_SCM depends on ARM_SMMU with the caveat that if ARM_SMMU
is a module, QCOM_SCM cant be inbuilt.

This can be done by adding below line in Kconfig for QCOM_SCM:

depends on ARM_SMMU || !ARM_SMMU

This is quite prevalent is drivers to ensure dependency like this

Thanks
-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] dmaengine: fsl-edma: dma map slave device address

2019-02-03 Thread Vinod Koul 
On 18-01-19, 12:06, Laurentiu Tudor wrote:
> This mapping needs to be created in order for slave dma transfers
> to work on systems with SMMU. The implementation mostly mimics the
> one in pl330 dma driver, authored by Robin Murphy.

Applied, thanks

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 02/18] dmaengine: imx-sdma: pass struct device to DMA API functions

2019-02-02 Thread Vinod Koul 
On 01-02-19, 09:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons.  Pass the easily
> available struct device from the platform_device to remedy this.

This looks good to me but fails to apply. Can you please base it on
dmaengine-next or linux-next please and resend

Thanks
-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 6/6] dmaengine: sh: rcar-dmac: Use device_iommu_mapped()

2018-12-16 Thread Vinod Koul 
On 11-12-18, 14:43, Joerg Roedel wrote:
> From: Joerg Roedel 
> 
> Use Use device_iommu_mapped() to check if the device is
> already mapped by an IOMMU.

Acked-by: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/6] driver core: Introduce device_iommu_mapped() function

2018-12-16 Thread Vinod Koul 
On 11-12-18, 14:43, Joerg Roedel wrote:
> From: Joerg Roedel 
> 
> Some places in the kernel check the iommu_group pointer in
> 'struct device' in order to find ot whether a device is
   ^^
Typo
-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE

2018-11-27 Thread Vinod Koul 
On 26-11-18, 17:56, Anshuman Khandual wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace these open encodings for an invalid node number with the
> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
> 'invalid node' from various places redirecting them to a common definition.
> 

>  drivers/dma/dmaengine.c   |  4 +++-


Acked-by: Vinod Koul 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] mm: Replace all open encodings for NUMA_NO_NODE

2018-11-24 Thread Vinod Koul 
On 23-11-18, 15:24, Anshuman Khandual wrote:

> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -386,7 +386,8 @@ EXPORT_SYMBOL(dma_issue_pending_all);
>  static bool dma_chan_is_local(struct dma_chan *chan, int cpu)
>  {
>   int node = dev_to_node(chan->device->dev);
> - return node == -1 || cpumask_test_cpu(cpu, cpumask_of_node(node));
> + return node == NUMA_NO_NODE ||
> + cpumask_test_cpu(cpu, cpumask_of_node(node));
>  }

I do not see dev_to_node being updated first, that returns -1 so I would
prefer to check for -1 unless it return NUMA_NO_NODE

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 2/2] drivers: remove force dma flag from buses

2018-05-03 Thread Vinod Koul 
On Sat, Apr 28, 2018 at 08:21:59AM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if implicit DMA
> configuration is required even when it is not described by the
> firmware.
> 
> Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> Acked-by: Bjorn Helgaas <bhelg...@google.com>  # PCI parts
> ---
> Changes in v2:
>   - This is a new change suggested by Robin and Christoph
> and is added to the series.
> 
> Changes in v3:
>   - Rebase and changes corresponding to the changes in patch 1/2
> 
> Changes in v4:
>   - Rebased on top of 4.17-rc2
> 
>  drivers/amba/bus.c| 1 -
>  drivers/base/platform.c   | 3 +--
>  drivers/bcma/main.c       | 2 +-
>  drivers/dma/qcom/hidma_mgmt.c | 2 +-

This one:
Acked-by: Vinod Koul <vk...@kernel.org>

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

2017-06-14 Thread Vinod Koul 
On Thu, Jun 08, 2017 at 03:25:28PM +0200, Christoph Hellwig wrote:
> DMA_ERROR_CODE is not a public API and will go away.  Instead properly
> unwind based on the loop counter.

Acked-By: Vinod Koul <vinod.k...@intel.com>

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RESEND PATCH V6 5/6] dmaengine: pl330: Make sure microcode is privileged

2016-12-05 Thread Vinod Koul 
On Fri, Dec 02, 2016 at 08:25:08PM +0530, Sricharan R wrote:
> From: Mitchel Humpherys <mitch...@codeaurora.org>
> 
> The PL330 performs privileged instruction fetches.  This can result in
> SMMU permission faults on SMMUs that implement the ARMv8 VMSA, which
> specifies that mappings that are writeable at one execution level shall
> not be executable at any higher-privileged level.  Fix this by using the
> DMA_ATTR_PRIVILEGED attribute, which will ensure that the microcode
> IOMMU mapping is only accessible to the privileged level.

Acked-by: Vinod Koul <vinod.k...@intel.com>

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] dma-debug: fix ia64 build, use PHYS_PFN

2016-09-30 Thread Vinod Koul 
On Thu, Sep 29, 2016 at 09:59:15PM +0200, Niklas Söderlund wrote:
> kbuild test robot reports:
> 
>lib/dma-debug.c: In function 'debug_dma_map_resource':
> >> lib/dma-debug.c:1541:16: error: implicit declaration of function 
> >> '__phys_to_pfn' [-Werror=implicit-function-declaration]
>  entry->pfn  = __phys_to_pfn(addr);
>^
> 
> ia64 does not provide __phys_to_pfn(), use the PHYS_PFN() alias.

Applied, thanks

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 0/2] dma-mapping: fix ia64 and m32r build error and warnings

2016-09-29 Thread Vinod Koul 
On Thu, Sep 29, 2016 at 12:02:38PM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund 
> 
> Hi Vindo,

:(

> 
> This small series fixes the build error and warnings for ia64 and m32r 
> which kbuild test robot found and where introduced in the series 
> '[PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave 
> transfers'.

Applied both

Thanks
-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

2016-09-26 Thread Vinod Koul 
On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> Hi,
> 
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> recent patch '9575632 (dmaengine: make slave address physical)'
> clarifies that DMA slave address provided by clients is the physical
> address. This puts the task of mapping the DMA slave address from a
> phys_addr_t to a dma_addr_t on the DMA engine.
> 
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU you
> need to map the DMA slave phys_addr_t to a dma_addr_t using something
> like this.
> 
> This series is based on top of v4.8-rc1. And I'm hoping to be able to collect 
> a
> Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> able to take the whole series through the dmaengine tree. If this is not the
> best route I'm more then happy to do it another way.
> 
> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> /dev/mmcblk1, i2c and the serial console which are devices behind the
> iommu.
> 
> Furthermore I have audited to the best of my ability all call paths
> involved to make sure that the dma_addr_t obtained from
> dma_map_resource() to is not used in a way where it would be expected
> for the mapping to be RAM (have a struct page). Many thanks to Christoph
> Hellwig and Laurent Pinchart for there input in this effort.

Applied, thanks

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

2016-09-15 Thread Vinod Koul 
On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> > Hi,
> > 
> > This series tries to solve the problem with DMA with device registers
> > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> > recent patch '9575632 (dmaengine: make slave address physical)'
> > clarifies that DMA slave address provided by clients is the physical
> > address. This puts the task of mapping the DMA slave address from a
> > phys_addr_t to a dma_addr_t on the DMA engine.
> > 
> > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > the same and no special care is needed. However if you have a IOMMU you
> > need to map the DMA slave phys_addr_t to a dma_addr_t using something
> > like this.
> > 
> > This series is based on top of v4.8-rc1. And I'm hoping to be able to 
> > collect a
> > Ack from Russell King on patch 4/6 that adds the ARM specific part and then 
> > be
> > able to take the whole series through the dmaengine tree. If this is not the
> > best route I'm more then happy to do it another way.
> > 
> > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> > /dev/mmcblk1, i2c and the serial console which are devices behind the
> > iommu.
> 
> As I said in last one, the dmaengine parts look fine to me. But to go thru
> dmaengine tree I would need ACK on non dmaengine patches.

I havent heard back from this one and I am inclined to merge this one now.
If anyone has any objects, please speak up now...

Also ACKs welcome...

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

2016-08-10 Thread Vinod Koul 
On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> Hi,
> 
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> recent patch '9575632 (dmaengine: make slave address physical)'
> clarifies that DMA slave address provided by clients is the physical
> address. This puts the task of mapping the DMA slave address from a
> phys_addr_t to a dma_addr_t on the DMA engine.
> 
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU you
> need to map the DMA slave phys_addr_t to a dma_addr_t using something
> like this.
> 
> This series is based on top of v4.8-rc1. And I'm hoping to be able to collect 
> a
> Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> able to take the whole series through the dmaengine tree. If this is not the
> best route I'm more then happy to do it another way.
> 
> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> /dev/mmcblk1, i2c and the serial console which are devices behind the
> iommu.

As I said in last one, the dmaengine parts look fine to me. But to go thru
dmaengine tree I would need ACK on non dmaengine patches.


-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v5 5/6] dmaengine: pl330: Make sure microcode is privileged

2016-08-07 Thread Vinod Koul 
On Wed, Jul 27, 2016 at 04:42:07PM -0700, Mitchel Humpherys wrote:
> The PL330 performs privileged instruction fetches.  This can result in
> SMMU permission faults on SMMUs that implement the ARMv8 VMSA, which

Lot of acronyms with no explanation whatsoever

> specifies that mappings that are writeable at one execution level shall
> not be executable at any higher-privileged level.  Fix this by using the
> DMA_ATTR_PRIVILEGED attribute, which will ensure that the microcode
> IOMMU mapping is only accessible to the privileged level.

And I get satndalone patch with no context for the series!

> 
> Cc: Dan Williams <dan.j.willi...@intel.com>
> Cc: Vinod Koul <vinod.k...@intel.com>
> Reviewed-by: Robin Murphy <robin.mur...@arm.com>
> Tested-by: Robin Murphy <robin.mur...@arm.com>
> Signed-off-by: Mitchel Humpherys <mitch...@codeaurora.org>
> ---
> 
> Notes:
> v3..v4
> 
>   - Reworked against the new dma attrs format.
> 
>  drivers/dma/pl330.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 4fc3ffbd5ca0..8cd624fc3760 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -1854,14 +1854,16 @@ static int dmac_alloc_resources(struct pl330_dmac 
> *pl330)
>  {
>   int chans = pl330->pcfg.num_chan;
>   int ret;
> + unsigned long dma_attrs = DMA_ATTR_PRIVILEGED;
>  
>   /*
>* Alloc MicroCode buffer for 'chans' Channel threads.
>* A channel's buffer offset is (Channel_Id * MCODE_BUFF_PERCHAN)
>*/
> - pl330->mcode_cpu = dma_alloc_coherent(pl330->ddma.dev,
> + pl330->mcode_cpu = dma_alloc_attrs(pl330->ddma.dev,
>   chans * pl330->mcbufsz,
> - >mcode_bus, GFP_KERNEL);
> + >mcode_bus, GFP_KERNEL,
> + dma_attrs);
>   if (!pl330->mcode_cpu) {
>   dev_err(pl330->ddma.dev, "%s:%d Can't allocate memory!\n",
>   __func__, __LINE__);
> -- 
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCHv7 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

2016-06-02 Thread Vinod Koul 
On Thu, Jun 02, 2016 at 02:58:07PM +0200, Niklas Söderlund wrote:
> Hi Vinod,
> 
> On 2016-06-01 23:36:11 +0530, Vinod Koul wrote:
> > On Wed, Jun 01, 2016 at 05:22:23PM +0200, Niklas Söderlund wrote:
> > > Hi,
> > > 
> > > [In this v7 series I have tried to address the questions raised by 
> > > Christoph 
> > > Hellwig and I hope it can awnser your concernes regarding dma-debug.]
> > > 
> > > This series tries to solve the problem with DMA with device registers
> > > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> > > recent patch '9575632 (dmaengine: make slave address physical)'
> > > clarifies that DMA slave address provided by clients is the physical
> > > address. This puts the task of mapping the DMA slave address from a
> > > phys_addr_t to a dma_addr_t on the DMA engine.
> > > 
> > > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > > the same and no special care is needed. However if you have a IOMMU you
> > > need to map the DMA slave phys_addr_t to a dma_addr_t using something
> > > like this.
> > > 
> > > This series is based on top of v4.7-rc1.
> > 
> > The dmanegine bits looks okay to me. Btw how is the merge planned for this?
> > Do you wnat this to be merged thru dmaengine tree or something else?
> 
> Yes, since the arm specific patch are depending on other parts of the 
> series I was hoping to be able to get Russells Ack on it and then try to 
> get it all in through the dmaengine tree.

Sounds good to me..

> If you see a better way I'm happy to do it that way, let me know what 
> you think. I hold off v8 that adresses the issues Russell brought up a 
> few days untill I know what you think is best.

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCHv7 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

2016-06-01 Thread Vinod Koul 
On Wed, Jun 01, 2016 at 05:22:23PM +0200, Niklas Söderlund wrote:
> Hi,
> 
> [In this v7 series I have tried to address the questions raised by Christoph 
> Hellwig and I hope it can awnser your concernes regarding dma-debug.]
> 
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> recent patch '9575632 (dmaengine: make slave address physical)'
> clarifies that DMA slave address provided by clients is the physical
> address. This puts the task of mapping the DMA slave address from a
> phys_addr_t to a dma_addr_t on the DMA engine.
> 
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU you
> need to map the DMA slave phys_addr_t to a dma_addr_t using something
> like this.
> 
> This series is based on top of v4.7-rc1.

The dmanegine bits looks okay to me. Btw how is the merge planned for this?
Do you wnat this to be merged thru dmaengine tree or something else?

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

2016-03-10 Thread Vinod Koul 
On Thu, Mar 10, 2016 at 05:05:23PM +0100, Niklas S??derlund wrote:
> Hi Christoph,
> 
> On 2016-03-07 23:38:47 -0800, Christoph Hellwig wrote:
> > Please add some documentation on where/how this should be used.  It's
> > not a very obvious interface.
> 
> Good idea, I have added the following to Documentation/DMA-API.txt and 
> folded it in to this patch. Do you feel it's adequate and do you know 
> anywhere else I should add documentation?
> 
> diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
> index 45ef3f2..248556a 100644
> --- a/Documentation/DMA-API.txt
> +++ b/Documentation/DMA-API.txt
> @@ -277,14 +277,29 @@ and  parameters are provided to do partial page 
> mapping, it is
>  recommended that you never use these unless you really know what the
>  cache width is.
>  
> +dma_addr_t
> +dma_map_resource(struct device *dev, phys_addr_t phys_addr, size_t size,
> +enum dma_data_direction dir, struct dma_attrs *attrs)
> +
> +Maps a MMIO region so it can be accessed by the device and returns the
> +DMA address of the memory. API should only be used to map device MMIO,
> +mapping of RAM is not permitted.
> +
> +void
> +dma_unmap_resource(struct device *dev, dma_addr_t addr, size_t size,
> +  enum dma_data_direction dir, struct dma_attrs *attrs)

Using function prototypes in documentation may not be a great idea as you
are explaining the role of this function and not arguments.

> +
> +Unmaps the IOMMU region previously mapped. All the parameters passed in
> +must be identical to those passed in (and returned) by the mapping API.
> +
>  int
>  dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
>  
> -In some circumstances dma_map_single() and dma_map_page() will fail to create
> -a mapping. A driver can check for these errors by testing the returned
> -DMA address with dma_mapping_error(). A non-zero return value means the 
> mapping
> -could not be created and the driver should take appropriate action (e.g.
> -reduce current DMA mapping usage or delay and try again later).
> +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
> +will fail to create a mapping. A driver can check for these errors by testing
> +the returned DMA address with dma_mapping_error(). A non-zero return value
> +means the mapping could not be created and the driver should take appropriate
> +action (e.g.  reduce current DMA mapping usage or delay and try again later).
> 
> -- 
> Regards,
> Niklas Söderlund

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 3/9] ACPI: add struct acpi_amba_quirk for AMD pl330 specific device config

2015-12-11 Thread Vinod Koul 
On Fri, Dec 11, 2015 at 06:57:51AM +, Wang, Annie wrote:
> >> +  /*
> >> +   * If the ACPI device already has a node attached. It must be
> >> +   * renamed.
> >> +   */
> >> +  if (quirk->quirk & MULTI_ATTACHED_QUIRK)
> >> +  sprintf(amba_devname, "%s%s", dev_name(>dev),
> >"DMA");
> >> +  else
> >> +  memcpy(amba_devname, dev_name(>dev),
> >> + strlen(dev_name(>dev)));
> >> +
> >> +  amba_dev = amba_device_alloc(amba_devname,
> >> resource->start,
> >> resource_size(resource));
> >>
> >
> >Isn't this basially an MFD in a rather odd fashion?

MFD yes, odd perhaps made out here!
> >
> >I would have though having a device which just splits the resources then 
> >creates 2
> >children would be a whole lot simpler?
> >
Yup!

> 
> It seems more complex, if I  trans an ACPI device to pdev, then attach 2 
> platform child nodes,
> and create an amba device refer to one of the childs. Too many trans. 

Sorry but I dont think that is right assumption, it will simper and PM would
become easy

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 4/9] dmaengine: pl330: add new items for pl330 private data

2015-12-11 Thread Vinod Koul 
On Thu, Dec 10, 2015 at 06:38:09AM +, Wang, Annie wrote:
> >
> >Why not DT or ACPI for this?
> >
> We choose to use private data, as pl330 already has  struct 
> dma_pl330_platdata. 
> Physically DMA share ACPI device with UART, however, BIOS believes DMA and 
> UART is one device.
> We can't  get irq share info from ACPI. And we don't use DT. 
> 
That should be then a MFD device

-- 
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/9] dma: pl330: use dma_addr_t for describing bus addresses

2013-06-17 Thread Vinod Koul 
On Tue, Jun 11, 2013 at 10:07:12AM +0530, Jassi Brar wrote:
 On 11 June 2013 00:04, Will Deacon will.dea...@arm.com wrote:
 
  The microcode bus address (pl330_dmac.mcode_bus) is currently a u32,
  which fails to compile when building on a system with 64-bit bus
  addresses.
 
  This patch uses dma_addr_t to represent the address instead.
 
  Acked-by: Jassi Brar jaswinder.si...@linaro.org
 
 
  Cc: Jassi Brar jaswinder.si...@linaro.org
  Cc: Vinod Koul vinod.k...@intel.com
  Signed-off-by: Will Deacon will.dea...@arm.com
Applied, thanks

--
~Vinod
  ---
   drivers/dma/pl330.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
  index 22e2a8f..f1bc593 100644
  --- a/drivers/dma/pl330.c
  +++ b/drivers/dma/pl330.c
  @@ -501,7 +501,7 @@ struct pl330_dmac {
  /* Maximum possible events/irqs */
  int events[32];
  /* BUS address of MicroCode buffer */
  -   u32 mcode_bus;
  +   dma_addr_t  mcode_bus;
  /* CPU address of MicroCode buffer */
  void*mcode_cpu;
  /* List of all Channel threads */
  --
  1.8.2.2
 
 
 
 
 -- 
 Linaro.org │ Open source software for ARM SoCs | Follow Linaro
 http://facebook.com/pages/Linaro/155974581091106  -
 http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

-- 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu