On Fri, Oct 02, 2020 at 04:55:34AM +0300, Dmitry Osipenko wrote:
> 02.10.2020 04:07, Nicolin Chen пишет:
> > On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote:
> > If we can't come to an agreement on globalizing mc pointer, would
> > it be possible to pass tegra_mc_driver
02.10.2020 04:07, Nicolin Chen пишет:
> On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote:
> If we can't come to an agreement on globalizing mc pointer, would
> it be possible to pass tegra_mc_driver through tegra_smmu_probe()
> so we can continue to use
On Thu, Oct 01, 2020 at 12:46:14PM +0200, Thierry Reding wrote:
> > > > - /*
> > > > -* This is a bit of a hack. Ideally we'd want to simply return
> > > > this
> > > > -* value. However the IOMMU registration process will attempt
> > > > to add
> > > > -* all
On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote:
> >>> If we can't come to an agreement on globalizing mc pointer, would
> >>> it be possible to pass tegra_mc_driver through tegra_smmu_probe()
> >>> so we can continue to use driver_find_device_by_fwnode() as v1?
> >>>
> >>> v1:
Hi Lu,
On 2020-09-27 12:34 a.m., Lu Baolu wrote:
> Hi,
>
> The previous post of this series could be found here.
>
> https://lore.kernel.org/linux-iommu/20200912032200.11489-1-baolu...@linux.intel.com/
>
> This version introduce a new patch [4/7] to fix an issue reported here.
>
>
01.10.2020 14:04, Nicolin Chen пишет:
> On Thu, Oct 01, 2020 at 12:23:16PM +0200, Thierry Reding wrote:
> > > >> It looks to me like the only reason why you need this new global
> API is
>> because PCI devices may not have a device tree node with a phandle to
>> the IOMMU.
The pull request you sent on Thu, 1 Oct 2020 20:50:30 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.9-rc7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/44b6e23be32be4470b1b8bf27380c2e9cca98e2b
Thank you!
--
On Thu, Oct 1, 2020 at 12:31 PM Nicolas Saenz Julienne
wrote:
>
> On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
> > On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> > > Hi Nicolas,
> > >
> > > Thanks for putting this together.
> > >
> > > On Thu, Oct 01, 2020 at
...
>> There are dozens variants of the panels and system could easily have
>> more than one panel, hence a direct lookup by phandle is a natural
>> choice for the panels.
>
> Not really, there's typically only just one panel. But that's just one
> example. EMC would be another. There's only a
Hi Linus,
The following changes since commit ba4f184e126b751d1bffad5897f263108befc780:
Linux 5.9-rc6 (2020-09-20 16:33:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.9-rc7
for you to fetch changes up to
On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
> On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> > Hi Nicolas,
> >
> > Thanks for putting this together.
> >
> > On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
> > > diff --git
On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> Hi Nicolas,
>
> Thanks for putting this together.
>
> On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index 4602e467ca8b..cd0d115ef329 100644
> >
On Thu, Oct 01, 2020 at 06:17:40PM +0200, Nicolas Saenz Julienne wrote:
> The default behavior for arm64 changed, so reflect that.
>
> Signed-off-by: Nicolas Saenz Julienne
Acked-by: Catalin Marinas
___
iommu mailing list
On Thu, Oct 01, 2020 at 06:17:39PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e1a69a618832..3c3f462466eb 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -43,8 +43,6 @@
> #include
> #include
>
> -#define
Hi Nicolas,
Thanks for putting this together.
On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 4602e467ca8b..cd0d115ef329 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -25,6 +25,7 @@
> #include
>
Using two distinct DMA zones turned out to be problematic. Here's an
attempt go back to a saner default.
I tested this on both a RPi4 and QEMU.
---
Nicolas Saenz Julienne (4):
of/fdt: Update zone_dma_bits when running in bcm2711
dma-direct: Turn zone_dma_bits default value into a define
The Raspberry Pi 4 needs two DMA zones as some of its devices can only
DMA into the 30-bit physical address space. We solved that by creating
an extra ZONE_DMA covering the 30-bit. It turns out that creating extra
zones unnecessarily broke Kdump on large systems. So default to a single
32-bit wide
Other code might need to reference it.
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/dma-direct.h | 1 +
kernel/dma/direct.c| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index
The default behavior for arm64 changed, so reflect that.
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/mmzone.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index fb3bf696c05e..d28ce77ccc2a 100644
---
arm64 wants to be able to set ZONE_DMA's size depending on the specific
platform its being run on. Ideally this could be achieved in a smart way
by parsing all dma-ranges and calculating the smaller DMA constraint in
the system. Easier said than done. We compromised on a simpler solution
as the
On Thu, Oct 01, 2020 at 09:51:51PM +0700, Suravee Suthikulpanit wrote:
> Sure. Let me send out v2 for this with some more clean up.
Great, while at it please also change the "iommu: amd:" subjects to
"iommu/amd:".
Thanks,
Joerg
___
iommu
Joerg,
On 10/1/20 7:59 PM, Joerg Roedel wrote:
On Thu, Sep 24, 2020 at 05:50:37PM +0700, Suravee Suthikulpanit wrote:
On 9/24/20 5:34 PM, Joerg Roedel wrote:
Hi Suravee,
On Wed, Sep 23, 2020 at 10:14:29AM +, Suravee Suthikulpanit wrote:
The framework allows callable implementation of
Yan,
On Thu, Oct 01 2020 at 09:39, Zi Yan wrote:
> On 1 Oct 2020, at 4:22, Thomas Gleixner wrote:
>> Can you please test:
>>
>>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/irq
>>
>> which contains fixes and if it still crashes provide the dmesg of it.
>
> My system boots
Hi Joerg
On Thu, Oct 01, 2020 at 02:58:41PM +0200, Joerg Roedel wrote:
> Hi Ashok,
>
> On Fri, Sep 25, 2020 at 12:06:17PM -0700, Ashok Raj wrote:
> > Sai Praneeth Prakhya (3):
> > iommu: Add support to change default domain of an iommu group
> > iommu: Take lock before reading iommu group
On 1 Oct 2020, at 4:22, Thomas Gleixner wrote:
> Yan,
>
> On Wed, Sep 30 2020 at 21:29, Zi Yan wrote:
>> I am running linux-next on my Dell R630 and the system crashed at boot
>> time. I bisected linux-next and got to your commit:
>>
>> x86/msi: Consolidate MSI allocation
>>
>> The crash log
On Thu, Sep 24, 2020 at 05:50:37PM +0700, Suravee Suthikulpanit wrote:
>
>
> On 9/24/20 5:34 PM, Joerg Roedel wrote:
> > Hi Suravee,
> >
> > On Wed, Sep 23, 2020 at 10:14:29AM +, Suravee Suthikulpanit wrote:
> > > The framework allows callable implementation of IO page table.
> > > This
Hi Ashok,
On Fri, Sep 25, 2020 at 12:06:17PM -0700, Ashok Raj wrote:
> Sai Praneeth Prakhya (3):
> iommu: Add support to change default domain of an iommu group
> iommu: Take lock before reading iommu group default domain type
> iommu: Document usage of "/sys/kernel/iommu_groups//type" file
On Sun, Sep 27, 2020 at 02:24:28PM +0800, Lu Baolu wrote:
> drivers/iommu/intel/iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied for v5.9, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Jacob,
On Mon, Sep 28, 2020 at 11:40:53AM -0700, Jacob Pan wrote:
> Just wondering if you will be able to take this for v5.10? There hasn't
> been any material changes since we last discussed in LPC. We have VFIO and
> other vSVA patches depending on it.
Queued for v5.10 now, thanks.
On Wed, Sep 30, 2020 at 09:05:23AM +0100, Will Deacon wrote:
> The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:
>
> Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)
>
> are available in the Git repository at:
>
>
Hi Baolu,
On Tue, Sep 29, 2020 at 08:11:35AM +0800, Lu Baolu wrote:
> I have no preference. It depends on which patch goes first. Let the
> maintainers help here.
No preference on my side, except that it is too late for this now to
make it into v5.10. Besides that I let the decission up to you
On Sat, Sep 26, 2020 at 06:26:02PM +0800, Adrian Huang wrote:
> From: Adrian Huang
>
> Commit 387caf0b759a ("iommu/amd: Treat per-device exclusion
> ranges as r/w unity-mapped regions") accidentally overwrites
> the 'flags' field in IVMD (struct ivmd_header) when the I/O
> virtualization memory
On Wed, Sep 30, 2020 at 09:05:23AM +0100, Will Deacon wrote:
> Please pull these arm-smmu updates for 5.10. Summary in the tag, but the
> big thing here is the long-awaited SVM enablement from Jean-Philippe.
> We're not quite done yet, but this pull extends the SMMUv3 driver so that
> we're very
On Thu, Oct 01, 2020 at 12:23:16PM +0200, Thierry Reding wrote:
> > >> It looks to me like the only reason why you need this new global
> > >> API is
> > > >> because PCI devices may not have a device tree node with a phandle
> > > >> to
> > > >> the IOMMU. However, SMMU
On Wed, Sep 30, 2020 at 01:36:18PM -0700, Nicolin Chen wrote:
> On Wed, Sep 30, 2020 at 05:31:31PM +0200, Thierry Reding wrote:
> > On Wed, Sep 30, 2020 at 01:42:57AM -0700, Nicolin Chen wrote:
> > > Previously the driver relies on bus_set_iommu() in .probe() to call
> > > in .probe_device()
On Thu, Oct 01, 2020 at 03:33:19AM -0700, Nicolin Chen wrote:
> On Thu, Oct 01, 2020 at 11:51:52AM +0200, Thierry Reding wrote:
> > > > >> ...
> > > > It looks to me like the only reason why you need this new global
> > > > API is
> > > > because PCI devices may not have a device
On Thu, Oct 01, 2020 at 11:51:52AM +0200, Thierry Reding wrote:
> > > >> ...
> > > It looks to me like the only reason why you need this new global API
> > > is
> > > because PCI devices may not have a device tree node with a phandle to
> > > the IOMMU. However, SMMU support
On Wed, Sep 30, 2020 at 07:48:50PM -0700, Nicolin Chen wrote:
> On Thu, Oct 01, 2020 at 05:06:19AM +0300, Dmitry Osipenko wrote:
> > 01.10.2020 04:26, Nicolin Chen пишет:
> > > On Thu, Oct 01, 2020 at 12:56:46AM +0300, Dmitry Osipenko wrote:
> > >> 01.10.2020 00:32, Nicolin Chen пишет:
> > >>> On
On Thu, Oct 01, 2020 at 05:06:19AM +0300, Dmitry Osipenko wrote:
> 01.10.2020 04:26, Nicolin Chen пишет:
> > On Thu, Oct 01, 2020 at 12:56:46AM +0300, Dmitry Osipenko wrote:
> >> 01.10.2020 00:32, Nicolin Chen пишет:
> >>> On Thu, Oct 01, 2020 at 12:24:25AM +0300, Dmitry Osipenko wrote:
> ...
On Wed, Sep 30, 2020 at 06:26:30PM -0700, Nicolin Chen wrote:
> On Thu, Oct 01, 2020 at 12:56:46AM +0300, Dmitry Osipenko wrote:
> > 01.10.2020 00:32, Nicolin Chen пишет:
> > > On Thu, Oct 01, 2020 at 12:24:25AM +0300, Dmitry Osipenko wrote:
> > >> ...
> > It looks to me like the only reason
On Wed, Sep 30, 2020 at 01:36:18PM -0700, Nicolin Chen wrote:
> On Wed, Sep 30, 2020 at 05:31:31PM +0200, Thierry Reding wrote:
> > On Wed, Sep 30, 2020 at 01:42:57AM -0700, Nicolin Chen wrote:
> > > Previously the driver relies on bus_set_iommu() in .probe() to call
> > > in .probe_device()
Yan,
On Wed, Sep 30 2020 at 21:29, Zi Yan wrote:
> I am running linux-next on my Dell R630 and the system crashed at boot
> time. I bisected linux-next and got to your commit:
>
> x86/msi: Consolidate MSI allocation
>
> The crash log is below and my .config is attached.
>
> [ 11.840905]
On Wed, Sep 30, 2020 at 07:29:12PM +0300, Dmitry Osipenko wrote:
> ...
> >> Secondly, I'm already about to use the new tegra_get_memory_controller()
> >> API for all the T20/30/124/210 EMC and devfreq drivers.
> >
> > Also, this really proves the point I was trying to make about how this
> > is
On Thu, Oct 01, 2020 at 05:11:30AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 19:47, Thierry Reding пишет:
> > On Wed, Sep 30, 2020 at 07:25:41PM +0300, Dmitry Osipenko wrote:
> >> 30.09.2020 19:06, Thierry Reding пишет:
> >>> On Wed, Sep 30, 2020 at 06:36:52PM +0300, Dmitry Osipenko wrote:
>
44 matches
Mail list logo
