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-f
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
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.or
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
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
___
i
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
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
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
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
t; 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
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
>
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 o
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 th
li
> 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
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
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
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.or
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 i
gt; 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
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
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
_
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
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-foundati
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
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
___
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);
> -
.c | 2 +-
> drivers/dma/qcom/hidma_mgmt.c | 2 +-
This one:
Acked-by: Vinod Koul
--
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
___
iommu mailing list
iommu@lists
t 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:
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]
> en
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
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 th
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
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 th
ext for the series!
>
> Cc: Dan Williams
> Cc: Vinod Koul
> Reviewed-by: Robin Murphy
> Tested-by: Robin Murphy
> Signed-off-by: Mitchel Humpherys
> ---
>
> Notes:
> v3..v4
>
> - Reworked against the new dma attrs format.
>
> drivers/
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 hav
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 registe
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 Do
On Tue, Feb 16, 2016 at 09:39:42PM +0100, Niklas Söderlund wrote:
> Enable slave transfers to devices behind IPMMU:s by mapping the slave
IPMMU:s ?
> addresses using the dma-mapping API.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
> ---
> drivers/dma/sh/rcar-dmac.c | 5
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(&adev->dev),
> >"DMA"
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
On Fri, Dec 04, 2015 at 11:24:21AM +0800, Wang Hongcheng wrote:
> has_no_cap_mask means this device has no preset cap mask.
> mcbuf_sz means bytes to allocate for MC buffer.
MC ?
> flags is for irq sharing, default is non-shared, in AMD
> Carrizo, pl330 shares IRQ with its corresponding UART devi
> >
> > This patch uses dma_addr_t to represent the address instead.
> >
> > Acked-by: Jassi Brar
>
>
> > Cc: Jassi Brar
> > Cc: Vinod Koul
> > Signed-off-by: Will Deacon
Applied, thanks
--
~Vinod
> > ---
> > drivers/dma/pl330.c | 2 +-
>
43 matches
Mail list logo
