Hi Robin,
On Wed, Sep 26, 2018 at 9:29 PM Robin Murphy wrote:
>
> On 30/08/18 15:45, Vivek Gautam wrote:
> > qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> > clock and power requirements.
> > On msm8996, multiple cores, viz. mdss, video, etc. use this
> > smmu. On sdm845, this smmu
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Jean-Philippe Brucker
> Sent: Wednesday, September 26, 2018 9:50 PM
> Subject: Re: [PATCH v3 03/10] iommu/sva: Manage process address spaces
>
> On 26/09/2018 13:45, Joerg Roedel wrot
在 2018年09月25日 20:04, Joerg Roedel 写道:
> On Fri, Sep 07, 2018 at 04:18:04PM +0800, Lianbo Jiang wrote:
>> In kdump kernel, it will copy the device table of IOMMU from the old device
>> table, which is encrypted when SME is enabled in the first kernel. So we
>> have to remap the old device table with
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> This save some duplication for ia64, and makes the interface more
> general. In the long run we want each dma_map_ops instance to fill this
> out, but this will take a little more prep work.
>
> Signed-off-by: Christoph Hellwig
(For
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> This way an architecture with less than 4G of RAM can support dma_mask
> smaller than 32-bit without a ZONE_DMA. Apparently that is a common
> case on powerpc.
Anything that uses a b43 wifi adapter which has a 31-bit limitation
actuall
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> +static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
> + u64 *phys_mask)
> +{
> + if (force_dma_unencrypted())
> + *phys_mask = __dma_to_phys(dev, dma_mask);
> + else
> +
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> This is somewhat modelled after the powerpc version, and differs from
> the legacy fallback in use fls64 instead of pointlessly splitting up the
> address into low and high dwords and in that it takes (__)phys_to_dma
> into account.
Thi
On Wed, 26 Sep 2018 14:45:27 +0200
Joerg Roedel wrote:
> On Wed, Sep 26, 2018 at 11:20:34AM +0100, Jean-Philippe Brucker wrote:
> > Yes, at the moment it's difficult to guess what device drivers will
> > want, but I can imagine some driver offering SVA to userspace, while
> > keeping a few PASIDs
On Thu, 20 Sep 2018 18:00:39 +0100
Jean-Philippe Brucker wrote:
> +
> +static int io_mm_attach(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, void *drvdata)
> +{
> + int ret;
> + bool attach_domain = true;
> + int pasid = io_mm->pasid;
‐‐‐ Original Message ‐‐‐
On Wednesday, September 26, 2018 9:59 PM, Greg Kroah-Hartman
wrote:
> On Mon, Sep 24, 2018 at 11:33:39AM +0200, Sedat Dilek wrote:
>
> > Hi Greg,
> > thanks and congrats for this release.
> > Me and several other people have an issue with "intel_iommu=on" (see
>
On Mon, Sep 24, 2018 at 11:33:39AM +0200, Sedat Dilek wrote:
> Hi Greg,
>
> thanks and congrats for this release.
>
> Me and several other people have an issue with "intel_iommu=on" (see
> [1]) and a patch is pending in [2].
> Unfortunately, it is not in linux-iommu Git.
> Hope this will soon hap
On Tue, 2018-09-25 at 13:29 +0200, Joerg Roedel wrote:
> On Thu, Aug 30, 2018 at 07:28:32PM -0300, Ezequiel Garcia wrote:
> > Printing verbosely via WARN macros and friends in interrupt handlers
> > is strongly discouraged. Drop them and use proper ratelimited
> > prints.
> >
> > Signed-off-by: Ez
On Mon, 24 Sep 2018 13:07:47 +0100
Jean-Philippe Brucker wrote:
> On 23/09/2018 04:05, Lu Baolu wrote:
> > Hi,
> >
> > On 09/21/2018 01:00 AM, Jean-Philippe Brucker wrote:
> >> Add bind() and unbind() operations to the IOMMU API. Bind()
> >> returns a PASID that drivers can program in hardware
On 9/26/2018 1:20 PM, Sinan Kaya wrote:
This patch actually broke the integrated endpoints like you were mentioning.
It was fixed by a follow up patch from nvidia guys.
https://github.com/torvalds/linux/commit/9d27e39d309c93025ae6aa97236af15bef2a5f1f#diff-a7f0acd715e991df5dfb450d2b9abebc
Tu
On 9/26/2018 12:22 PM, Raj, Ashok wrote:
pcie_capability_read_dword(dev, PCI_EXP_DEVCAP2, &cap);
+ if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
+ return;
Forgot to notice this.. I'm not sure if the same enforcement is
required for devices that are RCIEP. The spec isn't clear about ca
Hi Sinan
+ IOMMU list.
On Sat, Jun 30, 2018 at 11:24:24AM -0400, Sinan Kaya wrote:
> A PCIe endpoint carries the process address space identifier (PASID) in
> the TLP prefix as part of the memory read/write transaction. The address
> information in the TLP is relevant only for a given PASID conte
On 30/08/18 15:45, Vivek Gautam wrote:
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements.
On msm8996, multiple cores, viz. mdss, video, etc. use this
smmu. On sdm845, this smmu is used with gpu.
Add bindings for the same.
Signed-off-by: Vivek Gautam
Review
On 30/08/18 15:45, Vivek Gautam wrote:
Add bindings doc for Qcom's smmu-v2 implementation.
Reviewed-by: Robin Murphy
Signed-off-by: Vivek Gautam
Reviewed-by: Tomasz Figa
Tested-by: Srinivas Kandagatla
---
.../devicetree/bindings/iommu/arm,smmu.txt | 39 ++
1
On 30/08/18 15:45, Vivek Gautam wrote:
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smm
On 30/08/18 15:45, Vivek Gautam wrote:
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Global locks
On 30/08/18 15:45, Vivek Gautam wrote:
From: Sricharan R
The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using pm_runt
On 26/09/2018 13:45, Joerg Roedel wrote:
> On Wed, Sep 26, 2018 at 11:20:34AM +0100, Jean-Philippe Brucker wrote:
>> Yes, at the moment it's difficult to guess what device drivers will
>> want, but I can imagine some driver offering SVA to userspace, while
>> keeping a few PASIDs for themselves to
On 21/09/18 18:39, Stephen Boyd wrote:
Quoting Robin Murphy (2018-09-21 04:09:50)
Hi Stephen,
On 20/09/18 23:35, Stephen Boyd wrote:
I recently debugged a DMA mapping oops where a driver was trying to map
a buffer returned from request_firmware() with dma_map_single(). Memory
returned from req
On Tue, Sep 25, 2018 at 03:46:42PM -0700, Jacob Pan wrote:
> On Tue, 25 Sep 2018 15:16:47 +0200
> Joerg Roedel wrote:
>
> > On Sun, Sep 23, 2018 at 10:39:25AM +0800, Lu Baolu wrote:
> > > > +int iommu_sva_init_device(struct device *dev, unsigned long
> > > > features,
> > > > +
On Wed, Sep 26, 2018 at 11:20:34AM +0100, Jean-Philippe Brucker wrote:
> Yes, at the moment it's difficult to guess what device drivers will
> want, but I can imagine some driver offering SVA to userspace, while
> keeping a few PASIDs for themselves to map kernel memory. Or create mdev
> devices fo
On Wed, Sep 26, 2018 at 11:36:49AM +0200, Joerg Roedel wrote:
> Hi Greg,
>
> The following changes since commit 6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84:
>
> Linux 4.19-rc5 (2018-09-23 19:15:18 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/
On 25/09/18 21:16, Christoph Hellwig wrote:
Looking at the code I think this commit is simply broken for
architectures not using arch_setup_dma_ops, but instead setting up
the dma ops through arch specific magic.
I'll revert the patch.
Ugh, sorry about missing that too. Ack to a revert - think
On 26/09/2018 00:33, Lu Baolu wrote:
> Hi Joerg,
>
> On 09/25/2018 09:26 PM, Joerg Roedel wrote:
>> On Tue, Sep 25, 2018 at 11:15:40AM +0800, Lu Baolu wrote:
>>> This might be problematic for vt-d (and other possible arch's which use
>>> PASID other than SVA). When vt-d iommu works in scalable mod
Hi Jacob,
On 9/21/18 7:05 PM, Jacob Pan wrote:
> On Fri, 21 Sep 2018 12:07:09 +0200
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 5/11/18 10:54 PM, Jacob Pan wrote:
>>> Device faults detected by IOMMU can be reported outside IOMMU
>>> subsystem for further processing. This patch intends to provide
On 25/09/2018 23:46, Jacob Pan wrote:
> On Tue, 25 Sep 2018 15:16:47 +0200
> Joerg Roedel wrote:
>
>> On Sun, Sep 23, 2018 at 10:39:25AM +0800, Lu Baolu wrote:
>> > > +int iommu_sva_init_device(struct device *dev, unsigned long
>> > > features,
>> > > + unsigned int min_pasid, unsi
On 25/09/2018 23:17, Jacob Pan wrote:
> On Tue, 25 Sep 2018 15:58:41 +0100
> Jean-Philippe Brucker wrote:
>
>> Hi Jacob,
>>
>> Just two minor things below, that I noticed while using fault handlers
>> for SVA. From my perspective the series is fine otherwise
>>
>> On 11/05/2018 21:54, Jacob Pan
Hi Greg,
The following changes since commit 6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84:
Linux 4.19-rc5 (2018-09-23 19:15:18 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v4.19-rc5
for you to fetch changes up to 5
Hi Joerg
> > Joerg
> >
> > 2 weeks past. resend patch
>
> I applied that patch just yesterday, didn't you get the notice about
> that?
Thanks, nice to know
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/ma
On Wed, Sep 26, 2018 at 01:33:27AM +, Kuninori Morimoto wrote:
> Joerg
>
> 2 weeks past. resend patch
I applied that patch just yesterday, didn't you get the notice about
that?
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-founda
On Tue, Sep 25, 2018 at 03:41:34PM +, Nath, Arindam wrote:
> It does fix an issue where eMMC controller is an ACPI HID device and
> it fails to work with IOMMU enabled.
>
> Since for the ACPI HID, there is no actual pci_dev backing it, there
> is a NULL pointer de-referencing inside pci_for_ea
35 matches
Mail list logo
