Hi Steve,
On 6/4/19 5:01 PM, Steven Rostedt wrote:
On Mon, 3 Jun 2019 09:16:18 +0800
Lu Baolu wrote:
+TRACE_EVENT(bounce_unmap_single,
+ TP_PROTO(struct device *dev, dma_addr_t dev_addr, size_t size),
+
+ TP_ARGS(dev, dev_addr, size),
+
+ TP_STRUCT__entry(
+
On Mon, Jun 3, 2019 at 7:48 PM Rob Clark wrote:
>
> On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> >
> > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> > >
> > > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> > > >
> > > > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
> > > >
On 31.05.19 13:38, Juergen Gross wrote:
On 30/05/2019 14:46, Boris Ostrovsky wrote:
On 5/30/19 5:04 AM, Christoph Hellwig wrote:
Please don't add your private flag to page-flags.h. The whole point of
the private flag is that you can use it in any way you want withou
touching the common code.
> From: Jacob Pan
> Sent: Tuesday, June 4, 2019 6:09 AM
>
> On Mon, 3 Jun 2019 15:57:47 +0100
> Jean-Philippe Brucker wrote:
>
> > +/**
> > + * struct iommu_fault_page_request - Page Request data
> > + * @flags: encodes whether the corresponding fields are valid and
> > whether this
> > + *
This patch series is based on iommu.git / next branch.
Since SDHI host internal DMAC of the R-Car Gen3 cannot handle two or
more segments, the performance rate (especially, eMMC HS400 reading)
is not good. However, if IOMMU is enabled on the DMAC, since IOMMU will
map multiple scatter gather
On 03/06/2019 22:59, Jacob Pan wrote:
> On Mon, 3 Jun 2019 15:57:45 +0100
> Jean-Philippe Brucker wrote:
>
>> Allow device drivers and VFIO to get notified on IOMMU translation
>> fault, and handle recoverable faults (PCI PRI). Several series require
>> this API (Intel VT-d and Arm SMMUv3
[+Joerg on To:]
On Mon, Jun 03, 2019 at 02:15:37PM +0200, Marc Gonzalez wrote:
> From: Robin Murphy
>
> Apparently, some Qualcomm arm64 platforms which appear to expose their
> SMMU global register space are still, in fact, using a hypervisor to
> mediate it by trapping and emulating register
On 05/06/2019 12:11, Yoshihiro Shimoda wrote:
This patch adds a new capable IOMMU_CAP_MERGING to check whether
the IOVA would be contiguous strictly if a device requires and
the IOMMU driver has the capable.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/dma-iommu.c | 26
This patch adds the .capable into iommu_ops that can merge scatter
gather segments.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 408ad0b..81170b8
This patch adds a definition for default max_segs to be used by other
driver (renesas_sdhi) in the future.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Wolfram Sang
---
drivers/mmc/host/tmio_mmc.h | 1 +
drivers/mmc/host/tmio_mmc_core.c | 2 +-
2 files changed, 2 insertions(+), 1
This patch adds a new capable IOMMU_CAP_MERGING to check whether
the IOVA would be contiguous strictly if a device requires and
the IOMMU driver has the capable.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/dma-iommu.c | 26 --
include/linux/iommu.h | 1 +
2
This patch adds a condition to avoid a memory size limitation of
swiotlb if the driver runs on IOMMU.
Tested-by: Takeshi Saito
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Simon Horman
Reviewed-by: Wolfram Sang
---
drivers/mmc/host/tmio_mmc_core.c | 5 +++--
1 file changed, 3 insertions(+),
If the IOMMU driver has a capable for merging segments to
a segment strictly, this can expose the host->mmc->max_segs with
multiple segments to a block layer by using blk_queue_max_segments()
that mmc_setup_queue() calls. Notes that an sdio card may be
possible to use multiple segments with non
iommu_dma_map_sg() will use the unmap function in the future. To
avoid a forward declaration, this patch move the function place.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/dma-iommu.c | 48 +++
1 file changed, 24 insertions(+), 24
This patch ports the headers in alphabetic order to ease
the maintenance for this part.
Signed-off-by: Yoshihiro Shimoda
---
drivers/mmc/host/renesas_sdhi_core.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_core.c
This API can set a flag whether a device requires iova contiguous
strictly.
Signed-off-by: Yoshihiro Shimoda
---
include/linux/device.h | 1 +
include/linux/dma-mapping.h | 16
2 files changed, 17 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
On 05/06/2019 09:51, Tian, Kevin wrote:
>> From: Jacob Pan
>> Sent: Tuesday, June 4, 2019 6:09 AM
>>
>> On Mon, 3 Jun 2019 15:57:47 +0100
>> Jean-Philippe Brucker wrote:
>>
>>> +/**
>>> + * struct iommu_fault_page_request - Page Request data
>>> + * @flags: encodes whether the corresponding
On Wed, Jun 05, 2019 at 01:21:59PM +0100, Robin Murphy wrote:
> And if the problem is really that you're not getting merging because of
> exposing the wrong parameters to the DMA API and/or the block layer, or
> that you just can't quite express your requirement to the block layer in
> the
On Tue, Jun 4, 2019 at 11:58 PM Tomasz Figa wrote:
>
> But first of all, I remember Marek already submitted some patches long
> ago that extended struct driver with some flag that means that the
> driver doesn't want the IOMMU to be attached before probe. Why
> wouldn't that work? Sounds like a
On Wed, Jun 05, 2019 at 04:23:12PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Some subsystems, such as pinctrl, allow continuing to defer probe
> indefinitely. This is useful for devices that depend on resources
> provided by devices that are only probed after the init stage.
>
>
On Wed, 5 Jun 2019 08:51:45 +
"Tian, Kevin" wrote:
> > From: Jacob Pan
> > Sent: Tuesday, June 4, 2019 6:09 AM
> >
> > On Mon, 3 Jun 2019 15:57:47 +0100
> > Jean-Philippe Brucker wrote:
> >
> > > +/**
> > > + * struct iommu_fault_page_request - Page Request data
> > > + * @flags:
On 06/05/2019 02:11 PM, Yoshihiro Shimoda wrote:
> This patch adds a new capable IOMMU_CAP_MERGING to check whether
> the IOVA would be contiguous strictly if a device requires and
> the IOMMU driver has the capable.
s/has/is/? Or capable what?
> Signed-off-by: Yoshihiro Shimoda
> ---
>
With the SMRs inherited from the bootloader the first SMR might actually
be valid and in use. As such probing the SMR mask using the first SMR
might break a stream in use. Search for an unused stream and use this to
probe the SMR mask.
Signed-off-by: Bjorn Andersson
---
drivers/iommu/arm-smmu.c
Boot splash screen or EFI framebuffer requires the display hardware to
operate while the Linux iommu driver probes. Therefore, we cannot simply
wipe out the SMR register settings programmed by the bootloader.
Detect which SMR registers are in use during probe, and which context
banks they are
Qualcomm devices typically boot with some sort of splash screen on the display,
or for some devices (i.e. recent Qualcomm laptops) an EFI framebuffer. For this
the bootloader allocates a static framebuffer, configures the display hardware
to output this on the display, sets up the SMMU for the
On Wed, 5 Jun 2019 12:24:09 +0100
Jean-Philippe Brucker wrote:
> On 05/06/2019 09:51, Tian, Kevin wrote:
> >> From: Jacob Pan
> >> Sent: Tuesday, June 4, 2019 6:09 AM
> >>
> >> On Mon, 3 Jun 2019 15:57:47 +0100
> >> Jean-Philippe Brucker wrote:
> >>
> >>> +/**
> >>> + * struct
On Tue, 4 Jun 2019 18:11:08 +0200
Auger Eric wrote:
> Hi Alex,
>
> On 6/4/19 12:31 AM, Alex Williamson wrote:
> > On Sun, 26 May 2019 18:10:01 +0200
> > Eric Auger wrote:
> >
> >> This patch registers a fault handler which records faults in
> >> a circular buffer and then signals an
Hi Robin,
Thank you for your comments!
> From: Robin Murphy, Sent: Wednesday, June 5, 2019 9:22 PM
> > @@ -902,8 +914,18 @@ static int iommu_dma_map_sg(struct device *dev, struct
> > scatterlist *sg,
> > if (iommu_map_sg(domain, iova, sg, nents, prot) < iova_len)
> > goto
From: Thierry Reding
Some subsystems, such as pinctrl, allow continuing to defer probe
indefinitely. This is useful for devices that depend on resources
provided by devices that are only probed after the init stage.
One example of this can be seen on Tegra, where the DPAUX hardware
contains
Hi Rob,
On 2019-06-05 14:57, Rob Clark wrote:
> On Tue, Jun 4, 2019 at 11:58 PM Tomasz Figa wrote:
>> But first of all, I remember Marek already submitted some patches long
>> ago that extended struct driver with some flag that means that the
>> driver doesn't want the IOMMU to be attached
On Wed, Jun 5, 2019 at 6:18 AM Marek Szyprowski
wrote:
>
> Hi Rob,
>
> On 2019-06-05 14:57, Rob Clark wrote:
> > On Tue, Jun 4, 2019 at 11:58 PM Tomasz Figa wrote:
> >> But first of all, I remember Marek already submitted some patches long
> >> ago that extended struct driver with some flag that
31 matches
Mail list logo
