On 2019/5/30 20:20, John Garry wrote:
> On 30/05/2019 04:48, Zhen Lei wrote:
>> First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
>> opportunity to set {lazy|strict} mode as default at build time. Then put
>> the three config options in an choice, make people can only choo
-config IOMMU_DEFAULT_PASSTHROUGH
-bool "IOMMU passthrough by default"
+choice
+prompt "IOMMU default DMA mode"
depends on IOMMU_API
-help
- Enable passthrough by default, removing the need to pass in
- iommu.passthrough=on or iommu=pt through command line. If thi
On 24/05/2019 19:14, Jacob Pan wrote:
> On Thu, 23 May 2019 19:06:13 +0100
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index d546f7baa0d4..b09b3707f0e4 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -872,7 +872,14 @@
>> EXPORT_SYMBOL_GPL(iommu_group_
On 30/05/2019 18:45, Michael S. Tsirkin wrote:
> On Thu, May 30, 2019 at 06:09:24PM +0100, Jean-Philippe Brucker wrote:
>> Some systems implement virtio-iommu as a PCI endpoint. The operating
>> system needs to discover the relationship between IOMMU and masters long
>> before the PCI endpoint gets
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.
>
>
> There is already a bunch o
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
>
> On 29/05/2019 16:09, Tomeu Vizoso wrote:
> > On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
> >>
> > [snip]
> >> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> >> [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at
Hello,
> -Original Message-
> From: David Miller
> Sent: Friday, May 31, 2019 1:09 AM
>
> From: laurentiu.tu...@nxp.com
> Date: Thu, 30 May 2019 17:19:45 +0300
>
> > Depends on this pull request:
> >
> >
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
>
> I
On 23/05/2019 19:56, Robin Murphy wrote:
> On 23/05/2019 19:06, Jean-Philippe Brucker wrote:
>> From: Jacob Pan
>>
>> Traditionally, device specific faults are detected and handled within
>> their own device drivers. When IOMMU is enabled, faults such as DMA
>> related transactions are detected by
On 31/05/2019 13:04, Tomeu Vizoso wrote:
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
On 29/05/2019 16:09, Tomeu Vizoso wrote:
On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
[snip]
[ 345.204813] panfrost 180.gpu: mmu irq status=1
[ 345.209617] panfrost 180.gpu: Unhandl
Hi Laurentiu,
Am 30.05.19 um 16:19 schrieb laurentiu.tu...@nxp.com:
> This patch series contains several fixes in preparation for SMMU
> support on NXP LS1043A and LS1046A chips. Once these get picked up,
> I'll submit the actual SMMU enablement patches consisting in the
> required device tree cha
On Thu, May 30, 2019 at 05:19:50PM +0300, laurentiu.tu...@nxp.com wrote:
> +static phys_addr_t dpaa_iova_to_phys(const struct dpaa_priv *priv,
> + dma_addr_t addr)
> +{
> + return priv->domain ? iommu_iova_to_phys(priv->domain, addr) : addr;
> +}
Again, a drive
On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote:
> From: laurentiu.tu...@nxp.com
> Date: Thu, 30 May 2019 17:19:45 +0300
>
> > Depends on this pull request:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
>
> I'm not sure how you want me to handle
Thanks,
applied to the dma-mapping tree.
Hello Andreas,
> -Original Message-
> From: Andreas Färber
> Sent: Friday, May 31, 2019 7:15 PM
>
> Hi Laurentiu,
>
> Am 30.05.19 um 16:19 schrieb laurentiu.tu...@nxp.com:
> > This patch series contains several fixes in preparation for SMMU
> > support on NXP LS1043A and LS1046A chips.
Hi Christoph,
> -Original Message-
> From: Christoph Hellwig
> Sent: Friday, May 31, 2019 7:32 PM
>
> On Thu, May 30, 2019 at 05:19:50PM +0300, laurentiu.tu...@nxp.com wrote:
> > +static phys_addr_t dpaa_iova_to_phys(const struct dpaa_priv *priv,
> > +dma_
On Fri, May 31, 2019 at 04:53:16PM +, Laurentiu Tudor wrote:
> Unfortunately due to our hardware particularities we do not have
> alternatives. This is also the case for our next generation of ethernet
> drivers [1]. I'll let my colleagues that work on the ethernet drivers to
> comment more
> -Original Message-
> From: Christoph Hellwig
> Sent: Friday, May 31, 2019 7:56 PM
>
> On Fri, May 31, 2019 at 04:53:16PM +, Laurentiu Tudor wrote:
> > Unfortunately due to our hardware particularities we do not have
> alternatives. This is also the case for our next generation of et
On 31/05/2019 17:33, Christoph Hellwig wrote:
On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote:
From: laurentiu.tu...@nxp.com
Date: Thu, 30 May 2019 17:19:45 +0300
Depends on this pull request:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
I'm not
Hello Laurentiu,
Am 31.05.19 um 18:46 schrieb Laurentiu Tudor:
>> -Original Message-
>> From: Andreas Färber
>> Sent: Friday, May 31, 2019 7:15 PM
>>
>> Hi Laurentiu,
>>
>> Am 30.05.19 um 16:19 schrieb laurentiu.tu...@nxp.com:
>>> This patch series contains several fixes in preparation fo
On Fri, May 31, 2019 at 06:03:30PM +0100, Robin Murphy wrote:
> > The thing needs to be completely redone as it abuses parts of the
> > iommu API in a completely unacceptable way.
>
> `git grep iommu_iova_to_phys drivers/{crypto,gpu,net}`
>
> :(
>
> I guess one alternative is for the offending d
> -Original Message-
> From: Andreas Färber
> Sent: Friday, May 31, 2019 8:04 PM
>
> Hello Laurentiu,
>
> Am 31.05.19 um 18:46 schrieb Laurentiu Tudor:
> >> -Original Message-
> >> From: Andreas Färber
> >> Sent: Friday, May 31, 2019 7:15 PM
> >>
> >> Hi Laurentiu,
> >>
> >> Am
On 31/05/2019 18:08, Christoph Hellwig wrote:
On Fri, May 31, 2019 at 06:03:30PM +0100, Robin Murphy wrote:
The thing needs to be completely redone as it abuses parts of the
iommu API in a completely unacceptable way.
`git grep iommu_iova_to_phys drivers/{crypto,gpu,net}`
:(
I guess one alte
On Fri, May 31, 2019 at 06:45:00PM +0100, Robin Murphy wrote:
> Bleh, I'm certainly not keen on formalising any kind of
> dma_to_phys()/dma_to_virt() interface for this. Or are you just proposing
> something like dma_unmap_sorry_sir_the_dog_ate_my_homework() for drivers
> which have 'lost' the orig
The commit "iommu/vt-d: Delegate the dma domain to upper layer" left an
unused variable,
drivers/iommu/intel-iommu.c: In function 'disable_dmar_iommu':
drivers/iommu/intel-iommu.c:1652:23: warning: variable 'domain' set but
not used [-Wunused-but-set-variable]
Signed-off-by: Qian Cai
---
driver
24 matches
Mail list logo
