diff for duplicates of <1355187644.5334.23@snotra> diff --git a/a/1.txt b/N1/1.txt index 042183c..abe822f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,12 +1,12 @@ On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote: -> -> +>=20 +>=20 > > -----Original Message----- > > From: Wood Scott-B07421 > > Sent: Tuesday, December 04, 2012 11:53 PM > > To: Sethi Varun-B16395 > > Cc: Wood Scott-B07421; Joerg Roedel; linux-kernel@vger.kernel.org; -> > iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; +> > iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; =20 > Tabi > > Timur-B04825 > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes @@ -19,13 +19,13 @@ On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote: > > > > From: Wood Scott-B07421 > > > > Sent: Monday, December 03, 2012 10:34 PM > > > > To: Sethi Varun-B16395 -> > > > Cc: Joerg Roedel; linux-kernel@vger.kernel.org; +> > > > Cc: Joerg Roedel; linux-kernel@vger.kernel.org; =20 > iommu@lists.linux- -> > > > foundation.org; Wood Scott-B07421; +> > > > foundation.org; Wood Scott-B07421; =20 > linuxppc-dev@lists.ozlabs.org; > > > Tabi > > > > Timur-B04825 -> > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain +> > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain =20 > attributes > > > > required by fsl PAMU driver. > > > > @@ -33,16 +33,16 @@ On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote: > > > > > > > > > > > > > > > > -----Original Message----- -> > > > > > From: iommu-bounces@lists.linux-foundation.org +> > > > > > From: iommu-bounces@lists.linux-foundation.org =20 > [mailto:iommu- -> > > > > > bounces@lists.linux-foundation.org] On Behalf Of Joerg +> > > > > > bounces@lists.linux-foundation.org] On Behalf Of Joerg =20 > Roedel > > > > > > Sent: Sunday, December 02, 2012 7:33 PM > > > > > > To: Sethi Varun-B16395 > > > > > > Cc: linux-kernel@vger.kernel.org; > > > iommu@lists.linux-foundation.org; > > > > > Wood -> > > > > > Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi +> > > > > > Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi =20 > Timur-B04825 > > > > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain > > > attributes @@ -61,7 +61,7 @@ On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote: > > > > > of the > > > > > > subwindows? > > > > > > -> > > > > [Sethi Varun-B16395] It's possible to map a part of the +> > > > > [Sethi Varun-B16395] It's possible to map a part of the =20 > subwindow > > > i.e. > > > > > size of the mapping can be less than the sub window size. @@ -84,52 +84,52 @@ On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote: > > > > > > > + * subwindows. > > > > > > > + */ > > > > > > -> > > > > > This semantic is ugly, how about a feature detection +> > > > > > This semantic is ugly, how about a feature detection =20 > mechanism? > > > > > > > > > > > [Sethi Varun-B16395] A feature mechanism to query the type of > > > IOMMU? > > > > -> > > > A feature mechanism to determine whether this subwindow +> > > > A feature mechanism to determine whether this subwindow =20 > mechanism is > > > > available, and what the limits are. > > > > > > > So, we use the IOMMU capability interface to find out if IOMMU -> > > supports sub windows or not, right? But still number of sub +> > > supports sub windows or not, right? But still number of sub =20 > windows -> > > would be specified as a part of the geometry and the valid value +> > > would be specified as a part of the geometry and the valid value =20 > for > > > sub windows would 0,1 or actual number of sub windows. > > -> > How does a user of the interface find out what values are possible +> > How does a user of the interface find out what values are possible =20 > for -> > the "actual number of subwindows"? How does a user of the +> > the "actual number of subwindows"? How does a user of the =20 > interface find -> > out whether there are any limitations on specifying a value of zero +> > out whether there are any limitations on specifying a value of zero =20 > (in > > the case of PAMU, that would be a maximum 1 MiB naturally-aligned > > aperture to support arbitrary 4KiB mappings)? -> How about if we say that the default value for subwindows is zero and -> this what you get when you read the geometry (iommu_get_attr) after -> initializing the domain? In that case the user would know that -> implication of setting subwindows to zero with respect to the +> How about if we say that the default value for subwindows is zero and =20 +> this what you get when you read the geometry (iommu_get_attr) after =20 +> initializing the domain? In that case the user would know that =20 +> implication of setting subwindows to zero with respect to the =20 > aperture size. -So it would default to the maximum aperture size possible with no -subwindows? That might be OK, though is there a way to reset the +So it would default to the maximum aperture size possible with no =20 +subwindows? That might be OK, though is there a way to reset the =20 domain later on to get back to that informational state? How about finding out the maximum number of subwindows? -> Also, should we introduce an additional API like "iommu_check_attr", -> which the user can use to validate the attribute value. For example -> in case of geometry, the user can fill up the structure and pass it -> to the iommu driver in order to verify the aperture and subwindows +> Also, should we introduce an additional API like "iommu_check_attr", =20 +> which the user can use to validate the attribute value. For example =20 +> in case of geometry, the user can fill up the structure and pass it =20 +> to the iommu driver in order to verify the aperture and subwindows =20 > field. -Doesn't the current API raise an error if you do something -unsupported? In any case I don't think making a series of guesses and -seeing which ones are accepted is a good substitute for being able to +Doesn't the current API raise an error if you do something =20 +unsupported? In any case I don't think making a series of guesses and =20 +seeing which ones are accepted is a good substitute for being able to =20 simply read out the relevant parameters. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index bf61367..8493e75 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,21 +7,21 @@ "To\0Sethi Varun-B16395 <B16395@freescale.com>\0" "Cc\0Wood Scott-B07421 <B07421@freescale.com>" Joerg Roedel <joro@8bytes.org> + Tabi Timur-B04825 <B04825@freescale.com> linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> iommu@lists.linux-foundation.org <iommu@lists.linux-foundation.org> - linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> - " Tabi Timur-B04825 <B04825@freescale.com>\0" + " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" "\00:1\0" "b\0" "On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote:\n" - "> \n" - "> \n" + ">=20\n" + ">=20\n" "> > -----Original Message-----\n" "> > From: Wood Scott-B07421\n" "> > Sent: Tuesday, December 04, 2012 11:53 PM\n" "> > To: Sethi Varun-B16395\n" "> > Cc: Wood Scott-B07421; Joerg Roedel; linux-kernel@vger.kernel.org;\n" - "> > iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; \n" + "> > iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; =20\n" "> Tabi\n" "> > Timur-B04825\n" "> > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes\n" @@ -34,13 +34,13 @@ "> > > > From: Wood Scott-B07421\n" "> > > > Sent: Monday, December 03, 2012 10:34 PM\n" "> > > > To: Sethi Varun-B16395\n" - "> > > > Cc: Joerg Roedel; linux-kernel@vger.kernel.org; \n" + "> > > > Cc: Joerg Roedel; linux-kernel@vger.kernel.org; =20\n" "> iommu@lists.linux-\n" - "> > > > foundation.org; Wood Scott-B07421; \n" + "> > > > foundation.org; Wood Scott-B07421; =20\n" "> linuxppc-dev@lists.ozlabs.org;\n" "> > > Tabi\n" "> > > > Timur-B04825\n" - "> > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain \n" + "> > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain =20\n" "> attributes\n" "> > > > required by fsl PAMU driver.\n" "> > > >\n" @@ -48,16 +48,16 @@ "> > > > >\n" "> > > > >\n" "> > > > > > -----Original Message-----\n" - "> > > > > > From: iommu-bounces@lists.linux-foundation.org \n" + "> > > > > > From: iommu-bounces@lists.linux-foundation.org =20\n" "> [mailto:iommu-\n" - "> > > > > > bounces@lists.linux-foundation.org] On Behalf Of Joerg \n" + "> > > > > > bounces@lists.linux-foundation.org] On Behalf Of Joerg =20\n" "> Roedel\n" "> > > > > > Sent: Sunday, December 02, 2012 7:33 PM\n" "> > > > > > To: Sethi Varun-B16395\n" "> > > > > > Cc: linux-kernel@vger.kernel.org;\n" "> > > iommu@lists.linux-foundation.org;\n" "> > > > > Wood\n" - "> > > > > > Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi \n" + "> > > > > > Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi =20\n" "> Timur-B04825\n" "> > > > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain\n" "> > > attributes\n" @@ -76,7 +76,7 @@ "> > > > > of the\n" "> > > > > > subwindows?\n" "> > > > > >\n" - "> > > > > [Sethi Varun-B16395] It's possible to map a part of the \n" + "> > > > > [Sethi Varun-B16395] It's possible to map a part of the =20\n" "> subwindow\n" "> > > i.e.\n" "> > > > > size of the mapping can be less than the sub window size.\n" @@ -99,54 +99,54 @@ "> > > > > > > +\t * subwindows.\n" "> > > > > > > +\t */\n" "> > > > > >\n" - "> > > > > > This semantic is ugly, how about a feature detection \n" + "> > > > > > This semantic is ugly, how about a feature detection =20\n" "> mechanism?\n" "> > > > > >\n" "> > > > > [Sethi Varun-B16395] A feature mechanism to query the type of\n" "> > > IOMMU?\n" "> > > >\n" - "> > > > A feature mechanism to determine whether this subwindow \n" + "> > > > A feature mechanism to determine whether this subwindow =20\n" "> mechanism is\n" "> > > > available, and what the limits are.\n" "> > > >\n" "> > > So, we use the IOMMU capability interface to find out if IOMMU\n" - "> > > supports sub windows or not, right? But still number of sub \n" + "> > > supports sub windows or not, right? But still number of sub =20\n" "> windows\n" - "> > > would be specified as a part of the geometry and the valid value \n" + "> > > would be specified as a part of the geometry and the valid value =20\n" "> for\n" "> > > sub windows would 0,1 or actual number of sub windows.\n" "> >\n" - "> > How does a user of the interface find out what values are possible \n" + "> > How does a user of the interface find out what values are possible =20\n" "> for\n" - "> > the \"actual number of subwindows\"? How does a user of the \n" + "> > the \"actual number of subwindows\"? How does a user of the =20\n" "> interface find\n" - "> > out whether there are any limitations on specifying a value of zero \n" + "> > out whether there are any limitations on specifying a value of zero =20\n" "> (in\n" "> > the case of PAMU, that would be a maximum 1 MiB naturally-aligned\n" "> > aperture to support arbitrary 4KiB mappings)?\n" - "> How about if we say that the default value for subwindows is zero and \n" - "> this what you get when you read the geometry (iommu_get_attr) after \n" - "> initializing the domain? In that case the user would know that \n" - "> implication of setting subwindows to zero with respect to the \n" + "> How about if we say that the default value for subwindows is zero and =20\n" + "> this what you get when you read the geometry (iommu_get_attr) after =20\n" + "> initializing the domain? In that case the user would know that =20\n" + "> implication of setting subwindows to zero with respect to the =20\n" "> aperture size.\n" "\n" - "So it would default to the maximum aperture size possible with no \n" - "subwindows? That might be OK, though is there a way to reset the \n" + "So it would default to the maximum aperture size possible with no =20\n" + "subwindows? That might be OK, though is there a way to reset the =20\n" "domain later on to get back to that informational state?\n" "\n" "How about finding out the maximum number of subwindows?\n" "\n" - "> Also, should we introduce an additional API like \"iommu_check_attr\", \n" - "> which the user can use to validate the attribute value. For example \n" - "> in case of geometry, the user can fill up the structure and pass it \n" - "> to the iommu driver in order to verify the aperture and subwindows \n" + "> Also, should we introduce an additional API like \"iommu_check_attr\", =20\n" + "> which the user can use to validate the attribute value. For example =20\n" + "> in case of geometry, the user can fill up the structure and pass it =20\n" + "> to the iommu driver in order to verify the aperture and subwindows =20\n" "> field.\n" "\n" - "Doesn't the current API raise an error if you do something \n" - "unsupported? In any case I don't think making a series of guesses and \n" - "seeing which ones are accepted is a good substitute for being able to \n" + "Doesn't the current API raise an error if you do something =20\n" + "unsupported? In any case I don't think making a series of guesses and =20\n" + "seeing which ones are accepted is a good substitute for being able to =20\n" "simply read out the relevant parameters.\n" "\n" - -Scott + -Scott= -700abe31fe6a2b1d7c1f69b483c6a87a20f20bc6e4588e76841dd1e40ba953b1 +969038de77b83bbbc5f0e0f7d53f40d9a2d3466fbab1d118eb8868ed85f66380
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.