On 7/22/20 11:03 AM, Jun Miao wrote:
On 7/22/20 10:40 AM, Lu Baolu wrote:
Hi Jun,
On 7/22/20 10:26 AM, Miao, Jun wrote:
Kernel panic - not syncing: DMAR hardware is malfunctioning
CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
Hardware name: Intel Corporation Ice Lake Clie
As Intel VT-d files have been move to its own subdirectory, the prefix
makes no sense.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/debugfs.c | 2 +-
drivers/iommu/intel/iommu.c| 2 +-
drivers/iommu/intel/pasid.c| 2 +-
drivers/iommu/in
Hi Jun,
On 7/22/20 10:26 AM, Miao, Jun wrote:
Kernel panic - not syncing: DMAR hardware is malfunctioning
CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4
SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.190
Hi Jacob,
On 7/22/20 12:50 AM, Jacob Pan wrote:
Hi Baolu,
Not sure what state is this patch in, there is a bug in this patch
(see below), shall I send out an updated version of this one only? or
another incremental patch.
Please send an updated version. I hope Joerg could pick these as 5.8
fi
On Tue 21 Jul 09:20 PDT 2020, Konrad Dybcio wrote:
> >The current
> >focus has been on moving more of the SMMU specific bits into the
> >arm-smmu-qcom
> >implementation [1] and I think that is the right way to go.
>
> Pardon if I overlooked something obvious, but I can't seem to find a
> clean w
> -Original Message-
> From: Lu Baolu
> Sent: Tuesday, July 21, 2020 6:07 PM
> To: Limonciello, Mario; Joerg Roedel
> Cc: baolu...@linux.intel.com; Ashok Raj; linux-ker...@vger.kernel.org;
> sta...@vger.kernel.org; Koba Ko; iommu@lists.linux-foundation.org
> Subject: Re: [PATCH 1/1] iom
Hi Limonciello,
On 7/21/20 10:44 PM, Limonciello, Mario wrote:
-Original Message-
From: iommu On Behalf Of Lu
Baolu
Sent: Monday, July 20, 2020 7:17 PM
To: Joerg Roedel
Cc: Ashok Raj;linux-ker...@vger.kernel.org;sta...@vger.kernel.org; Koba
Ko;iommu@lists.linux-foundation.org
Subject: [
On Fri, 17 Jul 2020 13:59:54 -0600
Alex Williamson wrote:
> On Thu, 16 Jul 2020 11:45:16 -0700
> Jacob Pan wrote:
>
> > IOMMU UAPI data has a user filled argsz field which indicates the
> > data length comes with the API call. User data is not trusted,
> > argsz must be validated based on the c
On Fri, 17 Jul 2020 17:58:04 +0200
Auger Eric wrote:
> Hi Jacob,
> On 7/16/20 8:45 PM, Jacob Pan wrote:
>
> Could you share a branch? I was not able to apply this on either
> iommu/next or master?
>
Will push it to github for the next version. This set is based on
v5.8-rc1 and my fixes for devT
On 21/07/2020 13:24, Yong Wu wrote:
On Tue, 2020-07-21 at 11:40 +0200, Matthias Brugger wrote:
On 21/07/2020 04:16, Miles Chen wrote:
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading inf
PASID and PRI capabilities are only enumerated in PF devices. VF devices
do not enumerate these capabilites. IOMMU drivers also need to enumerate
them before enabling features in the IOMMU. Extending the same support as
PASID feature discovery (pci_pasid_features) for PRI.
Signed-off-by: Ashok Raj
PASID and PRI capabilities are only enumerated in PF devices. VF devices
do not enumerate these capabilites. IOMMU drivers also need to enumerate
them before enabling features in the IOMMU. Extending the same support as
PASID feature discovery (pci_pasid_features) for PRI.
Signed-off-by: Ashok Raj
Hi Baolu,
Not sure what state is this patch in, there is a bug in this patch
(see below), shall I send out an updated version of this one only? or
another incremental patch.
Thanks,
Jacob
On Mon, 6 Jul 2020 17:12:51 -0700
Jacob Pan wrote:
> From: Liu Yi L
>
> Address information for device
On Tue, 2020-07-21 at 20:52 +0530, Amit Pundir wrote:
[...]
> > > > Can you try booting *without* my patch and this in the kernel
> > > > command
> > > > line: "cma=16M@0x1-0x2".
> > >
> > > It doesn't boot with this added kernel command line.
> >
> > For the record, this placed
>The current
>focus has been on moving more of the SMMU specific bits into the arm-smmu-qcom
>implementation [1] and I think that is the right way to go.
Pardon if I overlooked something obvious, but I can't seem to find a
clean way for implementing qcom,skip-init in arm-smmu-qcom, as neither
the
On Tue, Jul 21, 2020 at 05:04:11PM +0200, Konrad Dybcio wrote:
> So.. is this a no-no?
>
> I of course would like to omit this entirely, but SMMUs on sdm630 and
> friends are REALLY picky.. What seems to happen is that when the
> driver tries to do things the "standard" way, hypervisor decides to
On Tue, 21 Jul 2020 at 18:15, Nicolas Saenz Julienne
wrote:
>
> On Tue, 2020-07-21 at 17:45 +0530, Amit Pundir wrote:
> > On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne
> > wrote:
> > > On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote:
> > > > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz
> -Original Message-
> From: iommu On Behalf Of Lu
> Baolu
> Sent: Monday, July 20, 2020 7:17 PM
> To: Joerg Roedel
> Cc: Ashok Raj; linux-ker...@vger.kernel.org; sta...@vger.kernel.org; Koba
> Ko; iommu@lists.linux-foundation.org
> Subject: [PATCH 1/1] iommu/vt-d: Skip TE disabling on qui
So.. is this a no-no?
I of course would like to omit this entirely, but SMMUs on sdm630 and
friends are REALLY picky.. What seems to happen is that when the
driver tries to do things the "standard" way, hypervisor decides to
hang the platform or force a reboot. Not very usable.
This thing is nee
On Fri, Jun 19, 2020 at 09:20:04AM +0100, Lorenzo Pieralisi wrote:
> There is nothing PCI specific in iort_msi_map_rid().
>
> Rename the function using a bus protocol agnostic name,
> iort_msi_map_id(), and convert current callers to it.
>
> Signed-off-by: Lorenzo Pieralisi
> Cc: Will Deacon
>
On Mon, Jul 20, 2020 at 09:43:00AM -0700, Ashok Raj wrote:
> PASID and PRI capabilities are only enumerated in PF devices. VF devices
> do not enumerate these capabilites. IOMMU drivers also need to enumerate
> them before enabling features in the IOMMU. Extending the same support as
> PASID featur
On Wed, Jul 15, 2020 at 10:35:11AM -0400, Jim Quinlan wrote:
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable o
On Tue, 2020-07-21 at 17:45 +0530, Amit Pundir wrote:
> On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne
> wrote:
> > On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote:
> > > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne
> > > wrote:
> > > > Hi Amit,
> > > > > Hi Nicolas,
> > > > >
On Tue, 21 Jul 2020 at 17:07, Nicolas Saenz Julienne
wrote:
>
> On Tue, 2020-07-21 at 13:28 +0200, Christoph Hellwig wrote:
> > On Tue, Jul 21, 2020 at 01:15:23PM +0200, Nicolas Saenz Julienne
> > wrote:
> > > I'm at loss at what could be failing here. Your device should be
> > > able
> > > to add
On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne
wrote:
>
> On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote:
> > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne
> > wrote:
> > > Hi Amit,
> > > > Hi Nicolas,
> > > >
> > > > I see a boot regression with this commit d9765e41d8e9 "dma-p
On Tue, 2020-07-21 at 13:28 +0200, Christoph Hellwig wrote:
> On Tue, Jul 21, 2020 at 01:15:23PM +0200, Nicolas Saenz Julienne
> wrote:
> > I'm at loss at what could be failing here. Your device should be
> > able
> > to address the whole 8GB memory space, which AFAIK is the max
> > available
> > o
On Tue, Jul 21, 2020 at 01:15:23PM +0200, Nicolas Saenz Julienne wrote:
> I'm at loss at what could be failing here. Your device should be able
> to address the whole 8GB memory space, which AFAIK is the max available
> on that smartphone family. But maybe the device-tree is lying, who
> knows...
On Tue, 2020-07-21 at 11:40 +0200, Matthias Brugger wrote:
>
> On 21/07/2020 04:16, Miles Chen wrote:
> > In previous discussion [1] and [2], we found that it is risky to
> > use max_pfn or totalram_pages to tell if 4GB mode is enabled.
> >
> > Check 4GB mode by reading infracfg register, remove
On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote:
> On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne
> wrote:
> > Hi Amit,
> > > Hi Nicolas,
> > >
> > > I see a boot regression with this commit d9765e41d8e9 "dma-pool:
> > > Do not allocate pool memory from CMA" on my Xiaomi Poco F1
> > >
On 21/07/2020 04:16, Miles Chen wrote:
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the un-exported symbol max_pfn.
This is a step towards buildi
On 21.07.20 04:16, Miles Chen wrote:
> In previous discussion [1] and [2], we found that it is risky to
> use max_pfn or totalram_pages to tell if 4GB mode is enabled.
>
> Check 4GB mode by reading infracfg register, remove the usage
> of the un-exported symbol max_pfn.
>
> This is a step towards
On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne
wrote:
>
> Hi Amit,
>
> On Tue, 2020-07-21 at 12:51 +0530, Amit Pundir wrote:
> > On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne
> > wrote:
> > > There is no guarantee to CMA's placement, so allocating a zone
> > > specific
> > > atomic po
Hi Amit,
On Tue, 2020-07-21 at 12:51 +0530, Amit Pundir wrote:
> On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne
> wrote:
> > There is no guarantee to CMA's placement, so allocating a zone
> > specific
> > atomic pool from CMA might return memory from a completely
> > different
> > memory zon
On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne
wrote:
>
> There is no guarantee to CMA's placement, so allocating a zone specific
> atomic pool from CMA might return memory from a completely different
> memory zone. So stop using it.
>
> Fixes: c84dc6e68a1d ("dma-pool: add additional coherent
Hi Joerg,
Please pull these Arm SMMU driver updates for 5.9. Summary is in the tag,
but the main thing is support for two new SoC integrations, one of which
is considerably more brain-dead than the other (determining which one is
left as an exercise to the reader although the diffstat is fairly re
35 matches
Mail list logo
