| Message ID | 1401975430-2648-2-git-send-email-thunder.leizhen@huawei.com |
|---|---|
| State | New |
| Headers | show |
Hi, On Thu, Jun 05, 2014 at 02:37:09PM +0100, Zhen Lei wrote: > This patch adds a description of the device tree binding for the Hisilicon > System MMU architecture. Similarly to my comments regarding the code, if this is a variant of the ARM SMMU architecture, then it almost certainly makes sense to express this as a delta againsts the ARM SMMU binding. > > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > --- > .../devicetree/bindings/iommu/hisilicon,smmu.txt | 70 ++++++++++++++++++++++ > 1 file changed, 70 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iommu/hisilicon,smmu.txt > > diff --git a/Documentation/devicetree/bindings/iommu/hisilicon,smmu.txt b/Documentation/devicetree/bindings/iommu/hisilicon,smmu.txt > new file mode 100644 > index 0000000..a2b2f23 > --- /dev/null > +++ b/Documentation/devicetree/bindings/iommu/hisilicon,smmu.txt > @@ -0,0 +1,70 @@ > +* Hisilicon System MMU Architecture Implementation > + > +Hisilicon SoCs may contain an implementation of the Hisilicon System Memory > +Management Unit Architecture, which can be used to provide 1 or 2 stages > +of address translation to bus masters external to the CPU. > + > +The SMMU may also raise interrupts in response to various fault > +conditions. > + > +** System MMU required properties: > + > +- compatible : Should be one of: > + > + "hisilicon,smmu-v1" > + > + depending on the particular implementation and/or the > + version of the architecture implemented. One of one possibilities? Are we expecting further variants? > + > +- reg : Base address and size of the SMMU. > + > +- #global-interrupts : The number of global interrupts exposed by the > + device. > + > +- interrupts : Interrupt list, with the first #global-irqs entries > + corresponding to the global interrupts and exactly one > + following entry corresponding to context interrupt. > + > +- smmu-masters : A list of phandles to device nodes representing bus > + masters for which the SMMU can provide a translation > + and their corresponding StreamIDs (see example below). > + > +** System MMU optional properties: > + > +- smmu-cb-memtype : A list of StreamIDs which not translate address but > + translate attributes. The StreamIDs list here can not be > + used for map(translation) mode again. > + StreamID first, then the type list below: > + 1, cahceable, WBRAWA, Normal outer and inner write-back > + 2, non-cacheable, Normal outer and inner non-cacheable > + 3, device, nGnRE > + others, bypass This sounds like configuration rather than device description. What is this for? Why is this necessary? > + > +- smmu-bypass-vmid : Specify which context bank is used for bypass mode. > + If omit, vmid=255 is default. Likewise, for all the points against smmu-cb-memtype. > + > +Example: > + > + smmu { Nit: missing unit-address; > + compatible = "hisilicon,smmu-v1"; > + reg = <0x40040000 0x1000>; > + #global-interrupts = <1>; > + > + /* > + * Global and context faults may use the same interrupt, if > + * only one exist. > + */ That comment sounds like it should be in the description of the interrupts property, not the example. > + interrupts = <0 188 4>, > + <0 188 4>; /* The last is the context interrupt */ > + > + /* > + * StreamID = 0 is bypass and force cacheable(WBRAWA). > + */ > + smmu-cb-memtype = <0x0 1>; Why? Cheers, Mark. > + > + /* > + * Two DMA controllers, each with exactly one StreamID. > + */ > + smmu-masters = <&dma0 0x0001>, > + <&dma1 0x0002>; > + }; > -- > 1.8.0 > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On Thursday 05 June 2014 21:37:09 Zhen Lei wrote: > +- smmu-masters : A list of phandles to device nodes representing bus > + masters for which the SMMU can provide a translation > + and their corresponding StreamIDs (see example below). > We're currently in the process of defining a generic binding for IOMMUs. While the smmu-masters property was copied from an existing binding, I think we will end up migrating away from that towards a common way to express those things, and we shouldn't add another one doing this in a nonstandard way. Please have a look at the latest discussion about the iommu binding using #iommu-cells and a reference from the master to the iommu and see if you can migrate your code to use that. Arnd
On Fri, Jun 06, 2014 at 08:48:26AM +0200, Arnd Bergmann wrote: > On Thursday 05 June 2014 21:37:09 Zhen Lei wrote: > > > +- smmu-masters : A list of phandles to device nodes representing bus > > + masters for which the SMMU can provide a translation > > + and their corresponding StreamIDs (see example below). > > > > We're currently in the process of defining a generic binding for IOMMUs. > > While the smmu-masters property was copied from an existing binding, > I think we will end up migrating away from that towards a common way > to express those things, and we shouldn't add another one doing this > in a nonstandard way. Please have a look at the latest discussion > about the iommu binding using #iommu-cells and a reference from the > master to the iommu and see if you can migrate your code to use that. Thanks for making this point -- I was going to do so yesterday but then hesitated due to uncertainty about whether this should really be a new driver. Either way, it would be very valuable at least to attempt to describe the Hisilicon SMMU implemenation using the new proposals, since that is a good test of how reusable the proposed generic binding actually is. Cheers ---Dave
On 2014/6/6 19:07, Dave Martin wrote: > On Fri, Jun 06, 2014 at 08:48:26AM +0200, Arnd Bergmann wrote: >> On Thursday 05 June 2014 21:37:09 Zhen Lei wrote: >> >>> +- smmu-masters : A list of phandles to device nodes representing bus >>> + masters for which the SMMU can provide a translation >>> + and their corresponding StreamIDs (see example below). >>> >> >> We're currently in the process of defining a generic binding for IOMMUs. >> >> While the smmu-masters property was copied from an existing binding, >> I think we will end up migrating away from that towards a common way >> to express those things, and we shouldn't add another one doing this >> in a nonstandard way. Please have a look at the latest discussion >> about the iommu binding using #iommu-cells and a reference from the >> master to the iommu and see if you can migrate your code to use that. > > Thanks for making this point -- I was going to do so yesterday but then > hesitated due to uncertainty about whether this should really be a new > driver. > > Either way, it would be very valuable at least to attempt to describe > the Hisilicon SMMU implemenation using the new proposals, since that is > a good test of how reusable the proposed generic binding actually is. > > Cheers > ---Dave > > . > Thanks. I adjusted my codes these day, I will send a new patch tommorrow.
On Fri, Jun 06, 2014 at 12:07:11PM +0100, Dave Martin wrote: > On Fri, Jun 06, 2014 at 08:48:26AM +0200, Arnd Bergmann wrote: > > On Thursday 05 June 2014 21:37:09 Zhen Lei wrote: > > > > > +- smmu-masters : A list of phandles to device nodes representing bus > > > + masters for which the SMMU can provide a translation > > > + and their corresponding StreamIDs (see example below). > > > > > > > We're currently in the process of defining a generic binding for IOMMUs. > > > > While the smmu-masters property was copied from an existing binding, > > I think we will end up migrating away from that towards a common way > > to express those things, and we shouldn't add another one doing this > > in a nonstandard way. Please have a look at the latest discussion > > about the iommu binding using #iommu-cells and a reference from the > > master to the iommu and see if you can migrate your code to use that. > > Thanks for making this point -- I was going to do so yesterday but then > hesitated due to uncertainty about whether this should really be a new > driver. > > Either way, it would be very valuable at least to attempt to describe > the Hisilicon SMMU implemenation using the new proposals, since that is > a good test of how reusable the proposed generic binding actually is. If this ends up being an addition to the existing ARM SMMU driver, I'm really not keen on using the new DT bindings. We're already stuck with the old bindings for that driver -- supporting both old and new in the same code only buys us maintenance headaches and pointless divergence within the driver. Will
On Monday 16 June 2014 17:26:53 Will Deacon wrote: > On Fri, Jun 06, 2014 at 12:07:11PM +0100, Dave Martin wrote: > > On Fri, Jun 06, 2014 at 08:48:26AM +0200, Arnd Bergmann wrote: > > > On Thursday 05 June 2014 21:37:09 Zhen Lei wrote: > > > > > > > +- smmu-masters : A list of phandles to device nodes representing bus > > > > + masters for which the SMMU can provide a translation > > > > + and their corresponding StreamIDs (see example below). > > > > > > > > > > We're currently in the process of defining a generic binding for IOMMUs. > > > > > > While the smmu-masters property was copied from an existing binding, > > > I think we will end up migrating away from that towards a common way > > > to express those things, and we shouldn't add another one doing this > > > in a nonstandard way. Please have a look at the latest discussion > > > about the iommu binding using #iommu-cells and a reference from the > > > master to the iommu and see if you can migrate your code to use that. > > > > Thanks for making this point -- I was going to do so yesterday but then > > hesitated due to uncertainty about whether this should really be a new > > driver. > > > > Either way, it would be very valuable at least to attempt to describe > > the Hisilicon SMMU implemenation using the new proposals, since that is > > a good test of how reusable the proposed generic binding actually is. > > If this ends up being an addition to the existing ARM SMMU driver, I'm > really not keen on using the new DT bindings. We're already stuck with > the old bindings for that driver -- supporting both old and new in the > same code only buys us maintenance headaches and pointless divergence > within the driver. We have to migrate the driver to the new binding anyway, it may be a bit painful, but there are not really any users yet so there is a chance we can remove the nonstandard code at some point, perhaps in a few years. Arnd
On Friday 06 June 2014 08:48:26 Arnd Bergmann wrote: > On Thursday 05 June 2014 21:37:09 Zhen Lei wrote: > > > +- smmu-masters : A list of phandles to device nodes representing bus > > + masters for which the SMMU can provide a translation > > + and their corresponding StreamIDs (see example below). > > > > We're currently in the process of defining a generic binding for IOMMUs. > > While the smmu-masters property was copied from an existing binding, > I think we will end up migrating away from that towards a common way > to express those things, and we shouldn't add another one doing this > in a nonstandard way. Please have a look at the latest discussion > about the iommu binding using #iommu-cells and a reference from the > master to the iommu and see if you can migrate your code to use that. Actually, nothing in 3.16 uses the broken binding yet, so I think we can just declare it obsolete and remove it once the new binding has been implemented. Arnd
On Mon, Jun 16, 2014 at 05:42:10PM +0100, Arnd Bergmann wrote: > On Monday 16 June 2014 17:26:53 Will Deacon wrote: > > On Fri, Jun 06, 2014 at 12:07:11PM +0100, Dave Martin wrote: > > > On Fri, Jun 06, 2014 at 08:48:26AM +0200, Arnd Bergmann wrote: > > > > On Thursday 05 June 2014 21:37:09 Zhen Lei wrote: > > > > > > > > > +- smmu-masters : A list of phandles to device nodes representing bus > > > > > + masters for which the SMMU can provide a translation > > > > > + and their corresponding StreamIDs (see example below). > > > > > > > > > > > > > We're currently in the process of defining a generic binding for IOMMUs. > > > > > > > > While the smmu-masters property was copied from an existing binding, > > > > I think we will end up migrating away from that towards a common way > > > > to express those things, and we shouldn't add another one doing this > > > > in a nonstandard way. Please have a look at the latest discussion > > > > about the iommu binding using #iommu-cells and a reference from the > > > > master to the iommu and see if you can migrate your code to use that. > > > > > > Thanks for making this point -- I was going to do so yesterday but then > > > hesitated due to uncertainty about whether this should really be a new > > > driver. > > > > > > Either way, it would be very valuable at least to attempt to describe > > > the Hisilicon SMMU implemenation using the new proposals, since that is > > > a good test of how reusable the proposed generic binding actually is. > > > > If this ends up being an addition to the existing ARM SMMU driver, I'm > > really not keen on using the new DT bindings. We're already stuck with > > the old bindings for that driver -- supporting both old and new in the > > same code only buys us maintenance headaches and pointless divergence > > within the driver. > > We have to migrate the driver to the new binding anyway, it may be > a bit painful, but there are not really any users yet so there > is a chance we can remove the nonstandard code at some point, > perhaps in a few years. The only way I see this working is if we kill the existing binding and move exclusively to the new one. I'm actually ok with that (we have no in-tree users), but it needs to happen ASAP in my opinion, otherwise we increase the window where the old binding can be adopted. Note that the next version of the ARM SMMU (v3) is considerably different to the current architecture, so a new driver (using the new bindings) will be required. This actually opens a wider question: if we don't have an in-tree user for a device-tree binding, do we consider that binding to be unused? Will
On Monday 16 June 2014 17:45:17 Will Deacon wrote: > On Mon, Jun 16, 2014 at 05:42:10PM +0100, Arnd Bergmann wrote: > > On Monday 16 June 2014 17:26:53 Will Deacon wrote: > > > On Fri, Jun 06, 2014 at 12:07:11PM +0100, Dave Martin wrote: > > > > On Fri, Jun 06, 2014 at 08:48:26AM +0200, Arnd Bergmann wrote: > > > > > On Thursday 05 June 2014 21:37:09 Zhen Lei wrote: > > > > > > > > > > > +- smmu-masters : A list of phandles to device nodes representing bus > > > > > > + masters for which the SMMU can provide a translation > > > > > > + and their corresponding StreamIDs (see example below). > > > > > > > > > > > > > > > > We're currently in the process of defining a generic binding for IOMMUs. > > > > > > > > > > While the smmu-masters property was copied from an existing binding, > > > > > I think we will end up migrating away from that towards a common way > > > > > to express those things, and we shouldn't add another one doing this > > > > > in a nonstandard way. Please have a look at the latest discussion > > > > > about the iommu binding using #iommu-cells and a reference from the > > > > > master to the iommu and see if you can migrate your code to use that. > > > > > > > > Thanks for making this point -- I was going to do so yesterday but then > > > > hesitated due to uncertainty about whether this should really be a new > > > > driver. > > > > > > > > Either way, it would be very valuable at least to attempt to describe > > > > the Hisilicon SMMU implemenation using the new proposals, since that is > > > > a good test of how reusable the proposed generic binding actually is. > > > > > > If this ends up being an addition to the existing ARM SMMU driver, I'm > > > really not keen on using the new DT bindings. We're already stuck with > > > the old bindings for that driver -- supporting both old and new in the > > > same code only buys us maintenance headaches and pointless divergence > > > within the driver. > > > > We have to migrate the driver to the new binding anyway, it may be > > a bit painful, but there are not really any users yet so there > > is a chance we can remove the nonstandard code at some point, > > perhaps in a few years. > > The only way I see this working is if we kill the existing binding and move > exclusively to the new one. I'm actually ok with that (we have no in-tree > users), but it needs to happen ASAP in my opinion, otherwise we increase the > window where the old binding can be adopted. I agree. I was hoping to get the generic binding ready for 3.16, but that didn't happen. Maybe we can add a small patch to the binding to explain that it will change in the future. > Note that the next version of the ARM SMMU (v3) is considerably different to > the current architecture, so a new driver (using the new bindings) will be > required. > > This actually opens a wider question: if we don't have an in-tree user for a > device-tree binding, do we consider that binding to be unused? Not in general, but often. We don't require dts files to be in the kernel, so we have to apply a bit of common sense. If anyone knows of out-of-tree users of the binding that are actually working with upstream kernels, we need a migration path. Anything that also requires out-of-tree kernel patches however is something we don't have to worry about. Arnd
On Mon, Jun 16, 2014 at 06:25:35PM +0100, Arnd Bergmann wrote: > On Monday 16 June 2014 17:45:17 Will Deacon wrote: > > On Mon, Jun 16, 2014 at 05:42:10PM +0100, Arnd Bergmann wrote: > > > We have to migrate the driver to the new binding anyway, it may be > > > a bit painful, but there are not really any users yet so there > > > is a chance we can remove the nonstandard code at some point, > > > perhaps in a few years. > > > > The only way I see this working is if we kill the existing binding and move > > exclusively to the new one. I'm actually ok with that (we have no in-tree > > users), but it needs to happen ASAP in my opinion, otherwise we increase the > > window where the old binding can be adopted. > > I agree. I was hoping to get the generic binding ready for 3.16, but that > didn't happen. Maybe we can add a small patch to the binding to explain > that it will change in the future. Perhaps, but saying "don't use this" isn't much better than just ripping out the support altogether. That said, I won't object to a patch adding a big fat warning to the current binding docs if it dissuades people from using what we currently have. > > Note that the next version of the ARM SMMU (v3) is considerably different to > > the current architecture, so a new driver (using the new bindings) will be > > required. > > > > This actually opens a wider question: if we don't have an in-tree user for a > > device-tree binding, do we consider that binding to be unused? > > Not in general, but often. We don't require dts files to be in the kernel, > so we have to apply a bit of common sense. If anyone knows of out-of-tree > users of the binding that are actually working with upstream kernels, > we need a migration path. Anything that also requires out-of-tree kernel > patches however is something we don't have to worry about. Ok. If Thierry's binding gets in for 3.17, then I'll try to convert the ARM SMMU driver over to it for 3.18 providing we don't grow any in-tree users of the existing binding in the meantime (or 3.17 depending on how early it gets queued). Sound fair? Will
On Monday 16 June 2014 19:26:45 Will Deacon wrote: > On Mon, Jun 16, 2014 at 06:25:35PM +0100, Arnd Bergmann wrote: > > On Monday 16 June 2014 17:45:17 Will Deacon wrote: > > > On Mon, Jun 16, 2014 at 05:42:10PM +0100, Arnd Bergmann wrote: > > > > We have to migrate the driver to the new binding anyway, it may be > > > > a bit painful, but there are not really any users yet so there > > > > is a chance we can remove the nonstandard code at some point, > > > > perhaps in a few years. > > > > > > The only way I see this working is if we kill the existing binding and move > > > exclusively to the new one. I'm actually ok with that (we have no in-tree > > > users), but it needs to happen ASAP in my opinion, otherwise we increase the > > > window where the old binding can be adopted. > > > > I agree. I was hoping to get the generic binding ready for 3.16, but that > > didn't happen. Maybe we can add a small patch to the binding to explain > > that it will change in the future. > > Perhaps, but saying "don't use this" isn't much better than just ripping out > the support altogether. That said, I won't object to a patch adding a big > fat warning to the current binding docs if it dissuades people from using > what we currently have. Ok. > > > Note that the next version of the ARM SMMU (v3) is considerably different to > > > the current architecture, so a new driver (using the new bindings) will be > > > required. > > > > > > This actually opens a wider question: if we don't have an in-tree user for a > > > device-tree binding, do we consider that binding to be unused? > > > > Not in general, but often. We don't require dts files to be in the kernel, > > so we have to apply a bit of common sense. If anyone knows of out-of-tree > > users of the binding that are actually working with upstream kernels, > > we need a migration path. Anything that also requires out-of-tree kernel > > patches however is something we don't have to worry about. > > Ok. If Thierry's binding gets in for 3.17, then I'll try to convert the ARM > SMMU driver over to it for 3.18 providing we don't grow any in-tree users of > the existing binding in the meantime (or 3.17 depending on how early it gets > queued). > > Sound fair? Sounds good. Let's make sure we get this done quickly now. I think there isn't much controversy left with the binding, though this particular one has been tough in the past. Arnd
On 2014/6/17 0:42, Arnd Bergmann wrote: > On Monday 16 June 2014 17:26:53 Will Deacon wrote: >> On Fri, Jun 06, 2014 at 12:07:11PM +0100, Dave Martin wrote: >>> On Fri, Jun 06, 2014 at 08:48:26AM +0200, Arnd Bergmann wrote: >>>> On Thursday 05 June 2014 21:37:09 Zhen Lei wrote: >>>> >>>>> +- smmu-masters : A list of phandles to device nodes representing bus >>>>> + masters for which the SMMU can provide a translation >>>>> + and their corresponding StreamIDs (see example below). >>>>> >>>> >>>> We're currently in the process of defining a generic binding for IOMMUs. >>>> >>>> While the smmu-masters property was copied from an existing binding, >>>> I think we will end up migrating away from that towards a common way >>>> to express those things, and we shouldn't add another one doing this >>>> in a nonstandard way. Please have a look at the latest discussion >>>> about the iommu binding using #iommu-cells and a reference from the >>>> master to the iommu and see if you can migrate your code to use that. >>> >>> Thanks for making this point -- I was going to do so yesterday but then >>> hesitated due to uncertainty about whether this should really be a new >>> driver. >>> >>> Either way, it would be very valuable at least to attempt to describe >>> the Hisilicon SMMU implemenation using the new proposals, since that is >>> a good test of how reusable the proposed generic binding actually is. >> >> If this ends up being an addition to the existing ARM SMMU driver, I'm >> really not keen on using the new DT bindings. We're already stuck with >> the old bindings for that driver -- supporting both old and new in the >> same code only buys us maintenance headaches and pointless divergence >> within the driver. > > We have to migrate the driver to the new binding anyway, it may be > a bit painful, but there are not really any users yet so there > is a chance we can remove the nonstandard code at some point, > perhaps in a few years. > > Arnd > > . > My driver will base on arm-smmu, and I saw Will Deacon had agreed to you. So me too.
On Tue, Jun 17, 2014 at 09:14:41AM +0200, Arnd Bergmann wrote: > On Monday 16 June 2014 19:26:45 Will Deacon wrote: > > On Mon, Jun 16, 2014 at 06:25:35PM +0100, Arnd Bergmann wrote: > > > On Monday 16 June 2014 17:45:17 Will Deacon wrote: > > > > On Mon, Jun 16, 2014 at 05:42:10PM +0100, Arnd Bergmann wrote: > > > > > We have to migrate the driver to the new binding anyway, it may be > > > > > a bit painful, but there are not really any users yet so there > > > > > is a chance we can remove the nonstandard code at some point, > > > > > perhaps in a few years. > > > > > > > > The only way I see this working is if we kill the existing binding and move > > > > exclusively to the new one. I'm actually ok with that (we have no in-tree > > > > users), but it needs to happen ASAP in my opinion, otherwise we increase the > > > > window where the old binding can be adopted. > > > > > > I agree. I was hoping to get the generic binding ready for 3.16, but that > > > didn't happen. Maybe we can add a small patch to the binding to explain > > > that it will change in the future. > > > > Perhaps, but saying "don't use this" isn't much better than just ripping out > > the support altogether. That said, I won't object to a patch adding a big > > fat warning to the current binding docs if it dissuades people from using > > what we currently have. > > Ok. > > > > > Note that the next version of the ARM SMMU (v3) is considerably different to > > > > the current architecture, so a new driver (using the new bindings) will be > > > > required. > > > > > > > > This actually opens a wider question: if we don't have an in-tree user for a > > > > device-tree binding, do we consider that binding to be unused? > > > > > > Not in general, but often. We don't require dts files to be in the kernel, > > > so we have to apply a bit of common sense. If anyone knows of out-of-tree > > > users of the binding that are actually working with upstream kernels, > > > we need a migration path. Anything that also requires out-of-tree kernel > > > patches however is something we don't have to worry about. > > > > Ok. If Thierry's binding gets in for 3.17, then I'll try to convert the ARM > > SMMU driver over to it for 3.18 providing we don't grow any in-tree users of > > the existing binding in the meantime (or 3.17 depending on how early it gets > > queued). > > > > Sound fair? > > Sounds good. Let's make sure we get this done quickly now. I think there > isn't much controversy left with the binding, though this particular one > has been tough in the past. I'm not sure how much else needs to be discussed for the generic binding since there seemed to be various degrees of agreement and then somebody came up with another use-case where the current proposal wouldn't work. I always thought that if we kept things completely generic (that is, leave it completely up to the device-specific binding what the specifier is used for), then there shouldn't be much controversy at all and the specifics could be handled in drivers where it makes the most sense. That said, I'll be mostly away from a computer this week, so I expect to only be able to get back to this sometime next week at the earliest. Thierry
Hi Will, > -----Original Message----- > From: linux-arm-kernel [mailto:linux-arm-kernel- > bounces@lists.infradead.org] On Behalf Of Will Deacon > Sent: Monday, June 16, 2014 11:57 PM > To: Arnd Bergmann > Cc: Kefeng Wang; Catalin Marinas; Tianhong Ding; huxinwei@huawei.com; > Zefan Li; Zhen Lei; Dave P Martin; linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH RFC v1 1/2] documentation/iommu: Add description of > Hisilicon System MMU binding > > On Mon, Jun 16, 2014 at 06:25:35PM +0100, Arnd Bergmann wrote: > > On Monday 16 June 2014 17:45:17 Will Deacon wrote: > > > On Mon, Jun 16, 2014 at 05:42:10PM +0100, Arnd Bergmann wrote: > > > > We have to migrate the driver to the new binding anyway, it may be > > > > a bit painful, but there are not really any users yet so there is > > > > a chance we can remove the nonstandard code at some point, perhaps > > > > in a few years. > > > > > > The only way I see this working is if we kill the existing binding > > > and move exclusively to the new one. I'm actually ok with that (we > > > have no in-tree users), but it needs to happen ASAP in my opinion, > > > otherwise we increase the window where the old binding can be > adopted. > > > > I agree. I was hoping to get the generic binding ready for 3.16, but > > that didn't happen. Maybe we can add a small patch to the binding to > > explain that it will change in the future. > > Perhaps, but saying "don't use this" isn't much better than just ripping > out the support altogether. That said, I won't object to a patch adding a > big fat warning to the current binding docs if it dissuades people from > using what we currently have. > > > > Note that the next version of the ARM SMMU (v3) is considerably > > > different to the current architecture, so a new driver (using the > > > new bindings) will be required. > > > > > > This actually opens a wider question: if we don't have an in-tree > > > user for a device-tree binding, do we consider that binding to be > unused? > > > > Not in general, but often. We don't require dts files to be in the > > kernel, so we have to apply a bit of common sense. If anyone knows of > > out-of-tree users of the binding that are actually working with > > upstream kernels, we need a migration path. Anything that also > > requires out-of-tree kernel patches however is something we don't have > to worry about. > > Ok. If Thierry's binding gets in for 3.17, then I'll try to convert the > ARM SMMU driver over to it for 3.18 providing we don't grow any in-tree > users of the existing binding in the meantime (or 3.17 depending on how > early it gets queued). > > Sound fair? Would you be considering the handling of hot plug masters in the arm-smmu driver while incorporating the new binding? -Varun
diff --git a/Documentation/devicetree/bindings/iommu/hisilicon,smmu.txt b/Documentation/devicetree/bindings/iommu/hisilicon,smmu.txt new file mode 100644 index 0000000..a2b2f23 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/hisilicon,smmu.txt @@ -0,0 +1,70 @@ +* Hisilicon System MMU Architecture Implementation + +Hisilicon SoCs may contain an implementation of the Hisilicon System Memory +Management Unit Architecture, which can be used to provide 1 or 2 stages +of address translation to bus masters external to the CPU. + +The SMMU may also raise interrupts in response to various fault +conditions. + +** System MMU required properties: + +- compatible : Should be one of: + + "hisilicon,smmu-v1" + + depending on the particular implementation and/or the + version of the architecture implemented. + +- reg : Base address and size of the SMMU. + +- #global-interrupts : The number of global interrupts exposed by the + device. + +- interrupts : Interrupt list, with the first #global-irqs entries + corresponding to the global interrupts and exactly one + following entry corresponding to context interrupt. + +- smmu-masters : A list of phandles to device nodes representing bus + masters for which the SMMU can provide a translation + and their corresponding StreamIDs (see example below). + +** System MMU optional properties: + +- smmu-cb-memtype : A list of StreamIDs which not translate address but + translate attributes. The StreamIDs list here can not be + used for map(translation) mode again. + StreamID first, then the type list below: + 1, cahceable, WBRAWA, Normal outer and inner write-back + 2, non-cacheable, Normal outer and inner non-cacheable + 3, device, nGnRE + others, bypass + +- smmu-bypass-vmid : Specify which context bank is used for bypass mode. + If omit, vmid=255 is default. + +Example: + + smmu { + compatible = "hisilicon,smmu-v1"; + reg = <0x40040000 0x1000>; + #global-interrupts = <1>; + + /* + * Global and context faults may use the same interrupt, if + * only one exist. + */ + interrupts = <0 188 4>, + <0 188 4>; /* The last is the context interrupt */ + + /* + * StreamID = 0 is bypass and force cacheable(WBRAWA). + */ + smmu-cb-memtype = <0x0 1>; + + /* + * Two DMA controllers, each with exactly one StreamID. + */ + smmu-masters = <&dma0 0x0001>, + <&dma1 0x0002>; + };
This patch adds a description of the device tree binding for the Hisilicon System MMU architecture. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> --- .../devicetree/bindings/iommu/hisilicon,smmu.txt | 70 ++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/hisilicon,smmu.txt -- 1.8.0