On 2016年07月12日 18:55, Joerg Roedel wrote:
Hey Vincent,
On Tue, Jul 12, 2016 at 05:03:08PM +0800, Wan Zongshun wrote:
Currently, those patches can not work at my eCarrizo board.
When I merged your patches, boot failed, and no any info print to me.
I set iommu=pt, it also does not work; set
linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
---
Vincent Wan(Zongshun)
www.mcuos.com
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2016年07月11日 15:19, Joerg Roedel wrote:
On Sun, Jul 10, 2016 at 07:40:53PM +0800, Wan Zongshun wrote:
Do you mean we need enable the V and TV bits to DTE entry after all
DTEs tables were initialized completely?
Yes, this is what my patch does and what fixes the bug that was
reported
On 2016年07月07日 00:00, Joerg Roedel wrote:
From: Joerg Roedel
There is a race condition in the AMD IOMMU init code that
causes requested unity mappings to be blocked by the IOMMU
for a short period of time. This results on boot failures
and IO_PAGE_FAULTs on some machines.
On 2016年07月05日 09:56, sunnydrake wrote:
On 04.07.16 16:51, Wan Zongshun wrote:
在 7/4/2016 4:48 AM, sunnydrake 写道:
Thanks for reply.
On 03.07.16 17:26, Wan Zongshun wrote:
在 7/3/2016 8:59 AM, sunnydrake 写道:
[description]
working in kernel 3.9
Oops in current 4.4.0-28,4.7.0-040700rc5
在 7/4/2016 4:48 AM, sunnydrake 写道:
Thanks for reply.
On 03.07.16 17:26, Wan Zongshun wrote:
在 7/3/2016 8:59 AM, sunnydrake 写道:
[description]
working in kernel 3.9
Oops in current 4.4.0-28,4.7.0-040700rc5
kernel options ivrs_ioapic[7]=00:14.0 ivrs_ioapic[8]=00:00.1
workaround to fix ivrs
在 7/3/2016 8:59 AM, sunnydrake 写道:
[description]
working in kernel 3.9
Oops in current 4.4.0-28,4.7.0-040700rc5
kernel options ivrs_ioapic[7]=00:14.0 ivrs_ioapic[8]=00:00.1
workaround to fix ivrs table
cause kernel Oops on boot
Do you mean "ivrs_ioapic[7]=00:14.0 ivrs_ioapic[8]=00:00.1" are
SLOT(devid),
> PCI_FUNC(devid));
>
> - devid = e->devid;
> flags = e->flags;
>
Sure, thanks for your patch.
This is my fault.
> ret = add_acpi_hid_device(hid, uid, ,
From: Wan Zongshun <vincent@amd.com>
This patch is to do the following:
1. Add error check for caller of iommu_device_create.
2. Add error check for caller of iommu_device_link and
move 'iommu = amd_iommu_rlookup_table[dev_data->devid]' out of
iommuv2 capability condition
2016-05-10 21:21 GMT+08:00 Wan Zongshun <vincent@amd.com>:
> From: Wan Zongshun <vincent@amd.com>
>
> AMD has more drivers will use ACPI to platform bus driver later,
> all those devices need iommu support, for example: eMMC driver.
>
> For latest AMD eMMC con
2016-06-14 1:40 GMT+08:00 Lutz Vieweg <l...@5t9.de>:
> On 06/13/2016 04:46 AM, Wan ZongShun wrote:
>>>
>>> With "iommu=pt":
>>>>
>>>>
>>>> [4.832580] iommu: Adding device :04:00.0 to group 1
0] AGP: This costs you 64MB of RAM
>> [0.00] AGP: Mapping aperture over RAM [mem 0xcc00-0xcfff]
>> (65536KB)
>
> I checked and the IOMMU-option is definitely enabled in the BIOS setup.
> So I assume right that these message are irrelevant (since AGP as a whole
> is irrelevant on
Original Message
From: Baoquan HE
If not valid just skip reserving the old domain id.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 4
drivers/iommu/amd_iommu_init.c | 5 +++--
Original Message
From: Baoquan HE
Here several things need be done:
1) Initialize amd_iommu_dev_table because it was set several times
since kdump kernel reboot. We don't need the set because we will
copy the content from old kernel.
Original Message
Add function copy_dev_tables to copy old DTE of the 1st kernel to
the new DTE table. Since all iommu share the same DTE table the
copy only need be done once as long as the physical address of
old DTE table is retrieved from iommu reg. Besides the old domain
Original Message
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 25 +
drivers/iommu/amd_iommu_types.h | 4
2 files changed, 29
From: Wan Zongshun <vincent@amd.com>
This patch is to do the following:
1. Add error check for caller of iommu_device_create.
2. Add error check for caller of iommu_device_link and
move 'iommu = amd_iommu_rlookup_table[dev_data->devid]' out of
iommuv2 capability condition
From: Wan Zongshun <vincent@amd.com>
AMD has more drivers will use ACPI to platform bus driver later,
all those devices need iommu support, for example: eMMC driver.
For latest AMD eMMC controller, it will utilize sdhci-acpi.c driver,
which will rely on platform bus to match
From: Wan Zongshun <vincent@amd.com>
AMD has more drivers will use ACPI to platform bus driver later,
all those devices need iommu support, such as eMMC acpi driver.
Signed-off-by: Wan Zongshun <vincent@amd.com>
---
drivers/iommu/amd_iommu.c | 4
1 file changed,
From: Wan Zongshun <vincent@amd.com>
AMD Uart DMA belongs to ACPI HID type device, and its driver
is basing on AMBA Bus, need also IOMMU support.
This patch is just to set the AMD iommu callbacks for amba bus.
Signed-off-by: Wan Zongshun <vincent@amd.com>
---
drivers/iommu
From: Wan Zongshun <vincent@amd.com>
This patch creates a new function for finding or creating an IOMMU
group for acpihid(ACPI Hardware ID) device.
The acpihid devices with the same devid will be put into same group and
there will have the same domain id and share the same page
From: Wan Zongshun <vincent@amd.com>
Current IOMMU driver make assumption that the downstream devices are PCI.
With the newly added ACPI-HID IVHD device entry support, this is no
longer true. This patch is to add dev type check and to distinguish the
pci and acpihid device code path.
From: Wan Zongshun <vincent@amd.com>
This patch is to make the call-sites of get_device_id aware of its
return value.
Signed-off-by: Wan Zongshun <vincent@amd.com>
---
drivers/iommu/amd_iommu.c | 51 +--
1 file changed, 41 inser
From: Wan Zongshun <vincent@amd.com>
There are some devices indentified using ACPI HID format in AMD chip.
This patch series enable iommu support for those ACPI HID device,
since the existing AMD iommu only supports PCI bus based device.
The latest public version of AMD IOMMU specifi
From: Suravee Suthikulpanit
This patch modifies the existing struct ivhd_header,
which currently only support IVHD type 0x10, to add
new fields from IVHD type 11h and 40h.
It also modifies the pointer calculation to allow
support for IVHD type 11h and 40h
d_type())
before parsing the contents.
[Vincent: fix the build error of IVHD_DEV_ACPI_HID flag not found]
Signed-off-by: Wan Zongshun <vincent@amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
---
drivers/iommu/amd_iommu_init.c | 107 ++
From: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
This patch introduces a new kernel parameter, ivrs_acpihid.
This is used to override existing ACPI-HID IVHD device entry,
or add an entry in case it is missing in the IVHD.
Signed-off-by: Wan Zongshun <vincent@amd.com>
From: Suravee Suthikulpanit
The IVHD header type 11h and 40h introduce the PCSup bit in
the EFR Register Image bit fileds. This should be used to
determine the IOMMU performance support instead of relying
on the PNCounters and PNBanks.
Note also that the PNCouters
From: Wan Zongshun <vincent@amd.com>
This patch introduces acpihid_map, which is used to store
the new IVHD device entry extracted from BIOS IVRS table.
It also provides a utility function add_acpi_hid_device(),
to add this types of devices to the map.
Signed-off-by: Wan Zongshun &l
Original Message
On 01/27/16 at 07:03pm, Wan Zongshun wrote:
Original Message
alias = amd_iommu_alias_table[devid];
table = irq_lookup_table[alias];
@@ -3688,7 +3688,7 @@ static struct irq_remap_table *get_irq_table(u16 devid,
bool
Original Message
On 01/27/16 at 06:18pm, Wan Zongshun wrote:
Original Message
In amd-vi spec the name of bit0 in DTE is V. But in code it's defined
as IOMMU_PTE_P. Here change it to IOMMU_PTE_V to make it be consistent
with spec.
Hi, Baoquan
Original Message
If irq table exists in old kernel create a new one and copy the content
of old irq table to the newly created.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/amd_iommu_init.c | 43
Original Message
In amd-vi spec the name of bit0 in DTE is V. But in code it's defined
as IOMMU_PTE_P. Here change it to IOMMU_PTE_V to make it be consistent
with spec.
Hi, Baoquan
This should be PR bit which means present, So maybe you got confusion
between DTE and PTE
Original Message
In amd-vi spec bit[60:58] are only used to store the bit[14:12] of GCR3.
No any other useage is found in several versions of amd-vi spec. So remove
them in this patch.
Also,this patch also made me confusion, please keep FC bit here, bit[60]
should be PTE's
Original Message
These macro definitions are also needed by irq table copy function
later, so move them to amd_iommu_types.h.
Typo for your subject (defitions?).
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 4
Original Message
This is a clean up. In get_irq_table() only if DTE entry is changed
iommu_completion_wait() need be called. Otherwise no need to do it.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 6 +++---
1 file changed, 3 insertions(+),
From: Wan Zongshun <vincent@amd.com>
There are some devices indentified using ACPI HID format in AMD chip.
This patch series enable iommu support for those ACPI HID device,
since the existing AMD iommu only supports PCI bus based device.
The latest public version of AMD IOMMU specifi
From: Suravee Suthikulpanit
This patch modifies the existing struct ivhd_header, which currently
only support IVHD type 0x10, to add new fields from IVHD type 11h and 40h.
It also modifies the pointer calculation to allow support for IVHD type
11h and 40h
From: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
This patch introduces a new kernel parameter, ivrs_acpihid.
This is used to override existing ACPI-HID IVHD device entry,
or add an entry in case it is missing in the IVHD.
Signed-off-by: Wan Zongshun <vincent@amd.com>
From: Wan Zongshun <vincent@amd.com>
This patch introduces acpihid_map, which is used to store
the new IVHD device entry extracted from BIOS IVRS table.
It also provides a utility function add_acpi_hid_device(),
to add this types of devices to the map.
Signed-off-by: Wan Zongshun &l
d_type())
before parsing the contents.
[Vincent: fix the build error of IVHD_DEV_ACPI_HID flag not found]
Signed-off-by: Wan Zongshun <vincent@amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
---
drivers/iommu/amd_iommu_init.c | 107 ++
From: Wan Zongshun <vincent@amd.com>
Current IOMMU driver make assumption that the downstream devices are PCI.
With the newly added ACPI-HID IVHD device entry support, this is no
longer true. This patch is to add dev type check and to distinguish the
pci and acpihid device code path.
From: Wan Zongshun <vincent@amd.com>
This patch creates a new function for finding or creating an IOMMU
group for acpihid(ACPI Hardware ID) device.
The acpihid devices with the same devid will be put into same group and
there will have the same domain id and share the same page
From: Wan Zongshun <vincent@amd.com>
This patch is to make the call-sites of get_device_id aware of its
return value.
Signed-off-by: Wan Zongshun <vincent@amd.com>
---
drivers/iommu/amd_iommu.c | 51 +--
1 file changed, 41 inser
From: Wan Zongshun <vincent@amd.com>
AMD Uart DMA belongs to ACPI HID type device, and its driver
is basing on AMBA Bus, need also IOMMU support.
This patch is just to set the AMD iommu callbacks for amba bus.
Signed-off-by: Wan Zongshun <vincent@amd.com>
---
drivers/iommu
2015-12-30 0:54 GMT+08:00 Wan Zongshun <vincent@amd.com>:
> From: Wan Zongshun <vincent@amd.com>
>
> Since uart dma is using AMD iommu, and it bases on amba bus.
> So we need set callbacks for amba bus type firstly.
>
> Signed-off-by: Wan Zongshun <vince
static bool check_device(struct device *dev)
{
u16 devid;
..
/* No PCI device */
if (!dev_is_pci(dev) && (get_acpihid_device_id(dev, NULL) < 0))
return false;
devid = get_device_id(dev);
That is true for this case, but the other
2016-01-07 20:04 GMT+08:00 Joerg Roedel <j...@8bytes.org>:
> On Tue, Jan 05, 2016 at 05:07:23AM -0500, Wan Zongshun wrote:
>> -static inline u16 get_device_id(struct device *dev)
>> +static inline int match_hid_uid(struct device *dev,
>> +
2016-01-07 20:06 GMT+08:00 Joerg Roedel <j...@8bytes.org>:
> On Tue, Jan 05, 2016 at 05:07:24AM -0500, Wan Zongshun wrote:
>> +static struct iommu_group *amd_iommu_device_group(struct device *dev)
>> +{
>> + if (dev_is_pci(dev))
>> +
From: Suravee Suthikulpanit
This patch modifies the existing struct ivhd_header, which currently
only support IVHD type 0x10, to add new fields from IVHD type 11h and 40h.
It also modifies the pointer calculation to allow support for IVHD type
11h and 40h
d_type())
before parsing the contents.
[Vincent: fix the build error of IVHD_DEV_ACPI_HID flag not found]
Signed-off-by: Wan Zongshun <vincent@amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
---
drivers/iommu/amd_iommu_init.c | 107 ++
From: Wan Zongshun <vincent@amd.com>
This patch creates a new function for finding or creating an IOMMU
group for acpihid(ACPI Hardware ID) device.
The acpihid devices with the same devid will be put into same group and
there will have the same domain id and share the same page
From: Wan Zongshun <vincent@amd.com>
This patch introduces acpihid_map, which is used to store
the new IVHD device entry extracted from BIOS IVRS table.
It also provides a utility function add_acpi_hid_device(),
to add this types of devices to the map.
Signed-off-by: Wan Zongshun &l
From: Wan Zongshun <vincent@amd.com>
This patch series enable ACPI hardware ID device support,
There are some devices indentified using ACPI HID format in AMD chip.
This patch series enable iommu support for those ACPI HID device,
since the existing AMD iommu only supports PCI bus
From: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
This patch introduces a new kernel parameter, ivrs_acpihid.
This is used to override existing ACPI-HID IVHD device entry,
or add an entry in case it is missing in the IVHD.
Signed-off-by: Wan Zongshun <vincent@amd.com>
From: Wan Zongshun <vincent@amd.com>
Current IOMMU driver make assumption that the downstream devices are PCI.
With the newly added ACPI-HID IVHD device entry support, this is no
longer true. This patch is to add dev type check and to distinguish the
pci and acpihid device code path.
From: Wan Zongshun <vincent@amd.com>
Since uart dma is using AMD iommu, and it bases on amba bus.
So we need set callbacks for amba bus type firstly.
Signed-off-by: Wan Zongshun <vincent@amd.com>
---
drivers/iommu/amd_iommu.c | 13 -
1 file changed, 12 inse
->iommu_dev' break your iommu work? It
seems not necessary.
>
> return 0;
> -
> err_unmap:
> unmap_iommu(iommu);
> error_free_seq_id:
> --
> 2.5.0
>
> ___
> iommu mailing list
>
58 matches
Mail list logo