On Fri, Jul 27, 2018 at 6:20 PM, Rob Landley wrote:
> On 07/24/2018 03:21 PM, Christoph Hellwig wrote:
>> On Tue, Jul 24, 2018 at 02:01:42PM +0200, Christoph Hellwig wrote:
>>> Hi all,
>>>
>>> can you review these patches to switch sh to use the generic
>>> dma-noncoherent code? All the requireme
On Tue, Jul 24, 2018 at 12:16 AM, Robin Murphy wrote:
> Whilst the common firmware code invoked by dma_configure() initialises
> devices' DMA masks according to limitations described by the respective
> properties ("dma-ranges" for OF and _DMA/IORT for ACPI), the nature of
> the dma_set_mask() API
protected
section of the file.
Fixes: ea6166f4b83e ("iommu/amd: Split irq_lookup_table out of the
amd_iommu_devtable_lock")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drive
_by_node() might
theoretically return a NULL pointer.
Fixes: 5fd577c3eac3 ("iommu/rockchip: Use OF_IOMMU to attach devices
automatically")
Signed-off-by: Arnd Bergmann
---
This warning appears to only have been introduced in linux-next after
the merge window opened.
---
drivers/i
On Tue, Feb 6, 2018 at 2:05 PM, Robin Murphy wrote:
>
> It looks like we have only one real arch (score) without IOMEM, and two
> (s390 and tile) where it is possible to configure out, so it does seem like
> a reasonable feature to assume. Maybe we could have something like
> asm-generic/no-io.h t
On Tue, Feb 6, 2018 at 11:14 AM, Geert Uytterhoeven
wrote:
> Hi all,
>
> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
> symbol bad_dma_ops, thus causing a link failure if it is ever used.
>
> The intention of this is twofold:
> 1. To catch users of the DMA API on sy
;t include asm/x86_init.h in asm/setup.h")
Signed-off-by: Arnd Bergmann
---
The broken commit is in x86/timers, please add this one on top
---
drivers/iommu/dmar.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index e9304d6247e1..ed1dd13e03
init.h used to rely on it being
included indirectly, so I have to put an explicit include in there
now.
Signed-off-by: Arnd Bergmann
---
arch/x86/include/asm/setup.h| 1 -
arch/x86/kernel/platform-quirks.c | 1 +
arch/x86/platform/ce4100/ce4100.c | 1 +
arch/x86/platform/
On Fri, Oct 13, 2017 at 8:23 PM, Robin Murphy wrote:
> Arnd reports a build warning[1] thanks to me missing ipmmu-vmsa's second
> set of ops when converting io-pgtable-arm users to the new iommu_iotlb_*
> callbacks. Rather than just treat the symptom with a point fix, this
> seemed like a good exc
On Wed, Oct 11, 2017 at 4:16 PM, Robin Murphy wrote:
> On 11/10/17 14:59, Arnd Bergmann wrote:
>
> That said, I think the third option is now viable as well, namely to
> shuffle some lines and get rid of the almost-duplicated ops entirely.
> I'll have a quick go at that
LB sync")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/ipmmu-vmsa.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index af8140054273..bdd0d0d20925 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/d
rent_memory() logic
error")
Reported-by: Roy Pledge
Signed-off-by: Arnd Bergmann
---
Roy, can you test this new fix?
---
drivers/base/dma-coherent.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-
>> @@ -338,14 +346,18 @@ static struct reserved_mem
>> *dma_reserved_default_memory __initdata;
>> static int rmem_dma_device_init(struct reserved_mem *rmem, struct device
>> *dev)
>> {
>> struct dma_coherent_mem *mem = rmem->priv;
>> + int ret;
>> +
>> + if (!mem)
>> +
. On compilers
that don't show the warning today, this should have no impact since the
function gets inlined anyway.
Signed-off-by: Arnd Bergmann
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
to fix up the warning
and make the code look reasonable at the same time.
Fixes: 2436bdcda53f ("dma-coherent: remove the DMA_MEMORY_MAP and DMA_MEMORY_IO
flags")
Signed-off-by: Arnd Bergmann
---
drivers/base/dma-coherent.c | 38 +-
1 file changed,
ns lets the compiler
drop the functions silently instead.
Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/qcom_iommu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/q
dependency, moving warning text into
a comment.
Fixes: 1f59adb1766d ("iommu/exynos: Replace non-existing big-endian Kconfig
option")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/Kconfig| 1 +
drivers/iommu/exynos-iommu.c | 4
2 files changed, 1 insertion(+), 4 deletions(-)
On Wed, Jul 19, 2017 at 5:12 AM, Yong Zhi wrote:
> From: Tomasz Figa
>
> This patch adds support for the IPU3 DMA mapping API.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Yong Zhi
This needs some explanation on why you decided to go down the
route of adding your own dma_map_ops. It's not o
On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst wrote:
> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote:
>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky
>>
>> I originally had a check for SME here in a previous version of the
>> patch. Thomas Gleixn
On Thu, Jul 6, 2017 at 4:24 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig wrote:
>>> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
I suppose another option is to just make the IOMMU and DMA
On Thu, Jul 6, 2017 at 4:06 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>>
>>>> On the other hand, if it's
On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>> On the other hand, if it's strictly about base/dma-mapping, we might
>> not need it indeed. The driver could call iommu-dma helpers directly,
>> without the need to provide its own DMA ops
On Thu, Jul 6, 2017 at 3:31 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>>>
>>> Sorry, I intended to mean:
&
On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>>
>> I'd say that this is something tha
On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig wrote:
>> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>> In general I think moving dma
>> ops and iommu implementations into modules is a bad idea
>
> Could you elaborate on th
On Sat, Jun 24, 2017 at 9:35 AM, Christoph Hellwig wrote:
> I always assumed that our streaming mappings are relaxed order for
> TLP anyway. And at very least Documentation/DMA-attributes.txt seems
> to imply something different:
>
>
> DMA_ATTR_WEAK_ORDERING
> --
>
> DMA
On Tue, May 16, 2017 at 7:22 AM, Oza Pawandeep wrote:
> current device framework and OF framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure is specifically written to take c
erent'; did you mean 'debug_dma_free_coherent'?
[-Werror=implicit-function-declaration]
This adds an explicit #include to make it build again.
Signed-off-by: Arnd Bergmann
---
drivers/iommu/mtk_iommu_v1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/d
selects COMMON_CLK_MT2701_IMGSYS which has unmet direct
dependencies (COMMON_CLK && COMMON_CLK_MT2701)
warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_MMSYS which has unmet direct
dependencies (COMMON_CLK && COMMON_CLK_MT2701)
This removes the select statements.
Signed-off-by: Arnd Berg
the warning.
Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 8ee54d71c7eb..bb537d06d319 100644
---
On Tuesday, November 8, 2016 6:49:51 AM CET Y.B. Lu wrote:
> Hi Arnd,
>
>
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: Tuesday, November 08, 2016 5:20 AM
> > To: Y.B. Lu
> > Cc: linuxppc-...@lists.ozlabs.org;
On Monday, October 31, 2016 9:35:33 AM CET Y.B. Lu wrote:
> >
> > I don't see any of the contents of this header referenced by the soc
> > driver any more. I think you can just drop this patch.
> >
>
> [Lu Yangbo-B47093] This header file was included by guts.c.
> The guts driver used macro SVR_M
method in soc driver
> and apply it on esdhc driver to fix this bug.
>
Looks good overall. With patch 3 dropped (or an explanation why it's still
needed), everything
Acked-by: Arnd Bergmann
Arnd
___
iommu mailing list
iommu@lis
On Friday, October 28, 2016 2:50:14 PM CEST Yangbo Lu wrote:
> Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
> header file. This SVR numberspace is used on some ARM chips as well as
> PPC, and even to check for a PPC SVR multi-arch drivers would otherwise
> need to ifdef t
On Friday, October 28, 2016 2:50:17 PM CEST Yangbo Lu wrote:
> +
> +static int soc_device_match_one(struct device *dev, void *arg)
> +{
> + struct soc_device *soc_dev = container_of(dev, struct soc_device,
> dev);
> + const struct soc_device_attribute *match = arg;
> +
> + if (ma
On Friday, September 16, 2016 3:09:29 PM CEST Laurent Pinchart wrote:
> > I wasn't thinking quite that far, though that is also a theoretical
> > problem. However, the simple solution would be to have a bit in the DMA
> > specifier let the driver know whether translation is needed or not.
> >
> >
On Friday, September 16, 2016 12:48:23 PM CEST Laurent Pinchart wrote:
> On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> > On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> > > On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> > >>
e 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...
>
lly been done through a vendor specific API that can be called by a
> > driver, or by directly accessing some kind of version register that is
> > not part of the device itself but that belongs to a global register area
> > of the chip.
Please add "From: Arnd Bergmann "
On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> Hi Arnd,
>
> Could you reply when you see the email?
> If your method doesn’t resolve the problem, we still want to use our old
> patchset.
>
> This guts driver had been discussed about one year and blocked many
> workaround upstream.
On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > All users of this driver are PowerPC specific and the header file
> > has no business in the global include/linux/ hierarchy, so move
> > it back before a
On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > SDHCI_SPEC_200)
> > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
>
On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index ..2f30698f5bcf
> > --- /dev/null
>
On Monday, May 30, 2016 3:14:38 PM CEST Arnd Bergmann wrote:
> We keep running into cases where device drivers want to know the exact
> version of the SoC a they are currently running on. In the past, this
> has usually been done through a vendor specific API that can be called
> by
All users of this driver are PowerPC specific and the header file
has no business in the global include/linux/ hierarchy, so move
it back before anyone starts using it on ARM.
This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
Signed-off-by: Arnd Bergmann
---
This part of the series
esdhc" identifier but that have other host versions that
are correctly detected.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d354f1fc..1d4814fe4cb2 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/hos
this into a platform_driver registering a soc_device
rather than providing an ad-hoc interface for soc-id]
Signed-off-by: Yangbo Lu
Signed-off-by: Arnd Bergmann
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0d9b2c..7106463f118e 100644
--- a/drivers/soc/Kconfig
+++ b/drivers
strings.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 246acdafedb6..fc7613cc7fd5 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
On Thursday, May 26, 2016 9:44:10 AM CEST Ulf Hansson wrote:
> On 26 May 2016 at 06:05, Yangbo Lu wrote:
> > Hi Uffe,
> >
> > Could we merge this patchset? ...
> > It has been a long time to wait for Arnd's response...
> >
> > Thanks a lot.
> >
> >
>
> As we are still in the merge window I won't
in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.
Signed-off-by: Arnd Bergmann
Cc: Andrzej Hajda
Cc: Andrew Morton
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
---
drivers/acpi/acpi_dbg.c
On Wednesday, May 25, 2016 6:49:18 PM CEST Sricharan wrote:
> Hi Arnd,
>
> >> Ok, so i was doing this from the idea that, other iommu drivers
> >> where polling on a status bit in their sync call to ensure completion
> >> of pending TLB invalidations. But in this case, there is no status bit.
> >
On Wednesday, May 25, 2016 4:15:31 PM CEST Sricharan wrote:
> >
> >Any operation that could trigger a DMA from a device is required
> >to have a barrier preceding it (usually wmb() one implied by writel()),
> >so this is clearly not about a driver that installs a DMA mapping
> >before starting a DM
On Monday, May 23, 2016 11:35:04 AM CEST Sricharan wrote:
> Hi Arnd,
>
> >> @@ -124,6 +124,9 @@ static void msm_iommu_reset(void __iomem *base, int
> >> ncb)
> >>SET_TLBLKCR(base, ctx, 0);
> >>SET_CONTEXTIDR(base, ctx, 0);
> >>}
> >> +
> >> + /* Ensure completion of r
On Friday 20 May 2016 13:44:10 Arnd Bergmann wrote:
> > #define GET_CTX_REG(reg, base, ctx) \
> > (readl((base) + (reg) + ((ctx) << CTX_SHIFT)))
> >
> > -#define SET_GLOBAL_REG(reg, base, val) writel((val), ((base) +
> > (
On Friday 20 May 2016 16:24:53 Sricharan R wrote:
> While using the generic pagetable ops the tlb maintenance
> operation gets completed in the sync callback. So use writel_relaxed
> for all register access and add a mb() at appropriate places.
>
> Signed-off-by: Sricharan R
> ---
> drivers/iomm
On Wednesday 18 May 2016 17:37:40 Sricharan wrote:
> >
> >These comments are completely useless. What is the specific race
> >that you are protecting against, and why are the implicit barriers
> >not sufficient here? Please find a better way to document what
> >is going on.
> >
>
> The reason for
On Monday 16 May 2016 12:19:00 Sricharan R wrote:
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index f7b4c11..1240a5a 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -124,6 +124,7 @@ static void msm_iommu_reset(void __iomem *base, int ncb)
>
On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: Thursday, May 05, 2016 4:32 PM
> > To: linuxppc-...@lists.ozlabs.org
> > Cc: Yangbo Lu; linux-...@vger.kernel.org; devicet...@vger
On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
>
> + fsl_guts_init();
> + svr = fsl_guts_get_svr();
> + if (svr) {
> + esdhc->soc_ver = SVR_SOC_VER(svr);
> + esdhc->soc_rev = SVR_REV(svr);
> + } else {
> + dev_err(&pdev->dev, "Fa
bit accessors as appropriate.
>
> CC: Arnd Bergmann
> CC: Christoph Hellwig
> CC: Darren Hart
> CC: Hitoshi Mitake
> Signed-off-by: Robin Murphy
> ---
>
Acked-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foun
On Monday 25 April 2016 16:28:01 Robin Murphy wrote:
> >>>
> >>> We _could_ - indeed I started doing that, but then decided that the
> >>> obfuscation of horrible macro-templated functions wasn't worth saving a
> >>> couple of hundred bytes in some code that isn't exactly difficult to
> >>> maintai
On Monday 25 April 2016 14:32:42 Will Deacon wrote:
> > >>
> > >>+static inline __u64 hi_lo_readq_relaxed(const volatile void __iomem
> > >>*addr)
> > >>+{
> > >>+ const volatile u32 __iomem *p = addr;
> > >>+ u32 low, high;
> > >>+
> > >>+ high = readl_relaxed(p + 1);
> > >>+ low = readl_
On Thursday 17 March 2016 12:01:01 Rob Herring wrote:
> On Mon, Mar 14, 2016 at 05:45:43PM +, Scott Wood wrote:
> > >> This makes the driver non-portable. Better identify the specific
> > >> workarounds based on the compatible string for this device, or add a
> > >> boolean DT property for the
On Thursday 17 March 2016 12:06:40 Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> > b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> > similarity index 91%
> > rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> > rename to Docum
On Wednesday 09 March 2016 18:08:51 Yangbo Lu wrote:
> @@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev,
> struct sdhci_host *host)
> struct sdhci_pltfm_host *pltfm_host;
> struct sdhci_esdhc *esdhc;
> u16 host_ver;
> + u32 svr;
>
>
On Wednesday 02 March 2016 11:48:43 Matthias Brugger wrote:
>
> On 26/02/16 12:06, Joerg Roedel wrote:
> > Hi Philipp,
> >
> > On Fri, Feb 26, 2016 at 09:55:55AM +0100, Philipp Zabel wrote:
> >> Do you have a stable branch that I could base the mediatek-drm patches
> >> on and that I may include i
On Monday 29 February 2016 13:42:57 Marek Szyprowski wrote:
> Drivers should use generic readl/writel calls to access HW registers, so
> replace all __raw_readl/writel with generic version.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Marek Szyprowski
>
Acked
On Monday 29 February 2016 11:22:24 Robin Murphy wrote:
> >>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> >>> index b325954cf8f8..ea0998921702 100644
> >>> --- a/drivers/iommu/Kconfig
> >>> +++ b/drivers/iommu/Kconfig
> >>> @@ -341,6 +341,7 @@ config MTK_IOMMU
> >>> bool "MTK I
On Monday 29 February 2016 11:13:39 Robin Murphy wrote:
> IOMMU_DMA does indeed depend on scatterlists having a DMA length, but
> the NEED_SG_DMA_LENGTH symbol should be selected, not depended upon.
>
> Reported-by: Arnd Bergmann
> Signed-off-by: Robin Murphy
>
Acked
On Monday 29 February 2016 10:37:40 Robin Murphy wrote:
> Hi Arnd,
>
> On 29/02/16 09:19, Arnd Bergmann wrote:
> > The newly added Mediatek IOMMU driver uses the IOMMU_DMA infrastructure,
> > but unlike other such drivers, it does not select 'ARM_DMA_USE_IOMMU
On Monday 29 February 2016 10:33:59 Marek Szyprowski wrote:
> > ---
> > I also see that some incorrect __raw_writel() calls have crept in
> > around the same time, which breaks running big-endian kernels when
> > this driver is loaded.
> >
> > Please fix and that that as well.
>
> Okay, so in the
nction]
Marking the functions as __maybe_unused gits rid of the two functions
and lets the compiler silently drop the object code, while still
doing syntax checking on them for build-time verification.
Signed-off-by: Arnd Bergmann
Fixes: 0df4fabe208d ("iommu/mediatek: Add mt8173 IOMMU dr
driver is enabled. Are there any cases where
we would enable an IOMMU but not use it?
Signed-off-by: Arnd Bergmann
Fixes: 0df4fabe208d ("iommu/mediatek: Add mt8173 IOMMU driver")
---
drivers/iommu/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/Kconfig b/dri
On Monday 29 February 2016 10:11:58 Arnd Bergmann wrote:
> This adds the same select that the other drivers have. On a related
> note, I wonder if we should just always select ARM_DMA_USE_IOMMU
> whenever any IOMMU driver is enabled. Are there any cases where
> we would enable an IOMMU
driver is enabled. Are there any cases where
we would enable an IOMMU but not use it?
Signed-off-by: Arnd Bergmann
Fixes: 0df4fabe208d ("iommu/mediatek: Add mt8173 IOMMU driver")
---
drivers/iommu/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/Kconfig b/dri
to uintptr_t instead.
Signed-off-by: Arnd Bergmann
Fixes: 740a01eee9ad ("iommu/exynos: Add support for v5 SYSMMU")
---
I also see that some incorrect __raw_writel() calls have crept in
around the same time, which breaks running big-endian kernels when
this driver is loaded.
Please fi
On Thursday 25 February 2016 13:26:17 Marek Szyprowski wrote:
> >> +}
> >> +
> >> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page
> >> **ret_page,
> >> + gfp_t flags);
> >> +extern bool arch_in_atomic_pool(void *start, size_t size);
> >> +exte
On Friday 19 February 2016 09:22:44 Marek Szyprowski wrote:
> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
> side-effect of this change is a switch from bitmap-based IO address space
> management to
On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki
> > > wrote:
> &
On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> On 25 September 2015 at 15:19, Rafael J. Wysocki wrote:
> > So if you allow something like debugfs to update your structure, how
> > do you make sure there is the proper locking?
>
> Not really sure at all.. Isn't there some debugfs loc
On Tuesday 15 September 2015 07:34:38 Viresh Kumar wrote:
> On 14-09-15, 09:03, Greg KH wrote:
> > What ever ones you think it is relevant for :)
>
> "Relevant" is a relevant term :)
>
> So, the patch which defined the type bool as _Bool was added in v2.6.19 :)
>
> 6e2182874324 ("[PATCH] Generic
On Monday 14 September 2015 09:21:54 Viresh Kumar wrote:
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..bea8e425a8de 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec,
> uns
this function)
np = of_find_matching_node(NULL, rk_iommu_dt_ids);
This removes the #ifdef and the corresponding of_match_ptr wrapper
to make it build both with CONFIG_OF enabled or disabled.
Signed-off-by: Arnd Bergmann
Fixes: 425061b0f5074 ("iommu/rockchip: Play nice in multi-platform build
On Tuesday 10 March 2015 14:27:04 Yingjoe Chen wrote:
> On Mon, 2015-03-09 at 22:56 +0100, Arnd Bergmann wrote:
> > On Monday 09 March 2015 11:26:52 Yingjoe Chen wrote:
> > > On Fri, 2015-03-06 at 18:48 +0800, yong...@mediatek.com wrote:
> > > > From: Yong Wu
>
On Monday 09 March 2015 11:26:52 Yingjoe Chen wrote:
> On Fri, 2015-03-06 at 18:48 +0800, yong...@mediatek.com wrote:
> > From: Yong Wu
> >
> > This patch add SMI(Smart Multimedia Interface) driver. This driver is
> > responsible to enable/disable iommu and control the clocks of each
> > loca
On Monday 09 March 2015 18:59:37 Paul Bolle wrote:
> Hi Yong,
>
> Yong Wu schreef op ma 09-03-2015 om 19:57 [+0800]:
> > On Fri, 2015-03-06 at 12:30 +0100, Paul Bolle wrote:
> > > On Fri, 2015-03-06 at 18:48 +0800, yong...@mediatek.com wrote:
> > > > --- a/drivers/soc/mediatek/Kconfig
> > > > +++
On Thursday 05 March 2015 18:56:36 Robin Murphy wrote:
> @@ -1630,6 +1630,13 @@ static int arm_smmu_device_cfg_probe(struct
> arm_smmu_device *smmu)
> size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
> smmu->pa_size = size;
>
> + /*
> +* What t
On Wednesday 25 February 2015 11:03:02 Murali Karicheri wrote:
>
> > (I don't know exactly how these patches all fit together, so that's
> > probably not accurate, but that's the *sort* of thing I'd like to include.)
> >
> > If that actually *is* what's going on, I have to wonder why this isn't
>
-bit.
Signed-off-by: Arnd Bergmann
Fixes: 859a732e4f713 ("iommu/arm-smmu: add support for iova_to_phys through
ATS1PR")
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 1d6d43bb3395..fc13dd56953e 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-sm
clared identifier is
reported only once for each function it appears in
../arch/arm/mm/dma-mapping.c: In function '__atomic_get_pages':
../arch/arm/mm/dma-mapping.c:1358:27: error: 'atomic_pool' undeclared (first
use in this function)
struct dma_pool *pool = &atomic_pool
On Friday 23 January 2015 17:55:25 Laurent Pinchart wrote:
>
> On Friday 23 January 2015 16:27:24 Arnd Bergmann wrote:
> > On Friday 23 January 2015 16:21:49 Laurent Pinchart wrote:
> > > +/**
> > > + * arm_iommu_detach_device
> > >
On Friday 23 January 2015 16:21:49 Laurent Pinchart wrote:
> +/**
> + * arm_iommu_detach_device
> + * @dev: valid struct device pointer
> + *
> + * Detaches the provided device from a previously attached map.
> + * This voids the dma operations (dma_map_ops pointer)
> + */
> +void arm_iommu_detach_
On Monday 19 January 2015 17:21:14 Thierry Reding wrote:
> On Mon, Jan 19, 2015 at 04:52:41PM +0100, Arnd Bergmann wrote:
> > On Monday 19 January 2015 13:36:24 Thierry Reding wrote:
> > > On Fri, Jan 16, 2015 at 01:18:21AM +0200, Laurent Pinchart wrote:
> > > > On
On Sunday 18 January 2015 13:18:51 Laurent Pinchart wrote:
> On Sunday 18 January 2015 15:54:34 Alexandre Courbot wrote:
> > On 01/16/2015 08:18 AM, Laurent Pinchart wrote:
> > > On Thursday 15 January 2015 11:12:17 Will Deacon wrote:
> > >> On Thu, Jan 15, 2015 at 08:28:44AM +, Thierry Reding
On Monday 19 January 2015 13:36:24 Thierry Reding wrote:
> On Fri, Jan 16, 2015 at 01:18:21AM +0200, Laurent Pinchart wrote:
> > On Thursday 15 January 2015 11:12:17 Will Deacon wrote:
> > > On Thu, Jan 15, 2015 at 08:28:44AM +, Thierry Reding wrote:
> > > > On Wed, Jan 14, 2015 at 10:46:10AM +
r look at this patch please? You had some
> comments in the past.
No further objections from my side. I don't think it's really needed,
but it seems harmless, so
Acked-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Friday 09 January 2015 16:56:03 Robin Murphy wrote:
>
> This one's a bit tricky to find a home for - I think technically it's
> probably an IOMMU patch, but then the long-underlying problem doesn't
> seem to have blown up anything until arm64, and my motivation is to
> make bits of Juno work,
On Thursday 08 January 2015 18:44:31 Murali Karicheri wrote:
> The grep of dma-ranges for arch/arm shows the size used is mask + 1 as
>
> ./boot/dts/keystone.dtsi: dma-ranges = <0x8000 0x8
> 0x
> 0x8000>;
> ./boot/dts/keystone.dtsi: dma-ranges;
On Thursday 08 January 2015 09:56:39 Arnd Bergmann wrote:
> There is another interesting case, which is a USB host controller or
> something similar behind a PCI bus. These are quite common and also
> need to be handled in some form. Let's do just PCI first for now, but
> be awa
On Thursday 08 January 2015 14:52:13 Murali Karicheri wrote:
>
> Could you add this as as a follow up patch as I don't have a platformm
> that support IOMMU and as such my understanding of the IOMMU is limited?
>
> I can help test the change to make sure it has no side effect on
> Keystone that
101 - 200 of 345 matches
Mail list logo
