On Mon, Mar 22, 2021 at 09:57:58PM +0000, Kaneda, Erik wrote: > > > > -----Original Message----- > > From: Shameerali Kolothum Thodi > > <shameerali.kolothum.thodi@xxxxxxxxxx> > > Sent: Monday, March 22, 2021 3:36 AM > > To: Kaneda, Erik <erik.kaneda@xxxxxxxxx>; linux-arm- > > kernel@xxxxxxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; iommu@lists.linux- > > foundation.org; devel@xxxxxxxxxx; Lorenzo Pieralisi > > <lorenzo.pieralisi@xxxxxxx>; Moore, Robert <robert.moore@xxxxxxxxx> > > Cc: Linuxarm <linuxarm@xxxxxxxxxx>; steven.price@xxxxxxx; > > Sami.Mujawar@xxxxxxx; robin.murphy@xxxxxxx; wanghuiqiang > > <wanghuiqiang@xxxxxxxxxx> > > Subject: [Devel] Re: [RFC PATCH v2 1/8] ACPICA: IORT: Update for revision E > > > > [+] > > > > Hi Erik, > > > > As this is now just merged ino acpica-master and based on the discussion we > > had here, > > > > https://github.com/acpica/acpica/pull/638 > > > > I had a discussion with ARM folks(Lorenzo) in the linaro-open-discussions call > > and > > can confirm that the IORT Revision E is not the final specification and has > > some issues > > which is now corrected in the latest E.b revision[1]. Also there are no current > > users > > for the Rev E and it may not be a good idea to push this version into the Linux > > kernel > > or elsewhere. > > > > So could you please revert the merge and I am planning to work on the E.b > > soon. > Hi, > > > Please let me know if I need to explicitly send a revert pull request or not. > > Please send a revert pull request and I'll remember to not submit Linux-ize the IORT patches. > > From all of the activity that I've seen with the IORT specification, > it looks like this table is nontrivial to design and maintain. The > difficulty I have with the table is that I do not understand which > table revisions are in active use. Possibly all of them in firmware in the field - I am not sure what you are asking though; if you can elaborate I'd be grateful. > So my question is this: which IORT revisions are being actively used? See above. Thanks, Lorenzo > > Thanks, > Erik > > > > Thanks, > > Shameer > > > > 1. https://developer.arm.com/documentation/den0049/latest/ > > > > > -----Original Message----- > > > From: iommu [mailto:iommu-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On > > Behalf Of > > > Shameer Kolothum > > > Sent: 19 November 2020 12:12 > > > To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; > > > iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; devel@xxxxxxxxxx > > > Cc: Linuxarm <linuxarm@xxxxxxxxxx>; steven.price@xxxxxxx; > > Guohanjun > > > (Hanjun Guo) <guohanjun@xxxxxxxxxx>; Sami.Mujawar@xxxxxxx; > > > robin.murphy@xxxxxxx; wanghuiqiang <wanghuiqiang@xxxxxxxxxx> > > > Subject: [RFC PATCH v2 1/8] ACPICA: IORT: Update for revision E > > > > > > IORT revision E contains a few additions like, > > > -Added an identifier field in the node descriptors to aid table > > > cross-referencing. > > > -Introduced the Reserved Memory Range(RMR) node. This is used > > > to describe memory ranges that are used by endpoints and requires > > > a unity mapping in SMMU. > > > -Introduced a flag in the RC node to express support for PRI. > > > > > > Signed-off-by: Shameer Kolothum > > <shameerali.kolothum.thodi@xxxxxxxxxx> > > > --- > > > include/acpi/actbl2.h | 25 +++++++++++++++++++------ > > > 1 file changed, 19 insertions(+), 6 deletions(-) > > > > > > diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index > > > ec66779cb193..274fce7b5c01 100644 > > > --- a/include/acpi/actbl2.h > > > +++ b/include/acpi/actbl2.h > > > @@ -68,7 +68,7 @@ > > > * IORT - IO Remapping Table > > > * > > > * Conforms to "IO Remapping Table System Software on ARM Platforms", > > > - * Document number: ARM DEN 0049D, March 2018 > > > + * Document number: ARM DEN 0049E, June 2020 > > > * > > > > > > > > ********************************************************** > > ****** > > > **************/ > > > > > > @@ -86,7 +86,8 @@ struct acpi_iort_node { > > > u8 type; > > > u16 length; > > > u8 revision; > > > - u32 reserved; > > > + u16 reserved; > > > + u16 identifier; > > > u32 mapping_count; > > > u32 mapping_offset; > > > char node_data[1]; > > > @@ -100,7 +101,8 @@ enum acpi_iort_node_type { > > > ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02, > > > ACPI_IORT_NODE_SMMU = 0x03, > > > ACPI_IORT_NODE_SMMU_V3 = 0x04, > > > - ACPI_IORT_NODE_PMCG = 0x05 > > > + ACPI_IORT_NODE_PMCG = 0x05, > > > + ACPI_IORT_NODE_RMR = 0x06, > > > }; > > > > > > struct acpi_iort_id_mapping { > > > @@ -167,10 +169,10 @@ struct acpi_iort_root_complex { > > > u8 reserved[3]; /* Reserved, must be zero */ > > > }; > > > > > > -/* Values for ats_attribute field above */ > > > +/* Masks for ats_attribute field above */ > > > > > > -#define ACPI_IORT_ATS_SUPPORTED 0x00000001 /* The root > > > complex supports ATS */ > > > -#define ACPI_IORT_ATS_UNSUPPORTED 0x00000000 /* The root > > > complex doesn't support ATS */ > > > +#define ACPI_IORT_ATS_SUPPORTED (1) /* The root complex > > > supports ATS */ > > > +#define ACPI_IORT_PRI_SUPPORTED (1<<1) /* The root complex > > > supports PRI */ > > > > > > struct acpi_iort_smmu { > > > u64 base_address; /* SMMU base address */ > > > @@ -241,6 +243,17 @@ struct acpi_iort_pmcg { > > > u64 page1_base_address; > > > }; > > > > > > +struct acpi_iort_rmr { > > > + u32 rmr_count; > > > + u32 rmr_offset; > > > +}; > > > + > > > +struct acpi_iort_rmr_desc { > > > + u64 base_address; > > > + u64 length; > > > + u32 reserved; > > > +}; > > > + > > > > > > > > /********************************************************** > > ***** > > > **************** > > > * > > > * IVRS - I/O Virtualization Reporting Structure > > > -- > > > 2.17.1 > > > > > > _______________________________________________ > > > iommu mailing list > > > iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx > > > https://lists.linuxfoundation.org/mailman/listinfo/iommu > > _______________________________________________ > > Devel mailing list -- devel@xxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxx > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s